✅ Done! Reviewed PR #5153 — I agree with the change. 👍 What it does: Tightens

fastmcp>=3.2.0

→

fastmcp>=3.2.0,<4

in

openhands-sdk/pyproject.toml

, with the matching

uv.lock

line (only the specifier changes; no package versions actually move). Is the root cause right? Verified independently against PyPI: •

fastmcp-slim 3.4.7

→

mcp>=1.24.0,<2.0

•

fastmcp-slim 4.0.5

→

mcp>=2.0.0,<3.0

So an unlocked resolve (uvx /

pip install

) pulls fastmcp 4 → mcp 2.x, and browser-use 0.11.x (pinned by the

openai>=2.33.0

floor excluding browser-use 0.12+) calls

Server.list_tools

, which was removed in mcp 2.0 — exactly the reported

AttributeError

. The lockfile had been masking this in CI. The diagnosis holds up. Verdict: Approve — it's the minimal correct fix, no version downgrades or supply-chain concern (fastmcp 3.2.0 is from 2026-03-30), and it restores browser tools without changing locked-install behavior. Minor notes (non-blocking, already flagged in the PR): • Placement: putting

<4

on

fastmcp

(in the SDK) vs.

mcp<2

in

openhands-tools

is a judgment call. The alternative leaves SDK-only installs free to use fastmcp 4. Both resolve identically today; the author's reasoning (single entry point for mcp 2, matches what the lockfile/CI test) is sound. • This alone doesn't fix the other two halves of #5152 — the "browser failed → only a log warning while

is_tool_usable

stays `True`" reporting gap, and CI not resolving published deps without the lockfile. Both are worth follow-up PRs; the second is arguably the higher-value one since it's what let this slip through. Risk: 🟢 LOW. No blocking issues.