Factline KYC, KYB and agent payments

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

Goes well beyond the readOnly/idempotent annotations: discloses the payment model (0.03 USDC via x402, or 15 credits of a Factline API key), the free-tier allowance (first 5 paid-tool calls a day free), the returned verdict vocabulary (pass / review / block_review with reasons), and the precise coverage boundary (no GSXT register query, Xinjiang flagged in the USCC checks). That is exactly the operational context an agent needs before spending money.

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 passage front-loaded with the use case, then coverage, verdict values, scope limit, and pricing in a logical order. Nearly every clause carries information, though the pricing/free-tier sentence is long enough to slightly slow scanning.

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

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

No output schema exists, yet the description names the verdict values and that reasons accompany them, plus discloses cost, auth paths, and the one data source it does not consult. Nothing material is missing for an agent deciding whether to call and how to pay.

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 all three parameters are already documented with descriptions, which sets the baseline at 3. The description's 'Input: name, uscc' merely restates the schema and says nothing new about api_key handling or USCC format requirements, so it adds little.

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 ('checks the 18-character Unified Social Credit Code... and screens the company against EU, UN, UK and US OFAC sanctions, BIS Entity List, MEU list and DHS UFLPA') scoped to Chinese suppliers. This cleanly distinguishes it from siblings like eu_company_check, us_company_lookup and supplier_invoice_check without the agent needing to open 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?

'Use this when the counterparty is a Chinese supplier you are about to pay or import from' gives an explicit trigger, and 'Does not query the Chinese register (GSXT)' carves out a scope exclusion. It stops short of naming the sibling to use instead for non-Chinese or non-sanctions checks, so usage routing is clear but not complete.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, open world), and the description adds genuinely non-redundant behavior: exact cost, two accepted payment paths, a free daily quota requiring no key or payment, and the return shape ('one verdict and a cite_as line'). It also discloses coverage limits via the country list (financials only in GB, FR, NO, FI, NL).

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?

Information-dense and front-loaded: trigger, scope, contents, output, then cost. No filler sentences, but several clauses are stacked into run-on sentences, making the payment and free-tier details slightly harder to scan than necessary.

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 paid, multi-source aggregation tool with no output schema, the description covers everything an agent needs: what data is returned, what the output format looks like ('one verdict and a cite_as line'), what it costs, how to pay, and when it is overkill. No material gap remains.

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 baseline is 3; the description adds real guidance by saying the input is 'name or id, best with country', telling the agent to combine identifiers with a country for better resolution, which the schema does not state. It does not explain tradeoffs between the other identifiers (kvk, vat, domain), so it stops short of 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?

States a specific verb+resource (full due diligence on a European company) and enumerates exactly what the dossier contains: registers in 10 countries plus GLEIF, directors/owners/parents screened for sanctions and PEP, VAT, Peppol, website, financial health. It explicitly positions itself above an 'existence check', which distinguishes it from siblings like company_lookup and eu_company_check.

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 trigger ('before a deal or large payment') and an explicit exclusion ('beyond an existence check'), plus the payment mechanics (0.15 USDC via x402, 75 credits, or 5 free calls/day) that gate invocation. It falls short of naming the cheaper sibling tools an agent should use for simple existence checks, leaving that mapping implicit.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior. The description adds material behavioral context beyond annotations: pricing via x402 or credits, API key usage, free first 5 paid calls per day, country coverage, and verdict outcomes.

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 use case, then compresses country coverage into a compact semicolon list, followed by verdict and payment details. It is dense but every clause carries coverage, cost, or auth information; minor density keeps it from a 5.

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 complex paid, multi-country, read-only tool with no output schema, the description supplies country coverage, verdict categories, payment/auth details, and API key placement. It does not clarify the minimum identifier needed when all five parameters are optional, though the schema covers parameter 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 all five parameters are already documented in the schema, including id, kvk, name, api_key, and country. The description restates country support and Dutch KvK insolvency meaning but adds little parameter-level meaning 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: check whether a European company is healthy, with enumerated country-specific signals and a clear verdict scale. The health-check focus is distinguishable from generic lookup/dossier siblings, but the description never names or contrasts those alternatives, so it falls short of full sibling differentiation.

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: use before dealing with a European company, and specifies which countries and signals are covered. It does not state when not to use it or explicitly route agents to company_lookup, company_dossier, or eu_company_check, so it lacks exclusions/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 declare readOnly/idempotent/openWorld/non-destructive, and the description adds what structured fields cannot: the cost per call (0.008 USDC or 4 credits), the free-first-5-per-day policy, and the auth mechanic that an api_key can be passed inline without reconnecting. It also enumerates the returned fields, so the agent knows the payload shape despite there being no output schema.

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

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

Front-loaded with the routing decision, then the register coverage, then returns, then cost. The long register enumeration is dense but earns its place by defining scope; only slight trimming would be possible.

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 listing the returned fields explicitly. Payment model, auth requirement, coverage and lookup modes are all present, leaving nothing an agent needs in order to call it correctly.

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

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

Schema coverage is 100%, so parameters are documented structurally. The description adds value beyond that by stating the two lookup modes (name or id) and by listing which countries have registers, which is what actually makes the optional country filter meaningful.

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?

Specific verb+resource: confirms a company exists and is active against named official registers. It explicitly positions itself as the cheap first step before a dossier, which cleanly separates it from company_dossier, company_health, eu_company_check and us_company_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?

States the exact selection condition ("only need to confirm a company exists and is active") and routes the agent to the more expensive dossier when that is insufficient. It also spells out the payment paths and the free-tier allowance, so the agent knows when no credentials are needed.

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

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

