[shossain786]

Closes the loop on #2. 0.4.2 stopped the bleeding by pinning mcp<2.0.0; this does the migration that pin was holding the door open for.

The change

mcp 2.0.0 removed the @app.list_tools() / @app.call_tool() decorators the server registered all 85 tools with. They're replaced by on_list_tools / on_call_tool callbacks on the Server constructor — handlers now take a ServerRequestContext plus typed request params and return ListToolsResult / CallToolResult rather than bare content lists.

The surface really was as small as the gate predicted. mcp 2.0 keeps camelCase aliases on its models (populate_by_name + validate_by_alias), so Tool(..., inputSchema=...) still validates — none of the 85 tool definitions across the four tools/*.py files needed a single edit. Only server.py changed.

The pin inverts to mcp>=2.0.0. The 0.4.2 ceiling was load-bearing because the code spoke 1.x; the floor is load-bearing now because the code speaks 2.x.

No wire change, on purpose

Tool names, input schemas, response content and error strings are byte-for-byte what 0.4.x emitted. A migration that also changes behaviour can't be verified as a migration. Returning is_error: true on the exception path is the semantically correct thing and is deliberately left as a follow-up.

smoke.yml had to change — and it caught itself

The smoke test called server.list_tools() with no arguments, so this migration breaks it. That signature belongs to the SDK, not to us. It now asserts against server.ALL_TOOLS — the registry we own — so the test measures the package rather than the SDK's calling convention.

Verification

Against the built wheel installed into a clean venv, never src/:

Check	Result
Registry	85 tools, 85 handlers, no orphans either direction
Entry point	exits 0 on EOF
Handshake	initialize still negotiates protocolVersion 2025-03-26
Wire schema	inputSchema still camelCase in tools/list
selenium-mcp-test Java suite	68/68 pass over real stdio JSON-RPC (same count as the 0.4.2 baseline)
New floor is real	forced onto mcp 1.29.0 the import fails loudly at ServerRequestContext; pip refuses the combination outright

Suite run under xvfb with the clean venv first on PATH, so python -m selenium_mcp.server resolved to the installed artifact.

⚠️ Merge after #5

The CHANGELOG's Infrastructure section describes Trusted Publishing and Dependabot, which land in #5. More importantly: do not tag 0.5.0 until #5 is merged and the PyPI publisher is enrolled, or the release will fail at the 403 that has been failing since ~July 1 and 0.5.0 will need publishing by hand like the three before it.