Dragons Eye Ransomware Claims

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description still adds substantial context beyond that: a per-batch read cap of 15 claim records that triggers a 'partial' marker, the unverified-claim caveat, the explicit warning that found=false is not proof of absence, and the payment/error-charging behavior. This is unusually rich disclosure for a read-only tool.

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

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

Front-loads what the tool does before caveats, and every sentence carries distinct information (scope, return shape, batch cap, epistemics, payment). It is dense and slightly cluttered with the pricing/error details, but nothing 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 no output schema, the description compensates by enumerating the return shape (found, claim count, claims with group, dates, sources) and flagging the partial-result case. Combined with the payment and error-charging notes, an agent has everything needed to call and interpret it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single param is documented there, but the description adds real semantics: the 25-domain maximum is restated as an operational constraint, and 'Domains only; use lookup_victim for company names' clarifies the expected value format beyond the schema's 'e.g. acme.com'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Check) and resource (vendor/supplier domains) with an explicit batch limit of 25, plus the purpose (ransomware leak-site claims for third-party-risk reviews). It distinguishes itself from the sibling lookup_victim by declaring domains-only 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?

Names the alternative explicitly ('use lookup_victim for company names') and gives the selecting condition (domain vs. company name). Also frames the intended use case, third-party-risk reviews, so an agent knows when this is the right 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 only cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description goes well beyond them: results are unverified criminal leak-site claims rather than confirmed breaches, found=false is not proof of absence, and it discloses the failure threshold, the $0.50 x402 charge, where payment goes (_meta["x402/payment"]), and that errors/invalid input are not charged. This is exactly the extra behavioral context annotations cannot express.

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 action and scope in the first clause, then each subsequent clause adds distinct, non-redundant information (output fields, alternative tool, data caveat, failure policy, cost/payment). No filler sentences.

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?

Despite having no output schema, the description names the returned fields, clarifies the semantics of a negative result, and covers pricing, payment transport, and error billing. For a one-parameter batch lookup tool, an agent has everything needed to call it correctly and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single parameter already documents the 1-100 range, 200-char limit and examples, so the schema carries the burden. The description restates 'up to 100 vendors (domains or company names)' without adding syntax or format meaning beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Check), resource (vendors: domains or company names), scope (up to 100, ransomware leak-site claims, one call), and enumerates the per-vendor return shape (group, dates, sources, claim count, groups). It also names the sibling it is not (vendor_risk_report), so an agent can distinguish it without opening either 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?

Explicitly routes the agent: raw claims here, but 'use vendor_risk_report for risk levels, a summary and actions.' It also gives the pathological condition (fails if the source is down for more than 25% of vendors) and the cost model, so the agent knows both when to pick it and what to expect when it degrades.

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, closed-world), so the bar is lower. The description adds two genuinely new facts beyond the annotations: the call is free, and the reported contents are cache-scoped to cve_intel and group_intel. It does not describe freshness semantics (e.g. staleness thresholds) or any rate limits.

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 compact sentence with 'Free.' front-loaded, and no filler. It is telegraphic (no verb) but every clause carries information relevant to selecting and interpreting the tool.

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

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

With no parameters and no output schema, the description must carry the return semantics, and it does: freshness plus the cached CVE ids and groups. That is adequate for a trivial, zero-arg coverage probe, though it omits how freshness is expressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline for a 0-param schema is 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 the concrete resource returned: indicator-feed freshness plus the CVE ids and ransomware groups currently cached. It also anchors itself against the cve_intel and group_intel siblings, so an agent can tell it apart from those tools. The verb is only implied ('returns/shows'), which keeps it 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?

'Free.' signals this is the no-cost alternative to paid siblings, and the reference to cve_intel/group_intel implies you consult it to see what those tools currently hold. However, there is no explicit when-to-use, when-not-to-use, or named alternative routing.

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?

Goes well beyond the annotations (readOnly/idempotent/non-destructive) by disclosing billing behavior: $0.50 USDC per call via x402 with the payment placed in _meta["x402/payment"], charge-only-on-full-success semantics, and explicit no-charge conditions for invalid input or upstream failure. This is exactly the cost/auth/error context an agent needs before invoking a paid tool.

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

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

