EXPERIMENT_022 // MCP.CAPABILITY-DISCOVERY.VISUALIZER
Paste or upload an MCP configuration — a JSON list of servers and the tools each one declares — and this experiment shows a server-to-tools capability map, labelling any unreadable server as unavailable instead of breaking the whole view.
LOADING EXPERIMENT...
Across a 12-agent fleet, every agent has its own MCP server list — and no single view showed which tools any one of them could actually call, across all its configured servers, until now. Paste an MCP configuration — or click Load demo preset to see a bundled sanitized example — and this experiment reads the declared server list and renders a capability map: one row per server, each expandable to its full declared tool list, with a name and description for every tool. Nothing is queried live and nothing you paste ever leaves the browser; a server whose declared tool manifest is missing or malformed is labelled unavailable and skipped, not treated as a reason to fail the whole map.
HOW IT WORKS
The parser reads a top-level `servers` or `mcpServers` object — the same shape a real MCP config uses — and, for each server key, its declared `tools` array. This is static introspection of the text you provide, not a live call to any MCP protocol endpoint: nothing configured in the pasted document is ever contacted.
The capability map renders one row per server (name, an available/unavailable status badge, a tool count), expandable to the full declared tool list — each tool's name and, when present, its description. Collapsed by default so a large fleet's surface stays scannable at a glance.
Each server is parsed independently. A server explicitly marked unavailable, one whose entry isn't a valid object, or one whose `tools` field is missing or malformed is labelled unavailable with a short, safe reason — the remaining servers still render in full. Individual malformed tool entries within an otherwise-valid list are skipped the same way, never fatal to the rest of that server's tools.
The parser touches exactly two fields per tool — `name` and `description` — and never reads or surfaces a server's `command`, `args`, `env`, or any credential-shaped field, even when present in the pasted config. Nothing you paste or upload is sent anywhere; the whole analysis runs client-side.
WHAT THIS PROVES
This experiment exists because of a question I kept answering by hand: for any one of the twelve agents in my fleet, which tools can it actually call, across everything registered in that agent's MCP surface? The answer lives scattered across separate config files and per-project overrides — readable individually, but never as one picture. A read-only introspection tool that turns a declared server list into a single capability map is the fastest way to answer that question, without touching a live server or exposing a credential to do it.
Automox's MCP Server 2.2 pitch — a live capability-discovery surface for its own tool set — is one confirming data point that this gap is real and other operators are building against it too, not the reason this exists. The harder, more durable proof is structural: per-server degradation, where an unreadable manifest never takes down the whole map, and a parser that only ever reads a tool's name and description, never its command, arguments, or environment, are the two properties that make a capability map safe to build from a real, credential-bearing config in the first place — not just a sanitized demo one.