Skip to content
Knowledge Hub/Article
Article

What Is MCP (Model Context Protocol)? Servers and Security

We explain MCP's host, client and server architecture, its JSON-RPC messages, tools and resources, OAuth-based authorization and its security risks.

Oğuzhan Gerçek··9 min read
What Is MCP (Model Context Protocol)? Servers and Security

Short answer: MCP (Model Context Protocol) is an open protocol for connecting AI applications to external systems such as databases and business applications. Anthropic announced it in November 2024, and since December 2025 the project has been part of the Agentic AI Foundation under the Linux Foundation. The AI application (the host) opens one client per MCP server, and each server exposes its tools, resources and prompts through JSON-RPC 2.0 messages. Revision 2026-07-28, released in July 2026, made the protocol stateless. Security rests on user approval for tool calls, tokens issued only for the server in question, and servers from verified sources.

What is MCP, and who created it?

According to the project's documentation, MCP is an open-source standard for connecting AI applications to external systems, and the docs compare it to a USB-C port for AI applications. The specification says the design takes some inspiration from the Language Server Protocol. Anthropic open-sourced the protocol on November 25, 2024; the announcement started from the observation that every new data source required its own custom implementation. MCP replaces those fragmented integrations with a single protocol.

On December 9, 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation; the AAIF's co-founders are Anthropic, Block and OpenAI. According to the Linux Foundation, more than 10,000 MCP servers had been published by then. As the governance page explains, changes to the specification go through Specification Enhancement Proposals (SEPs). We cover the model side in our LLM article and the agent side in our AI agent article.

MCP architecture: host, client and MCP server

According to the specification, the architecture has three components:

  • Host: The AI application the user works in. It creates the clients, enforces security policies and consent requirements, and handles user authorization decisions.
  • Client: A connector inside the host; each client communicates with exactly one server.
  • Server: A program that provides context and capabilities to clients; it can be a local process or a remote service.

One design principle matters for security: servers should not be able to read the whole conversation or see into other servers, and the full conversation history stays with the host. According to the documentation, local servers that use stdio typically serve a single client, while remote servers that use Streamable HTTP typically serve many.

The transport layer: stdio, Streamable HTTP and JSON-RPC 2.0

Messages use JSON-RPC 2.0, which its specification defines as a stateless, light-weight and transport-agnostic remote procedure call (RPC) protocol. MCP defines two standard transports:

  • stdio: The client launches the server as a subprocess; messages travel over standard input and output, one message per line.
  • Streamable HTTP: The server exposes a single HTTP endpoint and the client sends each message as its own POST; the reply comes back as a JSON object or as an SSE (Server-Sent Events) stream scoped to that request.

On Streamable HTTP, servers must validate the Origin header to prevent DNS rebinding attacks, and a server running locally should bind only to 127.0.0.1.

MCP capabilities: tools, resources and prompts

The specification classifies a server's three primitives by who controls them:

  • Prompts: Templates the user invokes by choice, such as slash commands or menu options.
  • Resources: Data the application attaches as context, such as file contents or git history.
  • Tools: Functions the model calls to take action, such as a POST request to an API or writing a file.

On the client side, the active feature is elicitation: a server asks the user for additional information through the client, but it must not use a form to request passwords, API keys or access tokens. Revision 2026-07-28, released on July 28, 2026 and the current version as of October 2026, deprecated sampling, roots and logging; they still work but become eligible for removal in the first revision released on or after July 28, 2027. The same revision made the protocol stateless by removing the initialize handshake: every request now carries its own protocol version and client capabilities, and clients can learn a server's capabilities with a server/discover call.

What does a tool call (tools/call) look like?

The client first uses tools/list to learn the available tools and the JSON Schema describing each tool's input, then calls a tool with tools/call. Here is a sample request in the format the specification defines:

{
  "jsonrpc": "2.0", "id": 3, "method": "tools/call",
  "params": {
    "name": "check_stock", "arguments": { "sku": "EX-1042" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

The protocol version and client capabilities in _meta are required on every request. The server replies with the same id and a result whose resultType is complete; the tool's output arrives in the content array, and errors from the tool itself are reported with isError: true. The specification says there should always be a human in the loop with the ability to deny tool invocations.

How is MCP different from an API?

An API is the request-and-response contract one piece of software offers to others; our glossary has a short definition. MCP does not replace APIs: the specification's security guidance separately describes MCP servers that connect clients to third-party APIs. The differences come down to three points:

  • Discovery: Code that uses an API knows its endpoints in advance; an MCP client learns the available tools at runtime with tools/list.
  • Audience: Tool descriptions and schemas are written for the model to read, and the model decides when to call a tool.
  • One format: Every server uses the same message structure, so a host can connect a new system without writing separate integration code.

Authorization in MCP: OAuth and least privilege

In the specification, authorization is optional and defined for HTTP-based transports; implementations using stdio should retrieve credentials from the environment instead. Over HTTP, a protected MCP server acts as an OAuth 2.1 resource server and the MCP client as an OAuth client. The specification builds on the OAuth 2.1 draft and on standards such as RFC 9728 and RFC 8707:

  • Declaring the audience: The client uses the resource parameter from RFC 8707 to state which server the token is for.
  • Validating the audience: The server accepts only tokens issued for it, and must not accept or pass on any other token.
  • Narrow scopes: The client requests only the scopes it needs, and asks for missing permissions when an operation requires them.

We cover the principle of least privilege in our IAM article; this layer is the subject of our identity management service.

MCP security: the attacks the specification warns about

According to the specification, MCP itself cannot enforce its security principles at the protocol level; that falls to the people who implement it. The Security Best Practices document describes the main attacks:

  • Confused deputy: A proxy server that connects to a third-party API with a static client ID can let an attacker obtain an authorization code without the user's consent. The fix is per-client consent.
  • Token passthrough: A server accepting a token that was not issued for it and passing it on to a downstream API; the specification explicitly forbids it.
  • SSRF: During OAuth discovery, a malicious server can steer the client toward internal network addresses or a cloud metadata endpoint.
  • Local server compromise: A local server runs with the client's privileges. The client should show the exact command without truncation, require explicit approval, and launch the server in a sandbox with minimal privileges.

Tool descriptions, supply chain and MCP in the enterprise

According to the specification, descriptions of tool behavior should be treated as untrusted unless they come from a trusted server. Microsoft's developer blog describes malicious instructions hidden in a tool description as tool poisoning, and a tool definition changed after approval as a rug pull. We explain how poisoning differs from prompt injection in our data poisoning article.

The official MCP Registry, in preview as of October 2026, hosts only metadata and verifies namespace ownership through a GitHub account or a domain; it leaves security scanning of server code to package registries and to aggregators such as server marketplaces. In an organization this translates into an approved server list, pinned package versions, narrow permissions per tool and logging of tool calls; the specification also asks clients to log tool usage for audit purposes (see our log article). We handle connecting enterprise systems in our system integration service and the infrastructure agents run on in our AI stack design and engineering service.

Frequently asked questions

What does MCP stand for? Model Context Protocol: an open standard that connects AI applications to external data sources and tools.

What is an MCP server? A program that offers tools, data and prompt templates to MCP clients. It can run as a local process or as a remote HTTP service.

What is MCP used for in AI? It lets an AI application connect to systems such as files, databases or business applications without a separate integration for each one.

What is the difference between MCP and an API? An API is a contract a service offers. MCP lets AI applications discover tools at runtime and call them all in the same way.

Is MCP secure? That depends on the implementation: the basic safeguards are user approval for tool calls, tokens issued only for that server, narrow permissions and servers from verified sources.

Sources