MCP, short for Model Context Protocol, is an open standard from Anthropic, introduced in November 2024, that lets AI models and agents connect to external tools and data through one consistent interface. Instead of a custom integration per model and per tool, a model speaks MCP once and can reach any MCP server.

I ship an MCP server. heydecks exposes a set of deck-building tools that Claude and other agents call directly, so I spend a lot of my week explaining what MCP actually is to people who keep hearing the acronym without ever getting a clean definition. This is that explanation, written for builders. What MCP is, the problem it fixes, how the pieces fit together, and a real call you can run today.

One housekeeping note before the definition, because the acronym is overloaded. In software, MCP almost always means the Model Context Protocol now; the search results for the term are dominated by it. It also stands for unrelated things in medicine and elsewhere, but if you landed here from an AI or developer context, the protocol is what you want. That is the only meaning I cover below.

#What does MCP stand for?

MCP stands for Model Context Protocol. It is an open standard that defines how an AI application talks to external systems: how it discovers what a tool can do, calls that tool, and reads back the result. Anthropic published the spec and open-sourced the SDKs in late 2024, and the protocol is now governed in the open rather than as one company's internal API.

The word "context" is doing real work in that name. A language model only knows what was in its training data plus whatever you put in the prompt. It cannot see your files, your database, or last night's deploy unless something hands that information over. MCP is the standardized way to hand it over, and to let the model act on what it finds.

#What problem does MCP solve?

Before MCP, every AI app needed a custom integration for every tool it wanted to reach. Ten models times ten tools meant a hundred bespoke connectors, an M times N problem that nobody could keep up with. MCP turns that into M plus N: each model speaks MCP once, each tool exposes one MCP server, and they all interoperate without per-pair glue.

The analogy that stuck, and the one Anthropic itself uses, is USB-C for AI. Before USB-C you had a drawer of cables, one shape per device. A single port replaced the drawer. MCP is the same move for AI integrations: one connector shape, so any compliant host can plug into any compliant server. Build the server once and every MCP-aware app can use it, instead of waiting for each app to bless your tool with a one-off plugin.

That is the part that changed my own work. I do not have to convince Cursor, Claude Desktop, and a dozen other clients to each build a heydecks integration. I run one server, and they can all talk to it.

#How does MCP work? The host, client, and server

MCP uses a client-server model with three roles. The host is the AI app you actually use, something like Claude Desktop or Cursor. Inside it runs a client, one per connection. The client talks to a server, a separate program that exposes tools and data. Messages travel as JSON-RPC 2.0, a plain request-and-response format.

There are two common transports. Local servers usually run over stdio: the host launches the server as a subprocess and they exchange JSON over standard input and output. Remote servers run over streamable HTTP, where the client sends requests across the network. heydecks is a remote HTTP server, so the same endpoint works for anyone, anywhere, with a token or an OAuth sign-in.

Here is every moving part in one place, so the vocabulary stops being slippery.

Read the table top to bottom and the structure falls out: host contains client, client connects to server, server offers tools, resources, and prompts.

#What are tools, resources, and prompts in MCP?

An MCP server exposes three kinds of capability, and the useful distinction is who controls each one. Tools are model-controlled: the AI decides when to call write_file or create_deck. Resources are app-controlled, read-only data the host pulls in as context, like a file or a record. Prompts are user-controlled templates a person invokes by name. That split decides who pulls each trigger.

Tools are the ones most people mean when they say MCP. A tool is a named action with a typed input schema, and the model reads that schema to learn what arguments to send. When I add a tool to heydecks, I describe its name, its purpose, and its fields; the model figures out the rest. Resources and prompts get less attention but matter for the same reason a good API has both reads and writes. Resources give the model fresh context to reason over. Prompts give a human a one-word way to kick off a known workflow without retyping instructions.

#How does an MCP request flow, step by step?

A request flows from the host to the model to the server and back, as a sequence of JSON-RPC calls. Nothing about it is exotic; the protocol is mostly a disciplined way to list capabilities and pass typed calls. Here is the end-to-end path for an agent building a deck through the heydecks server, which is the example I know best because I wrote it.

