knowngood

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint, yet the description adds substantial behavior: enumerated return values, the distinct 'could_not_ask' result never treated as a 'no', tools listed but never called, data sources limited to the named site plus population figures, and no ranking/listing changes. This goes well beyond the structured 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?

Front-loads purpose and return statuses, then adds behavioral constraints in a compact paragraph. It is dense but every sentence carries useful information; a bulleted return list could improve scanability slightly.

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?

For a one-parameter, read-only live check with no output schema, the description supplies the missing return contract (six statuses, including robots.txt exclusion) and clarifies side effects and data scope. An agent has enough to invoke and interpret the result correctly.

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% and the url parameter is already documented with hostname/URL and https assumption. The description does not add syntax or format meaning beyond the schema, so the baseline of 3 for high coverage 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 ('Check') and resource ('website LIVE for WebMCP tools') and enumerates return statuses. It distinguishes scope with 'LIVE' and 'does not consult the index', but does not name or contrast with sibling tools find_capability or get_site_report, so sibling differentiation remains implicit.

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?

Provides contextual cues: use for a live check where a browser is available, and clarifies it never consults the index or affects rankings. However, it never states when to choose this over find_capability or get_site_report; usage is implied from scope but alternatives are not addressed.

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 cover the safety profile (readOnlyHint, non-destructive), and the description adds real value on top: it discloses the return content (probe-verified signals, unverified apparent actions, verification tier, discovery source, report URL) and the empty-result contract ('count:0 with an empty_note — never a nearest guess'). It does not cover pagination or ordering beyond a brief mention of 'fixed published order' in the schema.

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 sentences, front-loaded with the purpose, followed by the result contract. Dense but every clause carries information about what comes back. No filler.

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 nine optional parameters and no output schema, the description correctly takes on the return-shape burden and names what the agent will get. It is nearly complete for a search tool; the main gap is that filter interplay (e.g., no query requires at least one filter) is left entirely 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 78% and the schema itself gives rich filter semantics (has_md, has_mcp, has_webmcp, has_endpoint, transactional). The description adds only the notion of discovery source ('declared agent access, probe discovery, or submitted') and does not restate or extend the filter meanings, so the schema is doing the heavy lifting.

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: 'Find websites where an agent can accomplish a task.' An agent immediately knows this is an index search over agent-ready sites. It does not explicitly contrast itself with siblings (check_webmcp, get_site_report), though those are distinct enough that the risk is low.

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 rather than stated — the description never says when to reach for this versus check_webmcp or get_site_report. It does clarify one important behavioral rule ('never a nearest guess'), which helps the agent interpret a null result, but there are no explicit when-to-use or when-not-to-use instructions.

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 cover the safety profile (readOnly, non-destructive, closed-world), and the description adds genuinely new behavioral context: reports are dated, missing hosts return found:false, and the tool 'never guesses a nearest match'. That no-fuzzy-fallback guarantee is exactly the kind of trait an agent cannot infer 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?

Purpose is front-loaded and the closing instruction ('Cite the report URL and its date') is actionable rather than filler. The middle enumerations make the first sentence long and slightly run-on, but every clause carries information.

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 no output schema, the description must convey the return shape, and it does: tested capabilities, pass/fail, probe time, apparent agent affordances, and discovery source, plus the found:false edge case. Auth requirements and any rate limits remain unstated, a minor gap for a read-only lookup.

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% and the single host parameter is already documented with an example ('example.com'), so the schema does the heavy lifting. The description only restates that the target is one listed website/host, adding no format or resolution detail 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 ('Fetch Known Good's dated verification report for one listed website') and enumerates the report's contents, so the agent knows exactly what comes back. The scope ('one listed website', 'this specific host') separates it from the broader lookup siblings check_webmcp and find_capability.

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 a clear use case in the form of the question it answers ('is this specific host agent-ready?'), which tells the agent when to reach for it. It does not explicitly name check_webmcp or find_capability or state when not to use it, so it falls short of full routing guidance.

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