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 tons 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 present MCP servers or open supply MCP servers for his or her AI workflows. There’s a want for a technique to effectively mix these present MCP servers–whether or not custom-built, publicly out there, or open supply–right into a unified interface that AI brokers can readily eat 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 software server, offering a unified interface the place brokers can uncover, entry, and invoke instruments. At present, we’re extending help for present MCP servers as a brand new goal kind 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 software 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 rapidly 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 gear 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. Think about 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 looking and search
• The Promotions crew 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 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 method lies in its organizational flexibility. Groups can group their MCP servers based mostly on a number of logical standards:

• Enterprise unit alignment: Set up the MCP servers by enterprise unit
• Product function 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 out there 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 gives 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 gear 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 software definitions.

The goal integration facet 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 sorts. This functionality extends to federation situations the place one AgentCore Gateway occasion can function a goal for one more, for hierarchical software group throughout organizational boundaries. The gateway can seamlessly combine with AgentCore Runtime cases that expose brokers as instruments, non-public MCP servers maintained by prospects, conventional AWS Lambda capabilities, and each Smithy and AWS service APIs.

Past goal range, the gateway’s authentication structure gives further operational advantages. The gateway decouples its inbound authentication from goal methods, 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 subtle software administration capabilities by means of a unified structure. When an agent requests software discovery, the gateway gives 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 information transformations, presenting a clear, constant interface to brokers whereas managing the complexity of various goal methods behind the scenes.

The addition of MCP server goal help 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 present 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 methods present constant safety controls whatever the underlying software implementation.

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

Answer 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 kind goal to a brand new or present MCP Gateway. Including an MCP server to an AgentCore Gateway will can help 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 have got the next conditions:

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 tips on how to 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 provider 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 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(
        title="DemoGateway",
        roleArn="<IAM Function>", # 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"]
    
    # 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 example, 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 need to use your individual present MCP server, we’re utilizing the next solely for instance. In a real-world atmosphere, the inbound authorization on your MCP server will seemingly differ from the gateway configuration. Seek advice from 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):
        increase 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 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.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 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': '<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(
    title="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']:
            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 Agents integration to checklist the instruments from MCP server. You can even 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 may change with any mannequin you want
    # Invoke the agent with the pattern immediate. It will solely invoke MCP listTools and retrieve the checklist of instruments the LLM has entry to. The beneath doesn't truly name any software.
    agent("Hello , are you able to checklist all instruments out there 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 would possibly should 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 means of the SynchronizeGatewayTargets API that performs protocol handshakes and indexes out there instruments. This API gives prospects with express management over when to refresh their software definitions, significantly helpful after making adjustments 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 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 forestall 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 circulation 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 software 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 obtainable 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 want 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 gives 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 method makes certain that software definitions within the gateway precisely mirror the goal MCP server’s capabilities with out compromising efficiency.

• Efficiency impression 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 would possibly have to retry if there’s rivalry, this trade-off is appropriate as a result of:
  • Software schema adjustments are sometimes rare operational occasions slightly 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",
        "technique": "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 express 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 would possibly make create/replace operations take longer than with different goal sorts, it helps forestall the complexity and potential points of getting targets with out validated software definitions.

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

ListTools conduct for MCP targets

The ListTools operation in AgentCore Gateway gives 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 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 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 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 circulation 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 permits 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 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 mechanically 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. In contrast to conventional key phrase matching, this permits 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": {
            "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

At present’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 important challenges in scaling MCP server implementations whereas sustaining safety and operational effectivity. By integrating present MCP servers alongside REST APIs and Lambda capabilities, AgentCore Gateway gives a extra unified, safe, and manageable answer 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 lowered upkeep overhead.

For extra detailed data and superior configurations, seek advice from the code samples on GitHub, the Amazon Bedrock AgentCore Gateway Developer Guide 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 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 Net Companies (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 neighborhood, serving to prospects 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.