Bewary: scam, phishing and fraud checks

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

Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds useful non-schema behavior: oldest-first ordering, cursor-based incremental reads, free cost, and API-key requirement. It stops short of explaining filter behavior or output pagination metadata, so not a 5.

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 clauses, front-loaded with the resource and ordering, then pagination and cost/auth. No redundant restatement of 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 and annotations cover much of the calling contract, and the description adds ordering, pagination, and auth/cost. However, with 0% schema description coverage and four optional filters, the lack of guidance for limit/types/watch_id leaves an agent guessing about filtering.

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 0%, so the description must explain all four parameters. It partially explains cursor via next_cursor, but says nothing about limit, types, or watch_id, leaving most filter semantics undocumented.

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 identifies the resource as the account's watch events and specifies oldest-first ordering, so it is more than a name restatement. It does not explicitly distinguish this event feed from list_watches or the lookup_* tools, but the resource is clear.

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 pagination usage ('Keep next_cursor...') and constraints (free, API key required), which helps invocation. It does not state when to choose this over list_watches or how the optional filters should be used.

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 closed-world, so the safety profile is covered. The description adds two genuinely new operational facts the annotations do not: the call is free and an API key is required. It stops short of noting pagination or result limits, which keeps it at 4.

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, and the resource scope is front-loaded ahead of the cost/auth note. Nothing is repeated from the title 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?

For a zero-param read tool with rich annotations and an output schema, the description covers what is missing from structured fields: cost and authentication. Only the absence of any result-volume or pagination hint keeps it just short of 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?

The tool takes no parameters, so per the baseline the schema cannot be improved upon and 4 applies by default. The description correctly introduces no parameter concepts that do not 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?

The description states the resource and scope precisely: every live watch on the account, with 'live' adding a meaningful filter the name alone does not convey. It is clearly distinct from the lookup_* siblings and from watch/unwatch, though it relies on the tool name to supply the verb '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?

Usage is only implied: an agent can infer this retrieves watches while watch/unwatch modify them, but the description never says when to call this versus those siblings or any precondition beyond an API key. For a zero-parameter listing tool the implied path is short, so 3 rather than 2.

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=true, so the safety profile is covered. The description adds genuinely useful context beyond that: a stated cost of 1 credit and the fact that it reports live vs. pulled status, which matters for interpreting results. It does not cover rate limits or what happens on a not-found app, keeping it below a 5.

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 clauses: the question it answers, the fields returned, and the cost. The cost is placed last where it belongs, and nothing is repeated from the schema 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?

With an output schema present, return values need not be spelled out, and the description nonetheless previews them plus the credit cost. The only gap is not clarifying whether a delisted app returns a status or an error, which an agent would want to know before calling.

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 67% — app_id and storefront are documented, while store is only an enum without prose. The description contributes nothing about parameters, so the schema carries the load. That lands at the baseline 3.

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 frames a specific question (is this app live, or did the store pull it?) and names the resource and the returned fields: name, developer, rating count, first/last seen live. That is a concrete verb+resource that an agent can distinguish from the lookup_domain, lookup_email, lookup_phone siblings in the same family.

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 opening question makes the trigger condition clear: use this when you need to verify an app's live status or pull its store metadata. It does not state exclusions or point to alternatives, but the sibling names make resource routing obvious, so context is clear without explicit when-not 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 and openWorldHint. The description adds credit cost and a higher deep cost, which is useful behavioral context, but it does not explain auth requirements, rate limits, or what deep changes beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One terse sentence with no filler; the output list and cost are front-loaded. However, the fragment style and ambiguous 'deep 30' reduce clarity slightly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained. Still, for a lookup tool with a sibling related_domains and an undocumented domain parameter, the description omits usage and parameter details, leaving gaps.

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 50%: deep is documented in the schema, while domain is not. The description only adds 'deep 30' cost, not domain format or deep semantics, so it does not compensate for the undocumented domain parameter.

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 specific outputs (domain age, lookalike-brand technique, abused TLD, blocklist status, verdict), making the resource and value clear. However, it is a noun phrase without an explicit verb and does not distinguish this from related_domains or other lookup_* siblings.

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 guidance is given on when to use this tool versus related_domains or other lookup tools; only cost is mentioned. The agent must infer usage from the name and title.

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=true, so the safety profile is covered. The description adds useful context with the 1-credit cost and output categories, but it does not say whether results can be missing or what external lookup behavior entails beyond the openWorldHint annotation.

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 short and has no wasted sentences, and the cost note is useful. However, the fragment style reads as a field list rather than a front-loaded explanation of what the tool does, weakening structure.

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 one-parameter lookup with an output schema and read-only/open-world annotations, the description gives cost and output categories. It still omits address semantics and sibling routing, so it is only minimally 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?

