I counted 658 MCP server tools to see how many can write, delete or send

Statio's catalog has a guide for 18 servers, and each guide lists every tool the server returned from tools/list, with a column for whether it reads or changes something. I put the 18 tables into one dataset, sorted the write tools further, and checked six servers against their current releases.

The headline numbers:

• 658 tools across 18 servers. 302 of them (46%) change something.
• 84 tools (13%) delete, remove, overwrite, or do something the server can't undo.
• 29 tools post a comment, send a message, share a file or publish to someone else.
• All 18 servers mix read tools with write tools. 17 have at least one destructive tool. HubSpot is the only one without.
• Six servers have more write tools than read tools: Google Drive, monday.com, Zendesk, Shopify, Airtable and Trello.

Every server in the table

Counts are for the tool list a client gets with the server's default settings. GitHub's second row has every toolset switched on. The server name links to its guide, which has the full tool list.

The median server is 43% writes. Even the most read-heavy ones carry something you would think twice about: Sentry's 15 tools include execute_sentry_tool, which runs about 60 more catalog tools by name, deletes among them. Jira's 40 include update_confluence_page, which replaces a page's content.

How I sorted them

A tool counts as a write when its guide's last column says it changes something. The guides take that column from the server's own read-only hint where the server sets one, and from the source or the vendor's description where it doesn't. Trello's three tools that only change the server's own saved setting count as reads.

A write is destructive when its name or description contains one of these stems: delete, remove, archive, trash, purge, drop, destroy, revoke, retire, cancel, unpublish, merge, overwrite, replace, reset, rebase, pause, unshare, irreversible, permanent, or "not undoable", or when its guide already marks it destructive. Tools that run any SQL, GraphQL mutation or raw API request also count, because they can delete anything the credential can reach.

A write sends when its name or description says it sends, emails, messages, chats, publishes, invites, shares, notifies, comments, replies or posts.

I ran that as a keyword match, then read every write tool and overrode 20 results. In 16 the keyword fired on the wrong word. In four it missed a destructive tool: push_files, Supabase's run_notebook and two raw batch-update tools in Google Drive. Opening a Bitbucket pull request is not destructive just because it has an option to close the branch on merge. Restoring a paused Supabase project isn't either. Each override is in the per-tool CSV with its reason.

What the servers' own annotations say

MCP lets a server mark each tool with readOnlyHint and destructiveHint. I could read the hints for five of the 18 from their source or tools/list output. Where a server set readOnlyHint, it matched my read and write split every time, which is partly by construction, since the guides took their read column from those hints. destructiveHint is where they disagree with me and with each other.

• GitHub (v2.1.0, every toolset on) sets destructiveHint: true on 7 of its 34 write tools and leaves it unset on the other 27, including merge_pull_request and push_files. The specification says an unset destructiveHint defaults to true, so read literally, every GitHub write is destructive.
• Airtable (1.14.0) marks 4 of 9 writes destructive, update_records, update_table and update_field among them, because they overwrite. My rule only counts delete_records. Airtable is stricter than I am.
• HubSpot (0.4.0) sets destructiveHint: false on all 7 writes, including hubspot-batch-update-objects, which overwrites properties on up to 100 records in one call.
• Google Drive (@us-all/google-drive-mcp 1.15.8) derives its hints from the verb at the start of each tool name, and only a list of verbs such as delete, remove and clear gets the flag. 10 of 68 writes are marked and the other 58 are left unset. update-file, which can replace a file's content, and docs-replace-text are not.
• monday.com (agent-toolkit 5.77.2) marks the same 11 tools my rule picked, all_api_write and delete_column included.

Eight of the 18 servers set no read-only hint on any tool: Bitbucket, Google Ads, Google Search Console, the Jira server, Shopify, Trello, Zendesk and Zoom. The specification doesn't ask clients to trust the ones that exist either:

“Clients should never make tool use decisions based on ToolAnnotations received from untrusted servers.”MCP specification, ToolAnnotations (2025-11-25)

What changed since the guides were written

The guides' tools/list runs date from October 16 to 26. On November 12 I checked six servers against their current README, docs or published package:

• Supabase documents eight tools the 0.14.0 run didn't return: create_edge_function_secret, submit_feedback, delete_feedback and five notebook tools that exist on hosted connections only. I added them, which takes Supabase from 29 to 37 tools.
• GitHub v2.1.0, released November 3, has delete_repository in its source and README, with destructiveHint: true and a confirmation step. The README already listed it at v2.0.2, but the guide's tools/list run on 2.0.2 didn't return it, and the HTTP server drops it unless a state key is configured. I couldn't run 2.1.0 here, so it is left out of the counts.
• Firecrawl 3.39.0, released November 10, adds research, government search, developer search and enrichment tools. All are marked read-only. Several register only under certain settings, so I kept the 26 measured on 3.29.1. Because the new tools all read, only Firecrawl's read count is low.
• Airtable's README lists 15 tools. The 1.14.0 package registers 16, the extra one being upload_attachment. The guide had 16.
• HubSpot 0.4.0 still registers the same 21 tools.
• Trello's README documents fewer tools than the 57 the server returns. The guide's count comes from the server.

What this means for access

Most MCP clients take a server as one unit: one config entry, one credential, every tool. With these numbers, granting a server to an agent hands it, on average, 17 write tools alongside the reads it wanted. On Google Drive it is 68.

That is the reason I built Statio to grant access per tool, and I made the full argument in Your triage agent can also merge pull requests. In Statio a server grant covers every tool, a deny on one tool overrides it, and an agent's tools/list only shows what it can call. MCP permissions has the details.

Per-tool grants stop at the tool boundary, though, and Zendesk shows where that leaves you. Its server puts 33 ticket and Help Center operations behind two tools, so a grant on zendesk_tickets covers searching tickets and replying to customers alike. The server's own --read-only flag is the switch for that one.

Method and limits

• Source: the tool tables in the 18 server guides on this site, each from a tools/list run or the vendor's list on the date in the CSV, plus the corrections above.
• What "tools" means here: the list a client gets with default settings. GitHub has 45 more behind optional toolsets, Supabase has a storage group that is off by default, and Zendesk can list its 38 operations as separate tools with --mode all.
• The classes are mine. The keyword rule is crude by design so that anyone can rerun it. Replacing a pull request's description counts as destructive under it, and so does removing a tag.
• Sample: these are the servers Statio has written guides for, which lean toward developer and work tools. Each count describes one release.

Get the data

• mcp-server-tool-counts.csv: one row per server, with the version and date each count was checked.
• mcp-server-tools.csv: one row per tool, with its class, the vendor's hints where I could read them, and every override with its reason.

You're welcome to use either. Please link to this page if you cite the numbers. If a count is wrong, email me at [email protected] and I'll fix it and note the change here.