DEV Community: Antonio GM

Five read-only settings shrank an MCP tool list. Two did nothing.

Antonio GM — Thu, 12 Nov 2026 13:04:40 +0000

A read-only or safe-mode setting is a promise about what a server will do. The tool list is what the server tells a client about itself. Those are not the same thing, and sometimes the setting does not show up in the list at all.

We started seven servers in Docker with and without such a setting and compared what each returned for tools/list. Five lists got shorter. Two did not change.

What we ran

Between 25 October and 5 November 2026 we started each server in Docker with no real credentials. Where a server needs a value to start, we passed an obviously fake one and no service was running behind it. We called no tools. The records are on each card under "Tested by us", with the exact start command.

Server	Setting	Default	With the setting	What left the list
Atlassian 0.23.1	`READ_ONLY_MODE=true`	98	58	40 names: 25 Jira tools (such as `jira_create_issue`, `jira_delete_issue`, `jira_transition_issue`) and 15 Confluence tools (such as `confluence_create_page`, `confluence_delete_page`)
Grafana 2.1.1	`--disable-write`	79	62	17 names that create, update or delete (for example `create_datasource`, `update_dashboard`, `delete_annotation`, `install_plugin`)
GitHub 2.1.0	`--read-only`	46	27	19 names (for example `create_pull_request`, `merge_pull_request`, `push_files`, `delete_file`, `issue_write`)
Supabase 0.15.0	`--read-only`	31	19	12 names (for example `apply_migration`, `create_project`, `deploy_edge_function`, `delete_branch`)
MongoDB 3.1.0	`--readOnly`	27	18	9 names: `insert-many`, `update-many`, `delete-many`, and the create, rename and drop tools for collections, indexes and databases
Blender 2.2.4	`BLENDER_MCP_SAFE_MODE=1`	9	9	Nothing: identical hashes
ClickHouse 0.7.0	`CLICKHOUSE_ALLOW_WRITE_ACCESS` false or true	3	3	Nothing: identical hashes

In every one of the five that shrank, tools only left: none were added. For Supabase, GitHub, Atlassian, Blender and ClickHouse we ran each configuration twice. Supabase, GitHub, Blender and ClickHouse gave identical hashes both times. Atlassian's descriptions matched, but its schema hash changed between starts: only the order of 11 comma-separated field names in four tools moved, the same set each time, and the tool count was the same. MongoDB and Grafana have one recorded run per configuration, and the MongoDB pair was run on two different days.

GitHub's server is distributed as a container image, so we took its binary from the official image (pinned by digest on the card) and ran it in our standard container. Its --read-only flag removed 19 of 46 tools.

When the list shrinks, a client can see it

Atlassian, Grafana, GitHub, Supabase and MongoDB take tools away when you set the flag. A client, or a scanner reading tool definitions, can tell the two configurations apart from names and schemas alone. That is the useful case, and the size differs a lot: 9 tools for MongoDB, 40 for Atlassian.

Two caveats. First, we only listed the tools; we did not check that the remaining ones respect the setting. Second, Grafana still lists grafana_api_request with --disable-write. The name says it makes API requests, and we did not test what it allows in that mode.

When it does not, the setting is invisible

Blender's safe mode and ClickHouse's write setting changed nothing in what the server announces. ClickHouse has a single query tool, run_query, so a write setting can only act inside it. A client connected to either server sees the same list whichever way the setting is turned.

That does not mean the settings do nothing. It means the tool list cannot tell you. It is the same situation as the two DBHub releases that announced a byte-identical tool list while one of them had a read-only mode that did not hold: DBHub 0.22.5 and 0.22.6: same tool list, different security status. To know whether a setting is enforced you need something other than the tool list: the advisories for that version, the project's tests, or a database user that cannot write.

A shorter list may also cost less

Two readers raised the cost side. One pointed out that a shorter, stable list could help prefix caching. Another noted that Claude Code loads tool definitions on demand, so a long list may weigh less there than it would in a client that sends everything every turn. We have measured neither, so we are not putting a number on it.

A paired test for normalizing hashes

After our last post a reader asked whether stripping what looks incidental could hide a real change. So we ran a paired test with a synthetic server of our own, with one tool and two settings: an ID written into the description (like the container ID), and an allowed target written into the input schema.

Only the ID changes. The description hash and the combined hash change. The schema hash does not. After replacing 12-character hexadecimal strings with a placeholder, all three hashes are identical again.
Only the allowed target changes. The description hash is the same. The schema hash changes, with or without normalizing.
Same configuration twice. Identical, as a control.

So in this case normalizing removed the incidental difference and left the real one visible. The limits are plain: it is a toy server with one tool, and our normalization replaces only 12-character hex strings, nothing else. One more detail from a real server: on Desktop Commander the changing text was the container hostname, which Docker sets by default to the container's 12-character ID. With a fixed hostname the text becomes probe-host, which that normalization does not touch. The script, fake-mcp-server.mjs, and the comparison output are in the public repository.

What this does not show

One machine per run, one or two runs of each configuration. A description that includes the date would look identical in two runs on the same day, so we repeat passes on other days and say what we find. We did not call any tool, so none of this tells you whether a setting works, only what the server announces.

