Production-Ready MCP #1: From Localhost to Production on Kubernetes

1. Introduction

1.1 The N×M Problem in AI Integration

The promise of Generative AI lies in its ability to reason over proprietary data. Historically, connecting Large Language Models (LLMs) to internal data sources required fragile, custom integrations, creating what Anthropic described as the "N × M problem" where each new data source (database, document repository, ERP API) required a bespoke connector for each AI platform.

The Model Context Protocol (MCP) standardizes this integration through three fundamental primitives:

• Resources: Passive data sources (file logs, database records) that can be read by models
• Tools: Executable functions enabling model actions (e.g., "create Jira ticket")
• Prompts: Pre-defined interaction templates guiding agent behavior

1.2 Research Context and Motivation

As enterprises like Microsoft integrate MCP into core systems (Dynamics 365 ERP for "adaptive intelligent operations"), the underlying infrastructure must evolve beyond occasional queries to support continuous agentic orchestration. This research addresses critical gaps in production deployment knowledge:

1. How does the protocol transport evolution impact network infrastructure?
2. What are the architectural patterns for stateful session management in distributed environments?
3. What performance characteristics can be expected under production loads?

2. Protocol Evolution: From SSE to Streamable HTTP

2.1 Architectural Limitations of Server-Sent Events

In pre-2025 MCP implementations, remote transport relied on Server-Sent Events (SSE). This architecture mandated two distinct, decoupled endpoints:

• An HTTP POST endpoint for receiving client commands
• A separate SSE endpoint for streaming asynchronous responses and notifications

This duality introduced severe operational complexity in distributed environments. The client managed the lifecycle of two independent connections. If the SSE connection dropped (which is common in mobile networks or behind aggressive corporate proxies), the server lost response capability while commands continued arriving via POST. System state became inconsistent, requiring complex reconnection and resynchronization logic on the client side.

Additionally, corporate firewalls frequently inspect and terminate long-lived HTTP connections showing intermittent traffic, interpreting them as potential data exfiltration channels or "zombie" connections.

Think of it this way: The SSE architecture is like trying to coordinate a project using two separate apps (WhatsApp for sending messages and Email for receiving responses). If your email connection drops but WhatsApp keeps working, you're sending questions without knowing nobody can answer you back. The dual-channel SSE approach had exactly this problem: one channel for sending (POST), another for receiving (SSE). If one failed, the system became deaf or mute, but not completely offline, making diagnosis even harder.

sequenceDiagram
    participant Client as MCP Client
    participant PostEP as POST Endpoint
    participant SseEP as SSE Endpoint
    participant ModernEP as Unified Endpoint
    participant Server as MCP Server

    Note over Client: Claude / ChatGPT
    Note over PostEP: Legacy: /messages
    Note over SseEP: Legacy: /sse
    Note over ModernEP: Modern: /mcp

    rect rgb(40, 20, 20)
        Note over Client,Server: LEGACY: Dual-Channel (SSE + POST)

        Client->>PostEP: 1. HTTP POST (send command)
        PostEP->>Server: Forward command
        Note over Client,PostEP: Connection 1: POST for sending

        Server->>SseEP: Process and prepare response
        SseEP-->>Client: 2. SSE Stream (receive response)
        Note over SseEP,Client: Connection 2: SSE for receiving

        Note right of Server: TWO SEPARATE CONNECTIONS
        Note right of Server: If POST fails: can't send
        Note right of Server: If SSE fails: can't receive
        Note right of Server: Partial failure hard to diagnose
    end

    rect rgb(20, 50, 30)
        Note over Client,Server: MODERN: Unified Streamable HTTP

        Client->>ModernEP: 1. HTTP POST (send command)
        ModernEP->>Server: Process command
        Note over Client,ModernEP: Single bidirectional connection

        Server->>ModernEP: Prepare response
        ModernEP-->>Client: 2. HTTP Response (chunked streaming)
        Note over ModernEP,Client: Same connection for response

        Note right of Server: ONE HTTP CONNECTION
        Note right of Server: Standard HTTP/1.1
        Note right of Server: Infrastructure friendly
        Note right of Server: Simple: up or down
    end
                    

