MCP: connecting Claude to real tools, not longer prompts
Before knowing MCP, the only way to give an agent access to an external service was to describe that access in text inside the prompt, or to code an ad hoc integration for each service, every time. That works for one tool. It becomes unmanageable at five, because every integration is written differently and nothing guarantees they coexist cleanly in the same context.
The problem it solves#
Model Context Protocol standardizes access to external tools: an MCP server exposes a set of capabilities (read an email, search a file, list deployments) in a common format that any compatible client can consume without tool-specific integration code. The gain isn't only practical, it's architectural: the agent no longer receives a text description of a tool it has to interpret, it receives a structured interface it can call directly.
In my everyday Claude Code usage, I have MCP servers connected for Gmail, Google Calendar, Vercel and WordPress.com. Concretely, that means I can ask the agent to check my recent Vercel deployments or find an email thread before a client call, without ever having described myself how to query those services: the MCP server carries that responsibility, not my prompt.
What changes compared to a hardcoded tool#
| Hardcoded integration | MCP server | |
|---|---|---|
| Reusability | Specific to a project or agent | Reusable by any MCP client |
| Maintenance | Owned by each integration | Centralized on the server side |
| Capability discovery | Manually described in the prompt | Exposed by the server, read dynamically |
| Switching providers | Rewriting the integration | Swapping servers, stable interface |
The row that matters most is the third one: an MCP server exposes what it can do, and the agent discovers it instead of guessing from a text written by a human who might have missed a case.
The real risk: access, not the protocol#
An MCP server gives the agent real access to a real system. The question to ask before connecting a server isn't "does it work", it's "what am I willing to let this agent do without direct supervision". A poorly scoped server (write access where only read was needed) turns a productivity gain into a security risk.
That's why, before connecting an MCP server, I always separate reversible actions (listing, searching, reading) from irreversible ones (sending, publishing, deleting). The former can run without systematic confirmation. The latter must stay behind explicit validation, regardless of how much I trust the server.
MCP and skills don't play the same role#
A skill encodes a behavior: a method, a checklist, a way of doing a recurring task. An MCP server encodes an access: a capability to act on an external system. The two combine naturally, a skill can very well rely on an MCP server to accomplish its task, but confusing the two leads to a classic mistake: trying to package system access inside a skill rather than a dedicated MCP server, which makes that access non-reusable elsewhere.
What still remains a real friction#
The protocol solves the problem of describing tools, not the agent's judgment about when to use them. A poorly documented MCP server (vague capability names, unexplained parameters) reproduces exactly the problem it was supposed to avoid, in a different form. Description quality remains decisive, it has simply moved: it's no longer in my prompt, it's in the server.
What this generalizes to#
MCP doesn't change anything about the agent's probabilistic nature: it remains free to decide when to call a tool, and can get it wrong. What it changes is the cost of connecting a new tool: from rewriting an integration every time, to simply connecting to a server that already exposes a clean interface. The question to ask before every new connection stays the same as for human access to a system: what scope, what reversibility, what supervision, regardless of the protocol used to expose it.