Support elicitation

[thekid]

See https://modelcontextprotocol.io/specification/2025-06-18/client/elicitation.

Step 1

The LLM decides to perform a tool call
The MCP client sends this to the server:

POST /mcp HTTP/1.1
Content-Type: application/json
Mcp-Session-Id: session-abc123

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "send_email",
    "arguments": {
      "email": "user@example.com"
    }
  }
}

The server locates the tool and starts execution

Step 2

The tool needs additional information from the user
The MCP servers sends the following back to the MCP client:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "elicitation/create",
  "params": {
    "mode": "form",
    "message": "Please confirm sending an email",
    "requestedSchema": {
      "type": "object",
      "properties": {}
    }
  }
}

The MCP client leaves the the HTTP connection open

Step 3

The MCP client requests the required data from the user
The MCP client sends this to the server:

POST /mcp HTTP/1.1
Content-Type: application/json
Mcp-Session-Id: session-abc123

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "action": "accept"
  }
}

The MCP server acknowledges this request

Step 4

The tool call is continued
The servers sends the result to the first response (the one which was left open above)

HTTP/1.1 200 OK
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "The registration was successful"
      }
    ],
  }
}

The tool call is now complete

[thekid]

This here from https://gofastmcp.com/servers/elicitation is really elegant:

@mcp.tool
async def collect_user_info(ctx: Context) -> str:
    """Collect user information through interactive prompts."""
    result = await ctx.elicit(
        message="Please provide your information",
        response_type=UserInfo
    )
    
    if result.action == "accept":
        user = result.data
        return f"Hello {user.name}, you are {user.age} years old"
    elif result.action == "decline":
        return "Information not provided"
    else:  # cancel
        return "Operation cancelled"

However, as the await already suggests, this will suspend the tool execution and continue it, implemented e.g. by the server's async event loop or something like coroutines / fibers.

The problem with these approaches is: They do not work in clustered setups with the typical request distributions. (this would either require sticky sessions or for all cluster members to know each other and then hand over requests to the machine the suspended coroutine is running on)

[thekid]

This design is fundamentally incompatible with stateless horizontal scaling.

Problem

In a nutshell:

                    Load Balancer
                         |
        +----------------+----------------+
        |                |                |
     Node A           Node B           Node C
        |
   [Holds SSE stream     
    for tools/call      
    id:2 open]
                         |
                    [Receives POST
                     with elicitation
                     response]
                     
   How is Node B supposed to tell the open stream on Node A to continue?! ⚡

Possible workarounds (and their respective caveats):

---

Sticky Sessions

Load balancer routes by Mcp-Session-Id always to the same node

• Breaks down when the node dies
• Prevents true auto-scaling

---

Shared State + Pub/Sub

Nodes communicate via Redis/NATS/etc

• Adds latency and complexity
• Still requires Node A to stay alive

This seems to be the way FastMCP solves this problem, see https://gofastmcp.com/deployment/http#custom-storage-backends (though in my opinion, it should read "MUST provide" [a custom storage backend], not "CAN provide" 😬

---

Stream Migration

Somehow move the open HTTP stream to Node B

• Practically impossible with standard HTTP
• Also requires Node A to stay alive

---

Conclusion

With the current state of how elication is designed we will not implement in this library. It's used in production clusters and FaaS, both of which scale horizontally.

Work is being done on this inside the MCP foundation's SEP-1442 and SEP-1858, and statelessness is a key part of the MCP Roadmap we might wait and see what they come up with.

[thekid]

I'm probably overlooking something as I'm still quite new to this matter, but I'm unsure why this can't just be done with a very simple solution based on returning an elicit result from the tool call including the comple call. The proposal SEP-1858 still requires storing state as far as I see.

Here's how I would design this:

Step 1

Client Calls Tool

POST /mcp HTTP/1.1
Content-Type: application/json
Mcp-Session-Id: session-abc123

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "create_account",
    "arguments": {
      "email": "user@example.com"
    }
  }
}

Step 2

Server returns elicitation Request (as result, not as separate request)

HTTP/1.1 200 OK
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "elicit": {
      "originalCall": {
        "name": "create_account",
        "arguments": {
          "email": "user@example.com"
        }
      },
      "message": "Please confirm account creation",
      "requestedSchema": {
        "type": "object",
        "properties": {
          "confirmed": { "type": "boolean" }
        },
        "required": ["confirmed"]
      },
      "serverState": "opaque-token-or-encrypted-blob-if-needed"
    }
  }
}

Connection closed. Completely stateless.

Step 3

Client prompts user, then calls tool again

POST /mcp HTTP/1.1
Content-Type: application/json
Mcp-Session-Id: session-abc123

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "create_account",
    "arguments": {
      "email": "user@example.com"
    },
    "elicitationResponse": {
      "action": "accept",
      "content": {
        "confirmed": true
      },
      "serverState": "opaque-token-or-encrypted-blob-if-needed"
    }
  }
}

Step 4

Server returns final result

HTTP/1.1 200 OK
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Account created successfully!"
      }
    ]
  }
}

Note: The serverState field is optional but useful if the server needs to remember something between calls without a database:

• Could be a signed JWT
• Could be encrypted blob
• Could be a cache key
• Could be omitted entirely if originalCall is enough

---

Comparison

Aspect	Current MCP Design	This idea
Stateless	❌ Server holds open stream	✅ Fully stateless
Clustering	❌ Needs sticky sessions	✅ Any node can handle any request
Serverless	❌ Can't hold connections	✅ Works perfectly
Complexity	❌ SSE + separate POST	✅ Simple request/response
Failure recovery	❌ Stream dies = lost	✅ Client can retry
Elegant code	✅ Co-routines / fibers can be suspended & resumed	➡️ Would need a different design