VerifyDesk

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

No annotations exist, so the description carries the full burden and it does volunteer one genuinely useful trait: the call 'Costs 1 credit'. It says nothing about authentication, failure modes for an unknown registration number, or result freshness/caching, which matters for a paid registry lookup.

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 return payload, then the two required inputs, then the cost in one short clause. Every sentence carries information and nothing is repeated from the title.

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

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

With no output schema, the description correctly enumerates the returned fields and flags the optional headcount, so an agent knows what to expect. It is complete enough for a two-parameter read tool, with the only gap being error behavior on non-matching registration numbers.

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 both parameters are documented in the schema, including the FR/GB enum values and the SIREN vs company-number distinction. The description restates these mappings without adding format, validation, or lookup hints beyond the schema, 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 ('Returns extended registry data for one company') and enumerates the payload (officers/directors in office, legal form, activity, address, headcount range). It never names or contrasts with the sibling verify_company, so an agent must infer why it would use this enrichment call rather than the plain verification one.

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 input contract ('country (FR or GB) and the exact registration number'), which tells the agent the prerequisite keys but not when this tool beats verify_company or screen_sanctions. No when-not-to-use or alternative routing is 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?

With no annotations, the description carries the full burden and does well: it discloses the cost profile ('Free to call') and the data window ('last 30 days'), which are genuine behavioral facts beyond the schema. It does not mention auth requirements or rate limits, so it falls short of 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 tight sentences with the contents front-loaded and the cost note appended. Every clause earns its place; nothing is repeated from the schema or title.

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

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

There is no output schema, so the description must hint at the return shape, and it does by naming the three returned fields and their window. No annotations exist either, and the 'free to call' note covers the main behavioral concern. Minor gap: no mention of formatting or staleness.

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. The description adds no parameter semantics because none exist, and needs none.

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 (get) and resource (usage) and enumerates exactly what is returned: plan, remaining credit balance, and call volume over the last 30 days. It is clearly distinguishable from the invoice-oriented siblings (extract_invoice, generate_invoice, validate_invoice, describe_coverage).

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 explicit when-to-use or when-not-to-use guidance and no named alternatives, but for a zero-parameter, cost-free read tool the implied usage ('check your balance/usage') is reasonably self-evident. It provides no routing 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?

With no annotations, the description carries the full burden and does so: matching normalization rules (case, accents, punctuation, word order, legal forms), fuzzy tolerance (one typo in 4+ letter words, transliterations), score range and type, the 10-party cap, list-availability reporting, Latin-script-only limits, the exclusion of DOB/nationality/address comparison, and a 1-credit cost. This is unusually thorough behavioral disclosure.

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

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

A single dense paragraph whose sentences each carry distinct payload (what/list scope, matching behavior, scoring, output/evidence, limitations, cost). It is front-loaded with the core purpose, though the length pushes the practical guidance (cost, limitations) toward the end.

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 and no annotations, yet the description explains the returned fields (score, match_type, data_as_of, lists screened/unavailable/last refreshed), the cap of 10 results, and the non-legal nature of matches. An agent has everything needed to invoke and interpret this tool 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%, so the baseline is 3, but the description adds genuine meaning: it explains the trade-off behind min_score (lower finds more variants and more false positives, higher finds fewer of both) and restates the default 0.85 and the Latin-script constraint on the name. That is more than the schema alone conveys.

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 (screens) and resource (a person or company name) and enumerates the exact lists consulted: OFAC SDN, OFAC Consolidated, UN, EU, UK. This is immediately distinguishable from the sibling tools (verify_company, verify_vat, validate_iban, enrich_company), none of which perform sanctions screening.

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 usage context: 'A match is a signal for enhanced due diligence, never a legal determination' and instructs the agent to retain 'data_as_of' as evidence of the check. It does not explicitly state when to prefer this over a sibling or when not to call it, but no sibling offers overlapping functionality, so the routing gap is minor.

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 no annotations, the description carries the full burden and does so: it discloses offline/non-existence semantics, the stable reason_code taxonomy for invalid input, the exact return fields (valid, reason, bank_code, branch_code, bic.valid), a subtle edge case ('a BIC country that differs from the IBAN country is a warnings entry, not an invalid result'), the scope limit of 'valid' to the IBAN only, and a credit cost.

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 primary action and then densely packed with return-value detail; nearly every clause adds information (registry release, reason codes, warnings semantics, cost). It is delivered as one long block without visual breaks, so a reader must parse a run-on sentence to reach the BIC rules, costing a point on structure.

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

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

