Dependency upgrades are often presented as a version number and a green lockfile. Hermes Agent’s MCP 2.0 migration is the more useful kind of public receipt: it names Claude Opus 5 (1M context) in its co-author metadata, then shows the unglamorous work needed to keep an agent conversation intact after an SDK changes its surface.
The repo evidence
MCP 2.0 moved model fields from camelCase to snake_case, changed the server import, and moved its HTTP stack to a different module. Hermes did not scatter version checks through its tools. In the inspected MCP tool module, mcp_field reads both field spellings while sdk_httpx() asks the installed SDK which HTTP implementation it actually uses.
That distinction is not cosmetic. A missing field alias could make a failed tool result look successful, an image lose its MIME type, or pagination stop after the first page. The migration also moves server tests toward MCPServer.call_tool, the public call surface, instead of a private manager whose contract changed beneath it.
The transferable skill
The transferable building skill: treat a library upgrade as a translation boundary, not a find-and-replace exercise. Put field normalization and foreign-client selection behind small adapters; then write tests for the dangerous direction of failure—the response that looks plausible but has silently lost a tool result, a cursor, or an auth error. Builders can reuse that pattern whenever an agent spans an SDK, a protocol, and an optional dependency.
The limit
The co-author trailer is public proof of coding-agent participation, not an audit of who wrote which line or a guarantee of correctness. The commit and tests describe merged source; they do not prove a released package, a reader’s dependency mix, or interoperability with every MCP server. The next meaningful receipt would be a release note and a real cross-version connection test.