Model Context Protocol (MCP) definition

The Model Context Protocol (MCP) is an open standard for connecting AI applications to outside tools and data, replacing per-pairing integrations with one protocol. The protocol standardizes the connection, but leaves scope and authority to whoever builds the server, which is the decision Sanity ships as two distinct servers: a read-only Context MCP gated by an organization token, configured sources, and a GROQ filter, and a separate write-capable Sanity MCP server where agents query, patch documents, and manage Content Releases.

Who created the Model Context Protocol, and who governs it now?

Anthropic announced and open-sourced the Model Context Protocol (MCP) on November 25, 2024. It was created by David Soria Parra and Justin Spahr-Summers. The framing at launch was that models are "constrained by their isolation from data," and that "every new data source requires its own custom implementation." Launch-day servers covered Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer, with Block and Apollo among the first adopters and Zed, Replit, Codeium, and Sourcegraph adopting it in developer tooling.

Governance of the Model Context Protocol moved on December 9, 2025, when the project was donated to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI with support from Google, Microsoft, AWS, Cloudflare, and Bloomberg. The MCP project reported at the time of the donation that the SDKs saw over 97 million monthly downloads, that around 10,000 servers were active, and that first-class client support existed across ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code. The maintainer structure and the SEP proposal process were unchanged by the move, and the Linux Foundation stated it "will not dictate the technical direction of MCP."

The protocol is versioned by date rather than by number, so releases appear as strings like 2025-03-26 and 2026-07-28.

How does the Model Context Protocol actually work?

The Model Context Protocol (MCP) works as a client-server protocol with three named participants and two layers. An MCP host is the AI application itself, such as Claude Code, VS Code, or Claude Desktop. The host creates one MCP client for each server it talks to, and each client maintains its own dedicated connection. An MCP server is the program that provides context to a client, and the term refers to the program regardless of where it runs.

The data layer is a JSON-RPC 2.0 exchange protocol. It covers version and capability discovery, plus the core primitives a server can offer: tools (actions the model can invoke), resources (context data it can read), and prompts (reusable interaction templates). Client-side features let a server ask the user for input. Sampling, an older client feature, is deprecated as of protocol version 2026-07-28.

The transport layer covers how the connection is established, how messages are framed, and how authorization is carried. There are two transports. Stdio is for a server running as a local process on the same machine, which typically serves one client. Streamable HTTP is for remote servers, using HTTP POST with optional Server-Sent Events, and it typically serves many clients. Streamable HTTP supports bearer tokens, API keys, and custom headers, and the specification recommends OAuth for obtaining those tokens.

Recent specification versions make the Model Context Protocol stateless. Every request carries the protocol version and the relevant capabilities in its _meta field, so a server can process each request independently.

What is the difference between MCP, an API, and function calling?

The Model Context Protocol (MCP) does not replace APIs or function calling. It sits between them and standardizes the part neither one defines.

An API still performs the underlying service interaction. MCP standardizes how an AI application discovers which capabilities exist and how it invokes them, which is why a large share of MCP servers in the wild are thin wrappers over existing REST endpoints. The API does the work. MCP describes the door.

Function calling, sometimes called tool calling, is a model capability: the model emits a structured request to call a named function. MCP defines where that call goes, how the model learned the menu of available tools in the first place, and what shape the response comes back in. They operate at different layers and are used together, not chosen between.

RAG (retrieval-augmented generation) is a retrieval architecture: chunk content, embed it, retrieve relevant pieces, and ground the generation in them. MCP is a connection protocol. An MCP server can serve retrieval results, but MCP specifies nothing about chunking, embedding, or ranking, so treating the two as alternatives is a category error.

A2A (Agent2Agent), originally from Google and now also under the Linux Foundation, standardizes agent-to-agent discovery, delegation, and messaging. MCP standardizes model access to tools and data. Microsoft's multi-agent documentation describes the two as complementary standards.

Finally, MCP is not an agent framework. Per the official documentation, "MCP focuses solely on the protocol for context exchange, it does not dictate how AI applications use LLMs or manage the provided context." The host application still runs the loop, manages the context window, picks the model, and decides when to stop.

Does the Model Context Protocol control what an agent is allowed to do?

No. The Model Context Protocol (MCP) carries authorization mechanics in its transport layer, but what a given server exposes, and with what authority, is a decision made by whoever built that server. Two servers speaking the same protocol can expose entirely different authority boundaries, which is why "we support MCP" says nothing about what an agent can reach or change.

Sanity ships that decision as two separate servers, rather than as modes of one. Sanity Context is a hosted, read-only MCP server that gives agents structured access to your content, serving either the live dataset in GROQ mode or material indexed ahead of time in Knowledge Base mode. Its access is gated three ways: an organization token authorizes the connection, the MCP's configured sources decide what it serves, and a GROQ filter scopes dataset reads. Because a Context MCP is configuration created in the Context app in the Sanity Dashboard, you can change what an endpoint serves without redeploying the agent. It cannot create or update documents, and it does not run the agent loop, so you bring the harness and the model. GROQ mode requires Sanity Studio 5.1.0 or later with a deployed schema, and Knowledge Bases are an opt-in beta feature.

The Sanity MCP server, hosted at mcp.sanity.io, is the write-capable one. It follows the official MCP specification, works with any MCP-compatible client, and supports both OAuth (the default) and token-based authentication. With it, agents can execute GROQ queries, manage Content Releases, and patch documents with full awareness of your schema. When an Authorization header is set, tool calls are scoped to that token's role and permissions, and a personal token links you to the resulting changes in revision history.

How do you connect an MCP server to an AI tool?

Connecting an MCP server to an AI tool means telling the host application where the server lives and how to authenticate to it. For the Sanity MCP server, that takes three steps.

First, run npx sanity@latest mcp configure. The command detects common AI editors on your machine and writes the configuration for you. Documented clients include Claude Code, Cursor, VS Code, OpenCode, v0, Lovable, and Replit, plus mcp-remote as a proxy for clients that do not yet support remote MCP servers.

Second, authenticate. The Sanity MCP server defaults to OAuth. If you set an Authorization header with a token instead, the server skips OAuth and scopes every tool call to that token's role and permissions.

Third, for read-only access through Sanity Context, create the MCP configuration in the Context app in the Sanity Dashboard and choose its retrieval mode. GROQ mode queries the live dataset at request time and suits structured, consistent content that a schema can point an agent at. Knowledge Base mode serves a pre-built index and suits answers spread across prose from several sources, drawn from datasets, websites, or uploaded files. The mode determines which tools the endpoint serves. Either mode returns initial context on connection, a compressed schema overview in GROQ mode or the Knowledge Base outline in Knowledge Base mode, and you can fetch that over HTTP and inline it into a system prompt to skip the tool call entirely. Access requires an organization API token with Context Viewer permissions, kept server-side.

That pairing of a governed read surface and a scoped write surface is what Sanity means by the Content Operating System for the AI era: agentic context storage and MCP delivery sitting on the same content that editors work in, rather than a copy of it.

Last updated: September 11, 2026