2.2 Streamable HTTP: Unified Transport Mechanics

The Streamable HTTP specification, formalized in the 2025-06-18 revision, unifies communication into a single HTTP endpoint (e.g., /mcp), eliminating parallel channel requirements. The server operates as an independent process handling multiple concurrent client connections.

Communication utilizes standard HTTP verbs (POST, GET) with enhanced semantics for bidirectional JSON-RPC:

• Direct Request-Response: Simple commands (list tools) follow classic HTTP: Request → Processing → Response
• Streaming via Chunked Transfer: Long-running operations use Chunked Transfer Encoding, allowing servers to send response chunks as they become available without knowing total message size a priori
• Infrastructure Compatibility: Single-channel HTTP traffic becomes indistinguishable from normal web traffic to load balancers, WAFs, and CDNs, drastically simplifying security policy and routing configuration

3. FastMCP Framework Implementation

3.1 Introduction to FastMCP

FastMCP is a Python framework that simplifies the development of MCP servers by providing high-level abstractions over the protocol specification. Built on modern async Python patterns, FastMCP handles the complexity of JSON-RPC communication, capability negotiation, and transport management, allowing developers to focus on implementing business logic for tools, resources, and prompts.

The framework supports both stdio transport (for local development) and HTTP transport (for production deployments), making it ideal for rapid prototyping and scalable production systems.

3.2 Basic Server Implementation

A minimal MCP server using FastMCP requires only a few lines of code. The following example demonstrates creating a server that exposes a database query tool:

from fastmcp import FastMCP

# Initialize the MCP server
mcp = FastMCP("Database Query Server")

@mcp.tool()
def query_users(limit: int = 10):
    """Query users from database with configurable limit"""
    # Database connection and query logic
    users = fetch_users_from_db(limit)
    return {
        "count": len(users),
        "users": users
    }

@mcp.tool()
def search_products(query: str, category: str = None):
    """Search products by name or category"""
    filters = {"name": query}
    if category:
        filters["category"] = category

    products = search_in_catalog(filters)
    return {
        "results": products,
        "total": len(products)
    }

# Run the server (stdio for development)
if __name__ == "__main__":
    mcp.run()

3.3 Resource Management

Resources represent passive data sources that LLMs can read. FastMCP provides decorators to expose filesystem content, database records, or API responses as MCP resources:

@mcp.resource("logs://application/{date}")
def get_application_logs(date: str):
    """Retrieve application logs for specific date"""
    log_path = f"/var/logs/app/{date}.log"
    with open(log_path, 'r') as f:
        return {
            "uri": f"logs://application/{date}",
            "mimeType": "text/plain",
            "text": f.read()
        }

@mcp.resource("config://database")
def get_database_config():
    """Return current database configuration (sanitized)"""
    return {
        "uri": "config://database",
        "mimeType": "application/json",
        "text": json.dumps({
            "host": "db.internal",
            "port": 5432,
            "database": "production",
            "pool_size": 20
        })
    }

3.4 HTTP Server for Production

For production deployments in Kubernetes, FastMCP servers must use HTTP transport. The framework integrates with ASGI servers like Uvicorn for high-performance async handling:

from fastmcp import FastMCP
import uvicorn

mcp = FastMCP("Production MCP Server")

# Tool and resource definitions...
# (same as previous examples)

# Create ASGI application
app = mcp.get_asgi_app()

if __name__ == "__main__":
    # Production server with Streamable HTTP
    uvicorn.run(
        app,
        host="0.0.0.0",
        port=8080,
        log_level="info"
    )

3.5 Integration with External State Management

For distributed deployments requiring session state management, FastMCP can integrate with Redis or other external stores through middleware patterns:

import redis
from fastmcp import FastMCP

