io.github.niksa90Published by GitHub account niksa90v0.25.1Updated Nov 6, 2026
Checks MCP tool lists: what agents misread, what breaks clients or caches, breaking changes
Checks an MCP server's tool list for findings, token cost, breaking changes and mid-session drift, so assistants can audit the servers they build.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Follow the launch instructions in the repository.
[toolmenu logo: a plug with a list of tools, one checked]
Checks for MCP servers' tool lists: changes that confuse agents, break prompt caches or break clients, caught before your users hit them.
[npm] [ci] [license: MIT] [MCP: 2026-07-28 and 2025] [toolmenu] [toolmenu MCP server on Glama]
Your MCP server's tool list is the menu every agent reads before it does anything. toolmenu checks that menu the way clients and agents will meet it: across calls, connections, clients and releases. No LLM is involved, so the same inputs always give the same answer and it fits in CI.
Every finding says what's wrong, where it is and what toolmenu saw, and ends with a → Next: step.
It runs on the 22-server bench and on hosted servers (GitHub, Atlassian, Sentry,
Notion, Supabase, Vercel…). What it has found on real servers is in
docs/FINDINGS.md.
Status: 0.25. Spec in docs/SPEC.md, every rule in docs/RULES.md, changes in CHANGELOG.md.
The MCP linters I found grade one snapshot of the menu: tool names, descriptions, schemas. toolmenu also checks when the menu changes:
session pins each
change to the step that caused it, and says where in the list it happened.session tells you whether
yours is one of them. It also checks the menu clients will actually show: a broken
x-mcp-header or a $ref they can't resolve hides a tool or fails every call to
it. When a tool stops to ask the user something, session answers "no" and says
whether the tool can take it.diff finds breaking changes and token growth, and checks the
version bump. history does it across a package's published releases. It installs
old versions with today's dependencies, so it records what they serve now
(FINDINGS F4).Run against the reference server, @modelcontextprotocol/server-everything, it
reports no false findings (bench/).
Needs Node 22 or later. The GitHub Action brings its own if the runner's Node is older, for toolmenu only: your server and the job's later steps keep the job's Node. Your server can be in any language: toolmenu starts it (stdio) or connects to it (HTTP).
One command sets up CI: it snapshots your server into menu.json (the baseline) and
writes .github/workflows/toolmenu.yml for your project (Node, Python, Go or Rust).
Commit both, open a pull request, and toolmenu comments on it.
Every value you pass with --env or --header goes into the workflow as
${{ secrets.… }}, never as text (a name like DATABASE_URL doesn't say it holds a
password); init says which secrets to add. It never overwrites a file.
Run it anywhere in the repository. .github/workflows/toolmenu.yml goes to the git
root, and the server starts in CI from the folder you ran init in, which is also
where menu.json is saved. That's how a monorepo package works: run init in
packages/server. Paths to files in the repository are made relative, so they work on
the runner. init lists anything that won't work there (a file outside the
repository, a localhost URL, a virtualenv the runner doesn't have), each with what
to do.
By hand:
HTTP servers work the same way: npx toolmenu snapshot https://example.com/mcp --header "Authorization: Bearer $TOKEN".
Servers behind OAuth (most hosted ones: GitHub, Atlassian, Sentry…): log in once, in a
browser, and snapshot and session use that login from then on, refreshing it as
needed:
Logins are stored per server in ~/.config/toolmenu/auth (readable only by you);
auth list and auth logout <url> manage them. A server that doesn't allow
dynamic registration needs a pre-registered app: --client-id (and
--client-secret). Over SSH or in a container, auth login --no-browser prints the
login URL instead of opening it: open it on any device, sign in, and paste back the
address the browser ends on (a localhost page that doesn't load is expected). In
CI, where nobody can sign in, pass a token as a header.
Both protocol generations are supported: 2026-07-28 (server/discover, stateless)
and the 2025 initialize handshake, through the official TypeScript SDK.
Every finding and error says what's wrong, where, what toolmenu saw, and ends in a
→ Next: step. Findings marked · unsure are heuristics (names and words): they say
what was seen, not what it means. toolmenu explain <rule> says what a rule checks,
its default level and how to change it (every rule is in docs/RULES.md).
Every command has its own help: toolmenu history --help.
Behind a proxy (HTTPS_PROXY), stdio servers get the proxy and CA settings
(HTTPS_PROXY, NO_PROXY, NODE_EXTRA_CA_CERTS, SSL_CERT_FILE, REQUESTS_CA_BUNDLE…)
along with the minimal environment, and NODE_USE_ENV_PROXY=1 so a Node server's
fetch uses the proxy. Without them a server that calls an API can't reach it, and
fails as if it were broken.
scanscan runs snapshot on every server in an MCP client config (Claude Desktop, Claude
Code's .mcp.json, Cursor, VS Code: the mcpServers or servers object) or in a
text file with one server per line (a URL or a command, optionally name<TAB> first),
four at a time (--concurrency), and prints them side by side, then each server's
findings, like this:
${VAR}, ${VAR:-default} and ${env:VAR} in the config are filled from the
environment. A server whose variable isn't set isn't started with an empty
credential: it's a row that says so. A server that couldn't be started or read
makes the exit code 2, because it wasn't checked; one marked disabled is listed and
left alone. URLs are printed without their query, which can hold a key. Nothing is
written unless --out-dir names a folder for each server's menu file.
mcptoolmenu mcp is toolmenu as an MCP server (stdio), so Claude Code, Cursor or any
other client can check the server it's working on while it works. In Claude Code, as a
plugin (the server, and skills for checking a change, checking a release, and setting up CI):
Or just the server, in any client: claude mcp add toolmenu -- npx -y toolmenu mcp, or
{"command": "npx", "args": ["-y", "toolmenu", "mcp"]} in an mcpServers config.
Each tool runs the CLI in a child process and returns its text report, so options,
toolmenu.config.json and stored OAuth logins work as they do on the command line.
Relative paths resolve from the folder toolmenu mcp runs in, or a call's cwd.
snapshot_menu and check_session start the command you give them, as the CLI does;
clients ask before each tool call unless you allow it. toolmenu's own menu passes its
checks with no findings, on both protocols and in a session (the test suite checks).
It snapshots the PR's build, diffs it against the baseline as it is on the PR's base
branch (or at the previous tag, on a tag push), runs the scenario, and
posts one comment that updates on every push: breaking changes, the token change
("this PR adds ~1,240 tokens to every conversation"), the suggested version bump,
and anything session caught. The same report goes to the job summary.
With sarif, findings also go to GitHub code scanning: alerts in the Security tab,
each on the line of its tool in your menu.json, and a code scanning check on the pull
request. GitHub shows an alert inline in the pull request only when that line changed in
it, so most stay in the Security tab and the check. Run the workflow on pushes to your
default branch too, so GitHub has a base to compare a pull request's alerts with. Code scanning is free for public repositories; private ones need GitHub Advanced
Security.
Outside the Action: toolmenu snapshot --sarif toolmenu.sarif -- node dist/server.js
writes the file beside the usual report (diff and session take --sarif too), or
--format sarif prints it instead.
writes a shields.io endpoint file (tools,
tokens, and errors or warnings, in red, yellow or green) and prints the README line
for it. Commit it with menu.json: it changes when the baseline does, so nothing
has to commit from CI. The badge at the top of this README is toolmenu's own MCP
server (toolmenu mcp), checked by itself.
Server behind auth, or PRs from forks and Dependabot? See docs/github-action.md.
Server that unlocks tools on request? Snapshot the full menu for the baseline and run the session on the default one: servers that unlock tools.
PRs without secrets are skipped, and a skipped check still passes; the skipped output tells you.
session: the menu changing while the agent workssession runs a scripted session (the scenario is the agent), lists the menu
after every step, and reports each change with the step that caused it.
--init writes a starter scenario from the live menu: it calls every read-only tool
that needs no arguments, then repeats one. If a tool looks like it unlocks more tools
(a domains or toolset parameter with an enum, "unlock" or "capabilities" in its
name, a description that says it enables or loads tools), the starter unlocks
every value, listing after each, then repeats the first, so the session sees every
tool behind the unlock. The values come from the parameter's enum or, without one,
from the server's own read-only listing (list_toolsets). Lookups that only describe
toolsets (list_toolsets, get_toolset_tools) aren't unlocks, and one not marked
read-only is suggested, never called. Anything it can't fill in is left as a
commented-out step. An unlock nothing in the menu names, like joining a room that
brings more tools, needs a step you add yourself. A scenario is only as good as its
steps, so the starter is a floor, not a ceiling.
On github-mcp-server 1.0.5 with --dynamic-toolsets (3 tools at the start, 19
toolsets), unlocking every toolset reaches 107 tools: all 81 that --toolsets all
serves, and 23 issue and pull-request tools that only the dynamic mode has.
No scenario? session --auto builds the steps from the menu: every read-only tool
whose required arguments the schema itself gives (a default, examples, an enum,
a type or format), cheapest first, then every value of each read-only unlock (outside
--max-calls, and the first value twice: a second identical unlock should change
nothing), then the first call again. It never guesses an ID: a tool that needs
owner, repo or an issue key is skipped, and the report names the flag that fills
it: --value repo_path=/src/app fills that parameter on every tool that requires it,
--value get_issue.issue_key=ABC-1 on one tool, --values-file values.yml takes a map
of either. Servers that don't mark their tools readOnlyHint (DeepWiki, every
2024-11-05 server) get nothing called unless you vouch for them by name:
--assume-read-only read_wiki_structure,ask_wiki_question. Only exact names are
accepted: a pattern would also cover tools a later release adds. A tool marked or
named as a write is never called, and the report says which tools ran on your word.
With --create-handles on 2026-07-28, --auto also calls the tool that creates a
session, basket or cart (start_session; a write, so only with the flag, and never
one marked destructiveHint; not locks, leases or checkouts) and gives the tools that
take it back the handle it returned, beside the made-up one.
--save-scenario auto.yml writes the steps, with the skipped tools commented out, for
you to fill in. Tools marked openWorldHint: true (web
search, fetch, scraping, which can cost API credits) are called only with
--open-world, except unlocks: changing the menu is what a session watches, and an
unlock spends no search credits, so it runs even on a server that marks every tool
open-world. A run that ends up calling nothing is session/nothing-called (warn),
with why each tool was left out, not a clean pass. On the 22 servers in bench/,
--auto reaches 60 of 262 read-only tools, 84 with --open-world.
session calls tools for real. Without allow_writes: true it refuses any tool
not marked readOnlyHint: true. --plan prints the steps without connecting.
diff: compare releasesThat's two real releases of the official filesystem server. Its calendar versions promise nothing about compatibility, so the bump isn't judged, but the breaking change is still an error. Changes are classified the way OpenAPI breaking-change checkers do it:
The same rules apply inside parameters: fields of an object parameter, array items,
and the options of an anyOf/oneOf union (zod's unions, discriminated unions and
.nullable()) are compared at every depth, with their path (gen.body.text,
search.filters[].field, gen.block(kind="image").url). Union options are paired by
the value of a discriminator they all fix; without one (a plain z.union of objects),
identical options first, so a reorder is no change, then by type and shared property
names. An option gone is breaking, a new one widens. The same change reached through
one shared definition at several places is one finding that lists them (places in
--json). Local $refs (#/$defs/…, #/definitions/…) are expanded first,
recursive ones one level deep, so a schema is compared by what it accepts, not how
it's spelled: moving a repeated block into $defs is one diff/schema-equivalent
notice with its token change ("accepts the same input: ~899 tokens fewer"), and a
breaking change inside $defs is breaking. A schema change no rule classifies is
never silent: it's a diff/schema-other "review it".
On mongodb-mcp-server 2.1.2 → 3.0.0 this finds aggregate.pipeline[]…$vectorSearch.numCandidates
and .limit narrowed from number to integer inside a union, where the whole
pipeline used to be one "review it".
Different spellings of the same schema are one schema (additionalProperties absent,
true or {}; zod 4's safe-integer bounds), and a change every tool shares is said
once for the menu: a server moving from zod 3 to zod 4 reads as its real changes (a
field that became required, the patterns zod 4 adds to email and uuid) plus one
diff/properties-opened line ("27 tools now accept properties they don't list … most
likely a schema generator upgrade"), not a "review it" per object.
The same change in many tools is reported once, with the tools it touches (pageId
is new and required in 25 of 29 tools, on chrome-devtools-mcp 1.8.0); counts are per
change. When a tool loses a parameter and gains a required one with a close name,
diff/param-renamed (warn, unsure) points out the likely rename; both changes stay
breaking. Every breaking finding's next step names the version to release when the
bump is too small.
It also reports the token change per tool and suggests a semver bump. To check the
bump, pass the release versions: --release 1.4.0..1.5.0 (npm, a git tag).
diff/version-bump then warns when the release's bump is smaller. Under 1.0.0 it
reads versions as npm's caret does (^0.2.3 accepts any 0.2.x): breaking changes need
a minor bump, new features a patch, and under 0.1.0 anything goes.
diff/version-backwards warns when the version goes down. Calendar versions and prereleases aren't judged. The version in the snapshot is what the
server reports (serverInfo.version), which is often not the release: the filesystem
server has said 0.2.0 for 19 releases (FINDINGS F5). It's shown, and only checked
with --server-version-is-release. diff also enforces an optional tokenBudget
(diff/token-budget). Order changes are only a notice here: between releases, prompt caches rebuild. Order
matters within a session.
--catalog)Big servers increasingly keep most operations out of the menu: a small fixed menu, a
search tool, and an execute tool (Sentry's search_sentry_tools + execute_sentry_tool,
Atlassian's discover + executeRead). A breaking change to one of those operations
never shows in the menu. snapshot --catalog asks the search tool a fixed set of
queries and keeps the operations it returns in menu.json; diff then compares
operations found in both snapshots with the same rules as tools.
A search returns only its top matches, so toolmenu crawls the catalog by its own
words: it starts from the search tool's own example phrases and the nouns in your tool
names, then searches for every operation it finds or sees mentioned, until 20 queries
in a row turn up nothing new (at most 200). On Atlassian's hosted server that finds all
154 operations behind its 21 tools; on Sentry's, 65 behind 9, the same on every run.
Queries are paced and a rate limit is waited out. An operation not found this time is a
notice (diff/catalog-missing: "not returned by the same queries"), never "removed";
one found only now is diff/catalog-added, and catalogs read with different queries,
or partly (a query failed), are diff/catalog-queries. To steer it, set
"catalog": { "queries": [...], "maxQueries": 200, "crawl": true } in
toolmenu.config.json (FINDINGS F15).
A crawl through search is a lower bound, not a proof: an operation that nothing in the
catalog names, and whose words no query uses, stays unfound. On @sentry/mcp-server
0.42 (stdio) it finds 63 of the 64 operations in the package's catalog; whoami comes
back only when asked for by name. Add queries like that to catalog.queries.
Command routers. Some servers put their operations behind router tools instead:
one tool per area that takes a command and its parameters, and lists its commands
when called with learn: true (Azure's MCP server serves 71 such tools in front of
~410 operations). --catalog detects them (a command parameter, an arguments
object, a boolean listing flag, and a description that says "router" or "sub
commands") and calls each once in its listing mode, never with a command, so nothing
runs. Routers whose command is required aren't called. Detection missed one? Name
them: "catalog": { "routers": ["keyvault", "storage"] }. A router lists everything
it has, so unlike a search the catalog is complete except for routers that failed
(catalog/failed says which, and why).
history: a package's releases, researchedIt installs each published version into a temp directory (install scripts off), snapshots it, and diffs it against the previous version that worked. For every version it records the protocol, the menu, the findings and the dependency versions that actually got installed: an old version installed today resolves its dependencies today, and can serve a different menu than it shipped with.
It's best effort: packages that need env vars, arguments or auth are recorded as failed, with a reason, never skipped. It installs and runs third-party code. Run it in a container.
snapshot also shows what the menu's tokens are spent on: the biggest tools (split
into description and schema), large enums, and waste you can remove:
$defs entry could hold it once: "one ~230-token block ×5 in
content_generateMessageHtml") or across tools (paid once per tool: mongodb-mcp-server
3.0.4 repeats a ~2,200-token pipeline schema in 3 tools). Only the largest repeated
block is named, not the pieces inside it.$defs: definitions nothing in the tool refers to. Notion's server 2.5.2
ships the same 9 in all 24 tools, 72% of its menu.Every tool's estimate is in the menu file, for the ones the summary leaves out:
jq -r '.tools[] | "\(.tokens)\t\(.name)"' menu.json | sort -rn.
snapshot rulesEvery rule comes from a failure I actually hit building 115 tools for one MCP server, or from the spec itself. If a rule can't point to one, it doesn't ship.
The full list, diff and session rules included, is docs/RULES.md.
The naming and ID rules are heuristics, tuned on real servers (FINDINGS F7 and F10) and a private 115-tool one. They're the extras; the change checks are the point.
Pin routing with routes.yml. Two tools fighting over one word needs a regression
test, not a rename you'll forget:
Matching is keyword matching, the way a keyword or BM25 tool search sees the menu: a tool matches if every word of the route is in its name or description (the exact phrase scores higher). It can't read "not", and neither can those searches: a disclaimer like "not the audit trail" puts "audit trail" into exactly the tool you meant to steer away from, and toolmenu says so.
Config (optional toolmenu.config.json):
offlineCheck turns on --offline-check for every snapshot of a stdio server.
descriptionLimit is where your client cuts tool descriptions: a number, or a client
whose cut has been reported: "claude-code" (the default: Claude Code's own docs,
code.claude.com/docs/en/mcp, read 2026-11-02:
16,384 characters for a tool loaded through tool search, which is on by default, and
4,096 for a tool that loads up front, marked _meta["anthropic/alwaysLoad"]: true;
the cut was 2,048 before v2.1.296), "claude-code-upfront" (4,096 for every tool:
Claude Code with tool search off) or
"amazon-q" (10,024, reported in
makenotion/notion-mcp-server#145).
Clients that send descriptions in full don't need a setting beyond that. If your own
client cuts shorter, as mine did at 280, set its number. fullDescriptions lists the
tools it sends uncut, so the description rules skip them.
--client)What an agent sees depends on its client. snapshot --client <name> (or "client" in the
config) checks the menu against what that client's own docs say, and every value
toolmenu uses names its source and the date it was read (src/clients.ts). What a
client doesn't document is left out, not guessed.
The snapshot adds a line such as as Claude Code: up front ~524 tokens · on demand ~344 per tool a search loads (largest: update_contacts, ~2,093), and --json a client
object. With a client that defers tools, search/findable runs at any menu size.
toolmenu sees what the server sends. Plenty of agent failures happen elsewhere:
descriptionLimit); they can't see your client.Exit codes: 0 clean · 1 findings at or above --fail-on · 2 couldn't connect
(for scan: a server wasn't checked) or bad usage. toolmenu <command> --help lists that command's own options.
o200k_base) of what the model reads: each tool's
name, description and input schema. Output schemas, annotations, icons and _meta
stay with the client and aren't counted. Vendors tokenize, cache and bill
differently. diff recounts both menus with the toolmenu that runs it, so a
baseline from an older version still compares fairly; a number quoted elsewhere (a
commit message, a dashboard) should say which toolmenu counted it (0.7.1 changed the
count for menus with icons by up to 5×, FINDINGS F7).Built by Nikša Perović while running a 115-tool MCP server and watching agents trip over its menu. Every rule started as one of those failures, and the research behind them is in docs/FINDINGS.md. The story of building it, and where it was wrong, is on niksa.me.
Found a false positive, or a failure toolmenu should catch?
Open an issue with the menu (a
menu.json is enough) and what you expected. Changes are listed in
CHANGELOG.md.
MIT
Source: README.md at commit 45d002c
Snapshot a server menu
Check an MCP server's tool list: start or connect to it, list its tools, and report findings (what agents misread, what breaks clients or prompt caches) and the token cost. Writes the menu file only when save_as is given (the baseline for diff_menus).
cwdenvurlclientcatalogcommandheaderssave_asDiff two menus
Compare two menu files (from snapshot_menu save_as, or toolmenu snapshot): breaking changes for clients, the token change per conversation, and the version bump it needs. Reads files only.
cwdafterrequiredbeforerequiredreleaseRun a session against a server
Check whether an MCP server's menu changes while an agent works: call its tools marked readOnlyHint whose arguments the schema can fill, list the menu after each call, and report each change with the call that caused it. Calls only read-only tools; never one marked openWorldHint unless open_world is set.
cwdenvurlcommandheadersmax_callsopen_worldExplain a rule
Explain a toolmenu rule by the name a finding gives (naming/vague-id): what it checks, its default level and how to change it. Without rule, lists every rule.
rule90% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
npx toolmenu snapshot -- node dist/server.js # or: npx toolmenu snapshot https://example.com/mcpnpx toolmenu init -- node dist/server.js # CI: a baseline, a workflow, a comment on every PRnpx toolmenu init -- node dist/server.js # add --with-session to also run session --autonpx toolmenu snapshot -- node dist/server.js # the menu, its findings, menu.jsonnpx toolmenu diff menu.json new-menu.json # what changed between two releasesnpx toolmenu session --auto -- node dist/server.js # call read-only tools, watch the menunpx toolmenu auth login https://mcp.example.com/mcpnpx toolmenu snapshot https://mcp.example.com/mcpnpx toolmenu scan ~/Library/Application\ Support/Claude/claude_desktop_config.jsonnpx toolmenu scan .mcp.json --format markdown server tools tokens findings github 42 ~18K 1 error · 2 warn filesystem 11 ~2.1K no findings linear – – not checked: LINEAR_API_KEY is not set (the config refers to it)/plugin marketplace add niksa90/toolmenu/plugin install toolmenu@toolmenu# .github/workflows/toolmenu.ymlon: pull_requestpermissions: contents: read pull-requests: writejobs: toolmenu: runs-on: ubuntu-latest steps: - uses: actions/checkout@v7 - uses: actions/setup-node@v7 with: { node-version: 22 } - run: npm ci && npm run build - uses: niksa90/[email protected] with: command: node dist/server.js baseline: menu.json # your committed snapshot scenario: scenario.yml # optional: run a session tooon: pull_request: push: branches: [main] # the base GitHub compares a pull request's alerts withpermissions: contents: read pull-requests: write security-events: write # to upload SARIFsteps: # … checkout, build, as above - uses: niksa90/[email protected] with: command: node dist/server.js sarif: toolmenu-sarif - uses: github/codeql-action/upload-sarif@v4 if: always() # findings fail the toolmenu step; upload them anyway with: sarif_file: toolmenu-sarifnpx toolmenu snapshot --badge toolmenu-badge.json -- node dist/server.js# scenario.ymlallow_writes: false # refuse to call tools not marked readOnlyHintsteps: - list - call: search_forms args: { query: onboarding } - call: unlock_toolset args: { toolset: audits } - wait_for: tools_list_changed # optional; timeout_ms defaults to 5000npx toolmenu diff menu.json new-menu.json$ npx toolmenu diff --release 2026.1.14..2026.8.31 fs-2026.1.14.json fs-2026.8.31.jsontoolmenu diff secure-filesystem-server 2026.1.14 → 2026.8.31 changes 1 breaking (1 tool) · 0 minor · 3 notice (13 tools) version suggested bump: major · not checked (calendar version) tokens ~1,640 → ~1,664 (+24, estimate): this release adds ~24 tokens to every conversation that loads the menu tools 14 → 14
ERROR diff/safety-hint `move_file` was marked additive-only and is now destructive (destructiveHint false → true; unset means destructive). Clients that auto-approve additive tools may now ask first. → Next: If the tool still never deletes or overwrites, set destructiveHint: false; if it does now, say so in the release notes.INFO diff/annotations Annotations changed the same way (openWorldHint (unset) → false) in 13 of 14 tools: read_file, read_text_file, read_media_file, read_multiple_files, write_file, edit_file, … (+7).…npx toolmenu snapshot --catalog -- node dist/server.jsnpx toolmenu history @modelcontextprotocol/server-filesystem --versions 19 --arg /tmp --csv fs.csvaudit: must_match: [list_team_audits] must_not_match: [get_audit_trail]audit trail: must_not_match: [get_store_scores] # on its own: must not match at all{ "rules": { "naming/shared-word": "off", "ids/authored": "error" }, "ignore": ["debug_*"], "routes": "routes.yml", "tokenBudget": 4000, "descriptionLimit": "claude-code", "fullDescriptions": ["search_capabilities", "lookup_*"], "offlineCheck": true}--out <path> where to write the menu (default: menu.json)--no-write don't write the menu file--routes <path> routes.yml--config <path> config file (default: toolmenu.config.json, if present)--format <fmt> text (default), json, github (annotations) or markdown--fail-on <level> error (default), warn or info--header <k: v> HTTP header, repeatable--env <K=V> env var for a stdio server, repeatable (it only gets a minimal environment otherwise)--timeout <ms> per-request timeout (default: 30000)--protocol <p> auto (default), legacy (2025 handshake only) or modern (2026-07-28 only; an error if the server lacks it)--processes <n> server processes or connections to compare (default: 2); 1 opens no second one, session's scope check included--lists <kinds> snapshot: also read and check prompts, resources (comma-separated); saved in the menu file beside the tools--client <name> snapshot: check the menu for one client, from its own docs: claude-code, claude-api-search or openai--as <name>:<cred> snapshot: list the menu as this identity too, repeatable: "reader:Authorization: Bearer …" (HTTP) or "admin:ROLE=admin" (stdio). The first is the menu saved; the others are compared--offline-check snapshot (stdio): also list the menu with the network cut off--concurrency <n> scan: servers checked at a time (default: 4)--out-dir <dir> scan: write each server's menu file there, as <name>.json