Web & domain tools

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuinely new behavioral context: the return contents (platform agent, hosting network with abuse email and CDN flag, registrar) and a paywall model ('a few free samples a day, then $0.005 USDC per call via x402') that an agent must know before calling. Rate-limit and cost specifics are exactly the kind of disclosure 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?

Two compact sentences with no filler, and the core purpose is front-loaded ahead of the pricing caveat. The opening clause ('Everyone to send an abuse or takedown report to for a site') is slightly awkward syntactically, which keeps it from a 5.

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?

The tool takes one simple parameter, has a full output schema so return values need not be described, and carries annotations covering safety. The description supplies the two things structured fields cannot: what parties are returned and the free-sample-then-paid pricing model, which is essential for correct invocation.

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?

There is a single parameter with 100% schema description coverage ('Domain or URL'), so the schema already does the work and the baseline is 3. The description adds no format detail such as whether a bare domain, a full URL, or a subdomain is preferred, so it neither compensates nor detracts.

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 states a specific resource: the set of parties (platform agent, hosting network, registrar) to whom abuse or takedown reports for a site should be sent. This is clearly distinguishable from siblings like domains__dmca-agent or domains__facts, though it doesn't explicitly name an alternative. The verb is implied (retrieve) rather than stated, which keeps it just short of 5.

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 phrase 'to send an abuse or takedown report to for a site' implies the use case, and the pricing note signals a cost gate, but there is no explicit when-to-use versus when-not-to-use guidance nor a pointer to the related dmca-agent tool. Usage is inferable rather than stated.

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 establish readOnly, idempotent, non-destructive, open-world behavior, so the bar is lower. The description adds genuinely non-structured context: a free-sample quota per day and a per-call cost of $0.002 USDC via x402, which is exactly the kind of rate-limit/cost disclosure an agent needs. It stops short of describing latency or error 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, zero waste: purpose first, then cost/quota. Both sentences earn their place and the key information is front-loaded.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. For a low-complexity single-domain check the description is largely sufficient, with the missing when-to-use-vs-siblings guidance being the only notable gap.

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 a single parameter at 100% schema coverage, baseline is 3; the schema itself only says 'Domain' with no format hint, and the description adds no syntax guidance such as whether a bare name or FQDN is expected. Schema carries the (thin) load and the description does not compensate.

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 phrase 'Registered or available, straight from the TLD registry' clearly conveys a domain availability/registration-status check against the authoritative registry. The verb is implicit rather than explicit, and it does not name or differentiate itself from siblings like domains__facts or domains__dns, so it falls short of a 5.

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?

There is no guidance on when to use this tool versus the many sibling tools (domains__facts, domains__dns, etc.), nor any stated preconditions. The only usage-adjacent content is the pricing/rate-limit note, which is not selection guidance.

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 declare read-only, open-world, idempotent, and non-destructive behavior, so the description is not burdened with explaining safety. It adds valuable behavioral context by disclosing the free-sample quota and the x402 USDC micropayment model, which are not present in structured fields.

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 description is two tight sentences with no wasted words. The core resource is front-loaded, followed by the cost model, making it easy to scan.

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 lookup with rich annotations and an output schema, the description supplies enough to invoke the tool correctly, including payment behavior. The main remaining gap is that it does not clarify how this differs from the domains__abuse-contacts sibling, which is relevant for selection.

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% for the single required domain parameter, and the schema already describes it as 'Platform domain or URL'. The description adds no additional syntax, format, or usage guidance for that parameter, so the baseline score of 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?

The description clearly states the resource returned: a published DMCA / abuse contact (email or form) for major platforms, hosts, CDNs, or registrars. It does not, however, distinguish this tool from the very similar sibling domains__abuse-contacts, leaving an agent to infer the boundary between the two.

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 provides no explicit when-to-use guidance, no conditions for selecting this tool over alternatives, and no prerequisites beyond a domain. Its pricing and rate-limit note is helpful context but does not tell the agent when this tool is the right choice.

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 readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds genuinely non-annotated context: a free daily sample quota and a per-call price ($0.001 USDC via x402), which is material to invocation decisions.

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 with no filler. However, leading with a bare list of record types rather than the action makes the opening slightly less front-loaded than it could be.

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 two-parameter read tool with annotations covering safety and an output schema covering return values, the description is nearly complete. The main omission is any explicit statement of the operation and its domain-of-applicability relative to siblings.

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 both parameters are documented there, including the type enumeration and 'ALL' option. The description's record-type list merely mirrors the schema's type field, adding no syntax or format detail beyond it, 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?

