AgentCore Gateway vs a self-hosted MCP server: how to choose | Agentic ERP Quickstart
A managed tool gateway removed per-adapter runtime ownership, and one identity path still skips it on purpose. The trade-off, and the signals that reverse it.
Series: Building Production-Grade ERP Agents on AWS (18 articles)
- …
- 17AgentCore Gateway vs a self-hosted MCP server: how to choose | Agentic ERP Quickstart This article
AgentCore Gateway vs a self-hosted MCP server: how to choose | Agentic ERP Quickstart
Every agent project reaches the same fork: put all your tools behind one MCP server you own and operate, or register them as targets on a managed gateway. Hosting your own gives you full protocol control and shared in-process state, and it also makes you responsible for authentication, scaling, and deployment for every adapter you will ever add, in one runtime. This project took the gateway, and the more interesting part is the exception: one identity path deliberately bypasses it, and a diagram that hides that fact will walk a security reviewer straight into the wrong conclusion about which control protects what.
Series: Building governed ERP agents on AWS · Series guide →
This post: How the project gives the agent one consistent way to reach its tools, and the one identity path that deliberately sits outside it.
Prereq: None. The auth profile overview covers the identity paths named here, if you want that background first.
New to this series? Start here
The Agentic ERP Automation Quickstart is an open source reference implementation that deploys an AI agent for work your team does by hand from a written procedure, on Amazon Bedrock AgentCore. Accounts payable is the worked example, where a case looks like an invoice that does not match its purchase order. A new process type is a skill directory and your own SOPs. Six terms recur below:
- MCP is the Model Context Protocol, the standard the agent uses to call tools. An MCP server implements tools an agent can call.
- AgentCore Gateway is the component that connects the agent to its tools. A target is one tool source registered with it.
- An adapter is the code behind a tool: the thing that actually talks to a system.
- The AWS for SAP MCP Server, also called the SAP MCP Runtime, is a separate AWS-provided runtime that gives the agent its SAP tools. You deploy it yourself.
- On-behalf-of, often written OBO, is a token exchange that lets SAP see the individual signed-in person instead of a shared technical account.
- Topology means the shape of the deployed path to SAP. This project has more than one.
The problem: tool domains multiply
An agent accumulates tool domains fast. Case state. Notifications. Knowledge retrieval. Deterministic calculations. SAP operations.
One reasonable answer is to put every domain behind a single project-owned MCP server. That fits well when you need shared in-process state, the full MCP surface, or a tightly coupled local development loop.
It also makes your project responsible for protocol behavior, authentication, request handling, scaling, observability, and deployment for every adapter, in one runtime.
Where a single server strains
A self-hosted server is not wrong. It gives you full control over protocol behavior, shared in-process state, and direct local debugging. Those are genuine advantages.
The strain shows up when unrelated tool domains want different operational boundaries. A notification handler and a SAP adapter do not need the same dependencies, the same scale profile, the same credentials, or the same owner. Putting them in one server turns each adapter decision into a shared-runtime commitment.
The decision: Gateway as the boundary
The project's first design decision record chose AgentCore Gateway as the project-owned tool boundary. In the reference implementation:
| Tool domain | How it is reached |
|---|---|
| The project's own discrete tools | AWS Lambda targets on Gateway |
| SAP functionality | An MCP target on Gateway, pointing at the externally operated AWS for SAP MCP Runtime |
The point of the boundary is that the agent gets one consistent way to reach its configured tools, without every implementation having to be a Lambda function. Behind the boundary, the adapter can be a Lambda-backed target or an MCP server target, depending on who owns it and how it needs to run.
Who owns what
For the Service and User target profiles, the split is:
| This repository owns | The external AWS stack owns |
|---|---|
| The Gateway target | The SAP MCP Runtime itself |
| The OAuth credential-provider wiring Gateway needs to call the external runtime | Its inbound Amazon Cognito or Microsoft Entra identity configuration |
| The SAP OAuth provider | |
| SAP read and write controls |
IMPORTANT
This split does not eliminate integration work. Someone still has to keep the selected auth profile, the target type, the external invocation URL, and the credential-provider configuration all in agreement. When those drift, the failure looks like a tool problem rather than a configuration problem.
The deliberate exception
The direct
ON_BEHALF_OF_TOKEN_EXCHANGE path works differently, and this is the part people draw wrong.In that topology the application publishes the external invocation URL, and the agent runtime calls the external MCP Runtime directly with the signed-in user's Entra token. No Gateway target is created for that path.
WARNING
Any policy or audit claim about Gateway has to name the topology and the deployed enforcement configuration. None of those claims carry over to direct on-behalf-of, because Gateway is not in that request path. The Cedar policy post covers the conditions under which policy enforcement applies.
What this choice does not buy
Three boundaries worth stating plainly:
- Gateway is not a universal SAP front door. It fronts the targets you configured, in the topologies that create them.
- Gateway does not replace MCP. The external SAP runtime is still an MCP server. This architecture uses Gateway and MCP together.
- Discovery mode is not a capability guarantee. Tool discovery is configurable: a pre-synchronized catalog can support semantic discovery, and a dynamic listing path can defer tool listing until invocation. Neither mode establishes that every MCP capability or server behavior is identical across target types.
Trade-offs
- What you give up. A single in-process server. Lambda targets have isolated execution and no shared process state, and Gateway does not expose every MCP feature the way a self-hosted server would.
- What you keep. Integration responsibility. The repository and the external SAP stack have separate configuration and ownership boundaries, and operators have to validate them together.
- What changes by topology. Direct on-behalf-of is a purposeful exception that changes which boundary governs the SAP call.
Keep the exception visible
Choose a stable agent-facing boundary when it lets independent tool domains evolve without collapsing into one project-owned runtime. Keep the implementation behind that boundary flexible. Then show the exceptions in the design rather than smoothing them out of the diagram.
Gateway can front an adapter. It does not take on the runtime, identity, permission, or SAP-system responsibilities that sit behind it.
Where to go next
- How an agent authenticates to SAP . The setting that decides which topology, and therefore which boundary, you get.
- Cedar policy for AI agents . When a policy on a covered target can actually block a request.
- S3 Vectors vs OpenSearch Serverless. Another cost and capability trade-off recorded as a design decision.
Series: Building Production-Grade ERP Agents on AWS (18 articles)
- …
- 17AgentCore Gateway vs a self-hosted MCP server: how to choose | Agentic ERP Quickstart This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article