Botworthy

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

Annotations already cover the read-only safety profile, and the description adds useful behavior beyond them: it discloses the freshness signal ('when Botworthy last scanned it') and the miss-path behavior ('If the site hasn't been scanned, says whether a scan is queued'). No rate limits or failure modes for malformed URLs are mentioned, and 'Accepts any URL or domain' sits slightly uneasily with openWorldHint=false, though not enough to be a direct contradiction.

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?

It is one dense sentence plus two short ones, front-loaded with the lookup purpose and the scan-freshness qualifier. The enumeration of five tasks and their control role/accessible-name payload is justified detail, though the sentence is long enough to be slightly heavy to parse.

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 carries the burden of describing returns and does so concretely (blocked status, 0-100 score, advice, per-task outcomes and steps). What is missing is secondary: error behavior for invalid input and the response shape when nothing is cached beyond the queued-scan note.

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 single parameter already has an example of both URL and bare-domain forms, so the schema does the heavy lifting. The description's 'Accepts any URL or domain' restates rather than extends that meaning, making the baseline 3 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?

The description gives a specific verb and resource ('Look up how well an AI agent could use a website ... when Botworthy last scanned it') and enumerates the returned data (blocked status, score out of 100, advice, five task outcomes with control role and accessible name). It does not name the sibling tools, so the boundary with request_scan/report_visit is only implied by the mention of queued scans.

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 title sets the intent ('Check a website before visiting it') and the description states 'Accepts any URL or domain', which implies pre-visit lookup usage. However, it never explicitly says when to call request_scan instead (e.g., when a scan is missing) or when report_visit applies, leaving the routing decision 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?

Beyond the annotations, it discloses that reports are not published and instead influence what Botworthy scans or rescans next, clarifying the downstream side effect. It also supplies substantive privacy and eligibility constraints, all consistent with the non-read-only, non-destructive 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?

Three compact sentences front-load the purpose, then explain the downstream effect, and finish with eligibility and privacy restrictions. Every sentence contributes useful information without filler or unnecessary repetition of the schema.

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?

Together with the detailed schema, the description provides enough context to construct a compliant report and understand why it is submitted. It remains short of fully complete because sibling-tool routing, outcome-selection criteria, and acceptance or error behavior are not explained, and there is no output schema to supply response details.

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 78% schema coverage, the schema already documents most fields, including the nested steps and followedRules structures. The description adds a valuable cross-field prohibition on user information, but does not clarify reporting conventions such as when outcome should be partial versus failed or blocked.

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 opening sentence clearly states that the tool reports to Botworthy how one of five supported tasks went on a website. It provides some post-visit context through the scanning explanation, but does not explicitly distinguish the tool from check_site or request_scan.

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?

It gives strong when and when-not guidance: report a performed task only if the visit involved no login, personal-data entry, or CAPTCHA/bot-check bypass, and never include user information. Explicit routing to check_site or request_scan for related needs would make tool selection more complete.

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?

The annotations already establish that this is a non-read-only, non-destructive, idempotent, closed-world operation. The description adds context the annotations cannot: scans run in asynchronous batches and take days rather than minutes, so the caller must not block on a result. The statement that already-scanned sites are not re-queued corroborates the idempotent hint and explains the deduplication behavior concretely.

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?

Three short sentences with no filler. The action and its constraint come first, the latency warning second, the deduplication behavior last — a front-loaded order that matches the order in which an agent needs the 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?

For a simple three-parameter queueing tool with full schema coverage and no output schema, the description covers the crucial unknowns: asynchronous latency and deduplication of previously scanned sites. It could add a word on whether any confirmation or identifier is returned and how to later verify results via check_site, but nothing essential to making the call is missing.

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?

All three parameters are already documented at 100% schema description coverage, so the description carries no burden here. It adds nothing about the `note`, `agent`, or accepted URL/domain format of `site`, leaving the schema to do all the work. Baseline 3 applies when the schema is fully covered.

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: 'Queue a website that Botworthy hasn't scanned yet.' The scoping condition (only unscanned sites) makes the action concrete. It does not, however, name or differentiate itself from the siblings check_site and report_visit, so an agent must infer the boundary itself.

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 description implies the right moment to call it — a site not yet scanned — and warns 'don't wait for it' because scans take days. That is useful operational guidance. What is missing is explicit routing: an agent should presumably call check_site first to learn whether a site has already been scanned before requesting a scan, and nothing states that or names the alternative.

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