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

Annotations mark this readOnlyHint=false, destructiveHint=false, openWorldHint=true, and the description explains why: it starts (launches) every server, a real side effect on the environment. It also discloses the analytical output — toxic-flow combinations of untrusted-read/private-read/data-egress tools. It omits failure/timeout handling and any auth or resource expectations for launching many servers at once.

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 sentence, front-loaded with the action, then the mechanism, then the payoff. The enumeration of toxic-flow conditions is the only length and it is doing real work, so nothing is wasted.

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?

An output schema exists, so return values need not be described, and the description still previews the key finding (toxic flows). It covers the launch-and-audit pipeline adequately; only edge behavior when a server cannot start or hangs is unaddressed for a tool that spins up many processes.

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?

With a single parameter at 100% schema description coverage, the schema already defines 'path' as the MCP config file. The description only repeats the same concept ('in an MCP config file') without adding format, path resolution, or relative-vs-absolute details, so the baseline 3 applies.

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 (audit) over a specific resource (every server in an MCP config file) and what it produces (report of toxic flows). It also pinpoints the scope boundary against a sibling by saying it audits 'each one like inspect_server', so an agent knows this is the whole-config version, not the single-server one.

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 phrase 'audit each one like inspect_server' frames this as the batch counterpart to inspect_server, giving clear usage context. It stops short of an explicit rule ('use inspect_server for one server, audit_config for a whole file') and never mentions check_server or scan_config, so the sibling routing is implied rather than stated.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the agent knows this is a safe outbound read. The description usefully names what is assessed (liveness, maintenance, safety) and the output shape (0-100 score, verdict, signals), but adds nothing about network cost, latency, or failure behavior when the target is unreachable.

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?

Two tight sentences, front-loaded with the purpose before the return shape; nothing is wasted. Slight redundancy in enumerating return values when a full output schema already exists keeps it from a 5.

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, a 100%-covered two-parameter schema, and an output schema handling return values, the description covers what the tool is and what it produces. The remaining gap is sibling differentiation, which matters here because three other tools operate on MCP configurations/servers.

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 coverage is 100%, including the enum and the auto-detect note on 'source'. The phrase 'from its npm package or GitHub repo' restates what the schema already encodes, adding no new format or constraint detail. Baseline 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?

States a specific verb and resource with scope: checking whether ONE MCP server is 'alive, maintained, and safe to use' from an npm package or GitHub repo. Clear, but it never distinguishes itself from the sibling inspect_server, which sounds like a near-neighbor operation.

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?

Usage context is implied: single-server checks sourced from npm or GitHub. There is no explicit when-to-use/when-not statement and no routing between this tool, inspect_server, audit_config, or scan_config, so the agent must infer the boundary.

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

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

Annotations already declare readOnlyHint=false (consistent with spawning a process), openWorldHint=true, and destructiveHint=false, so the safety profile is largely covered. The description adds real value on top: it discloses that a server process is launched, that the tool compares against the previous inspection (implying persisted state), and that it flags poisoned descriptions and missing destructiveHint - details the annotations cannot convey. It stays silent on network/auth implications of the open world.

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?

A single front-loaded sentence with the action first and the audit dimensions collected in a colon list - no filler and no redundancy. Slightly dense, but every clause adds a distinct capability rather than restating the name.

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?

An output schema exists, so the return shape needn't be explained, and the description covers inputs, the act of inspection, and the categories of findings. The only residual gap is the statefulness implied by 'changed since the last inspection' - where that baseline is stored and whether it must be primed - which is left unstated.

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 100%, so command, args, and url are already documented in the schema. The description reinforces the two input modes (stdio command vs Streamable HTTP url) and mirrors the schema's own example, but adds no syntax or format detail beyond it. Baseline 3 applies when the schema carries the parameter documentation.

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 names a concrete verb and resource: it starts an MCP server (stdio command or Streamable HTTP url), reads its tool list, and audits it. It even enumerates the audit dimensions, so the agent knows exactly what output to expect. What it lacks is differentiation from the sibling check_server or audit_config - the reader can't tell from the text alone which of these to reach for.

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 mechanics of use are implied clearly (start the server either via a stdio command or a URL, then audit), but there is no explicit when-to-use, when-not-to-use, or pointer to the alternatives among audit_config, check_server, and scan_config. Given three similarly-named siblings, the routing burden is left to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context by disclosing that it delegates to check_server and is limited to npm-launched servers, but that npm-only scope sits in tension with the source enum offering 'github', and no cost/latency or partial-failure behavior is described for a fan-out operation.

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 sentence, front-loaded with the core action and resource, with the example file name appended as low-cost clarification. No filler or redundancy.

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?

An output schema exists, so return values need not be explained, and the delegated check_server behavior is stated. What is missing is what happens for non-npm entries or when only part of the config fails, which matters for a fan-out scan.

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 100%, so path and source are already documented with an enum for source, giving a baseline of 3. The description contributes nothing about parameter meaning beyond what the schema states.

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 names a concrete action (run check_server) and its scope (every npm-launched MCP server in a config file, e.g. mcp.json), which an agent can distinguish from check_server's single-target behavior. It does not, however, differentiate itself from the sibling audit_config, which appears to operate on the same config-file resource.

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?

Usage is implied: this is the batch counterpart to check_server, so the agent can infer when to pick it. There is no explicit when-to-use guidance and no mention of when audit_config would be preferable, leaving a real ambiguity between config-level siblings.

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