Annotations already establish read-only, idempotent, open-world, non-destructive behavior, and the description adds important operational context: what data is checked, risk levels and flags, accepted inputs, x402 cost, API-key credits, and the first-5-free daily quota. This materially helps an agent understand cost and prerequisites before calling.

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 dense but front-loaded: it starts with the use case, then lists the evidence returned, then covers accepted inputs and payment. Every sentence contributes either routing, output expectations, or payment semantics.

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 no-output-schema tool with meaningful complexity, the description lists the key returned data points and risk flags well enough to set expectations. It does not describe the exact response shape, but combined with the rich annotations and complete schema, it 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?

Schema coverage is 100%, so the parameters are already well documented. The description still adds useful meaning by clarifying that the input may be a domain, URL or email, and by explaining when the optional API key matters versus the free-quota or x402 payment paths.

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: judging whether a website or email domain is trustworthy. It enumerates concrete checks such as RDAP registration age, expiry, registrar, nameservers, MX/SPF/DMARC, disposable domains and risk scoring, making it clearly distinct from sibling tools like company dossiers or email verification.

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 clear usage context: use when you need to judge domain trustworthiness. It does not explicitly name alternatives or when-not-to-use cases, so it falls short of full routing guidance, but the intended context is clear.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds context they cannot: pricing at 0.002 USDC via x402 or 1 Factline credit, plus the first 5 paid calls per day being free with no payment or key. It also defines the output categories (deliverable, risky, undeliverable), which matters for a paid, open-world 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?

Two sentences, both front-loaded: the use case and check inventory come first, payment mechanics second. Every clause carries information an agent needs — no filler and no repetition of the title.

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

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

With no output schema, the description supplies the return shape by naming the three verdicts, and it covers the payment/auth paths an agent must handle. Nothing required to invoke the tool correctly is missing.

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

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

Schema description coverage is 100% — both the email format example and the api_key sourcing from get_trial_key are documented in the schema itself. The description adds no parameter-level detail beyond that, so the baseline of 3 is appropriate.

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

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

States a specific verb and resource (verify an email address) and enumerates the exact checks performed: syntax, live MX routing, 9,000+ disposable domains, role addresses, free providers, typo suggestions and SPF/DMARC. The sibling phone_verify covers a different resource, so the distinction is implicit but unambiguous.

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?

Clearly names the trigger context — before signup, outreach or onboarding — so an agent knows when to reach for it. It does not name exclusions or alternatives (e.g. when a syntax-only check would suffice), which keeps it short of a 5.

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 read-only, idempotent, open-world and non-destructive, and the description still adds real context on top: the per-call price (0.05 USDC / 25 credits), the free-tier allowance of five paid calls per day with no key, and the four possible verdict outcomes. Pricing and the payment-vs-key path are exactly the operational facts an agent cannot get from 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?

Front-loaded with the use case, then coverage, then verdict, then input and pricing — a sensible order. The long mid-sentence enumeration of ten country codes is dense but each clause carries distinct information. Slightly overpacked for a single breath, but nothing is redundant.

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

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

With no output schema, the description still tells the agent what comes back (a single verdict from four values). Zero required parameters over seven inputs is handled by 'name or id, best with country'. Payment, auth and free-tier paths are all covered, leaving no material gap for correct invocation.

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 a non-obvious heuristic the schema does not: 'name or id, best with country', signaling the call works with a name alone and that country improves matching. It also mentions kvk as the bankruptcy trigger, reinforcing the schema. Not a 5 because vat and domain are not elaborated beyond their schema descriptions.

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 specific verbs (finds, screens, checks, flags) and a precise resource scope: a European company across 10 named registers plus sanctions/PEP/VAT/Peppol/bankruptcy checks, collapsing into one verdict. That is far more than a restatement of the name. It stops short of 5 because it never names the sibling it replaces (company_dossier, kyc_check, eu_sanctions_screen), leaving the agent to infer differentiation from the enumerated 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?

Opens with an explicit trigger: 'Use before onboarding, paying or contracting a European company', which is a concrete decision context. It gives no exclusion or when-not guidance, and does not point at alternatives for cheaper narrower checks, so it falls short of the top band.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the bar is lower, yet the description adds substantial context: live querying of the EC service, partial return data (name/address only when published), and a detailed cost model (0.003 USDC via x402, 2 credits per Factline key, 5 free paid-tool calls/day). This is exactly the payment/auth detail an agent needs before invoking.

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

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

The trigger condition is front-loaded and the sentences are dense but purposeful; each covers a distinct concern (scope, coverage gap, pricing, free tier). It is a long single block, but no sentence is wasted.

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

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

