MCP (Model Context Protocol): the standard for tools and context
The 'USB-C' that connects models to tools and data in a standardized, reusable way.
5 min read
Every AI application was reinventing the wheel: database integration here, API call there, everything coupled to the model in a different way. MCP (Model Context Protocol) solves this with a single contract — an open protocol that standardizes how models discover and invoke tools, resources, and prompts, regardless of who implemented them.
The problem MCP solves
Before MCP, every team connecting an LLM to an external tool wrote its own integration layer. Want to fetch data from S3? Custom code. Query a database? More custom code. Reuse that integration in another agent, another project, with another model? Rewrite everything.
The result was a zoo of incompatible adapters. Switching models meant rewriting integrations. Adding a new tool meant touching the agent's core. Sharing a tool between teams was nearly impossible without duplication.
This problem isn't new — it's the same problem USB solved in hardware. Before USB, every peripheral had its own proprietary connector. After USB (and today USB-C), any peripheral speaks the same language and any device can use it. MCP does the same for AI tools: it defines a single interface that any client (agent, app, IDE) can use to discover and call any tool exposed by any MCP server.
MCP Architecture: client ↔ server
An MCP client (agent, IDE, app) discovers tools, resources, and prompts exposed by independent MCP servers. The model decides what to call; the protocol standardizes how the call happens.
- Agente / App · MCP Client
- LLM · Raciocínio + decisão
- MCP Protocol · JSON-RPC 2.0
- MCP Server · Banco de dados
- MCP Server · API externa
- MCP Server · Arquivos / S3
- Bedrock AgentCore · Gateway MCP
MCP client, MCP server — and what each one does
The protocol divides the world into two well-defined roles.
MCP Server is who exposes capabilities. It declares tools (tools), resources (resources — data the model can read, like files or database records), and reusable prompts (prompts). An MCP server is essentially a process that responds to JSON-RPC 2.0 calls over a transport (stdio, HTTP+SSE, or WebSocket). Any team can write an MCP server for their internal API and make it available to all company agents.
MCP Client is who consumes those capabilities. The agent (or IDE, or app) calls tools/list to discover what's available, and tools/call to execute. The client doesn't need to know anything about the server's internal implementation — it only needs to understand the MCP contract.
The LLM itself doesn't speak MCP directly. It uses tool calling (lesson 07) to decide which tool to invoke and with what arguments. The agent, acting as MCP client, translates that decision into a real MCP call. This separation matters: tool calling is the mechanism by which the model decides to act; MCP is the protocol by which the action is executed in a standardized way. They are complementary layers, not competing ones.
Tool Calling vs MCP — not the same thing
| Aspect | Tool Calling (Lesson 07) | MCP | |
|---|---|---|---|
| What it is | LLM capability to decide to call a function | Transport and tool-discovery protocol | — |
| Who acts | The model (reasoning) | The agent/client (execution) | — |
| Where it lives | Inside the inference cycle | In the integration / infrastructure layer | — |
| Standardization | Varies by provider (OpenAI, Anthropic, Bedrock…) | Single open protocol (Anthropic, industry-adopted) | — |
| Reuse across projects | No — each app defines its own schemas | Yes — MCP server is reusable by any client | — |
In practice, MCP shifts where you put integration effort. Without MCP, every new agent that needs to access your CRM system requires someone to write and maintain a specific wrapper. With MCP, you write the CRM's MCP server once and any agent in the company — regardless of model, framework, or team — can discover and use those tools automatically. The investment pays off on the second integration. My recommendation: treat MCP servers like capability microservices. Version them, document tool schemas carefully, and apply authentication at the transport layer — don't assume that because it's internal it's safe.
MCP — who's who
Tap a concept, then its definition.
Why this matters for architecture: reuse, decoupling, and ecosystem
The architectural gain from MCP goes beyond saving lines of code. It introduces real decoupling between the model and tools. You can switch the LLM from Claude to Titan without touching MCP servers. You can update a tool's implementation without redeploying the agent. You can audit all tool calls at a single entry point.
The ecosystem is already relevant: IDEs like Cursor and VS Code Copilot are MCP clients. Tools like GitHub, Slack, and Postgres already have public MCP servers. This means an MCP server you write today for your agent can tomorrow be used directly by a developer in their IDE — with no changes.
On AWS, Bedrock AgentCore Gateway (covered in lesson 17) exposes tools via MCP, acting as a managed MCP server. You register your tools once and any MCP client — whether a Bedrock agent or an external agent — can discover and call them with authentication and observability already included.
The spec also defines resources: data that the server exposes for the model to read directly into context, without a tool call. Think of a config file, a customer record, or a database schema — the MCP server exposes them as resources, and the client injects them into the model's context when needed. This complements RAG (lesson 06): RAG searches dynamically; MCP resources are structured references the agent knows exist.
Key takeaways on MCP
Frequently asked questions about MCP
Does MCP replace the model's native tool calling?
No. Tool calling is the LLM's internal mechanism to decide to act. MCP is the external protocol that standardizes how the agent executes that action. You need both: the model decides, MCP delivers.
Do I need MCP to build a working agent?
Not for a prototype. But without MCP, every new integration is coupled to the agent. MCP starts paying off when you have more than one tool, more than one agent, or more than one team. It's a scale decision, not a functionality one.
Is MCP secure by default?
The protocol defines the mechanisms (OAuth 2.0 for HTTP, for example), but security implementation is your responsibility. An unauthenticated MCP server exposed internally is still a risk — any compromised agent can call it. Apply authentication, per-tool authorization, and logging for all calls.
What's the difference between MCP and a regular REST API?
A REST API you design freely. MCP defines a specific contract for tool discovery (tools/list), execution (tools/call), resource reading, and prompt use — a contract that any MCP client already knows how to speak. It's the difference between a proprietary cable and USB-C.
Quick check
1. Which best describes MCP?