The Model Context Protocol, usually shortened to MCP, is a way for AI applications to connect to external tools and data sources through a standard interface. Instead of each application building a custom integration for each tool, the tool exposes itself as an MCP server, and any compatible client can discover what the server offers and use it. That standardisation is powerful, and it creates a new responsibility: before you connect a client to a server, especially a server you did not write, you should inspect what it claims to offer, and verify that its claims match its behaviour. A server that offers more than you expected, or that behaves differently from its description, is a risk to understand before it touches your data, not after.
The MCP Capability Inspector helps with that inspection. It queries a server for its declared capabilities: the tools it exposes, the resources it can read, the prompts it offers, and the protocol features it supports. Think of it as reading the menu before ordering, and checking that the kitchen actually serves what the menu promises. The inspector does not make the server trustworthy. It makes its claims visible, which is the first step toward judging trustworthiness.
The pieces of a capability: tools, resources, and prompts
An MCP server can expose three main kinds of capability. Tools are actions the client can ask the server to perform: searching a database, creating a file, sending a message, running a calculation. Tools are the most powerful capability, because they change things, and they deserve the most scrutiny. For each tool, inspect its name, its description, and its input schema, meaning the parameters it accepts and their types. A tool whose description is vague, whose parameters are broad, or whose name suggests one thing while its schema allows another, should be treated with caution. A tool named "read file" that also accepts a parameter for writing, or a tool with a parameter that accepts arbitrary commands, is a red flag, not a convenience.
Resources are data the server can provide for reading: files, database rows, documents, or other content exposed through addresses. Resources are generally less risky than tools, because reading does not change state, but they still deserve inspection, because a resource may expose more data than you expect. Check which resources are listed, whether their addresses reveal internal paths or identifiers, and whether any resource gives access to sensitive content such as credentials, private messages, or system configuration. A server that exposes its own configuration files as resources is misconfigured, however convenient it may seem during development.
Prompts are reusable templates the server offers, such as a standard instruction for reviewing code or summarising a document. Prompts are the least risky capability in most cases, but they still deserve a read, because a prompt template shapes what the model is instructed to do, and a template that includes instructions to ignore safety rules, to reveal system content, or to take actions without confirmation is a problem, even if it arrives in the innocent-looking form of a template.
Beyond these three, servers declare protocol capabilities: which protocol version they support, whether they support features such as sampling, where the server asks the client model to generate text, and how they handle logging and progress notifications. These details matter less for a first inspection, but they matter for compatibility: a client that expects a feature the server does not support will fail in confusing ways, and an inspector report that lists supported features helps you predict those failures before you wire the server into an application.
A worked example
Suppose you are evaluating a server that claims to help with project documentation. You run the inspector and find that it exposes three tools: list documents, read document, and search documents. The schemas look reasonable: each takes a document identifier or a search term, and returns text. It also exposes resources for the same documents, and one prompt template for summarising a document. So far, the server matches its description, and the capabilities are read-only, which limits the risk considerably.
Then you look closer and notice a fourth tool you did not expect: update document, which accepts a document identifier and new content. The server's documentation did not mention writing, and the team that proposed the server described it as read-only. That discrepancy is the whole point of inspection. It does not necessarily mean the server is malicious; it may be a general-purpose server with writing enabled by default, or a feature the documentation forgot. But it changes the risk assessment entirely: a client connected to this server could, through a compromised prompt or a mistaken instruction, modify documents. The correct response is to ask why the tool exists, whether it can be disabled, and whether access controls limit who can use it, before connecting the server to anything that matters. If the writing tool cannot be disabled and is not needed, that is a reason to choose a different server, or to place this one behind a proxy that blocks the tool.
A second scenario shows the subtler value of inspection. Suppose the inspector reports that a tool's input schema accepts a free-form string for a file path, with no restriction. Even if the tool is described as reading only project documents, a free-form path parameter may allow reading files outside the project, depending on how the server validates it. You test with a path outside the project directory, in a safe test environment, and find that the server refuses it. Good: the validation exists even though the schema does not show it. If instead the server returns the file, you have found a path traversal weakness before any real data was exposed. Inspection plus a small, safe test beats either alone.
Common mistakes
The first mistake is connecting first and inspecting later, or never. The order matters, because once a client is connected, a tool can be invoked by a prompt, including a prompt that arrives from untrusted content, and the window for careful judgement has closed. Inspect before connecting, and re-inspect after updates, because a server update can add capabilities silently.
The second mistake is reading only tool names. Names are marketing. Schemas and descriptions are the substance. A tool named "get weather" with a schema that accepts arbitrary code is not a weather tool. Read the schema for every tool you intend to enable, and be suspicious of tools with very broad parameters.
The third mistake is enabling everything by default. Most clients allow you to enable a subset of a server's tools. Enable only the tools your application needs, and leave the rest disabled. The tools you never enable cannot be misused, however the server or the prompts behave. Least privilege is not paranoia. It is the cheapest security control available.
The fourth mistake is trusting the inspector's output as proof of safety. The inspector reports declared capabilities, not actual behaviour. A server can declare one thing and do another, and only testing, code review, or a trusted source can close that gap. Treat inspection as the first step in evaluation, not the last.
Honest limitations
Capability inspection cannot detect malicious behaviour hidden behind honest-looking declarations, and it cannot assess the quality of the server's implementation, its handling of your data, or its compliance with privacy rules. Those require code review, testing, and, for sensitive use, formal assessment. Inspection also depends on the server answering honestly; a server designed to deceive an inspector will pass inspection while behaving differently in use. That is why inspection pairs with other controls: running servers in restricted environments, limiting their access to data, monitoring what they are asked to do, and keeping audit logs of tool invocations.
Closing
Inspect before you connect: list the tools, resources, and prompts, read the schemas rather than the names, question anything the documentation did not mention, enable only what you need, and test the boundaries in a safe environment. To check the structure of a server's configuration, use the JSON Schema Validator, and to compare a server's interface with a web API you already know, try the OpenAPI Specification Diff Checker. For the discipline of building safe tool interfaces, read Function Calling Schema Builder Guide.