1. You connect the server once. In Cursor that is a few lines of config; in Claude Code it is a single command. The host opens a browser, you sign in, and the connection is live.
2. On startup the host's MCP client runs the initialize handshake and asks the server what it offers. heydecks answers with its tool list and each tool's input schema.
3. You type a plain request: "Build a six-slide launch deck for our June release and publish it."
4. The model picks tools to match. It calls list_slide_templates to learn the slide shapes, writes the slide content itself, then calls create_deck and add_slides.
5. Each call travels host to client to server as a JSON-RPC request. heydecks runs it as you, in your workspace, on your brand, and returns the result.
6. The model calls publish_deck. The server returns a live URL at /d/<slug>, and heydecks renders a PDF and a native, editable PowerPoint from the same deck.

The connection in step one is the only manual part. For Claude Code it is one line:

claude mcp add --transport http heydecks https://heydecks.com/mcp

For an editor like Cursor, you point it at the remote server and it runs the sign-in for you:

{ "mcpServers": { "heydecks": { "url": "https://heydecks.com/mcp" } } }

After that, the agent does the discovery and the calls on its own. The first request opens a browser to authorize heydecks over OAuth, the server issues a scoped token tied to your account, and every later call reuses it. There is also a CLI, npx heydecks install, that wires up Claude Desktop, Claude Code, and Cursor in one command.

#How is MCP different from an API?

An API is a fixed contract you write code against: a developer reads the docs and wires each endpoint in by hand. MCP sits a layer above, built for models. A server advertises its tools and their schemas, and the model discovers and calls them at runtime, with no per-endpoint glue. The same question shows up constantly in search results, and that is the honest answer.

The two are not rivals. Under the hood, an MCP server usually calls the very APIs it wraps. heydecks is a clean example: the same backend powers a REST API for code and a hosted MCP server for agents. If you are writing a script, you hit the REST endpoint directly. If you want Claude to build a deck in conversation, it discovers the tools over MCP and decides which to call. One is for developers who know exactly what they want; the other is for a model figuring it out on the fly. For a deeper look at the agent side, I wrote a whole piece on how to connect Claude to an MCP server.

#Why does MCP matter now, and what should you watch out for?

MCP matters now because it stopped being one vendor's idea. Anthropic open-sourced it in late 2024, and within months the major IDEs and other model makers added support, including OpenAI in 2025. A tool that ships one MCP server is reachable from every host that speaks the standard, which is why the directory of available servers keeps growing; I keep a running list of the best MCP servers worth connecting.

Now the honest part, because the hype skips it. When you connect a server, you grant it real capability. An MCP tool can read your files, hit external APIs, and spend money; a heydecks deck costs credits, and a less careful server could do worse. So trust matters the way it does with any dependency. Run servers you can vet, prefer scoped tokens you can revoke, and remember that a malicious or compromised server can return content designed to steer the model, the same prompt-injection risk you have anywhere a model reads untrusted text. The protocol is also young and still arguing with itself about things like statefulness, so expect the spec to keep moving. None of that is a reason to avoid MCP. It is a reason to treat an MCP server like code you are installing, because that is what it is.

Here is a deck heydecks built from a single URL, rendered on a sample brand. The same flow runs over the MCP server an agent connects to.

Want an agent to build decks for you? Connect the hosted MCP server, call the REST API from your own code, or read the docs to wire it up. If you are coming from the slide side, this is also how Claude can build a PowerPoint end to end.

#Frequently asked questions

#Is MCP just JSON?

No. The wire format is JSON-RPC 2.0, but MCP is the specification around it: how a client and server announce themselves, list capabilities, and exchange tool calls and results. JSON is the envelope. The protocol is the agreement about what goes inside and what the two sides are allowed to ask each other.

#Does ChatGPT use MCP?

Yes. OpenAI added support for MCP across its products in 2025, so the protocol is no longer Anthropic-only. That is the whole point of a standard: ChatGPT, Claude, Cursor, and many other hosts can all connect to the same server. Build one MCP server and these clients can use it without separate integrations.

#What is an MCP server?

An MCP server is a program that exposes a set of capabilities, its tools, resources, and prompts, to AI clients over the protocol. It can run locally over stdio or remotely over HTTP. heydecks runs one at heydecks.com/mcp that exposes deck-building tools an agent can discover and call.

#Is MCP the same as RAG?

No. RAG, retrieval-augmented generation, fetches text chunks and stuffs them into the prompt as context. MCP is a connection standard that lets a model call live tools and pull current data at runtime. You can use an MCP server to feed a RAG pipeline, but they solve different problems: one retrieves text, the other wires the model to systems it can act on.