Rework your MCP structure: Unite MCP servers by means of AgentCore Gateway

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

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

With out a centralized method, clients face important challenges: discovering and sharing instruments throughout organizations turns into fragmented, managing authentication throughout a number of MCP servers grows more and more advanced, and sustaining separate gateway cases for every server rapidly turns into unmanageable. Amazon Bedrock AgentCore Gateway helps solves these challenges by treating current MCP servers as native targets, giving clients 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 means of a real-world instance of an e-commerce ordering system, the place totally different groups keep specialised MCP servers for his or her particular domains. Take into account an enterprise e-commerce system the place totally different groups have developed specialised MCP servers:

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

Beforehand, an ordering agent would want 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 assist 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 based mostly on a number of logical standards:

• Enterprise unit alignment: Arrange the MCP servers by enterprise unit
• Product characteristic boundaries: Every product workforce owns their MCP server with domain-specific instruments permitting them to keep up 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 means of AgentCore Gateway. The agent connects to the gateway and discovers the obtainable instruments. Every workforce maintains management over their domain-specific instruments whereas contributing to a cohesive agent expertise. The gateway handles instrument 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 various agent implementations with a big selection of instrument 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 may be Lambda capabilities, OpenAPI specs, Smithy fashions, MCP servers, or different instrument definitions.

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

Past goal variety, the gateway’s authentication structure supplies further operational advantages. The gateway decouples its inbound authentication from goal techniques, letting brokers entry instruments that use a number of identification suppliers by means of 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 identification supplier for the goal.

With this authentication basis you get subtle instrument administration capabilities by means of a unified structure. When an agent requests instrument 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 instrument sorts, so brokers can uncover related instruments no matter their implementation. Throughout instrument invocation, the gateway handles the mandatory 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 assist represents a big 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 make it possible for instrument definitions stay present throughout the totally different goal sorts, whereas its authentication and authorization techniques present constant safety controls whatever the underlying instrument implementation.

The gateway combines MCP servers, conventional APIs, and serverless capabilities right into a coherent instrument atmosphere. This functionality, together with enterprise-grade safety and efficiency, makes it a helpful 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 sort goal to a brand new or current MCP Gateway. Including an MCP server to an AgentCore Gateway will will let you centralize your instrument 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 might have the next stipulations:

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

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

Create a gateway

To create a gateway, you should use the AgentCore starter toolkit to create a default authorization configuration with Amazon Cognito for JWT-based inbound authorization. It’s also possible to use one other OAuth 2.0-compliant authentication supplier as an alternative of Cognito.

import time
import boto3

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

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

# Name the create_gateway API
# This operation is asynchronous so might take time for Gateway creation
# This Gateway will leverage a CUSTOM_JWT authorizer, the Cognito Person Pool we reference in auth_config
def deploy_gateway(poll_interval=5):
    create_response = gateway_client.create_gateway(
        identify="DemoGateway",
        roleArn="", # The IAM Position should have permissions to create/checklist/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"]
    
    # Look ahead to 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.instrument()
def getOrder() -> int:
    """Get an order"""
    return 123

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

@mcp.instrument()
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 instance. In a real-world atmosphere, the inbound authorization to your MCP server will probably differ from the gateway configuration. Consult with this GitHub code instance to create an Amazon Cognito consumer 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):
        increase FileNotFoundError(f"Required file {file} not discovered")
print("All required information discovered ✓")

agentcore_runtime = Runtime()

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

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 may increasingly 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.exchange(':', '%3A').exchange('/', '%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 Id 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.shopper('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': '',
            },
            'clientId': '', # Shopper MUST match with the ClientId configured in Cognito for the Runtime authorizer
            'clientSecret': ''
        }
    }
)
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.shopper("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": [""],
                }
            },
        },
    ],
)  # 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 test 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']:
            increase Exception(f"Gateway goal failed with standing: {standing}")
        time.sleep(interval)

poll_for_status()

Check Gateway with Strands Brokers framework

Let’s check the Gateway with the Strands Brokers integration to checklist the instruments from MCP server. It’s also possible to use different MCP-compatible brokers constructed with totally different agentic frameworks.

