FactStamp

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

Beyond the readOnly/idempotent annotations, it discloses cost (US$0.20 per batch, with the alternative rail's per-claim pricing and floor), that every verdict carries the register's own date and a citation, that the batch yields ONE receipt, and that the Ed25519 receipt is verifiable offline against a named well-known key. Those are exactly the traits an agent can't get from annotations: price, evidentiary output and auditability.

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 verb and resource are front-loaded in sentence one, and the verdict taxonomy follows immediately. It is a single dense paragraph with some redundancy around pricing/rails and receipt signing, but nearly every clause carries actionable information rather than 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?

There is no output schema, so the description carries the return burden and does: per-claim verdicts, accompanying register dates, citations, and one signed receipt with offline verification. Combined with annotations covering safety and the fully documented single parameter, an agent has everything needed to call it 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 coverage is 100% and the enum already lists the vocabulary, so the baseline is 3; the description adds real meaning by explaining that field is closed-vocabulary and that an off-list field is answered not_checkable naming the list, and by describing subject as identifier, name or both. Much of this restates schema text, which keeps it from a 5.

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 opens with a specific verb+resource ('Audit what an agent believes about companies') and then defines the exact output taxonomy (supported / contradicted / stale / not_checkable) plus batch size, so the tool's function is unambiguous. It never names a sibling such as check_entity or route_claim, so an agent must infer why it would pick this over a single-entity lookup.

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

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

It gives a concrete boundary condition – up to 10 claims on this rail, longer audits go to POST /audit with its pricing – which is real routing guidance. It also states the consequence for out-of-vocabulary fields (not_checkable, not a guess). What's missing is explicit guidance on when to use this versus the sibling check/route/verify tools for a single belief.

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?

With readOnlyHint=false and openWorldHint=true already declared, the description adds genuinely new context: no charge is made, no artefact is produced internally, a human completes the payment on the card rail, and downstream work only fires once Stripe records the session as paid. This resolves the apparent tension between 'opens a session' and 'charges nothing'. It stops short of stating that each call creates a new non-idempotent session.

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

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

Four short sentences, purpose front-loaded, no repetition. The phrasing 'the thing that taps is a human' is rhetorical but does encode the meaningful fact that no automated charge occurs, so it earns its place, if narrowly.

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

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

For a single-parameter tool with no output schema, the description covers what is returned (payment link, session id), what is not done (no charge, no artefact), and the external dependency (Stripe's paid record gates the redeem path). Only the non-idempotency of repeated calls is left to annotations.

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

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

Only one parameter, and schema coverage is 100%, with the sku description already pointing to list_card_packages as the source and giving an example. The tool description adds nothing about sku format or lookup, so the schema carries the load and baseline 3 applies.

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

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

The first sentence gives a specific verb and resource: 'Opens a Stripe Checkout Session for one card package and returns its payment link and its session id.' An agent immediately knows this is a payment-link generator, not a package executor. It does not name a sibling tool for contrast, which keeps it out of 5 territory.

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?

'This tool charges nothing and produces no artefact' plus 'The package's work runs only at its redeem path' implicitly tells the agent when not to expect results here, but no alternative tool (e.g. a redeem/verify sibling) is named and no precondition such as 'call list_card_packages first' appears in the description. Usage is inferable but not explicit.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description adds substantial non-annotated behavior: mechanical reproducible extraction, no inference, pricing and claim cap, preview-before-charge behavior for the pack door, and an offline-auditable Ed25519-signed receipt. No contradiction with 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?

Front-loads the core operation with "A whole document in one call" and then groups pricing, alternatives, and receipt details. It is dense and repeats the receipt concept somewhat, but most detail is justified by pricing, auditability, and routing complexity.

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?

Without an output schema, the description still explains the return shape enough: per-claim answers from owning doors with signed receipts plus one document-level receipt. It also covers cost, alternatives, and offline verification, which is complete for a one-parameter verification 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 `document` parameter is already well documented. The description adds that this door expects PROSE rather than a bare list, which helps content selection, though that point also overlaps with usage guidance.

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 whole document for verifiable claims and returns per-claim and document receipts. It explicitly distinguishes itself from verify_bulk and single-claim siblings like check_figure, check_entity, verify_citation, and verify_package.

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 explicit when-to-use guidance: prose documents up to 5 claims for US$0.25, with a pack-funded HTTP door for better-funded or uncertain cases. It also names alternatives for bare lists and single claims, so the agent can route correctly.

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 safety (readOnlyHint, idempotentHint, openWorldHint), but the description adds substantial context beyond them: the underlying sources (GLEIF LEI index, US SEC EDGAR), the four-way verdict vocabulary, the conservative near-match behavior ('a near name match is never reported as a match'), and an Ed25519-signed receipt verifiable offline against a published key. That is exactly the kind of audit/trust behavior an agent cannot get from the annotation block.

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 constraints, then the receipt mechanism — a sensible ordering with no filler sentences. The receipt sentence is long and appends audit detail rather than selection-relevant guidance, so it is dense but not wasteful.

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

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

With no output schema, the description carries the return-value burden and does so (four verdict values plus near-match caveat), and it names the sources and the verification artifact. It omits operational facts such as rate limits, cost, or authentication needs, but for a read-only lookup tool this is close to 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?

Schema description coverage is 100%, so the baseline is 3. The description references 'under which identifier and jurisdiction' and the notion that an identifier resolves exactly, mirroring the schema (which already documents name/LEI/CIK and jurisdiction examples), but adds no new syntax or format detail beyond what the schema provides.

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

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

States a specific verb and resource ('Verify a legal entity') and immediately unpacks the scope into three concrete sub-questions: existence, identifier/jurisdiction, and registration currency. Scope exclusions ('not advice, not a credit check, not a sanction screen') further sharpen what the tool is, letting an agent separate it from check_figure and verify_citation without opening a 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?

The description gives clear when-not guidance ('not advice, not a credit check, not a sanction screen') and states the output space (found/ambiguous/not_found/unknown), which frames when the tool applies. It stops short of naming a sibling tool as the alternative for the excluded cases, so routing among the other verification tools 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 context beyond them: price and settlement currency, the coverage block naming registers NOT consulted, the never-guess policy for unread registers, the four possible verdicts, and an offline-verifiable Ed25519 receipt with a published key URL. This is exactly the kind of operational detail 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?

The core claim is front-loaded, but the single enormous sentence with stacked em-dashes is hard to parse and carries marketing padding ('the whole picture', 'never guessed'). Pricing and audit-receipt details earn their place; the rhetorical framing does not.

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, so the description carries the return-value burden, and it does: verdict states, the coverage block, and the signed receipt. Combined with annotations covering the read-only/idempotent profile, an agent has everything needed to call and interpret this correctly.

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

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

Schema coverage is 100%, and the schema already documents both 'query' (company number, legal name, LEI or CIK) and 'jurisdiction' with examples. The description adds little parameter-level detail, notably nothing about how jurisdiction breaks ties, so the baseline 3 applies.

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

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

The description names a concrete deliverable: a single paid answer consolidating identity/standing, registered office, SIC activity, previous names, filing position, sanctions screening and ownership for one company. That clearly separates it from narrower siblings like check_sanctions or check_figure. It never names an actual sibling tool, though, so the differentiation is inferred from the field list rather than stated.

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

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

It gives a usable when-to-use context: 'at the point of signing, onboarding, paying or acquiring a counterparty,' and an explicit exclusion, 'Not advice, not a credit check.' What is missing is routing guidance to sibling alternatives (e.g. when to use check_entity or check_sanctions instead of paying for the full file).

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 read-only/idempotent/open-world, but the description adds substantial context beyond them: one live read of Corporations Canada, six sections with a coverage block, an Ed25519-signed receipt verifiable offline at a published key, found/not_found/unknown verdicts with unknown explicitly free, and explicit non-goals (not advice, credit check or KYB).

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?

Purpose is front-loaded, but the body is two very long run-on sentences that bundle output fields, limitations, verdict semantics, pricing and signing into a dense block. Nearly every clause carries information, yet the wall-of-text form makes it harder to scan than it needs to 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 no output schema, the description carries return-value burden and does so: it enumerates the six sections, the found/not_found/unknown verdict space, the receipt/coverage artifacts, and the exclusions. An agent has everything needed to call it correctly and interpret results.

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% on the single query parameter, so baseline is 3, but the description adds real meaning: the value must be a nine-digit BN and why a company name cannot substitute for it. That clarifies the accepted input format and the constraint behind it beyond the schema's own wording.

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: Canadian company lookup / federal corporation register check, keyed by nine-digit Business Number. It also names what it is not (provincial/territorial registers, director/officer names), which lets an agent separate it from the generic check_entity_file siblings without opening a 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 clear selection conditions: BN only, name alone cannot reach the endpoint, and provincial/territorial corporations live in a different register this file does not read. It stops short of naming the specific sibling to use instead (e.g. check_entity_file_il or a provincial source), so it is context-rich but not fully routed.

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?

Well beyond the readOnly/idempotent/openWorld annotations, it discloses the live data source (Registrar of Companies dataset on data.gov.il), staleness behavior (amended returns and late registrations may not appear), the verdict set including 'unknown is a first-class answer and is not charged,' and the Ed25519-signed receipt checkable offline against /.well-known/factstamp-issuer.json. These are exactly the behavioral traits an agent needs and none are in the structured fields.

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

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

The core purpose is front-loaded in the opening clause and the subsequent sentences each carry material information (data source, exclusions, verdicts, receipt). It is dense and sprawling on the first sentence but still earns most of its length 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 fully compensates by describing the seven returned sections, the receipt and coverage block, and the four possible verdicts. An agent has everything needed to call it 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 coverage is 100% and there is a single parameter, so the schema already documents the accepted formats. The description restates the same number/name semantics without adding new syntax or format detail, 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+resource ('Israeli company lookup and company register check') with explicit lookup keys (nine-digit company number with check digit, or registered name in Hebrew/English) and enumerates exactly which fields come back. The Israel scope distinguishes it from check_entity_file_ca and the other entity siblings without needing their schemas.

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?

Frames the tool's boundaries clearly: it is 'not advice, not a credit check and not a KYB service,' and it declares its non-coverage (officers/directors/shareholders, financial statements) and freshness caveat. It stops short of naming a sibling alternative or a when-not-to-use-this-tool routing rule, so it is context-rich but not fully explicit about alternatives.

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), and the description adds substantially beyond them: the exact verdict vocabulary returned, that results are cited with an as-of date, and that an Ed25519-signed receipt covering question/verdict/sources/time is verifiable offline against a published key. That is real, auditable behavioral 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?

The core action and return values are front-loaded in the first two sentences, which earns its place. The receipt sentence is long and slightly promotional, and 'Not advice' is a thin fragment, but overall the text is reasonably tight for the amount of information conveyed.

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

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

With no output schema, the description carries the burden of describing returns and does so by naming all four verdicts and the citation/as-of-date framing. It also covers auditability and where the signing key lives, so an agent has what it needs to call and interpret the 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 both parameters and the routing role of series_id are already fully documented in the schema. The description implies the claim must be a dated figure and enumerates return verdicts, but adds no syntax or usage detail for the parameters themselves, so it lands at the baseline.

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

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

The description states a specific action (submit a dated figure claim for verification) and its outcome (a verdict of verified/stale/contradicted/unknown cited to the publisher's own series). It is clear on its own, but it never names or distinguishes itself from siblings like check_document, check_entity, or verify_citation, so an agent must infer the boundary from the name alone.

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

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

'Relevant wherever a number is going onto a page, deck or decision' gives concrete when-to-use context, and the schema notes series_id bypasses the router when routing was ambiguous. However, there is no explicit when-not guidance or routing to any named alternative among the check_*/verify_* siblings.

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 flag readOnly/openWorld/idempotent, and the description goes well beyond them: it discloses verdict semantics ('listed', 'mismatch', 'not_found', 'unknown'), the rule that near names are never conflated, that unconsulted lists are named as such, that a listed verdict stands regardless of missing lists, and that an Ed25519-signed, offline-verifiable receipt is produced. This is unusually rich operational 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?

The verdict and source lists are front-loaded, and every statement is substantive. However, it is delivered as a few very long em-dash-chained sentences, and the receipt sentence could be tightened, so it is dense rather than wasteful.

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, so the description carries the burden of explaining returns and does so fully: the verdict vocabulary, the per-list consulted status with retrieval and report dates, and the signed receipt/audit path. An agent knows what it will get back.

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

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

Schema description coverage is 100%, so the schema already documents name, kind and country with their own semantics. The description reinforces the person/entity distinction ('a near name is never reported as the same party') but adds no syntax, format or default details 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?

The description states a specific verb and resource ('Sanctions screening of a name'), enumerates the exact lists read (OFAC SDN, UN consolidated, EU FSF, UK Sanctions List) and the four possible verdicts. An agent can distinguish this from siblings like check_entity or check_vat without opening a schema.

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

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

Usage is implied by the purpose — screen a person or company name for sanctions exposure — but the description never says when to prefer this over check_entity, check_document or check_figure, nor states any prerequisites or exclusions. The 'not advice, not a legal determination' caveat is a disclaimer, not routing 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?

Adds substantial behavior beyond the readOnly/openWorld/idempotent annotations: keyless access to the official VIES service, that an outage is NEVER reported as invalid, that some member states disclose nothing and the response says so rather than returning an empty string, and the Ed25519-signed receipt auditable offline against a published key. These are exactly the failure-mode and trust details an agent cannot infer from structure.

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 purpose in the first clause, then layered with behavior, scope, and the receipt mechanism. Most sentences earn their place, though the receipt sentence is long and somewhat elaborate relative to a two-parameter read 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?

There is no output schema, so the description carries the return-value burden and does so explicitly: valid, invalid, or unknown, plus member state, register request date, and trader identity where disclosed. Nothing needed to call or interpret the result is missing.

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

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

Schema description coverage is 100%, so both parameters (vat_number, country_code) are already documented with format and examples, including the GB exclusion and XI inclusion. The description reinforces the country scope but adds no syntax or format detail 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 and resource ('An EU VAT number check — VAT validity, and the VAT registration behind it') and names the upstream source (VIES). An agent can immediately distinguish this from check_entity, check_sanctions, or check_document 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?

Gives clear scope boundaries and exclusions: GB is out of scope post-Brexit while XI is covered, and it explicitly disclaims 'not tax advice, not a credit check'. That narrows usage well, but it never names the sibling tools an agent should prefer for adjacent tasks (e.g. entity or sanctions checks), so the routing guidance is implicit rather than explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that — prices are in AUD, there are exactly 11 products priced across 13 SKUs, and nothing is metered or subscribed — but the phrasing is metaphorical enough that details like currency semantics and result stability are only loosely communicated.

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 the core content (11 products, 13 AUD prices) lands early, but 'Included.' is a wasted opening fragment and 'The per-call doors stay open beside them' is decorative rather than informative. Every sentence should earn its place; here two sentences are mostly mood.

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-parameter listing tool with no output schema, the description does sketch the record shape (products, prices, unit per payment, package return, input destination) and states the pricing model. What is missing is any note on whether the catalogue is static or live-fetched, but an agent can call this correctly from what is given.

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. It does describe what the catalogue entries contain ('the unit one payment buys for each SKU, what the package returns, and where the input is sent'), which maps to the returned fields rather than inputs.

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 conveys that this surfaces 'the one-off card packages as one machine-readable catalogue' with 11 products and 13 AUD prices, which is a recognizable resource. But it never uses a clear verb like 'list' or 'returns', opens with the opaque fragment 'Included.', and does not name the sibling buy_card_package, so the agent must infer that this is the read-side counterpart to purchasing.

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 per-call doors stay open beside them' gestures at alternatives (per-call tools vs. packages) but never states when to call this listing versus when to call buy_card_package or the per-call checkers. There is no explicit when-to-use or when-not-to-use guidance, only atmospheric hints.

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, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds vague phrases like 'no-guess rule' and 'as-of date' but does not explain them, nor does it describe response shape or any other behavioral detail 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?

It is short, but the opening word 'Included.' is a fragment that does not earn its place and makes the definition harder to parse. The description is not front-loaded with a clear action.

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 and no parameters, the description should clearly explain what the tool returns. It hints at coverage, publisher, and as-of date metadata, but leaves the return format and the meaning of 'no-guess rule' unexplained.

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 has zero parameters, so the baseline is 4. There are no parameter semantics for the description to clarify.

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 that largely restates the title 'List what this engine covers' rather than stating a clear action and resource. It mentions publisher and as-of date metadata for each series, but never explicitly says it lists series or what an agent should expect.

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, when not to use it, or which sibling tools to choose instead. The agent must infer its role from the name and title alone.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered; the description adds the important non-obvious traits: it is free/included, it produces no verdict, and it discloses the extracted value/date and score signals. It stops short of describing error behavior for unrouteable claims or output shape specifics, 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?

Two tightly written sentences with zero filler, and the no-verdict boundary is front-loaded via the leading 'Included' cost note. The opening word 'Included' is slightly opaque in isolation but earns its place by encoding the billing model up front.

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

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

For a one-parameter, read-only, non-verdict tool with no output schema, the description covers return contents, cost, and the sibling boundary well. Minor omissions are what happens on an unroutable claim and any pagination/format details, but nothing critical to correct invocation 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 a single parameter with 100% schema description coverage, so the schema already documents 'claim' as the assertion to route. The description adds nothing about the claim string (e.g. expected format, length limits, how ambiguity is handled), 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 and resource (routes a claim to a series) and enumerates what the response contains: target series, extracted value/date, and scoring signals. It also explicitly separates itself from check_figure by declaring it returns no verdict, so an agent can pick between 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?

Names the alternative (check_figure) and the exact condition that selects it ('when you want one' — a verdict), plus a cost signal ('pay for') that guides usage under a paid tier. This is explicit routing guidance rather than implied usage.

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), and the description adds substantial context on top: flat pricing, the 12-item cap on this door, the 25-item HTTP door, the guarantee that every item is answered by the same door as a single call (consistency), and an auditable Ed25519-signed receipt checkable offline. That is exactly the extra behavioral detail 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?

It is a single dense paragraph but front-loads purpose and forms before pricing and receipt details, and every sentence carries information (forms, limits, pricing, sibling routing, receipt). The pricing and door-detail sentences are the heaviest, but they justify their place for a paid 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?

There is no output schema, so the description carries that burden; it does describe what comes back (verdicts plus an Ed25519-signed receipt covering question, verdict, sources and time) and how to verify it. Adequate for the tool's complexity, though a fuller picture of the per-item verdict shape would make it airtight.

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 goes slightly beyond by explaining the two forms as a semantic choice ('items[] of {tool, input} or the citations[]/packages[] shorthand') and by reinforcing the item limit, giving the agent a reason to pick one form over the other.

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

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

The opening clause gives a specific verb and resource ('Check a whole list in one call: a bibliography or a dependency manifest') and immediately names the alternatives it is not ('to check the claims inside a document, use check_document, and to check one reference use verify_citation or verify_package'). An agent can distinguish it from every sibling without opening a 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?

It states explicitly when to reach for this tool (a whole list / manifest in one call) and routes to the correct siblings for the two adjacent cases (prose claims → check_document, single reference → verify_citation/verify_package). Exclusions and alternatives are both spelled out, leaving nothing 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 only cover readOnly/openWorld/idempotent; the description goes well beyond them, disclosing the data sources (Crossref, arXiv), the exact verdict semantics (mismatch never reported as verified, near title match never verified, absent title -> not_found, one-year tolerance), and a signed offline-checkable receipt with the issuer key URL. That is unusually rich behavioural context 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?

Purpose and required input are front-loaded in the first two sentences, and the longer clauses on comparison semantics and the signed receipt each carry useful information rather than filler. It is dense and somewhat run-on, but nothing is clearly expendable.

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 does the work of sketching the return payload (existence, title, authors, year, container, retraction/citation status) and the possible verdicts, which is what an agent needs to interpret results. Minor gaps remain around error/limited-coverage cases, but the picture is essentially complete for a 5-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 description coverage is 100%, so the baseline is 3, but the description adds genuine meaning about how the parameters interact: the claimed_* fields are all optional and each is compared one-by-one against the record, with disagreements surfaced as mismatch rather than a pass. It still doesn't restate format constraints like maxLength or the surname-comparison rule beyond what the schema says.

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

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

The description states a specific verb and resource — checking whether a citation's metadata exists, is correct, and has been retracted — and names concrete inputs (DOI, arXiv ID, title). It does not explicitly differentiate itself from near-neighbours like check_document, check_entity or verify_bulk, but the citation/DOI scope is unambiguous enough to route correctly.

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 implies usage by describing the two modes of the tool (bare lookup vs. comparison against claimed fields) and the meaning of verdicts, but never says when to choose this over verify_bulk, check_document or verify_package, nor any when-not condition. The agent must infer the boundary from the resource type alone.

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

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

Annotations cover only readOnly/idempotent/openWorld; the description adds substantial behavior beyond them: the not_found path returns nearest real versions, invented names return lookalike published names, and the Ed25519-signed receipt is offline-verifiable against a published key URL. This is exactly the safety-and-output context annotations cannot carry.

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

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

Front-loaded with the core action and return contract in the first two sentences, which is the right ordering. It runs long with rhetorical asides ('which is the point, because that is how slopsquatting gets installed', 'by someone who was not here') that add flavor but cost tokens.

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 and a simple two-parameter surface, the description carries the full burden and does so: it explains verdicts, the not_found/lookalike edge cases, and the signed receipt. An agent can call this correctly and interpret the result without further documentation.

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

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

Schema description coverage is 100%, so both parameters are already documented, including the 'express@4.18.2' syntax and the ecosystem enum with its npm default. The description only restates 'package and version plus its ecosystem', adding no syntax or format detail 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 and resource ('Reports on a dependency', submit a package/version/ecosystem) and enumerates exactly what the response contains: existence, yanked/deprecated status, and OSV advisories. The 'not a security audit' scope note further sharpens what it is against what an agent might assume.

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 usage context ('at the point of installation') and an explicit exclusion ('Not a security audit'), which steers the agent away from a plausible wrong expectation. It does not, however, name a sibling alternative (e.g. verify_bulk) for batch or other verification needs, so routing is implied rather than stated.

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

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

Annotations cover the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false), and the description adds substantial context: first check answered immediately, re-checked daily for 30 days, changes recorded as signed receipts, webhook POSTs, and a read token shown only once. It does not state rate limits or how to stop a watch, which are the notable remaining gaps.

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 well-ordered (what it does, mechanics, alternatives, signing). The final sentence on Ed25519 receipts and the well-known key URL is dense and could be trimmed, but every sentence carries actionable content.

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

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

