What is the Model Context Protocol?

The Model Context Protocol is an open protocol that lets an AI application call tools and read data on any server that speaks it. Write a server for your ticket system once, and every application that supports MCP can use it.

It is not a model, an agent framework or an API for one product. It is closer to a plug standard. A model’s own tool calling says how the model asks for a tool inside one application. MCP says how that application finds the tool on another system and calls it there.

Anthropic introduced MCP in 2024. In December 2025 it donated the protocol to the Agentic AI Foundation, a fund under the Linux Foundation. The specification is versioned by date, and the current version is 2026-07-28.

MCP has three participants. The architecture overview names them:

• The host: the AI application a person uses, such as a chat assistant or a code editor.
• A client: a connection the host opens to one server. A host with three servers runs three clients.
• A server: a program that offers tools and data. It can run on the same machine, over standard input and output, or remotely over HTTP.

Messages are JSON-RPC 2.0. A client asks a server what it offers with a list request, and calls a tool with tools/call. Since the 2026-07-28 version every request carries its own protocol version and capabilities, so a server can answer each one on its own.

A server offers three kinds of things. The specification sorts them by who decides when they are used:

• Tools are functions the model decides to call: search tickets, read a part record, update a work order. Each has a name, a description and a schema for its arguments.
• Resources are data the application attaches as context: a file, a record, the schema of a database.
• Prompts are templates a person chooses, often shown as slash commands.

Tools get most of the attention, because they are how a model acts. They are also where most of the risk sits.

MCP fixes the parts every integration used to reinvent: how a client learns what a server offers, the shape of a tool’s description and arguments, the message format and the two transports. For remote servers it also defines an authorization flow based on OAuth 2.1.

That is the value. A team that wrote one connector per assistant writes one server, and each new assistant that supports MCP can use it.

The protocol carries tools and data. It does not decide what flows through it. The architecture overview says MCP “does not dictate how AI applications use LLMs or manage the provided context.” Four decisions stay with whoever builds the host and the server:

• Who may connect. The authorization specification is plain: “Authorization is OPTIONAL for MCP implementations.” When it is used, it tells the server who connected, not what that person may see.
• Which tools a user is offered. A server answers a list request with the tools available to that client. Which ones those are is the server’s decision.
• Which calls run. The specification asks hosts to get a person’s consent before invoking a tool. How a host asks, and whether it asks every time, is up to the host.
• Which records come back. A tool that reads tickets returns whatever its code returns. Whether it checks the asking person’s access, record by record, is up to the tool.

The specification says so itself: “MCP itself cannot enforce these security principles at the protocol level”.

• A service account behind the server. The server reaches the ticket system with one broad account, so everyone who can connect reads what that account reads.
• Too many tools. Every connected server adds its tool descriptions to the model’s context on every call. See what is context engineering?
• Tool results read as orders. A ticket a tool returns can carry text that reads like an instruction. That is prompt injection, and MCP passes the text through like any other.
• Descriptions taken on trust. The specification treats tool descriptions as untrusted unless they come from a trusted server, and a tool as arbitrary code. A local server runs on your machine, with your access.
• Writes with no approval. A tool that updates a work order runs as soon as the model calls it, unless the host stops to ask.

Before you connect one, six questions:

1. Who runs it, and where? Local over standard input and output, or remote over HTTP, and on whose infrastructure?
2. How does a client authenticate, and as whom does the server act: the person, or one account for everyone?
3. Does each tool check the person’s access per record, or return whatever its query finds?
4. Which tools change something, and who approves those calls before they run?
5. How large are its tool results, and do they cite the records they came from?
6. Is every call logged with its arguments and its result?

Curiosity Studio can act as an MCP server. Since July 2025 a workspace can host its AI tools over MCP, so external MCP clients can discover and call them, as the changelog records. A coding assistant or another AI application can then search and read the records Studio connects, through Studio’s AI tools.

Access control comes from Studio, not from the protocol. The documentation of the built in read tool says access control is its only boundary, over MCP as in a chat: it reads what the calling user can see. Records come from more than 70 systems, with the access rights of their source, checked per record at query time. In tools you write, the reach is yours to set: use the query scoped to the current user. The AI agents page has the developer view.

The documentation describes Studio as a server, not as a client of other MCP servers. To bring another system’s records into Studio, you connect it with a connector, or write one with the connector SDK.