Edmondo's Vault

MCP

May 18, 202611 min read

Model Context Protocol (MCP)

Overview

Model Context Protocol (MCP) is an open standard introduced by Anthropic in November 2024 for standardizing how applications provide context to large language models. MCP functions as a universal interface—analogous to “USB-C for AI applications”—enabling seamless integration between AI models and various data sources, tools, and resources. The protocol addresses the problem of fragmented integrations by providing a consistent way for LLMs to access external context.

MCP employs a client-server architecture where AI applications (hosts) connect to lightweight servers exposing specific data sources or functionalities. Communication uses JSON-RPC 2.0 for message formatting with two standard transport mechanisms: stdio for local processes and Streamable HTTP for remote connections.

Key technical components covered:

  • Client-server architecture and components
  • Transport mechanisms (stdio and Streamable HTTP)
  • Server capabilities (tools, resources, prompts)
  • Protocol lifecycle and capability negotiation
  • Sampling and LLM interaction patterns
  • Security and authorization framework
  • SDKs and implementation resources
  • Version history and specification changes

Client-Server Architecture

MCP implements a three-component architecture:

MCP Host is the AI application (Claude Desktop, IDEs, AI assistants) initiating connections to MCP servers. Manages multiple MCP clients simultaneously, coordinating integration of external data and tools. Responsible for presenting available tools to users, routing requests to appropriate servers, and aggregating responses.

MCP Client embedded within the host maintains dedicated one-to-one connection with an MCP server. Each client handles:

  • Protocol version negotiation
  • Capability exchange during initialization
  • Bidirectional communication between host and server
  • Message serialization and deserialization
  • Connection lifecycle management
  • Error handling and recovery

MCP Server is a lightweight program exposing specific data sources or functionalities via MCP standard. Examples include:

  • Data source servers: Google Drive, Slack, GitHub, Notion
  • Database servers: PostgreSQL, MySQL, MongoDB
  • API servers: REST APIs, GraphQL endpoints
  • Tool servers: Code execution, file operations, web scraping
  • Knowledge base servers: Documentation, internal wikis

Servers run as independent processes (HTTP model) or subprocesses (stdio model). A single host can connect to multiple servers simultaneously, each providing distinct capabilities. Servers remain stateless where possible, with state managed by the underlying data source.

Transport Mechanisms

MCP defines two standard transport protocols:

stdio Transport for local integrations uses standard input/output streams. Client launches MCP server as subprocess with communication through stdin/stdout:

  • Messages formatted as JSON-RPC 2.0
  • Newline-delimited messages (no embedded newlines)
  • Server writes responses to stdout
  • Server may write UTF-8 logging to stderr
  • Client can capture, forward, or ignore stderr output
  • Ideal for same-machine integrations

Streamable HTTP Transport for remote integrations uses HTTP POST and Server-Sent Events:

Server provides two endpoints:

  • SSE Endpoint: Client establishes connection to receive server messages via Server-Sent Events
  • HTTP POST Endpoint: Client sends messages to server

Connection flow:

  1. Client connects to SSE endpoint
  2. Server sends endpoint event containing URI for message posting
  3. Client sends all subsequent messages via HTTP POST to provided URI
  4. Server messages arrive as SSE message events with JSON data

Message encoding: Server messages encoded as JSON in SSE event data. Client messages sent as HTTP POST with JSON body.

Advantages: Supports multiple concurrent client connections, enables remote server deployments, works through standard HTTP infrastructure (load balancers, proxies).

Custom transports permitted provided they preserve JSON-RPC message format and lifecycle requirements. Clients encouraged to support stdio whenever possible for simplicity.

Server Capabilities: Tools, Resources, and Prompts

MCP servers expose three types of capabilities:

Tools are executable functions allowing LLMs to perform actions, process data, and interact with external systems. Each tool defined with:

  • name: Unique identifier for the tool
  • description: Natural language explanation of tool purpose and usage
  • inputSchema: JSON Schema defining required and optional parameters
  • annotations: Optional behavior hints (read-only, destructive, idempotent)