Front-loads the core purpose, then layers billing and error semantics in packed parenthetical clauses with no filler. Slightly dense — the payment/charging sentence carries several distinct behaviors at once — but 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?

With no output schema, the description correctly covers the failure path (error lists ids with no data plus covered ids to retry), the charge rule, and the payment channel. It stops short of describing the success payload shape, though that is partly inferable by reference to cve_intel.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single ids parameter already documents the 1-50 range and CVE pattern. The description restates the 50-item ceiling without adding format or semantics beyond the schema, so 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+resource+scope: "cve_intel for up to 50 CVEs in one call," which immediately distinguishes it from the singular sibling cve_intel and from cve_status/coverage. The batch intent and cardinality bound are explicit in the first clause.

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 conveys when batching applies (up to 50 ids in one call) and what happens when the batch is not fully available, including retry guidance on the returned covered ids. It does not explicitly say when to prefer the single-CVE cve_intel over this tool, so the alternative routing is left 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 cover safety (readOnly/idempotent/openWorld), and the description adds substantial extra context beyond them: x402 pricing and payment location, the queued-not-charged error behavior, the no-charge-on-invalid-input/failure policy, and an explicit AI-generated disclaimer on the attack flow.

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?

Dense but well front-loaded: capability inventory first, then operational caveats (caching, pricing, error handling). Nearly every clause earns its place, though the enumeration is long enough to verge on a feature dump.

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

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

With no output schema, the description responsibly enumerates what comes back, and it covers payment, error, and caching behavior. An agent has everything needed to call it correctly and interpret the result.

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 id parameter, and the description adds no syntax or format detail beyond the schema's pattern and example. Baseline 3 when the schema carries the load.

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 specific verb+resource framing ('Everything an agent needs to prioritize one CVE') and then enumerates the exact payload (CVSS, KEV, EPSS, ATT&CK, D3FEND). It is clearly a per-CVE enrichment tool and is distinguishable from siblings like cve_batch_intel and cve_status.

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?

Explicitly tells the agent to check cve_status (free) first and explains the uncached-CVE case. It does not, however, route the agent to cve_batch_intel for multi-CVE work, which is the obvious alternative for batch use.

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, non-destructive, and closed-world, so the safety profile is fully covered. The description usefully adds the data composition (KEV, EPSS, cache flag) and the cost context, but says nothing about failure modes for unknown CVEs, staleness of EPSS, or rate limits.

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 dense sentence with the cost marker front-loaded and no redundant restatement of the title. It is information-dense but readable; the parenthetical field list is the only mild bulk.

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

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

With no output schema, the description correctly enumerates what comes back (KEV dates, ransomware use, required action, EPSS, cache flag), which is the right burden for this tool. The only gap is behavior when a CVE is absent from KEV/EPSS or when nothing is cached.

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% with a single `id` parameter that carries its own pattern and example, so the schema does the heavy lifting. The description adds no format or semantics beyond what the schema already states, which is the baseline-3 case.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

It names a specific resource (CVE) and the exact payload returned: CISA KEV status fields, EPSS, and a cache flag. The lead word "Free" and the phrase "whether paid cve_intel detail is cached" implicitly differentiate it from the paid cve_intel sibling, though the free-vs-paid relationship is left to be inferred rather than stated as a routing rule.

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 this is the free/no-cost path relative to cve_intel, but never explicitly says when to prefer this tool vs. cve_intel or cve_batch_intel. An agent can infer intent from the pricing marker, but there is no stated trigger or exclusion.

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 only cover the read-only/idempotent/open-world safety profile; the description adds materially more: uncached groups return an error rather than a result and are queued, not charged; the call costs $0.05 USDC via x402 with payment passed in _meta["x402/payment"]; invalid input or upstream failure returns an error and is not charged. These are exactly the operational traits annotations cannot express.

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

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

