Skip to content
atlas

MCP server

A small program that offers tools or data to AI apps through the Model Context Protocol, such as reading mail or searching files.

Draft - this entry has not been reviewed yet.

Formal

A program that speaks the Model Context Protocol and tells a connected AI app which tools, data and prompts it offers, each with a name and a text description; it runs the tool calls it receives, either on the same machine or over the internet.

In plain English

Like letting a temp from an unknown agency into the office because their written list of skills looks useful - you only have their word for what they will actually do.

In practice

The office manager at a small Danish firm installs a free MCP server from the web so an assistant can manage her calendar; it asks for her full account login, and every tool description it sends goes straight to the model.

Why it matters

Each one is outside code with real access running next to your assistant, so a careless or hostile one can leak secrets or steer the model - it deserves the same care as installing any other software.

Technical deep dive

An MCP server exposes up to three server-side primitives. Tools are model-invoked functions, advertised via tools/list with a name, a natural-language description, a JSON Schema inputSchema (JSON Schema 2020-12 is the default dialect) and optionally an outputSchema, and executed via tools/call, which returns content blocks and optionally structuredContent. Resources are application-controlled, URI-addressed data read with resources/read, and prompts are user-selected templates fetched with prompts/get. Tools may also carry annotations such as readOnlyHint, destructiveHint, idempotentHint and openWorldHint; the specification says clients must treat these as untrusted unless the server itself is trusted, because a malicious server can simply lie.

There are two standard transports. With stdio the host launches the server as a local subprocess and exchanges newline-delimited JSON-RPC over stdin and stdout; the server runs with the user's own operating-system privileges, and the authorization specification says stdio servers should take credentials from the environment rather than run OAuth. With Streamable HTTP the server is a remote endpoint and, when protected, acts as an OAuth 2.1 resource server: it must publish OAuth 2.0 Protected Resource Metadata (RFC 9728), accept only tokens whose audience is itself (RFC 8707 resource indicators), and must not pass tokens it received through to upstream APIs, a rule aimed at the confused-deputy problem. Local HTTP servers must also validate the Origin header to resist DNS rebinding. The 2026-07-28 revision made the protocol stateless: the initialize handshake and the Mcp-Session-Id header are gone, servers must implement server/discover, list results carry ttlMs and cacheScope caching hints, and any cross-call state has to be modelled as explicit handles passed in tool arguments.

Most real-world risk sits in the server ecosystem rather than the wire format. Tool poisoning hides instructions in tool descriptions, which the host feeds verbatim to the model; a "rug pull" changes a tool's definition after the user approved it; and with several servers connected, one server's descriptions can shadow or redirect another's tools. Ordinary software flaws apply too: CVE-2025-6514, published in July 2025, was a critical OS command injection in the widely used mcp-remote proxy, triggered by connecting to a malicious server. Validation errors should be returned as tool execution errors (isError) rather than protocol errors so the model can correct its call.

Operationally an MCP server should be treated like any third-party dependency with credentials: pin versions and review source, prefer official or registry-verified servers, grant narrowly scoped tokens, run local servers in a container or sandbox where possible, log every tool call, and have organisations enforce an allowlist of approved servers through managed client configuration.

What to learn first

Everything this builds on, foundations first.

  1. Inference
  2. →Token
  3. →Network
  4. →Next-token prediction
  5. →IP address
  6. →Protocol
  7. →Sampling
  8. →Client
  9. →Port
  10. →Structured output
  11. →Server
  12. →API
  13. →Tool calling
  14. →MCP server

Relationships

A kind of
Server
Requires
Tool calling

Sources & further reading

Official documentation

Reference works

Where this data comes from

This entry was drafted by an AI from the sources above and has not yet been checked by a person. Treat it as a starting point, and check anything important against the sources.

See the review queueSuggest a correction on GitHubThis term as JSON

Check yourself

Loading…

Atlas is in beta.