The sole required parameter is address, but schema description coverage is 0% and the description never mentions address format, validation, or how the input maps to the returned facts. With one undocumented parameter, the description does not compensate for the schema gap.

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 concrete data returned (mail server, disposable/free provider, role mailbox, sender domain facts), but it is a noun-phrase fragment and never states the action or resource itself; the name and title carry 'look up email address.' It also does not distinguish this tool from the sibling lookup_domain despite overlapping domain-related output.

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, prerequisites, or exclusions, and only mentions cost. An agent must infer from sibling names whether lookup_email or lookup_domain is appropriate.

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 and openWorldHint, and an output schema exists, so the bar is lower. The description still adds real value by disclosing the 1-credit cost and the precise validation dimensions performed (length, structure, check digits), which the annotations do not cover. It omits any note on rate limits or data freshness for the community report.

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 tightly packed questions plus a cost note in one paragraph, with the core capability front-loaded. The interrogative framing is slightly unusual but efficient; no sentence is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema handling return values and annotations covering safety and open-world behavior, the description covers what remains: validation scope, bank resolution, community signal, the country-mismatch use case, and cost. Nothing an agent needs to call it 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 coverage is 100%, so baseline would be 3. The description goes beyond the schema by explaining the purpose of claimed_country — comparing it against the IBAN to surface a mismatch — which the schema only describes as 'ISO 3166-1 alpha-2 country the payee claims.' That added intent justifies a 4.

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 (IBAN) and enumerates exactly what is returned: validity across country length/structure and check digits, bank name and BIC, and community report status. That is far more specific than the sibling lookup_* tools' bare resource names, so an agent can separate it from lookup_wallet or lookup_payment_handle immediately.

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 a concrete conditional: pass the claimed country specifically to catch a mismatch between what the payee says and what the IBAN encodes. It also states the cost (1 credit), which shapes invocation decisions. It stops short of naming an alternative tool or an explicit when-not-to-use case.

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=true, so the safety profile is covered. The description adds genuinely useful non-schema context — the 'Cost: 1 credit' billing disclosure — but omits failure behavior (private/reserved IPs, invalid input) and any rate or quota context.

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 fragments with zero filler and the credit cost front-loaded alongside the payload summary. It is efficiently sized, though the telegraphic style makes it read as field names rather than a coherent statement.

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 needn't be spelled out (the description nonetheless lists them, partially duplicating it). The critical gap is input-side: nothing tells the agent what an acceptable 'ip' value looks like. For a one-parameter tool this is the only thing the description needed to add, and it did not.

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 single required 'ip' parameter has 0% schema description coverage and the description says nothing about it — no IPv4 vs IPv6 acceptance, no format example, no domain-name rejection rule. The only schema signal is type:string, which the description does not build on.

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 is a fragment listing returned attributes (owner, ASN, country, hosting type, rDNS) rather than a stated action; combined with the name and title an agent can infer it enriches an IP, but the description itself never says what it does. It also gives no explicit differentiation from the many lookup_* siblings, which are separated only by their resource in the tool name.

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 mention of when a different lookup_* tool applies, and no prerequisites. An agent must infer usage entirely from the tool name.

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 readOnly and openWorld annotations, the description discloses cost (1 credit), the scam-list check, and an important output privacy constraint: existence and status only, never the person's name. These are meaningful behavioral details an agent would otherwise not know.

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 existence/status question and then the privacy and cost constraints. Every sentence adds useful information with 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?

With an output schema and annotations already present, the description supplies the remaining decision-relevant context: cost and privacy limitations. It is complete enough to invoke correctly, though it could mention pagination or rate-limit behavior if applicable.

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 only 50%, but the description compensates by naming the supported providers and the handle formats ($Cashtag, PayPal.me name, Venmo username). It reinforces the provider enum and handle semantics beyond 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?

