Remodel your MCP structure: Unite MCP servers by AgentCore Gateway

As AI brokers are adopted at scale, developer groups can create dozens to lots of of specialised Model Context Protocol (MCP) servers, tailor-made for particular agent use case and area, group capabilities or groups. Organizations additionally have to combine their very own current MCP servers or open supply MCP servers for his or her AI workflows. There’s a want for a option to effectively mix these current MCP servers–whether or not custom-built, publicly out there, or open supply–right into a unified interface that AI brokers can readily devour and groups can seamlessly share throughout the group.

Earlier this yr, we launched Amazon Bedrock AgentCore Gateway, a totally managed service that serves as a centralized MCP device server, offering a unified interface the place brokers can uncover, entry, and invoke instruments. At the moment, we’re extending help for current MCP servers as a brand new goal kind in AgentCore Gateway. With this functionality, you possibly can group a number of task-specific MCP servers aligned to agent objectives behind a single, manageable MCP gateway interface. This reduces the operational complexity of sustaining separate gateways, whereas offering the identical centralized device and authentication administration that existed for REST APIs and AWS Lambda capabilities.

With no centralized method, prospects face important challenges: discovering and sharing instruments throughout organizations turns into fragmented, managing authentication throughout a number of MCP servers grows more and more complicated, and sustaining separate gateway cases for every server shortly turns into unmanageable. Amazon Bedrock AgentCore Gateway helps solves these challenges by treating current MCP servers as native targets, giving prospects a single level of management for routing, authentication, and power administration—making it as easy to combine MCP servers as it’s so as to add different targets to the gateway.

Breaking down MCP silos: Why enterprise groups want a unified Gateway

Let’s discover this by a real-world instance of an e-commerce ordering system, the place totally different groups preserve specialised MCP servers for his or her particular domains. Contemplate an enterprise e-commerce system the place totally different groups have developed specialised MCP servers:

• The Procuring Cart crew maintains an MCP server with cart administration instruments
• The Product Catalog crew runs their MCP server for product searching and search
• The Promotions crew operates an MCP server dealing with promotional logic

Beforehand, an ordering agent would wish to work together with every of those MCP servers individually, managing a number of connections and authentication contexts. With the brand new MCP server goal help in AgentCore Gateway, these specialised servers can now be unified underneath a single gateway whereas sustaining their team-specific possession and entry controls. The facility of this method lies in its organizational flexibility. Groups can group their MCP servers primarily based on a number of logical standards:

• Enterprise unit alignment: Arrange the MCP servers by enterprise unit
• Product function boundaries: Every product crew owns their MCP server with domain-specific instruments permitting them to take care of clear possession whereas offering a unified interface for his or her brokers
• Safety and entry management: Completely different MCP servers require totally different authentication mechanisms. The gateway handles the authentication complexity, making it easy for approved brokers to entry the instruments they want

The next diagram illustrates how an ordering agent interacts with a number of MCP servers by AgentCore Gateway. The agent connects to the gateway and discovers the out there instruments. Every crew maintains management over their domain-specific instruments whereas contributing to a cohesive agent expertise. The gateway handles device naming collisions, authentication, and supplies unified semantic search throughout the instruments.

The AgentCore Gateway serves as an integration hub in trendy agentic architectures, providing a unified interface for connecting numerous agent implementations with a big selection of device suppliers. The structure, as illustrated within the diagram, demonstrates how the gateway bridges the hole between agent and power implementation approaches, now enhanced with the power to straight combine MCP server targets.

AgentCore Gateway integration structure

In AgentCore Gateway, a goal defines the APIs, Lambda capabilities, or different MCP servers {that a} gateway will present as instruments to an agent. Targets could be Lambda capabilities, OpenAPI specs, Smithy fashions, MCP servers, or different device definitions.

The goal integration facet of the structure showcases the gateway’s versatility in device integration. With the brand new MCP server goal help, the gateway can straight incorporate instruments from public MCP servers, treating them as first-class residents alongside different goal varieties. This functionality extends to federation eventualities the place one AgentCore Gateway occasion can function a goal for one more, for hierarchical device group throughout organizational boundaries. The gateway can seamlessly combine with AgentCore Runtime cases that expose brokers as instruments, personal MCP servers maintained by prospects, conventional AWS Lambda capabilities, and each Smithy and AWS service APIs.

