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

Annotations only declare readOnlyHint and openWorldHint; the description goes well beyond them by stating it makes no model call, spends no credits, and never runs anything, which directly answers the cost/side-effect question for an agent deciding whether to probe. It also discloses the shape of what comes back, including a 'no_match' verdict path and the fact that operator-run inputs are labeled and never counted as independent — an honesty caveat an agent could not get from annotations.

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 opening routing sentence is well front-loaded, but the trust-card enumeration is delivered as one enormous run-on sentence of comma-separated fields (7- and 30-day counts, distinct inputs, median time and cost, who pays, login, where it runs, what is public) that would be far easier to scan as a short list. Every item is plausibly useful, but the packaging costs readability.

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?

There is no output schema, so the description carries the full burden of describing return values — and it does, covering both the success case (trust card contents) and the null case ('no_match'). For a two-parameter read-only check, an agent has enough to decide whether to call it and how to interpret the result.

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 both parameters are already documented with examples in the schema itself. The description contributes only the word 'optionally' to confirm that site scoping is non-mandatory, which is a marginal addition over the schema's existing 'optional site or host' text. 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: check whether a recently verified workflow exists for a task, and enumerates the concrete task shapes it covers (search a site and read a result, look something up across pages, fill a public form). It does not name its nearest siblings (find_skill, try_skill, search_skills) among the twelve available tools, so an agent must infer the boundary from the 'free, read-only, never runs anything' framing rather than from an explicit routing sentence.

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 ('call this first for a multi-step task on a public website'), three concrete qualifying examples, and an explicit exclusion ('not for easy lookups you can already do with one API call'). The when-to-use condition is front-loaded in the first clause, so the routing decision is available without reading further.

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