The description states a precise lookup operation across named payment providers and specifies the exact checks performed: existence, active status, and scam-list membership. It distinguishes this tool from adjacent lookups like lookup_email or lookup_wallet by naming Cash App, PayPal.me, and Venmo.

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 payment-handle domain makes usage broadly clear, but the description does not explicitly say when to use this tool versus other lookup_* siblings or when not to use it. It implies usage through the provider names without offering alternative routing or exclusions.

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=true, so safety is covered. The description adds useful cost information (1 credit; 10 with line type), which is real behavioral context beyond annotations, but it does not clarify auth requirements or output freshness despite the open-world hint.

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 short and front-loads return fields and cost, but it is written as two fragments rather than a coherent sentence. The phrase 'with line type 10' is not self-explanatory and would benefit from clearer phrasing.

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 the description need not enumerate return values, yet it does so instead of covering the missing essentials: acceptable phone number format, auth requirements for line_type, and any ambiguity around credit cost. For a 2-parameter lookup tool with only 50% schema description coverage, this leaves significant gaps.

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 only 50%, and the description does not compensate for the undocumented `number` parameter—there is no format guidance such as E.164 or country-code expectations. The `line_type` parameter is described in the schema, and the description's phrase 'with line type 10' ambiguously relates to cost rather than parameter semantics.

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 what the lookup returns (country, number type, blocklist status, verdict) but never states a clear verb or scope such as validating or enriching a phone number. The title and name make the resource obvious, but the description itself only implies the purpose.

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 siblings such as lookup_email or lookup_iban, nor any prerequisite or exclusion. The only usage-adjacent information is pricing, which does not tell an agent when to select this tool.

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=true, so the safety profile is covered. The description adds a genuinely useful non-schema fact — a cost of 1 credit — but says nothing about what happens when a code is unknown, whether results are cached, or how the scam/shared classification should be interpreted.

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?

One question plus one cost clause — tight and front-loaded, with no wasted sentences. The question form is slightly informal but not misleading, and the cost is placed where an agent will actually see it.

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 tool is structurally simple with only two parameters. However, with zero schema coverage the agent still lacks the input format and country-scoping behavior needed to call it correctly on the first try.

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 0%, so the description carries the full burden for the two parameters and delivers nothing: no short-code format (digits only? length?), no explanation that country defaults to US, and no note that the same code can differ across countries.

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 the resource ('this SMS short code') and the exact questions the lookup answers: operator identity, legitimacy, shared vs. scam status. Against siblings like lookup_phone and lookup_domain, the resource is unambiguous, so an agent can route 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?

There is no guidance on when to choose this tool over lookup_phone (which may also accept short codes) or when not to use it. The country parameter's role is never mentioned, leaving the agent to infer that a short code may be country-scoped.

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 and openWorldHint, so the safety profile is covered; the description adds real value beyond that by disclosing the credit cost (1, or 30 for deep) and the specific behavior of reporting whether a shortener itself disabled, flagged, or removed the link. It omits that deep mode requires an API key, leaving that to the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Roughly two sentences with zero filler: the purpose question is front-loaded, the resolution behavior follows, and the cost caveat is compressed to a fragment at the end. Every clause carries information an agent would otherwise have to guess.

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 not be spelled out, and the description covers the key behavioral facts (redirect chasing, shortener verdicts, cost). The main residual gap is the API-key prerequisite for deep mode, which lives only in the schema rather than the prose.

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 only 50% — the required 'url' parameter has no description at all — so the description has to compensate, and it does partially by explaining what happens to the URL (redirect/shortener resolution). It also adds cost semantics for 'deep' (30 credits) that the schema does not state, though it never clarifies accepted URL formats.

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?