Past goal variety, the gateway’s authentication structure supplies extra operational advantages. The gateway decouples its inbound authentication from goal techniques, letting brokers entry instruments that use a number of id suppliers by a single interface. This centralized method simplifies growth, deployment, and upkeep of AI brokers. Now, the identical method can be utilized for MCP server targets, the place the gateway manages the complexity of interfacing with the server utilizing the configured id supplier for the goal.

With this authentication basis you get refined device administration capabilities by a unified structure. When an agent requests device discovery, the gateway supplies a constant view throughout the built-in targets, with instruments from MCP servers showing alongside Lambda capabilities and conventional APIs. The semantic search functionality operates uniformly throughout the device varieties, so brokers can uncover related instruments no matter their implementation. Throughout device invocation, the gateway handles the required protocol translations, authentication flows, and information transformations, presenting a clear, constant interface to brokers whereas managing the complexity of various goal techniques behind the scenes.

The addition of MCP server goal help represents a major evolution within the gateway’s capabilities. Organizations can now straight combine MCP-native instruments whereas sustaining their investments in conventional APIs and Lambda capabilities. This flexibility permits for gradual migration methods the place groups can undertake MCP-native implementations at their very own tempo whereas facilitating steady operation of current integrations. The gateway’s synchronization mechanisms be sure that device definitions stay present throughout the totally different goal varieties, whereas its authentication and authorization techniques present constant safety controls whatever the underlying device implementation.

The gateway combines MCP servers, conventional APIs, and serverless capabilities right into a coherent device setting. This functionality, together with enterprise-grade safety and efficiency, makes it a useful infrastructure for agentic computing.

Answer Walkthrough

On this put up, we’ll information you thru the steps to arrange an MCP server goal in AgentCore Gateway, which is so simple as including a brand new MCP server kind goal to a brand new or current MCP Gateway. Including an MCP server to an AgentCore Gateway will permit you to centralize your device administration, safety authentication, and operational greatest practices with managing MCP servers at scale.

Get began with including MCP Server into AgentCore Gateway

To get began, you’ll create an AgentCore Gateway and add your MCP Server as a goal.

Stipulations

Confirm you have got the next stipulations:

You’ll be able to create gateways and add targets by a number of interfaces:

The next sensible examples and code snippets exhibit how one can arrange and use Amazon Bedrock AgentCore Gateway. For an interactive walkthrough, you should utilize these Jupyter Notebook samples on GitHub.

Create a gateway

To create a gateway, you should utilize the AgentCore starter toolkit to create a default authorization configuration with Amazon Cognito for JWT-based inbound authorization. You can even use one other OAuth 2.0-compliant authentication supplier as a substitute of Cognito.

import time
import boto3

gateway_client = boto3.consumer("bedrock-agentcore-control")

# Create an authorization configuration, that specifies what consumer is allowed to entry this Gateway
auth_config = {
    "customJWTAuthorizer": {
        "allowedClients": ['<cognito_client_id>'], # Shopper MUST match with the ClientId configured in Cognito.
        "discoveryUrl": '<cognito_oauth_discovery_url>',
    }
}

# Name the create_gateway API
# This operation is asynchronous so could take time for Gateway creation
# This Gateway will leverage a CUSTOM_JWT authorizer, the Cognito Consumer Pool we reference in auth_config
def deploy_gateway(poll_interval=5):
    create_response = gateway_client.create_gateway(
        identify="DemoGateway",
        roleArn="<IAM Function>", # The IAM Function will need to have permissions to create/listing/get/delete Gateway
        protocolType="MCP",
        authorizerType="CUSTOM_JWT",
        authorizerConfiguration=auth_config,
        description="AgentCore Gateway with MCP Server Goal",
    )
    gatewayID = create_response["gatewayId"]
    gatewayURL = create_response["gatewayUrl"]
    
    # Await deployment
    whereas True:
        status_response = gateway_client.get_gateway(gatewayIdentifier=gatewayID)
        standing = status_response["status"]
        if standing == "READY":
            print("✅ AgentCore Gateway is READY!")
            break
        elif standing in ["FAILED"]:
            print(f"❌ Deployment failed: {standing}")
            return None
        print(f"Standing: {standing} - ready...")
        time.sleep(poll_interval)