With no output schema, the description still covers returns (read URL, one-time token) and side effects (daily re-checks, webhook POSTs, signed receipts). Nothing an agent needs to invoke the tool correctly appears to be missing.

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

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

Schema coverage is 100%, and the description still adds value by giving concrete subject examples (DOI, arXiv ID, title, 'npm:express@4.18.2') and by explaining that the optional https webhook receives each recorded change as JSON — behavior the schema field only hints at.

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

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

The opening sentence states a specific verb and resource with scope: 'Watch ONE citation or ONE package version instead of checking it once.' It immediately distinguishes itself from verify_citation/verify_package (one-off checks) and watch_portfolio (lists), 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?

Explicit when-to-use and alternatives are named: 'For a whole list of references under one purchase use watch_portfolio; for a one-off answer that does not need watching, use verify_citation or verify_package.' Both the sibling and the selecting condition are given.

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 flag readOnlyHint=false, openWorldHint=true and idempotentHint=false; the description goes far beyond by disclosing cost ($5/portfolio, per-reference and per-check pricing), purchase semantics ('ONE purchase covers the whole list'), the once-only token, immediate signed first check, daily re-check cadence, and that each change yields a signed receipt while no changes yield no message.

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 purpose and scope, then pricing, then return/receipt details in a logical order. It is dense but nearly every sentence carries new information; the pricing triple ('US$5 a portfolio — 20 cents a reference, under a cent a check') is slightly redundant.

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

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

With no output schema, the description compensates by stating what is returned (a read URL and a token shown only once) and what audit artifact accompanies checks (an Ed25519-signed receipt verifiable against a published key). For a paid, non-idempotent watch tool this is close to complete, though it could note anything about token expiry or renewal.

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

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

Schema coverage is 100% and both parameters (items, webhook) are already documented, so the baseline is 3. The description adds useful semantics the schema lacks: that a repeated reference is charged once and that webhook posts only fire on recorded changes, plus the 25-item ceiling in prose.

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 with scope: 'Watch a whole list instead of one reference at a time: up to 25 citations or package versions re-checked every day for 30 days under one token.' It also explicitly distinguishes itself from the sibling watch_add, 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?

Names the alternative and the selecting condition: 'ONE purchase covers the whole list: for a single subject on its own, use watch_add.' The 'whole list vs single reference' split is the exact decision the agent needs to make among these siblings.

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