What Is an MCP Server? Meaning, Types and Security
An MCP server is a program that makes a system's data and actions available to AI applications through the Model Context Protocol (MCP). It is the server side of the protocol: it tells an AI agent which tools, resources and prompts it offers, runs the tools the agent calls, and returns the results in a standard format. The AI application on the other side, such as Claude, Cursor or a custom agent, runs an MCP client that connects to it.
In plain terms, the meaning of "MCP server" is an adapter between one system and any MCP-compatible agent. A database, a ticketing tool, a file system or a data catalog each gets its own MCP server, and any MCP-compatible agent can use it without a custom integration. The protocol article explains MCP as a whole. This one is about the component that teams actually deploy, secure and choose between.
An MCP server exposes three kinds of capability to AI agents: tools the model can call, resources the application can attach as context, and prompts the user can pick. It runs either locally, as a subprocess talking over standard input and output (stdio), or remotely, as an HTTPS endpoint using the Streamable HTTP transport and OAuth 2.1. The current specification, revision 2026-07-28, made the protocol stateless. The main risks sit on the server: prompt injection through tool descriptions and results, over-broad permissions and tokens that are passed through to other systems. A good MCP server validates every input, scopes access to the calling user and logs every call.
What Is an MCP Server?
The Model Context Protocol defines three roles. The host is the AI application the user works in. Inside it, an MCP client holds the connection to one server. The MCP server is the program that provides context and capabilities. One host can run many clients, so a single agent can work with several servers at once, for example a code repository, a warehouse and a catalog.
Anthropic introduced MCP in November 2024 and donated it in December 2025 to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI. At the time of the donation in December 2025, the Linux Foundation counted more than 10,000 published MCP servers. In July 2026 the maintainers reported close to half a billion monthly downloads across the four Tier 1 SDKs, which are the libraries most servers are built with. Both figures were the latest published as of November 2026.
An MCP server holds no language model of its own. It describes what it can do, waits for requests and executes them. The reasoning stays in the agent, while the access, the business logic and the controls stay in the server. That split is what makes a server reusable across agents, and it is also why the server is the right place to enforce security.
What Does an MCP Server Expose?
The specification gives servers three primitives. They differ in who decides when they are used, which matters for both design and security.
| Primitive | Who controls it | What it is | Data catalog example |
|---|---|---|---|
| Tools | The model | Functions the model can call to retrieve information or take an action, each with a name, a description and a JSON Schema for its inputs | Search assets, trace lineage, apply a classification label |
| Resources | The application | Structured data or content the host can attach to the conversation, identified by a URI | A dataset description or a glossary term loaded as context |
| Prompts | The user | Predefined templates the user picks, often shown as slash commands or menu items | "Explain where this metric comes from" |
In practice, tools carry most of the weight. Many production servers expose tools only. Snowflake's managed MCP server, for example, does not support resources or prompts at all. When people say an MCP server "gives an agent access" to a system, they usually mean a list of tools.
Tool descriptions are written for the model as much as for developers. The model reads them to decide which tool to call and with what arguments, so a vague description produces wrong calls. That is also why the description is an attack surface, as the security section explains.
How Does an MCP Server Work?
MCP messages are JSON-RPC 2.0 requests and responses. A typical exchange with a server looks like this:
- Discovery. The client asks the server for its tools with
tools/list. The server answers with each tool's name, description, input schema and optional annotations, such as a hint that a tool is read-only. - Selection. The host gives the tool list to the model. When a user asks a question, the model decides which tool to call and fills in the arguments.
- Invocation. The client sends
tools/callwith the tool name and arguments. The server validates the input, checks that the caller may perform the action, calls the underlying system and returns the result as text, structured content or a link to a resource. - Repeat. The model reads the result and calls more tools until it can answer. The specification says a human should always be able to deny a tool invocation, so hosts typically ask for confirmation before sensitive actions.
The protocol changed shape in 2026. Revision 2026-07-28 removed the initialization handshake and protocol-level sessions, so every request now carries its own protocol version, client identity and capabilities. Any request can reach any instance of a server behind an ordinary load balancer, which makes remote servers much easier to scale. Over HTTP, the method and tool name also travel in Mcp-Method and Mcp-Name headers, so a gateway can route, meter and authorize calls without parsing the body. A server that needs state across calls can return an explicit handle that the model passes back as an argument.
Server implementations do not all move at once. Snowflake's managed server, for example, documents support for revision 2025-11-25. The specification includes backward compatibility rules for that reason, and it is worth checking which revision a server and a client support before connecting them.
Local vs Remote MCP Servers
The specification defines two standard transports, and they produce two very different kinds of server.
| Local MCP server | Remote MCP server | |
|---|---|---|
| Transport | stdio: newline-delimited JSON-RPC over the standard input and output of a subprocess | Streamable HTTP: each message is an HTTP POST to one MCP endpoint, answered with JSON or a server-sent event stream |
| Where it runs | On the user's machine, started by the host application | On a server or in the cloud, reached over HTTPS |
| Credentials | Read from the environment, such as an API key in a config file | OAuth 2.1 under the MCP authorization specification |
| Typical use | Developer tools, local files, prototypes | Shared enterprise systems used by many people and agents |
| Who operates it | Each user, on each laptop | The system owner, once, for everyone |
| Main risk | Running an untrusted binary with the user's local access | Weak authorization, over-broad scopes, exposed endpoints |
The older HTTP with server-sent events transport is officially deprecated and has a one-year off-ramp. For enterprise data, the direction is clear: remote servers operated by the owner of the system. They give a single place to enforce permissions and audit usage, instead of copies of credentials spread across laptops. Many vendors now ship a managed remote MCP server alongside their API.
How Do MCP Servers Handle Authentication?
Authorization is optional in MCP, but any server that touches real data needs it. For HTTP servers, the specification builds on OAuth 2.1 and a selected set of related standards. A protected MCP server acts as an OAuth 2.1 resource server: it accepts access tokens, and a separate authorization server, often the company's identity provider, signs the user in and issues them. Local stdio servers are told not to use this flow and to take credentials from the environment instead.
The rules that matter most in practice:
- Audience binding. A server must only accept tokens issued for it, checked under RFC 8707 resource indicators, and must reject expired or invalid tokens with HTTP 401.
- No token passthrough. A server must not accept a token meant for another service or forward the client's token to a downstream API. If it needs to call another system, it gets its own credentials for that system.
- Least-privilege scopes. Servers should advertise the scopes a request needs, so clients ask for a minimal set and step up only when a higher-risk tool requires it.
- Client registration. Revision 2026-07-28 deprecated Dynamic Client Registration in favor of Client ID Metadata Documents and requires clients to validate the issuer of an authorization response under RFC 9207. Expect servers to differ here for a while. Snowflake's managed server, for instance, does not support dynamic client registration.
The design goal is that an agent acts as the user, with the user's identity and no more than the user's permissions. A server that connects to its backend with one powerful service account and lets every caller use it breaks that model, even if the MCP connection itself is perfectly authenticated.
What Are the Security Risks of MCP Servers?
An MCP server combines two things attackers like: it is reachable by a language model that follows instructions found in text, and it holds credentials to real systems. The MCP security best practices and vendor guidance name these risks:
- Prompt injection through tools. Text returned by a tool, such as a document, a ticket or a database value, can contain instructions that the model then follows. The specification tells clients to validate tool results before passing them to the model and to treat tool annotations as untrusted unless the server is trusted.
- Tool poisoning and tool shadowing. A malicious server can hide instructions in a tool description, or register a tool that imitates a trusted one. Snowflake's documentation warns about both and recommends verifying every tool of a third-party server before use.
- Excessive permissions. A token with broad scopes, or a server running under an administrator account, turns one stolen credential or one manipulated agent into wide access. The MCP security best practices list scope minimization among the mitigations.
- Token passthrough and confused deputy. A server that forwards tokens or proxies a third-party authorization flow without per-client consent can let an attacker act with someone else's access.
- Local server compromise. A local server is a program running with the user's own access. A malicious startup command in a configuration, a malicious package or an unprotected server left listening on localhost can expose files and credentials.
The controls follow from the risks. The specification requires servers to validate all tool inputs, implement access controls, rate limit tool invocations and sanitize tool outputs, and asks clients to show inputs before calling a tool, confirm sensitive operations, time out calls and log tool usage for audit. For AI programs this is part of AI agent governance: an inventory of which servers each agent may use, owners for those servers, and guardrails around what comes back.
MCP Server vs API
Most MCP servers wrap an existing API. The difference is who the interface is designed for.
| REST or GraphQL API | MCP server | |
|---|---|---|
| Primary consumer | A developer writing code against documented endpoints | A language model choosing tools at run time |
| Discovery | Documentation, OpenAPI files, SDKs | tools/list, with descriptions written for the model |
| Integration effort | One integration per application | One server, usable by any MCP-compatible agent |
| Granularity | Many fine-grained endpoints | Fewer tools shaped around tasks, with compact results that fit a context window |
| Security model | Defined by each API | OAuth 2.1 resource server with audience-bound tokens, plus the API's own controls behind it |
The API usually stays in place, and the MCP server becomes a second interface on top of it, built for a different kind of consumer. The related idea of tool calling describes the model side: how an LLM produces a structured request. MCP standardizes how those requests reach a server.
How to Choose or Build an MCP Server
Whether you adopt a vendor's server or build your own with one of the official SDKs, the same questions decide whether it is safe to put in front of agents:
- Who publishes it? Prefer servers operated by the owner of the system over community wrappers. Read every tool description before enabling it.
- Local or remote? For shared business data, choose a remote server with OAuth so access follows the user and can be revoked centrally.
- Whose permissions does it use? Calls should run with the signed-in user's identity and rights, not a shared service account.
- Can you narrow the tools? Look for an allowlist, read-only modes and role-based filtering of
tools/list, so an agent never sees tools it cannot use. - Are write actions separated? Read and write tools should be distinct, with annotations and confirmation for destructive actions.
- Are results bounded? Pagination and field selection keep responses small, which protects both the context window and the data.
- Is every call logged? You need to know which agent called which tool, for whom, and what came back.
- Which spec revision does it support? Check compatibility with the clients you use, especially after the stateless 2026-07-28 revision.
When building, keep tools few and task-shaped, write descriptions as instructions for a model, return structured results, and treat everything that comes back from the underlying system as untrusted text.
MCP Servers for Data Teams
For data and analytics work, MCP servers fall into two groups. Data servers answer questions from the data itself: warehouse servers run SQL or natural-language queries, such as the Snowflake-managed MCP server that exposes Cortex Analyst, Cortex Search and Cortex Agents as tools. Context servers answer questions about the data: what a term means, which table is the trusted one, who owns it and where it comes from. That second kind is what a data catalog, a business glossary and data lineage provide, and agents need it to use the first kind correctly.
The Dawiso MCP server is a context server. According to the Dawiso documentation, it is a remote server that lets agents search catalog objects by name, full text or label, read their attributes and relations, and trace lineage upstream or downstream, while write tools can update attributes, add labels and apply classifications such as PII. tools/list returns only the tools the connecting user's role permits, every tool is either read-only or read-write, administrators maintain an environment-wide allowlist, and list results page at 20 items by default. Dawiso documents setup for Claude and names Cursor among supported clients. For a worked example of what an agent gains from a catalog over MCP, see what an MCP server on a data catalog gives AI agents.
Conclusion
An MCP server is the part of the Model Context Protocol that does the real work: it decides what an agent can see and do in one system, executes the calls and enforces the rules. Its meaning is simple, an adapter that lets any MCP-compatible agent use a system, but its quality varies widely. The useful questions are whether it runs locally or remotely, whose permissions it uses, how narrowly its tools can be scoped and whether every call is logged. With the stateless 2026-07-28 revision, remote servers have become easier to operate at scale, which makes those governance questions the main thing left to get right.
Sources
- Model Context Protocol - Specification 2026-07-28, Server Features (prompts, resources and tools, with the control hierarchy)
- Model Context Protocol - Specification 2026-07-28, Tools (human in the loop, annotations, security considerations)
- Model Context Protocol - Specification 2026-07-28, Transports (stdio and Streamable HTTP)
- Model Context Protocol - Specification 2026-07-28, Authorization (OAuth 2.1 resource server, token handling)
- Model Context Protocol - Security Best Practices (confused deputy, token passthrough, local server compromise, scope minimization)
- Model Context Protocol Blog - The 2026-07-28 Specification (July 28, 2026)
- Anthropic - Introducing the Model Context Protocol (November 2024) and Donating the Model Context Protocol and establishing the Agentic AI Foundation (December 2025)
- Linux Foundation - Linux Foundation Announces the Formation of the Agentic AI Foundation (December 9, 2025)
- Snowflake Documentation - Snowflake-managed MCP server
- Dawiso Help - Dawiso Model Context Protocol (MCP)
See it in action
MCP (Model Context Protocol)
Connect agents and LLMs directly to your enterprise data and business knowledge.