MCP Explained: How the Model Context Protocol Works

The Model Context Protocol (MCP) gives AI applications a standard way to discover context and call tools exposed by external systems. It can connect a coding assistant to a repository, a project agent to a live board, or an internal assistant to approved company data.

MCP solves an integration problem. It does not make every client equally capable, grant permissions automatically, or make an untrusted server safe.

What Is MCP?

MCP is an open protocol for exchanging context and actions between AI applications and external systems. A server describes what it can expose. A host application connects to that server, negotiates supported capabilities, and decides how those capabilities appear in its user or agent experience.

The familiar “USB for AI” analogy is useful but incomplete. A physical connector does not need to decide who may read a document, whether a write requires approval, or how a tool result reaches a model. A production MCP integration does.

The official MCP architecture documentation distinguishes three roles:

• Host — the AI application that manages the experience, security boundaries, and one or more MCP clients;
• Client — the protocol component inside the host that maintains a connection to one server;
• Server — the program or service that exposes capabilities and handles requests.

The model itself is not the MCP client. The host decides when model output should lead to a tool call and how the result is presented or fed back into the conversation.

The Capabilities Exposed by MCP

Servers can expose three main primitives:

• Tools — operations the host may invoke, such as creating a card, querying a database, or posting a comment;
• Resources — addressable context the host may read, such as a project document or repository file;
• Prompts — reusable prompt templates offered by the server.

Clients can also advertise capabilities such as roots, sampling, or elicitation. Support is negotiated during initialization, so a server should not assume that every host implements every feature.

In practice, many integrations focus on tools. A useful tool definition includes a clear name, a precise description, an input schema, and predictable errors. The server must still authorize every call; tool discovery is not permission to execute everything.

How an MCP Connection Works

A typical session follows this sequence:

1. The host opens a connection through an MCP client.
2. Client and server negotiate protocol versions and capabilities.
3. The client discovers the tools, resources, and prompts available to that identity.
4. The host decides what context to request or which tool to call.
5. The server validates identity, permissions, and input before execution.
6. The result or structured error returns to the host.

MCP standardizes the exchange, not the host's decision-making. One client may ask for confirmation before every write. Another may rely on server-side approval policy. A third may not expose a particular primitive at all.

Transports: Local and Remote

The current protocol architecture documents two standard transports:

• stdio, where a host starts a local server process and exchanges messages through standard input and output;
• Streamable HTTP, where a client connects to a remote HTTP endpoint.

Transport choice affects deployment and authentication. A local stdio server inherits risks from the machine on which it runs. A remote HTTP server needs secure authentication, authorization, network controls, and careful handling of credentials.

The older HTTP+SSE transport may still appear in existing integrations, but new implementations should follow the current specification and the requirements of their target clients.

Why MCP Matters

A shared integration surface

Without a protocol, each AI host and business system needs a bespoke contract. MCP gives server developers and client developers a shared vocabulary for discovery, schemas, calls, results, and errors.

That can reduce duplicate integration work. It does not eliminate client-specific testing: authentication formats, transports, supported primitives, and approval experiences still vary.

Live, scoped context

An agent is more useful when it can retrieve the current project state instead of relying on copied text. MCP can expose live context while keeping the source system responsible for access control.

Good servers expose the smallest useful context. They do not return an entire workspace when a card, document, or project-scoped query is sufficient.

Governed actions

MCP tools can turn an assistant into an operational participant. That makes identity and policy more important, not less. Before a write reaches the system of record, the server can check project access, scopes, agent rules, and approval requirements.

More choice, not automatic portability

MCP can make it easier to connect several compatible clients to the same server. It can also reduce dependence on a proprietary tool-calling format. But switching clients is not guaranteed to be frictionless: capability support, configuration, authentication, context limits, and interface behavior may differ.

MCP in Project Work

A project-management server can expose a focused set of capabilities:

• read project, card, dependency, document, and decision context;
• create or update work within a defined project scope;
• surface blocked items, pending approvals, and delivery signals;
• let a dedicated agent claim a mission and report its result;
• connect approved workspace plugins without giving the model unrestricted system access.

In Stellary, for example, the same MCP endpoint can serve an interactive human client or a dedicated workspace agent. Their available tools and write behavior differ because identity, permissions, scopes, and autonomy policy are enforced by the server. See the Stellary MCP reference for the current implementation.

Security Questions to Ask Before Connecting a Server

Treat an MCP server as software that can read data or perform actions, not as a harmless prompt library.

Before enabling one, verify:

1. Who operates the server? Review its publisher, source, and deployment path.
2. What data can it access? Prefer narrow project or resource scopes.
3. Which actions can it perform? Separate reads from writes and consequential operations.
4. Where is approval enforced? Client confirmation helps; server-side policy protects every client.
5. What is logged? Record the actor, tool, inputs, outcome, error, and approval decision where appropriate.
6. How are tokens stored and revoked? Use separate credentials for separate clients or agents.

Descriptions and tool outputs are untrusted inputs. Hosts and servers should account for prompt injection, malicious content, excessive permissions, and data returned from third-party systems.

Getting Started

As a user:

1. confirm that your chosen client supports the server's transport and authentication method;
2. create a narrow, revocable credential;
3. connect the server and inspect the discovered tools;
4. test read-only calls against a non-critical project;
5. add writes gradually, with approvals for high-impact actions.

As a server developer, start with the official MCP documentation, implement the current specification through an official SDK where practical, and test each target host instead of treating “MCP compatible” as a complete compatibility matrix.

To connect an AI client to Stellary, follow the updated MCP integration guide.