Tool execution flow:

  1. Server advertises available tools during capability negotiation
  2. Client presents tools to LLM
  3. LLM decides to invoke tool based on context
  4. Client sends tool execution request to server
  5. Server executes tool and returns results
  6. Results incorporated into LLM context

Resources are data that servers provide to clients including file contents, database records, API responses, or documentation. Resources identified by unique URIs following patterns like file:///path/to/file or db://table/record.

Resource properties:

  • uri: Unique resource identifier
  • name: Human-readable resource name
  • description: Explanation of resource contents
  • mimeType: Content type (text/plain, application/json, image/png)
  • content: Either text string or binary data (base64-encoded)

Resources support:

  • Listing: Enumerate available resources
  • Reading: Retrieve resource content by URI
  • Subscriptions: Receive notifications when resources change
  • Templates: URI templates with variables for dynamic resource access

Prompts are predefined templates guiding LLMs in specific tasks. Prompts ensure consistent, structured interactions and can:

  • Accept dynamic arguments for customization
  • Include context from resources
  • Chain multiple interaction steps
  • Provide examples and formatting instructions

Prompt structure:

  • name: Unique prompt identifier
  • description: Explanation of prompt purpose
  • arguments: Optional parameters the prompt accepts
  • messages: Array of message templates with role and content

Prompts enable:

  • Reusable interaction patterns
  • Consistent AI behavior across sessions
  • Domain-specific workflows
  • User-friendly interfaces for complex operations

Protocol Lifecycle and Capability Negotiation

MCP connection follows structured three-phase lifecycle:

Initialization Phase:

Version Negotiation: Client sends initialize request specifying supported protocol version (e.g., 2024-11-05, 2025-03-26, 2025-06-18). Server responds with same version if compatible, otherwise suggests supported version. If incompatible, client must disconnect. Date-based versioning indicates last date of backward-incompatible changes.

Capability Negotiation: Both parties declare supported features preventing unsupported operations:

Client capabilities may include:

  • roots: Provides filesystem roots
  • sampling: Supports LLM sampling requests
  • experimental: Experimental feature flags

Server capabilities may include:

  • prompts: Offers prompt templates
  • resources: Provides readable resources with optional subscriptions
  • tools: Exposes callable tools
  • logging: Supports structured logging
  • completions: Provides argument autocompletion

Both parties exchange capability lists during initialization. Only negotiated capabilities may be used during operation phase.

Operation Phase: Normal protocol communication occurs with both parties adhering to negotiated protocol version and capabilities. Messages exchanged according to JSON-RPC 2.0 format with method names indicating operation type (e.g., tools/list, resources/read, prompts/get).

Shutdown Phase: Client sends disconnect notification for graceful termination. Server closes connection and cleans up associated resources. Ensures both parties terminate session without leaving resources in inconsistent state.

Connection management best practices:

  • Implement timeout mechanisms for unresponsive connections
  • Handle network interruptions gracefully
  • Clean up resources on abnormal disconnection
  • Support reconnection with capability renegotiation

Sampling and LLM Interaction Patterns

Sampling enables MCP servers to request LLM completions through clients, facilitating sophisticated agentic behaviors:

Request-response flow:

  1. Server initiates: Sends sampling/createMessage request with messages and parameters
  2. Client reviews: Inspects and potentially modifies request (add safety instructions, inject context, alter system prompt)
  3. Client samples: Forwards processed request to connected LLM using established authentication
  4. Client reviews completion: Filters sensitive information, validates format, applies post-processing
  5. Client returns result: Server receives final LLM response and continues operation

Request parameters:

messages: Array of message objects with role (user/assistant) and content (text/image objects).

modelPreferences: Model selection guidance including:

  • hints: Array of suggested model names
  • costPriority: (0-1) Importance of minimizing costs
  • speedPriority: (0-1) Importance of low latency
  • intelligencePriority: (0-1) Importance of advanced capabilities

