MCP Elicitation Not Working at Runtime - FastMCP Remote Server Issue

[Pratikkumar24]

Pre-submission Checklist

• I have checked that this question would not be more appropriate as an issue in a specific repository
• I have searched existing discussions and documentation for answers

Question Category

• Protocol Specification
• SDK Usage
• Server Implementation
• General Implementation
• Documentation
• Other

Your Question

MCP Elicitation Not Working at Runtime - FastMCP Remote Server Issue

Problem Summary

MCP elicitation is "not working at runtime" when calling tools on a remote FastMCP server deployed on fastmcp.cloud. The elicitation form never appears, and the tool execution hangs or fails silently.

What works:

• ✅ Elicitation works perfectly with local stdio transport (Cursor)
• ✅ Elicitation works perfectly with MCP Inspector using HTTP/remote
• ✅ Server code is correct (proven by MCP Inspector working)

What doesn't work:

• ❌ Elicitation hangs/doesn't appear when calling tools via Cursor with remote SSE/http transport
• ❌ Elicitation doesn't appear at runtime in the fastmcp.cloud UI when executing tools

Technical Details

Server Setup

• Framework: FastMCP (Python)
• Transport: SSE (Server-Sent Events) for remote deployment
• Deployment: fastmcp.cloud
• Server Code Example:

from fastmcp import FastMCP, Context
from dataclasses import dataclass

mcp = FastMCP(name="elicitation-server")

@dataclass
class UserData:
    name: str
    age: int
    email: str = ""

@mcp.tool
async def collectUserData(ctx: Context) -> str:
    """Collect user data through MCP elicitation."""
    logger.info("collectUserData: Starting elicitation request")
    
    result = await ctx.elicit(
        message="Please provide your personal information (name, age, and optionally email).",
        response_type=UserData
    )
    
    if result.action == "accept":
        user = result.data
        return f"Thank you {user.name}! You are {user.age} years old."
    # ... handle decline/cancel

Client Configuration

Cursor MCP Config (.vscode/mcp.json):

{
  "servers": {
    "my-mcp-server": {
      "type": "sse",
      "url": "https://necessary-fuchsia-cicada.fastmcp.app/mcp"
    }
  }
}

Observed Behavior

1. Tool Schema View: Shows empty properties: {} (expected for elicitation tools)

2. Tool Execution: When calling the tool:

   • No elicitation form appears
   • Tool execution hangs or times out
   • No error messages shown
   • Server logs show elicitation request initiated but no response received

3. Comparison with Working Scenarios:

   • Local (stdio): Elicitation form appears immediately, works perfectly
   • MCP Inspector (HTTP/remote): Elicitation form appears, works perfectly
   • Remote (SSE): Elicitation form never appears, execution hangs

Root Cause Hypothesis

Based on testing evidence:

1. Server is correct: MCP Inspector proves remote elicitation works with HTTP transport
2. Cursor supports elicitation: Works perfectly with stdio transport
3. Issue is transport-specific: SSE transport in Cursor may not properly handle elicitation state management

According to MCP specification:

• For remote servers, elicitation state MUST be bound to user identity, not session IDs
• Remote servers require proper user identification from MCP authorization

Questions

1. Is this a known issue with FastMCP + remote SSE transport + elicitation?
2. Does Cursor fully support remote elicitation over SSE transport?
3. Are there any FastMCP configuration options needed for remote elicitation?
4. Should I use HTTP transport instead of SSE for remote elicitation?
5. Is there a workaround to make elicitation work with remote FastMCP servers?

What I've Tried

• ✅ Verified server code follows FastMCP elicitation patterns
• ✅ Tested with MCP Inspector (works - proves server is correct)
• ✅ Tested locally with stdio (works - proves Cursor supports elicitation)
• ✅ Added logging to track elicitation requests
• ✅ Verified tool schema is correct (empty properties for elicitation tools)
• ❌ Tried different FastMCP versions
• ❌ Checked server logs (shows elicitation initiated but no client response)

Environment

• FastMCP Version: Latest
• Python Version: 3.14
• Cursor Version: Latest
• Deployment Platform: fastmcp.cloud
• Transport: SSE (Server-Sent Events)

Additional Context

The MCP Elicitation Specification states:

"For remote MCP servers, user identification MUST be derived from credentials acquired via MCP authorization when possible (e.g. sub claim)"

