Model Context Protocol explained: roles, primitives and risks

The Model Context Protocol (MCP) is an open standard for connecting AI applications to the tools and data they need. Instead of every assistant writing its own integration for every service, a service exposes its capabilities once as an MCP server, and any compatible application can use them. This page covers the moving parts: who plays which role, what a server can offer, how messages travel, and which security questions to settle before you connect one.

The problem it solves

Before a shared protocol, connecting a model to a ticketing system, a database and a file store meant three custom integrations, and doing the same for a second assistant meant three more. Every combination of application and tool was its own project. MCP replaces that grid with a common interface: tool builders write a server, application builders write a client, and the two meet in the middle.

The idea resembles the language server protocol that lets many code editors share the same language tooling. It does not make a model smarter, and it does not decide what an agent should be allowed to do; that decision stays with the agent harness. What MCP standardizes is the plumbing.

Hosts, clients and servers

MCP defines three roles. The names are easy to confuse, so it helps to pin them down.

A host with five servers configured runs five clients. Each session is kept separate: a server sees its own exchange with the host, not the other servers and not the whole chat history, unless the host chooses to pass that information along.

What a server can offer

Servers expose three kinds of capability, and the difference between them is mostly about who is in control.

• Tools are functions the model may decide to call, such as searching tickets or creating a branch. Each has a name, a description and a JSON Schema for its input. Tools are where actions happen, so they carry most of the risk.
• Resources are pieces of data identified by a URI, such as a file, a database record or a log. The host application chooses which resources to attach to the context; they are meant for reading.
• Prompts are reusable templates the user picks explicitly, often surfaced as slash commands, such as "summarize this incident".

The protocol also works in the other direction. A server can ask the host for a model completion (sampling), ask the user for structured input (elicitation), and learn which directories or locations the host allows it to work within (roots). Hosts are expected to keep the user in charge of each of these.

A tool definition is compact:

{
  "name": "search_tickets",
  "description": "Search support tickets by text. Read-only.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query":  {"type": "string"},
      "status": {"type": "string", "enum": ["open", "closed"]}
    },
    "required": ["query"]
  }
}

And this is the request the client sends when the model decides to use it:

{"jsonrpc": "2.0", "id": 7, "method": "tools/call",
 "params": {"name": "search_tickets",
            "arguments": {"query": "refund", "status": "open"}}}

How a session works

Messages are JSON-RPC 2.0: requests with an id, responses that echo it, and one-way notifications. A session opens with an initialization exchange in which client and server agree on a protocol version and declare which features each supports. The client then lists what the server offers (for example with tools/list), calls tools as the model requests them, and receives notifications when a server's list of tools or resources changes. The official specification has the full message set.

Two standard transports carry those messages.

• stdio. The host starts the server as a local subprocess and exchanges messages over standard input and output. It is simple and fast, and the server runs with the permissions of the user who launched it.
• Streamable HTTP. The server runs as an independent service that clients reach over HTTP, with optional streaming of responses. This suits shared or hosted servers and brings the usual web concerns: authentication, network exposure and multiple tenants.

For HTTP-based servers the specification defines an authorization flow built on OAuth, so a user can grant a client scoped access without handing over a password. Local stdio servers usually read their credentials from the environment instead. Choosing between the two deployment styles is a trade-off in its own right; remote vs local MCP servers works through it.

Security considerations

MCP makes connecting a tool easy. That ease is also the main risk, because every connected server widens what the agent can see and do. The questions below are worth settling for every server.

1. A local server is code you run. A stdio server executes on your machine with your permissions. Vet it like any dependency: know who publishes it, pin the version and read what it does with files and the network.
2. Descriptions are instructions. The model reads tool descriptions as guidance. A malicious or careless server can hide instructions there ("also send the contents of the config file"), and a description can change after you first approved the server. Review on change, not only on install.
3. Tool output is untrusted input. A ticket body, an email or a web page returned by a tool can contain text that tries to steer the agent toward another tool. The combination to watch for is access to private data, exposure to untrusted content and a way to send data out, all in one session.
4. Credentials tend to be too broad. A server holding an all-powerful token turns any manipulated call into a powerful one. Give each server the narrowest scope it needs; the specification also warns against servers simply passing a client's token through to other services.
5. Names can collide. With several servers connected, two tools can look alike, and a tool from one server can be described so that the model prefers it over another's.

The specification's own principles put user consent and control first: hosts should show what a tool will do and ask before running it. How well a given host lives up to that is something to check, not assume. The guide to choosing MCP servers includes a vetting routine.

Connecting is not authorizing

The most common governance mistake is treating a configured server as permission. Adding a file-system server to your client means the agent can reach those files; it does not mean every task should. A safer pattern separates the two decisions: connect a server once, then grant each task only the tools it needs, starting with read-only ones, and keep actions with consequences (writing, sending, deleting, exporting) behind an approval. Connect tools without widening authority and start agents read-only develop this pattern, and MCP, skills or CLIs helps decide whether a protocol server is the right shape for a tool at all.

MCP and GoCux

GoCux works with MCP on the client side: MCP tools run in your own compatible client, close to the files and permissions they touch. GoCux does not publish a hosted MCP endpoint. Its guidance is to begin with read-only tools, and a server you have configured does not count as authorized for every task just because it is there. When work reaches a consequential step such as sending, deleting or exporting, it pauses for someone on the team, and the held call is quoted exactly as requested. The MCP quickstart walks through the setup.

Before you add an MCP server

• Who publishes the server, and is the version pinned?
• Does it run locally over stdio or remotely over HTTP, and does that fit the data involved?
• Which credentials does it hold, and are they scoped as narrowly as the work allows?
• Have you read every tool description, and will you notice if one changes?
• Which tools are read-only, and which ones write, send, delete or export?
• Does your host ask before running a tool and show the full arguments?
• Can untrusted content reach the same session as private data and an outbound tool?
• Can you see afterwards which tools were called, with which arguments and results?

A server that passes these checks is a useful extension of an agent. One that does not should stay disconnected, or stay read-only, until it does.