systemPrompt: Optional directive for model behavior.

includeContext: Scope of additional context (current server data, connected servers).

temperature: Randomness control (0-2).

maxTokens: Generation limit.

stopSequences: Array of sequences terminating generation.

metadata: Provider-specific parameters.

Response format: Includes model (name used), stopReason (endTurn/stopSequence/maxTokens), role (typically assistant), and content (generated text/images).

Security boundaries: Client maintains control throughout sampling:

  • Can reject or modify sampling requests
  • Applies safety filters to inputs and outputs
  • Manages LLM authentication and billing
  • Enforces rate limits and quotas

This design enables servers to leverage LLM capabilities while clients maintain security and policy enforcement.

Security and Authorization Framework

MCP implements comprehensive security through OAuth 2.1-based authorization:

Authentication mechanisms:

OAuth 2.1 Implementation: Standard authorization framework with:

  • Proof Key for Code Exchange (PKCE) preventing interception attacks
  • Token validation ensuring authenticity
  • Refresh token rotation for long-lived sessions
  • Secure token storage encrypted at rest

Mutual TLS (mTLS): Authenticates both clients and servers using certificates, preventing man-in-the-middle attacks. Ensures both parties verify each other’s identity before communication.

Authorization patterns:

Role-Based Access Control (RBAC): Defines roles with specific permissions implementing principle of least privilege. Users and services access only necessary resources for their functions.

Attribute-Based Access Control (ABAC): Fine-grained dynamic policy evaluation based on:

  • User attributes (role, department, clearance level)
  • Resource attributes (sensitivity, owner, type)
  • Environmental attributes (time, location, network)

Token Audience Binding: Uses Resource Indicators (RFC 8707) binding tokens to intended audiences. Ensures tokens only accepted by services they were issued for, preventing token misuse.

MCP Servers as OAuth Resource Servers: Classified as OAuth Resource Servers with protected resource metadata for discovering corresponding Authorization Server. Enables standardized authorization flows.

Security best practices:

Input validation: Validate and sanitize all inputs preventing injection attacks and ensuring data integrity.

Secure communication: Enforce HTTPS for all communications protecting data in transit from interception and tampering.

Token management:

  • Never expose tokens in logs or URLs
  • Implement token rotation policies
  • Use short-lived access tokens with longer-lived refresh tokens
  • Revoke tokens on logout or suspicious activity

Supply chain security: Verify all components including third-party tools and libraries to prevent supply chain attacks.

Regular security audits: Conduct periodic assessments including penetration testing and code reviews identifying vulnerabilities.

Version-specific security requirements (2025-06-18):

  • MCP clients MUST implement Resource Indicators (RFC 8707)
  • Protocol version specified via MCP-Protocol-Version header in HTTP
  • Lifecycle operations promoted from “SHOULD” to “MUST”

SDKs and Implementation Resources

Official SDKs provide comprehensive MCP implementation:

Python SDK (modelcontextprotocol/python-sdk):

  • Full MCP specification implementation
  • Build MCP clients connecting to any server
  • Create MCP servers exposing resources, prompts, and tools
  • Support for stdio, SSE, and Streamable HTTP transports
  • Handle all protocol messages and lifecycle events
  • Type hints for improved development experience

TypeScript SDK (modelcontextprotocol/typescript-sdk):

  • Complete MCP specification implementation
  • Build clients and servers in TypeScript/JavaScript
  • Support for stdio and SSE transports
  • Full protocol message and lifecycle handling
  • Type definitions for compile-time safety

Implementation components provided by SDKs:

  • Protocol message serialization/deserialization
  • Transport layer abstractions
  • Capability negotiation helpers
  • Error handling utilities
  • Logging integration
  • Testing utilities

Example implementations and resources:

  • MCP Server Guide & Examples: Practical examples in Python and TypeScript
  • Hugging Face MCP Course: SDK fundamentals, architecture, and core concepts
  • Amazon Q Developer Documentation: Integration guidance including server loading, tools, prompts, configuration

