An MCP server is a program that exposes a focused set of capabilities to an AI application through the open Model Context Protocol. It may offer tools the model can request, resources the application can read, or reusable prompts a person can select. The server does not turn a model into an all-powerful operator: the host application still decides which server to connect, which context to pass to the model, whether a tool call needs approval, and what result returns to the conversation.
This definition reflects the official MCP architecture published for protocol version 2026-07-28. That date matters. MCP is evolving, and older explainers may describe different discovery, transport, or client features. The current documentation describes stateless requests, JSON-RPC 2.0 messages, a host-client-server arrangement, and server primitives for tools, resources, and prompts.
The three participants: host, client, and server
People often use “client” to mean the whole AI app, but the protocol separates three roles:
- MCP host: the AI application that coordinates the model, user experience, and one or more server connections.
- MCP client: the component inside the host that maintains a dedicated connection to one MCP server. A host connected to five servers generally manages five client connections.
- MCP server: the local or remote program that exposes context or actions through the protocol.
A local server commonly runs as a process beside the host and communicates over standard input/output. A remote server commonly uses Streamable HTTP. The data-layer messages stay protocol-shaped even though connection setup, authentication, and operational risk differ.
What an MCP server can expose
| Primitive | What it provides | Who initiates its use | Example |
|---|---|---|---|
| Tools | Schema-defined functions that can perform work | The model can request a call; the host may validate or ask for approval | search_docs, create_issue |
| Resources | Readable context identified by URIs | The application decides what to retrieve and include | A handbook page or database schema |
| Prompts | Reusable, parameterized interaction templates | The user explicitly selects or invokes them | “Summarize this incident” |
This distinction prevents a common misunderstanding. A resource is not automatically copied into every model request, and a listed tool is not automatically executed. MCP describes interfaces and messages; the host defines the product experience and policy around them.
How the protocol layer works
The 2026-07-28 architecture separates a data layer from a transport layer. The data layer defines JSON-RPC 2.0 messages, version and capability information, primitives, results, errors, and notifications. The transport layer carries those messages over stdio or Streamable HTTP and handles connection-specific concerns.
Current requests carry protocol and capability metadata. A client can use server/discover to learn a server’s supported versions, identity, and capabilities, then use methods such as tools/list and tools/call. Discovery is useful, but a friendly schema is not a security guarantee. Tool descriptions are input from another software boundary and should be inspected accordingly.
A five-step MCP tool trace
Here is a conceptual, reproducible trace for a read-only documentation search. It is not evidence that a particular server was tested; it shows the observable control points a well-designed host can implement.
| Step | Observable event | Control that matters | Example outcome |
|---|---|---|---|
| 1 | Client discovers the server and lists tools | Pin an expected server identity, version range, and allowed tool set | search_docs appears with a string query schema |
| 2 | The model selects a tool based on the user’s request | Treat the choice as a proposal, not an authorization decision | The model proposes search_docs({query: "refund policy"}) |
| 3 | The client validates arguments, scope, and approval policy | Reject unknown fields, oversized input, missing scopes, or write intent | The read-only query passes |
| 4 | The server executes against the underlying system | The server rechecks authorization and uses least-privilege credentials | Only the permitted documentation index is searched |
| 5 | The result returns to the client and then the model | Log the call, constrain result size, and treat returned text as untrusted data | Three document matches return with source URIs |
| Denied path | An unexpected request attempts to update a document | The client and server both enforce the granted read-only scope | Denied before execution; no document changes |
The denied row is the most important one. Natural-language intent is not a permission system. If a connection was granted only search access, an unexpected write must fail even when the model strongly recommends it.
What an MCP server is not
- It is not a model. The host supplies the model and decides how model output is used.
- It is not an agent. An agent may use MCP connections, but planning, memory, retries, and stopping rules live elsewhere.
- It is not a replacement for every API. The server often wraps APIs, databases, files, or internal services behind a common interaction surface.
- It is not an automatic trust boundary. A server can still contain vulnerable or malicious code, misleading tool descriptions, excessive permissions, or unsafe network access.
- It is not Anthropic-only. MCP is an open protocol used across multiple applications and development ecosystems.
Can the model execute arbitrary server code?
Not through MCP merely because the server is connected. The model receives descriptions and may propose a tool call whose name and arguments fit a published schema. The host client sends a specific protocol request. The server maps that request to an implementation it already owns. A well-designed server does not accept arbitrary source code, shell commands, file paths, or URLs unless that capability is deliberately defined and authorized.
That said, a dangerously broad tool such as run_shell(command) effectively creates a general execution surface. Protocol structure cannot rescue an unsafe tool design. Narrow verbs, typed arguments, server-side validation, and operating-system isolation are what turn a connection into a defensible capability.
Is MCP safe?
MCP can be deployed safely, but connection does not imply trust. The official authorization guidance says authorization is optional and strongly recommended for servers that access user-specific data, auditable actions, protected APIs, enterprise systems, or per-user rate limits. For remote HTTP servers, MCP follows OAuth 2.1 conventions. Local stdio servers may obtain credentials through environment or embedded library flows, but they still run code on the machine and deserve the same supply-chain scrutiny as any dependency.
For a deeper threat model and runtime checklist, use our MCP security audit. The short version is below.
- Verify the source. Prefer an official repository or a publisher whose identity and release process you can validate.
- Read the manifest and tool descriptions. Look for capabilities that do not match the promised job.
- Grant least privilege. Use a read-only token for read-only work and restrict filesystem or database scope.
- Prefer scoped, short-lived credentials. Never place unrelated secrets in the server’s environment.
- Require confirmation for writes. Deleting, sending, purchasing, publishing, and permission changes deserve explicit checkpoints.
- Validate on both sides. Clients should validate calls before sending; servers must enforce authorization before execution.
- Test in isolation. Start with synthetic data and a sandbox account. Inspect errors and unexpected network activity.
- Log actions and results. Record server identity, tool, arguments with secrets redacted, result state, and approver.
- Remove unused connections. Old tokens and forgotten local processes expand the attack surface.
MCP server versus a direct API
Use MCP when an AI application needs a discoverable, reusable capability surface that can work across compatible hosts. Use a direct API when you own both ends of a fixed workflow, need complete control over transport and retries, or want the smallest possible production dependency chain.
The choice is not ideological. A direct API is often clearer for one deterministic integration. MCP becomes valuable when multiple tools, resources, or hosts would otherwise require repeated adapters. Our MCP versus API guide covers the decision in detail.
A practical evaluation before you connect
| Question | Good evidence | Stop signal |
|---|---|---|
| Who maintains it? | Named organization, signed releases, active security policy | Typosquatted package or anonymous binary |
| What can it reach? | Explicit allowlist of paths, APIs, and scopes | Entire home directory or administrator token by default |
| What can change? | Separate read/write tools with approval on writes | One broad execute-anything tool |
| Can you observe it? | Structured logs and stable request identifiers | No audit trail or silent background actions |
| Can you revoke it? | Short-lived token, documented disconnect and cleanup | Long-lived shared credential with unclear ownership |
Frequently asked questions
What is the difference between an MCP server and an MCP client?
The server exposes capabilities. The client maintains the connection and exchanges protocol messages on behalf of the host AI application. One host can create multiple clients, usually one for each connected server.
Can an MCP server access my files?
Only if its implementation and operating-system permissions allow file access. A filesystem server may be intentionally scoped to selected directories; an unrelated remote server should not gain local file access merely because it speaks MCP. Always inspect configuration and runtime permissions.
Do I need to build an MCP server?
No. You can use an existing server when its publisher, capability surface, and permissions meet your requirements. Build one when you need a private system, a narrower interface, or controls an existing server does not provide.
Does MCP automatically make tools portable?
It standardizes discovery and invocation, which reduces adapter work. Portability still depends on the protocol versions and capabilities supported by both client and server, plus authentication and deployment requirements.
Sources and review date
This article was researched and reviewed on 14 September 2026 against the official MCP architecture overview, server concepts, and authorization guidance. Protocol-specific statements are dated because later revisions may change individual methods or features.
The takeaway: an MCP server is a constrained capability provider, not a magic autonomy switch. Choose a trustworthy implementation, expose the smallest useful surface, enforce permissions outside the model, and keep every consequential action observable and revocable.