AWS MCP Gateway (AgentCore) connects Bedrock agents to AWS services via MCP. Learn the architecture, service quotas, fixed limits, and when self-managed alternatives fit better.
A user on AWS re:Post split a large OpenAPI spec across roughly 50 targets in Bedrock AgentCore Gateway. The result: a silent "Creation failed" error with no diagnostic detail explaining what went wrong. That failure pattern is a useful lens for understanding the AWS MCP Gateway as a whole: a managed service that solves the agent-to-tool wiring problem cleanly inside AWS, but whose service quotas and fixed architectural constraints create specific walls that teams need to map before building on it.
This article covers what AgentCore Gateway is, how requests flow through it, the exact service limits that matter in production, and when a self-managed or provider-agnostic gateway fits better.
AWS MCP Gateway is Amazon's managed implementation of the open-source Model Context Protocol specification developed by Anthropic. It serves as a bridge between Amazon Bedrock language models and AWS services like S3, DynamoDB, RDS, CloudWatch, and Bedrock Knowledge Bases.
The protocol defines three primitives:
If you are unfamiliar with the broader category, our explainer on what an AI gateway is covers the fundamentals. AWS MCP Gateway is a specific, AWS-scoped instance of that pattern, natively integrated with Amazon Bedrock's Converse API.
The gateway implements a client-server architecture. An AI application (the MCP client, typically embedded in Amazon Bedrock) sends a toolUse message when a model decides it needs external data. The gateway routes that call to the appropriate MCP server, which executes the action against the target AWS service and returns the result.
Target types include Lambda functions, OpenAPI-described endpoints, Smithy models, standalone MCP servers, and API Gateway endpoints. Each target gets its own tool definitions, and the gateway handles the translation between the model's tool call and the target's interface.
The three-component model (client, gateway, server) centralizes authentication and discovery. Instead of each agent managing its own credentials for every service, the gateway brokers access through IAM. For teams already deep in AWS, this removes a real category of wiring work.
Every managed service has quotas. AgentCore Gateway's are worth studying because several of them are fixed, meaning no support ticket will raise them.
| Limit | Default | Adjustable? |
|---|---|---|
| Targets per gateway | 100 | Yes |
| Tools per target | 1,000 | Yes |
| Inline schema size | 1 MB | Yes |
| S3 schema payload size | 10 MB | Yes |
| Tool name length | 256 characters | Yes |
| Request timeout | 15 minutes | No (fixed) |
| WebSocket frame size | 32 KB | No (fixed) |
| Concurrent tool-call connections | 1,000 | Yes |
| Max payload size | 100 MB | No (fixed) |
The adjustable limits are manageable. The fixed ones define the architecture's ceiling.
A 32 KB WebSocket frame cap means large tool responses must be chunked or stored externally and referenced by pointer. A fixed 15-minute request timeout rules out long-running operations unless you redesign them as asynchronous workflows. These are not bugs. They are design constraints of a managed service optimized for a specific request profile.
The re:Post case mentioned above is instructive. The user had a 1.2 MB raw OpenAPI spec and split it into approximately 50 targets. The creation failed silently.
The likely culprit, as the AWS community response explained: the 1 MB inline schema limit. But 1.2 MB was the raw spec size. The MCP tool definition generated from an OpenAPI spec is typically larger than the raw spec because each tool gets its own full JSON schema with expanded parameters and no $ref references. A 1.2 MB OpenAPI spec can easily expand well beyond that once every tool definition is self-contained.
The workarounds are predictable:
What made debugging hard was the absence of diagnostic detail. "Creation failed" with no specifics about which limit was hit. Teams operating near any of these limits need to instrument their own size checks before deployment, because the gateway will not tell them which wall they hit.
Service limits are concrete. The broader architectural constraints are subtler but equally important for the build-or-buy decision.
Vendor lock-in. AWS MCP Gateway tightly couples AI infrastructure to Amazon services. Teams running multi-cloud strategies, or those who want the option to move, inherit a migration cost proportional to how deeply they integrate. Every target, every IAM policy, every CloudWatch integration is AWS-specific.
No multi-provider routing. The gateway lacks advanced routing strategies and extensive multi-provider support. If your agents need to call tools hosted outside AWS, or route across multiple LLM providers, AgentCore does not cover that. For context on why multi-provider routing matters for MCP security and resilience, the protocol's trust model assumes a gateway that can enforce policy regardless of where the tool lives.
Cost unpredictability. AWS pricing for AI workloads involves multi-dimensional pricing across gateway services, API requests, and premium features. Teams report difficulty forecasting costs before they hit production volumes.
Standard API gateways are not substitutes. AWS API Gateway handles HTTP traffic. It does not handle MCP. A dedicated MCP gateway provides tool abstraction, agent-specific security, and real-time observability that traditional API gateways were never designed for.
The alternative to a managed MCP gateway is running your own. The question is what "your own" actually requires.
An MCP gateway sits between agents and tools as a control plane that enforces authentication, authorization, and policy for every tool call. Without one, every agent handles its own credentials, its own policies, and its own failure modes for every tool. That is the N-by-M integration problem, and it scales poorly.
Obot is one open-source option. It is purpose-built for MCP governance, can run self-hosted on Kubernetes or Docker or as a managed service, and includes a built-in catalog, composite server support, and multi-role RBAC out of the box. For teams that need to stay cloud-agnostic, that combination is hard to match with AgentCore.
The DIY option looks simpler than it is. Building your own MCP gateway looks straightforward until you get to per-user OAuth token lifecycles, rug-pull detection, catalog governance, and policy-as-code. Those are the capabilities that separate a weekend prototype from an enterprise-grade control plane. Rug-pull detection alone (where an MCP server changes its tool definitions after approval to execute different actions) requires continuous monitoring infrastructure that most teams underestimate.
What enterprise-ready MCP gateways provide, regardless of vendor: centralized identity, multi-role RBAC, a curated server catalog, per-user OAuth passthrough, policy-as-code, and MCP-specific threat handling including protection against tool poisoning and cross-server shadowing.
The decision framework maps to three variables: cloud commitment, provider diversity, and governance requirements.
AgentCore Gateway fits when:
Look elsewhere when:
The evaluation criteria that matter most: deployment model (managed vs. self-hosted vs. hybrid), openness (open-source vs. proprietary), catalog and discovery capabilities, and identity and policy enforcement. AWS Bedrock AgentCore Gateway is recommended only for teams committed to AWS, with its scope limited to the AWS boundary. For everyone else, the managed-service convenience does not offset the architectural constraints.
Map the limits table against your actual workloads. If your largest OpenAPI spec is 200 KB and your longest tool call completes in under a minute, AgentCore's fixed limits will never matter. If you are stitching together dozens of large specs across providers, those walls are closer than they appear.