The description enumerates record types (A, AAAA, MX, NS, TXT, CNAME, CAA) which implies DNS resolution, but it never states a verb such as 'look up' or 'fetch.' The agent must infer the action from the title and sibling context rather than from an explicit verb+resource statement.

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?

There is no when-to-use guidance and no comparison to alternatives such as domains__facts. The pricing sentence tells the agent about cost but not about which tool to choose in a given situation.

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 readOnly, idempotent, openWorld, and non-destructive behavior. The description meaningfully adds the commercial behavior: a limited number of free samples per day, then $0.003 USDC per call via x402, which an agent must know before invoking. It stops short of describing return shape 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?

Two tight sentences, with the output contents front-loaded before the pricing caveat. The output list is slightly comma-heavy but every element is informative; nothing is wasted.

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?

An output schema exists, so return values need no prose explanation, and the cost model plus result scope are documented. For a simple one-parameter lookup tool this is essentially complete, with only the missing sibling-routing guidance as a minor gap.

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?

Single required 'domain' parameter whose schema description coverage is 100%, so the schema fully carries parameter meaning. The description adds no syntax, format, or validation detail for the domain value, so the baseline of 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?

Specific resource (a domain's email authentication) plus an enumerated result set: MX, SPF, DMARC records, mail provider, issues, and a grade. This clearly separates it from siblings like domains__dns or domains__facts, which do not cover mail authentication grading.

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 usage (checking a domain's email auth posture) and adds a valuable cost/rate-limit condition, but never states when to pick this over domains__dns or other domain tools, nor any exclusions or prerequisites. Usage is inferable rather than directed.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond the annotations: a free-sample quota and a $0.002 USDC per-call cost via x402, which is important for an agent deciding whether to invoke it.

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 tight sentences with no filler, and the returned-data summary is front-loaded ahead of the pricing note. Slightly list-like rather than sentence-structured, 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?

For a single-parameter read tool with an output schema, the description needn't explain return values, and it covers the data domain plus cost. The only real gap is the absence of sibling differentiation, which the output schema and annotations cannot compensate for.

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% for the single 'domain' parameter, so the schema already documents it. The description adds no additional semantics (e.g., whether URL vs bare domain affects behavior), which is the expected baseline when the schema does 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?

The description lists the returned data fields (registrar, created, expiry, age, status codes, nameservers, DNSSEC) but never states a verb or explicitly says it returns registration facts for a given domain. It also does not distinguish itself from siblings like domains__availability or domains__dns, so the agent must infer the purpose from the title and field list.

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?

There is no when-to-use guidance, no prerequisites, and no reference to alternative tools. The pricing/quota sentence is operational context, not usage guidance, so the agent gets no help choosing between this and the many sibling domain tools.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond the annotations: the cost model (free within a daily allowance, then $0.002 USDC per call via x402) and the fact that results are rule-based with a trademark flag.

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 deliverable and the strategies, followed by pricing. No filler, though the first sentence is dense with a comma-list that could be trimmed.

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 a full schema, an output schema, and annotations carrying the safety profile, the description need only add the cost/allowance model and generation scope, which it does. Nothing critical is missing for correct invocation.

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 the schema already documents all five parameters. The description references TLDs, prefixes, suffixes and the trademark flag, but adds no syntax, format, or defaulting detail beyond what the schema provides.

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 output (rule-based domain candidates) and enumerates the generation strategies (exact, stopword-free, hyphenated, prefixed, suffixed) plus the trademark flag, so an agent knows exactly what it produces. It implicitly separates itself from domains__availability (which would check a name), but never names or contrasts a sibling 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?

Usage is implied by the description ('candidates for a keyword'), but there is no explicit when-to-use, when-not-to-use, or routing to alternatives such as domains__availability for checking live registration. The daily-allowance note gives context but not selection guidance.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-structured context: the metered pricing model (a few free samples per day, then $0.002 USDC per call via x402), which materially affects how an agent should budget or batch calls. It stops short of describing latency, rate-limit behaviour, or failure modes on unallocated IPs.

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 tight sentences with zero waste: the return payload is front-loaded, then the cost caveat. Every clause earns its place and there is no boilerplate.

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 an output schema present, the description need not explain return values, and it correctly focuses on source and cost. An agent has enough to call it correctly: one required IP argument, a read-only idempotent profile, and the payment model. The only real gap is the absence of any hint about overlap with the ip-geolocation siblings.

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?

There is a single parameter and schema coverage is 100%, so the schema already carries the full burden (type plus 'IPv4 or IPv6 address'). The description adds no format, syntax, or edge-case detail about the ip argument. Baseline 3 is appropriate when the schema does the work and the description contributes nothing extra.

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 resource and enumerates exactly what is returned (network, organisation, range, country, abuse email) plus the data source (regional internet registry). An agent can tell what it gets back without opening the schema. It does not explicitly differentiate itself from the near-namesake siblings ip-geolocation__lookup or ip-geolocation__asn, so it falls short of a 5.

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 says what the tool returns but never says when to use it versus ip-geolocation__lookup, ip-geolocation__asn, or domains__abuse-contacts — siblings that plausibly overlap on IP and abuse-email data. The only usage-adjacent content is the pricing model, which is a cost signal rather than selection guidance.

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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-structured context: the free daily allowance and the x402 per-call price, which materially affects an agent's decision to invoke it. It still omits rate-limit specifics and what happens when the allowance is exhausted.

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: the output is front-loaded, the pricing caveat follows. No filler, no repetition of the title, nothing that fails to earn its place.

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?

An output schema exists, so return values need no explanation, and the annotations cover the safety semantics. The description supplies the one thing structured fields cannot — the cost model. The remaining gap is sibling disambiguation, which matters given four adjacent IP/ASN tools.

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?

Only one parameter, and schema description coverage is 100% ('IPv4 or IPv6 address'), so the schema carries the detail. The description's phrase 'for one IP' only restates the single-address scope without adding format or edge-case guidance, matching the baseline for high-coverage schemas.

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 the exact resource returned — ASN, organisation, and hosting flag — plus the scope ('one IP'), so an agent knows precisely what this produces. It does not, however, differentiate itself from close siblings like ip-geolocation__lookup, ip-geolocation__country, or domains__ip-owner, so the agent must infer the distinction.

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 states a cost model ('free within the daily allowance, then $0.0005 USDC per call via x402') but gives no guidance on when to choose this over ip-geolocation__lookup, __country, __batch, or domains__ip-owner. No exclusions, no prerequisites, no routing logic.

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 readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely new behavioral context: a free-sample quota per day and a $0.02 USDC x402 payment per call, which an agent needs to know before invoking. It still does not disclose partial-failure behavior or whether all-or-nothing results are returned.

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 with zero filler, and the scope/capacity constraint is front-loaded ahead of the cost note. Each sentence carries distinct information (capacity, then payment terms).

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 single-parameter tool with an output schema and full safety annotations, the description covers the essentials an agent needs: batch capacity and the payment model. Minor gaps remain around error/partial-result handling for malformed entries in a 100-IP batch.

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?

There is one parameter with 100% schema description coverage, which sets the baseline at 3. The description's 'up to 100 IPs' merely restates the schema's 'max 100' and adds no format or delimiter detail beyond the schema's 'Comma-separated IPs'.

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 ('Full lookup') plus the batch scope ('up to 100 IPs in one call'), which separates it from the single-IP sibling ip-geolocation__lookup. It never names that sibling or ip-geolocation__asn/country explicitly, so the differentiation is implied rather than stated.

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?

No when-to-use or when-not guidance: nothing says to prefer this over repeated calls to ip-geolocation__lookup, nor what happens with more than 100 IPs. The pricing line hints at a cost trade-off for bulk work but is not framed as selection guidance.

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 readOnly, idempotent, non-destructive and open-world behavior, so the bar is lower. The description still adds genuinely useful operational context: a free daily allowance followed by $0.0005 USDC per call via x402, which tells the agent there is a cost/rate dimension not visible in 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?

Two tight sentences with no filler, and the core capability ('Country and continent for one IP') is front-loaded before the pricing caveat.

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?

An output schema exists, so return-value explanation is unnecessary, and pricing plus scope are covered. The only real gap is the absence of routing guidance relative to the ip-geolocation siblings.

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% for the single 'ip' parameter, and the schema already specifies IPv4 or IPv6. The description adds no syntax or format detail beyond restating that the input is one IP, 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 concrete resource and output ('Country and continent for one IP'), with the singular scope distinguishing it from ip-geolocation__batch and the narrower field set distinguishing it from ip-geolocation__asn and ip-geolocation__lookup.

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 phrase 'for one IP' implicitly routes single-IP queries here rather than to the batch sibling, but there is no explicit when-to-use guidance, no comparison against ip-geolocation__lookup or ip-geolocation__asn, and no stated prerequisites for the paid path.

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 readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely new operational context the annotations cannot carry: free usage within a daily allowance, then $0.001 USDC per call billed via x402, which tells the agent about cost and a payment/auth requirement before calling.

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 tight sentences: the returned fields are front-loaded and the cost/payment model follows. No filler, no restatement of the tool name or annotations.

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?

An output schema exists, so return values need not be explained, and cost/auth are covered. The one material omission is sibling differentiation among the four ip-geolocation tools, which an agent must otherwise resolve on its own.

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?

There is a single required parameter with 100% schema description coverage ('IPv4 or IPv6 address'), so the schema fully documents it. The description adds no format, validation, or edge-case detail beyond that, 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 names a specific resource (one IP) and enumerates the exact data returned: country, continent, EU membership, network block, ASN, organisation, hosting flag. That is far more concrete than a generic 'look up IP info'. However, it never distinguishes itself from sibling tools ip-geolocation__asn, ip-geolocation__country, or ip-geolocation__batch, and listing ASN as an output while a dedicated ASN tool exists invites selection ambiguity.

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?

There is no when-to-use guidance and no mention of alternatives. The description implies single-IP scope via 'for one IP', which weakly routes an agent away from ip-geolocation__batch, but the choice between this, ip-geolocation__asn, and ip-geolocation__country is left entirely 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?

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description still adds valuable operational context: free daily samples and a per-call cost of $0.0005 USDC via x402, which tells the agent about rate/cost limits before invoking.

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 core purpose and followed by the pricing caveat. No filler; 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?

For a one-param classifier with an output schema handling return values and annotations covering safety, the description is nearly complete. Only missing usage-context guidance, but nothing essential for correct invocation is absent.

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?

Single required 'keyword' param with 100% schema coverage, so the schema already documents it. The description's phrase 'search keyword' slightly clarifies intent but adds little syntax or format detail beyond the schema. 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 ('Classify'), a specific resource ('a search keyword'), and enumerates the exact output categories (transactional, commercial, navigational, informational). An agent immediately knows exactly what this tool produces.

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 makes the tool's purpose clear but offers no when-to-use/when-not guidance or reference to alternatives. The pricing note implies a paid-first-call context but does not help select between this and sibling tools.

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 readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely non-structured behavior: a free daily sample quota and $0.003 USDC per call via x402, which an agent must know before invoking. It does not describe output shape, but the output schema covers that.

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 tight sentences, zero filler. The functional description is front-loaded and the cost/rate caveat follows, so an agent gets purpose first and constraints second.

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 single-input read tool with an output schema, the description covers purpose, returned fields, and the unusual payment/quota model. Only the lack of sibling routing keeps it from being fully complete.

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?

Only one parameter with 100% schema description coverage, so the schema already documents 'url'. The phrase 'on a page' loosely confirms the single input but adds no format, scope, or crawling semantics 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-like action (extract links) and resource (a page), plus the returned fields (anchor text, nofollow flags). It is clear what the tool produces, though it never names a sibling such as seo__page-audit to sharpen the boundary.

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 by 'links on a page' and the pricing line tells the agent there is a per-call cost after a free daily quota, which is a real invocation constraint. There is no explicit when-to-use/when-not guidance or routing against seo__page-audit or web__read.

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 readOnly/openWorld/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavioral context that annotations do not: a rate/cost model ('A few free samples a day, then $0.005 USDC per call via x402'), which tells the agent to expect throttling and payment.

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 compact sentences: the field inventory is front-loaded and the pricing note follows. Dense but every clause is informative, with 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?

An output schema exists, so return values need not be re-explained, yet the description still sketches them usefully. For a single-parameter read-only tool with full annotation coverage, this is essentially complete; only usage routing against siblings 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 coverage is 100% and there is a single required 'url' parameter already documented in the schema, so the description carries little additional parameter burden. It adds no syntax or format detail (e.g., scheme requirements) beyond 'Page URL'.

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 title 'On-page SEO audit' plus the description's enumerated outputs (title, meta, H1, canonical, noindex, hreflang, structured data, OG tags, word count, links, alt text, issues, score) make it clear this tool audits a single page's on-page SEO signals. It is distinguishable from seo__links and seo__robots-check by the breadth of the field list, though the description itself is a noun list rather than an explicit verb+resource statement.

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?

There is no guidance on when to use this tool versus the sibling seo__links or seo__robots-check, no prerequisites, and no exclusions. The agent must infer applicability from the field list 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuine behavioral context annotations cannot: a rate/access model ('a few free samples a day') and per-call pricing ($0.002 USDC via x402). It also discloses the return entities, though not error 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?

Two tight sentences with the purpose front-loaded ahead of the pricing note. No filler; every clause carries information, though the pricing sentence could arguably be deferred to separate documentation.

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?

Output schema exists, so return values need not be enumerated, and parameter coverage is full. Combined with the disclosed pricing and result contents, the description is complete enough for an agent to invoke it correctly; only explicit when-to-use routing against siblings 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%, so the schema already documents both url and user_agent, making 3 the baseline. The description's mention of Googlebot/GPTBot/ClaudeBot loosely hints that user_agent selects a crawler identity, but adds little syntactic or format 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?

The description names a specific resource (robots.txt fetchability) and states exactly what the result contains: the crawler's permission decision, the deciding rule, and declared sitemaps. It is clear what the tool does, though it does not explicitly differentiate itself from siblings like seo__page-audit or seo__links.

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 guidance and never names an alternative or condition for choosing this over sibling SEO tools. Usage is only inferable from the subject matter (robots.txt checking).

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context by disclosing the billing model: free within a daily allowance, then $0.001 USDC per call via x402, which an agent needs to reason about cost before calling. It does not disclose rate-limit behavior on the paid path or caching.

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 tight sentences with zero padding; the functional scope is front-loaded and the pricing caveat follows it. Every clause conveys 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?

An output schema exists, so return values need not be explained, and the description usefully enumerates the check categories plus the cost model. What is missing is when to prefer this over related domain/email-auth tools, but for a single-input validator the description is close to sufficient.

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?

There is a single required parameter with 100% schema description coverage, though the schema description is only the redundant label 'Email'. The baseline of 3 applies when the schema carries the parameter burden; the description adds no format, normalization, or length constraints beyond what is implied.

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 names the concrete checks it performs on an email (syntax, domain mail acceptance, disposable and role-account flags), so an agent knows exactly what the tool evaluates. It is a resource+checks statement rather than a bare verb+resource, and it doesn't differentiate itself from adjacent validators beyond the implied 'email' scope.

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?

There is no guidance on when to call this versus alternatives such as domains__email-auth or the other validators__* tools, and no prerequisites or exclusions are stated. The only contextual sentence is about pricing, which is not usage guidance.

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 safe-read profile (readOnly, idempotent, non-destructive, openWorld). The description adds genuine behavioral context annotations do not: it discloses the validation method (mod-97 + country length), that a UK sort code is extracted as a side result, and a cost model (free within daily allowance, then $0.0005 USDC per call via x402). The pricing/allowance disclosure is materially useful for an agent deciding whether to call.

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, zero waste; the functional purpose is front-loaded and the pricing caveat follows. Appropriately sized for a single-parameter validator, though the cost detail could arguably be deferred.

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?

An output schema exists, so return values need not be spelled out, and annotations carry the safety profile. For a low-complexity one-parameter validator, the description covers method, a notable side output, and cost. The missing piece is usage/alternative guidance, keeping it at 4.

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?

There is one parameter with 100% schema description coverage, so the baseline is 3. The description implies which aspects of the IBAN are checked (checksum and country length), marginally clarifying the input expectation, but adds no format, normalization, or example details 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?

The description names a specific verb and resource: mod-97 checksum validation, country length check, and UK sort code extraction on an IBAN. This is concrete and distinguishable from siblings like validators__email or validators__imei by the IBAN resource. It stops short of explicitly contrasting with alternatives, so a 4 rather than 5.

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?

There is no when-to-use or when-not-to-use guidance, no mention of prerequisites, and no routing to or away from sibling validators. The only context is the billing note, which says nothing about when this tool is the right choice.

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 establish readOnlyHint, idempotentHint, non-destructive and openWorld, so the safety profile is covered. The description adds behavior beyond that: a cost model (free daily allowance, then $0.0005 USDC per call via x402), which an agent needs to decide whether to call. It stops short of describing error behavior for an invalid IMEI.

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, zero filler. The functional behavior is front-loaded and the cost/rate-limit caveat follows, which is the correct ordering for an agent scanning for purpose first.

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 a single required param, an output schema present (so return values need not be documented), and annotations covering safety, the description supplies everything else an agent needs: what is validated, what is returned structurally, and the payment/allowance model.

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%, but the schema's only param description is the bare word 'IMEI'. The description compensates by disclosing the validation semantics (length + Luhn) that define what counts as a valid input, plus the structural breakdown returned. That is meaningful added meaning over the schema text.

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 verb (validate) and resource (IMEI), and goes further by stating the exact checks performed (length + Luhn) and the output decomposition (TAC, serial, check digit). The sibling set consists of validators for entirely different resources (VIN, IBAN, email, phone, postcode), so no explicit differentiation is required and the scope is unambiguous.

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 explicit when-to-use or when-not-to-use guidance, though the purpose itself makes the intended context obvious. The pricing sentence ('Free within the daily allowance, then $0.0005 USDC per call via x402') is useful decision-relevant context but is not usage routing. Adequate but with a clear gap.

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 readOnly/idempotent/openWorld/destructive=none, so the safety profile is free. The description adds meaningful non-structured behavior: a pricing model (free within the daily allowance, then $0.0005 USDC per call via x402). It stops short of describing handling of invalid or non-UK numbers.

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 core capability and followed by the billing caveat. No filler or redundant restatement of the title.

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?

An output schema exists, so return values need no explanation, and the description covers capability and cost. It is nearly complete for a single-param validator, with only error/invalid-input behavior unaddressed.

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?

Single required parameter with 100% schema description coverage, so the schema already carries the definition. The description only implies the input is a UK number without adding format or normalization guidance, matching the baseline for well-covered schemas.

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 specific verbs (classify, format) and a specific resource (UK phone number), plus the classification taxonomy and E.164 output format. It is clearly distinguishable from siblings like validators__uk-postcode and validators__email without opening any 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?

Usage is implied by the resource name: use it for UK phone numbers. There is no explicit when-to-use/when-not guidance or named alternative, though the siblings are functionally distinct enough that routing ambiguity is low.

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 readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely useful context the annotations cannot: the free daily allowance and the $0.0005 USDC per-call x402 charge, plus that it normalises and splits outward/inward codes rather than only validating.

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?

A single front-loaded sentence with the core function first, the output behavior second, and the cost model last. Every clause earns its place and nothing is 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 an output schema present, return values need no explanation, and the description covers purpose, normalization behavior, and pricing. The only gap is the absence of any statement about invalid-input handling or format expectations, which is minor for a single-parameter validator.

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?

Only one parameter, and schema description coverage is 100%, so the schema already carries the parameter semantics. The description adds nothing about accepted postcode formats, casing, or whitespace handling, 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 specific verbs (validate, normalise, split) on a specific resource (UK postcode format), which cleanly separates it from sibling validators like validators__uk-phone, validators__email, and validators__iban. An agent can identify the tool's function 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?

Usage is implied by the resource name — validate/normalise a UK postcode — but there is no explicit when-to-use guidance, no mention of how it differs from related validators, and no stated behavior for invalid input. The pricing sentence is a cost note, not usage guidance.

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 readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds genuinely new context by disclosing the cost/rate-limit model: free within a daily allowance, then $0.0005 USDC per call via x402, which tells the agent a payment path exists.

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 compact sentences, front-loaded with the substantive validation scope and followed by the pricing caveat. Every clause carries information, though the pricing sentence runs long enough to be slightly dense.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. Purpose plus pricing/rate-limit disclosure make this largely sufficient for a simple single-parameter validator, with the only real gap being routing guidance versus sibling validators.

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 a single parameter and 100% schema description coverage, the schema is the authoritative source; the description adds no format or syntax detail beyond it. Baseline 3 applies, since 'vin' is documented but minimally.

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 names the specific validation dimensions (format, check digit, WMI, model-year candidates), which clearly separates it from sibling validators like validators__imei or validators__iban. It lacks an explicit verb (e.g. 'Validate'), but the resource and scope are unambiguous.

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?

There is no statement of when to use this tool, when not to, or which alternative to prefer. The validator-family naming implies a check operation, but no selection guidance is given for a directory containing many other validators.

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 readOnly, openWorld, idempotent and non-destructive, so the safety profile is covered. The description adds genuine non-annotation context: the metered pricing (free samples then $0.003 USDC via x402) and the fact that only 'public' pages are supported, both of which affect whether and how the agent invokes it.

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 what is returned and then the cost model, with no filler. The enumerated field list is somewhat long but readable and each item is informative.

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?

An output schema exists so return values need not be re-explained, and annotations cover the safety profile. The description still adds the two things structured data does not convey: cost/x402 metering and the public-only scope. Only the absence of guidance relative to web__unfurl keeps it from a 5.

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?

There is a single parameter with 100% schema description coverage ('Public http(s) URL'), so the schema already carries the semantics. The description restates 'public web page' but adds no format, length, or edge-case detail beyond the schema, making the baseline 3 correct.

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 names the resource and output form precisely ('main content of a public web page as clean markdown') and enumerates the returned fields, so an agent knows exactly what it gets. It does not explicitly distinguish itself from the nearby sibling web__unfurl, which likely also extracts page metadata, so sibling differentiation is left to inference.

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?

There is no explicit when-to-use or when-not statement, and no sibling is named as an alternative. The only guidance is the implicit cost model ('a few free samples a day, then $0.003 USDC per call'), which usefully signals this is a metered call but does not tell the agent when to prefer web__read over web__unfurl.

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, idempotent, openWorld, non-destructive), so the bar is lower. The description adds cost/allowance behavior and the x402 payment mechanism, which is genuinely new information an agent needs before calling at volume, though it says nothing about rate limits, failures, or auth setup for payment.

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 tight sentences: the returned-data list is front-loaded and the pricing caveat follows. Every clause carries content, though the opening noun list would read better with an explicit verb.

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 an output schema present, the return shape needn't be described, and the description still sketches the payload plus the billing model for a simple one-parameter fetch. The remaining gap is sibling differentiation (web__read), which matters given the crowded web__/domains__ namespace.

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?

One parameter with 100% schema description coverage ('Public http(s) URL'), so the schema already carries the semantics. The description only says 'for a URL' and adds no meaning beyond that, which is the expected baseline when the schema does the work.

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 enumerates exactly what the tool extracts from a URL (Open Graph, Twitter cards, favicon, theme colour, JSON-LD types, RSS/Atom feeds, sitemaps), which is concrete and distinguishes it from a plain page reader. It lacks an explicit verb and never names sibling web__read, so an agent must infer the contrast from the output list alone.

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 pricing sentence ('Free within the daily allowance, then $0.002 USDC per call via x402') gives a real decision input, and the trigger is implied to be 'I need preview/metadata for a URL'. However, there is no explicit when-to-use versus web__read or web__url-safety, and no when-not guidance anywhere.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: the cost model (free within the daily allowance, then $0.003 USDC per call via x402), which affects whether an agent should call it. It does not clarify whether the output is raw signals or a verdict, but the output schema carries that.

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 substantive signal list before the pricing clause. The enumeration is long but each item is a distinct check, so it earns its place; no filler text.

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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. What is present — signals inspected plus cost — is enough to call the tool correctly; the only real gap is routing guidance against sibling URL tools.

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?

There is a single parameter with 100% schema description coverage ('Public http(s) URL'), so the schema does the work and the baseline is 3. The description adds no format, length, or normalization guidance for the url argument beyond what the schema already states.

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 names the resource (a URL) and enumerates the specific safety signals it inspects — redirect chain, TLS cert, domain age, punycode/lookalike tricks, bare IPs, security-header grade — which clearly distinguishes it from generic fetchers like web__read and web__unfurl. It never states the verb explicitly ('check'/'report on'), but the enumerated signals make the operation unambiguous.

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?

There is no when-to-use or when-not-to-use guidance, and no sibling is named even though web__read, web__unfurl and domains__facts are obvious alternatives an agent would need to disambiguate against. Usage is only implied by the subject matter.

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