What is MCP? A builder's guide to the Model Context Protocol

By Elia KuratliUpdated September 28, 20268 min read

MCP, the Model Context Protocol, is an open standard for connecting AI models and agents to external tools and data through one interface. Anthropic introduced it in November 2024 and donated it to the Linux Foundation's Agentic AI Foundation in December 2025. A host speaks MCP once and can reach any MCP server.

I ship an MCP server: heydecks exposes deck-building tools that Claude, ChatGPT, Cursor, and other agents call directly. So I explain MCP a lot, usually to people who have heard the acronym many times and never got a clean definition. This is that explanation for builders, updated for the 2026-07-28 revision of the spec, which changed more than any release since launch.

One note on the acronym: in software, MCP now almost always means the Model Context Protocol. It stands for unrelated things in medicine and elsewhere, which this post does not cover.

#What does MCP stand for?

MCP stands for Model Context Protocol. It defines how an AI application discovers what a tool can do, calls it, and reads back the result. "Context" is the important word: a model only knows its training data plus what is in the prompt. It cannot see your files, your database, or last night's deploy unless something hands them over. MCP is the standard way to hand them over, and to let the model act on what it finds.

The protocol is governed in the open. Since December 2025 it sits in the Agentic AI Foundation, a Linux Foundation fund co-founded by Anthropic, Block, and OpenAI, while the MCP maintainers keep control of the technical direction through a public proposal process (SEPs).

#What problem does MCP solve?

Before MCP, every AI app needed a custom integration for every tool. Ten apps times ten tools meant a hundred connectors. MCP turns that M times N problem into M plus N: each app implements MCP once, each tool ships one server, and they interoperate.

The usual analogy is a USB-C port for AI: one connector shape, so any compliant host plugs into any compliant server. That is what changed my own work. I do not need Cursor, Claude, and every other client to build a heydecks integration. I run one server and they can all use it.

#How does MCP work? Hosts, clients, and servers

MCP uses a client-server model with three roles. The host is the AI app you use, such as Claude, ChatGPT, or Cursor. Inside it runs a client, one per connection. The client talks to a server, a separate program that exposes capabilities. Messages are JSON-RPC 2.0.

There are two standard 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 use Streamable HTTP. The older HTTP plus SSE transport is formally deprecated. heydecks is a remote server, so one URL works for anyone, with OAuth or a token.

PieceWhat it isExample
HostThe AI app a person uses; holds the model and manages connectionsClaude, ChatGPT, Cursor
ClientA connector inside the host, one per serverthe client Cursor opens to reach heydecks
ServerA program that exposes capabilities over MCPthe heydecks server at heydecks.com/mcp
ToolAn action the model decides to callcreate_deck, publish_deck
ResourceData the host or model can read as contexta file, a database row
PromptA template a user invokes on purposea saved "summarize this repo" command

Read it top to bottom: host contains client, client connects to server, server offers tools, resources, and prompts.

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

These are the three things a server can offer, and the useful distinction is who pulls the trigger. Tools are model-controlled: the AI decides when to call create_deck. Resources are context and data the app or the model reads. Prompts are user-controlled templates a person picks by name.

Tools are what most people mean by MCP. A tool is a named action with a JSON Schema for its inputs. When I add a tool to heydecks, I write its name, purpose, and fields; the model reads the schema and works out the arguments.

Clients can offer features back to servers too. The one that matters in 2026 is elicitation, where a server asks the user for missing information mid-task. Roots, sampling, and logging were deprecated in the 2026-07-28 spec, with at least a twelve-month window before removal.

#What changed in the 2026 MCP spec?

The 2026-07-28 revision made the protocol stateless. The main changes, per the MCP project's own release post:

  • No initialize handshake and no sessions. Each request carries its protocol version and client capabilities, and the Mcp-Session-Id header is gone. A server can sit behind a plain load balancer.
  • server/discover. Servers must implement it to advertise versions, capabilities, and identity. Clients can call it first or skip it.
  • Multi round-trip requests. When a server needs more input, it returns an input_required result and the client retries with the answer, replacing server-initiated requests.
  • Extensions. Optional features ship as opt-in extensions, including Tasks (long-running jobs with polling), MCP Apps (interactive UI inside the chat), and Enterprise Managed Authorization.
  • Authorization hardening. Issuer validation per RFC 9207, and Client ID Metadata Documents preferred over dynamic client registration, which is now deprecated but still works.
  • Legacy transport deprecated. The old HTTP plus SSE transport is formally deprecated, with a one-year transition.

