What is MCP (Model Context Protocol)?
MCP, the Model Context Protocol, is an open standard for connecting AI models to outside tools and data. A client and server exchange JSON-RPC 2.0 messages so the model can read a typed list of what a source offers, then call it. It replaces one custom integration per tool with one protocol.
/mcp. Nothing here needs an API key or a signup.
The comparison the specification itself draws is to a port standard. Before it, every model host that wanted to reach a database, a filesystem or an API wrote a bespoke adapter for each one. MCP describes that connection once, so a server written for one host works with every other host that speaks the protocol.
The problem it was built to solve
A language model can only act on what is in its context window. Getting anything else in there means somebody wrote code to fetch it, format it and inject it. That code is specific to both sides: this model host, that data source.
With N hosts and M sources, you were on the hook for N times M integrations. MCP turns that into N plus M. A source implements a server once; a host implements a client once; anything on either side of the protocol can now reach anything on the other.
The six primitives
The specification splits capabilities by which side offers them. Servers offer three things to the model, and clients offer three things back to the server.
| Side | Primitive | What it is |
|---|---|---|
| Server | Tools | Functions the model can execute |
| Server | Resources | Context and data for the model or user to read |
| Server | Prompts | Templated messages and workflows for users |
| Client | Sampling | Lets the server ask the model to generate something |
| Client | Roots | Lets the server ask which URI or filesystem boundaries apply |
| Client | Elicitation | Lets the server ask the user for more information |
Tools are the ones most people mean when they say MCP. They carry a JSON schema for their arguments, so the model gets typed parameters rather than guessing at a query string. The specification is blunt that tools represent arbitrary code execution and must be treated accordingly, and that users have to approve sampling requests explicitly rather than by default.
How a session actually starts
A client connects, both sides negotiate protocol version and capabilities, and only then does the client ask what tools exist. Two transports are standard:
- stdio runs the server as a subprocess and passes newline-delimited
JSON-RPC over standard input and output. No network hop, so it is fast and local.
- Streamable HTTP POSTs and GETs against a single endpoint, optionally
streaming replies as server-sent events, with a session ID header carrying state across requests.
The practical consequence of that startup handshake is a cost most people miss. Every tool a connected server exposes sits in the model's context window for the whole session, used or not. Connect enough servers and the menu starts crowding out the work. The trade against a plain request is laid out in MCP versus plain HTTP for agent data.
What MCP deliberately does not do
MCP standardises the interface, not the commerce. There is no payment primitive, no billing, no pricing negotiation in the protocol. A server that costs money to run has to solve that somewhere else, which for us means the same wires are also plain URLs that answer with an HTTP 402 payment offer.
That is why this service ships both. All 58 wires are reachable through the remote MCP server at /mcp or locally with npx botwire-mcp, and the identical routes take a direct call at $0.005 to $0.01 per request. An agent that already speaks MCP gets discovery; an agent that found a route mid-task just calls it. The design behind an interface an agent can use with no setup at all is covered in what makes an API agent-native.
# local stdio server: discovery across every wire npx botwire-mcp # remote MCP endpoint, same wires https://thebotwire.com/mcp # the same data as a plain URL, no MCP client needed curl "https://thebotwire.com/cve/preview?q=openssl"
Setting a server up inside a desktop client, including the config file location and how to tell whether it connected, is in the MCP server connection guide.
FAQ
Is MCP made by Anthropic or is it an open standard?
Both, in sequence. Anthropic introduced and published the protocol, and the specification, schema and reference implementations are open and versioned in public. Servers and clients are written by many organisations, and a host does not need permission from anyone to implement it.
Do I need MCP to give a model access to data?
No. Any model host that can make an HTTP request can call a URL, and that path works for callers who have never configured anything. MCP earns its cost when the model should discover what a source offers on its own, and when the same source gets called repeatedly across a session.
What is the difference between an MCP server and an API?
An MCP server is usually a described wrapper over an API. The API defines what data exists and what it costs; the MCP server tells a model what is available, in what shape, with typed arguments. One is the supply, the other is the menu.
How do I know which protocol version a server speaks?
Version is agreed during initialisation, before any tool call happens. Clients send the version they support, servers reply with what they will use, and the agreed version travels on subsequent HTTP requests as a header. Mismatches fail at the handshake rather than halfway through a call.
Sources
Protocol purpose, the JSON-RPC 2.0 message format, the split between server features (tools, resources, prompts) and client features (sampling, roots, elicitation), and the security requirements around tool execution and sampling approval are defined in the Model Context Protocol specification, version 2025-11-25. Live wire count, per-call pricing and poll cadence for this service are published at thebotwire.com/health.
Related: MCP vs plain HTTP for connecting agents to data · How do I connect an MCP server to Claude Desktop?