FactStamp

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

Goes well beyond the annotations by resolving the counter-intuitive semantics of a 'buy' tool: it charges nothing, produces no artefact, a human completes payment, and the package's work only runs at the redeem path after Stripe records payment. That is exactly the non-obvious behavioral context an agent needs, and nothing contradicts the readOnlyHint=false/openWorldHint=true flags.

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 surprising constraint with a one-word 'Free.' and stays to four sentences. Slightly literary phrasing ('the thing that taps is a human') costs a little density but each sentence carries real information.

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

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

With no output schema, the description still names the return values (payment link and session id), and annotations cover the read/write and open-world profile. Nothing material for 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?

Schema description coverage is 100% and the single sku parameter is fully documented in the schema, including its format and an example. The description adds no parameter-level detail, so the baseline 3 applies.

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

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

States a specific verb and resource: opens a Stripe Checkout Session for one card package, and names what it returns (payment link, session id). It is distinguishable from list_card_packages and verify_package, though it never explicitly contrasts itself with those siblings.

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

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

Usage is implied (call it to obtain a payment link for a package that list_card_packages published), and the redeem-path sentence hints at lifecycle, but there is no explicit when-to-use / when-not-to-use statement or named alternative for validating or listing packages.

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

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

Annotations already declare readOnly/idempotent/openWorld, but the description adds substantial context beyond them: flat pricing (US$0.25 for the first 5 claims, 5 cents per claim), a reproducible/mechanical extraction guarantee ('nothing is inferred'), and an Ed25519-signed, offline-auditable receipt with the published key URL. These are material behaviors an agent could not infer from 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?

Front-loaded with the core capability, then pricing, then alternatives, then receipt auditability — a sensible order. The prose is flowery and dense ('the door that owns it', 'a better-funded document'), but nearly every clause carries routing, pricing, or audit 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?

With no output schema, the description fully covers the return shape (per-claim receipts plus one document receipt), the input constraint (prose), cost, and determinism. Combined with annotations that already cover safety, an agent has everything needed to invoke 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?

Only one parameter and the schema already documents it at 100% coverage (baseline 3). The description adds input-type meaning by stating 'This door reads PROSE,' effectively constraining what the document argument should contain, which is more than the schema states.

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

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

States a specific verb and resource — checking a whole document — and immediately characterizes the output as verifiable claims answered with signed receipts plus a document-level receipt. It explicitly distinguishes itself from siblings (verify_bulk, check_figure, check_entity, verify_citation, verify_package), 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?

Gives explicit when-to-use and when-not-to-use guidance: prose documents go here, bare reference/package lists go to verify_bulk, and single claims go to the specific check_* tools. It even routes uncertain callers to the free-preview HTTP door first. Alternatives and their selecting conditions are named.

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 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, idempotentHint, and openWorldHint=false, covering the safety profile. The description adds genuine non-annotation context: the tool is free, packages are one-off, and nothing is metered or subscribed. It does not describe freshness, pagination, or any failure behavior, so it adds some but not rich value.

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 useful fact ('Free') and the catalogue contents are enumerated efficiently. However, the closing sentence ('The per-call doors stay open beside them') is vague, decorative prose that costs space without adding actionable meaning.

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

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

With no output schema, the description carries the burden of explaining returns and does so reasonably: 11 products, 13 prices in AUD, the per-SKU payment unit, package output, and input destination. It is complete enough for an agent to know what it will get, though the enumeration is impressionistic rather than exact.

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, which is the baseline-4 case. Nothing in the schema needs compensating for, and the description correctly implies no input is required.

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

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

The description identifies a specific resource (the one-off card packages) and characterizes the output as a machine-readable catalogue of products, prices, SKUs, returns, and input destination. It implicitly contrasts with the per-call alternative ('The per-call doors stay open beside them'), which helps distinguish it from buy_card_package, though it never names the sibling directly.

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

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

Usage is only implied: the word 'catalogue' and 'Free' suggest a discovery step, and the note about per-call doors hints that other paths exist. There is no explicit 'use this before buying a package' instruction or named alternative, so the agent must infer when to reach for this tool over buy_card_package.

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 'Free' as cost context and references an opaque 'no-guess rule,' which is some extra behavioral information but remains unexplained and limited.

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 very short, but it is poorly structured: it opens with 'Free.' and then presents a fragment rather than a front-loaded action. The phrase 'no-guess rule' is undefined, so not every element clearly earns its place.

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

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

For a zero-parameter list tool with annotations covering safety and no output schema, the description should at least clarify return shape and when to call it. It names some returned fields (publisher, as-of date) but leaves the no-guess rule and sibling usage 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 and schema description coverage is 100%. Per the rubric, the baseline for no parameters is 4; there is no parameter semantics for the description to add.

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 noun phrase listing return contents rather than a clear action; it largely restates the title 'List what this engine covers' without explicitly saying it lists series. An agent can infer from the tool name, but sibling differentiation is absent and the purpose remains vague.

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

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

No guidance is given on when to use this tool versus check_entity, check_figure, or route_claim. The only contextual clue is 'Free,' which describes cost, not usage conditions.

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), so the bar is lower. The description still adds meaningful context beyond them: the cost model ('Free', 'pay for check_figure') and the explicit non-outcome ('Returns NO verdict'), which prevents the agent from misusing the result as a judgment.

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

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

Two sentences; the pricing note is front-loaded as a one-word hook, followed by the output contract and the explicit exclusion. No sentence is wasted and the ordering prioritizes what the agent needs first.

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

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

With no output schema, the description must carry the return contract, and it does: series, extracted value, date, and signals. It does not cover failure modes or input limits (4000 chars, min 4), but for a single-parameter read-only tool the picture is nearly complete.

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

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

Only one parameter, and schema description coverage is 100%, so the schema already documents 'claim' fully. The description adds nothing about the claim's syntax or constraints, 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 (route) and resource (claim) plus the concrete output: target series, extracted value and date, and scoring signals. It also explicitly distinguishes itself from the sibling check_figure by declaring it returns no verdict.

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 vs alternative: this tool is free and returns no verdict, so the agent is told to call check_figure when a verdict is actually needed. The selection condition is stated outright 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), 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.