Front-loads the identity and payload inventory, then handles error and payment behavior in the closing sentences; every sentence earns its place. The long nested content list makes the first sentence dense, but nothing is padding.

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?

There is no output schema, yet the description enumerates what comes back, and the pricing, payment channel, and cache-miss/charge behavior complete the picture. An agent has everything needed to decide, invoke, and interpret the call.

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?

A single 'name' parameter with 100% schema description coverage (including examples 'akira, qilin'), so the schema carries the semantics. The description adds nothing about the parameter, and the baseline of 3 applies when coverage is this high.

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+resource ('Threat-hunting profile of one active ransomware group') and enumerates the exact payload: leak-site listings, momentum status, tools, malware, campaigns, ATT&CK techniques, CVEs, headlines, D3FEND countermeasures. It also explicitly differentiates itself from the sibling group_profile, so an agent can separate the two without opening either 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?

States the use context (threat-hunting profile of a group) and names an alternative with its condition ('Use group_profile for its claim sample'). It does not address when to prefer this over other siblings such as recent_claims or cve_intel, but the primary routing decision is explicit rather than implied.

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), yet the description adds genuinely new operational context: per-call cost ($0.02 USDC via x402), where payment goes (_meta["x402/payment"]), that invalid input and upstream failures are not charged, and that claims are unverified leak-site data rather than confirmed breaches. That provenance caveat and billing model 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?

Four tight sentences, front-loaded with purpose and output contents before secondary details (alternative tool, error semantics, disclaimer, pricing). No filler and no repetition of structured fields.

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

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

With no output schema, the description compensates by describing the returned fields and the sample-vs-full-list distinction, plus error and billing behavior. An agent has everything needed to call this correctly and interpret the result responsibly.

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 ('Ransomware group name or alias, e.g. akira'), so the schema already does the work. The description adds no format, casing, or matching nuances beyond what the schema states, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get a profile of one ransomware group') and enumerates the exact contents returned: aliases, first-observed date, and a sample of newest claims. It explicitly distinguishes itself from the sibling recent_claims, so an agent can route without opening either schema.

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

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

Gives positive guidance ('Use it to understand who a group is') and names the alternative with the condition that selects it ('use recent_claims for a longer list of its latest claims'). Error behavior for unknown groups (error, not charged) is also stated up front.

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 the safe read-only/idempotent profile, and the description adds genuinely non-obvious behavior: a $0.25 USDC charge per call via x402 with the payment payload location (_meta["x402/payment"]), plus the billing rule that invalid input or upstream failure errors out without being charged. Cost and payment-transport details are exactly the kind of context annotations cannot convey.

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 batch scope and sibling relationship come first, then the cost and error/charging semantics. No filler, and the highest-value operational fact (price and payment location) is stated plainly rather than buried.

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

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

With no output schema, the description should ideally hint at what comes back per item (e.g. per-item results vs. a single aggregate), and it only covers failure behavior. Coverage of cost, payment transport, limits and error charging is otherwise solid for a one-parameter read-only batch 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 100% and the single items parameter is fully documented (1-100 strings, maxLength 260), so the baseline is 3. The description restates the same 1-100 constraint and adds only the pricing nuance that the whole batch is one flat charge, which does not extend parameter meaning 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 states the resource (domains or IPv4 addresses) and the batch scope (up to 100 per call), and explicitly positions itself as the batch counterpart to indicator_check. However, it never states what the check actually determines, deferring the core purpose entirely to the sibling tool's description, so it is not self-contained.

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?

"Same as indicator_check for up to 100 domains or IPv4 addresses in one call" clearly signals when to reach for this tool versus the single-item sibling, and the flat-price note gives a reason to batch. It stops short of an explicit when-not rule (e.g. what to do below the item limit or whether indicator_check is preferred for one item).

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?

Goes well beyond the readOnly/openWorld/idempotent annotations by disclosing the hourly cache, that a stale feed errors and is not charged, that invalid input or upstream failure errors without charge, and the exact $0.01 USDC x402 cost with the payment field name. This is the kind of billing and failure semantics an agent needs 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?

