VerifyLite

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

Annotations already establish readOnlyHint and openWorldHint, and the description adds genuinely new behavior: the fetch is passive (no active probing), billing is x402-based, and no charge applies when the host cannot be checked. It stops short of latency, rate limits, or failure modes.

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 scope, then layers return values, use cases, and billing in dense sentences with no filler. The flag enumeration is long but each item is informative, and no sentence is redundant.

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 still specifies the return values (verdict categories, score range, flag list) and covers the cost model and the no-charge edge case. Nothing an agent needs to invoke this correctly 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?

Schema description coverage is 100% and the single parameter is fully documented as an absolute HTTP/HTTPS URL. The description only reinforces that it takes one URL rather than adding format, length, or validation detail, 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 and resource ('safety check for one URL') and immediately narrows scope to a single URL, which separates it from check_sites_batch and check_site_safety_pro. It also enumerates the exact output shape (verdict, 0-100 score, named flags), so an agent knows precisely what it gets.

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 concrete when-to-use contexts ('before visiting, linking to, buying from, or submitting data to an unfamiliar site') and routes to list_prices for pricing. It never explicitly contrasts with the _pro variant or the batch sibling, so the agent must infer selection from the 'one URL' scope alone.

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 mark read-only and open-world; the description adds key behavior: a Google Web Risk blocklist hit forces an unsafe verdict, no charge when the blocklist is unreachable, and x402 payment via list_prices. It does not cover auth/permissions or rate limits, but adds meaningful billing and verdict logic.

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 the core operation, then lists report outputs, usage scenario, and billing caveat; each sentence carries distinct information. There is no repetition or 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?

No output schema exists, so the description usefully summarizes verdict/score/TLS/redirects/headers and billing behavior. It leaves sibling selection implicit, but otherwise supplies enough to call the tool 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 single url parameter is documented as an absolute HTTP/HTTPS URL, so the description needn't re-specify it. The description only implies link input and adds no format or validation 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?

Names a specific operation: website safety check plus Google Web Risk blocklist lookup, and enumerates the full report fields. The 'plus'/'full report' phrasing distinguishes it from the basic sibling, though it never names check_site_safety or check_sites_batch explicitly.

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 concrete use case: screening links before payment, login, or download, and points to list_prices for paid access. It does not state when to choose check_site_safety or check_sites_batch instead, so exclusions/alternatives are absent.

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 readOnlyHint/openWorldHint annotations, it discloses the pricing model (per site, via x402), the billing exception ('not charged if no site can be checked'), and the full shape of each result including verdict, score, and per-flag evidence. It also points to list_prices for current pricing, which is exactly the kind of context annotations cannot carry.

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 the core capability, then layers cost, output shape, use case, and billing caveat in a tight sequence with no filler. Every sentence contributes distinct 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?

No output schema exists, yet the description enumerates the return payload (verdict, 0-100 score, TLS/redirect/header/mixed-content/insecure-form/domain-age flags, summary count) and the billing and referral path. Nothing an agent needs to invoke or interpret the tool correctly 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?

Schema description coverage is 100% and there is a single parameter, so the schema already documents urls fully. The description's note that pricing is per unique URL is a useful but minor addition beyond the schema's own text, 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 and resource ('batch website safety check... full /safe report for several URLs in one call') and implicitly contrasts with single checks by noting it is cheaper than them. An agent can distinguish this from check_site_safety 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 a concrete use case ('screening every link in a search result, email, or document at once') and a cost-based reason to prefer it over single checks. It does not name check_site_safety or check_site_safety_pro as alternatives, so the routing guidance is implied rather than explicit.

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=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond that: the call is free, so there is no billing side effect to weigh. It does not, however, disclose the return shape or any freshness/caching behavior.

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 short sentences, front-loaded with what it returns, with zero filler. Nothing could be removed without losing meaning.

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 input parameters, no output schema, and simple read-only annotations, the description covers what the tool returns (every tool plus its price). It is adequate for such a trivial tool, though it omits any note on price currency or formatting.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter-level gaps exist.

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 ('Lists every VerifyLite tool and its current price'), which is unambiguous and clearly distinct from the safety-checking siblings like check_site_safety and verify_url. An agent can tell instantly that this is an informational catalog call, not a verification call.

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 gives no when-to-use, when-not-to-use, or alternative guidance; 'Free' is a cost note, not routing guidance. The usage is inferable from the name and purpose, but nothing in the text explicitly directs the agent.

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?

readOnlyHint=true is reinforced by 'side-effect free', and the description adds genuinely new behavioral facts: no network contact, the specific error taxonomy, and the x402 payment requirement pointing to list_prices. The payment/rate-cost disclosure is valuable context annotations cannot express. Minor ambiguity with openWorldHint=true, but not a 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?

Four short sentences, front-loaded with the core purpose and clamped by the input constraint, then the outcome set, then behavior, then usage. No sentence is redundant or padded.

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 correctly describes the return value (normalized form or a named error code) and additionally covers cost model. An agent has everything needed to decide to call it, form the request, and interpret failures.

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 there is only one parameter, so the schema already carries the semantics (type, maxLength 2048, absolute HTTP/HTTPS). The description restates the same constraint without adding format or edge-case detail beyond it, so 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?

It names a specific verb and resource ('URL syntax validator') and immediately scopes the input to 'one absolute HTTP or HTTPS URL', with an enumerated set of failure outcomes. The 'Never contacts the destination' clause implicitly separates it from the check_site_safety siblings, which do contact destinations.

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 clear usage context ('cleaning URLs from user input, scraped pages, or LLM output before fetching them'), which tells the agent when this tool fits. It stops short of naming or excluding specific alternatives (e.g., check_site_safety), so the routing decision 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.