What Is the Model Context Protocol (MCP)?

The Model Context Protocol (MCP) is an open protocol that standardizes how AI applications connect to external systems so they can discover and use tools, retrieve contextual resources and apply reusable prompts through defined client-server messages.

Without a common protocol, every AI application needs custom code for each file store, database, development platform or business service. MCP defines shared roles and messages, allowing compatible hosts and servers to connect without designing a new interface for every pairing.

The protocol operates between an AI host and external capabilities. It does not define the language model, decide which tool is safe, grant business authorization or determine how retrieved context influences a model. Those responsibilities remain with the host, server and surrounding identity, data and policy systems.

This boundary matters on employee endpoints. A local MCP server may read files or invoke programs with the permissions of its process, while a remote server may reach cloud data and APIs. Agentic AI security therefore treats an MCP connection as one part of a larger chain of identity, permissions, data access, logging and containment.

Why the Model Context Protocol exists

AI applications need more than a model to complete many useful tasks. A coding assistant may need repository files and an issue tracker. A workplace assistant may need a calendar, a document store and permission to create a draft. Each external system has its own API, authentication model and data representation.

MCP creates a common integration layer between the AI application and those systems. A host can connect to several compatible servers, learn what each server offers and exchange structured requests and results. The server remains responsible for translating the MCP operation into a local file action, database query or downstream API request.

How MCP architecture works

MCP uses a host-client-server architecture. The official MCP architecture defines a JSON-RPC-based data layer for messages and a transport layer for carrying them locally or over a network.

MCP host

The host is the AI application a person or another system interacts with. It coordinates the model, user experience, permissions, available integrations and multiple MCP connections. An integrated development environment, desktop assistant or enterprise agent runtime can act as a host.

The host is not the same as an MCP client. A host may manage a separate client for each server, then combine the discovered capabilities in one application experience.

MCP client

An MCP client is the protocol component inside the host that communicates with one MCP server. It sends requests, receives results and handles the capabilities used on that connection. A project-files server and calendar server therefore have distinct protocol relationships even when one assistant presents them together.

MCP server

An MCP server is a program that exposes capabilities through MCP. It may run as a local process on the same endpoint as the host or as a remote service reached over a network. “Server” describes its protocol role, not its physical location.

A server can expose three main server-side primitives:

• Tools are schema-defined operations the AI application can request, such as searching a repository or creating a ticket.
• Resources provide contextual data, such as file contents, database schemas or application records.
• Prompts provide reusable message templates or workflows that a user or host can select.

The server implements these capabilities. It need not contain a model or offer all three primitives.

Data and transport layers

The data layer defines request, response and notification semantics using JSON-RPC 2.0. The transport layer carries those messages, commonly over standard input and output for local processes or Streamable HTTP for remote integrations. Transport choice changes authentication and network exposure, not the participant roles.

The MCP request flow

A typical MCP tool flow has six stages.

1. Configure the connection. The host is given an approved local server command or remote server endpoint and the settings needed to connect.
2. Exchange metadata. The client and server communicate protocol version, identity and supported capabilities, either through discovery or request metadata.
3. Discover capabilities. The client requests a list of available tools, resources or prompts and receives names, descriptions and schemas.
4. Select an operation. The host or model proposes a tool call or resource request based on the user’s task and available capabilities.
5. Authorize and execute. The host applies user-control and policy checks; the server validates the request and invokes its local logic or downstream service.
6. Return and use the result. The server returns structured content or an error. The host decides what enters model context, what is shown to the user and what is recorded.

Diagram text alternative: A user request enters an AI host. The host uses an MCP client to discover or request a capability from one MCP server. The server reaches a tool or resource and returns a result or error. The host applies policy, approval and audit controls before producing the outcome.

The diagram shows a protocol path, not an authorization guarantee. A valid request can still be unsafe or unauthorized.

MCP tools, resources and prompts

MCP primitives separate actions from context and reusable interaction patterns. Keeping those roles distinct helps hosts present appropriate controls.

MCP tools

An MCP tool is a callable interface exposed by a server. Its definition includes a name, description and input schema. A model or host can use it to form a structured request instead of generating a provider-specific API call directly.

Tools may read data, change records, send messages or invoke code, depending on the server. The word “tool” therefore says nothing about impact. Hosts and servers need separate controls for identity, authorization, argument validation, consent, rate limits and audit evidence.

MCP resources

A resource is data that a server makes available for context. It can represent a file, schema, record or generated view identified through a URI. The host controls whether that content enters the model’s context.

Calling a resource passive does not make it harmless. A document can contain confidential data or instructions intended to manipulate an agent. Resource access needs the same attention to scope, provenance and data handling as other application reads.

MCP prompts

An MCP prompt is a reusable interaction template. A server might offer one for reviewing an incident with relevant resources. Prompts can improve consistency, but they do not override host policy or authorize tools.