Server development workflow:

  1. Define tools, resources, and prompts
  2. Implement handlers for client requests
  3. Declare server capabilities during initialization
  4. Handle lifecycle events (initialize, disconnect)
  5. Implement error handling and logging
  6. Test with MCP-compatible clients

Client development workflow:

  1. Implement transport layer (stdio or HTTP)
  2. Handle protocol negotiation
  3. Discover server capabilities
  4. Present tools/prompts to users or LLMs
  5. Route requests to appropriate servers
  6. Handle responses and errors

Version History and Specification Changes

2024-11-05: Initial standardized release establishing date-based versioning system (YYYY-MM-DD) indicating last date of backward-incompatible changes. Enables incremental improvements while maintaining interoperability.

2025-03-26: Major update introducing:

  • Authorization Framework: OAuth 2.1-based comprehensive authorization enhancing security and flexibility
  • Streamable HTTP Transport: Replaced previous HTTP+SSE transport improving data transmission efficiency
  • JSON-RPC Batching: Support for sending multiple requests in single call reducing overhead (later removed)
  • Tool Annotations: Comprehensive descriptions of tool behavior (read-only, destructive, idempotent)
  • Schema Enhancements: message field in ProgressNotification, audio data support, completions capability for autocompletion

2025-06-18: Refinement release with:

  • JSON-RPC Batching Removal: Streamlined protocol by removing batching support
  • Structured Tool Output: Tools return explicitly defined structured content for better AI understanding
  • OAuth Resource Servers: Classified MCP servers as OAuth Resource Servers with metadata for Authorization server discovery
  • Resource Indicators: Required implementation of RFC 8707 preventing malicious servers from obtaining access tokens
  • Security Best Practices: Clarified security considerations with new dedicated documentation page
  • Elicitation Support: Servers can request additional user information during interactions
  • Resource Links: Tool call results can include resource links enhancing discovery
  • Protocol Version Negotiation: Required MCP-Protocol-Version header in subsequent HTTP requests
  • Lifecycle Operation Update: Changed recommendation from “SHOULD” to “MUST” emphasizing importance

2025-11-05 (Upcoming): Scheduled release November 25, 2025 with release candidate November 11, 2025. 14-day RC validation window. Priority areas:

  • Asynchronous Operations: Support for long-running tasks
  • Statelessness and Scalability: Enhanced server performance and deployment flexibility
  • Server Identity: Servers advertise identity through .well-known URLs for discovery
  • Official Extensions: Recognize and document industry-specific extensions
  • SDK Support Standardization: Clear guidelines for developers

Specification evolution reflects focus on security enhancements (OAuth 2.1, Resource Indicators), improved developer experience (structured outputs, annotations), and enterprise readiness (scalability, standardization).

Claude Desktop Integration

Configuration location varies by platform:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
  • Windows: %APPDATA%\Claude\claude_desktop_config.json
  • Linux: ~/.config/claude/claude_desktop_config.json

Configuration format:

{
  "mcpServers": {
    "ServerName": {
      "command": "command-to-launch-server",
      "args": ["arg1", "arg2"],
      "env": {
        "ENVIRONMENT_VARIABLE": "value"
      }
    }
  }
}

stdio server example:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/files"]
    }
  }
}

HTTP server example:

{
  "mcpServers": {
    "remote-server": {
      "command": "uvx",
      "args": [
        "mcp-proxy",
        "--transport", "streamablehttp",
        "http://localhost:8000/mcp"
      ],
      "env": {
        "API_KEY": "your-api-key"
      }
    }
  }
}

Integration workflow:

  1. Edit configuration file adding MCP server entries
  2. Restart Claude Desktop to apply changes
  3. Verify integration by accessing server tools in Claude interface
  4. Server capabilities appear automatically in Claude’s tool selection

Multiple server support: Configure multiple servers simultaneously, each with unique name. Claude Desktop manages connections to all configured servers, presenting combined set of tools and resources to user.

Graph View

Backlinks

  • No backlinks found