if __name__ == "__main__":
    deploy_gateway()

# Values with < > must be changed with actual values

 Create a pattern MCP Server

For instance, let’s create a pattern MCP server with three easy instruments that return static responses. The server makes use of FastMCP with stateless_http=True which is required for AgentCore Runtime compatibility.

from mcp.server.fastmcp import FastMCP

mcp = FastMCP(host="0.0.0.0", stateless_http=True)

@mcp.device()
def getOrder() -> int:
    """Get an order"""
    return 123

@mcp.device()
def updateOrder(orderId: int) -> int:
    """Replace current order"""
    return 456

@mcp.device()
def cancelOrder(orderId: int) -> int:
    """cancel current order"""
    return 789

if __name__ == "__main__":
    mcp.run(transport="streamable-http")

Configure AgentCore Runtime deployment

Subsequent, we are going to use the starter toolkit to configure the AgentCore Runtime deployment. The toolkit can create the Amazon ECR repository on launch and generate a Dockerfile for deployment on AgentCore Runtime. You need to use your personal current MCP server, we’re utilizing the next solely for example. In a real-world setting, the inbound authorization in your MCP server will seemingly differ from the gateway configuration. Consult with this GitHub code instance to create an Amazon Cognito user pool for Runtime authorization.

from bedrock_agentcore_starter_toolkit import Runtime
from boto3.session import Session

boto_session = Session()
area = boto_session.region_name
print(f"Utilizing AWS area: {area}")

required_files = ['mcp_server.py', 'requirements.txt']
for file in required_files:
    if not os.path.exists(file):
        elevate FileNotFoundError(f"Required file {file} not discovered")
print("All required information discovered ✓")

agentcore_runtime = Runtime()

auth_config = {
    "customJWTAuthorizer": {
        "allowedClients": [
            '<runtime_cognito_client_id>' # Client MUST match with the ClientId configured in Cognito, and can be separate from the Gateway Cognito provider.
        ],
        "discoveryUrl": '<cognito_oauth_discovery_url>',
    }
}

print("Configuring AgentCore Runtime...")
response = agentcore_runtime.configure(
    entrypoint="mcp_server.py",
    auto_create_execution_role=True,
    auto_create_ecr=True,
    requirements_file="necessities.txt",
    area=area,
    authorizer_configuration=auth_config,
    protocol="MCP",
    agent_name="mcp_server_agentcore"
)
print("Configuration accomplished ✓")

# Values with < > must be changed with actual values

Launch MCP server to AgentCore Runtime

Now that we’ve the Dockerfile, let’s launch the MCP server to AgentCore Runtime:

print("Launching MCP server to AgentCore Runtime...")
print("This will likely take a number of minutes...")
launch_result = agentcore_runtime.launch()
agent_arn = launch_result.agent_arn
agent_id = launch_result.agent_id
print("Launch accomplished ✓")

encoded_arn = agent_arn.change(':', '%3A').change('/', '%2F')
mcp_url = f"https://bedrock-agentcore.{area}.amazonaws.com/runtimes/{encoded_arn}/invocations?qualifier=DEFAULT"

print(f"Agent ARN: {launch_result.agent_arn}")
print(f"Agent ID: {launch_result.agent_id}")

Create MCP server as goal for AgentCore Gateway

Create an AgentCore Identification Useful resource Credential Supplier for the AgentCore Gateway to make use of as outbound auth to the MCP server agent in AgentCore Runtime:

identity_client = boto3.consumer('bedrock-agentcore-control', region_name=area)

cognito_provider = identity_client.create_oauth2_credential_provider(
    identify="gateway-mcp-server-identity",
    credentialProviderVendor="CustomOauth2",
    oauth2ProviderConfigInput={
        'customOauth2ProviderConfig': {
            'oauthDiscovery': {
                'discoveryUrl': '<cognito_oauth_discovery_url>',
            },
            'clientId': '<runtime_cognito_client_id>', # Shopper MUST match with the ClientId configured in Cognito for the Runtime authorizer
            'clientSecret': '<cognito_client_secret>'
        }
    }
)
cognito_provider_arn = cognito_provider['credentialProviderArn']
print(cognito_provider_arn)

# Values with < > must be changed with actual values

Create a gateway goal pointing to the MCP server:

gateway_client = boto3.consumer("bedrock-agentcore-control", region_name=area)
create_gateway_target_response = gateway_client.create_gateway_target(
    identify="mcp-server-target",
    gatewayIdentifier=gatewayID,
    targetConfiguration={"mcp": {"mcpServer": {"endpoint": mcp_url}}},
    credentialProviderConfigurations=[
        {
            "credentialProviderType": "OAUTH",
            "credentialProvider": {
                "oauthCredentialProvider": {
                    "providerArn": cognito_provider_arn,
                    "scopes": ["<cognito_oauth_scopes>"],
                }
            },
        },
    ],
)  # Asynchronously create gateway goal
gatewayTargetID = create_gateway_target_response["targetId"]

# Values with < > must be changed with actual values

After making a gateway goal, implement a polling mechanism to examine for the gateway goal standing utilizing the get_gateway_target API name:

import time

def poll_for_status(interval=5):
    # Ballot for READY standing
    whereas True:
        gateway_target_response = gateway_client.get_gateway_target(gatewayIdentifier=gatewayID, targetId=gatewayTargetID)
        standing = gateway_target_response["status"]
        if standing == 'READY':
            break
        elif standing in ['FAILED', 'UPDATE_UNSUCCESSFUL', 'SYNCHRONIZE_UNSUCCESSFUL']:
            elevate Exception(f"Gateway goal failed with standing: {standing}")
        time.sleep(interval)

poll_for_status()

Take a look at Gateway with Strands Brokers framework

Let’s check the Gateway with the Strands Agents integration to listing the instruments from MCP server. You can even use different MCP-compatible brokers constructed with totally different agentic frameworks.

from strands import Agent
from mcp.consumer.streamable_http import streamablehttp_client
from strands.instruments.mcp.mcp_client import MCPClient

def create_streamable_http_transport():
    return streamablehttp_client(gatewayURL,headers={"Authorization": f"Bearer {token}"})

consumer = MCPClient(create_streamable_http_transport)

with consumer:
    # Name the listTools 
    instruments = consumer.list_tools_sync()
    # Create an Agent with the mannequin and instruments
    agent = Agent(mannequin=yourmodel,instruments=instruments) ## you possibly can change with any mannequin you want
    # Invoke the agent with the pattern immediate. This can solely invoke MCP listTools and retrieve the listing of instruments the LLM has entry to. The beneath doesn't really name any device.
    agent("Hello , are you able to listing all instruments out there to you")
    # Invoke the agent with pattern immediate, invoke the device and show the response
    agent("Get the Order id")

Refreshing device definitions of your MCP servers in AgentCore Gateway

The SynchronizeGatewayTargets API is a brand new asynchronous operation that permits on-demand synchronization of instruments from MCP server targets. MCP servers host instruments which brokers can uncover and invoke. With time, these instruments would possibly should be up to date, or new instruments could also be launched in an current MCP server goal. You’ll be able to join with exterior MCP servers by the SynchronizeGatewayTargets API that performs protocol handshakes and indexes out there instruments. This API supplies prospects with specific management over when to refresh their device definitions, significantly helpful after making modifications to their MCP server’s device configurations.

When a goal is configured with OAuth authentication, the API first interacts with the AgentCore Identification service to retrieve the required credentials from the desired credential supplier. These credentials are validated for freshness and availability earlier than communication with the MCP server begins. If the credential retrieval fails or returns expired tokens, the synchronization operation fails instantly with applicable error particulars, transitioning the goal to a FAILED state. For targets configured with out authentication, the API proceeds on to device synchronization.

The device processing workflow begins with an initialize name to the MCP server to determine a session. Following profitable initialization, the API makes paginated calls to the MCP server’s instruments/listing functionality, processing instruments in batches of 100 to optimize efficiency and useful resource utilization. Every batch of instruments undergoes normalization the place the API provides target-specific prefixes to assist stop naming collisions with instruments from different targets. Throughout processing, device definitions are normalized to facilitate consistency throughout totally different goal varieties, whereas preserving the important metadata from the unique MCP server definitions.

The synchronization move begins when:

1. An Ops Admin initiates the SynchronizeGatewayTargets API, triggering AgentCore Gateway to refresh the configured MCP goal.
2. The gateway obtains an OAuth token from AgentCore Identification for safe entry to the MCP goal.
3. The gateway then initializes a safe session with the MCP server to retrieve model capabilities.
4. Lastly, the gateway makes paginated calls to the MCP server instruments/listing endpoint to retrieve the device definitions, ensuring the gateway maintains a present and correct listing of instruments.

The SynchronizeGatewayTargets API addresses a essential problem in managing MCP targets inside AgentCore Gateway: sustaining an correct illustration of obtainable instruments whereas optimizing system efficiency and useful resource utilization. Right here’s why this specific synchronization method is effective:

Schema consistency administration: With out specific synchronization, AgentCore Gateway would wish to both make real-time calls to MCP servers throughout ListTools operations (impacting latency and reliability) or threat serving stale device definitions. The SynchronizeGatewayTargets API supplies a managed mechanism the place prospects can refresh their device schemas at strategic instances, resembling after deploying new instruments or updating current ones of their MCP server. This method makes certain that device definitions within the gateway precisely replicate the goal MCP server’s capabilities with out compromising efficiency.

• Efficiency impression trade-offs: The API implements optimistic locking throughout synchronization to assist stop concurrent modifications that might result in inconsistent states. Whereas this implies a number of synchronization requests would possibly have to retry if there’s competition, this trade-off is appropriate as a result of:
  • Device schema modifications are sometimes rare operational occasions somewhat than common runtime occurrences
  • The efficiency price of synchronization is incurred solely when explicitly requested, not throughout common device invocations
  • The cached device definitions facilitate constant excessive efficiency for ListTools operations between synchronizations

Invoke the synchronize gateway API

Use the next instance to invoke the synchronize gateway operation:

import requests
import json

def search_tools(gateway_url, access_token, question):
    headers = {
        "Content material-Sort": "utility/json",
        "Authorization": f"Bearer {access_token}"
    }

    payload = {
        "jsonrpc": "2.0",
        "id": "search-tools-request",
        "technique": "instruments/name",
        "params": {
            "identify": "x_amz_bedrock_agentcore_search",
            "arguments": {
                "question": question
            }
        }
    }

    response = requests.put up(gateway_url, headers=headers, json=payload, timeout=5)
    response.raise_for_status()
    return response.json()

# Instance utilization
token_response = utils.get_token(user_pool_id, client_id, client_secret, scopeString, REGION)
access_token = token_response['access_token']
outcomes = search_tools(gatewayURL, access_token, "order operations")
print(json.dumps(outcomes, indent=2))

Implicit synchronization of instruments schema

Throughout CreateGatewayTarget and UpdateGatewayTarget operations, AgentCore Gateway performs an implicit synchronization that differs from the express SynchronizeGatewayTargets API. This implicit synchronization makes certain that MCP targets are created or up to date with legitimate, present device definitions, aligning with the peace of mind from AgentCore Gateway that targets in READY state are instantly usable. Whereas this would possibly make create/replace operations take longer than with different goal varieties, it helps stop the complexity and potential points of getting targets with out validated device definitions.

The implicit synchronization move begins when:

1. An Ops Admin creates or updates the MCP goal utilizing CreateGatewayTarget or UpdateGatewayTarget operations.
2. AgentCore Gateway configures the brand new or up to date MCP goal.
3. The gateway asynchronously triggers the synchronization course of to replace the device definitions.
4. The gateway obtains an OAuth token from AgentCore Identification for safe entry.
5. The gateway then initializes a safe session with the MCP server to retrieve model capabilities.
6. Lastly, the gateway makes paginated calls to the MCP server’s instruments/listing endpoint to retrieve the device definitions, ensuring the gateway maintains a present and correct listing of instruments.

ListTools habits for MCP targets

The ListTools operation in AgentCore Gateway supplies entry to device definitions beforehand synchronized from MCP targets, following a cache-first method that prioritizes efficiency and reliability. In contrast to conventional OpenAPI or Lambda targets the place device definitions are statically outlined, MCP goal instruments are found and cached by synchronization operations. When a consumer calls ListTools, the gateway retrieves device definitions from its persistent storage somewhat than making real-time calls to the MCP server. These definitions have been beforehand populated both by implicit synchronization throughout goal creation/replace or by specific SynchronizeGatewayTargets API calls. The operation returns a paginated listing of normalized device definitions.