Front-loads purpose then layers returns, usage, caveat, and billing; every sentence carries information. It is dense and slightly long, but without an output schema the enumeration of return fields is necessary rather than padding.

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

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

With no output schema, the description correctly enumerates the return shape (listed/not_listed, match type, reason, linked reports/clusters). Combined with cache, error, and payment semantics, an agent has everything needed to call and interpret the result.

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 parameter is fully documented in the schema (100% coverage), so the baseline is 3. The description adds one genuinely new nuance, that parent domains are also checked, but omits the schema's URL acceptance, so it neither compensates nor richly extends the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: checks a domain/parent domain/IPv4 against ThreatCluster's 30-day IOC feed and answers whether it is attacker infrastructure. The scope ('one domain or IPv4', 'high-confidence 30-day feed') cleanly separates it from sibling indicator_batch_check and the cve_*/group_* tools.

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

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

Gives concrete usage contexts ('before opening a link, in email triage or SOC enrichment') and an important interpretive caveat ('Not listed is not proof of safety'). It does not name the batch alternative for multi-indicator workloads, so the single-vs-bulk routing decision is left implicit.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false), and the description adds substantial context beyond them: every result is an unverified criminal claim rather than a confirmed breach, found=false is not proof of absence because only commercially reusable sources are covered, the $0.01 USDC x402 cost with the payment location in _meta, and the fact that invalid input or upstream failure is not charged.

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 purpose, then usage routing, then caveats, then cost/error behavior — a logical order with no filler sentences. The final sentence is dense with three separate facts (price, payment location, non-charging on failure), which slightly taxes readability but each clause is load-bearing.

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

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

With no output schema, the description enumerates what comes back (group, claimed date, first-observed date, country, sector, licensed sources), and it covers payment mechanics and error behavior. An agent has everything needed to invoke and interpret this call.

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 (company name or domain, with examples and length bounds), so the schema already carries the meaning. The description restates 'one company name or domain' but adds no syntax or format detail beyond the schema, which is the baseline-3 case.

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 (search) and resource (ransomware leak-site claims) with an explicit scope limit: one company name or domain. It also names the sibling tools it is not (batch_exposure_check, recent_claims), so an agent can route 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?

Explicitly says when to use this tool (a single vendor or target) and names two alternatives with their selecting conditions (batch_exposure_check for a list of up to 25 domains, recent_claims for the newest claims overall). This is textbook when/when-not/alternatives 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 closed-world, but the description adds genuinely new behavioral facts: zero input, no network request, no payment, and that every result is stamped with an 'unverified claim' label. The provenance/caveat disclosure about results is valuable context the annotations cannot convey.

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 front-loaded with the most decision-relevant fact ('Free.') and then lists return contents in a single dense, waste-free sentence. Every clause earns its place and nothing is redundant.

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

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

With no parameters, no output schema, and annotations covering the safety profile, the description carries the remaining burden well by enumerating what the result contains and the caveat label it carries. An agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so the baseline is 4. The description reinforces this with 'No input', which fully aligns with the empty schema and leaves nothing ambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb ('Return') and enumerates the resources returned: prices of paid tools, payment network (Base), address, licensed data sources, and the 'unverified claim' label. This is far more specific than a tautology. It does not explicitly name or route against any sibling tool, so it stops at 4.

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 conveys the usage context — this is the free, no-cost query requiring no input and no network request — which implies when an agent should reach for it (cost/pricing and source-provenance questions). However, it never names an alternative tool or an explicit when-not condition, so guidance is only implied.

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 the description adds substantial context beyond them: a per-call price ($0.01 USDC via x402), where the payment goes (_meta["x402/payment"]), that failed/invalid calls are not charged, and that results are unverified criminal claims with often-null country/sector. This is unusually rich behavioral disclosure.

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

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

Front-loads purpose and filter scope before routing and cost details; every sentence carries distinct information. It is dense with several clauses in the final sentence, which slightly reduces readability but not substance.

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?