"For remote servers, elicitation state MUST be bound to user identity, NOT associated with session IDs alone"

References:

• MCP Elicitation Spec
• FastMCP Documentation
• Cursor MCP Docs

Expected Behavior

When calling a tool that uses ctx.elicit():

1. Tool execution should pause
2. Elicitation form should appear in the client UI
3. User fills the form
4. Tool continues with the collected data
5. Tool returns result

Actual Behavior

1. Tool execution starts
2. Elicitation form never appears
3. Tool execution hangs indefinitely
4. No error message shown
5. Server logs show elicitation request but no client response

---

Has anyone successfully gotten FastMCP elicitation to work with remote SSE transport? Any guidance would be greatly appreciated!

[Agent-Hellboy]

Is this a known issue with FastMCP + remote SSE transport + elicitation?

i think so , please check evalstate/fast-agent#602 , it's using fastmcp client i guess.

Does Cursor fully support remote elicitation over SSE transport?

yes it supports , i have tested it.

Are there any FastMCP configuration options needed for remote elicitation?

i don't think so

Should I use HTTP transport instead of SSE for remote elicitation?

there is a proposal to make this in-flight tools/call

[isheng-eqi]

Your diagnosis is correct: the issue is transport-specific, and you have already identified the root cause in the spec quote. Let me connect the dots.

The root cause: SSE does not carry user identity

Your testing matrix tells the story:

Transport	Elicitation works?	Why
stdio (local)	✅ Yes	Process ownership = user identity, no auth needed
MCP Inspector (HTTP)	✅ Yes	Inspector manages sessions locally, no remote user identity required
SSE (remote, Cursor)	❌ No	SSE has no built-in mechanism to carry user identity between requests

Elicitation over SSE fails because:

1. When ctx.elicit() is called, the server sends an elicitation request to the client
2. The client must display the form and send back the response
3. For remote servers, the spec requires the elicitation state to be bound to user identity, not session ID
4. SSE transport does not have a standard way to convey user identity — there is no auth header in SSE connections
5. The server cannot match the elicitation response to the original request because it has no way to identify "which user" the SSE stream belongs to

Why MCP Inspector works but Cursor does not

MCP Inspector manages the full OAuth flow and maintains session state internally. When it sends an elicitation request via HTTP, the session context (including user identity from the OAuth token) is preserved.

Cursor over SSE does not have this — the SSE connection is established once at startup, and there is no per-request auth context. When the server calls ctx.elicit(), the elicitation request goes out over SSE, but the response cannot be matched back to the authenticated user context.

The fix: use Streamable HTTP instead of SSE

The spec quote you found is the key:

"For remote MCP servers, user identification MUST be derived from credentials acquired via MCP authorization."

SSE transport cannot satisfy this requirement. Streamable HTTP transport can.

Migrate your server from SSE to Streamable HTTP:

# Instead of:
mcp.run(transport="sse", host="0.0.0.0", port=8000)

# Use Streamable HTTP:
mcp.run(transport="streamable-http", host="0.0.0.0", port=8000)

And update your Cursor config:

{
  "servers": {
    "my-mcp-server": {
      "type": "http",
      "url": "https://necessary-fuchsia-cicada.fastmcp.app/mcp"
    }
  }
}

Streamable HTTP carries the MCP session ID and Authorization header on every request, so the server can map elicitation state to the authenticated user.

If you must stay on SSE

The only workaround is to implement user identification yourself:

1. Add a custom auth header to your Cursor SSE config (if Cursor supports it)
2. Use a pre-shared token that identifies the user
3. Bind elicitation state to a composite key of (custom_user_id, tool_call_id) instead of session ID

But this is fragile and non-standard. Streamable HTTP is the correct path.

FastMCP-specific note

Check if fastmcp.cloud supports Streamable HTTP transport for your deployment tier. If it only supports SSE, you may need to:

1. Self-host the server with Streamable HTTP
2. Wait for fastmcp.cloud to add Streamable HTTP support (it is on their roadmap per the proposal referenced by Agent-Hellboy)
3. Use MCP Inspector's HTTP mode for testing and accept SSE limitations in production until the platform catches up

Summary

Your server code is correct. Your testing proves it. The issue is purely transport-level: SSE cannot satisfy the spec's requirement that remote elicitation be bound to user identity. Switch to Streamable HTTP.