The demo that breaks the moment two people use it
A working MCP prototype tends to look the same everywhere. A server runs as a local subprocess, speaks JSON-RPC over stdin and stdout, and drives an agent that queries the production database and files a Jira ticket on the first attempt. It demos well. That's the trap, because almost nothing about that setup survives a second user.
The trouble arrives in a predictable order. The server ran as a subprocess on someone's laptop, so it inherited that person's credentials and network access, and there was no authentication between client and server because a single local process never needed any.1 Then two hundred people want it, each with different permissions. Security asks who can call the tool that writes to the database. Finance asks why one team's runaway agent made ten thousand API calls overnight. Compliance wants a log of which agent touched which customer record, and when. The demo has no answer to any of it, because it never had to.
MCP standardizes how an application discovers and calls external tools, and that's all it does. It's a connectivity standard, not a security or governance one, so it won't authenticate your users, authorize an action, isolate a tenant, or keep an audit trail for you.3 Those are the parts you build for production, and they're what this article is about. It follows the three concerns the AWS guidance uses to organize the work: tool design, server hosting, and governance.2 (For why MCP exists in the first place, the companion piece covers it.)
Key distinction
An MCP server proves an integration is possible. An MCP platform makes that integration safe to run for many users, across many tools, under audit. The distance between the two is the actual project.
What this article covers
- Why tool design is a performance decision, with concrete rules for naming, granularity, and size.
- How tool descriptions eat into the context window, and how to keep the surface small.
- Where identity, scoped tokens, and authorization belong once servers go remote and shared.
- What a gateway does, and when it's worth running one.
- Which failures have already happened in the wild, and a sane order to build in.
An MCP server is not an MCP platform
The gap between the two is made of the parts a demo gets to skip. A platform serves many tenants, so it needs identity and per-user authorization. It runs continuously, so it needs logging, tracing, and versioning. It's shared, so one team's mistake can't be allowed to starve everyone else, which is what rate limits and load shedding are for. The source material makes the same point from the other side: plenty of early servers were written for one user, so multi-tenancy and access control take real engineering, and agents that run for a while suffer context drift as their state goes stale.3
Design rule
Read the three concerns as a checklist. Tool design drives accuracy and cost. Hosting drives access control (local, remote, or gateway). Governance drives safety and audit: scoped tokens, rate limits, tool-selection metrics, versioning. A prototype can ignore two of them; a platform can't.
Figure 1. The demo skips every part that makes production hard: identity, per-user authorization, rate limits, and audit. The right-hand system isn't the left-hand one scaled up; it's a different design.
API-shaped tools versus workflow-shaped tools
Exposing a REST API one-to-one as MCP tools is the usual first mistake. The guidance names a tension that cuts both ways: too few tools and the model can't gather what it needs, too many and it loses track of which tool to pick and in what order, which surfaces as hallucinated calls.4 Map every endpoint to its own tool and you land on the "too many" side without trying.
Tools shaped around workflows do better, because they hand the model a result instead of a kit of parts. One orders_summarize_for_customer tool that does the joins and returns the answer removes four decisions the model would otherwise get wrong. The guidance points to peer-reviewed work: structured tool wrappers came out roughly three times more accurate on database tasks than direct API access, and following the tool-design recommendations moved task accuracy by 28 to 32 percent. Both figures are AWS summarizing external research rather than its own measurements, so read them as direction, not promises.5
Design rule
Scope tools to workflows, not endpoints. Name them so a sort groups related operations, domain-noun-verb style: github_issue_create, github_pullrequest_merge. Keep the parameter count near eight or below, write each description as if it were a prompt (purpose, when to use it, output, errors), and split a server once it crosses roughly fifty tools. Separate read and write servers when you want authorization to differ by side.4
Figure 2. Five chatty tools give the model five chances to choose wrong. One workflow-scoped tool gives it one. Fewer, better-scoped tools raise accuracy and cut latency.
Every tool description competes for context
Tool definitions aren't free. The model reads every registered tool's name, description, and schema on every call, and that text lands in the same context window your reasoning needs. The guidance puts numbers on it: a typical definition runs 250 to 500 tokens, so twenty tools burn five to ten thousand tokens before the model has even read the question.6
That cost compounds. The source material calls prompt bloat the main scaling bottleneck, since the more servers you connect, the more the descriptions crowd out reasoning and the worse tool selection gets.7 One large evaluation it cites, about twenty thousand API calls and over six thousand dollars in compute, found MCP integration adds heavy input-token overhead, and it defines a metric, Overhead, to track that alongside proactivity, tool correctness, and effectiveness.7 The tools that make an agent capable are the same ones running up its bill.
Load tools on demand, not all at once
If descriptions are the cost, stop paying for tools the model doesn't need this turn. The guidance lays out three approaches.6 Static definition ships a hand-picked set, cheap and predictable but brittle when needs shift. Dynamic discovery registers everything, flexible but growing context linearly with tool count, so it falls over past a few dozen. A search function is what scales: index every tool's description, then at query time pull back only the handful that match, the same move RAG makes for documents.
The payoff is measurable. RAG-MCP, which applies retrieval to tool selection, lifted tool-selection accuracy from 13.62 percent to 43.13 percent against a large tool pool while cutting average prompt tokens from about 2,134 to 1,084, roughly half.8 Managed gateways are starting to ship this: Amazon Bedrock AgentCore Gateway exposes a native semantic search over tools, so an agent can reach thousands of them without loading every description at once.6
Figure 3. Retrieve tools the way RAG retrieves documents. The catalog can hold thousands; the model only ever reads the few that match the task.
Local, remote, and gateway hosting
The guidance gives three places to run a server, and each one shifts what you're responsible for.9 The local server is the demo setup, fine for a coding assistant, but with no client-server auth and a copy per user that needs a registry to distribute. A remote server runs over HTTP, which is where central access control, authentication, and versioning become possible, and where multi-tenant identity becomes your new problem. A gateway sits in front of everything as one endpoint, handling authentication, authorization, routing, and protocol translation, so you can add servers or tools behind it without touching clients.
A gateway is not a requirement for every deployment. It earns its place as servers and tools go remote, shared, multi-user, or centrally governed, and before that it's overhead: for one team and one server, it's a box you pay to run for nothing. Once you have a dozen teams, a hundred tools, and an auditor who wants a single answer to "who can call what," it becomes the difference between policy you enforce and policy you only wrote down. AgentCore Gateway and Docker's MCP Gateway are two current takes on the pattern; the shape matters more than the brand.9
Figure 4. Once MCP is shared across teams, common concerns belong in one place instead of copied into every server. The gateway is where identity, authorization, and routing are enforced once for everyone behind it.
Authentication and authorization are separate problems
The most dangerous shortcut in the stack lives right here. Two access patterns are worth designing for up front: machine-to-machine, where no user is in the loop, and user-delegated, where a person authorizes the agent to act for them.9 The tempting move is to take the token the user signed in with and pass it straight through to every downstream system. Don't. User credentials shouldn't propagate through the agent chain; downstream calls should carry explicitly scoped, purpose-built tokens, one per tool, so none can borrow another's reach.9
Production warning
Never propagate the caller's token to downstream services. Mint scoped, purpose-built tokens per tool, check that the token's aud (audience) matches the service receiving it, and isolate tokens per server. AWS positions AgentCore Identity as the component that handles this token isolation for both machine-to-machine and user-delegated access.9
The guidance's worked example makes the stakes plain. An admin asks an agent to clone the production database, which needs read and create rights and nothing more. If the agent carries the admin's token and the model decides, wrongly, to drop a table, the call goes through, because the token allowed it. Give the agent a token scoped to read and create, and the same hallucinated delete fails harmlessly. Least privilege here isn't a compliance box to tick; it's what turns a model's mistake into a shrug. The protocol backs this directly. MCP added an OAuth 2.1 authorization framework for HTTP transports in March 2025, and the June 2025 revision made the server an OAuth resource server and required resource indicators (RFC 8707), so a token minted for one server can't be replayed against another.10
The failures are already in the wild
Runtime policy decides what's allowed right now, for this user, this data, this context. Written as policy-as-code and checked on every call, it lets you change the rules without redeploying servers. Some actions shouldn't run on the model's judgment at all, and the spec itself calls for human confirmation on tool calls with side effects.11 This isn't hypothetical caution; the source material catalogs incidents that already happened.12 CVE-2025-6514 was a command-injection flaw in the mcp-remote proxy, rated CVSS 9.6, that allowed remote code execution when a client connected to a malicious server. Indirect prompt injection, which the material also calls XPIA, plants instructions in outside content: ask an agent to "check open issues" and a booby-trapped issue can steer it into reaching private repositories. Tool poisoning hides instructions in a tool's own metadata, including rug-pull redefinitions that change a tool's behavior after you've approved it. The defenses are ordinary platform hygiene: sanitize inputs, sandbox servers, confirm side effects with a human, and audit a server before it reaches production.12
Figure 5. The path of one production call. Authentication and authorization are distinct gates; the policy decision either allows execution or routes to a human, who approves (execute) or denies (stop and return a denial). Audit logging is cross-cutting: it records successful calls, authorization failures, policy denials, human approvals and denials, and execution failures. A denied request never reaches execution.
What to monitor, rate-limit, and audit
Day-two operations need what the demo never produced. The guidance names the metrics that predict trouble: token usage, tool-selection accuracy, how many tools an agent has registered, and tool latency, with alarms on per-tool output-token thresholds to catch context-window overuse early.9 Guard shared capacity at two levels, coarse per-server limits so one tenant can't starve the rest and tighter per-tool limits pinned to the slowest downstream API, and return standard X-RateLimit headers and shed load when you're over budget. To catch regressions before users do, some AWS teams build golden datasets from historical API logs and test tool selection against them on every change.9
One benefit comes close to free. Because MCP routes every capability through a defined interface with named inputs and outputs, the traffic is auditable by construction, and you can say which agent touched which data, under what permission, and when. The source material calls this the auditability dividend, and it's exactly the record a regulated environment needs and a black-box model call never left behind.3
A phased path from laptop to platform
You don't need the whole platform on day one. You need to know which stage you're at, and what the next one asks of you.
Figure 6. A maturity model, not a checklist. Most teams should ship stage two before worrying about stage four; the mistake is stalling at stage one and calling it production.
Each stage earns the next. A remote server is worth building once more than one host needs it. Scoped identity gets urgent the moment real user data comes within reach. A gateway pays off when the number of servers and teams makes per-server controls unmanageable. The source material notes that keeping all of this healthy is turning into its own discipline, with "Agent Ops" teams treating the MCP layer as infrastructure to run rather than a feature to ship once.3
Treat the MCP layer like production infrastructure
The distance between a demo and a platform isn't a smarter model or a better prompt. It's the work the demo skipped: tool designs that fit the context window, tokens scoped so a wrong call fails safe, policy you can change without a redeploy, and enough logging to reconstruct what happened. None of it is exotic. It's the operational discipline you'd bring to any shared service that touches production data, applied to a layer that happens to take its orders from a model.
So run it like one. Version it, watch it, and decide ahead of time which actions need a human on the button. Add a gateway when the layer is genuinely shared, and not before. Moring.ai builds in this space, between an agent's intent and its authority to act, because that's where the failures that matter tend to show up.
Sources and further reading
- AWS Prescriptive Guidance, "Model Context Protocol strategies on AWS" (supplied source), server hosting: a local server runs over stdio with no client-server auth and inherits the user's credentials. docs.aws.amazon.com/…/mcp-hosting-strategy.html. ↩
- AWS Prescriptive Guidance (supplied source): the three pillars (tool design, hosting, governance) and their Well-Architected mapping. docs.aws.amazon.com/…/mcp-strategies. ↩
- Emergence document (supplied source), §VI.C: single-user origins, context drift, the auditability dividend, and "Agent Ops" teams; connectivity-not-governance from §I–II. ↩
- AWS Prescriptive Guidance (supplied source), tool-design strategy: the too-few / too-many tension, workflow scoping, naming, read/write split, and the ~50-tool / ~8-parameter guidelines. docs.aws.amazon.com/…/mcp-tool-strategy.html. ↩
- AWS Prescriptive Guidance (supplied source): the ~3× database-task figure ("Middleware for LLMs," EMNLP 2024) and the 28–32% figure (MARCO). Both are AWS summaries of external work, not AWS measurements. ↩
- AWS Prescriptive Guidance (supplied source), tool discovery: static / dynamic / search-function approaches; ~250–500 tokens per tool (so ~5,000–10,000 at 20 tools); AgentCore Gateway semantic search. docs.aws.amazon.com/…/mcp-tool-strategy-discovery.html. ↩
- Emergence document (supplied source), §IV.A–B: prompt bloat; the ~20,000-call, >$6,000 evaluation; and the Proactivity / Tool-Correctness / Effectiveness / Overhead metrics. Underlying study: "Help or Hurdle?" arXiv:2508.12566 (3.25×–236.5× input-token overhead). ↩
- Emergence document (supplied source), §IV.C, Table 3: RAG-MCP, 13.62% → 43.13% tool-selection accuracy and ~2,134 → 1,084 prompt tokens. Underlying paper: "RAG-MCP," arXiv:2505.03275. ↩
- AWS Prescriptive Guidance (supplied source), hosting and governance: local/remote/gateway; machine-to-machine vs user-delegated access; scoped tokens, `aud` validation, and token isolation (AgentCore Identity); the clone-database example; rate limiting; observability; golden-dataset regression. docs.aws.amazon.com/…/mcp-governance-strategy.html. ↩
- MCP authorization: OAuth 2.1 added in the 2025-03-26 revision; 2025-06-18 made the server an OAuth resource server and required RFC 8707 resource indicators. specification 2025-06-18; auth0.com/blog/mcp-specs-update-all-about-auth. ↩
- MCP specification, tools: human-in-the-loop confirmation for sensitive, state-changing actions. modelcontextprotocol.io/…/server/tools. ↩
- Emergence document (supplied source), §V, Table 4: CVE-2025-6514 (
mcp-remote, CVSS 9.6), XPIA / "check open issues," tool poisoning and rug-pulls, with mitigations. Primary sources: nvd.nist.gov/vuln/detail/CVE-2025-6514; invariantlabs.ai/blog/mcp-github-vulnerability. ↩
Editorial note: the demo-versus-platform framing, the "gateway when shared" position, and the phased rollout are Moring.ai's interpretation. Tool, hosting, and governance specifics come from the AWS strategies document; the security taxonomy and benchmarks from the Emergence document; protocol and CVE details are cross-checked against the MCP specification and NVD. Named products (AgentCore, Docker MCP Gateway) are examples of published patterns, not Moring.ai deployments. Current MCP spec revision: 2025-11-25.
