Model Context Protocol (MCP)

Model Context Protocol, usually called MCP, is a standard way for AI applications to connect models with external tools, data, and workflows. It helps an assistant discover what it can access and how to call those capabilities safely.

You can think of MCP as a connector layer for AI apps. Instead of every AI product building a different custom integration format, MCP defines a common way to expose resources, tools, and prompts.

The problem MCP solves

Modern AI assistants often need more than text generation. They may need to:

• Search company documents.
• Read files.
• Query a database.
• Create tickets.
• Inspect code.
• Call internal APIs.
• Update a project management system.

Without a shared protocol, every integration becomes custom work. The assistant needs one approach for GitHub, another for a database, another for Slack, another for a file system, and so on.

MCP gives these integrations a more consistent shape. Messages use JSON-RPC 2.0, so requests, responses, errors, and notifications all have a predictable envelope.

Hosts, clients, and servers

MCP has three important roles:

• Host: the AI application, such as a desktop assistant, IDE, agent harness, or chat product. The host owns the user interface, model calls, permissions, approvals, and final execution policy.
• MCP client: the protocol connection that the host creates for one server. Each client-server connection is one-to-one.
• MCP server: the integration that exposes tools, resources, prompts, or related capabilities.

A host can connect to many servers by creating many clients. For example, an AI coding assistant may run one client for a GitHub server, one for a docs server, and one for a local file server.

The model may request a tool. The host still decides what servers are available, which tools are exposed to the model, whether the user must approve the call, and whether the call is actually executed through the client.

MCP uses two standard transports: stdio for local subprocess servers and Streamable HTTP for remote servers. The transport carries JSON-RPC messages; it does not change the core roles.

Tools, resources, prompts, and client features

MCP servers commonly expose three kinds of server capabilities:

1. Tools: model-invoked functions, such as search_issues or create_ticket. A tool has a name, description, input schema, and result.
2. Resources: readable, addressable data, such as files, documents, or records. Resources use URIs, and the host application chooses when to include them in the model’s context.
3. Prompts: reusable prompt templates a server offers for specific workflows. They are often invoked by a user action, such as a slash command. They do not directly control the model by themselves.

MCP also defines client features that a server can ask the host to use:

• Sampling: the server asks the host’s model for a completion. The host can require user approval and controls which model is used.
• Elicitation: the server asks the user for missing input through the host interface.
• Roots: the host tells the server which folders or URIs it may work within.

Tools are active. Resources are information. Prompts are reusable workflow templates. Sampling, elicitation, and roots flow in the other direction: they let a server ask the host for model help, user input, or allowed scope. MCP does not replace skills; it exposes capabilities that a skill or assistant may use.

This separation is useful because not every integration should be treated as an action. Reading a document is different from deleting a record, and asking the user for one missing value is different from giving the server full access to a folder.

The lifecycle of an MCP connection

A typical MCP connection follows a simple lifecycle:

1. Initialize: the host opens the transport and starts a JSON-RPC session with the server.
2. Negotiate capabilities: the client and server exchange the protocol version and the capabilities each side supports.
3. Operate normally: the host lists available tools, resources, and prompts, calls tools, reads resources, and handles notifications.
4. Update when needed: a server can notify the client that its tool list or other capabilities changed.
5. Shutdown: the host closes the session and cleans up the server process or remote connection.

Good hosts treat MCP servers as dependencies that can fail. They set timeouts, show useful errors, handle partial results, and keep the user in control when a server is slow or unavailable.

Why MCP matters for context

MCP is closely related to context engineering. A model needs useful context to answer well. MCP can provide a structured way to fetch that context from external systems.

For example, when a user asks about a support ticket, an MCP server could provide:

• The ticket description.
• Customer account details.
• Recent related incidents.
• Available support actions.

The assistant can use this information instead of relying only on its training data. The host still decides which resources or tool results are safe and useful enough to place in the context window.

Why MCP matters for agents

Agents need tools. MCP gives agents a standard way to discover and call tools from different systems.

This is useful because an agent may need to work across many services. A research agent might use web search, a document store, and a notes app. A coding agent might use a repository, terminal commands, test results, and issue tracking.

MCP does not make an agent safe by itself. The application still needs permissions, human confirmations, logging, and limits. But MCP helps organize the connection between the agent and the outside world.

A practical example

Imagine an internal assistant for engineering teams. It connects to:

• A GitHub MCP server for repositories and pull requests.
• A documentation MCP server for internal docs.
• A ticketing MCP server for bugs and tasks.

When a user asks, “What changed in the last release?”, the assistant can gather pull requests, match them to tickets, read related docs, and produce a summary. MCP gives each integration a predictable interface.

Security and trust

MCP expands what an AI application can reach, so the security boundary matters.

• Install only trusted servers. Review what files, networks, accounts, and commands a server can reach before enabling it.
• Use least-privilege credentials scoped per server. A docs server should not inherit write access to a production ticketing system.
• Remote servers should use OAuth-based authorization or another explicit authorization flow, not shared long-lived secrets pasted into prompts.
• Treat tool descriptions, resource text, prompt templates, and tool results as untrusted input. They can carry prompt injection or tool-poisoning instructions; prompt engineering covers the basic attack pattern.
• Avoid confused-deputy failures, where the model convinces a powerful server to act on behalf of a less-privileged user.
• Ask for user consent before sensitive reads or writes, especially actions that change data, spend money, or send messages.

A safe MCP setup starts from the user and the host’s policy, not from the model’s request. The model can suggest an action, but the host authorizes it.

When MCP is useful

MCP is useful when:

• You want one assistant to work with many systems.
• You want integrations to be reusable across clients.
• You need structured access to tools and data.
• You want clearer boundaries between the model and external actions.

It may be unnecessary for a small app with one simple API call. In that case, a direct integration may be easier.

The key idea

MCP is a protocol for connecting AI applications to external tools, data, prompts, and workflows. Hosts create one client per server, use JSON-RPC over stdio or Streamable HTTP, negotiate capabilities, and decide what the model may use. MCP is especially useful for context-rich assistants and agents that need to work across many services, but the host must still handle security, approval, timeouts, and failures.