JOURNAL / PROTOCOLS & AGENTS

What is MCP?
The connection layer for AI tools.

The Model Context Protocol gives AI applications a shared way to connect to tools, reusable prompts, and external context. It standardizes the connection; the application still decides what to trust and what to allow.

Ethernet connectors against a dark background, illustrating a connection between systems.PROTOCOL / CONNECTION / SYMPLOKA
THE CONNECTION IS A DESIGN CHOICE

A common connector changes how systems meet.

MCP defines a shared interface between an AI application and external services. The value is interoperability; the boundary still needs clear permissions.

01 / A SHARED LANGUAGE FOR CONNECTIONS

MCP is a protocol—not a model, agent, or guarantee.

Model Context Protocol (MCP) is an open standard for connecting AI applications to external data and tools. It gives the application and an integration a common way to exchange requests and results, instead of requiring every product to invent a different connector for every service.

An MCP server can make a service’s capabilities available to a compatible AI application. The application chooses how to present those capabilities and when to call them. MCP does not make a model more capable by itself, create permission to access every service, or decide whether an action is safe. For the model-side request and execution round trip, see how tool calling works ↗.

A protocol can make connections more consistent. It cannot make every connection trustworthy.

02 / THREE PARTS OF THE CONNECTION

Host, client, server: the roles are distinct.

The current specification describes communication between an AI host, a client connector inside that host, and a server that provides context or capabilities.

HostThe AI application the person uses, such as an assistant, editor, or custom workflow.
ClientThe connector within the host that speaks MCP and communicates with a server.
ServerThe integration that offers specific data or actions to a compatible client.
CapabilityA server may expose tools, resources, prompts, or a supported subset of these features.

A tool is an operation an application can ask the server to run. A resource provides contextual information. A prompt is a reusable message template. The protocol defines these building blocks; each server still chooses which capabilities it offers.

03 / MCP AND APIS

MCP can connect to an API; it does not replace the service.

An API defines how software interacts with a particular service. An MCP server can sit between that API and an AI host, translating the service’s operations into capabilities a compatible client can discover and use. MCP standardizes parts of the integration layer; it does not make every service expose the same tools or behave the same way.

The protocol is versioned, and supported features can differ across clients and servers. The specification published on 28 July 2026 describes stateless requests and per-request capability information. When building or troubleshooting an integration, check the actual protocol version and features both sides support; older examples may describe an earlier edition.

MCP handles an agent’s connection to tools and resources. For the separate question of how independent agents delegate work to one another, see the guide to A2A ↗.

For the broader distinction between an AI model and a system that can act, read What is an AI agent? ↗

04 / THE SECURITY BOUNDARY

Review what a server can see and what its tools can change.

An integration may read files, query a database, send a message, or change a record. Those powers come from the server and the permissions it receives, not from the words “MCP” or “AI.” Treat the server and its outputs as part of the system’s trust boundary.

Check the sourceKnow who operates the server and what software or service it connects to.
Limit permissionsGrant only the data and actions needed for the task; separate read access from write or delete access.
Review side effectsShow what will be sent or changed, and ask before actions with meaningful consequences.
Test untrusted contentDocuments and tool results can contain misleading instructions. Keep data separate from trusted policy.

The MCP specification calls for user consent and control and says implementers must handle security in their applications. It also warns that tool behavior descriptions should be treated as untrusted unless they come from a trusted server. See why agent permissions belong at the tool boundary ↗.

Authentication identifies the client or user presenting a credential; authorization decides what that identity may access. In the 2026-07-28 specification, MCP authorization is optional. For remote HTTP transports, the specification defines a flow based on the OAuth 2.1 draft; it says this flow is not intended for local stdio servers, which retrieve credentials from the environment. The new version deprecates Dynamic Client Registration (DCR) in favor of Client ID Metadata Documents, while retaining DCR for compatibility. Clients must use tokens issued for that MCP server, and servers must validate tokens for their own resource instead of accepting or forwarding unrelated tokens. Read the versioned authorization specification ↗ for the full flow.

05 / QUESTIONS PEOPLE ASK

Four quick answers.

Is MCP an AI model?No. It is a protocol that AI applications and integrations can use to communicate.
Is every MCP server safe?No. Safety depends on who runs it, what access it has, and how the host reviews its actions.
Does it replace APIs?No. An MCP server can adapt an existing API for use by compatible AI applications.
Will every client support every feature?No. Versions and optional capabilities vary. Check compatibility before relying on a feature.
CURRENT SPECIFICATION, AUTHORIZATION & PROJECTModel Context Protocol specification, 2026-07-28 ↗MCP authorization specification, 2026-07-28 ↗Maintainers’ notes on the 2026 specification release ↗Official MCP project on GitHub ↗