Opens with a concrete question ('Is this link safe to open?') and then names the mechanism: resolves shorteners and redirects and reports the real destination. The resource (a URL/link) is clearly distinct from lookup_domain, lookup_ip, or lookup_shortcode, though it never explicitly contrasts itself with the nearest sibling lookup_shortcode.

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 framing 'Is this link safe to open?' implies the use case (pre-open safety vetting), and the credit note hints at the cost trade-off of the deep mode. However, there is no explicit when-to-use vs. when-not guidance and no named alternative for cases like 'I only have a domain, not a full URL' (lookup_domain).

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=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-obvious behavioral context the agent cannot get elsewhere: this is a paid call costing 1 credit, which should factor into 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, front-loaded with the question the tool answers, then the cost. Nothing is padded, though the extreme brevity means some essential call guidance is simply absent rather than compressed.

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 shape need not be described. However, for a two-parameter tool with zero schema coverage, the description leaves the agent without address formatting rules or chain-selection guidance, and does not say what happens for wallets absent from the list.

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 0% and the description says nothing about either parameter. The 'chain' enum's seven values (btc, eth, trx, ltc, sol, xmr, dash) and the expected address format are undocumented in the text, so the description fails to compensate for the coverage gap.

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 (wallet) and the specific check performed (membership on Bewary's scam list), which is more precise than the bare name 'lookup_wallet'. It does not explicitly differentiate itself from siblings, but the sibling names cover obviously distinct resources (domain, email, IP), so mis-selection risk is low.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no stated when-to-use or when-not-to-use guidance, no mention of alternatives, and no prerequisites such as address format or supported chains. The interrogative phrasing implies a screening use case but leaves the agent to infer it.

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 and openWorldHint, so the safety profile is covered. The description adds genuinely useful context beyond that — 5 credits per page, API key required, relation strength values, and the caveat that 'a relation is a link, not proof of common ownership' — but says nothing about result ordering or how verdicts are surfaced.

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-loaded with the core question, then the pivot list, then the caveats and cost. Every clause adds information — no filler, no 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?

With an output schema present, return shape need not be explained, and annotations cover read-only behavior. Cost, auth, and interpretation caveats are all supplied; the only real gap is pagination semantics for the page/per_page parameters.

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 0%, so the description carries the burden for all three parameters. It hints that results are paginated ('5 credits a page') but never explains page numbering or the per_page cap of 50, leaving two of three parameters undocumented in both the schema and the 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?

The description opens with a specific verb and resource ('Which other domains share infrastructure or a kit with this one') and enumerates the exact pivots used (IP, /24, ASN, name servers, certificate, registrar, template, tracking id). That level of specificity clearly separates it from lookup_domain, which examines a single domain.

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 states the condition that selects this tool (you want domains linked by shared infrastructure) and an explicit scope exclusion ('CDNs and shared hosting are not pivoted on'). It stops short of naming lookup_domain or another sibling as the alternative when the agent only wants single-domain data.

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 destructiveHint=true and idempotentHint=true. The description usefully adds that only the watch is removed, that events remain readable, and that there is no cost, which informs the agent about side effects beyond the 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 short sentences, front-loaded with the action and its consequence. The telegraphic 'Cost: free' fragment is slightly ambiguous but still earns 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?

Given the existing output schema and annotations covering destructiveness and idempotency, the description covers what is deleted, what survives, and cost. Reversibility/re-creation guidance is the only 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?

There is only one parameter and schema description coverage is 100%, so the schema already explains the wch_ id format. The description adds no parameter-level 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?

States a specific verb and resource ('Delete a watch') plus the resulting state (no more events or charges), which clearly distinguishes it from the sibling 'watch' tool that creates watches.

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 context is clear: use this to stop monitoring; the cost note and the fact events remain readable imply it's a safe cleanup action. It does not explicitly name 'watch' as the way to re-create, so no exclusions are 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 mark this as a non-read-only but non-destructive, idempotent operation; the description adds real value beyond them by disclosing the cost model (1 credit/day, plus 1 per lookalike event for brand watches) and the API key requirement. It also clarifies the idempotent behavior concretely — re-watching mutates the event-type set rather than creating a duplicate. It does not cover failure modes or whether an existing watch's other settings are preserved.

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 dense paragraph that front-loads the core effect ('get events when ... changes') before listing event kinds, then closes with cost and auth. Every clause carries information, though the long semicolon chain of event types is harder to scan than a short structured list would 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?

With an output schema present, the description needn't describe return values, and it does cover the mutation semantics, idempotency, cost, and auth that the annotations alone don't. What's missing is how this relates to list_watches/unwatch for lifecycle management, which matters for a subscription-style tool.

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 67% and the description compensates by enumerating the watchable entity categories (domain, phone, wallet, brand) that map to the type enum, and by explaining that 'watching it again updates the event types', which gives meaning to the optional events array beyond its schema line. It adds no format detail for value beyond what the schema already says (E.164, wallet address, brand id).

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 (get events) and resource (watches on domains, phones, wallets, brands) and enumerates the event categories, so the agent can distinguish it from snapshot tools like lookup_domain. It never explicitly names a sibling or states the contrast, leaving that inference to the reader.

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 conditions are implied rather than stated: cost ('1 credit a day'), 'API key required', and the note that 'watching it again updates the event types' tell the agent about operational constraints. There is no explicit guidance on when to choose watch over lookup_domain/list_events, or how it relates to unwatch.

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