MCP `streamable-http` transport fails with "Context is not available outside of a request"

[Dual-0]

While connecting my LibreChat MCP client via the streamable-http transport always fails immediately after session creation with the following warning:

Failed to validate request: Context is not available outside of a request
The HTTP layer itself is healthy — every POST /mcp/ returns 200 OK and a new session ID is created by StreamableHTTP session manager. The failure occurs in the background task immediately after, before any tool call is ever made.

Steps to Reproduce

1. Enable Context Agent in Nextcloud
2. Configure an external MCP client (in my case LibreChat) using streamable-http transport pointing to:
   https://<nextcloud>/index.php/apps/app_api/proxy/context_agent/mcp/
3. Send a valid initialize JSON-RPC request with Authorization: Bearer <app-password>
4. Observe the log

Logs

INFO - Created new transport with session ID: 3ff000a886594d35ba3f46e00510a786
INFO - "POST /mcp/ HTTP/1.0" 200 OK
WARNING - Failed to validate request: Context is not available outside of a request
This repeats identically on every connection attempt regardless of the authentication method used.

Root Cause

In my point of view the streamable-http transport processes incoming MCP JSON-RPC messages asynchronously in a background task, outside of the original FastAPI request lifecycle. Seems the request validation relies on FastAPI context variables (e.g. request object) to identify the calling user. Because these context variables are not propagated into the background task, the validation crashes with a ValueError and the session is dropped immediately.

Expected Behaviour

The MCP session should initialize successfully and the tools should be available to the external client.

[weltmaister]

Additional reproduction data from a live Nextcloud AIO deployment

Environment

• Nextcloud: 32.0.6
• app_api: 32.0.0
• assistant: 2.13.0
• context_agent: 2.5.1 (enabled)
• context_agent container image: ghcr.io/nextcloud/context_agent:2.5.1
• Runtime inside the live container:
  • fastmcp 2.13.0.2
  • mcp 1.25.0
  • supported protocol versions reported by the live container: ['2024-11-05', '2025-03-26', '2025-06-18', '2025-11-25']

What was reproduced

All requests were sent to:
https://<host>/index.php/apps/app_api/proxy/context_agent/mcp/
with:

• Authorization: Bearer <app-password>
• Accept: application/json, text/event-stream
• Content-Type: application/json

Observed behavior:

• initialize returns HTTP 200
• a fresh MCP session id is created on every attempt
• response body still contains:
  {"jsonrpc":"2.0","id":1,"error":{"code":-32602,"message":"Invalid request parameters","data":""}}

This was reproduced with multiple protocol versions, including the ones reported by the live container itself:

• 2024-11-05
• 2025-03-26
• 2025-06-18
• 2025-11-25

Changing clientInfo, id, and basic capabilities shapes did not change the result.

Important transport observation

If the client does not send both media types in Accept, the server replies with:

• HTTP 406 Not Acceptable
• message: Client must accept both application/json and text/event-stream

Logs from the live context_agent container

The internal ASGI path seen by the app is:

• POST /mcp/

Before any local debugging patching

The container log shows the exact warning mentioned in this issue:

INFO - Created new transport with session ID: 3d70a05353fa488baa8609265d41f161
INFO - "POST /mcp/ HTTP/1.1" 200 OK
WARNING - Failed to validate request: Context is not available outside of a request

This was emitted for the initialize request.

Additional validation noise around the same failure

The server also logged pydantic validation traces that ended up as the generic -32602 Invalid request parameters response. Example fragments:

ListToolsRequest.method
  Input should be 'tools/list' [type=literal_error, input_value='initialize', input_type=str]

CallToolRequest.method
  Input should be 'tools/call' [type=literal_error, input_value='initialize', input_type=str]

After instrumenting the live middleware for additional logging

A temporary local debug patch was applied only to observe what the middleware can actually see during the failing request.
The relevant log line was:

MCP DEBUG headers []
WARNING - Failed to validate request: Authorization header is missing/invalid

So during the failing MCP middleware path, the FastMCP helper returned an empty header set for that request.

Post-failure behavior in the same session

Using the MCP session id returned with the failing initialize response:

• notifications/initialized returned HTTP 202
• tools/list returned HTTP 200 with:
  {"result":{"tools":[]}}

Summary of the reproduction data

• the failure is reproducible on a real AIO deployment with context_agent 2.5.1
• session creation happens
• initialize still fails with generic -32602
• the container logs do contain the more specific warning from this issue:
  Context is not available outside of a request
• when instrumented further, the middleware sees no HTTP headers at all for the failing request path

[janepie]

Thank you for reporting this, I'll have a look on what is happening here