# Redis connection pool
redis_client = redis.Redis(
    host='redis-service',
    port=6379,
    decode_responses=True,
    max_connections=50
)

mcp = FastMCP("Stateful MCP Server")

@mcp.tool()
def get_user_context(user_id: str):
    """Retrieve user context from distributed cache"""
    cache_key = f"user:context:{user_id}"
    cached_data = redis_client.get(cache_key)

    if cached_data:
        return json.loads(cached_data)

    # Fetch from primary database if not cached
    user_data = fetch_user_from_db(user_id)

    # Cache for future requests (TTL: 1 hour)
    redis_client.setex(
        cache_key,
        3600,
        json.dumps(user_data)
    )

    return user_data

4. Kubernetes Deployment Architecture

graph TB
    Client["External Client
(Claude, ChatGPT, etc.)"]

    subgraph k8s["Kubernetes Cluster"]
        Ingress["Nginx Ingress
proxy-buffering: off
mcp.company.com"]
        Service["Service (LoadBalancer)
Port 8080"]

        subgraph pods["HPA Auto-Scaled Pods (Network Policy Protected)"]
            Pod1["MCP Pod 1
FastMCP Server
Uvicorn ASGI
Stateless"]
            Pod2["MCP Pod 2
FastMCP Server
Uvicorn ASGI
Stateless"]
            Pod3["MCP Pod 3
FastMCP Server
Uvicorn ASGI
Stateless"]
        end

        Redis[("Redis Cluster
Session State Store
HA with Sentinel")]
    end

    Client -->|"HTTPS"| Ingress
    Ingress --> Service
    Service -.->|"Load Balanced"| Pod1
    Service -.->|"Load Balanced"| Pod2
    Service -.->|"Load Balanced"| Pod3
    Pod1 & Pod2 & Pod3 -->|"Session State"| Redis

    classDef clientStyle fill:#1e293b,stroke:#ec4899,stroke-width:2px,color:#f8fafc
    classDef ingressStyle fill:#1e293b,stroke:#8b5cf6,stroke-width:2px,color:#f8fafc
    classDef serviceStyle fill:#1e293b,stroke:#10b981,stroke-width:2px,color:#f8fafc
    classDef podStyle fill:#1e293b,stroke:#6366f1,stroke-width:2px,color:#f8fafc
    classDef redisStyle fill:#1e293b,stroke:#f59e0b,stroke-width:2px,color:#f8fafc

    class Client clientStyle
    class Ingress ingressStyle
    class Service serviceStyle
    class Pod1,Pod2,Pod3 podStyle
    class Redis redisStyle

4.1 Container Optimization and Security

The foundation of scalability is an efficient container image. Best practices for MCP include multi-stage builds separating compilation dependencies (e.g., C compilers for Python libraries) from runtime dependencies, yielding smaller, more secure images.

Security hardening requires running the server process as a non-root user to mitigate privilege escalation risks if the container is compromised. Secrets (authentication tokens, API keys) must never be embedded in images. Instead, use Kubernetes Secrets injected as environment variables or mounted volumes at runtime.

4.2 Ingress Controller Configuration Challenges

One of the most insidious problems in Kubernetes MCP deployment is default buffering behavior in Ingress controllers, specifically Nginx Ingress Controller. Nginx is designed to optimize web content delivery by buffering responses before sending to clients. For Streamable HTTP, where Time-to-First-Token (TTFT) latency is critical to user experience, this behavior is destructive.

If buffering is active, the MCP server may send response chunks, but Nginx retains them until the buffer fills or the connection closes. To the LLM client, this appears as an unresponsive server.

Think of it this way: Nginx with buffering enabled acts like a waiter who decides not to bring your dishes until they have 100 plates accumulated "to save trips." For a normal dinner, maybe it works. But when you're having a real-time conversation, like an LLM processing a complex query and streaming results in chunks, you want each dish as soon as it's ready, not waiting for dessert while your appetizer gets cold. With buffering on, response chunks get held in Nginx while the client thinks the server has frozen.

sequenceDiagram
    participant MCP as MCP Server
    participant Nginx as Nginx Ingress
    participant Client as LLM Client

    Note over MCP: Sends chunks
    Note over Nginx: Buffering: ON
    Note over Client: Waiting...

    rect rgb(40, 20, 20)
        Note over MCP,Client: Problem: Nginx holds chunks in buffer
        MCP->>Nginx: Chunk 1 (streaming)
        Note right of Nginx: Buffered
        MCP->>Nginx: Chunk 2 (streaming)
        Note right of Nginx: Buffered
        MCP->>Nginx: Chunk 3 (streaming)
        Note right of Nginx: Buffered
        Nginx--xClient: Chunks blocked
        Note over Client: Appears unresponsive!
    end

    rect rgb(25, 50, 25)
        Note over MCP,Client: Solution: proxy-buffering: "off"
        MCP->>Nginx: Chunk (streaming)
        Nginx->>Client: Chunk (real-time)
        Note over Client: Receives immediately!
    end
                    

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: mcp-server-ingress
  annotations:
    nginx.ingress.kubernetes.io/proxy-buffering: "off"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
spec:
  rules:
  - host: mcp.company.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: mcp-server-service
            port:
              number: 8080

4.3 Load Balancing Strategies

The current MCP specification (v2025-06-18) maintains session state coupling. When a client connects, capability negotiation occurs and a session ID is generated. If subsequent requests from the same client route to a different server (Pod B) unaware of the initial negotiation (performed on Pod A), requests fail.

Two architectural approaches address this:

4.3.1 Session Affinity (Sticky Sessions)

The immediate but less resilient solution configures the load balancer to ensure "affinity", consistently routing a specific client's traffic to the same pod using identifiers like session cookies or source IP.

Limitations: IP-based affinity is fragile in modern networks due to NAT and mobile proxies. If the specific pod fails or restarts (common in Kubernetes), the session is irrevocably lost, forcing the client to restart the entire workflow.

4.3.2 Distributed State with Redis

To achieve true high availability and elastic scalability, architecture must decouple session state from server processes. The recommended solution uses fast distributed storage like Redis to maintain session context.

In this architecture:

• Initialization: When a session is created, the server serializes negotiated state (capabilities, auth tokens) and stores it in Redis under key mcp-session-{id}
• Execution: Each subsequent request carries mcp-session-id in headers. Any pod receiving the request queries Redis, retrieves context ("hydrates" the session), executes the operation, and updates state if necessary
• Advantage: This enables any pod to serve any request. If a pod dies, traffic automatically redirects to another healthy pod that can continue the session transparently

Think of it this way: The Redis-backed architecture is like a modern hospital's electronic health record system. When you arrive at the emergency room at 3 AM, any doctor on duty can access your complete medical history (allergies, previous surgeries, current medications). It doesn't matter which doctor saw you yesterday. And if the hospital catches fire (catastrophic failure), your records are safe in external backups. Each MCP server is a doctor who can "hydrate" the patient's session on demand from the central system.

graph TB
    subgraph sticky["Sticky Sessions (Session Affinity)"]
        LB1["Load Balancer"]
        LB1 -.->|"Pinned"| PodA1["Pod A
(Session 1,2)"]
        LB1 -.->|"Pinned"| PodB1["Pod B
(Session 3)"]
        LB1 -.->|"Pinned"| PodC1["Pod C
(Session 4,5)"]

        PodB1 x--x Fail1["Pod B crashes
Session 3 lost!"]

        Problems["Problems:
Pod failure = session loss
Uneven load distribution
Cannot freely scale"]

        style LB1 fill:#1e293b,stroke:#6366f1,stroke-width:2px
        style PodA1 fill:#1e293b,stroke:#6366f1,stroke-width:2px
        style PodB1 fill:#1e293b,stroke:#6366f1,stroke-width:2px
        style PodC1 fill:#1e293b,stroke:#6366f1,stroke-width:2px
        style Fail1 fill:#2d1b1b,stroke:#ef4444,stroke-width:2px,stroke-dasharray: 5 5
        style Problems fill:#2d1b1b,stroke:#ef4444,stroke-width:2px
    end

    subgraph redis["Redis-Backed (Distributed State)"]
        LB2["Load Balancer"]
        LB2 -.->|"Any pod"| PodA2["Pod A
(Stateless)"]
        LB2 -.->|"Any pod"| PodB2["Pod B
(Stateless)"]
        LB2 -.->|"Any pod"| PodC2["Pod C
(Stateless)"]

        PodA2 & PodB2 & PodC2 <-.->|"Session State"| RedisDB[("Redis Cluster
(All sessions)")]

        Benefits["Benefits:
Pod failure = no session loss
True horizontal scaling
Free to restart/redeploy"]

        style LB2 fill:#1e293b,stroke:#10b981,stroke-width:2px
        style PodA2 fill:#1e293b,stroke:#10b981,stroke-width:2px
        style PodB2 fill:#1e293b,stroke:#10b981,stroke-width:2px
        style PodC2 fill:#1e293b,stroke:#10b981,stroke-width:2px
        style RedisDB fill:#1e293b,stroke:#f59e0b,stroke-width:3px
        style Benefits fill:#1b2d1b,stroke:#10b981,stroke-width:2px
    end

    style sticky fill:#1a1a1a,stroke:#ef4444,stroke-width:2px,stroke-dasharray: 5 5
    style redis fill:#1a1a1a,stroke:#10b981,stroke-width:2px
                    

5. Distributed State Management

5.1 The Statelessness Paradox

While RESTful architecture preaches complete statelessness, MCP handles conversations and contexts that are inherently continuous. Although Streamable HTTP transport is technically stateless (each HTTP request is independent), the MCP application layer is not. The protocol requires servers to remember enabled tools, negotiated protocol versions, and security contexts.

Attempting pure stateless implementation today would result in loss of advanced features like server-to-client notifications and would require capability renegotiation on every tool call, introducing unacceptable latency.

Think of it this way: HTTP stateless is like having a conversation where you lose your memory after every sentence. "What's your name?" "John." "Nice to meet you, what's your name?" "I just told you, John!" This works for isolated web pages (each click is independent), but LLMs are having continuous conversations, multi-step reasoning, using tools in sequence. They need to "remember" which tools were enabled, what security context was negotiated, and what capabilities were agreed upon during session initialization. That's why MCP needs state, even while running over stateless HTTP.

5.2 Redis: Beyond Session Storage

Redis performs vital auxiliary roles in scalable MCP architecture beyond session management:

• Response Caching: Tools querying slowly-changing data (e.g., "list database tables") can cache responses in Redis, reducing backend system load
• Vector Search: With search modules, Redis can act as the agent's long-term memory, enabling Retrieval-Augmented Generation (RAG) directly at the cache layer

sequenceDiagram
    participant Client
    participant PodA as Pod A
    participant PodB as Pod B (Different!)
    participant PodC as Pod C
    participant Redis as Redis Cluster

    rect rgb(25, 40, 60)
        Note over Client,Redis: Step 1: Session Initialization
        Client->>PodA: 1. Initialize
        PodA->>Redis: 2. Store session
{session-id: abc123,
capabilities, auth, version}
        Note right of Redis: Stored
    end

    rect rgb(20, 50, 30)
        Note over Client,Redis: Step 2: Execute on Different Pod
        Client->>PodB: 3. Tool call
(session: abc123)
        Note right of PodB: Different pod!
        PodB->>Redis: 4. Hydrate session state
        Redis-->>PodB: Session context
        PodB-->>Client: 5. Execute & respond
        Note over Client,PodB: Any Pod Can Handle Request
    end

    rect rgb(40, 20, 20)
        Note over Client,Redis: Step 3: Transparent Failover
        Client-xPodA: Request (Pod A crashed)
        Note right of PodA: Pod A Failed
        Client->>PodC: 6. Retry to Pod C
        PodC->>Redis: 7. Fetch session
        Note right of Redis: Session intact!
        Redis-->>PodC: Session context
        PodC-->>Client: 8. Continue execution
        Note over Client,PodC: Transparent Failover
No data loss!
    end

6. Performance Considerations

6.1 Latency Factors in Distributed MCP Architecture

Performance in distributed MCP deployments is influenced by several architectural factors. The primary latency components include:

• Network Round-Trip Time: Communication between client, Ingress controller, MCP server pod, and Redis adds cumulative latency. Geographic distribution and network topology significantly impact total response time
• Redis Access Latency: Session state retrieval from Redis typically adds single-digit millisecond overhead in well-configured clusters. Redis Sentinel or Cluster mode selection affects consistency versus latency trade-offs
• Pod Scheduling and Routing: Load balancer algorithms (round-robin, least connections) and pod readiness impact request distribution efficiency
• Serialization Overhead: JSON-RPC message encoding/decoding and session state serialization contribute to processing time

6.2 Scalability Characteristics

The Redis-backed architecture enables horizontal scalability with important considerations:

6.3 Performance Optimization Strategies

To achieve optimal performance in production MCP deployments, consider:

1. Redis Configuration: Use Redis pipelining for batch operations, enable persistence (RDB/AOF) based on durability requirements, and configure appropriate maxmemory-policy (e.g., allkeys-lru for cache-like behavior)
2. Connection Pooling: Maintain persistent Redis connection pools in MCP server processes to avoid connection establishment overhead on each request
3. Caching Strategy: Implement multi-tier caching with in-process cache for frequently accessed immutable data and Redis for shared mutable state
4. Resource Limits: Set appropriate Kubernetes resource requests and limits to prevent pod eviction while allowing efficient bin-packing
5. Monitoring: Instrument latency metrics at each layer (Ingress, application, Redis) to identify bottlenecks

7. Security Considerations

7.1 OAuth 2.0 Integration

The 2025-06-18 specification formalizes MCP servers as Resource Servers in OAuth 2.0 flows, elevating security standards. Static API keys are discouraged due to rotation and revocation difficulties.

Recommended architecture involves:

• Short-lived Access Tokens: Clients obtain tokens from identity providers (Azure AD, Okta) and present via Authorization: Bearer header
• Token Security: Tokens should be bound to the client using DPoP (Demonstration of Proof-of-Possession, RFC 9449) or mTLS (RFC 8705), preventing token theft and replay attacks where tokens are intercepted and reused by attackers
• Scope Validation: Servers must validate not only token validity but required scopes for specific tool execution (e.g., read-only tokens cannot execute deletion tools)

7.2 Network Isolation

In multi-tenant Kubernetes clusters, assuming internal network security is a mistake (Zero Trust approach). Kubernetes NetworkPolicies should restrict ingress traffic to MCP pods, allowing connections only from:

• Ingress Controller (port 8080)
• Prometheus (port 9090 for metrics)

Egress should be limited to Redis (port 6379), specific external APIs, and cluster DNS. This prevents compromised pods in other namespaces from laterally attacking the MCP server.

8. Future Roadmap & Specification Enhancement Proposals

8.1 SEP-1686: Asynchronous Operations

Current MCP operates predominantly synchronously: client requests, waits, and receives. For tasks requiring minutes or hours (e.g., "analyze all security logs from last month"), the synchronous model breaks due to HTTP timeouts.

SEP-1686 introduces formal Tasks concept:

• Client initiates operation and immediately receives task_id
• Client polls status or subscribes to progress notifications via SSE
• Architectural Impact: Requires message queue integration (RabbitMQ, SQS) and background workers. Architecture shifts from pure Request/Response to event-driven, enabling resilience to network disconnections during long processes

8.2 SEP-1442: True Statelessness

SEP-1442 aims to fundamentally resolve scalability by removing persistent session state requirements from servers. The proposal modifies the protocol so all necessary execution context is transmitted with requests or standardizes recoverable state mechanisms.

Impact: If implemented, this change would enable Serverless architectures (AWS Lambda, Knative) for hosting MCP servers, drastically reducing operational costs and complexity as Sticky Sessions and Redis requirements disappear for many use cases.

9. Conclusion

Operationalizing the Model Context Protocol at enterprise scale is a multidisciplinary challenge intersecting software engineering, DevOps, and security. The transition to Streamable HTTP has significantly simplified the transport layer, making MCP compatible with modern web infrastructure, but state management and proxy configuration remain common pitfalls.

For successful scalable MCP server deployment in Kubernetes, we recommend:

1. Adopt Streamable HTTP: Abandon SSE-based implementations to avoid network compatibility issues
2. Externalize State: Use Redis for session management, avoiding Sticky Session fragility and enabling true horizontal scalability
3. Fine-tune Ingress: Disable Nginx buffering and adjust timeouts to support AI interaction streaming nature
4. Layered Security: Implement OAuth 2.0 with scope validation and consider mTLS for internal traffic
5. Deep Observability: Implement structured logging and distributed tracing to demystify probabilistic LLM interactions
6. Prepare for Future: Design modular code architecture facilitating future adoption of asynchronous patterns (SEP-1686) and stateless designs (SEP-1442)

MCP is paving the way for a new era of connected systems where the barrier between AI reasoning and corporate data is dissolved. With correct architecture, organizations can transform this promise into robust, scalable competitive advantage.

10. References

1. Anthropic. (2025). "Introducing the Model Context Protocol." Anthropic News. Retrieved from https://www.anthropic.com/news/model-context-protocol
2. Model Context Protocol. (2025). "Specification 2025-06-18." Official MCP Documentation. Retrieved from https://modelcontextprotocol.io/specification/2025-06-18
3. Lowin, J. (2025). "FastMCP: The fast, Pythonic way to build MCP servers and clients." FastMCP Documentation. Retrieved from https://gofastmcp.com
4. Microsoft. (2025). "Evolving the Dynamics 365 ERP Model Context Protocol Server." Microsoft Dynamics 365 Blog. Retrieved from https://www.microsoft.com/en-us/dynamics-365/blog/it-professional/2025/11/11/dynamics-365-erp-model-context-protocol/
5. Lammers, A. (2025). "Understanding Model Context Protocol (with Streamable HTTP)." Technical Blog. Retrieved from https://www.alexanderlammers.net/2025/06/29/understanding-model-context-protocol-with-streamable-http/
6. Redis Labs. (2025). "Introducing Model Context Protocol (MCP) for Redis." Redis Blog. Retrieved from https://redis.io/blog/introducing-model-context-protocol-mcp-for-redis/
7. Kubernetes Project. (2025). "Horizontal Pod Autoscaling." Kubernetes Documentation. Retrieved from https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
8. Vijay Kumar, A. B. (2025). "Model Context Protocol Deep Dive: Deployment Patterns." Medium. Retrieved from https://abvijaykumar.medium.com/model-context-protocol-deep-dive-part-3-2-3-hands-on-deployment-patterns-3c2c45e65efb
9. Model Context Protocol. (2025). "Roadmap and Specification Enhancement Proposals." MCP Development. Retrieved from https://modelcontextprotocol.io/development/roadmap
10. Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., & Waite, D. (2023). "OAuth 2.0 Demonstrating Proof of Possession (DPoP)." RFC 9449, IETF. Retrieved from https://datatracker.ietf.org/doc/html/rfc9449
11. Campbell, B., Bradley, J., Sakimura, N., & Lodderstedt, T. (2020). "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens." RFC 8705, IETF. Retrieved from https://datatracker.ietf.org/doc/html/rfc8705