chore(deps): update fastmcp requirement from <4.0.0,>=3.0.0 to >=3.0.0,<5.0.0

[dependabot]

Updates the requirements on fastmcp to permit the latest version.

Release notes

Sourced from fastmcp's releases.

v4.0.5: No Country for Loose Ints

Tool parameters declared strict with Field(strict=True), StrictInt, or a strict model config are honored again, on both direct calls and task submission. Since the SDK v2 migration the server's lax default overrode them and silently coerced values.

What's Changed

Security 🔒

• Add regression test for the unconfigured ID-JAG guard by @​zzstoatzz in PrefectHQ/fastmcp#5146

Fixes 🐞

• Preserve field-level strict validation in lax mode by @​zzstoatzz in PrefectHQ/fastmcp#5141

Other Changes 🦾

• docs: add v4.0.5 changelog entries by @​zzstoatzz in PrefectHQ/fastmcp#5148

Full Changelog: PrefectHQ/fastmcp@v4.0.4...v4.0.5

Changelog

Sourced from fastmcp's changelog.

---

title: "Changelog" icon: "list-check" rss: true tag: NEW

v4.0.8: Take Three

Completion goes back to its 4.0.5 behavior. The visibility check added in 4.0.6 and reworked in 4.0.7 simulated list requests through middleware, and in 4.0.7 that could let a response cache serve hidden prompts to other clients. New tests pin both problems, and withholding suggestions for hidden references will return with a proper design. Resource template patterns are now cached without a size limit, so servers with thousands of templates read fast again, and OAuthProxy revokes the upstream refresh token instead of sending its own token upstream.

Security 🔒

