v0.5.0 — runs on the mcp 2.0 SDK
Completes the work 0.4.2 deferred. 0.4.2 stopped the bleeding by pinning away from the 2.0 SDK; this migrates to it.
Changed
- Migrated to the
mcp2.0 SDK. 2.0.0 removed the@server.list_tools()/@server.call_tool()decorators this server registered its 85 tools with. They are replaced byon_list_tools/on_call_toolcallbacks on theServerconstructor, taking aServerRequestContextplus typed request params and returningListToolsResult/CallToolResult. (#2) - The
mcpdependency is now>=2.0.0,<3.0.0. 1.x can no longer run this code. The upper bound is deliberate and permanent — it is what stops a future major from silently breaking installs, and it is what gives Dependabot something to report when one appears. - The server reports its own version in the MCP handshake, read from installed distribution metadata.
No behaviour change on the wire
Tool names, input schemas, response content and error strings are byte-for-byte what 0.4.x emitted. The migration was shipped as a migration and nothing else.
Verified before release
Against the built artifact installed into a clean virtualenv — never the source tree:
- 85 tools, 85 handlers, no orphans in either direction
- entry point exits cleanly
initializestill negotiatesprotocolVersion 2025-03-26inputSchemastill camelCase on the wireselenium-mcp-test: 68/68 pass over real stdio JSON-RPCtwine check: PASSED on both sdist and wheel
Infrastructure
- PyPI publishing moved to Trusted Publishing (OIDC); the stored API token is no longer used.
- Dependabot now watches
pyproject.tomland the workflow actions. - A daily smoke test installs the published package from PyPI and asserts it can actually start.
Full changelog: https://github.com/seleniumboot/selenium-mcp/blob/master/CHANGELOG.md