Exam-style
A team has built an internal assistant as an agent. It can raise and update tickets, search a document store, and look up leave balances in an HR API. Each of those three connections was written by hand: a bespoke tool definition, a bespoke adapter, and a bespoke bit of glue holding it together. A fourth system is now on the list, and a second team wants to reach the same three from an agent of its own. Someone suggests Model Context Protocol [MCP]. What does adopting it actually give them?
Reveal the answer
B. An open protocol for connecting agents to external tools and data sources through one common interface, so a system exposed once can be called by any agent that speaks the protocol
MCP is an open protocol that standardises how an agent reaches things outside itself. A system publishes its capabilities once, as an MCP server, describing what each tool does and what it expects; any MCP-aware agent can then discover and call those tools through the same interface. For this team that changes the arithmetic. The fourth system gets exposed once rather than wired into one agent, and the second team points its agent at servers that already exist instead of writing the same three adapters again. What it does not change is the agent’s judgement: choosing the right tool at the right moment is still tool usage, and a badly described tool is chosen badly no matter how it is connected. The four wrong answers are the four common confusions, and each is a real thing that MCP is not. It is not a prompt format; how the instructions are written is a separate concern, and MCP says nothing about it. It is not a memory store; deciding what an agent remembers within a conversation and between conversations is memory management, held in its own store with its own retention rules. It is not agent-to-agent plumbing; the ways agents delegate, hand off, and share a workspace are multi-agent communication patterns, and MCP runs the other way, between one agent and the systems it acts on. And it is not proprietary: MCP is an open standard used well outside AWS, though AWS does implement it. Amazon Bedrock AgentCore Gateway is the managed piece that takes APIs a company already has and exposes them as MCP tools, which is how an existing HR API becomes callable without anyone writing an adapter for it.
Q. An agent reaches a ticketing system, a document store and an HR API, and all three connections were hand-written. A fourth system is coming and a second team wants the same three. What does adopting Model Context Protocol [MCP] give them?
A. One common interface between agents and external systems. A system is exposed once as an MCP server, and any agent that speaks the protocol can discover and call its tools without a bespoke adapter per pairing.
Why? Sort the confusions by direction and by layer. MCP runs outward, from one agent to the systems it acts on, so it is not the agent-to-agent plumbing; delegation, handoff and a shared workspace are multi-agent communication patterns, a different problem in agentic AI. It sits at the connection layer, not the prompt layer and not the memory layer, so it is neither a way of writing prompts nor a place to keep conversation history. And it is an open standard rather than an AWS product, which is why the AWS piece is a service that speaks it: Amazon Bedrock AgentCore Gateway exposes existing APIs as MCP tools. Connecting a system is the cheap half. Describing each tool well enough that the agent picks the right one is still the work, because tool usage is a decision the model makes from those descriptions.