If you run a server, the practical effect is simpler scaling. If you only use servers, you will not notice much, except that remote servers get more reliable.

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

Here is the path for an agent building a deck through heydecks:

  1. You connect the server once. The host opens a browser, you sign in, and it stores a scoped token.
  2. The client learns what the server offers, by listing its tools (and, on the 2026 spec, optionally calling server/discover). heydecks answers with its tools and their input schemas.
  3. You type: "Build a six-slide launch deck for our June release and publish it."
  4. The model picks tools. It calls list_slide_templates to learn the slide shapes, writes the content itself, then calls create_deck and add_slides.
  5. Each call goes host to client to server as a JSON-RPC request. heydecks runs it as you, in your workspace, on your brand.
  6. The model calls publish_deck and gets a live URL at /d/<slug>, then export_deck for a PDF or editable PowerPoint download link.

Step one is the only manual part. In Claude Code it is one line:

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

In Cursor, point it at the URL and it runs the sign-in:

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

Setup for every Claude app, including claude.ai custom connectors, is in Claude MCP setup and the MCP docs.

Here is the kind of launch deck that request produces, rendered on a sample brand:

1 / 9
A live deck built with heydecks: Product Launch.Open the full deck

#How is MCP different from an API?

An API is a fixed contract a developer reads and wires in by hand, endpoint by endpoint. MCP sits a layer above, built for models: a server describes its tools and schemas, and the model discovers and calls them at runtime with no per-endpoint glue.

They are not rivals. An MCP server usually calls the same API it wraps. heydecks is an example: one backend powers a REST API for code and a hosted MCP server for agents. A script calls POST /v1/generate directly; Claude in a conversation discovers the tools over MCP and decides which to call.

#What should you watch out for with MCP?

Trust. Connecting a server grants it real capability: it can read data, call external APIs, and spend money. A heydecks deck costs credits, and a careless server could do worse. The spec itself says tool descriptions from untrusted servers should be treated as untrusted and that hosts must get user consent before invoking tools. A compromised server can also return text designed to steer the model, the same prompt-injection risk you have anywhere a model reads untrusted content.

So treat a server like a dependency you install. Prefer servers published by the vendor they wrap, use scoped tokens you can revoke, and read what a server asks for before you connect it. My list of the best MCP servers sticks to ones with clear owners.

If you want to see a working server from the client side, connect the heydecks MCP server and ask your agent for a deck: it is the quickest way to watch tools, schemas, and OAuth do their jobs.

#Frequently asked questions

#Who owns MCP now?

The Agentic AI Foundation, a directed fund under the Linux Foundation, since Anthropic donated MCP in December 2025. The project's maintainers still run its technical direction through public spec proposals.

#Is MCP just JSON?

No. The wire format is JSON-RPC 2.0, but MCP is the agreement on top: how servers describe tools, resources, and prompts, how clients call them, and how auth works. JSON is the envelope.

#Does ChatGPT use MCP?

Yes. OpenAI added MCP support in 2025 and co-founded the Agentic AI Foundation that now hosts it. Claude, ChatGPT, Cursor, Gemini, Microsoft Copilot, and VS Code can all connect to the same server.

#What is an MCP server?

A program that exposes tools, resources, or prompts to AI clients over MCP, either locally over stdio or remotely over Streamable HTTP. heydecks runs one at heydecks.com/mcp with tools for building, publishing, and exporting decks.

#Is MCP the same as RAG?

No. RAG retrieves text chunks and adds them to the prompt. MCP is a connection standard that lets a model call live tools and fetch current data. An MCP server can feed a RAG pipeline, but they solve different problems.

Keep reading

What is MCP? Model Context Protocol explained (2026)