There is no output schema, and the description compensates by stating what comes back (registered/valid status plus trader name and address when published). With pricing, auth options, and geographic coverage all covered, an agent has everything needed to call 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 both parameters are documented (the eori example and the api_key provenance from get_trial_key), so the schema carries the load. The description reinforces the payment/key paths but adds no syntax or format detail 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 ('check an EU EORI customs number') with scope qualifiers (all EU member states, GB excluded, live validation against the European Commission's EORI service). This clearly distinguishes it from near siblings like eu_vat_check or eu_company_check.

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?

'Use when you need to check an EU EORI customs number' plus the explicit exclusion 'GB numbers are not covered' gives clear when-to-use and when-not context. It does not name an alternative tool for non-EU/GB checks, so it stops short of a 5.

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 and non-destructive, so the safety profile is covered; the description adds genuinely new operational context: it is free, covers ~30 currencies, supports only today or working days within the last 90 days, and returns cross rates. The working-day/90-day constraint is exactly the kind of limit an agent needs and could not infer from 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 single most decision-relevant token ('Free') followed by the when-to-use clause, then inputs. One dense block with essentially no filler; only slight cost is the packing of constraints into a run-on list.

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 enough: it names the data source, coverage, date window and that cross rates come back. It could say more about the response shape or what happens on non-working days, but an agent has what it needs to invoke 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 description coverage is 0% and all four params are bare strings, so the description carries the full documentation burden. It supplies the default for base (EUR), a format example for symbols (USD,GBP), a format for date (YYYY-MM-DD), and identifies date and amount as optional — a meaningful lift, though it never clarifies that amount is a numeric quantity typed as a string.

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

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

States a specific verb+resource combination: ECB euro reference rates for ~30 currencies, plus cross-rate conversion, with the currency universe and date range named. An agent can distinguish it immediately from every sibling (none of which deal with FX) without opening the schema.

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

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

Gives an explicit trigger — 'Use when the user needs an official euro exchange rate or a conversion for an invoice, contract or report' — which maps a user intent onto the tool. It stops short of stating when not to use it or naming an alternative, but no sibling is a plausible substitute for FX rates.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description adds genuinely useful context beyond them: cost ('Free') and the exact return payload an agent can expect. It does not mention rate limits or auth, but for a free public read it adds value above what the structured fields provide.

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 sentence front-loads the cost/usage cue ('Free. Use when...') and then packs purpose, return fields, and both accepted input formats with no filler. Every clause carries 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?

There is no output schema, so the description carries the burden of describing return values – and it does so explicitly (title, date, in-force status, EUR-Lex link). Combined with the input-format examples and safety annotations, nothing needed to call the tool correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description supplies concrete input examples the schema only restates: a CELEX number (32016R0679) and free-text citations (Directive 2015/849). This clarifies that two different identifier formats are accepted, which is useful disambiguation.

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 (lookup) and resource (EU regulation/directive/decision) and enumerates exactly what is returned: official title, date, in-force status, EUR-Lex link. This cleanly distinguishes it from sibling checks like eu_company_check or eu_vat_check, which target different EU identifiers.

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 triggering condition ('use when the user cites an EU regulation, directive or decision and you need its official title, date, whether it is still in force, and the EUR-Lex link to cite'), which is strong context. It does not name an alternative tool or state when not to use it, but the sibling set has no overlapping citation-lookup tool, so this is near-sufficient.

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 read-only, idempotent, non-destructive and open-world, but the description adds far more: fuzzy matching approach, the exact per-name and per-call price, two payment routes (x402 vs 15 Factline credits), a free tier of 5 paid calls/day, and the return shape per name. That is exactly the cost and auth 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 trigger and the capability, then pricing and output shape. Slight redundancy in quoting the cost twice ('0.0012 USDC per name' and 'Costs 0.03 USDC via x402'), but every sentence carries decision-relevant 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?

No output schema exists, yet the description specifies the per-name return structure (match flag, top score, up to 3 scored matches with their lists), and it covers cost, auth and the free-tier escape hatch. An agent has everything needed to call this correctly and predict the response.

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

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

Schema coverage is 67% and the description compensates where it matters: the 1-25 cap on `names` and the per-name pricing tied to it. It does not explain what `type` (person/entity) changes in matching behavior, and the 'people or companies' phrasing only loosely maps to that enum.

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 ('screening a list of people or companies ... against the EU, UN, UK and US OFAC sanctions lists') plus the batch capacity, which implicitly separates it from the single-record sibling eu_sanctions_screen. An agent can tell at a glance this is the multi-name variant.

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?

'Use when screening a list of people or companies at once' gives an explicit trigger, and 'For customer bases, payouts and vendor lists' names concrete scenarios. It stops short of naming the alternative to use for a single person (eu_sanctions_screen) or the pep_batch/kyc_check boundary, so routing is implied rather than fully resolved.

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 read-only, idempotent, non-destructive, but the description adds substantial context beyond them: the fuzzy-matching behavior (spelling, transliteration, word order), what the response contains (scored matches with lists, references, birth dates), and the full cost model — 0.005 USDC via x402, 3 credits, or 5 free paid-tool calls per day. That payment/free-tier detail is exactly the kind of operational fact annotations cannot convey.

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

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

Three sentences, front-loaded with the 'Use when' trigger, then capability/return shape, then pricing. Dense but every clause carries information the agent needs (coverage, matching behavior, output shape, cost), with no filler or repetition of the title.

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

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

There is no output schema, yet the description states what comes back (scored possible matches with list, reference and birth date), plus cost and free-tier mechanics and the api_key path. For a single-lookup screening tool this covers everything needed to invoke it correctly; only the person/entity enum semantics remain unaddressed.

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 75%, so the baseline is 3, and the description earns an upgrade by explaining how the name parameter is actually matched — fuzzy handling of spelling variants, transliteration and word order — which is behavioral meaning the schema does not carry. It does not clarify the person/entity enum or how birth_year is used to disambiguate matches, leaving those to the schema.

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

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

States a specific verb and resource — 'screens the name against the EU, UN, UK and US OFAC lists' — and scopes it further with dataset size (25,000+ persons, companies and vessels) and refresh cadence. This clearly separates it from sibling batch/wallet variants (eu_sanctions_batch, eu_sanctions_wallet) without naming them explicitly.

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?

'Use when you must check whether a person or company is under sanctions' gives an explicit trigger condition, which is more than most siblings offer. However, it never names alternatives such as eu_sanctions_batch for multiple names, pep_screen, or us_trade_screen, so the agent must infer routing from tool names 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 readOnly, idempotent, openWorld, and non-destructive behavior. The description adds meaningful context beyond them: weekly OFAC refresh, returned fields, x402 pricing, API-key credit cost, and a free daily allowance. It leaves some payment-flow details implicit, such as how x402 payment is performed or what happens on payment failure.

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 front-loaded with the primary use case, then coverage, return values, and cost. Despite being a single dense passage, every clause carries operational value for invoking or paying for the tool.

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

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

With no output schema, the description supplies the key return fields: sanctioned true/false, currency, listed entity, and programme. For a read-only paid screening tool, it also covers refresh cadence and payment/free-tier mechanics, leaving no major invocation gap.

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

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

Schema coverage is 100%, so the address and api_key parameters are already documented. The description still adds useful semantics by listing supported blockchain/currency types for the address and by explaining that api_key usage consumes credits with a free first-5-calls allowance.

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: screening crypto wallet addresses against the US OFAC SDN list. It names supported chains and clarifies the OFAC scope, which disambiguates it from generic EU sanctions screening siblings despite the eu_ prefix in the tool name.

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

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

It gives clear triggers: 'Use before sending crypto to an address, or when asked if a wallet is sanctioned.' It does not explicitly name alternatives such as eu_sanctions_screen or eu_sanctions_batch, nor does it state when not to use this tool, but the wallet-specific context is sufficient.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description still adds materially new behavioral facts: cost (0.005 USDC or 3 credits), the free-allowance rule (5 paid calls/day, no key needed), and a data-coverage caveat about NL national tenders. These are exactly the operational details 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?

Three tight sentences, front-loaded with the trigger, then the NL differentiator, then pricing. Every clause carries information an agent needs; nothing is repeated from the title or schema.

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 usefully states the returned fields (English titles, buyer, deadline, value). Only gaps are the unformatted optional filters (limit, deadline_within) and no note on empty-result or error behavior for a paid, open-world 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 coverage is 57%, so the baseline is 3. The description maps most documented filters to natural language (country, CPV, keywords, deadline, minimum value) and reveals the 'EU' country value, but says nothing about limit, deadline_within format, or min_value units, leaving the undocumented half of the schema unassisted.

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?

Specific verb+resource ('search open public tenders') anchored to a named source (TED, the EU's official journal) and an explicit scope extension for the Netherlands (TenderNed below-threshold tenders not in TED). No sibling tool covers tenders, so the agent can route here unambiguously.

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?

'Use when the user looks for public contracts to bid on' gives a clear triggering condition, and the payment paragraph implicitly routes paid vs. key-based vs. free-tier callers. It stops short of explicit when-not conditions or naming the alternative path (e.g. get_trial_key) as a prerequisite action, which the schema does instead.

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 read-only, idempotent, non-destructive, open-world behavior. The description adds material context beyond that: live external lookup in VIES, inclusion of registered name/address where shared, and a precise payment model (0.003 USDC via x402 or 2 credits, with five free paid-tool calls per day).

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 trigger and scope, then adds coverage, input format, and pricing in a compact block. It is dense and slightly run-on at the end, but every clause carries useful 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?

For a read-only verification tool with no output schema, the description supplies what an agent needs: data source (VIES), geographic coverage, return content (validity plus registered name/address where shared), input format, and cost/auth requirements.

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 vat and api_key are already fully documented in the schema. The description repeats the VAT example and country-prefix requirement but adds no new syntax or constraints, 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: a live validity check of an EU VAT number against VIES, explicitly covering all 27 member states plus Northern Ireland. This clearly distinguishes it from siblings like eu_eori_check or eu_company_check without needing to name them.

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 trigger condition: 'Use when the user gives an EU VAT number and you need to know if it is valid.' It does not name when-not to use it or point to alternatives (e.g., eu_eori_check for EORI numbers), so it stops short of a 5.

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 non-read-only, non-idempotent, open-world behavior; the description adds real value beyond them by disclosing outcomes per mode (100 credits / 14 days / no human step vs. 2,000 credits monthly / one per email) and an upgrade path. The only gaps are what happens if a trial key already exists or the response shape, but for a small issuance tool this is substantial.

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 key fact ('Free'), then conditions, modes, and the agent instruction. Four tight sentences with no filler; every sentence adds routing or behavioral 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 carries the burden of explaining what comes back, and it does by naming the key types, credit amounts, and durations. Minor gaps remain around use_case and the exact response format, but nothing essential 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 coverage is 75%, so baseline is 3. The description clarifies email and api_key semantics (omit email for starter, pair email+api_key to upgrade), but much of that repeats the schema's own descriptions, and the use_case parameter is left undocumented in both places.

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 the specific action (obtaining a Factline key) and its two variants (instant starter key vs. email-backed trial key). It clearly separates itself from the sibling report/check tools by framing the purpose as key acquisition when free calls run out, not a data 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?

Gives an explicit trigger ('use when free calls for today are used up or the user wants more paid checks without a crypto wallet') and an explicit behavioral instruction ('Ask the user for the email; never invent one'). It also explains the branch condition between the two modes (omit email vs. supply email), so the agent knows which path to take.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavioral facts: the 0.001 USDC x402 cost, the 1-credit Factline key alternative, and the first-5-free daily allowance, plus the explicit scope limit on account-holder confirmation. It still says nothing about how failures surface (e.g. malformed vs. checksum-failing IBAN) or response shape.

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

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

Three sentences, front-loaded with the usage trigger, then capabilities, then the negative scope plus cost. Dense but every clause carries information; the only mild redundancy is that the '(paid)' title already signals payment, which the last sentence then elaborates.

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 takes on the burden of indicating what comes back, and it does so at a useful level (checks performed, bank name for NL IBANs, explicit non-result for account holder). It is missing return-value structure for the non-Dutch case and any error/failure semantics, so not fully 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 coverage is 100% and the api_key parameter's own description already explains the fl_live_ prefix and get_trial_key flow, so the description is not required to compensate. The description adds no parameter-level detail (format, casing, spaces, country prefix handling) beyond what the schema provides, 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 (check/validate an IBAN) and enumerates exactly what is validated: country-specific length, mod-97 checksum, SEPA membership, and Dutch bank identification. It also draws the boundary ('Does not confirm the account holder'), which separates it from kyc_check / eu_sanctions_screen 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?

'Use when you need to check an IBAN before a payout or invoice' gives a concrete triggering context, and the closing sentence scopes out account-holder verification. It stops short of naming a sibling alternative to use when the account holder does matter (e.g. kyc_check), leaving that routing to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds material context beyond that: the checks run in parallel, any subset of name/email/phone/vat suffices, the exact verdict vocabulary, and the cost/free-tier mechanics that materially affect whether an agent should call this repeatedly.

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

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

A single dense paragraph that front-loads the trigger, then scope, then the verdict vocabulary, then cost. Every clause carries information, but the run-on construction and the inline payment details make it harder to scan than a two- or three-sentence split would be.

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

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

For a 12-parameter, no-output-schema, paid read tool, the description covers the essentials: what it checks, what verdicts come back, and what it costs. It does not explain how partial inputs change coverage (e.g. name-only vs name+VAT), or what 'incomplete' means operationally, which is the main remaining gap.

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

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

With 12 parameters and only 50% schema description coverage, the description must compensate, and it does partially: it names name, email, phone and vat as the inputs and states that any subset is acceptable, which is the key semantic an agent needs. However, it never mentions kvk, pep, type, company, country, birth_year or company_country, and 'send any of name, email, phone, vat' arguably understates the accepted input set.

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 bundle: screens a name against EU/UN/UK/US sanctions and PEP, verifies email and phone, and checks an EU VAT number in VIES. It explicitly bounds the scope ('not a company deep-dive') and enumerates the four verdicts, so an agent can distinguish it from company_lookup, company_dossier, eu_sanctions_screen, email_verify and eu_vat_check 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?

Opens with the trigger condition ('when onboarding a new customer, seller or business') and adds a negative condition ('not a company deep-dive'), which routes the agent away from the deep-dive siblings. It also spells out the payment paths (x402 USDC, Factline credits, five free calls per day), which is usage guidance as much as pricing.

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

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

Beyond the annotations (readOnly, idempotent, openWorld), the description discloses the crucial behavioural facts: this is a live registry check that includes both active and ended cases, it costs 0.01 USDC via x402 or 5 credits of a Factline key, and the first 5 paid calls per day are free with no key needed. Cost, auth path and rate/free-tier limits are exactly the kind of context annotations cannot express.

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

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

Front-loaded with the trigger and scope, then the source and returned fields, then practical constraints. Mostly dense fragments with no filler, though the opening sentence packs many comma-separated clauses that could be split for faster scanning.

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 read-only lookup with no output schema, the description covers what an agent needs: what is queried, which entity types are valid, what data comes back (court, case number, dates, administrator, claims deadline), and how billing/auth works. Nothing material is missing.

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

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

Schema coverage is 100%, so parameters are already documented, but the description adds the meaningful semantic that KvK number and company name are alternative inputs ("Input: KvK number or company name"), consistent with zero required parameters. The api_key role is only hinted at here since the schema already explains it in detail, so this is a modest step above the baseline 3.

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

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

Names a specific action (check bankruptcy/suspension of payments), a specific resource (Dutch company), and even the data source (Centraal Insolventieregister / Rechtspraak) with the fields returned. It does not explicitly differentiate itself from adjacent siblings like company_health or eu_company_check, which is the only thing keeping it from a 5.

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

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

The trigger is explicit ("Use when you need to know if a Dutch company is bankrupt or in suspension of payments") and it gives a hard scope exclusion ("Legal entities only"), which rules out individuals/PEP-style lookups. It offers no named alternatives or when-not guidance versus the other company tools, so it stops short of full 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?

Annotations already cover the read-only, idempotent, non-destructive profile, and the description adds substantive context beyond them: per-name cost (0.0012 USDC), total (0.03 USDC), the 15-credit API-key path, the first-5-free-per-day allowance, and the shape of the result (top 3 matches with positions and status). What it omits is what happens when both api_key and payment are available, or any rate limit beyond the free tier.

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 trigger condition is front-loaded in the opening clause, and every subsequent phrase carries load (pricing, output shape, billing fallback). The pricing and free-tier detail is dense but not redundant, though it slightly crowds the core selection signal.

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

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

With no output schema, the description compensates by describing the return value, and it also covers both billing paths and the free daily allowance, which an agent needs before invoking a paid tool. The remaining gap is the precedence between api_key and x402 payment, which the schema only hints at.

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 would be 3, but the description adds a genuine parameter constraint the schema lacks: the upper bound of 25 names per call. The ';' separator and the api_key sourcing are already documented in the schema.

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

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

The description states a specific verb and resource: screen a list of up to 25 names for PEP status in one call, returning the top 3 matches with positions and status. The batch scope ('list', 'in one call') clearly separates it from the single-name sibling pep_screen without needing to open 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?

It gives a concrete when-to-use cue ('For customer-base and CRM re-screening') and the precondition of up to 25 names. It stops short of explicitly routing single-name lookups to pep_screen, so the alternative is implied rather than 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 the safety profile (readOnly, idempotent, openWorld), and the description adds materially: pricing (0.003 USDC via x402 or 2 Factline credits), a free tier of 5 paid-tool calls per day, and the accepted-document return contents. It omits failure behavior when a company is not found in the directory, which keeps it below 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?

The purpose and trigger are front-loaded in the first clause, followed by return values, regulatory context, and pricing. Dense and nearly waste-free, though the regulatory mandate sentence is more motivational than operationally necessary.

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 five optional parameters, no output schema, and no required fields, the description supplies what the structured data cannot: what the response contains, what payment/auth paths exist, and how to avoid payment via the free daily quota. Nothing essential for a correct first call is missing.

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

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

Schema coverage is 100% and each field already documents itself, including the 'Or a company number...' alternative phrasing and the api_key flow. The description largely restates those identifier options rather than adding new semantics such as precedence when id and vat are both supplied, so the baseline of 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 action (look up in the Peppol Directory) and its output (Peppol participant ids and accepted document types), with the accepted identifier schemes spelled out. It is clearly distinguishable from siblings like eu_vat_check or company_lookup, which validate registrations rather than resolve Peppol participation.

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

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

The opening 'Use when you need to send an e-invoice or check if a company can receive one' gives a concrete trigger, reinforced by the Belgium 2026 / France 2026-09 mandates. It does not name an alternative tool or state when not to use it (e.g., vs eu_vat_check for pure VAT validation), so it stops short of a 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely non-structural behavior: fuzzy matching semantics, a default 5-year lookback for former PEPs, and the full payment model (0.005 USDC via x402, 3 credits, first 5 paid calls/day free). Pricing and free-tier quota are exactly the kind of context that changes how an agent plans a call.

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 when-to-use clause, then scope, then mechanics, then pricing — a sensible ordering. It is dense but every sentence carries information; the coverage enumeration is long yet functional.

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

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

No output schema exists, and the description does not say what a result looks like (boolean, match score, position details), which is the main remaining gap for an agent deciding how to consume the response. Everything needed to decide whether and how to invoke it is present.

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 still adds value by framing the matching behavior (fuzzy matching against positions, country and dates, default 5-year recency window), which tells the agent why country and birth_year disambiguate. It stops short of explaining how the api_key interacts with the free-tier path 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?

States a specific verb and resource ('check whether a person is a politically exposed person') and then enumerates the exact coverage scope (heads of state, ministers, central bank governors, MEPs/MPs across EU/EEA/UK/US/CH, current or former). An agent knows precisely what the tool returns a verdict on without opening the schema.

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

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

Gives a clear triggering condition ('Use when you must check ... for AML/KYC') and names a complementary tool ('Pairs with sanctions screening'). It does not distinguish itself from the sibling pep_batch (single vs. bulk), so the multi-person alternative is left implicit.

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

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

Annotations already establish read-only, idempotent, non-destructive safety. The description adds substantive non-schema behavior: pricing via x402 or API credits, a 5-free-call daily allowance, and the returned validation attributes. It does not cover error modes, but the cost and free-tier disclosure is strong.

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 sentences, front-loaded with the use case and result details, then payment information. Every sentence carries scope, parameter guidance, or cost context without 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?

For a 3-parameter paid read-only tool with full schema coverage and no output schema, the description supplies the missing return-field details, national-number handling, and pricing. Nothing critical for an agent to call it correctly is absent.

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?

With 100% schema description coverage, the baseline is 3. The description's national-number example reinforces how to pass country, but it largely mirrors schema text and adds no extra syntax for phone or api_key.

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

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

The description opens with "check a phone number from any country" and enumerates the checks performed: validity, possible allocation, E.164/national format, country, line type, and SMS-capable hint. That is a specific verb+resource with clear scope; no sibling tool performs phone validation, so implicit differentiation is sufficient.

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 clear trigger ("Use when you need to check a phone number from any country") and a specific condition for national numbers with an example. It does not state when not to use the tool or name alternatives, so the guidance is clear but not exhaustive.

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?

The annotations already declare a read-only, idempotent, non-destructive, open-world operation. The description adds meaningful context beyond those annotations: the cost (0.02 USDC via x402 or 10 credits of a Factline API key), the daily free tier of 5 paid-tool calls, the possible outcomes (no_hits, review, block_review), and that the response includes list versions and a signed receipt. All of that would be hard to infer from the annotations 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?

The description is dense but efficient: the trigger condition comes first, then the screening behavior, the return values, the inputs, and the pricing. Every sentence states a distinct fact. It's on the long side, but nothing is filler; the pricing and free-tier details are operationally important.

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's no output schema, so the description has to describe the return values, and it does: the no_hits, review and block_review outcomes, list versions, and a signed receipt. For a paid screening tool, the main gap is that it doesn't say how this differs from the closely related sibling tools, eu_sanctions_wallet and eu_sanctions_batch, when an agent has to choose.

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 33%, so the schema leaves gaps. The description partly fills them by naming the inputs (wallet, owner, optional owner_type, birth_year, country). But it doesn't explain expected formats, such as an EVM/bech32 address form or an ISO country code, and it never mentions the api_key parameter or its fl_live_ prefix, which the schema also documents. So it adds only moderate value beyond the schema.

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

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

The description states a specific verb and resource: it screens a self-hosted wallet against OFAC-listed addresses, the claimed owner against sanctions and PEP lists, and the company register, then issues an evidence record. This is clear, but the description never mentions the sibling eu_sanctions_wallet. So the agent can't tell from the description alone which tool is the right one for a wallet-only 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?

The description gives a clear trigger: 'Use when a crypto service sends to or receives from a self-hosted wallet and must document its checks (EU AMLR, Travel Rule files)'. That tells the agent the context and the compliance purpose. But it gives no guidance on when NOT to use this tool, such as eu_sanctions_wallet or eu_sanctions_batch, and doesn't say what to do if the user only needs a quick screen.

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

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

Annotations already establish read-only, idempotent, non-destructive, open-world behavior, and the description adds what the annotations cannot: the verdict taxonomy (pass/review/hold), the hold-on-mismatched-IBAN rule, and pricing mechanics (0.08 USDC via x402, 40 credits, 5 free calls/day, no key needed). It doesn't discuss latency, failure modes, or what evidence accompanies a 'review' verdict, so not a 5.

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

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

Front-loaded with the use case and verdict framing, and every sentence carries operational information (checks performed, hold rule, cost model). The mid-section is a dense semicolon list that reads as a run-on, which costs it a point but not much is wasted.

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

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

For a 10-parameter, all-optional, no-output-schema tool, the description covers the checks and the verdict classes but leaves open what an agent must supply for a useful result and what payload accompanies each verdict. The hold/pass/review model is stated but not elaborated, so an agent cannot fully anticipate the response.

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

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

Schema coverage is 100%, so baseline would be 3, but the description adds real semantics beyond the schema: kvk 'adds a bankruptcy check', known_iban triggers a hold on changed bank details, and api_key is tied to get_trial_key for immediate reuse. It stops short of stating which parameters are minimally required for a meaningful verdict.

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 ('check a supplier invoice before paying') and then enumerates the concrete sub-checks performed: registers, sanctions/PEP screening, VAT match, IBAN validity, whitelist, email, bankruptcy, Peppol. This clearly differentiates it from single-purpose siblings like iban_check or eu_sanctions_screen by signaling it is a bundled pre-payment fraud check.

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

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

Explicitly names the trigger: 'Use before an agent pays a supplier invoice', and adds a conditional rule for known_iban ('a different bank account than the one on file puts it on hold'). It does not tell the agent when to prefer the cheaper single-check siblings over this composite, but the decision context is otherwise clear.

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

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

Annotations already declare readOnly/idempotent/non-destructive and open-world, so safety is covered; the description adds the behavioral facts annotations cannot carry: exact price (0.01 USDC via x402 or 5 credits of a Factline key) and the free tier of 5 paid-tool calls per day with no key needed. It also enumerates the returned record fields, so the agent knows the payload shape despite there being no output schema.

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

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

Front-loaded with purpose and return fields, then the practical constraints; every sentence (including cost and the free-call allowance) earns its place. It is a dense single block with no visual separation between purpose, input and pricing, which costs a little scannability.

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 paid, read-only lookup with no output schema and no required params, it covers everything an agent needs to decide and call: identity of the resource, alternative identifiers, coverage limits, price, free-tier escape hatch, and the returned record fields. Only edge cases such as ambiguous name matches or not-found behavior are unstated.

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

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

Schema coverage is 100%, so baseline 3, but the description adds real meaning beyond the schema: it states that name, ticker or CIK are alternative lookup keys (the schema marks nothing required and gives no anyOf/logic). The api_key mechanic is left mostly to the schema, which documents it well.

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?

Specific verb and resource: 'verify a US listed company or SEC registrant: finds it by name, ticker or CIK and returns its SEC record.' The US/EDGAR scope plus the explicit exclusion 'Private US companies are not in EDGAR' distinguishes it from the generic company_lookup and from eu_company_check/china_supplier_check 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?

Says clearly when to use it (verifying a US listed company/SEC registrant) and when not (private US companies, which are not in EDGAR), plus the payment prerequisites. It stops short of naming a specific sibling as the fallback for non-US or private companies, so there is no explicit alternative routing.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), and the description adds genuinely non-obvious context: pricing (0.005 USDC via x402 or 3 credits), a 5-free-calls-a-day allowance, and the legal distinction that these are trade restrictions, not asset freezes. What it omits is what a hit looks like — match score, list provenance, or confidence bands — which matters for an open-world screening tool.

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

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

Front-loads the trigger and the scope, then packs coverage, exclusions, inputs and pricing into two dense sentences with no filler. The parentheticals do real work (which agencies' lists, what the ban means) rather than restating 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 and a screening tool whose value depends on interpreting hits, the description should say roughly what comes back (match/no-match, score, list source). It also advertises a threshold that does not exist, so an agent cannot tell how to tune sensitivity. Everything else — pricing, eligibility for free tier, key handling pointer — is present.

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 description's input line claims 'name, optional type (entity or person), threshold', but no threshold parameter exists in the schema — a misleading statement about the call signature. Meanwhile the api_key parameter, which the schema documents well, is never mentioned in the description. With 67% schema coverage the schema carries most weight, but the phantom threshold parameter actively degrades correctness.

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 — screens a name against the US Consolidated Screening List and the DHS UFLPA Entity List — and explicitly carves out the SDN list as belonging to a different (sanctions) screen. The agent can distinguish this from eu_sanctions_screen or pep_screen by coverage rather than guesswork.

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 concrete trigger: 'Use before buying from, selling to or shipping to a company, above all a Chinese or Russian one,' and draws the boundary against the sanctions screen via the SDN exclusion. It stops short of naming the sibling sanction tools (eu_sanctions_screen, pep_screen) or saying when this is unnecessary (e.g. pure EU-only exposure).

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 context beyond the annotations: pricing (0.05 USDC via x402 or 25 credits), the free-first-5-calls-a-day policy, no-account requirement, and how alerts are delivered (webhook plus /v1/watch/alerts with the returned token). It also explains when re-screening fires (sanctions on list changes, company daily, apk daily).

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 use case before mechanics, and every sentence carries real information (use condition, kinds, alert routing, pricing). It is a single dense block, which makes it slightly harder to scan than a structured breakdown would be.

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

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

For a paid, stateful monitoring tool with no output schema, the description covers everything an agent needs: cost and free tier, auth path (api_key), what gets created, and how results arrive. No material gap remains.

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?

With 60% schema coverage, the description meaningfully enriches the kind enum by explaining what each value monitors and how often, and restates the value formats (COUNTRY:name or number, Dutch plate). It leaves label and api_key largely to the schema, which is acceptable since their descriptions already exist.

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

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

States a concrete verb+resource+scope: 'Watches one item for 30 days', and enumerates the three kinds with what each monitors. An agent can immediately tell this apart from the one-shot screening siblings like eu_sanctions_screen or nl_apk_alert.

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 an explicit use condition — 'the user wants to be told later or must show screening keeps running' — which cleanly separates ongoing monitoring from point-in-time lookups. It does not name a specific sibling to use instead for one-off screening, so it stops short of full when/when-not/alternatives routing.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that the call is free and that the alerts are fact changes surfaced over time, which is useful context. However, it does not say what happens when no watches exist, whether results are truncated, or how alert recency is computed, so it goes slightly beyond annotations but does not add rich behavioral detail.

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 front-loads the free/scheduling cue and the alert categories are listed compactly in one sentence. The 'Input:' sentence partly repeats schema content, but the whole thing stays dense and readable with no 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?

For a zero-required-parameter read tool with a 100% schema and no output schema, the definition covers purpose, trigger, prerequisites, and the required credential forms. It is slightly under-specified only on return shape (how watches vs alerts are presented) and empty-watch behavior, which is a minor gap, not a blocking one.

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 each parameter (token, api_key, since) is already documented in the schema with format hints (wt_..., fl_live_..., YYYY-MM-DD). The description restates those formats and the either-or relationship between token and api_key, which is mildly helpful but largely redundant. 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 gives a specific verb (lists) and resource (watches and alerts), enumerates the alert categories (sanctions match, company status, name/address change, APK or recall change), and explicitly points to the originating siblings (watch_30_days or a key). An agent can distinguish this from watch_30_days, nl_apk_alert, and the screening tools 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 when to use it ('start of a session or on a schedule') and the precondition (the user has Factline watches from watch_30_days or a key). That is a clear context plus prerequisite, so nothing material is left to inference.

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

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

Annotations already declare read-only, idempotent, non-destructive and open-world, and the description goes well beyond them: it discloses the cost model (0.01 USDC or 5 credits), the daily free-call allowance with no key needed, which external sources are consulted, and the shape of the verdict (allow/review/deny plus a trust-provider block with decision, score, evidence, ttl).

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 trigger is front-loaded and the return shape and pricing each get their own short clause; nothing is padding. The opening sentence is dense enough to be a run-on with several comma-separated checks, which costs it a point.

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 five optional parameters, the description compensates by explaining what is checked, what comes back (including the trust-provider block) and how payment works. An agent has everything needed to decide to call it and to 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?

At 80% schema coverage the schema already documents url, wallet, api_key, company and country. The description's "Input: url, optional wallet, company, country" only restates them and flags wallet as optional, and it omits api_key entirely from that list even though it is a real input — baseline 3 is right.

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?

Specific verb-plus-resource: it reads a seller's 402 challenge, screens payTo wallets against OFAC, checks domain age/setup and uptime probes, and returns allow/review/deny. That scope is clearly distinct from siblings like x402_pay_guard, x402_sellers and eu_sanctions_wallet, so an agent can pick it 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?

"Use before an agent pays an x402 endpoint it has not used before" is an explicit trigger condition with a clear pre-payment context. It does not name exclusions or point to the closely related siblings (x402_pay_guard, x402_sellers) as alternatives, so it stops short of full 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?

Annotations already declare read-only, idempotent, non-destructive behavior, and the description adds substantial context on top: it is free, it produces allow/review/deny with reasons plus a signed verdict, and strict mode converts a wallet mismatch or missing pay_to into a deny rather than a review. That is exactly the pre-payment behavioral detail an agent needs.

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 key facts ('Free. Use right before paying') then the checks and inputs, with no filler. The body is a long dense sentence, but every clause contributes distinct information, so it remains efficient rather than bloated.

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 tool with 6 params and no output schema, the description covers purpose, when to call, the exact checks, the input list, and the return shape (allow/review/deny with reasons and a signed verdict). An agent has everything needed to call and interpret it.

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

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

With 100% schema coverage the baseline is 3, but the description adds meaning beyond the schema: it explains that pay_to comes from the 402 challenge, which fields are optional, and precisely what strict mode does ('deny instead of review on a wallet mismatch or missing pay_to'). That semantic gloss raises it above 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?

States a specific verb and resource ('screens the payTo wallet', 'checks that payTo is a wallet this seller lists') and enumerates the exact checks performed. However, it never names or differentiates from the very similar sibling x402_payee_check, so an agent must infer the distinction rather than being told.

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?

'Use right before paying an x402 seller' gives a clear placement in the workflow, and the mode description implies a stricter usage variant. It stops short of naming alternatives (x402_payee_check) or when not to call it, so it is clear context without exclusions.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower. The description adds genuine value beyond them: data provenance (Coinbase x402 Bazaar), ranking basis (unique payers, 30 days), and freshness via a daily endpoint-validity check. No pagination, rate-limit, or caching behavior is disclosed.

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 "Free." then the usage trigger, then the payload description. Information-dense with no filler, though the second clause is a dense run-on packing ranking, uptime, speed and networks into one colon chain.

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

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

No output schema exists, so the description carries the return-value burden and does so by describing ranked sellers with uptime, speed, and network data. Adequate for a 3-param read-only tool, though it omits the default/paging behavior of limit and the exact returned fields.

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

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

Schema coverage is 67%, with q and network already documented in the schema; the description only reinforces q with examples ("sanctions, weather, search") that largely duplicate the schema's own example. The limit parameter is undocumented in both schema and description, and its string type for a count is unexplained.

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

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

The description names the specific resource (sellers from the Coinbase x402 Bazaar) and its scope (ranked by unique payers over 30 days, with Factline uptime/speed/network checks). An agent can tell this is a discovery/directory tool, but it never explicitly contrasts itself with the x402_payee_check or x402_pay_guard 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?

"Use when looking for an x402 API to pay for a task, or to see if a seller is used and up" gives an explicit when-to-use trigger. No when-not condition and no named alternatives are provided, but the usage context is clear.

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