There is no output schema, so the description must explain returns, and it does thoroughly: success fields, invalid reason codes with human-readable reasons, BIC validation results, and the warnings-vs-invalid distinction. An agent has everything needed to call the tool and interpret results 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 description coverage is 100%, so the baseline is 3; the description goes further by tying the optional bic to its downstream behavior (bic.valid, country comparison, warnings rather than failure) and clarifying that 'valid' refers to the IBAN alone, which the schema cannot express. It does not restate the iban space/format syntax, which the schema already covers.

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 precise verb+resource ('Validates an IBAN offline against the SWIFT IBAN Registry, Release 103') and enumerates exactly what is checked: country registration, length, BBAN format, check digits and ISO 7064 mod-97. This is clearly separable from siblings like verify_vat and verify_company, and the schema even adds 'Not a VAT number' to close the ambiguity.

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

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

Gives strong usage context: 'offline' checking, an explicit boundary ('This checks structure, not that the account or BIC exists'), and a cost signal ('Light read: costs 0.2 credit'). It stops short of explicitly routing the agent to alternatives such as verify_vat when a tax identifier is at hand, so no formal when-not/alternative guidance is 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?

With no annotations, the description carries the burden and does well: it discloses the credit cost, the result cap (up to 5 records), the two supported registries, and the returned field set. It omits failure behavior (no match found), permission/auth requirements, and whether results are cached or live.

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, front-loaded with the purpose, then scope, input, return shape, and cost. No filler, though the input sentence largely duplicates the schema and could be trimmed.

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

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

With no annotations and no output schema, the description compensates by enumerating returned fields, disclosing cost, and bounding result count. Missing only edge-case behavior (no-match/error handling) and permission requirements for a verification call.

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

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

Schema description coverage is 100%, so the schema already documents both parameters including the enum and example formats. The description's restatement ('country and a query that is either a registration number or a company name') adds no syntax or nuance 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 (verifies) and resource (company against its official state registry) plus the outcome (legal status). The registry scoping (FR SIREN/SIRET, GB Companies House) makes it clearly distinguishable from siblings like screen_sanctions or verify_vat 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?

It implies the context of use (checking a company against an official registry) and tells the agent which countries and query forms are valid, but gives no explicit when-not-to-use guidance and never names an alternative such as enrich_company. Usage is inferable rather than directed.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses the 7-day stale-cache fallback, that stale answers carry stale:true, their original checkedAt, and never a consultation number, that no cached answer yields a retryable error, and that a fresh check costs 0.2 credit. These are exactly the behavioral traits an agent cannot infer from schema alone.

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 result before detailing fallback and cost semantics. It is dense and semicolon-chained, but each clause (fallback, staleness markers, cost) conveys distinct operational 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 must describe returns — and it does: validity, registered name and address when provided, stale flag, checkedAt, consultationNumber, and error behavior. An agent has everything needed to call and interpret this 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. The description goes beyond it by explaining the functional consequence of requester_vat_number — that VIES issues a consultationNumber as official proof, and that an unknown requester is refused — which the schema only states in passing.

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 (validates an EU VAT number live against VIES) and names the authoritative source. It is trivially distinguishable from sibling validate_iban, and the schema even reinforces the boundary by stating the input is not an IBAN.

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 context: use it to check current VAT validity, and supply requester_vat_number when you need VIES's official proof of the check. It does not explicitly position itself against verify_company or validate_iban, so routing between siblings is left partly to inference.

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