What Is the Model Context Protocol (MCP)? A Plain-English Guide

By Mark Kuhn · April 30, 2026 · 8 min read

MCP is the open standard that lets AI agents call your APIs. Here's what it actually is, how a client and server talk, and where it fits — without the jargon.

If you've spent any time around AI tools lately, you've probably run into three letters that keep showing up: MCP. It's in Claude's settings, in Cursor's docs, in half the "look what I built" posts on your feed. And like a lot of fast-moving tech, the explanations tend to be either one sentence that tells you nothing or a spec document that assumes you already know the answer.

Here's the short version. The Model Context Protocol (MCP) is an open standard for connecting AI assistants to outside tools and data. An MCP server exposes a set of named tools — think of them as functions the AI is allowed to call. An MCP client (Claude Desktop, Cursor, and a growing list of others) discovers those tools and lets the model use them during a conversation. That's the whole idea: a common plug so any compliant AI can talk to any compliant tool, without a bespoke integration for every pair.

The rest of this post is the longer version — how it works, why it exists, and where something like API2MCP fits in.

Why we needed a protocol at all

Rewind a couple of years. If you wanted an AI model to do something in the real world — check a database, hit an API, read a file — you wrote glue. Custom function-calling schemas for one model, a different plugin format for another, a webhook here, a wrapper there. Every tool-and-model combination was its own little integration project, and none of it transferred.

That's the problem MCP set out to kill. Anthropic introduced it as an open standard in late 2024, and the framing was deliberately unglamorous: it's "a USB-C port for AI applications." Not the most exciting metaphor, but it's accurate. Before USB, every device had its own connector and you kept a drawer full of cables. MCP is the attempt to standardize the connector so the drawer goes away.

The important word is open. MCP isn't a Claude feature — it's a published spec anyone can implement, on either side. Build a server once and every MCP-capable client can use it. Build a client and it can reach every MCP server out there. That two-sided network effect is why the ecosystem grew fast, and it's why you're seeing the acronym everywhere.

The three concepts you actually need

You can understand MCP with three words: host, client, and server. People blur them together constantly, so let's keep them straight.

Host — the application the human is using. Claude Desktop, Cursor, Windsurf, the Claude mobile app. It's where the model lives and where you type.
Client — the connector inside the host that speaks MCP. One host manages one client connection per server. In practice you'll hear "client" and "host" used interchangeably; the distinction only matters when you're building one.
Server — the thing on the other end that actually does something. It advertises a list of tools and handles the calls. A weather server, a GitHub server, a server that wraps your company's internal API.

The flow between them is refreshingly boring, which is a compliment. When the host connects to a server, the first thing it does is ask "what can you do?" The server replies with a list of tools, each with a name, a human-readable description, and a JSON schema describing its inputs. The model reads those descriptions, decides a tool is relevant to what you asked, and the client sends a structured call. The server runs it and sends back a result. The model folds that result into its answer.

Nobody hand-writes the tool call. You ask Claude a question in plain English; the model picks the tool and fills in the arguments from the schema. That's the part that feels like magic the first time, and it's really just the model matching your intent to a well-described function.

Tools, resources, and prompts

Tools get all the attention, but the spec defines three kinds of things a server can offer, and it's worth knowing the difference.

Tools are actions — functions the model can invoke. get_weather, create_issue, search_customers. This is 90% of what people build and use.

Resources are data the server makes available for context — a file, a record, a document the model can read but not necessarily act on. Think of them as read-only context the host can pull in.

Prompts are reusable, server-defined templates — canned instructions a user can trigger, often surfaced as slash commands in the host. A support server might ship a /triage-ticket prompt that sets up the model with the right framing.

Most servers start and end with tools. Resources and prompts are there when you need richer behavior, and you can happily ignore them until you do.

A concrete example

Abstractions are slippery, so let's make it real. Say you run a weather API. It has an endpoint like GET /v1/current?city=... that returns a temperature and conditions.

Wrapped as an MCP server, that endpoint becomes a tool the model sees roughly like this:

{
  "name": "get_current_weather",
  "description": "Get the current weather for a city.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "city": { "type": "string", "description": "City name, e.g. 'Denver'" }
    },
    "required": ["city"]
  }
}

Now you type into Claude: "What's the weather in New York right now?" The model reads that description, recognizes it's a match, and issues a call with { "city": "New York" }. The server turns that into the real HTTP request to your API, gets { "temp": 71, "conditions": "Partly cloudy" } back, and hands it to the model. Claude answers: "It's 71°F and partly cloudy in New York."

You never wrote a request. You never touched the schema. You asked a question and the protocol handled the plumbing.

Where the credentials go (and why it matters)

Here's the question that should be on your mind if you're thinking about exposing a real API: where do my API keys live?

This is the part people get wrong when they hand-roll integrations, and it's the part MCP handles cleanly when you do it right. The credential belongs on the server side, not with the model. The AI calls a tool; the server holds the API key and attaches it to the upstream request. The model sees the tool and the response — never the secret.

That separation is the whole security story in one sentence, and it's non-negotiable for anything beyond a toy. A model that can see your production API key is a model that can leak it into a log, a transcript, or an answer. A model that can only invoke a tool can't leak what it never had. When we built API2MCP, this was the first principle everything else hung off of: keys are encrypted at rest and injected server-side on every call, so the AI is functionally a caller with no idea what auth even looks like.

Where API2MCP comes in

So if MCP is this clean, why isn't everyone's API already an MCP server?

Because building one is still real work. The spec is friendly, but a production server means writing the server, mapping every endpoint to a tool with a good schema, handling authentication to your upstream API, hosting the thing, keeping tokens safe, dealing with rate limits and timeouts, and updating it when your API changes. For one internal API that's a weekend. For several, it's a running maintenance cost nobody asked for.

That's the gap API2MCP fills. You point it at an API — give it the base URL, the credentials, and an OpenAPI spec (or let it discover one) — and it generates the MCP server for you. Every endpoint becomes a tool automatically. Credentials are encrypted and injected server-side. You get a hosted server URL and an access token you paste into Claude or Cursor, and you're done. No server code, no glue, no hosting to babysit.

The point isn't that MCP is hard — it's that you shouldn't have to reimplement the same wrapper for every API you own. Write it once as a spec, and let the wrapping be someone else's problem.

The mental model to walk away with

If you remember one thing, make it this: MCP standardizes how AI agents call tools, and a tool is just an API endpoint with a good description and its credentials kept server-side. Everything else — hosts, clients, resources, prompts — is detail you can pick up as you go.

The reason it matters right now is momentum. Agents are only as useful as the things they can actually touch, and MCP is quickly becoming the default way they touch anything. An API that speaks MCP is an API your customers' AI assistants can use directly. An API that doesn't is one they have to work around.

If you want to see the wrapping happen end to end, the next post walks through turning an OpenAPI spec into a working MCP server with no code — with a real spec, start to finish. Or if you'd rather just try it, the getting-started guide gets you to a live server in about five minutes.