MCP in production: tools as servers
Lesson 2 of 4 in Agentic Systems on AWS.
Hardwiring every tool into every agent does not survive contact with an enterprise — fifty agents times forty tools is two thousand integrations. The Model Context Protocol collapses that: tools become servers that any MCP-speaking agent can discover and call. The agent application is the host; it runs an MCP client per connection; each server advertises its tools in a standard, machine-readable form. Discovery is a request (tools/list), invocation is a request (tools/call), and both get answers. Because every interaction has that same shape, one client implementation reaches every tool you ever add — which is the whole reason to use an MCP client library rather than writing forty bespoke integrations.
The professional question is never "what is MCP" — it is where the server runs. The exam guide draws the line itself: Lambda for stateless MCP servers providing lightweight tool access, Amazon ECS for MCP servers that provide complex tools. Watch one prompt exercise both lanes below.
| Host | Fits when | The trade |
|---|---|---|
Lambda | Stateless, lightweight tool access: lookups, calculations, single API wraps — any invocation can serve any request | Scale-to-zero economics and zero servers, against cold starts, execution time limits, and nowhere to keep in-memory session state |
Amazon ECS | Complex tools: heavy dependencies, long-running work, state held across a session, steady high traffic | Always-on containers you size and pay for — in exchange for persistent processes and no per-invocation ceiling |
AgentCore Gateway | The tool already exists as an API or Lambda function and you want it exposed as an MCP tool without writing a server | A managed front door (covered next lesson) — AWS runs the MCP plumbing; you keep the backend |
Key terms: MCP, Strands Agents, Bedrock AgentCore
Interactive checkpoint quiz (3 questions) — open this page in a browser to take it.