MCP Strategies on AWS, Part 1: Reading the Whole Guide

written by Stefan Christoph

- 9 minutes read
TL;DR: AWS published a Prescriptive Guidance paper, “Model Context Protocol strategies on AWS,” that organizes MCP into three pillars: tool design, hosting, and governance. The most useful parts are concrete: keep tools to eight parameters or fewer, bundle any workflow that needs three or more calls into one tool, split a server past fifty tools, and remember each tool definition costs 250 to 500 tokens on every single model call. The paper is a guide-tier document (it tells you how to think, not which buttons to click), so this is the start of a four-part series where I turn each pillar into runnable code. This first post covers what the guidance contains, why it matters, and how it lines up with the security concerns the wider MCP community has been raising. The headline accuracy numbers come from external research, not an AWS benchmark, so I treat them as cited research rather than a guarantee.

A customer asked me last month why their internal agent kept picking the wrong tool. They had wired up forty-odd MCP tools to a single agent and assumed more capability meant more usefulness. The opposite happened. The model spent its context budget reading tool descriptions and still guessed. That conversation is the reason I read the new AWS guidance the day it landed, and the reason I am writing this series.

AWS published Model Context Protocol strategies on AWS as part of its Prescriptive Guidance program in March 2026. It is a strategy document, and the temptation with strategy documents is to read the one-paragraph summary and move on. I think that is a mistake here, because the actionable content is in the details: the specific thresholds that would have told my customer to split their server long before it broke.

This post is the map of the whole guide. The three posts after it each take one pillar and build working code against it.

What AWS Prescriptive Guidance actually is

Before the content, the container. AWS Prescriptive Guidance is a library of material written by AWS experts, organized into three tiers aimed at three audiences [1]:

  • Strategies: broad methodologies for executives, framed around business outcomes.
  • Guides: actionable plans for architects and technical managers that break a strategy into implementable components.
  • Patterns: hands-on implementations with code and step-by-step tasks for builders.
The scaling problem leads to MCP, which combines with three pillars: tool design, hosting, and governance

The shape of the guidance: MCP answers the scaling problem but is necessary, not sufficient. The three pillars (tool design, hosting, governance) are what you combine with it.

The MCP paper sits in the guide tier. That placement explains its character: it is prescriptive about how to think (when to bundle tools, how to scope tokens, where to host) but it deliberately stops short of click-by-click implementation. The pattern-tier layer, the runnable code, is left to you. That gap is exactly what this series fills. Each later post is the pattern I wish shipped alongside the guide.

The problem MCP is solving

The guide opens with an honest framing of why naive tool scaling breaks, and it breaks in two ways.

First, duplication without governance. Every team rebuilds the same integration, so you pay N times for the same work, carry N times the bugs, and have no central place to enforce security, track usage, or manage versions. Embedding tools directly in an agent makes it worse, because every tool change forces an agent redeploy.

Second, context-window pressure. Every tool definition is sent on every model invocation, competing with the system prompt and conversation history. As the window fills, the model degrades: it has a harder time finding the relevant information and less capacity left for reasoning.

The Model Context Protocol answers the first problem cleanly. It is a universal standard, often described as “USB-C for AI applications,” where an MCP server acts as an intermediary that hosts tools and exposes them over JSON-RPC 2.0. That decouples agent development from tool development and standardizes how tools are packaged and invoked.

The guide is refreshingly direct about the limit here: the MCP standard does not solve all scaling and governance challenges. It is necessary but not sufficient. You still have to combine it with effective tool design, hosting, and governance, which is the rest of the document.

When to use MCP, and build versus buy

Adopt MCP when you need centralized governance over how agents reach enterprise systems, when developers are losing time to inconsistent custom integrations, when you have duplicated tools, or when you want to expose proprietary capabilities to external agents as a governed interface.

Once you have chosen MCP, the guide gives a decision ladder that I find genuinely useful in customer conversations because it pushes back on the instinct to build:

  1. Use a pre-built server first. Many open-source servers already exist for filesystems, web browsing, code sandboxes, databases, and APIs. AWS ships its own managed AWS MCP Server for authenticated access to AWS.
  2. Enhance an existing server before building. Enrich tool definitions with documentation and examples, add complementary tools, or improve the underlying APIs to be more model-friendly.
  3. Build custom only when you must: domain-specific multi-step workflows, golden-path abstractions that enforce organizational standards, or complex orchestration that embeds compliance.

Most teams should start at step one and only graduate to step three with a clear reason. I have watched too many projects begin by building a bespoke server for a problem a pre-built one already solved.

The three pillars in one paragraph each

