modelcontextprotocol

Implements a standardized JSON-RPC 2.0 message system enabling bidirectional communication between MCP clients and servers through structured request/response/notification patterns. Messages are serialized as JSON with explicit method names, parameters, and correlation IDs, allowing both clients and servers to initiate requests and handle asynchronous responses. The protocol supports notifications (fire-and-forget messages) and distinguishes between successful responses and error objects with standardized error codes.

Provides a pluggable transport abstraction that decouples the JSON-RPC message protocol from underlying communication channels. Implementations can use stdio (for local process spawning), HTTP with Server-Sent Events (for request-response patterns), or WebSocket (for persistent bidirectional connections). Each transport handles framing, connection lifecycle, and error recovery independently while maintaining identical JSON-RPC semantics at the protocol layer.

Provides a debugging tool (MCP Inspector) that intercepts and displays all JSON-RPC messages exchanged between clients and servers in real-time. The tool shows request/response pairs, message timing, error details, and payload contents. It supports message filtering, search, and export for offline analysis. The inspector can replay messages to reproduce issues and validate server behavior under specific conditions.

Establishes a tiered SDK ecosystem with reference implementations in TypeScript (Tier 1), Python (Tier 1), and community implementations in Rust, Go, Java, and others. Tier 1 SDKs provide complete protocol support with conformance testing; Tier 2 SDKs provide core functionality with limited features; Tier 3 SDKs are community-maintained with variable quality. Each SDK tier is documented with feature matrices showing which protocol features are supported.

Maintains a centralized registry of ~2,000 MCP servers with indexed capabilities (tools, resources, prompts) enabling discovery by feature. The registry includes server metadata (name, description, author), capability descriptions, and links to documentation. Servers can be discovered by searching for specific tool names, resource types, or prompt templates. The registry supports filtering by language, deployment model (local, cloud), and maintenance status.

Establishes a formal process for proposing, discussing, and implementing protocol enhancements through Specification Enhancement Proposals (SEPs). SEPs are reviewed by maintainers and community members, discussed in working groups, and merged into the specification only after consensus. The process includes templates, voting procedures, and explicit criteria for acceptance. All SEPs are archived and versioned alongside protocol specifications.

Implements a capability negotiation protocol during client-server connection initialization where both parties exchange supported features, protocol versions, and implementation details through initialize and initialized messages. Clients declare their sampling capabilities, prompt support, and other features; servers declare available tools, resources, prompts, and extensions. This enables graceful degradation and feature-aware behavior without requiring out-of-band configuration.

Defines a tool system where servers expose callable functions with JSON Schema parameter definitions and descriptions. Clients can list available tools via tools/list, inspect their schemas, and invoke them via tools/call with structured parameters. The schema validation is performed by clients before invocation and by servers during execution, ensuring type safety and clear error reporting. Tools support optional descriptions, icons, and input schemas for UI generation.

Implements a resource system where servers expose files, documents, or data blobs via URI-based addressing (e.g., file://path/to/file, database://query/result). Clients can list available resources via resources/list, read resource content via resources/read, and subscribe to resource updates via resources/subscribe. Resources support MIME types, descriptions, and optional annotations. The protocol supports both complete content delivery and streaming for large resources.

Defines a prompt system where servers expose reusable prompt templates with named arguments, descriptions, and optional icons. Clients can list available prompts via prompts/list, retrieve prompt content via prompts/get with argument substitution, and receive prompt updates via prompts/updated notifications. Prompts support composition (referencing other prompts), conditional sections, and formatting hints for UI rendering.

Enables servers to request LLM inference from clients via sampling/create messages, allowing servers to generate text, code, or structured data using the client's LLM. Servers provide a prompt (or messages array), model selection, and sampling parameters (temperature, max_tokens, stop sequences). Clients stream responses back via content blocks, supporting text, tool use, and image content types. This inverts the typical client-server relationship, enabling servers to leverage client-side LLM capabilities.

Provides a task abstraction for long-running operations where clients can create tasks via tasks/create, poll progress via tasks/progress, and cancel via tasks/cancel. Tasks have unique IDs, progress tracking (percentage, status messages), and result delivery. The system supports both polling and event-based progress updates, enabling clients to monitor server-side operations without blocking. Tasks can be nested and support explicit cancellation with cleanup semantics.

Implements OAuth 2.1 authorization for MCP clients connecting to servers, supporting multiple client registration methods (static credentials, dynamic registration, PKCE flow). Clients obtain access tokens via authorization endpoints, include tokens in connection headers, and refresh tokens when expired. Servers validate tokens against issuer endpoints and enforce scope-based access control. The framework supports both bearer tokens and custom authorization schemes.

Maintains versioned protocol specifications (2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25) with explicit changelog documentation and conformance test suites. Each version is published as a JSON Schema definition (schema.json) and TypeScript type definitions (schema.ts) that serve as the single source of truth. Conformance tests validate that implementations correctly handle all protocol features, error cases, and edge cases. The framework supports semantic versioning with breaking changes documented explicitly.