Arrange Act Assert

Jag Reehals thinking on things, mostly product development

From Static to Stateful: Revolutionising AI Communication with the MCP Protocol

10 Mar 2025

MCP standardises how AI applications communicate with external systems using JSON‑RPC 2.0 over stateful, bidirectional connections. Unlike standard JSON‑RPC, which treats every request independently, MCP augments the protocol by embedding session tokens and context IDs into each message.

This enhancement provides state, enabling advanced, multi‑step interactions and dynamic module loading at runtime. Such a stateful design is essential for modern, agile AI systems.

Imagine an AI‑powered payments system that dynamically integrates a new fraud detection module during operation. MCP allows the system to load this module on the fly without a full redeployment, provided the server supports dynamic module loading.

In this post, we'll explore the MCP protocol, its core components, and how it compares to traditional REST and GraphQL APIs.

Core Components

Advantages:

Disadvantages:

flowchart LR
    subgraph "MCP Core Components"
        direction LR
        A["Client<br/>(Requests & Callbacks)"] --- C
        C --- B["Server<br/>(Tools & Resources)"]
        C["Protocol Layer<br/>(JSON-RPC 2.0+)"]

        C -.-> D[("Session<br/>Tokens")]
        C -.-> E[("Context<br/>IDs")]
    end

    A <===> |"Stateful<br/>Bidirectional<br/>Communication"| B

    classDef component fill:#4285f4,stroke:#333,stroke-width:1px,color:white,rounded:true
    classDef token fill:#fbbc05,stroke:#333,stroke-width:1px,color:#333,rounded:true

    class A,B,C component
    class D,E token

    style A font-weight:bold
    style B font-weight:bold
    style C font-weight:bold

Technical Deep Dive

State Management

MCP's implementation of statefulness builds on the foundation of JSON‑RPC. While standard JSON‑RPC treats each request as stateless, MCP embeds unique session tokens and context IDs into every message. This approach allows the server to:

State Management Interaction Diagram

sequenceDiagram
    autonumber
    participant Client
    participant Server

    rect rgb(240, 248, 255)
    Note over Client,Server: Session Initialization
    Client->>Server: Initiate Connection (JSON‑RPC Request)
    Server-->>Client: Respond with Session Token & Context ID
    end

    rect rgb(245, 245, 245)
    Note over Client,Server: Stateful Interaction
    Client->>Server: Request with Session Token & Context ID
    alt Context Valid
        Server-->>Client: Response with Updated Context
        Client->>Server: Follow-up Request (with updated context)
        Server-->>Client: Final Result (context-aware)
    else Context Invalid
        Server-->>Client: Error: Invalid Context
    end
    end

Security

MCP's security is built on a layered approach, incorporating additional steps to safeguard dynamic interactions and state management.

Security Layers Diagram

flowchart TD
    A[Client Request] --> B[JSON‑RPC Message]
    B --> |"Embedded Security"| C{"Session Token,<br/>Context ID &<br/>Auth Token"}
    C --> D[TLS Encryption]
    D --> E[Authentication<br/>& Authorization]
    E --> F[Token Validation]
    F --> G[Access Control]
    G --> H[Secure Processing]

    classDef process fill:#4285f4,stroke:#333,stroke-width:1px,color:white,rounded:true
    classDef security fill:#0f9d58,stroke:#333,stroke-width:1px,color:white,rounded:true
    classDef tokens fill:#fbbc05,stroke:#333,stroke-width:1px,color:#333,rounded:true

    class A,B,H process
    class D,E,F,G security
    class C tokens

Error Handling

MCP integrates robust error handling mechanisms to ensure reliable interactions even in complex, stateful sessions.

Error Handling Sequence Diagram

sequenceDiagram
    autonumber
    participant Client
    participant Server

    Client->>Server: Function call request (with session token)
    alt Error Scenario
        Server--x Client: Error Response
        Note over Client,Server: Error Code, Message & Recovery Hints
        Client->>Server: Retry with Error Handling Strategy
        alt Recovery Successful
            Server-->>Client: Success Response
        else Persistent Error
            Server--x Client: Escalated Error With Diagnostics
        end
    else Success Scenario
        Server-->>Client: Success Response with Updated State
    end

