v2.6.0 MCP server returns -32602 on initialize (fixed on main, needs release)

[tomac01]

Summary

The released v2.6.0 app is unusable as an MCP server: every initialize call returns JSON-RPC -32602 "Invalid request parameters". MCP clients (e.g. Claude Code) report Failed to reconnect ... -32602.

The root cause is already fixed on main (commit c0183be, 2026-06-03, "get http headers by calling get_http_headers instead of context that may be unavailable", together with the fastmcp ^2.14 bump), but no release contains that fix yet — the latest tag is still v2.6.0. This issue is mainly a request to cut a patch release (2.6.1).

Affected version

• App: context_agent 2.6.0 (App Store / published Docker image)
• Bundled libs in that image: fastmcp 2.13.0.2, mcp 1.27.0 (pin was fastmcp = "^2.11.2")
• Nextcloud 32.0.11.1, AppAPI 32.x with HaRP, accessed via the AppAPI proxy URL …/index.php/apps/app_api/proxy/context_agent/mcp/

Symptom

Client response to initialize:

{"jsonrpc":"2.0","id":1,"error":{"code":-32602,"message":"Invalid request parameters","data":""}}

ExApp container log:

INFO:      - "POST /mcp/ HTTP/1.1" 200 OK
WARNING - Failed to validate request: No active HTTP request found.
mcp.server.streamable_http - INFO - Terminating session: None

Root cause

In ex_app/lib/mcp_server.py (v2.6.0), UserAuthMiddleware.on_message reads the request via:

authorization_header = context.fastmcp_context.request_context.request.headers.get("Authorization")

With the fastmcp 2.13 that ships in the 2.6.0 image, the on_message middleware runs before the MCP SDK sets its request_ctx ContextVar. So context.fastmcp_context.request_context (which resolves to mcp.server.lowlevel.server.request_ctx.get()) raises, and the request is unavailable.

Confirmed by instrumenting the middleware in the running 2.6.0 container:

[diag] request_ctx LookupError (ContextVar not set)
[diag] ctx.request_context.request -> ValueError('Context is not available outside of a request')
[diag] get_http_headers() -> {} (empty)

mcp/shared/session.py then catches the resulting exception during request handling and returns -32602 to the client.

Fix on main

main already replaces the line with get_http_headers().get("authorization") and bumps fastmcp to ^2.14 (commit c0183be). That addresses the issue — it just hasn't been released.

Workaround for self-hosters on 2.6.0

For anyone stuck on the released image, the request is available in fastmcp's own _current_http_request ContextVar (set by RequestContextMiddleware, the outermost ASGI middleware), which is visible inside on_message even on fastmcp 2.13:

from fastmcp.server.http import _current_http_request

class UserAuthMiddleware(Middleware):
    async def on_message(self, context, call_next):
        request = _current_http_request.get()
        authorization_header = request.headers.get("Authorization") if request else None
        if authorization_header is None:
            raise Exception("Authorization header is missing/invalid")
        ...

Verified end-to-end on the affected 2.6.0 container: initialize → 200 OK, tools/list → 50 tools.

Request

Please publish a patch release (e.g. 2.6.1) that includes commit c0183be, since the currently released version cannot serve MCP.