What is MCP?
The Model Context Protocol is a standard interface between an AI application and the capabilities it can use. It is not a framework, not a hosting product and not tied to one vendor — it is an agreement about how a client asks “what can you do?” and how a server answers.
The problem it solves
Before a standard existed, connecting a model to an external capability meant writing an integration for one specific pairing. Every assistant had its own plugin format; every tool provider re-implemented the same integration once per assistant. Ten tools and five clients is fifty integrations, and every one of them rots independently.
MCP replaces that grid with two sides of one contract. A server describes what it offers in a machine-readable form. A client reads that description and can immediately use it. Ten tools and five clients becomes fifteen implementations, not fifty — and any new client gets every existing server for free.
Before
N × M
One integration per tool, per client.
With a protocol
N + M
Each side implements the contract once.
Client, server, transport
Three moving parts, and only one of them is yours to think about most of the time.
The host / client
The AI application — a desktop assistant, a coding agent, an IDE, your own program built on an SDK. It connects to servers, reads what they offer and passes those capabilities to the model.
The server
A process or an HTTP endpoint that exposes capabilities. It does not know or care which client is calling; it answers the protocol. An image server, a database server, a ticketing server — all the same shape from the outside.
The transport
How the two talk. Either stdio, where the client spawns the server as a local subprocess, or HTTP, where the server is a remote endpoint. The capabilities are identical either way; only operations differ.
Tools, resources and prompts
A server can expose three kinds of thing. In practice most servers, this one included, are mostly about the first.
| Primitive | What it is | Example here |
|---|---|---|
| Tools | Actions the model can invoke, each with a JSON schema for its arguments. | generate_image, remove_background |
| Resources | Data the client can read into the model’s context. | A generated image the client attaches |
| Prompts | Reusable templates a client can surface to the user. | A pre-written asset-pipeline instruction |
💡 Why the schema matters more than it sounds
Because the tool arrives with a full JSON schema, the model knows which fields exist, which are required, and what the allowed values are — before it calls anything. That is the difference between an agent that gets an aspect ratio right first time and one that guesses and retries.
What a call actually looks like
Underneath, MCP is JSON-RPC. The client lists tools once, then calls them by name. You will rarely write this by hand — your client does it — but seeing it demystifies the whole thing.
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "generate_image",
"arguments": {
"prompt": "a paper boat on still water",
"aspectRatio": "16:9"
}
}
}That is the entire mechanism. Everything else — discovery, capability negotiation, streaming — is machinery around this one idea.
When MCP is worth it
Use MCP when…
- The model decides what to call and when.
- You want the same capability in several clients.
- The tool list should change without redeploying the client.
- You want schemas the model can read rather than prose it must interpret.
Skip it when…
- Your own code decides the sequence.
- It is one call in one service.
- You need behaviour a protocol layer would only get in the way of.
- A plain POST does the job in three lines.
This is not an either/or. The image tools on this site are available both ways, on purpose: the same operations as MCP tools and as REST endpoints, so an agent and a cron job can both do the work without either being forced through the wrong door.
FAQ
What is the Model Context Protocol in one sentence?
It is a standard way for an AI application to discover and call capabilities offered by an external server, so any compliant client can use any compliant server without either side writing code specifically for the other.
What is the difference between a tool and a resource?
A tool is an action the model can invoke, with a JSON schema for its arguments — generating an image, sending a message, running a query. A resource is data the client can read into context, like a file or a record. Prompts are reusable templates a client can surface to the user.
Do I need to run a server locally?
Not necessarily. MCP servers can run as a local process the client spawns and talks to over stdio, or as a remote HTTP endpoint the client connects to over the network. Remote is easier to operate; local is useful when the server needs access to your machine.
Is MCP tied to one AI company?
No. It is an open protocol with an open specification and implementations across many clients and languages. That portability is most of the point — a server you write once is reachable from every client that speaks it.
When should I not use MCP?
When there is no model in the loop. If your own code is deciding what to call and when, a plain HTTP request is simpler and has fewer moving parts. MCP earns its keep when the model itself needs to discover and choose the capability.