Tools, Prompts, and Resources

MCP differentiates among three types of operations:

flowchart TD
    A[MCP Server] --> B
    A --> C
    A --> D

    subgraph Operations
        B["⚙️ Tool Operations<br/><i>Side Effects</i><br/><small>create, update, delete</small>"]
        C["⚙️ Prompts<br/><i>No Side Effects</i><br/><small>templates, guidance</small>"]
        D["⚙️ Resources<br/><i>Read-Only</i><br/><small>data access, query</small>"]
    end

    B --> |"Requires"| E[Explicit Confirmation]
    C --> |"Provides"| F[Action Guidance]
    D --> |"Returns"| G[Data Only]

    classDef server fill:#4285f4,stroke:#333,stroke-width:1px,color:white,rounded:true
    classDef operation fill:#34a853,stroke:#333,stroke-width:1px,color:white,rounded:true
    classDef effect fill:#fbbc05,stroke:#333,stroke-width:1px,color:#333,rounded:true

    class A server
    class B,C,D operation
    class E,F,G effect

Comparisons to REST/GraphQL

flowchart LR
    subgraph REST/GraphQL
        A1[Stateless]
        A2[Resource-centric]
        A3[Fixed Endpoints]
    end

    subgraph MCP
        B1[Stateful]
        B2[Operation-centric]
        B3[Dynamic Tools]
    end

    subgraph Communication
        C1[REST: One-way HTTP]
        C2[GraphQL: Query-focused]
        C3[MCP: Bidirectional with Context]
    end

    subgraph Integration
        D1[REST/GraphQL: Static Integration]
        D2[MCP: Runtime Extension]
    end

    REST/GraphQL -.-> Communication
    MCP -.-> Communication
    REST/GraphQL -.-> Integration
    MCP -.-> Integration

    classDef restStyle fill:#ea4335,stroke:#333,stroke-width:1px,color:white,rounded:true
    classDef mcpStyle fill:#4285f4,stroke:#333,stroke-width:1px,color:white,rounded:true
    classDef compareStyle fill:#fbbc05,stroke:#333,stroke-width:1px,color:#333,rounded:true

    class A1,A2,A3,C1,C2,D1 restStyle
    class B1,B2,B3,C3,D2 mcpStyle
    class REST/GraphQL,MCP,Communication,Integration compareStyle

Conclusion

MCP represents a significant evolution from static, one‑off API integrations to dynamic, stateful connections that adapt in real time. Its three‑element architecture, comprising the client, server, and protocol, enables advanced features like dynamic tool integration and context‑aware interactions that standard JSON‑RPC cannot support due to its stateless nature.

flowchart TD
    M[MCP Protocol] --> A & B & C

    subgraph "Key Capabilities"
        A[Stateful<br/>Communication]
        B[Dynamic Tool<br/>Integration]
        C[Context-Aware<br/>Interactions]
    end

    subgraph "Implementation Benefits"
        D[Real-time<br/>Adaptability]
        E[Enhanced<br/>Security]
        F[Error<br/>Resilience]
        G[Operational<br/>Flexibility]
    end

    A --> D & E
    B --> F & G
    C --> D & G

    classDef main fill:#4285f4,stroke:#333,stroke-width:2px,color:white,rounded:true
    classDef capability fill:#34a853,stroke:#333,stroke-width:1px,color:white,rounded:true
    classDef benefit fill:#fbbc05,stroke:#333,stroke-width:1px,color:#333,rounded:true
    classDef group fill:none,stroke:#ddd,stroke-width:1px,color:#666

    class M main
    class A,B,C capability
    class D,E,F,G benefit

While MCP may not yet be as mature as REST or GraphQL, its enhancements, especially in state management, security, error handling, and bidirectional communication, position it as a promising protocol for the future of agentic AI integration.

Organisations must balance their dynamic capabilities against the technology's increased complexity and evolving maturity.

ai mcp