What the MCP Capability Inspector does
The MCP inspector reads what a Model Context Protocol server says about itself - its discover or initialize result and its tools, resources and prompts lists - and turns it into a capability summary, a table of tools with their parameters and safety hints, and a list of specification and safety findings. It never runs anything: you paste the JSON, or load a public JSON file, and the page only reads it.
That makes it useful before you connect a new server to an assistant, when reviewing a pull request that changes tool definitions, or when a client refuses a server and you need to know which field it objected to.
How to use it
- Capture the server's responses. Most clients and SDKs can log the raw JSON-RPC traffic; copy the discover or initialize response and the tools/list response (and resources/list or prompts/list if you want them).
- Paste them into the box - one response, a JSON array of responses, or one response per line. Bare result objects without the JSON-RPC envelope work too.
- Leave the revision on Detect, or choose the revision you want the server judged against, for example 2026-07-28 to see what a modern client will expect.
- Press Inspect and read the summary, the tools table and the findings. Download the tools as CSV or the whole report as JSON to share it.
Reading the results
Errors break a required field or a MUST in the schema; a strict client may reject the result. Warnings cover SHOULD rules, deprecated features and missing capability declarations. Items marked as an A2Z heuristic are our own checks, not protocol rules.
The Read-only and Open world columns show the effective hints after the schema defaults are applied. A tool with no annotations counts as possibly destructive and open-world, because those are the defaults. Hints come from the server and are untrusted unless you trust the server.
Safety findings flag wording in descriptions that tries to steer the model - pseudo-system tags, requests to hide things from the user, mentions of credential files - and invisible Unicode characters. They are pattern matches: a hit means read the text yourself, not that the server is malicious, and a clean result does not prove it is safe.
Worked example: reviewing a GitHub issues server
The first example pastes an initialize result declaring protocolVersion 2025-11-25, tools with listChanged, resources with subscribe and logging, followed by a tools/list with three tools.
The inspector reports 3 tools. search_issues is marked read-only. create_issue is declared not read-only and not destructive, so it shows as additive. The third tool is named "close issue" - the space breaks the 2025-11-25 naming guidance, it has no annotations so it defaults to possibly destructive, and its inputSchema lists "reason" as required without defining it, so a model would have to guess what to send.
It also notes that resources are declared as a capability while no resources/list was pasted. That is not an error - it simply was not captured - but it is worth checking.
Why read declarations before connecting
Everything in a tool description is read by the model as context, which is why the specification tells clients to treat tool annotations and descriptions from untrusted servers with caution. A description that tells the model to read a private key, or to keep something from the user, is a prompt injection that arrives through a tool list rather than through a web page.
Reading the list first also catches ordinary mistakes: duplicate tool names that a client cannot tell apart, required parameters that are never described, a missing inputSchema, or a 2026-07-28 list result without its ttlMs and cacheScope.
Loading a URL
If you publish a static JSON dump of your server's tools, you can load it by URL. The page asks the a2z.tools fetcher for the file as plain text, through the same address checks used by our other URL tools, and puts it in the box. It does not speak MCP to that address, does not open a Streamable HTTP or SSE session, and never calls a tool. If the file cannot be fetched you see an Unavailable notice, never an empty clean report.
Limitations: what the result does not prove
- It inspects declarations only. It cannot tell whether the server behaves as declared, whether its tools are safe to run, or whether an annotation such as readOnlyHint is true.
- The safety checks are heuristics. Injection can be phrased in endless ways, so no finding list can prove a description is harmless.
- Only the page of results you paste is checked; paginated lists (with nextCursor) need every page pasted to be complete.
- JSON Schema inside inputSchema and outputSchema is checked for MCP-specific rules, not fully validated as JSON Schema 2020-12.
Privacy: where your data goes
The analysis runs in your browser. If you choose to load a public URL instead of pasting, a2z.tools fetches that address read-only and returns the text to your tab; private and internal addresses are refused and nothing is stored. Only a public URL you choose is fetched, as plain JSON. The inspector never connects to an MCP transport and never calls a tool. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- Model Context Protocol specification 2026-07-28 - checked 19 Sep 2026
- MCP tools - names, annotations and schemas
- MCP versioning and backward compatibility
- MCP specification 2025-11-25
- MCP schema source (TypeScript)
Frequently asked questions
Does the MCP inspector connect to my server?
No. It reads JSON you paste, or a public JSON file you ask it to load as plain text. It never opens an MCP transport, never sends a JSON-RPC request to a server, and never calls a tool, so it is safe to use on servers you do not trust yet.
How do I get the JSON to paste?
Log the raw messages your client or SDK exchanges with the server, or send tools/list yourself from a test harness, and copy the responses. Paste them whole - the JSON-RPC envelope with jsonrpc, id and result - or just the result objects.
What are MCP tool annotations and can I trust them?
Annotations are hints a server attaches to a tool: readOnlyHint, destructiveHint, idempotentHint and openWorldHint, plus a title. The specification says clients must treat them as untrusted unless the server itself is trusted, because a server can label a dangerous tool as read-only.
What is tool poisoning in MCP?
It is a prompt injection hidden in a tool's description or schema: text the model reads as instructions, such as telling it to read a secret file or to conceal an action from the user. The inspector flags common patterns and invisible characters, but reading the descriptions yourself is the real defence.
Why does the inspector say my list result is missing ttlMs?
In the 2026-07-28 revision, tools/list, resources/list, prompts/list and server/discover results are cacheable and must include resultType, ttlMs and cacheScope. Servers written for 2025-11-25 or earlier omit them. Choose an older revision in the selector to judge the server by the rules it was written for.
Which MCP revision is my server using?
An initialize result states it in protocolVersion. A modern server lists what it supports in supportedVersions of its server/discover result. With Detect selected, the inspector reads those fields; if neither is pasted it assumes 2025-11-25 and says so.
Last reviewed by the A2Z.Tools team against the sources listed above.
