chore: upgrade fastmcp to >=3.4.0 to resolve authlib 1.7.x JWT compatibility

[coderabbitai]

Background

This issue tracks upgrading fastmcp from >=3.2.3 to >=3.4.0 in pyproject.toml.

It was identified as a follow-up to PR #1762 (CVE dependency fixes) in review comment #1762 (comment).

Problem

PR #1762 promotes authlib to a direct dependency and bumps it to >=1.7.1 to address CVE-2026-41425 and CVE-2026-44681.

However, authlib 1.7.0 migrated its JOSE backend to joserfc, which changed JsonWebToken.encode() to return str instead of bytes. fastmcp 3.2.x (written against the authlib 1.6.x API) calls .decode("utf-8") on the encode result in two files:

• fastmcp/server/auth/providers/jwt.py lines 134–139 (RSAKeyPair.sign_token())
• fastmcp/server/auth/jwt_issuer.py lines 145–146 and 198–199

If encode() returns str, calling .decode("utf-8") raises AttributeError: 'str' object has no attribute 'decode'.

OpenRAG's MCP server (src/mcp_http/server.py) does not currently configure fastmcp with JWT auth providers, so this bug would only surface if a deployment enables fastmcp JWT-based auth (e.g., JWTTokenVerifier or OAuthProxy). The blast radius is limited but real for any such deployment.

Research: Does fastmcp 3.4.0 Fix This?

Yes. The fastmcp 3.4.0 release notes (released 2026-06-03) explicitly state:

The auth stack migrated its JWT handling to joserfc.
— via PR PrefectHQ/fastmcp#4221 "Migrate auth JWTs to joserfc"

By migrating JWT encode/decode to joserfc natively, fastmcp 3.4.0 no longer uses authlib.jose.JsonWebToken for JWT operations and therefore no longer calls .decode("utf-8") on its result. The incompatibility with authlib 1.7.x is fully resolved.

Required Change

In pyproject.toml, bump the fastmcp lower bound:

# Before
"fastmcp>=3.2.3",

# After
"fastmcp>=3.4.0",

And regenerate uv.lock accordingly (uv lock).

Notable Breaking Change in fastmcp 3.4.0

fastmcp 3.4.0 has one breaking change: proxy initialize is now forwarded to the upstream server (fail-fast if upstream is unavailable). Review whether OpenRAG's MCP proxy setup in src/mcp_http/server.py is affected.

Acceptance Criteria

• fastmcp lower bound updated to >=3.4.0 in pyproject.toml
• uv.lock regenerated
• Confirm no breaking changes from fastmcp 3.2.x → 3.4.0 affect OpenRAG's MCP server (src/mcp_http/server.py)
• Integration tests pass