Remodel your MCP structure: Unite MCP servers by way 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 features or groups. Organizations additionally must combine their very own present MCP servers or open supply MCP servers for his or her AI workflows. There’s a want for a approach to effectively mix these present 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 yr, we launched Amazon Bedrock AgentCore Gateway, a completely managed service that serves as a centralized MCP software server, offering a unified interface the place brokers can uncover, entry, and invoke instruments. Immediately, we’re extending help for present MCP servers as a brand new goal sort in AgentCore Gateway. With this functionality, you’ll be able to 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 software and authentication administration that existed for REST APIs and AWS Lambda features.

And not using a centralized strategy, 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 advanced, and sustaining separate gateway cases for every server shortly turns into unmanageable. Amazon Bedrock AgentCore Gateway helps solves these challenges by treating present 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 way of a real-world instance of an e-commerce ordering system, the place completely different groups preserve specialised MCP servers for his or her particular domains. Think about an enterprise e-commerce system the place completely different groups have developed specialised MCP servers:

• The Purchasing Cart crew maintains an MCP server with cart administration instruments
• The Product Catalog crew runs their MCP server for product looking 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 beneath a single gateway whereas sustaining their team-specific possession and entry controls. The facility of this strategy lies in its organizational flexibility. Groups can group their MCP servers primarily based on a number of logical standards:

• Enterprise unit alignment: Set up the MCP servers by enterprise unit
• Product characteristic 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 completely different authentication mechanisms. The gateway handles the authentication complexity, making it easy for licensed brokers to entry the instruments they want

The next diagram illustrates how an ordering agent interacts with a number of MCP servers by way of AgentCore Gateway. The agent connects to the gateway and discovers the obtainable instruments. Every crew maintains management over their domain-specific instruments whereas contributing to a cohesive agent expertise. The gateway handles software naming collisions, authentication, and offers 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 wide selection of software 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 flexibility to straight combine MCP server targets.

AgentCore Gateway integration structure

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

The goal integration aspect of the structure showcases the gateway’s versatility in software 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 an additional, for hierarchical software 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 features, and each Smithy and AWS service APIs.

Past goal range, the gateway’s authentication structure offers extra operational advantages. The gateway decouples its inbound authentication from goal programs, letting brokers entry instruments that use a number of identification suppliers by way of a single interface. This centralized strategy simplifies growth, deployment, and upkeep of AI brokers. Now, the identical strategy 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 software administration capabilities by way of a unified structure. When an agent requests software discovery, the gateway offers a constant view throughout the built-in targets, with instruments from MCP servers showing alongside Lambda features and conventional APIs. The semantic search functionality operates uniformly throughout the software varieties, so brokers can uncover related instruments no matter their implementation. Throughout software 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 programs 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 features. 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 present integrations. The gateway’s synchronization mechanisms guarantee that software definitions stay present throughout the completely different goal varieties, whereas its authentication and authorization programs present constant safety controls whatever the underlying software implementation.

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

Resolution Walkthrough

On this publish, 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 present MCP Gateway. Including an MCP server to an AgentCore Gateway will let you centralize your software 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 conditions:

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

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

Create a gateway

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

import time
import boto3

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

# Create an authorization configuration, that specifies what consumer 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 could 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(
        title="DemoGateway",
        roleArn="", # The IAM Position 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"]
    
    # Anticipate 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.software()
def getOrder() -> int:
    """Get an order"""
    return 123

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

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

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

Configure AgentCore Runtime deployment

Subsequent, we’ll 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 should use your individual present MCP server, we’re utilizing the next solely for example. In a real-world setting, the inbound authorization to your MCP server will possible differ from the gateway configuration. Discuss 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 now have the Dockerfile, let’s launch the MCP server to AgentCore Runtime:

print("Launching MCP server to AgentCore Runtime...")
print("This will 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.consumer('bedrock-agentcore-control', region_name=area)

cognito_provider = identity_client.create_oauth2_credential_provider(
    title="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.consumer("bedrock-agentcore-control", region_name=area)
create_gateway_target_response = gateway_client.create_gateway_target(
    title="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 take a look at the Gateway with the Strands Brokers integration to listing the instruments from MCP server. You too can use different MCP-compatible brokers constructed with completely 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'll be able to exchange with any mannequin you want
    # Invoke the agent with the pattern immediate. This may solely invoke MCP listTools and retrieve the listing of instruments the LLM has entry to. The under doesn't truly name any software.
    agent("Hello , are you able to listing all instruments obtainable to you")
    # Invoke the agent with pattern immediate, invoke the software and show the response
    agent("Get the Order id")

Refreshing software definitions of your MCP servers in AgentCore Gateway

The SynchronizeGatewayTargets API is a brand new asynchronous operation that allows on-demand synchronization of instruments from MCP server targets. MCP servers host instruments which brokers can uncover and invoke. With time, these instruments may must be up to date, or new instruments could also be launched in an present MCP server goal. You’ll be able to join with exterior MCP servers by way of the SynchronizeGatewayTargets API that performs protocol handshakes and indexes obtainable instruments. This API offers prospects with express management over when to refresh their software definitions, notably helpful after making modifications to their MCP server’s software configurations.

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

The software processing workflow begins with an initialize name to the MCP server to ascertain 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 forestall naming collisions with instruments from different targets. Throughout processing, software definitions are normalized to facilitate consistency throughout completely 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 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/listing endpoint to retrieve the software definitions, ensuring the gateway maintains a present and correct listing 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 strategy is effective:

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

• Efficiency influence trade-offs: The API implements optimistic locking throughout synchronization to assist forestall concurrent modifications that might result in inconsistent states. Whereas this implies a number of synchronization requests may must retry if there’s rivalry, this trade-off is suitable as a result of:
  • Instrument 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 software invocations
  • The cached software 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": "software/json",
        "Authorization": f"Bearer {access_token}"
    }

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

    response = requests.publish(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 software definitions, aligning with the peace of mind from AgentCore Gateway that targets in READY state are instantly usable. Whereas this may make create/replace operations take longer than with different goal varieties, it helps forestall the complexity and potential points of getting targets with out validated software 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 software 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/listing endpoint to retrieve the software definitions, ensuring the gateway maintains a present and correct listing of instruments.

ListTools conduct for MCP targets

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

InvokeTool (instruments/name) Habits for MCP Targets

The InvokeTool operation for MCP targets handles the precise execution of instruments found by way of ListTools, managing real-time communication with the goal MCP server. Not like 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 software exists in its synchronized definitions. For MCP targets, AgentCore Gateway performs an preliminary initialize name to ascertain 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 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 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 software.

Search software conduct for MCP targets

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

When software definitions are synchronized from an MCP goal, AgentCore Gateway routinely generates embeddings for every software’s title, description, and parameter descriptions. These embeddings are saved alongside the normalized software 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 precise terminology doesn’t match.

Seek for MCP server instruments by way of the gateway

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

import requests
import json

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

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

    response = requests.publish(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

Immediately’s announcement of MCP server help 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 present MCP servers alongside REST APIs and Lambda features, AgentCore Gateway offers a extra unified, safe, and manageable answer for software integration at scale. Organizations can now handle their instruments by way of a single, centralized interface whereas benefiting from unified authentication, simplified software discovery and decreased upkeep overhead.

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

Concerning the authors

Frank Dallezotte is a Senior Options Architect at AWS and is enthusiastic about working with impartial software program distributors to design and construct scalable purposes 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 Companies (AWS) with over 20 years of expertise in software program structure, IT consulting, and answer supply. He helps ISVs remodel and modernize their purposes on AWS. He’s additionally a part of the AI/ML Technical discipline neighborhood, serving to prospects construct and scale Gen AI options.

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