Tool design is the most prescriptive section and the one I would read first. It gives hard numbers: keep parameters to eight or fewer, bundle any workflow that needs three or more separate calls into a single tool, split a server once it passes fifty tools, separate read operations from write operations so destructive actions are explicit, and name tools domain-noun-verb so related operations cluster when sorted. The post-two companion code measures all of this.

Hosting walks a spectrum from local (a subprocess over stdio, simplest, no client-to-server auth needed) through remote (over HTTPS, with real authentication and version control) to an MCP gateway (a central proxy that handles auth, routing, and, via Amazon Bedrock AgentCore Gateway, semantic tool search to cut context use) [2]. The guide is candid that most MCP usage today is local, and that the spectrum is not one-size-fits-all.

Governance is where the security story lives, and its headline principle is token isolation: MCP tools must use their own purpose-generated, scoped-down tokens, and user credentials must not propagate through the agentic system. The canonical example is an admin asking an agent to clone a production database, where a hallucinated cleanup step reusing admin credentials would delete production, but a scoped read-and-create token makes that delete fail safely. Amazon Bedrock AgentCore Identity is the named AWS implementation for managing both machine-to-machine and user-delegated tokens [3].

How this lines up with the wider MCP conversation

I did not want to read this guide in isolation, so I mapped it against what the security research community has been documenting. The community has converged on a small set of MCP attack classes: prompt injection via tool descriptions, tool poisoning, confused deputy, exfiltration, and chain-of-trust abuse. Here is where the AWS guidance is strong and where it leaves work for you:

  • Confused deputy and token passthrough: this is the guide’s headline, and it aligns directly with the MCP specification, which states that servers must validate that tokens were issued specifically for them and explicitly forbids token passthrough [4]. The guide’s token-isolation model is a textbook mitigation.
  • Context-window degradation: the guide’s quantified tool-design advice matches Anthropic’s own engineering guidance that loading every tool definition up front is wasteful and degrades performance [5]. The 250-to-500-tokens-per-tool math is the most useful thing in the document.
  • Tool poisoning: the guide addresses this only partially, through definition discipline and a private, scanned registry. It assumes you trust the servers you register. Runtime tool-definition integrity checks are defense-in-depth you add on top.
  • Prompt injection via processed content: addressed obliquely. Separating read from write and scoping tokens limits the blast radius of a successful injection, but the guide does not prescribe input or output sanitization. Token isolation limits the damage, not the occurrence.

That last distinction matters. The guide is scoped to design, hosting, and governance strategy. It is not a complete agentic-security playbook, and reading it as one would leave gaps. I will be explicit about those gaps in the governance post.

The numbers worth quoting, with a caveat

The guide cites a 28 to 32 percent task-accuracy improvement from following its tool-design advice, and a roughly threefold accuracy gain from structured tool wrappers over raw API access. These come from external research papers, not AWS-controlled benchmarks, so I quote them as cited research, not as an AWS service-level guarantee. The numbers I trust without qualification are the structural ones (eight parameters, three-plus calls to bundle, fifty tools to split, 250 to 500 tokens per definition) because they are design rules, not performance claims.

Where the series goes from here

This was the map. The next three posts are the territory, each with code you can run:

  • Part 2: Tool Design in Code. Granular versus coarse-grained tools using a GitHub-issue example, a token-tax counter that measures the real cost of N tool definitions, and demos of the eight-parameter rule and domain-noun-verb naming.
  • Part 3: Hosting, from Local to AWS. A local stdio server as the starting point, then infrastructure-as-code for a remote server that is bounded to a single AWS account and not internet-facing, with the real deploy output and the path to extend it outward.
  • Part 4: Governance in Code. A token-isolation demo where a scoped token makes a hallucinated delete fail safely, plus per-tool rate limiting with the standard rate-limit headers.

(Links will be added once each part is published.)

If you are advising a team on agentic AI, the build-versus-buy ladder and the token-isolation story are the two things from this guide I would put in front of them first. The rest is detail, but as my customer with forty tools learned, the detail is where the project succeeds or stalls.

Sources

  1. AWS Prescriptive Guidance and Getting started — the three-tier program model.
  2. Create an Amazon Bedrock AgentCore Gateway — managed MCP entry point with optional semantic search.
  3. Provide identity and credential management with Amazon Bedrock AgentCore Identity.
  4. MCP specification — Authorization Security Considerations.
  5. Anthropic — Writing effective tools for AI agents.
  6. Model Context Protocol strategies on AWS (PDF) — the source guide.
Stefan Christoph

About the Author

Stefan Christoph is a Principal Solutions Architect at AWS, focused on agentic AI, media & entertainment, and helping builders move from demo to production. He writes about AI architecture, developer productivity, and the future of software.

This is a personal blog. Opinions expressed here are my own and do not represent the views or positions of my employer.

Learn more →

❤️ Created with the support of AI (Kiro)