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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered; the description reinforces this with 'Never calls the server.' It adds genuinely new context: paid per check, the three-valued outcome (go/no_go/fix), and the goal of avoiding a failed round trip. It does not cover rate limits or failure handling, keeping it below a 5.

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?

Front-loaded with the usage instruction, then the checks, then the return and cost note. Each sentence carries information, though the list of validated checks in the first sentence is dense. Efficient overall with minimal padding.

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?

No output schema exists, so the description usefully explains the return values (go, no_go, fix). Combined with cost disclosure, the usage trigger, and the non-invocation guarantee, it is complete enough for a 5-param tool with nested objects. The nested last_trip object's feedback semantics are left mostly to the 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 100%, so all five parameters are already documented, establishing the baseline of 3. The description clarifies what the 'arguments' param is checked against (required, types, allowed values, unknown keys), which adds modest value, but it says nothing extra about last_trip or license_key beyond the schema.

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: it preflights an MCP tool call, validating server reachability, auth, tool existence, and argument-schema conformance. The closing 'Never calls the server' sharply distinguishes it from actual invocation tools, and from siblings like route or tool_card. An agent can tell exactly what this does without opening the schema.

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?

Gives an explicit trigger ('right before calling a tool on an MCP server you have not used today') and points to list_paid_tools for cost. The 'you have not used today' qualifier implicitly excludes already-used servers, so the when-not is present but not spelled out as a hard rule.

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