Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the safety burden is covered. The description adds real value beyond that by naming the specific risk categories inspected (unpinned packages, inline secrets, plain HTTP, auto-approved tools, unreviewed enablement), which tells the agent what kind of findings to expect.

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?

One front-loaded sentence with the verb first and a tight parenthetical clarifying the resource shape. Every clause carries information; nothing is padded.

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?

With annotations covering the safety profile and an output schema presumably describing the findings, the description only needs to explain scope and intent, which it does. The only gap is the ambiguous input format for `config`, which matters given the untyped schema.

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?

Schema description coverage is 0% and the single `config` parameter is an untyped object, so the description must compensate. The parenthetical '(mcpServers map)' does hint at the expected shape, but it does not clarify whether the input is a parsed object or a raw JSON string, nor what keys are meaningful.

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?

States a specific verb (Review) and resource (MCP client configuration JSON), and enumerates the exact classes of issues it looks for. It is clear what the tool does, but it never distinguishes itself from the sibling mcp_server_review, which an agent could easily confuse it with.

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 enumerated checks imply when the tool is useful (auditing an mcpServers config), but there is no explicit when-to-use/when-not guidance and no pointer to mcp_server_review or other siblings for adjacent tasks. Usability is inferred rather than directed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.