AI assistants are becoming useful not just because their models are improving, but because they can reach the systems where work happens: document stores, internal databases, calendars, code repositories, and business software. Model Context Protocol, usually shortened to MCP, is one emerging standard for making those connections less bespoke.
The important word is standard. MCP is not an AI model, an agent, or a universal security layer. It is a protocol for moving context and invoking capabilities between an AI application and an external service. That distinction matters because the same connection that lets an assistant retrieve a policy document can also let it call a tool that changes a record, sends a message, or reaches sensitive data. Whether that connection is useful or reckless depends on the permissions, review points, and operational controls around it.
This guide explains how MCP works in practical terms, what it changes compared with one-off integrations, and the questions to answer before connecting an AI assistant to anything consequential.
What is Model Context Protocol?
Model Context Protocol is an open, client-server protocol for connecting AI applications with external context and capabilities. Its core purpose is straightforward: rather than building a different custom connector for every assistant and every service, a developer can expose a service through a common interface that compatible AI applications can understand. The original public announcement described the goal as a common way to connect AI systems with the places where data lives; the current specification defines the protocol’s technical roles and message rules.
That does not mean every connection becomes interchangeable. A payroll system, a customer database, and a local folder have different data, permissions, and failure modes. MCP standardizes the conversation around a connection. It does not remove the need to decide what an AI application may see, which actions it may take, or when a person must approve a result.
A useful analogy is a common plug shape, not a universal power supply. The plug makes a connection possible; the application still has to handle voltage, safety, ownership, and what should happen if something goes wrong.
How an MCP connection is structured
The official MCP architecture separates three roles:
- Host: the AI application that coordinates the experience. A desktop assistant, coding environment, or enterprise agent can act as the host.
- Client: the component inside the host that maintains a connection to one MCP server. A host can create separate clients for separate servers.
- Server: the program that offers context or capabilities to the client. It may run locally on the same machine or remotely over a network.
In a simple workflow, a person asks an assistant for help. The host decides which connected server is relevant, its client talks to that server, and the server returns information or carries out a permitted tool call. The host then brings the result back into the AI interaction. MCP uses JSON-RPC message conventions at its data layer and supports local standard-input/output connections as well as remote Streamable HTTP connections.
This separation is more than vocabulary. It makes a crucial question visible: which component is doing what? The host shapes the user experience and may ask for approval. The client manages a particular connection. The server describes or executes its own capabilities. A team cannot sensibly govern an AI workflow if it does not know which of those layers holds a credential, receives a document, or turns a model’s suggestion into an external action.
Tools, resources, and prompts are not the same thing
MCP servers can expose three core kinds of capability. Resources provide context, such as a file, a database record, or an API response. Prompts are reusable interaction templates. Tools are functions an AI application can invoke, such as searching a system, creating a ticket, or calling another API.
The difference matters because the risk is different. Reading a public knowledge-base article is not equivalent to sending a customer email. A resource can still contain sensitive or misleading material, while a tool can cause a real-world change. The MCP specification explicitly treats tools as arbitrary code execution and says hosts should obtain explicit user consent before invoking them. Tool descriptions from an untrusted server also deserve caution; a polished description is not proof that a tool is safe or that it will do only what a model infers from its name.
A well-designed MCP connection therefore makes the tool surface legible. Each tool should have a narrow purpose, a clear input shape, and an understandable outcome. Broad, catch-all actions make it harder for a host to present a useful confirmation and harder for a reviewer to diagnose a mistake later.
Why local and remote MCP servers deserve different questions
Location changes the security conversation. A local server commonly uses the standard-input/output transport and runs alongside the host on a user’s machine. A remote server commonly uses Streamable HTTP and can serve many clients. Neither arrangement is automatically safer.
A local server may be convenient for a developer’s files or tools, but it should be treated as a program with the privileges of its execution environment. Teams should know who supplied it, how it is updated, what files or environment variables it can reach, and how it is removed. A remote server creates a different set of questions: who operates it, what data crosses the network, how it authenticates clients, and whether its scopes are limited to the operation at hand.
For HTTP-based protected servers, MCP defines an authorization flow built on established OAuth standards. The current authorization specification requires a server to validate that an access token was issued for that server as its intended audience, and it describes progressive requests for the scopes needed by a particular operation. Those are useful protocol requirements, but they are not a substitute for a sound access model. Authorization may be optional in an implementation, and the protocol cannot independently decide whether a connected tool should have been granted a powerful permission in the first place.
Why Model Context Protocol needs a security boundary
MCP makes the connection between language-model output and external systems easier to express. That is exactly why an organization should not treat it as a background implementation detail. A model can misunderstand an ambiguous instruction. Retrieved content can include a malicious instruction intended to redirect the model. A valid credential can be too broad for the task. A server that accepts or forwards the wrong token can undermine the intended trust boundary.
The protocol’s own security guidance calls out token passthrough as an anti-pattern. If a server accepts a token that was not issued specifically for it and forwards that token downstream, it can blur accountability and enable access beyond the intended resource. The same guidance recommends a progressive, least-privilege scope model rather than starting every connection with a broad set of permissions. The U.S. National Security Agency’s 2026 MCP guidance reaches the larger operational point: authentication, authorization, input validation, and monitoring remain necessary when an AI-driven workflow connects to tools and data.
In other words, MCP can make an agent more capable without making its judgment more reliable. Good security design assumes that the model, the connected service, and the surrounding workflow can all fail in different ways.
Five controls to put in place before connecting MCP to production
1. Start with a task map, not a server list
Define the user task before enabling a connection. What information is actually needed? Which system is authoritative? Is the desired result a read-only answer, a draft, or a completed action? Name the owner of the workflow and the actions it must never take. This keeps a team from granting a broad connector simply because it might be useful later.
2. Treat the server as software you are choosing to trust
Record the server’s publisher, source location, version, update path, dependencies, and the data it can access. Review changes before exposing a new tool or a new permission. For local servers, include the process permissions and environment secrets in that review. For remote servers, include its authorization flow, privacy terms, and the place where logs and data are retained. A registry entry is not an assurance program.
3. Use small, operation-specific permissions
Prefer a read-only scope for a research task over a general administrative token. Request elevated access only when the exact operation needs it. Separate connections for separate systems when that separation makes audit and revocation clearer. The point is not to add consent dialogs for every harmless lookup. It is to make a meaningful difference between viewing a record, preparing a draft, and changing or disclosing something.
4. Keep sensitive actions behind an intelligible confirmation
A person should see the target, proposed action, relevant parameters, and the information that supports it before approving a consequential step. “Allow tool use” is too vague when the tool can send a message, delete a file, change access, or create a financial commitment. When the impact is high, the safest successful result may be a draft or an escalation rather than an autonomous call.
5. Preserve a usable trail and a fast stop button
Log which server, tool, input, permission, and result were involved in a run—while applying appropriate privacy protection to the logs themselves. Monitor new tools, scope elevation, failures, unusual usage, and repeated approval patterns. Assign a named owner who can disable a connection or reduce its access quickly. A connection that cannot be paused or investigated is not ready for a sensitive workflow.
MCP versus an API: what changes and what does not
MCP is not a replacement for APIs. An MCP server will often call APIs, query databases, or read local files behind the scenes. An API defines a service’s own interface. MCP gives AI applications a common way to discover and use context-oriented capabilities across different services.
The practical benefit is a more consistent integration boundary for AI tools. The practical limit is equally important: a common boundary cannot turn a poorly designed API, an over-privileged service account, or an unsafe business process into a safe one. The controls that matter most—identity, permissions, validation, confirmation, and monitoring—still belong to the organization that deploys the workflow.
Evaluate the workflow before you expand its access
The right test is not whether an assistant can call a tool in a clean demo. Test the specific workflow with normal requests, incomplete requests, conflicting information, unavailable services, and instructions embedded in untrusted content. Check the final answer, but also check the path: did the assistant use the right source, select the permitted tool, request approval at the correct point, and stay within the assigned scope?
Unhyd’s guide to evaluating AI agents before scale offers a complementary framework for that work. MCP gives an agent a standardized connection to tools and context. Evaluation provides the evidence for deciding whether the agent should use that connection at all, and under which conditions.
The most durable use of MCP will not be the one with the longest tool menu. It will be the one where people can explain, in plain language, what the connection is for, what it can access, when it can act, and how it can be stopped.
FAQ
Is Model Context Protocol only for AI agents?
No. MCP is designed for AI applications that need external context or capabilities. An autonomous agent can use it, but so can an assistant that only retrieves information or helps a person prepare work.
Does MCP make an AI assistant autonomous?
No. MCP can expose tools that an AI application may invoke, but the host and the surrounding system determine permissions, confirmations, and whether an action is ever executed.
Can MCP work with local software?
Yes. The architecture supports local servers using standard input and output as well as remote servers using Streamable HTTP. Local does not mean low-risk; the server’s process permissions and origin still need review.
What is the first security decision to make?
Decide the smallest useful task and the minimum data and permissions it needs. That decision shapes the server choice, scope design, review step, and evaluation plan more effectively than a generic checklist added after access is granted.
Sources
- Model Context Protocol Specification, version 2026-07-28
- Model Context Protocol: Architecture Overview
- Model Context Protocol: Authorization Specification
- Model Context Protocol: Security Best Practices
- National Security Agency: Model Context Protocol—Security Design Considerations for AI-Driven Automation
- Anthropic: Introducing the Model Context Protocol