InvokeTool (instruments/name) Conduct for MCP Targets

The InvokeTool operation for MCP targets handles the precise execution of instruments found by ListTools, managing real-time communication with the goal MCP server. In contrast to the cache-based ListTools operation, instruments/name requires energetic communication with the MCP server, introducing particular authentication, session administration, and error dealing with necessities. When a instruments/name request arrives, AgentCore Gateway first validates the device exists in its synchronized definitions. For MCP targets, AgentCore Gateway performs an preliminary initialize name to determine a session with the MCP server. If the goal is configured with OAuth credentials, AgentCore Gateway retrieves recent credentials from AgentCore Identification earlier than making the initialize name. This makes certain that even when ListTools returned cached instruments with expired credentials, the precise invocation makes use of legitimate authentication.

The inbound authorization move begins when:

1. The MCP consumer initializes a request with MCP protocol model to AgentCore Gateway.
2. The consumer then sends the instruments/name request to the gateway.
3. The gateway obtains an OAuth token from AgentCore Identification for safe entry.
4. The gateway initializes a safe session with the MCP server to invoke and deal with the precise execution of the device.

Search device habits for MCP targets

The search functionality in AgentCore Gateway permits semantic discovery of instruments throughout the totally different goal varieties, together with MCP targets. For MCP targets, the search performance operates on normalized device definitions that have been captured and listed throughout synchronization operations, offering environment friendly semantic search with out real-time MCP server communication.

When device definitions are synchronized from an MCP goal, AgentCore Gateway mechanically generates embeddings for every device’s identify, description, and parameter descriptions. These embeddings are saved alongside the normalized device definitions, enabling semantic search that understands the intent and context of search queries. In contrast to conventional key phrase matching, this enables brokers to find related instruments even when precise terminology doesn’t match.

Seek for MCP server instruments by the gateway

Use the next instance to seek for instruments by the gateway.

import requests
import json

def search_tools(gateway_url, access_token, question):
    headers = {
        "Content material-Sort": "utility/json",
        "Authorization": f"Bearer {access_token}"
    }

    payload = {
        "jsonrpc": "2.0",
        "id": "search-tools-request",
        "technique": "instruments/name",
        "params": {
            "identify": "x_amz_bedrock_agentcore_search",
            "arguments": {
                "question": question
            }
        }
    }

    response = requests.put up(gateway_url, headers=headers, json=payload, timeout=5)
    response.raise_for_status()
    return response.json()

# Instance utilization
token_response = utils.get_token(user_pool_id, client_id, client_secret, scopeString, REGION)
access_token = token_response['access_token']
outcomes = search_tools(gatewayURL, access_token, "math operations")
print(json.dumps(outcomes, indent=2))

Conclusion

At the moment’s announcement of MCP server help as a goal kind in Amazon Bedrock AgentCore Gateway is an development in enterprise AI agent growth. This new functionality addresses essential challenges in scaling MCP server implementations whereas sustaining safety and operational effectivity. By integrating current MCP servers alongside REST APIs and Lambda capabilities, AgentCore Gateway supplies a extra unified, safe, and manageable answer for device integration at scale. Organizations can now handle their instruments by a single, centralized interface whereas benefiting from unified authentication, simplified device discovery and decreased upkeep overhead.

For extra detailed info and superior configurations, consult with the code samples on GitHub, the Amazon Bedrock AgentCore Gateway Developer Information and Amazon AgentCore Gateway pricing.

In regards to the authors

Frank Dallezotte is a Senior Options Architect at AWS and is obsessed with working with unbiased software program distributors to design and construct scalable functions on AWS. He has expertise creating software program, implementing construct pipelines, and deploying these options within the cloud.

Ganesh Thiyagarajan is a Senior Options Architect at Amazon Internet Providers (AWS) with over 20 years of expertise in software program structure, IT consulting, and answer supply. He helps ISVs remodel and modernize their functions on AWS. He’s additionally a part of the AI/ML Technical discipline group, serving to prospects construct and scale Gen AI options.

Dhawal Patel is a Principal Generative AI Tech lead at Amazon Internet Providers (AWS). He has labored with organizations starting from massive enterprises to mid-sized startups on issues associated to Agentic AI, Deep studying, distributed computing.