One tool's full risk classification on a published MCP server: category, severity, risk analysis and evidence, OWASP classes, parameter schema and the recommended policy default. Use when deciding whether to allow a specific tool call, e.g. "should execute_sql on this server be permitted?"
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | Tool name as the server declares it. | |
| server | Yes | Registry slug or npm package name of the server. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies this is a read-only query tool (returns classification), but it does not explicitly state that it has no side effects or that it is idempotent. With no annotations, this is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the key purpose and immediately providing a usage example. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, usage context, and output fields well. It could mention error cases (e.g., tool not found) but is adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters with descriptions. The tool description does not add new insights beyond the schema, and with 100% coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a risk classification for a single tool, distinguishing from siblings like check_mcp_server (server-level) and check_mcp_stack (stack-level). It specifies the output contents and provides a concrete usage example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when deciding whether to allow a specific tool call' and gives an example, providing clear context. However, it does not mention when not to use it or specify alternative tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a distinct and clearly separated purpose: checking single servers, batch checking multiple servers, checking a specific tool on a server, accessing change events, and searching the registry. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern: check_mcp_server, check_mcp_stack, check_tool, get_change_events, search_registry. The verb 'check' is used for three tools but the nouns differentiate them clearly.
Five tools is well-scoped for a registry server. It covers the essential operations (search, single check, batch check, tool-level check, change feed) without being overwhelming or too sparse.
The tool surface covers the core functionality of registry lookup and checking. While there is no explicit 'register' tool, the check_mcp_server tool implicitly queues unknown servers. Minor gap: no dedicated tool to list all servers or get a single server's summary without a search.