What is MCP Server?

How It Works

An MCP Server implements the provider side of the Model Context Protocol. It may be a local subprocess wrapping files or developer commands, or a remote service adapting databases, SaaS APIs, and internal platforms. The Host owns model orchestration, user experience, consent, and cross-server policy; an MCP Client carries protocol messages to one Server; the Server translates authorized requests into bounded backend operations. It is not the language model, a registry, a gateway, an authorization server, or the source of truth behind the adapter, and it receives only the context included in a request rather than the whole conversation by default.

Protocol revision is part of the Server contract. In MCP 2026-07-28, the Core is stateless: the Server must process each Request independently from its _meta protocol version and relevant Client Capabilities, must implement server/discover, and must return UnsupportedProtocolVersionError (-32022) with supported versions when necessary. It cannot infer identity, capabilities, task, or conversation from a connection, process, or response stream. Durable business state belongs behind an explicit, scoped handle supplied on every later Request. MCP 2025-11-25 and earlier revisions are Legacy and establish protocol state with initialize and notifications/initialized; a Dual-era Server must keep Modern and Legacy semantics separate instead of silently mixing them.

A Server advertises only the primitives it implements. Tools are model-controlled actions, Resources are application-controlled context addressed by URI, and Prompts are user-controlled templates by interaction convention; MCP does not force a particular UI. Capability discovery is not authorization. tools/list, resources/list, and prompts/list may be empty or filtered by credentials presented on that Request, but they must not change merely because another Request used the same connection. Return deterministic ordering, pagination cursors, truthful cache scope and TTL, and change notifications only when the declared capability supports them.

Tool contracts need precise descriptions and valid JSON Schema. Schemas without $schema use JSON Schema 2020-12; network $ref resolution must be disabled by default, and composition depth and validation work need bounds. Validate arguments before execution and ensure structuredContent conforms when an outputSchema is declared. Keep protocol errors separate from domain failures, limit output bytes and media, and treat descriptions, annotations, Resource content, Prompt content, and downstream responses as untrusted data. An annotation such as readOnlyHint is useful metadata, not proof that an operation is harmless or authorized.

When a supported tools/call, resources/read, or prompts/get operation needs Elicitation, Sampling, or Roots, a Modern Server returns resultType: "input_required" through Multi Round-Trip Requests instead of initiating a JSON-RPC Request. Any requestState that returns through the Client is attacker-controlled. Protect integrity with HMAC or AEAD when it affects access or behavior; bind it to the authenticated Principal, a short TTL, method, and salient parameter digest; enforce single use when replay could duplicate an effect; and never assume the Client will answer or retry.

The standard Transports are stdio and Streamable HTTP. A stdio Server reads one newline-delimited JSON-RPC message from stdin and writes only protocol messages to stdout; logs belong on stderr, and EOF is the graceful shutdown signal. A Modern HTTP Server exposes one POST endpoint and returns JSON or a Request-scoped SSE stream. It validates Origin, the body/header protocol version, Mcp-Method, and required Mcp-Name values; a local listener should bind to loopback; and it should stop cancelled work as soon as practical when the response stream closes. Protocol-level Sessions, the standalone HTTP+SSE Transport, GET streams, and stream resumption are Legacy or removed, not current defaults.

Authorization is optional at the protocol level, but a protected HTTP Server acts as an OAuth Resource Server. It publishes Protected Resource Metadata, validates that every Bearer Token was issued for its own Audience, distinguishes unauthenticated 401 from insufficient-scope 403, and rejects Token Passthrough. Scope is only a coarse permission boundary: each Tool, Resource, Prompt, Tenant, object, purpose, and side effect still needs deterministic application authorization. A stdio Server obtains credentials from its execution environment instead of applying the HTTP OAuth profile, and should run with a minimal filesystem, process, and network sandbox.

Production safety extends beyond protocol validity. Sanitize Resource URIs and file paths, prevent traversal and uncontrolled egress, isolate tenants and downstream credentials, rate-limit expensive calls, apply timeouts and cancellation, and place idempotency keys or transactional guards before retryable side effects. Do not let Tool output, Resource text, or Prompt instructions override Host policy. Trace the immutable Server build, protocol era and revision, transport, Principal and Tenant, effective policy, method and capability revision, target Tool or Resource, Request ID, MRTR step, idempotency decision, latency, error class, cancellation, and final effect status without logging tokens, secrets, or unrestricted payloads.

Use an MCP Server when multiple compatible Hosts need a discoverable, versioned interface to a bounded capability domain. Keep existing APIs and databases as authoritative backends, and add a Gateway or Registry only when fleet-level routing, inventory, or policy requires one. A conforming Server standardizes discovery and exchange; it does not automatically make an integration portable, trustworthy, correctly authorized, idempotent, or operationally ready.

Key Characteristics

• Explicit role boundary: exposes protocol capabilities while the Host retains model orchestration, consent, and cross-server policy
• Modern stateless contract: validates per-request version and capabilities, implements server/discover, and uses explicit handles for durable state
• Distinct primitives: declares Tools, Resources, and Prompts with separate discovery, control, Schema, caching, and error semantics
• Transport-aware endpoint: preserves stdio framing or Streamable HTTP headers, Origin checks, Request-scoped streams, cancellation, and shutdown
• Resource-server security: validates Audience, Scope, Tenant, object, operation, and purpose without accepting token passthrough or trusting metadata
• Effect-aware operations: bounds input and output, validates results, makes retries idempotent, isolates dependencies, and emits redacted audit evidence

Common Use Cases

1. Expose a narrow, read-only repository or documentation capability to local coding Hosts through stdio
2. Adapt a remote SaaS or internal API to scoped Tools with OAuth, object-level authorization, rate limits, and audit records
3. Publish tenant-filtered Resources and URI Templates without exposing the underlying database or filesystem directly
4. Offer user-selected domain Prompts while keeping their content subordinate to Host policy and input validation
5. Run horizontally scaled Streamable HTTP instances with explicit state handles, bounded retries, and idempotent side effects

Frequently Asked Questions

Related Tools

Related Terms

Related Articles