• completions: revert the list-based visibility check (#5240, #5244) by @​zzstoatzz in #5250

Fixes 🐞

• Fix OAuthProxy upstream refresh token revocation by @​Ujemny in #5243
• resources: keep every compiled template pattern cached by @​zzstoatzz in #5248

New Contributors

• @​Ujemny made their first contribution in #5243

Full Changelog: v4.0.7...v4.0.8

v4.0.7: Double Take

Fixes two regressions from 4.0.6. The completion visibility check runs only the list-specific middleware hooks, so rate limits, logging, and metrics see a single request per completion again. Resource template patterns are cached, which makes template reads faster than in 4.0.5.

Fixes 🐞

• completions: check reference visibility through typed list hooks only by @​zzstoatzz in #5244
• resources: cache compiled URI template patterns by @​zzstoatzz in #5245

Full Changelog: v4.0.6...v4.0.7

v4.0.6: Comma Chameleon

Resource templates now match what clients actually send: literals raw or percent-encoded, and list query parameters exploded or comma-joined. A Client whose exit is cancelled releases its session instead of leaking it, completion no longer answers for prompts and templates the caller can't see, and JSON schemas with float or oversized length limits load instead of failing. The auth fixes cache OIDC discovery and keep Google tokens out of request URLs.

Enhancements ✨

• Name nested fields in detailed CodeMode schemas by @​zzstoatzz in #5111
• Add a docs skill by @​zzstoatzz in #5175

... (truncated)

Commits

• 004bf15 docs: add v4.0.5 changelog entries (#5148)
• f9654c2 oauth-proxy: add regression test for unconfigured ID-JAG guard (#5146)
• 053f128 Preserve field-level strict validation in lax mode (#5141)
• 490049f docs: add v4.0.4 changelog entries (#5127)
• ef851de chore: Update SDK documentation (#5126)
• 7ae9d6e chore: Update SDK documentation (#5043)
• 73ad4ab ty: resolve warnings surfaced by ty 0.0.79 (#5123)
• a01f835 Fix #5115: OAuthProxy accepts self-contained ID-JAG tokens even when iden (#5...
• f21e00d Fix multipart string-array default encoding (#5121)
• f044b9d fix(local-provider): apply transforms in get_tasks (#5117)
• Additional commits viewable in compare view

---

Note

Medium Risk
Widening a major-version bound for MCP support may surface fastmcp 4.x API or behavior changes at install/upgrade time even though this PR only edits the pin.

Overview
Relaxes the core fastmcp pin in pyproject.toml from <4.0.0 to <5.0.0, so installs of openenv can resolve fastmcp 4.x (still >=3.0.0) alongside the existing MCP-related runtime deps.

No application code changes—only the declared dependency range moves to track newer fastmcp releases (including recent security and validation fixes in the 4.0 line).

^{Reviewed by Cursor Bugbot for commit 4815cef. Bugbot is set up for automated code reviews on this repo. Configure here.}

[bot-ci-comment]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 63de2da. Configure here.}

[cursor]

FastMCP 4 drops tool schemas

Medium Severity

Widening fastmcp to <5.0.0 installs FastMCP 4, which uses MCP SDK v2 snake_case models. _tool_from_server_tool reads inputSchema and falls back to {} when that attribute is absent, and WebSocket tools/list dumps models without aliases, so agents and MCP clients receive empty or non-spec tool schemas.

 

^{Reviewed by Cursor Bugbot for commit 63de2da. Configure here.}

[cursor]

REQUEST_CHANGES at 63de2da4 (Bugbot Medium + release gate)

Widening fastmcp from <4.0.0 to <5.0.0 is package cargo and currently unsafe for OpenEnv’s MCP surface.

Tier 1

• FastMCP 4 / MCP SDK v2 uses snake_case tool models. _tool_from_server_tool in src/openenv/core/env_server/mcp_environment.py only reads inputSchema and otherwise emits {}, so tools/list / agent tool schemas go empty under FastMCP 4.

Required before merge: keep the <4.0.0 ceiling, or land FastMCP 4-compatible schema extraction (both casings) plus regressions under an installed FastMCP 4. Do not fold into Thursday 0.6.0 without that.

Not a security CVE, but a hard functional break for MCP envs. Quiet Slack.

  

_{Sent by Cursor Automation: Release}

[cursor]

Tier 1 — FastMCP 4 breaks tool schemas. Widening to <5 installs FastMCP 4 (MCP SDK v2 snake_case). src/openenv/core/env_server/mcp_environment.py _tool_from_server_tool only reads camelCase inputSchema and falls back to {}, so agents/MCP clients get empty schemas. Keep <4.0.0 (or add FastMCP 4-compatible schema extraction + regressions) before merging; this is package cargo and must not land in 0.6.0 without that adapter work.

[cursor]

Alignment Review Report

Scope: one line in pyproject.toml (core openenv package) widening the fastmcp upper bound <4.0.0 → <5.0.0, i.e. now permitting the fastmcp 4.x major line.

Automated Checks

• Lint: FAIL — pre-existing, not from this PR. ruff format --check flags 56 files across the tree (26 under envs/, plus the two tests/ files test_grid_world.py / test_julia_env.py that usort flags on a clean tree per AGENTS.md). This PR changes only pyproject.toml (no Python), so zero lint findings are attributable to it. (uv was missing from the review shell; I installed it to run the hook.)
• Debug code: CLEAN for this PR. check-debug.sh reports only pre-existing print/TODO lines in src/; none are introduced here.

Open RFCs Context

• RFC 003 – MCP Support (In Review, @Darktex, @pankit-eng) — directly relevant: fastmcp is the MCP implementation this RFC governs.
• Other active RFCs (000/001/002/005/008/012 In Review, 010/011 Draft) don't intersect a dependency-bound change.

Verification performed

Because this widens a core dependency to a new major, I resolved and exercised it:

• uv sync --all-extras resolves fastmcp==4.0.5 on this branch.
• MCP test suite: 116 passed (tests/core/test_mcp/*, test_production_mode_mcp.py, test_web_interface_mcp.py, tests/envs/test_mcp_client_close.py).
• All core imports resolve under 4.x, including the internal path from fastmcp.client.client import CallToolResult (mcp_environment.py:62); in-memory Client(mcp_server), list_tools, call_tool, and the CallToolResult(...) constructor all behave as before.
• The most dangerous 4.x removals do not apply: no ctx.elicit / ctx.sample / ctx.list_roots usage anywhere, and no camelCase result reads (.isError / .structuredContent) in src/.

Tier 1: Fixes Required

• None attributable to this diff. (The lint failures above are pre-existing and unrelated.)

Tier 2: Alignment Discussion

Principle Conflicts

ALIGNMENT FLAG: Widening a core dependency to a brand-new major (fastmcp 4.x)

• Principle at stake: "Cutting-edge for stability" (.claude/docs/PRINCIPLES.md:23)
• The concern: The root uv.lock is git-ignored (.gitignore:121), so the core test job runs uv sync --all-extras unpinned — this bound change alone silently moves core installs onto fastmcp 4.x (an MCP-SDK-v2 rebuild). I verified it currently passes (116 MCP tests on 4.0.5), so this is low risk today, but there's no committed lockfile floor pinning a known-good 4.x for core.
• Suggested reviewer: @Darktex (authored this principle line)

RFC Conflicts

ALIGNMENT FLAG: Allowing fastmcp 4.x touches the MCP boundary under active review

• RFC at stake: RFC 003 – MCP Support (In Review)
• The concern: fastmcp 4.x rebuilds on MCP SDK v2 with a new sessionless protocol era, Client defaulting to mode="auto", snake_case field renames (camelCase reads bridged-but-deprecated), and removal of server-initiated sampling/roots and era-gated ctx.elicit. None break the current code, but they change the agent-facing MCP semantics RFC 003 governs, so the owners should know the dependency can now float onto that behavior.
• Suggested reviewer: @Darktex, @pankit-eng (RFC 003 authors)

Proactive notes (not required for this PR)

• src/openenv/core/env_server/mcp_environment.py:111 reads the now-deprecated tool.inputSchema; under 4.x this emits a FastMCPDeprecationWarning (it surfaced in the passing test run) but still returns the correct schema via the compat bridge. Migrating to tool.input_schema would future-proof against removal of the camelCase shim (and any later fastmcp>=5 bump). Pre-existing code, not introduced here.
• Version skew: per-env envs/*/uv.lock files still pin fastmcp 3.x (CI --frozen-checks them) while core now permits 4.x. Expected since envs are separate projects, but worth noting for behavior consistency.

Summary

• 0 mechanical issues to fix from this diff (MCP suite passes on 4.0.5; lint failures are pre-existing).
• 2 alignment points for human review (core-dep major-version widening; MCP behavior governed by RFC 003).
• 0 hard RFC conflicts — 1 RFC-relevant heads-up (RFC 003) plus a proactive inputSchema deprecation cleanup suggestion.

  

_{Sent by Cursor Automation: Pre-review}

[cursor]

This widens the core fastmcp bound to allow the 4.x major line. I verified uv sync --all-extras resolves fastmcp==4.0.5 and the MCP suite passes (116 tests), and the risky 4.x removals (ctx.elicit/sample/list_roots) aren't used here — so it's functional.

Two things worth a look before merge:

1. fastmcp 4.x is an MCP-SDK-v2 rebuild (new sessionless protocol era) governed by RFC 003 – MCP Support (In Review).
2. It surfaces a FastMCPDeprecationWarning for tool.inputSchema at src/openenv/core/env_server/mcp_environment.py:111 (bridged/works today; migrating to .input_schema future-proofs it).

Since the root uv.lock is git-ignored, there's no committed lockfile floor pinning a known-good 4.x for the core package.

[cursor]

Keeping this blocked, but with an actual root cause this time. Two attempts at the FastMCP 4 widening have now been closed or held with "session-persistence failures" as the only diagnosis (#1119, and this PR). I reproduced it against fastmcp==4.0.9 and traced the mechanism, so the next attempt does not have to rediscover it.

What fails. Only TestMCPSessionTransportPersistence::test_http_session_mcp_state_persists_across_calls and …::test_websocket_mcp_state_persists_across_calls. A tool that does count = await ctx.get_state("counter") / await ctx.set_state("counter", count + 1) returns 1 on every call instead of 1, 2.

Why. FastMCP 4 made session state keyed by session id. Context.set_state writes to a shared store under f"{self.session_id}:{key}" (_make_state_key), and Context.session_id resolves in this order: a _fastmcp_state_prefix cached on session._connection.state, then connection.session_id, then the mcp-session-id request header, and finally a fresh uuid4().

I instrumented our own /mcp path and both transports land on the last branch:

call 2: session_obj=…556752  connection=…555216  connection.session_id=None  ctx.session_id=9ba3736e-…
call 3: session_obj=…751856  connection=…780064  connection.session_id=None  ctx.session_id=59a00e6f-…
same ServerSession across calls: False | connection present: True | state store object: same

The store is shared, so nothing is lost — every call simply reads and writes a different key. The server-side Connection is rebuilt per call and carries no session_id, so FastMCP mints a new prefix and caches it on an object that is thrown away. Under FastMCP 3 this did not matter because state was not keyed by session identity; holding mcp_session() open was sufficient.

So this is not a version-cap edit. To widen the cap, OpenEnv has to give FastMCP a stable session identity for the lifetime of an OpenEnv session. Roughly in order of soundness:

1. Reuse one server-side connection/ServerSession per OpenEnv session, so FastMCP's own cached prefix survives. Correct, but it lives in exactly the MCP transport plumbing that #1098–#1100 are currently reshaping.
2. Seed the prefix at dispatch: set connection.state["_fastmcp_state_prefix"] to the OpenEnv session id. Small and uses FastMCP's own caching hook, but it leans on a private attribute and needs a regression test plus a comment explaining the coupling.
3. Send mcp-session-id: <openenv session id> on in-process requests. Only covers the path where request_context.request exists, so it does not fix the WebSocket failure.

Recommendation: keep fastmcp>=3.0.0,<4.0.0 on main and treat the upgrade as a scheduled migration owned alongside the MCP lifecycle work, not as a Dependabot bump. This PR is also BEHIND and its two failures are reproducible on a current checkout, so it should not be merged as-is.

For whoever picks it up: the reproduction is uv pip install fastmcp==4.0.9 then PYTHONPATH=src:envs pytest tests/core/test_production_mode_routes.py::TestMCPSessionTransportPersistence, and the two existing tests are already the right acceptance criteria.

View PR

  

_{Sent by Cursor Automation: Release}