MCP end to end

You already built MCP from scratch. Chapter 18's lab was a working Model Context Protocol server and client in 150 lines, and the Part 1 investigation ran over it with the tools moved out of the process. This chapter zooms out from that lab to the ecosystem: how MCP servers are hosted, the genuine economics of tool discovery at scale, where AgentCore Gateway fits, and the under-discussed question of when MCP is overhead a plain function call would avoid. The protocol is settled; the design decisions are about when and how to use it.

What MCP settled, and what it did not

The concepts chapter framed MCP as the standard port for tools, and the lab proved it is a small, honest protocol: JSON-RPC, an initialize handshake, tools/list for discovery, tools/call for invocation. What that standardization settled is real: any MCP-speaking client can use any MCP server without bespoke integration, which is why an ecosystem of thousands of community servers exists and why one agent can reach tools written by people it will never meet. The USB-C analogy holds, one port, many devices.

What MCP did not settle is whether you should reach for it at all for a given tool, and that is the chapter's actual subject. A protocol designed for cross-boundary interoperability carries costs that are invisible at the scale of the lab and real at the scale of a platform. Knowing when those costs are worth paying is the skill.

Hosting servers

An MCP server is any process that answers the protocol, which means hosting one is a normal deployment question with an agent flavor. Two common shapes:

• On Lambda. An MCP server that fronts an internal API is a natural Lambda: the function speaks the protocol, runs on demand, scales to zero, and carries its own scoped IAM role. This is how a team exposes its service to agents without standing up a persistent server.
• Via Gateway. AgentCore Gateway is the managed MCP-server factory: point it at a Lambda, an OpenAPI spec, or a Smithy model and it manufactures the server for you, with auth and metering wrapped around it. The decoder ring named this; the design review adds the judgment: Gateway is worth it for the enterprise long tail, dozens or hundreds of existing APIs you do not want to hand-wrap, and overkill for the handful of tools a focused agent actually uses, which are cheaper to expose as the 150-line server you already know how to write.

Either way, the anti-lock-in property from the earlier lab holds: a Gateway-manufactured server is consumable by any MCP client, and its targets are ordinary APIs you still own, so nothing about hosting via MCP traps you.

The economics of discovery

Here is the cost the lab's three-tool demo could not show. MCP is discovery-first: a client calls tools/list and loads every tool's name, description, and schema into the model's context. With three tools that is free. With three hundred tools, from a dozen connected servers, the tool definitions alone can consume a large slice of the context window before the agent has read a single word of its task, and every token in that window is paid for on every turn. Tool definitions are not free context; at scale they are a significant, recurring cost.

The mitigations are real and worth knowing:

• Tool search. Instead of loading all schemas upfront, the agent searches the tool catalog and loads only the relevant few, the pattern the companion context-engineering book prices in detail. Gateway's search over an aggregated catalog is this: a way to connect hundreds of tools while paying context for only the handful a given task needs.
• Scoping the server set. An agent does not need every server the organization has; it needs the servers its job uses. Connecting an agent to fewer, task-relevant servers is the cheapest mitigation and the most often skipped, because "connect everything" is easier than deciding what each agent actually needs.
• Keeping the definitions cacheable. Tool lists render into the prompt prefix, so a stable tool set caches and a churning one does not. A server whose tool list changes every request quietly destroys the fleet's cache hit rate, which is the caching discipline reaching all the way out to protocol design.

When MCP is overhead

The design review's most useful verdict is the one the ecosystem's enthusiasm obscures: MCP is for tools that cross a boundary, and for tools inside your own process it is often pure overhead. The lab moved three tools out of the process to demonstrate the protocol; that move bought interoperability (any client can now use them) at the cost of a serialization round trip and a network hop. When the tool is your own function, called only by your own agent, in your own codebase, that trade is backwards: a direct function call is faster, simpler, and carries no protocol tax, and wrapping it in MCP adds a wire format and a server to operate for interoperability nobody will use.

The decision rule: reach for MCP when the tool is shared (used by agents or teams beyond the one that wrote it), third-party (someone else's tool you want to consume), or separately deployed (it lives in another service regardless of MCP). For a tool that is none of those, private, first-party, in-process, a plain function in the loop is the right call, and Part 1's in-process tools were not primitive, they were correctly scoped. The frequent mistake is MCP-ifying everything on principle, paying the boundary cost for tools that never cross a boundary.

Don't be confused: MCP the protocol vs MCP the ecosystem. The protocol is the small, settled thing you built: JSON-RPC, list, call. The ecosystem is the sprawling thing around it: thousands of community servers of wildly varying quality, security, and maintenance. Adopting the protocol is a clean engineering decision; adopting an arbitrary community server is a supply-chain decision with trust implications, because a malicious or compromised server's tool descriptions and results flow straight into your agent's context and actions. Vet third-party servers the way you vet any dependency, more, because this one talks directly to your model.

👉 Next: A2A and the multi-vendor future, the protocol one level up, where agents hire other agents across trust boundaries, and an honest accounting of which standards are load-bearing today versus aspirational.