How MCP skills relate to the protocol

“MCP skills” is a common phrase, but skills are not one of MCP’s standardized server primitives. A skill is generally a portable set of instructions, examples or supporting files that teaches an AI agent how to approach a task. The official Agent Skills guide uses skills to guide coding assistants through MCP server development; the skills help the assistant build an integration rather than becoming part of the wire protocol.

A skill can tell an agent when to use an MCP tool or how to interpret its result. The server exposes the capability, while the host-specific skill influences planning. Packaging skills with MCP configuration does not turn a skill into an MCP message type.

This distinction prevents a common design error: treating instructions as enforcement. A skill can recommend a safe sequence, but the server and downstream system must still enforce authorization and validate every operation.

A worked endpoint example

Northstar Studio, a fictional company, gives developers an approved coding assistant on managed laptops. The assistant connects to two MCP servers: a local server that exposes read access to the current project folder and a remote server that can search and update work items.

Priya asks the assistant to summarize a bug and prepare a proposed fix. The host discovers a project-file resource and read-only search tool on the local server, plus tools for reading a work item and adding a draft comment on the remote server.

The host selects the relevant file and work-item operations. Before the remote tool runs, the system connects Priya’s authenticated identity to a narrowly scoped authorization grant. Policy permits reading the assigned work item and creating a draft, but not changing its status or editing another team’s project.

The servers return the bug details and file content. The assistant prepares a change and asks to add a draft comment. The host shows Priya the target and content, the remote server validates scope, and the work-item service records the approved update.

MCP standardizes discovery, requests and results in this flow. It does not authenticate Priya by itself, decide which project she may access, inspect the proposed fix for correctness or guarantee that the local file server cannot reach other folders. Those controls belong to the host, server, endpoint and downstream systems.

Benefits of MCP

MCP can reduce repeated integration work when hosts and servers implement the protocol correctly.

• Consistent integration roles: Hosts, clients and servers have defined responsibilities that can be reasoned about separately.
• Capability discovery: A client can learn which tools, resources and prompts a server exposes instead of relying only on hard-coded assumptions.
• Composable connections: One host can connect to multiple specialized servers while maintaining separate client relationships.
• Structured tool calls: Schemas make inputs and results more explicit than unstructured text exchange.
• Provider independence: A server can expose a stable MCP surface while translating requests to its own data source or API.

These benefits depend on implementation quality. A poorly named tool, broad schema or unreliable server remains difficult to use even when its messages conform to MCP.

MCP risks and limitations

MCP expands what an AI application can reach, so the protocol boundary needs explicit security design. The official security guidance identifies risks including token misuse, server-side request forgery, session or event injection, confused-deputy behavior and weak authorization flows.

• A protocol connection is not trust. Compatibility does not establish that a server, client, tool description or returned resource is benign.
• Tool descriptions can mislead. A listed description is metadata supplied by a server, not independently verified behavior.
• Local servers inherit endpoint exposure. A local process may reach files, environment variables, credentials or programs available to its operating-system account.
• Remote servers add network and identity boundaries. Tokens, redirects, server identity, transport security and downstream API authorization need validation.
• Prompt injection can cross the boundary. A resource or tool result can contain instructions that attempt to redirect model behavior.
• Broad tools create broad impact. A general shell, database or messaging tool exposes more authority than a small operation with a narrow schema.
• Results and evidence can be incomplete. Structured data may be wrong or stale, while each component may log only part of the action path.
• Protocol versions evolve. Clients and servers need compatible versions and capability handling; assumptions tied to one revision can age quickly.

MCP itself cannot decide the correct business policy. Organizations still need to identify the user and agent, limit tool and data scope, validate inputs and outputs, protect credentials, record policy decisions and preserve a revocation path.

How MCP relates to endpoint trust

An endpoint may host the AI application, local MCP servers, credentials and accessible files. Its operating-system identity, management state and runtime controls therefore affect the MCP boundary. A remote model does not remove risk when a local client or server can change local resources.

Endpoint trust provides context rather than blanket approval. A managed, compliant laptop may satisfy one access requirement, but each MCP tool call still needs authorization for the user, agent, requested action and target resource. AI agent identity helps distinguish the software actor from the employee who initiated or approved its work.

Enforcement may occur at the MCP server, operating system, API gateway or target service. API security remains relevant when a server translates MCP calls into API requests. Each layer needs enough identity and request context to audit its decision.

MCP and related concepts

MCP is an integration protocol, not a complete agent platform or security system.

MCP security focuses on clients, servers, transports, authorization and exposed primitives. Wider agentic AI security also covers the model, runtime, memory, non-MCP tools, endpoint state, data governance and response.

MCP provides standardized connection, not automatic safety. A sound deployment identifies each participant and capability, grants only necessary authority, mediates consequential actions outside the model and records evidence for revocation or investigation.