Covers purpose, alternative, data caveats, and billing for a 2-param read-only tool with no output schema. The only gap is that returned fields are not enumerated (country/sector nulls only hinted), which matters somewhat without an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters (group, limit) are already fully documented with examples and ranges in the schema. The description's 'akira or qilin' example and the 1-10 range merely restate schema content, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (list), resource (ransomware leak-site claims), and scope (newest 1-10, optional group filter). It explicitly distinguishes itself from the sibling lookup_victim, so an agent can route without opening either schema.

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

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

Gives the when-to-use case (watch recent activity) and names the alternative tool (lookup_victim) with the condition that selects it (search for a specific company). Nothing is left 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 declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, but the description adds information they do not carry: it is free, requires no payment, and performs no network request. Cost and side-effect profile are exactly the kind of context that matters for a validation step.

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, zero filler. The cost and offline guarantees are front-loaded, and the routing guidance follows immediately.

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

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

No output schema exists, yet the description states the return value in functional terms ('tells you whether it will be searched as a domain or a name'), so the agent knows what it gets back. Combined with the preconditions and cost profile, nothing needed 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?

There is one parameter at 100% schema description coverage, so the schema already documents the input, its max length, and examples. The description adds no syntax or format detail beyond what the schema provides, 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?

States a specific verb pair (check and normalize) applied to a specific resource (company name or domain), and explicitly routes relative to the sibling lookup_victim. An agent can tell what this does and how it differs from the lookup family without opening the schema.

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

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

Gives a clear precondition: call this before lookup_victim, and it tells you whether the input will be searched as a domain or a name. No explicit when-not-to-use case or competing alternative is named, so it falls just short of the top band.

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 cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds substantive context the annotations cannot: every result is an unverified leak-site claim, none_found is not proof of absence, the call fails uncharged if the source is down for >25% of vendors, and pricing is $3 USDC via x402 in _meta. That is unusually rich behavioral disclosure.

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 purpose and output shape, then caveats and billing; nearly every sentence carries operational weight (risk-level thresholds, error/refund policy, payment channel). Slight redundancy where 'Read-only' echoes readOnlyHint and the risk-level enumeration is dense, but nothing is truly 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?

No output schema exists, so the description carries the return-value burden and does so fully: it enumerates claim fields, all five risk levels with their 90-day/12-month semantics, follow-up actions, and the portfolio summary. Payment mechanics, failure semantics and the unverified-claim caveat are all covered.

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% with a single parameter, so the schema already documents the vendor array, its 1-100 bounds and the domain-or-name format. The description only restates the 100-vendor cap, adding no format or syntax detail beyond the schema. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Build a third-party ransomware risk report'), its scope (up to 100 vendors as domains or company names) and its exact output contents (claims, risk levels, follow-up actions, portfolio summary). An agent can distinguish it from batch_exposure_check without opening either 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?

Explicitly targets vendor reviews and audits, and names the alternative ('use batch_exposure_check for a cheaper raw check of up to 25 domains') with the tradeoff that selects it. Both when-to-use and the sibling route are spelled out.

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, closed-world, so the description's extra value is the auth requirement (secret from creation) and the cost note 'Free.' It doesn't cover failure modes such as an invalid/expired secret, but it is well above the annotation baseline.

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, cost and resource front-loaded, followed immediately by the prerequisite. Nothing extraneous.

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

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

No output schema exists, and the description compensates by listing the returned fields, plus the secret prerequisite. Missing only edge-case behavior (invalid secret, expired watch), which is minor for a two-parameter read 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 100%, so the baseline is 3; the description adds provenance meaning — the webhook_secret is the value returned once at creation and is needed for authorization, not just an opaque string.

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 (status of a paid vendor watch) and enumerates exactly what is reported: items, expiry, last check, last webhook delivery. No sibling tool covers watches, so it is trivially distinguishable from the cve/indicator/vendor_risk 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?

Explains the context of use — a watch created via HTTP POST /v1/watch — and flags the prerequisite that the webhook_secret returned at creation is required. It stops short of naming alternatives or when-not-to-call conditions, but no sibling duplicates this function.

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