Remodel 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 lot of specialised Mannequin 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 technique to effectively mix these current MCP servers–whether or not custom-built, publicly accessible, 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 totally managed service that serves as a centralized MCP software server, offering a unified interface the place brokers can uncover, entry, and invoke instruments. Right now, we’re extending assist 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 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 capabilities.

With out a 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 advanced, and sustaining separate gateway situations 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 means of a real-world instance of an e-commerce ordering system, the place completely different groups keep specialised MCP servers for his or her particular domains. Take into account an enterprise e-commerce system the place completely different groups have developed specialised MCP servers:

The Buying Cart crew maintains an MCP server with cart administration instruments
The Product Catalog crew runs their MCP server for product shopping 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 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 ability 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 characteristic boundaries: Every product crew 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: Totally 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 means of AgentCore Gateway. The agent connects to the gateway and discovers the accessible 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 various agent implementations with a big 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 immediately 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 will be Lambda capabilities, 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 assist, the gateway can immediately incorporate instruments from public MCP servers, treating them as first-class residents alongside different goal sorts. 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 situations 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 offers extra operational advantages. The gateway decouples its inbound authentication from goal programs, letting brokers entry instruments that use a number of id 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 id supplier for the goal.

With this authentication basis you get refined software administration capabilities by means 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 capabilities and conventional APIs. The semantic search functionality operates uniformly throughout the software sorts, so brokers can uncover related instruments no matter their implementation. Throughout software invocation, the gateway handles the required protocol translations, authentication flows, and knowledge 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 assist represents a major evolution within the gateway’s capabilities. Organizations can now immediately 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 software definitions stay present throughout the completely different goal sorts, whereas its authentication and authorization programs present constant safety controls whatever the underlying software implementation.

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

Resolution 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 will let you centralize your software administration, safety authentication, and operational finest 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’ve got 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 display easy methods to arrange and use Amazon Bedrock AgentCore Gateway. For an interactive walkthrough, you should utilize these Jupyter Pocket book 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 may also 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 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 Consumer Pool we reference in auth_config
def deploy_gateway(poll_interval=5):
    create_response = gateway_client.create_gateway(
        identify="DemoGateway",
        roleArn="", # The IAM Function 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"]
    
    # Watch for 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 current order"""
    return 456

@mcp.software()
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 should utilize your personal current MCP server, we’re utilizing the next solely for instance. In a real-world surroundings, the inbound authorization to your MCP server will seemingly differ from the gateway configuration. Check 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 recordsdata 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 got 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 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': '',
            },
            '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(
    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 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']:
            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. You may also 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 possibly can 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 really name any software.
    agent("Hello , are you able to checklist all instruments accessible 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 have to 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 accessible 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 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 acceptable 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 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, software definitions are normalized to facilitate consistency throughout completely different goal sorts, whereas preserving the important metadata from the unique MCP server definitions.

The synchronization stream begins when:

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

The SynchronizeGatewayTargets API addresses a essential 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 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 threat serving stale software definitions. The SynchronizeGatewayTargets API offers a managed mechanism the place prospects can refresh their software schemas at strategic instances, akin to after deploying new instruments or updating current ones of their MCP server. This method makes certain that software 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 might result in inconsistent states. Whereas this implies a number of synchronization requests may have to retry if there’s competition, this trade-off is appropriate as a result of:
- Software schema modifications are sometimes rare operational occasions slightly than common runtime occurrences
- The efficiency value 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",
        "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 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 sorts, it helps stop the complexity and potential points of getting targets with out validated software definitions.

The implicit synchronization stream begins when:

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

ListTools habits for MCP targets

The ListTools operation in AgentCore Gateway offers entry to software 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 software definitions are statically outlined, MCP goal instruments are found and cached by means of synchronization operations. When a consumer calls ListTools, the gateway retrieves software definitions from its persistent storage slightly than making real-time calls to the MCP server. These definitions had 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 software 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. In contrast to 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 software 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 stream begins when:

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

Search software habits for MCP targets

The search functionality in AgentCore Gateway allows semantic discovery of instruments throughout the completely different goal sorts, together with MCP targets. For MCP targets, the search performance operates on normalized software definitions that had 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 robotically generates embeddings for every software’s identify, 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. 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 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-Sort": "software/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

Right now’s announcement of MCP server assist 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 offers a extra unified, safe, and manageable resolution for software integration at scale. Organizations can now handle their instruments by means of a single, centralized interface whereas benefiting from unified authentication, simplified software discovery and decreased upkeep overhead.

For extra detailed data and superior configurations, confer 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 obsessed with working with impartial 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 resolution supply. He helps ISVs rework and modernize their functions on AWS. He’s additionally a part of the AI/ML Technical area 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 giant enterprises to mid-sized startups on issues associated to Agentic AI, Deep studying, distributed computing.