I run AgentShortlist, a directory of MCP servers where every line has a source. This is our own data.
A check that reads only what an MCP server tells the model cannot tell these two releases apart. DBHub 0.22.5 and 0.22.6 announce exactly the same two tools, with the same descriptions and the same input schemas. One of them is affected by a published advisory.
@bytebase/dbhub 0.22.5 and 0.22.6, published on 24 June 2026, about three hours apart (04:22 and 07:34 UTC, from the npm registry).node:22-slim), no credentials, DBHub's --demo mode (an in-memory SQLite database with sample data), a fixed hostname, in the order 0.22.5, 0.22.6, 0.22.5, 0.22.6. Each version ran twice so we could see whether the environment alone changes the result.
Each server reported execute_sql and search_objects. The SHA-256 of the descriptions, of the schemas and of both together was the same in the four runs:
| Hash | Value (first 16 characters) |
|---|---|
| Descriptions | a629bd6a8da832f3 | | Schemas | 910f0162e3129022 | | Both | 5fc028095d373457 |
Two runs of the same version were identical, so the environment is not what makes them match. The tool list of 0.22.5 and of 0.22.6 is byte-identical. Both releases answered with protocol revision 2025-03-26: neither answered server/discover within 20 seconds, so these hashes come from initialize. A hash is only comparable if it says how the list was asked.
Not the tool definitions. We compared the two published packages as text, without running either. In 0.22.6 the PostgreSQL, MySQL, MariaDB and SQLite connectors contain read-only statements (BEGIN READ ONLY, START TRANSACTION READ ONLY and PRAGMA query_only); in 0.22.5 none of those strings appear. The lines that define each tool's description, input schema and registration are the same in both.
That fits what the advisory describes: the database-level read-only setting was written but gated on a config value that was never set, so only a check of each statement's first keyword remained, and a SELECT that calls a function with side effects passed it. It is the part the advisory is about, and it is not visible in tools/list.
mysql-mcp-server 0.4.1 and 0.4.2 also span an advisory (GHSA-rqfv-2mw9-78g2, a missing Origin and Host check in the SSE transport). We could not compare their tool lists: in a clean Docker environment neither started, first because of a missing dotenv module and then, with that added, on an AttributeError about list_resources. We did not investigate the cause. Version 0.4.4 started and listed three tools.
What we did not test: whether read-only mode holds in 0.22.5 or 0.22.6 (we did not run a write), other DBHub versions, or any other transport. Read-only mode on the database also says nothing about data leaving through another tool in the same client, which a reader pointed out; that is outside this test. A matching hash is not a security result. It tells you the announced tools did not change.
We then ran the same kind of check across database servers: 13 database MCP servers: who can write? Full post, with the test records on the card: https://agentshortlist.dev/blog/dbhub-same-tool-list-different-security-status?utm_source=devto . We also publish a short note on MCP advisories, the MCP Risk Radar: https://agentshortlist.dev/radar?utm_source=devto