What Is MCP?

A standard protocol for exposing tools to models, so integrations stop being written once per application.

Before MCP, connecting a model to a data source meant writing that integration inside your application. Every application needed its own. Ten applications wanting the same five integrations meant fifty implementations of the same work.

The Model Context Protocol standardizes the interface. Write a server once, and any compatible client can use it.

The shape

MCP is a client-server protocol.

Servers expose capabilities — a filesystem server, a database server, a ticketing server. Each declares what it offers and handles requests.

Clients are the applications with a model attached. The client discovers what a server offers and makes those capabilities available to the model as tools.

The decoupling is the point. Servers know nothing about which model or application will use them. Clients know nothing about a server’s internals. Both sides implement one protocol instead of N integrations.

Servers can run locally as a subprocess or remotely over HTTP. Local is common for filesystem and developer tooling; remote for shared services.

Three kinds of capability

Tools — functions the model can call. Search a database, create a ticket, read a file. These map directly onto normal tool calling; MCP standardizes how they are discovered rather than how they are invoked.

Resources — data the client can read and place in context. A file, a schema, a document. Not called; fetched.

Prompts — reusable templates a server offers for common operations against it.

Tools are the part that matters most in practice.

What it changes and does not change

Does not change: the model still only emits requests. Execution still happens outside it. Every security consideration is unchanged — validate arguments, enforce permissions on the user rather than the request, gate irreversible operations.

Does change: where integration code lives, and who writes it. A vendor can ship one MCP server rather than plugins for each AI application. Discovery becomes dynamic — a client can ask a server what it offers at runtime.

The practical effect is a shared ecosystem instead of per-application silos.

Where it earns its keep

Reusable integrations. A database server written once serves every compatible client.

Local data access. A local server can reach files and services that a hosted model provider never sees. The data stays on your machine; only tool calls and results cross the boundary.

Vendor-supplied access. Publishing an MCP server is a reasonable way for a product to become usable from AI applications generally.

Composition. Multiple servers at once — filesystem, database, ticketing — with the client presenting the union.

Where it does not help

One integration in one application. The protocol is overhead if you have a single tool and a single consumer. Define the tool directly.

Latency-critical paths. An extra process and protocol hop is real, if small.

Tool sprawl. MCP makes adding tools easy, which makes it easy to add too many. Selection accuracy degrades past roughly a dozen similar tools, and connecting five servers with eight tools each produces exactly that. Route to a relevant subset rather than exposing everything.

Security worth stating plainly

MCP does not solve agent security, and easy integration can obscure the risk.

A server is code you are running. A third-party server has whatever access you grant it. Treat it as you would any dependency.

Tool descriptions come from the server and enter your model’s context. A malicious or compromised server can shape model behavior through them.

Server results are untrusted text. A server returning web content or user-submitted data is a prompt injection vector, exactly as any other tool would be.

Permissions still belong to you. Nothing in the protocol enforces what the current user may do. That check happens in your client or in the server, deliberately.

What to remember

• MCP standardizes how models discover and use tools, so integrations get written once rather than per application.
• Servers expose tools, resources, and prompts; clients present them to the model.
• Nothing about the execution or security model changes — the model still only requests.
• Worth it for reusable integrations, local data access, and composition; overhead for a single tool in a single app.
• Servers are dependencies with access, their descriptions reach your context, and their results are untrusted.

Next: Your First LLM API Call