DBHub 0.22.5 and 0.22.6 announce the same tool list. One has a published security advisory

Antonio GM — Wed, 04 Nov 2026 09:19:45 +0000

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.

What we compared

@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).
Advisory GHSA-mwwr-p57h-56pf, from OSV.dev, rated high: DBHub's read-only mode did not prevent database writes. It affects every release before 0.22.6, including 0.22.5, and 0.22.6 is the fixed one. The advisory was published on 24 September 2026, three months after the fix.
Both releases in Docker (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.

What we measured

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.

What did change

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.

What this means

A scanner that compares tool descriptions and schemas, which is where tool-poisoning checks look, would give these two releases the same result. The advisory database gives them different ones. They answer different questions.
Read-only mode is enforced in the server's code, not announced in its tool list. To know whether it holds you need the advisory data and the exact version.
If you pin MCP servers, pin the version and check that version against the advisories, not just its tool list.

A second case, and what it does not show

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

I started 10 MCP servers in Docker. One tool description changed between two runs of the same version

Antonio GM — Wed, 28 Oct 2026 08:58:34 +0000

I run AgentShortlist, a directory of MCP servers where every line has a source. This is our own data.

A hash of a server's tool descriptions can change between two runs without anyone touching the code. We saw it with Desktop Commander 0.3.1. Across two runs only the description of start_process differed, and the only difference in that text was a Docker container ID: fd1cb95d1f61 in one run, 6f6d4f1f57de in the other. It sits at character 1348 of a description 4180 characters long. The schemas and the other 24 descriptions were identical.

Our first reading was that something had changed in the tool. It had not. The server writes its container hostname into the description, so the text depends on where it runs. This is an effect of the environment, not a vulnerability and not a sign of risk. We corrected our own notes the same day.

The practical lesson is for anyone who watches MCP servers for changes by hashing tools/list: compare hashes taken in the same environment, or strip hostnames and paths before hashing. Otherwise a harmless container ID looks like a changed tool.

The rest of this post is what else those runs recorded.

What we ran

On 25 October 2026 we installed 10 servers from our verified cards in Docker on a Windows machine with WSL2, with no credentials and only synthetic data. Seven ran in node:22-slim. Three (excel, fetch, git) ran in an image with uv and Python 3.12; the git one also needed git installed, and a first attempt without it did not start.

For each we sent initialize and tools/list with our probe script and stored the tool names and a sha256 of the canonical list (sorted by name and by key), with separate hashes for descriptions, schemas and both together. The records are on each card under "Tested by us".

All 10 passed. Here "pass" means three things: the package installed and started, it answered the handshake with a valid protocol version, and it returned a tool list. It does not mean the tools work, that they do what their descriptions say, or that any limit the project documents holds. In this first run we called no tools. A second run later the same day added one harmless call, with synthetic data, to four of the servers (memory, everything, git and fetch); the result is on their cards.

Server	Version	Tools listed
excel-mcp-server	2.2.2	46
chrome-devtools-mcp	1.12.0	32
@playwright/mcp	0.0.83	25
Desktop Commander	0.3.1	25
codebase-memory-mcp	0.12.1	17
server-everything	2.0.0	16
mcp-server-git	2026.10.19	12
server-memory	2.0.0	9
Context7	4.4.4	2
mcp-server-fetch	2026.10.19	1

Playwright's count is its default tool set. Its README lists more behind optional --caps groups, which we did not enable.

Same hash twice, or only once

Eight servers (chrome-devtools, codebase-memory, Context7, excel, memory, everything, git and fetch) gave identical hashes in two runs. Desktop Commander was run twice and differed, as above. For Playwright our record does not show a second run, so a repeat could still differ. One matching pair is weak evidence of stability, not proof.

What the names say

From the tool names alone we group tools by what they appear to do. The rules are in the open and deliberately simple: a name such as start_process counts as running commands, write_file as writing files. These groups come from names, not from what the tools do inside, and not from any limit the server enforces. A tool called read_file might refuse most paths; we did not test that.

With that caveat, some names are worth knowing before you connect a server:

Desktop Commander: 7 tool names that start, talk to or stop processes (start_process, interact_with_process, kill_process, force_terminate, list_processes, read_process_output, list_sessions), 5 that write files or folders, and 2 that read or set its own config.
Playwright: browser_evaluate and browser_run_code_unsafe, two tools that run code. The second one has "unsafe" in its name; we only know what the name says.
Chrome DevTools MCP: evaluate_script is the one name our rules treat as running code, among 32.
mcp-server-git: 5 names that change repository state (git_add, git_commit, git_checkout, git_create_branch, git_reset) and 7 that only read.
server-memory: 6 of 9 names create, add or delete stored data.
server-everything: one name, get-env, says it returns environment variables. We did not call it. The project is a reference server for testing clients, so this is not a statement about what it exposes in normal use.
mcp-server-fetch: one tool, fetch, which reaches the network by its name.

The grouping has gaps. For codebase-memory, 16 of 17 names match no group, and for Context7 neither of its two does. That does not mean those tools are harmless; it means our name rules say nothing about them. Cards for those servers show how many tools fall outside any group.

One count that was off

The Desktop Commander card said 24 tools, counted from the source when we wrote it. The running server listed 25 for our test client. We checked the project's src/server.ts on its main branch, where package.json says 0.3.1: it defines 25 distinct tool names, the same 25 the server returned. One of them, give_feedback_to_desktop_commander, is left out when the connecting client is named desktop-commander-app, so for that client the list has 24. The card will say 25, with a note that the count depends on the client.

What this does not show

Apart from one harmless call on four of the servers, we did not test whether any tool works, what it does with real data, or whether it is safe to run. Ten passes on one machine on one day say these packages can be installed and answer a basic request in that environment. For any one server, check the card's other lines (source per line, advisories, access type) before you connect it, and use the report link on the card if something here is wrong.

Full post with the per-server cards: https://agentshortlist.dev/blog/10-mcp-servers-in-docker-what-their-tool-lists-tell-you?utm_source=devto. We also publish a short note on MCP advisories, the MCP Risk Radar: https://agentshortlist.dev/radar?utm_source=devto

We read 25 MCP servers. Here is what we found

Antonio GM — Sat, 24 Oct 2026 13:30:00 +0000

This is a copy of an article first published on AgentShortlist, where the tables and cards live.

On 18 and 19 October 2026 we read the documentation and source of 25 MCP servers and wrote down, line by line, what each one says and does. Every line on a verified card carries a source and a review date. This article adds the 25 cards up.

It isn't a ranking or a security audit. It records what the projects document and what their code shows. Where we couldn't check something, the card says "not verified", and that turned out to be a big part of the result.

Read-only modes: documented in 5 of 25

Plenty of these servers can change data. Whether you can run them read-only is the question that moves the risk the most.

Documented read-only mode or recipe	None found in the docs and source we read	Not verified
GitHub MCP server, n8n-mcp, MongoDB MCP server, DBHub, pREST	Playwright MCP, Desktop Commander, MySQL MCP server, Chrome DevTools MCP, Blender MCP, IDA Pro MCP, Talk to Figma MCP	The other 13

"None found" means we didn't find one in what we read, not that none exists. For browser and design tools a read-only mode isn't really the right idea anyway. For the MySQL server it is, and there isn't one, so the limit has to live in the database user.

Telemetry: three on by default, and mostly silence

Chrome DevTools MCP collects usage statistics by default, and its performance tools can send trace URLs to Google's CrUX API. The Apify MCP server collects telemetry about tool calls by default, with Sentry error tracking. Blender MCP collects a minimal anonymous usage record by default; prompts, generated code and scene data are collected only if you opt in.

All three document how to turn it off. Two more projects, codebase-memory-mcp and context-mode, say they send nothing; we didn't verify that claim. For the other 20 we found no statement either way in the docs we read. What stood out to us is how few projects say anything about what leaves your machine.

Advisories: 40 published, none on the latest versions we checked

We matched the cards to packages on npm, PyPI and Go, but only when we could confirm the package belongs to the same repository. That gave 24 packages across 20 of the 25 cards, with 40 published advisories on OSV.dev in total. Half of those 20 cards have none.

We could check the latest version for 23 of the 24 packages, the npm and PyPI ones, and none of them is affected by a published advisory as of 19 October. We didn't check the latest version of the one Go module, the GitHub MCP server.

Card	Published advisories
n8n-mcp	11
MCP reference servers (filesystem and git packages)	10
GitHub MCP server	4
MySQL MCP server	4
Chrome DevTools MCP, DBHub, Apify, Desktop Commander and Serena	2 each

Read the table with care. More advisories often just means a project is more used and more closely examined, not that it's worse. A package with none isn't proven safe. The practical takeaway is smaller: older versions are affected, so pin a version you've actually checked.

Upkeep: the issue backlogs differ a lot

Open issues created before 20 July 2026, counted on 19 October:

Server	Open issues	Of which older than that date
Playwright MCP	4	0
n8n-mcp	64	16
Chrome DevTools MCP	173	46
GitHub MCP server	380	112
Desktop Commander	311	126
MySQL MCP server	6	1

A busy project collects more issues. The number tells you where to look, not what to conclude.

Projects that point somewhere else

A few READMEs say another option fits better, which is useful to read before you install:

The Playwright MCP README recommends Playwright CLI with Skills for coding agents, because it avoids loading large tool schemas and page snapshots into the model's context.
The awslabs/mcp README recommends the Agent Toolkit for AWS for production software built with coding agents, and calls it the successor to the servers in that repository.
The IDA Pro MCP README opens by recommending the official Hex-Rays server instead.
The MCP reference servers README says they are reference implementations, not production-ready solutions.

What to do with this

If a server can change data, look for its read-only option before anything else. Search the README for telemetry and set the opt-out if you want it. Pin versions and check them against advisories; the config checker does that in your browser. And treat "not stated" as a question to ask the maintainers, not as a yes.

Every card, with its sources, is on the verified cards page. You can compare servers in the live comparator or filter by what you need in the picker. If a card has a mistake, send us the primary source and we'll correct it.