from strands import Agent
from mcp.shopper.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}"})

shopper = MCPClient(create_streamable_http_transport)

with shopper:
    # Name the listTools 
    instruments = shopper.list_tools_sync()
    # Create an Agent with the mannequin and instruments
    agent = Agent(mannequin=yourmodel,instruments=instruments) ## you may exchange with any mannequin you want
    # Invoke the agent with the pattern immediate. This can solely invoke MCP listTools and retrieve the checklist of instruments the LLM has entry to. The beneath doesn't truly name any instrument.
    agent("Hello , are you able to checklist all instruments obtainable to you")
    # Invoke the agent with pattern immediate, invoke the instrument and show the response
    agent("Get the Order id")

Refreshing instrument 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 may 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 means of the SynchronizeGatewayTargets API that performs protocol handshakes and indexes obtainable instruments. This API supplies clients with express management over when to refresh their instrument definitions, significantly helpful after making modifications to their MCP server’s instrument configurations.

When a goal is configured with OAuth authentication, the API first interacts with the AgentCore Id service to retrieve the mandatory credentials from the required 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 acceptable error particulars, transitioning the goal to a FAILED state. For targets configured with out authentication, the API proceeds on to instrument synchronization.

The instrument 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/checklist 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, instrument definitions are normalized to facilitate consistency throughout totally different goal sorts, whereas preserving the important metadata from the unique MCP server definitions.

The synchronization movement 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 Id 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/checklist endpoint to retrieve the instrument definitions, ensuring the gateway maintains a present and correct checklist of instruments.

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

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

• Efficiency affect trade-offs: The API implements optimistic locking throughout synchronization to assist stop concurrent modifications that would result in inconsistent states. Whereas this implies a number of synchronization requests may must retry if there’s rivalry, this trade-off is appropriate as a result of:
  • Software schema modifications are sometimes rare operational occasions somewhat than common runtime occurrences
  • The efficiency value of synchronization is incurred solely when explicitly requested, not throughout common instrument invocations
  • The cached instrument 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-Kind": "utility/json",
        "Authorization": f"Bearer {access_token}"
    }

    payload = {
        "jsonrpc": "2.0",
        "id": "search-tools-request",
        "methodology": "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 specific SynchronizeGatewayTargets API. This implicit synchronization makes certain that MCP targets are created or up to date with legitimate, present instrument definitions, aligning with the reassurance from AgentCore Gateway that targets in READY state are instantly usable. Whereas this may make create/replace operations take longer than with different goal sorts, it helps stop the complexity and potential points of getting targets with out validated instrument definitions.

The implicit synchronization movement 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 instrument definitions.
4. The gateway obtains an OAuth token from AgentCore Id 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/checklist endpoint to retrieve the instrument definitions, ensuring the gateway maintains a present and correct checklist of instruments.

ListTools habits for MCP targets

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

InvokeTool (instruments/name) Habits for MCP Targets

The InvokeTool operation for MCP targets handles the precise execution of instruments found by means of ListTools, managing real-time communication with the goal MCP server. Not like the cache-based ListTools operation, instruments/name requires lively 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 instrument 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 contemporary credentials from AgentCore Id 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 movement begins when:

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

Search instrument habits for MCP targets

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

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

Seek for MCP server instruments by means of the gateway

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

import requests
import json

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

    payload = {
        "jsonrpc": "2.0",
        "id": "search-tools-request",
        "methodology": "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 assist as a goal sort in Amazon Bedrock AgentCore Gateway is an development in enterprise AI agent growth. This new functionality addresses important 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 instrument integration at scale. Organizations can now handle their instruments by means of a single, centralized interface whereas benefiting from unified authentication, simplified instrument discovery and diminished 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 Net Companies (AWS) with over 20 years of expertise in software program structure, IT consulting, and answer supply. He helps ISVs rework and modernize their functions on AWS. He’s additionally a part of the AI/ML Technical subject neighborhood, serving to clients construct and scale Gen AI options.

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