)
Last updated: October 15, 2026
What is an MCP server? An MCP server is a program that exposes tools, data and prompt templates to an AI application through the Model Context Protocol (MCP). It can run locally or remotely, and it lets an AI agent act on a system such as a database, a code repository or a SaaS app. This guide explains how it works, when you need one and how to run one safely.
TL;DR: Key Takeaways
- An MCP server exposes 3 kinds of primitives (resources, tools and prompts), and each client keeps a 1:1 relationship with one server, according to the MCP specification, architecture page (revision 2026-07-28).
- Streamable HTTP is the main transport for remote servers. The older HTTP+SSE transport is deprecated, and revision 2026-07-28 removed protocol-level sessions, per the MCP specification, Streamable HTTP page.
- The MCP security guidance covers at least 9 named attack patterns, from confused deputy to token passthrough, and says servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server" (MCP security best practices).
- The Cloud Security Alliance cites the MCPTox benchmark: attack success rates were above 60% across 45+ real-world MCP servers, with the best-performing model reaching 72.8% (CSA, July 2026).
- The OWASP MCP Top 10, still in beta, lists 10 risks, including tool poisoning (MCP03) and shadow MCP servers (MCP09) (OWASP).
MCP server concepts at a glance
| Term | What it is | Example |
|---|---|---|
| Host | The AI application that creates clients and enforces consent | An AI coding assistant |
| Client | A component inside the host that talks to exactly one server | One client per connected server |
| MCP server | A program that exposes tools, resources and prompts | A files and Git server, or a database server |
| Tool | A function the model can call | get_weather |
| Resource | Data a client can read | File contents |
| Prompt | A reusable template chosen by the user | A slash command |
| Transport | How messages travel between client and server | stdio or Streamable HTTP |
What is an MCP server?
An MCP server is the part of the Model Context Protocol that sits next to your data or tools. It advertises what it can do, accepts requests from an MCP client, runs the requested operation and returns the result. The server contains no model. It only supplies context and capabilities to the AI application that connects to it.
Our guide to the Model Context Protocol covers the protocol as a whole. This article stays on the server side: what a server exposes, how it communicates and how to operate it safely.
MCP server vs client vs host
The specification describes a client-host-server architecture. The host process creates client instances, controls their permissions and enforces security policy and consent. Each client communicates with exactly one server, and a server can be a local process or a remote service, per the architecture page.
One design principle matters for security. The specification states that servers "should not be able to read the whole conversation, nor 'see into' other servers." A server therefore receives only the context the host chooses to send it.
MCP server vs API
An API is a fixed contract written for developers. An MCP server wraps capabilities in a self-describing format so that an AI application can discover them at runtime, ask a user for approval and call them with typed arguments. Many MCP servers call a regular API underneath.
A server adds discovery and a consent model, not new access to the data. If the API behind it is over-permissioned, the server inherits that problem.
Why MCP servers matter
MCP servers matter because they let one integration serve many AI applications. The specification's design principles say servers should be extremely easy to build and highly composable. A team writes a server once, and any compatible host can use it.
The same convenience creates a new trust boundary. A server may hold credentials, run code on a laptop or return text that the model reads as instructions. Anthropic's Claude Code documentation puts it plainly: "Verify you trust each server before connecting it" (Claude Code docs).
OWASP now maintains a dedicated MCP Top 10, currently in beta. Its entries read like a map of server-side failure modes, and we return to them in the security section below.
)
What an MCP server exposes: tools, resources and prompts
An MCP server exposes three primitives. Tools are functions the model can call, resources are data the client can read and prompts are templates a user can invoke. Each primitive has a different party in control, which determines where approval and validation need to sit.
| Primitive | Who controls it | What it does | Example |
|---|---|---|---|
| Tools | The model | Functions the model decides to call | Writing a file, sending an API request |
| Resources | The application | Contextual data attached by the client | File contents, Git history |
| Prompts | The user | Templates invoked by user choice | Slash commands, menu options |
The control labels and examples come from the specification's server overview (revision 2025-03-26). Tools carry the most risk because the model, not the user, chooses when to call them.
Anatomy of a tool
A tool definition has a unique name, a human-readable description and an inputSchema written in JSON Schema. It can also carry an outputSchema and optional annotations. A server that supports tools declares the tools capability and can notify clients when its tool list changes, per the tools page (revision 2025-11-25).
The description is the part to watch. The model reads it to decide when to call the tool, so it behaves like an instruction someone else wrote. The specification says clients must treat tool annotations as untrusted unless they come from trusted servers, and adds that there "SHOULD always be a human in the loop with the ability to deny tool invocations."
How an MCP server works: transports and a tool call
An MCP server talks to a client over one of the two transports in the specification: stdio for local processes and Streamable HTTP for local or remote services. Both carry the same JSON-RPC messages. The choice decides who can reach the server, how it authenticates callers and which attacks apply.
| stdio | Streamable HTTP | |
|---|---|---|
| Where the server runs | A local process started by the client | A local or remote HTTP service |
| How messages move | JSON-RPC over standard input and output | Each message is an HTTP POST to one MCP endpoint, answered with JSON or an SSE stream |
| Authentication | Credentials come from the environment | OAuth 2.1 authorization is recommended for HTTP-based servers |
| Main risk | Code runs with the client's privileges | DNS rebinding, token handling, network exposure |
The Claude Code documentation shows both in practice. It recommends HTTP for remote cloud services, marks SSE as deprecated and uses stdio for local processes and custom scripts. The authorization specification says HTTP-based implementations should follow it, while stdio implementations should not and should retrieve credentials from the environment instead.
How a tool call flows
A tool call moves through six stages. The table follows revision 2026-07-28 for the protocol and the 2025-11-25 tools page for the tool messages.
| Stage | Who acts | What happens |
|---|---|---|
| 1. Discover | Client and server | The client learns the server's capabilities and lists its tools with tools/list |
| 2. Select | Model, through the host | The model picks a tool based on the user's request and the tool descriptions |
| 3. Approve | Host and user | The host shows the tool and its inputs, and the user can deny the call |
| 4. Call | Client | The client sends tools/call with the tool name and arguments |
| 5. Execute | Server | The server validates the input, checks access and runs the operation |
| 6. Return | Server and client | The server returns content and an isError flag, and the client validates the result before the model reads it |
Stages 3 and 6 are where most controls belong. Servers must validate inputs, apply access controls, rate limit invocations and sanitize outputs. Clients should confirm sensitive operations and validate results before the model sees them.
What changed in revision 2026-07-28
The latest revision changed how servers handle connections. Check which revision your SDK and clients speak before you deploy.
| Area | Revisions 2025-03-26 to 2025-11-25 | Revision 2026-07-28 |
|---|---|---|
| Connection setup | initialize handshake and an optional Mcp-Session-Id session | No protocol-level sessions, and each request carries its protocol version and client capabilities |
| Standalone stream | Client could open an SSE stream with HTTP GET | GET stream endpoint removed |
| Server-initiated requests | Sent on SSE streams | Returned inside results as input requests |
| Stream resumption | Resumable with Last-Event-ID | Not supported |
Sources: the Streamable HTTP page and the architecture page. Servers that still need state across requests mint an explicit handle, such as a cart ID. The security guidance warns that a guessed handle must not grant access to another user's state.
Streamable HTTP also mirrors the method and tool name into HTTP headers. The aim is that intermediaries "can route and inspect requests without parsing the body." Servers must reject requests where headers and body disagree.
Common MCP server examples and when you need one
The specification's architecture diagram shows three typical servers: files and Git and a database, both on the local machine, and one for external APIs on the internet. Where a server runs and what sits behind it sets its risk profile.
The Claude Code documentation adds concrete cases: a local stdio server for Airtable started with npx, and remote HTTP servers for Stripe and HubSpot.
You need your own MCP server when an agent must reach a system with no published server, or when you want to control exactly which tools the agent sees. You can skip one when a single application calls a single API.
| Situation | Best fit | Reason |
|---|---|---|
| A SaaS vendor already publishes a server | Connect the vendor's remote server after vetting it | No code to maintain, but you inherit its tool descriptions |
| Agents need internal data such as tickets or a database | Build a server with a few narrow tools | You control the descriptions, schemas and permissions |
| One app calls one API with fixed logic | Call the API directly | Runtime discovery adds no value |
| Many teams run many servers | Add a policy point between agents and servers | One place to enforce permissions and limits |
How to build or run an MCP server
Building a server starts small. Pick an SDK for your language, expose one narrow tool and connect it to a client you control. Most of the effort goes into tool design and access control, not protocol plumbing.
Build the tools narrowly
Write each tool for one job, with a precise description and a strict input schema. For a tool with no parameters, the specification recommends { "type": "object", "additionalProperties": false }. Return actionable errors with isError: true, because the model can use them to correct a retry.
Keep output small. Claude Code shows a warning when MCP tool output exceeds 10,000 tokens and sets a default maximum of 25,000 tokens.
Connect it to a client
In Claude Code, a remote server is added with claude mcp add --transport http <name> <url> and a local one with claude mcp add <name> -- <command>. A server can be scoped as local (the default), project (shared in .mcp.json) or user (all your projects). For project-scoped files, Claude Code asks for approval in interactive sessions, and a cloned repository cannot approve its own servers.
Run it with the right transport
Use stdio for tools that serve one person on one machine. Use Streamable HTTP when several people or agents share the server, and put authentication in front of it.
Security and governance for MCP servers
MCP servers concentrate risk because they combine credentials, executable code and text the model trusts. The main threats are tool poisoning, prompt injection through tool output, over-permissioned tools, careless token handling and unvetted or local servers. Each has a published control.
| Threat | What happens | Control |
|---|---|---|
| Tool poisoning and rug pulls | Hidden instructions in a tool description steer the agent, or the description changes after approval | Review full descriptions, pin hashes, re-review on change |
| Prompt injection through tool output | A tool returns text that the model treats as instructions | Treat tool results as untrusted, validate and sanitize them |
| Over-permissioned tools | A broad scope or tool lets one mistake reach many systems | Least-privilege scopes, narrow tools, human approval |
| Token misuse | A server accepts or forwards tokens meant for other services | Validate audience, never pass tokens through |
| Local server compromise | A downloaded server runs code with the user's privileges | Show the exact command, sandbox, restrict access |
| Unvetted servers | An untrusted or shadow server joins the environment | Inventory, allowlist, re-review on update |
Tool poisoning and rug pulls
Tool poisoning hides adversarial instructions in tool descriptions or similar metadata. The Cloud Security Alliance's July 2026 research note describes four variants: description poisoning, rug pulls where a definition changes after approval, tool shadowing across servers and supply chain compromise.
The note cites the MCPTox benchmark, which reports attack success above 60% across more than 45 real-world MCP servers, and 72.8% for the top-performing agent model. These are researcher-reported benchmark results, not a measure of your environment. The note also lists CVE-2025-6514, scored CVSS 9.6, in the mcp-remote library, which had close to half a million downloads at disclosure.
CSA recommends keeping an inventory, hashing tool manifests at approval and re-verifying them, and allowlisting approved servers. Our MCP Security 101 guide walks through the attack in detail.
Prompt injection through tool output
A tool result goes back to the model, so any text a tool fetches can carry instructions. OWASP's MCP Top 10 names this MCP06: Prompt Injection via Contextual Payloads. The Claude Code documentation likewise warns that servers that fetch external content can expose you to prompt injection.
Servers must sanitize outputs, and clients should validate tool results before passing them to the model. Our guide to MCP prompt injection shows how an injected instruction travels from a tool result into an agent's next action.
Over-permissioned tools and scopes
An over-permissioned server turns a small mistake into a large one. The security guidance on scope minimization warns against publishing every scope up front and against wildcard or omnibus scopes such as *, all or full-access. It recommends a minimal initial scope set and step-up requests when a privileged operation is first attempted.
OWASP lists the same pattern as MCP02: Privilege Escalation via Scope Creep. Our guide to excessive agency covers the broader problem.
Token handling
A protected MCP server acts as an OAuth 2.1 resource server. The authorization specification requires it to validate that access tokens were issued specifically for it. It also says the server "MUST NOT accept or transit any other tokens." Tokens must not appear in the URI query string.
Token passthrough is the anti-pattern the rule prevents. The security guidance says it can bypass controls such as rate limiting, blur the audit trail and let a stolen token turn the server into a data exfiltration proxy. It also describes a confused deputy problem for MCP proxy servers that use a static client ID with dynamic registration and a consent cookie. The fix is per-client consent before any third-party authorization step.
Local servers, Origin checks and localhost
A local server runs with the privileges of the client that starts it. The security guidance warns that a malicious startup command can run arbitrary code, so clients with one-click setup must show the exact command and require explicit approval. It also recommends sandboxing with minimal default privileges.
For Streamable HTTP, the specification sets three rules. Servers must validate the Origin header on all incoming connections and respond with HTTP 403 Forbidden when it is present and invalid, to prevent DNS rebinding. Servers running locally should bind only to 127.0.0.1 rather than 0.0.0.0. Servers should implement proper authentication for all connections.
Vetting servers and registries
A registry tells you who published a server, not whether its code is safe. The official MCP Registry, which is in preview, uses namespace authentication so that only the owner of a GitHub account or domain can publish under it. It delegates security scanning to package registries such as npm and PyPI and to downstream aggregators.
Treat every server like a third-party dependency: check the publisher and source, read the tool definitions in full and re-review on version changes. OWASP lists shadow MCP servers as MCP09, so an inventory comes first.
How to evaluate and run an MCP server safely
Use this procedure before any server reaches production. It combines the specification's requirements with mitigations from OWASP and CSA.
- Inventory every server. List each MCP server your teams use, including those added outside IT procurement, and record the owner and the systems it can reach.
- Check provenance. Confirm the publisher, the source repository and the namespace. A registry namespace proves ownership of an account or domain, not the safety of the code.
- Read the tool definitions in full. Review names, descriptions and input schemas, then record a hash of each at approval so that a later change is detected.
- Pick the narrowest transport and credentials. Use stdio for single-user local tools and OAuth-protected Streamable HTTP for shared servers. Request minimal scopes and never pass tokens through.
- Sandbox and bind carefully. Run local servers with restricted file and network access, bind local HTTP servers to 127.0.0.1 and validate the
Originheader. - Keep a human in the loop for high-impact tools. Show the tool and its inputs before the call, require approval for writes and payments, and treat tool output as untrusted.
- Log, test and re-review. Log tool definition loads and invocations, test poisoning and injection cases before rollout and re-review a server whenever it updates.
How NeuralTrust approaches MCP server risk
NeuralTrust is a Barcelona-based AI agent security company. Agent Gateway (TrustGate) sits between agents, workflows, models and MCP tools, enforces per-agent permissions and limits, and offers 200+ pre-built MCP servers. That addresses over-permissioned tools at one policy point instead of server by server.
Agent Runtime Security (TrustGuard) detects prompt injection and data leakage at runtime, which covers the tool-output risk. Agent Posture Management (TrustLens) inventories agents and their connections, which supports step 1 above. AI Red Teaming (TrustTest) tests agents before launch, which is where poisoning and injection test cases belong. Together they form the Runtime Security Mesh, and NeuralTrust holds four Gartner Hype Cycle 2026 recognitions for AI Runtime Defense.
None of this replaces server-side basics. Audience-checked tokens, input validation and least-privilege scopes remain the job of whoever operates the server.
Which setup should you choose?
Choose the setup that matches who uses the server and what it can reach. A personal tool and a shared enterprise integration need different transports, credentials and approval rules.
| Your situation | Setup | Why |
|---|---|---|
| Solo developer on one machine | A local stdio server from a source you reviewed, sandboxed | The specification says stdio limits access to just the client |
| A team sharing a SaaS integration | The vendor's remote HTTP server with OAuth and minimal scopes | HTTP-based servers should follow the authorization specification |
| Agents that need internal data | Your own server with a few narrow tools | You control descriptions, schemas and permissions |
| Many teams and many servers | An inventory plus a gateway between agents and servers | One place for permissions, limits and logging |
| One app, one fixed API | Call the API directly | Runtime discovery adds no value |
Conclusion
The answer to "what is an MCP server" comes down to one idea: it turns a system into something an AI agent can discover and use, through typed tools, readable resources and reusable prompts. That convenience moves trust to the server, because its tool descriptions, tokens and code all shape what the agent does. Pick the transport that fits your users, scope tokens narrowly, vet each server like a dependency and keep human approval on high-impact tools.
Secure MCP Servers in Production with NeuralTrust
Put one gateway between your agents and your MCP servers, with per-agent permissions and limits.
)
Related Comparisons
FAQs about What Is an MCP Server
1. What is an MCP server in simple terms?
An MCP server is a program that gives an AI application controlled access to a tool or data source. It lists what it can do, accepts requests from an MCP client, runs the operation and returns the result. It can run locally or remotely, and it holds no model of its own.
2. What is the difference between an MCP server and an MCP client?
The server exposes tools, resources and prompts. The client lives inside the host application and connects to exactly one server. The host creates the clients, enforces consent and decides which context each server receives.
3. Is an MCP server the same as an API?
No. An API is a fixed contract for developers, while an MCP server describes its capabilities in a form an AI application can discover at runtime and call with user approval. Many MCP servers call an API underneath, so they inherit that API's permissions and weaknesses.
4. Should an MCP server run locally or remotely?
Run it locally over stdio when it serves one person on one machine. Run it remotely over Streamable HTTP when a team or several agents share it, and protect it with OAuth. Local servers run with the client's privileges, so they need sandboxing and a reviewed source.
5. Are MCP servers safe?
An MCP server is only as safe as its code, tool descriptions and permissions. The specification sets requirements for token validation, Origin checks and consent, and OWASP lists 10 MCP risks in beta. Vet every server like a dependency, limit its scopes and keep human approval on high-impact tools.
6. What is tool poisoning in MCP?
Tool poisoning hides adversarial instructions in a tool's description or metadata, which the model reads as trusted context. The Cloud Security Alliance describes variants including rug pulls, where a description changes after approval. Defenses include reviewing full descriptions, pinning hashes and re-reviewing servers when they update.
7. How do I secure a remote MCP server?
Put OAuth 2.1 in front of it and validate that every token was issued for your server. Never accept or forward tokens meant for other services. Validate the Origin header, keep scopes minimal, validate inputs, rate limit calls and sanitize outputs.
About the Author
Roger Howroyd is Head of Global SEO and AI at NeuralTrust, where he leads the company's search strategy across SEO, AEO, GEO, and LLM optimization. He specializes in AI-powered search, content strategy, and SEM. Connect on LinkedIn.
NeuralTrust is the leading platform for securing and scaling AI agents. Named a Pioneer in the Gartner Emerging Market Quadrant for AI Application Security 2026, recognized across four Gartner Hype Cycle reports in 2026, and featured in the Gartner Market Guide for Guardian Agents 2026, the Gartner Market Guide for AI Gateways 2025 and the KuppingerCole Leadership Compass for Generative AI Defense 2025. Headquartered in Barcelona with offices in London and New York. ISO 27001 certified.
Sources
- Model Context Protocol, "Architecture," specification revision 2026-07-28: https://modelcontextprotocol.io/specification/2026-07-28/architecture
- Model Context Protocol, "Tools," specification revision 2025-11-25: https://modelcontextprotocol.io/specification/2025-11-25/server/tools
- Model Context Protocol, "Streamable HTTP," specification revision 2026-07-28: https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http
- Model Context Protocol, "Authorization," specification revision 2026-07-28: https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
- Model Context Protocol, "Security Best Practices," latest specification: https://modelcontextprotocol.io/specification/latest/basic/security_best_practices
- Model Context Protocol, "The MCP Registry" (preview), accessed Oct 15, 2026: https://modelcontextprotocol.io/registry/about
- OWASP, "OWASP MCP Top 10" (beta), accessed Oct 15, 2026: https://owasp.org/www-project-mcp-top-10/
- Cloud Security Alliance, "MCP Tool Poisoning: Adversarial Hijacking of AI Agent Workflows," Jul 2, 2026: https://labs.cloudsecurityalliance.org/research/csa-research-note-mcp-tool-poisoning-ai-agent-exfiltration-2/
- Claude Code Docs, "Connect Claude Code to tools via MCP," accessed Oct 15, 2026: https://code.claude.com/docs/en/mcp
- Model Context Protocol, "Server Features," specification revision 2025-03-26: https://modelcontextprotocol.io/specification/2025-03-26/server
)
)
)
)