Agent Services (x402): compliance, company, procurement

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds valuable behavioral context beyond those: pricing per call, USDC on Base via x402, and that it returns payment requirements unless payment_signature is supplied. This is meaningful operational 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?

The description is front-loaded with purpose, then usage, then payment mechanics and sample. It is efficient and every sentence is useful, though the price/payment lines slightly interrupt the flow.

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 should carry more burden for return values. It explains the x402 payment gating but does not describe the actual weather/delay payload after payment, nor geographic scope beyond 'US airport delays' implied by the title.

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

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

Schema description coverage is 100%, and the schema already documents the airport code formats and payment_signature semantics. The description adds no parameter detail 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?

The description states a specific purpose: checking weather or US airport delays affecting a flight, pickup or shipment. The title adds METAR/TAF/FAA scope, making the resource clear. It does not explicitly name the sibling weather_forecast to differentiate, so it falls short of a 5.

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

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

It gives explicit usage context: 'Use when planning around a specific airport in the next hours.' This is clear and actionable. It does not provide exclusions or name alternatives, so a 4 is appropriate.

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 the description adds material behavior beyond them: the $0.50 per-batch price, the x402/USDC-on-Base payment mechanism, and the fact that it returns payment requirements unless payment_signature is supplied. That payment-gate behavior is the single most important thing an agent must know and it is disclosed. It doesn't cover failure modes or partial-batch behavior.

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 a category tag, then purpose, then usage, then price/payment behavior and a sample link. Sentences are short and each carries distinct information, though the bracketed category tag and sample path are slightly ornamental.

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, but the description explains the critical return branch (payment requirements vs. results once payment_signature is given). For a paid batch tool this is nearly complete, leaving only the paid-response shape undescribed.

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 every parameter (names formatting, min_score range, matches_per_name range, payment_signature, include_export_control) is already documented in the schema. The description only restates the 100-name cap, adding no semantics beyond structured data. 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 action and scope: screen a whole list of customers/suppliers/payees against sanctions and US export-control lists 'in one call'. The batch framing ('whole list', 'up to 100 names') distinguishes it from the single-entity siblings screen_sanctions and screen_export_control, though it never names 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?

Gives clear usage context — 'onboarding backlogs or periodic re-screening' — which tells the agent when batch mode is appropriate. It stops short of stating when-not to use it or naming the per-name alternatives for one-off lookups.

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 genuinely useful behavior beyond them: the $0.002 price, the x402/USDC-on-Base payment mechanism, and the crucial fact that a call without payment_signature returns payment requirements rather than a result. It does not describe the shape of a successful (paid) response or any error/rate-limit behavior.

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

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

Four tight sentences with the purpose front-loaded, followed by usage, pricing/payment, and a sample pointer. The '[Data utilities]' prefix is minor filler but nothing else is wasted.

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

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

With no output schema, the description should carry the return-value burden, and it only explains the unpaid response (payment requirements), not what a paid call yields (a date? a count? a holiday list?). For an 8-parameter tool with several distinct modes, that leaves the agent guessing at the result shape.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters including `add`, `until`, `weekend`, and `payment_signature`. The description adds no parameter-level detail beyond that (e.g. how `add` and `until` interact, or default weekend handling), so the baseline 3 applies.

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

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

States a specific verb and resource: compute a payment/delivery/legal deadline in business days for a given country, with the holiday dependency named. It stops short of mentioning the other capability implied by the title, listing a year's public holidays via the `year` parameter, so the scope is slightly narrower than the tool actually is.

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 when-to-use condition ('Use when a due date or notice period depends on local public holidays') and explains the payment handshake ('Returns the x402 payment requirements unless payment_signature is given'). No siblings overlap this function, so there are no alternatives to route between, but no explicit exclusions are offered either.

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), but the description adds genuinely useful non-obvious behavior: pricing, the x402 payment flow, and that the call returns payment requirements rather than results unless payment_signature is supplied. It still omits what a successful verification returns.

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 tag and core purpose, followed by usage, pricing, payment behavior, and a sample pointer in a compact block. Dense but every sentence carries information; 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?

With no output schema, the description covers purpose, usage, cost, payment mechanics, and a sample. It leaves the shape of a successful verification result (valid/invalid, matched company name) unspecified, which is a minor gap for a 2-param tool.

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

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

Schema coverage is 100%, so both parameters are already documented in the schema. The description restates the payment_signature behavior but adds no syntax or format detail beyond what the schema provides, making the baseline 3 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 EU trader's EORI number") plus the context in which it matters (shipping, invoicing, customs). It is clearly distinct from data-lookup siblings, though it does not explicitly contrast with the close sibling check_vat.

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 customs paperwork or a shipment needs a confirmed EU EORI" gives a clear when-to-use trigger. It does not name exclusions or point to an alternative tool for non-EU VAT checks, so it falls 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 read-only/idempotent/open-world, but the description adds meaningful operational context: price ($0.02 USDC on Base), the x402 payment flow, and that a call returns payment requirements unless payment_signature is supplied. It does not describe rate limits or behavior on invalid/unknown VAT numbers, 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 a category tag, purpose, and usage, followed by pricing and return behavior. Dense but every sentence carries information; the sample path and payment mechanics are useful rather than filler.

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

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

With no output schema, the description appropriately explains the two-phase return behavior (payment requirements vs. result) and the payment model. It is complete enough to invoke correctly, though it omits the response shape of a successful VAT verification.

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

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

Schema description coverage is 100%, so the schema already documents both parameters, including the country-prefix format and the payment_signature semantics. The description's 'Returns the x402 payment requirements unless payment_signature is given' largely restates what the schema says, so it adds little beyond the baseline.

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

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

States a specific verb and resource: 'Verify an EU supplier's or customer's VAT number'. It is clearly distinguishable from the sibling check_eori (customs identifier) and supplier_check, giving an agent an unambiguous target.

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

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

Gives concrete trigger conditions: 'before invoicing or paying', 'when applying the reverse charge', 'onboarding a B2B counterparty in the EU'. It lacks explicit when-not or a named alternative sibling, 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 cover the safety profile (readOnly, idempotent, openWorld), and the description adds genuinely useful non-structured behavior: the $0.10 price, USDC-on-Base/x402 payment model, and the fact that it returns payment requirements unless payment_signature is supplied. It does not describe failure modes or the shape of screening results, but the payment gating disclosure is valuable.

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

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

Front-loads purpose and use case, then price, payment behavior, and a sample link, all in a few dense sentences. The bracketed category tag is slightly noisy but the content is otherwise tight and well-ordered.

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

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

There is no output schema, so the description carries the burden of explaining returns, yet it only describes the payment handshake and points to a sample rather than indicating what a screening result contains (hit flags, matched lists, confidence). Adequate for invoking the tool, but incomplete on the result side.

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

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

Schema description coverage is 100% and all seven parameters (name, type, dob, lei, country, registration_number, payment_signature) are documented in the schema itself. The description adds no additional parameter meaning, 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 verb (screen) and resource (a new counterparty, person or company) and scopes it to a single call, which implicitly distinguishes it from the individual screen_sanctions/screen_pep siblings. It does not name any sibling explicitly, so differentiation relies on the reader inferring the aggregation angle.

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

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

Gives clear context: use before onboarding, contracting or paying, and as a first-pass screen before human review. It stops short of naming alternatives (e.g., batch_sanctions_screen for many parties, or the single-purpose screeners), so when-not-to-use is only implied by 'first-pass'.

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

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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint, so the safety profile is covered. The description adds a genuinely important non-obvious behavior: the call returns x402 payment requirements unless payment_signature is supplied, plus the $0.003 USDC-on-Base pricing — a two-phase payment gate an agent could not infer from the schema alone. It omits the actual return content, but the title names the check categories.

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

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

Front-loaded with the core action, then use case, then pricing, then payment mechanics, then a sample link — every sentence is functional. The bracketed "[Data utilities]" tag is the only mildly expendable element.

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, two-parameter checker with no output schema, the description covers the trigger, cost, and the payment-gating flow, which is the behavior most likely to trip up an agent. Only the shape of the returned trust report is left implicit, and the title largely covers that.

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

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

Schema description coverage is 100%, with both the required domain format and the optional payment_signature semantics documented in the schema itself. The description only echoes the payment_signature behavior already stated in the schema, so it adds little parameter-level meaning beyond the baseline.

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

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

The description pairs a specific verb ("Sanity-check") with a specific resource (a vendor's or sender's domain), and the title enumerates the actual checks performed (DNS, Email Auth, TLS, Headers). It distinguishes itself from generic lookup siblings by scoping to pre-trust of an email/link/payment, though it never names the closest sibling (email_verify) directly.

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

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

It gives a concrete trigger: "Use when an unfamiliar domain appears in an invoice, email or supplier record," which tells the agent exactly what situation calls for this tool. There are no exclusions or named 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 cover readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is already clear. The description adds important payment behavior: 'Returns the x402 payment requirements unless payment_signature is given.' This is valuable context not present in annotations. However, it doesn't describe the return format or data freshness, which is a minor gap given the read-only nature.

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 are efficient and front-loaded: the first states the purpose, the second states usage and payment behavior. The sample URL is included but doesn't detract. Could be slightly tighter by omitting the sample reference, but it's useful for developers.

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

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

Covers purpose, usage, and payment mechanics, which are the key requirements for an agent to invoke this tool correctly. With no output schema, the description could say more about the response shape, but annotations and the title already indicate it returns label, recall, and adverse event data. For a read-only tool with full schema coverage and clear payment behavior, it's 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 description coverage is 100%, so both parameters are fully documented in the schema. The description adds no additional parameter syntax or format details beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.

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 verb and resource: checks 'official US label warnings, recalls and most-reported adverse reactions' for a medicine. The name 'drug_safety' and title match, and the specificity (label warnings, recalls, adverse reactions) clearly distinguishes it from any sibling tool, none of which deal with pharmaceuticals.

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?

Provides clear usage context: 'Use when an agent needs citable FDA facts about a drug.' This is a positive when-to-use statement, but doesn't explicitly name alternatives or exclusions. Sibling tools are all unrelated, so no exclusion is needed, but the description doesn't say when *not* to use this tool (e.g., for non-US drugs or general medical advice).

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 read-only/idempotent/open-world profile, and the description adds critical context beyond them: the $0.004 USDC-on-Base x402 pricing and the payment-gating behavior ('Returns the x402 payment requirements unless payment_signature is given'). This is exactly the kind of behavioral trait an agent needs to call the tool correctly and is not derivable 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-loads the category tag and purpose before routing guidance, pricing, and payment behavior. It is dense and largely waste-free, though the list-like stacking of pricing, payment, and sample notes is slightly choppy.

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 5-parameter tool with no output schema and no required params, the description covers purpose, usage context, cost, and the payment gating flow, which is enough to invoke it. It stops short of describing the response payload shape, but the payment-requirements return behavior is at least indicated.

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 five parameters (base, date, amount, symbols, payment_signature) are already documented, establishing a baseline of 3. The description's note about returning payment requirements unless payment_signature is given loosely reinforces that parameter but adds no new syntax or format detail 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?

States a specific verb and resource ('Get an official, citable euro exchange rate') and explicitly frames scope around invoices, ledger entries, and tax returns. It also distinguishes itself from the market-feed alternative, so an agent can differentiate it from sibling data tools 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 when-to-use condition ('when the rate must come from an official source rather than a market feed'). It lacks an explicit when-not or a named sibling alternative, but the official-vs-market distinction is actionable 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 readOnly/openWorld/idempotent semantics, and the description adds genuinely useful context beyond them: the price ($0.0015 USDC on Base, x402) and the payment flow (returns payment requirements unless payment_signature is given). It also reinforces 'no side effects.' It stops short of describing rate limits or the actual verification result 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?

Dense but front-loaded: purpose first, then usage, then price/payment mechanics and a sample link. Sentence count is justified, though the '[Data utilities]' tag and price echo 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 should clarify the return contract. It explains the payment-requirements return path well but never describes the actual verification result (deliverability verdict, disposable/MX flags), so an agent can't anticipate the output of a paid, successful 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 100%, so the schema already defines both parameters, giving a baseline of 3. The description adds meaning for payment_signature by explaining the x402 flow and what happens when it is omitted, plus the batching hint lives in the schema itself.

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

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

States a specific verb (check) and resource (email address) and clarifies the goal (looks real and deliverable), with the title adding the exact checks performed (syntax, MX, disposable, SPF/DMARC). It is unambiguously an email-verification tool, though the description body itself doesn't differentiate it beyond what the title already conveys.

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

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

Gives clear usage context: 'before sign-up, outreach or invoicing' and 'Use when you need a quick check with no side effects.' This tells the agent when to reach for it, but there are no explicit exclusions or named 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 declare readOnlyHint, openWorldHint, and idempotentHint, so safety profile is covered. The description adds critical x402 payment behavior: returns payment requirements unless payment_signature is given, and notes the price ($0.004 USDC on Base). This dual-mode behavior (challenge vs. paid response) is not evident from annotations or schema. Does not describe rate limits or error modes, but adds substantial value.

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

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

Three sentences, each earning its place: purpose, usage scenarios, and payment/return behavior plus sample link. Front-loaded with the core function. No waste.

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?

Complete enough for an agent: purpose, usage context, payment mechanics, and sample path are covered. No output schema exists, so description needn't explain return values beyond the payment-requirements behavior, which it does. Missing only minor details like rate limits or error handling.

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 schema documents all five parameters thoroughly. The description mentions payment_signature behavior and implies query/code usage, but adds little beyond what schema already provides. Baseline 3 is appropriate.

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

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

States a specific verb (find) and resource (HS/commodity code and import duty) with clear scope (goods shipped into UK or US). Distinguishes itself from siblings like screen_export_control and check_eori by focusing on tariff lookups rather than compliance 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?

Explicitly names when to use it: 'when quoting landed cost or preparing a UK or US customs entry'. This gives concrete scenarios that differentiate it from other trade tools. No exclusions listed, but the scenarios are specific enough.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint, idempotentHint). The description adds genuinely useful context beyond them: the $0.001 x402 payment model, the fact that it returns payment requirements unless payment_signature is supplied, and a sample path. It omits rate limits or error behavior, 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 core purpose, then use cases, then the payment mechanics; each sentence carries information. The price appears in both the title and the body, a small redundancy, but overall it is tight and well-ordered.

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 two-parameter, no-output-schema tool this covers purpose, trigger, and the non-obvious payment flow, which is the most likely point of confusion. It does not sketch the response fields (country/network), a modest gap given there is no output schema.

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

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

Schema coverage is 100%, so both parameters — including the batch capability (up to 50 comma-separated IPs) and the payment_signature semantics — are already documented in the schema. The description restates the payment-requirements behavior without adding syntax or format detail beyond it, so the baseline 3 applies.

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

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

The description names a specific verb+resource — 'Find which country and network an IP address belongs to' — and immediately scopes the use cases (fraud checks, geo-compliance, log enrichment). No sibling tool does IP geolocation, so differentiation is 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?

It states a clear triggering condition: 'Use when a decision depends on where a request or login comes from,' plus three concrete scenarios. It stops short of naming exclusions or an alternative tool, but no sibling overlaps, so the gap is minor.

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

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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint, so the safety profile is covered. The description adds real value beyond that: the $0.02 x402 price and the fact that it returns payment requirements instead of data unless payment_signature is supplied — a non-obvious two-path behavior worth disclosing.

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

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

Front-loads the core purpose before pricing and payment flow, and each sentence carries distinct information (purpose, use cases, cost, payment semantics, sample). Slightly dense with commercial/plumbing detail but nothing is wasted.

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

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

With no output schema and all four params documented, the description still conveys purpose, the payment-gated response path, and a sample pointer. An agent has enough to call it correctly; only an explicit alternative-tool routing hint is missing.

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

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

Schema description coverage is 100%, so all four parameters (lei, name, children_limit, payment_signature) are already documented in the schema. The description only echoes the payment_signature gating behavior and adds no syntax or format detail, making the baseline 3 correct.

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

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

States a specific verb+resource ('find out who owns or controls a company') and enumerates the outputs (parent chain, ultimate parent, subsidiaries). Clear, but it never names a sibling such as lookup_company or counterparty_due_diligence to disambiguate the ownership-focused scope.

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

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

'Use for KYB, credit or group-exposure checks' gives concrete usage context an agent can match against an intent. It stops short of naming alternatives or stating when NOT to use it, so it stays at 4 rather than 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 declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds value beyond them by disclosing the cost profile ('Free') and, since there is no output schema, spelling out exactly what each entry contains (job, price, endpoint, inputs, sample URL). It does not mention auth requirements or rate limits, so it falls short of a 5.

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

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

A single dense sentence, front-loaded with the cost signal in 'Free.' and then the core verb and payload. Every clause earns its place; 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?

For a zero-required-parameter listing tool with no output schema, the description compensates well by describing the returned fields and the group dimension, and annotations cover the safety profile. Minor omissions are pagination/response size and any auth expectations.

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

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

Schema description coverage is 100% and the single parameter has an enum, so the schema already fully documents the group filter. The description lists human-readable group names ('Compliance & counterparty', 'Company & tax') that loosely map to the enum values but adds no filtering syntax or behavior 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 names a specific verb (Lists) and resource (all services) and enumerates the four groups plus the returned fields (job, price, endpoint, inputs, sample URL). This makes it unmistakably a catalog/discovery tool, clearly distinct from every query-specific sibling such as lookup_company or check_vat.

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

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

Usage is implied rather than stated: 'Free' plus the full catalog enumeration signals a browse/discovery call, and the optional group filter hints at narrowing results. However, it names no alternative and gives no explicit when-to-use or when-not-to-use condition, so the agent must infer that this is the entry point for exploring available services.

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

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

Annotations cover read-only/idempotent/open-world safety, and the description adds the non-obvious commercial behavior: a $0.02 x402/USDC charge and that the call returns payment requirements unless payment_signature is supplied. That payment gating is exactly the kind of behavioral fact an agent cannot get from annotations or 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-loads the purpose, then usage condition, then the cost/payment mechanics and sample path — every sentence carries distinct information 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?

With no output schema, the description still explains the return behavior for the unpaid case (payment requirements) and the paid case, and all 8 params are optional and self-documented in the schema. It stops short of describing what a successful registry record contains or matching/limit behavior, a minor 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 description coverage is 100% with all 8 parameters documented, including LEI format, fuzzy name ranking, auto-detected query, and jurisdiction codes, so the baseline is 3. The description only touches payment_signature implicitly via the payment-flow sentence and adds no parameter meaning beyond the schema.

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

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

Specific verb+resource with a clear scope: confirm a company exists, is active and is who it claims to be, backed by the title naming the registries (GLEIF LEI, UK, Norway). It does not explicitly distinguish itself from close siblings like counterparty_due_diligence, supplier_check, or sec_company_filings, so an agent must infer the boundary.

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 use context — obtaining an official registry record for a counterparty before onboarding, invoicing or contracting. No explicit when-not or named alternative, so routing against sibling verification tools is left to inference.

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

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

Annotations already declare readOnly, idempotent and openWorld, so the safety profile is covered. The description adds genuinely new behavioral context: the paid x402 flow, the price, and the two-phase invocation where omitting payment_signature returns payment requirements rather than data. It does not cover error handling or rate limits, so it is strong but not exhaustive.

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 front-loaded sentences plus a sample pointer; the purpose and when-to-use lead, and the payment mechanics follow. The price is restated from the title, which is minor redundancy rather than bloat.

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

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

With no output schema, the description still covers the payment-gated return path and points to a sample response, which is the key unknown for this tool. The shape of the actual indicator payload (per-country, per-year values) is only implied via the sample link, leaving a small 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 description coverage is 100%, so the schema already documents years, countries, indicators and payment_signature, including defaults and the omit-to-get-requirements behavior. The description restates the payment_signature consequence but adds no format or constraint 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?

The description states a specific verb and resource ('Get official macro figures for a country') and names the concrete use cases (research, market sizing, country-risk). No sibling tool covers macro/economic indicators, so it is trivially distinguished from the rest of the catalog.

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 an explicit selection condition: 'Use when a figure must be citable to an official source,' which tells the agent when this beats ad-hoc or unofficial sources. It stops short of naming exclusions or alternative tools, but no obvious sibling competes for the same intent.

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

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

Annotations cover read/idempotent/openWorld, so the bar is lower, and the description adds the crucial non-annotation behavior: the x402 payment gate, the $0.005 price, and the fact that it returns payment requirements unless payment_signature is supplied. It doesn't describe the shape of successful paper results or pagination, keeping it from 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 a category tag, then purpose, then the agent trigger, with payment mechanics last. The price appears in both the title and description, a minor redundancy, but overall tight and well ordered.

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 an 8-param, no-output-schema tool, the description covers the critical payment-gated flow and points to a sample for the return format. The only gap is that the successful paper-search response shape isn't characterized, but the sample link offsets this.

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 every parameter (doi, type, limit, query, author, years, payment_signature) is already documented in the schema. The description adds no syntax or format detail beyond what the schema provides, so the baseline 3 applies.

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

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

States specific verbs and resources: 'Verify a citation or DOI, or find research papers on a topic,' and names Crossref as the backing source. No sibling tool covers research papers or DOI resolution, so an agent can distinguish this immediately from the sanctions/company/weather tools.

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

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

'Use when an agent must check that a reference exists and is cited correctly' gives clear usage context and intent. It stops short of stating when to use the doi path vs. the query/author filters, but the primary trigger is unambiguous.

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

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

Annotations already cover readOnly, idempotent, and openWorld, but the description adds genuinely non-obvious operational context: the $0.05 x402/USDC-on-Base pricing and the fact that it returns payment requirements unless payment_signature is supplied. That payment-gating behavior is the kind of detail an agent cannot infer 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-loads the category tag and purpose, then usage, price, payment behavior, and a sample path in compact sentences. Slightly dense but every sentence carries distinct 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 full schema coverage, no output schema, and annotations handling the safety profile, the description covers the remaining gaps: cost, the x402 payment flow, and a sample endpoint. Adequate for an agent 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 limit, lists, since, change_types, and payment_signature are all fully documented in the schema. The description adds no syntax or format detail beyond it, so the baseline 3 applies.

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

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

States a specific verb and resource: 'See what changed on official sanctions lists since your last check.' The delta/change-monitoring framing distinguishes it conceptually from the screening siblings (screen_sanctions, batch_sanctions_screen), though it never names 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 re-screening customers against new designations or monitoring list updates' gives a clear situational trigger. It lacks an explicit when-not or a named alternative, so it stops 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 read-only, idempotent, open-world behavior, so the safety profile is covered. The description adds real context the annotations do not: the x402 payment gate, the $0.02 cost, and the fact that the call returns payment requirements rather than results unless payment_signature is supplied. It still says nothing about rate limits or how results are shaped on a hit.

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 bracketed domain tag and the core action, then layers usage, pricing, and payment behavior in short sentences. Slightly dense with billing and sample-link housekeeping, but every sentence carries information and nothing is buried.

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

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

There is no output schema, so the description carries the burden of describing returns, and it only covers the payment-requirements branch. An agent gets no picture of what a screening result looks like (match records, scores against min_score, list codes), which is the actual payload of a 6-parameter screening call.

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

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

Schema description coverage is 100%, so all six parameters (name, limit, lists, country, min_score, payment_signature) are already documented in the schema. The description adds no syntax or interpretation beyond that, so the baseline 3 applies.

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

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

States a specific verb (screen) and resource (a buyer or consignee against US export-control lists), and the title pins it to the Consolidated Screening List. It is clear what the tool does, but it never names the neighboring screen_sanctions / batch_sanctions_screen tools, and the lists parameter (SDN, SSI) overlaps those siblings, so the boundary is left to inference.

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 a deal may involve US-origin items or technology,' which is genuine when-to-use guidance tied to a business decision. It offers no when-not condition and no named alternative for non-US or sanctions-only checks, so the routing guidance stops one step short of 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 only cover readOnly/idempotent/openWorld; the description adds the material behavioral facts an agent cannot get elsewhere: it costs $0.02 USDC on Base via x402, and it returns x402 payment requirements unless payment_signature is supplied. That payment-gating flow is exactly the kind of non-obvious behavior this field should capture.

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

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

Front-loads purpose, then usage, then price/payment mechanics in four compact sentences with no filler. The '[Compliance & counterparty]' tag and sample path are slightly incidental but cheap, so it stays tight.

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 person-screening tool with no output schema and full schema coverage, the description covers purpose, trigger, and payment flow. It only describes the payment-requirements return path, not the shape of the actual PEP match results (candidate list, match scoring), which is a modest 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?

Schema description coverage is 100%, so all five parameters are already documented in the schema and the baseline is 3. The description only references payment_signature tangentially ('unless payment_signature is given') and adds no syntax or format meaning beyond the schema for name, limit, country, or birth_year.

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 (PEP)') and scopes it to KYC/AML onboarding, so the agent can tell it apart from the sanctions siblings by entity type. It never names screen_sanctions or batch_sanctions_screen explicitly, so the differentiation is conceptual rather than explicit.

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

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

Gives clear trigger context: 'Use when onboarding a customer, director or beneficial owner.' That is a real when-to-use signal, but there are no exclusions (e.g. 'for sanctions lists use screen_sanctions instead') and no prerequisite guidance beyond the payment note.

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 and openWorld, so safety is covered. The description adds genuinely non-obvious behavior: per-call pricing ($0.02 USDC on Base, x402) and the fact that a payment-signature-free call returns x402 payment requirements rather than results. It stops short of describing match-score semantics or rate limits.

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

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

The compliance purpose and when-to-use condition are front-loaded, followed by the payment mechanics and a sample pointer. Every sentence carries information, though the bracketed category tag and price/sample metadata make it slightly denser than a pure task description.

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 an 8-parameter tool with no output schema, the description covers the otherwise invisible x402 payment flow and the conditional return value, which is the highest-risk unknown. Screening semantics and result shape are largely covered by the rich schema, leaving only minor gaps.

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 every parameter including dob, country, min_score, lists and payment_signature is already documented in the schema with defaults and ranges. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb (screen) and resource (customer/supplier/payee against official sanctions lists) with the compliance framing. It does not distinguish itself from close siblings like batch_sanctions_screen, screen_pep or counterparty_due_diligence, so the agent must infer the boundary from the name alone.

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

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

"Use when one party must be cleared before money or goods move" gives a clear triggering condition and the onboarding/contracting/paying context. It offers no explicit exclusions or named alternatives (e.g. batch vs. single screening), so routing between siblings 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 readOnly, idempotent and openWorld, so the safety profile is covered. The description adds meaningful behavior beyond that: pricing per call and the x402 payment handshake, including that the tool returns payment requirements unless payment_signature is supplied. That is genuinely useful operational context not present in the annotations.

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

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

Dense but front-loaded: purpose first, then usage trigger, then pricing/payment mechanics, then a sample pointer. Every clause carries information, though the pricing and sample tokens add minor clutter for an agent whose main job is selection.

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 describing returns and does so ('returns the x402 payment requirements unless payment_signature is given'). Combined with full schema coverage and read-only annotations, an agent has enough to call it correctly, though result shape (fields per grant call) is still unspecified.

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 with defaults and semantics (limit range, status values, payment_signature relay, min_days_to_deadline). The description adds nothing parameter-specific beyond the payment flow already covered, 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 ('Find open or upcoming EU grant calls') and scopes it to a topic fit, which separates it from sibling search tools like search_tenders or search_us_federal_awards. An agent can identify what it returns 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 triggering context ('Use when scouting Horizon Europe, Digital Europe, LIFE, CEF, EU4Health or similar funding'), which tells the agent when this tool is the right pick. It stops short of naming exclusion conditions or an explicit alternative sibling for non-EU procurement, so it 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?

Beyond the readOnly/idempotent annotations, the description discloses non-obvious operational behavior: the $0.03 per-call price, the x402/USDC on Base payment rail, and that the endpoint returns payment requirements unless a payment_signature is supplied. This payment handshake is exactly the kind of trait an agent must know before invoking the 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?

Three tight sentences covering purpose, usage, and payment mechanics, with the core value proposition front-loaded. Nothing is wasted, though the payment and sample pointers make it slightly dense.

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 7-parameter, no-output-schema tool, the description covers purpose, use cases, and the critical payment flow. It does not describe the shape of the returned award records beyond a sample path, but with annotations and a full 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 description coverage is 100% across all 7 parameters, so the schema already carries the parameter documentation burden. The description adds no filter syntax, default values, or format detail beyond what the schema states, 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?

The description gives a specific verb and resource ('Find out who wins EU public contracts') and tags the domain [Procurement]. It implies the distinction from search_tenders by focusing on award winners rather than open opportunities, but it never names that sibling explicitly, so differentiation is left partly to inference.

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 sizing a public-sector market or researching a competitor's contracts' states concrete use cases rather than a vague purpose. However, it offers no exclusions or alternative routing (e.g., when to prefer search_tenders or tender_alerts), so it stops short of full when/when-not 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 only cover safety/openness (readOnly, openWorld, idempotent). The description adds behavior annotations cannot express: per-call pricing ($0.03 USDC on Base via x402) and the critical payment handshake — without payment_signature the call returns payment requirements rather than results. That is exactly the non-obvious behavior an agent must know before invoking.

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

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

Front-loads purpose, then usage, then cost and payment mechanics, then a sample link — four short sentences with little waste. The pricing/payment sentence is dense but earns its place given it is the difference between getting results and getting a payment challenge.

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 covers the one return-value case an agent must anticipate (payment requirements vs. results) and supplies a sample path. Combined with 100%-covered params and annotations covering safety, nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100%, so every parameter including cpv, countries, and min_days_to_deadline is already documented in the schema. The description only echoes payment_signature indirectly ('unless payment_signature is given') and adds no format or default semantics, so baseline 3 is correct.

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

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

States a specific verb and resource ('Find open EU public tenders') plus the scope that matters for selection: open, biddable tenders rather than awards. The word 'open' implicitly separates it from siblings like search_tender_awards, but no sibling is named outright, so it falls short of a 5.

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

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

'Use when building a bid pipeline or sales leads from public procurement' gives a clear use context that an agent can match against a user request. It offers no exclusions or explicit alternative routing (e.g., grants vs awards vs alerts), so it is clear context without the when-not guidance a 5 would need.

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 the description adds genuinely new behavioral context: it is a paid tool ($0.02/call, x402 on Base) and returns payment requirements unless payment_signature is supplied. This payment flow disclosure is valuable beyond the annotation set.

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 [Procurement] tag and the core purpose, then usage, price, payment behavior, and a sample link. Dense but each sentence carries information, 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?

No output schema exists, so the description carries return-value burden and does disclose the payment-requirements response when unpaid. For an 8-param, no-required-param search tool this is largely complete, though it could say more about result shape.

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 8 parameters (days, limit, naics, agency, award_type, etc.) are already documented. The description only loosely references recipient/agency intent and adds no syntax or default detail beyond the schema, so baseline 3 is appropriate.

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

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

States a specific verb and resource: find US federal contracts and grants recipients or what a company was awarded. The US federal / USAspending.gov scope clearly distinguishes it from siblings like search_eu_grants and search_tender_awards.

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

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

Gives clear usage contexts (competitor research, partner finding, US public-sector sales leads), which tells an agent when it fits. It does not explicitly name an alternative or exclusion, so it stops just 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 safety profile (readOnly, idempotent, openWorld), but the description adds non-obvious behavior: the call returns x402 payment requirements unless payment_signature is supplied, plus explicit pricing. That gating behavior is essential context an agent cannot infer from the schema and is genuinely additive.

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

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

Front-loaded with the primary action and scope, then usage, then payment mechanics. The '[Company & tax]' tag and 'Sample: /samples/sec-edgar' are mildly extraneous but the whole thing stays tight.

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 and no required parameters, so the description must convey what comes back and how the payment handshake works — it does both (profile, filings, financials, payment requirements). It omits pagination/limit behavior and error handling, keeping it short of a 5.

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 seven parameters (cik, name, ticker, forms, limit, financials, payment_signature) are already documented. The description adds only the payment_signature gating semantics, which matches what the schema says, so baseline 3 applies.

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

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

States a specific verb+resource+scope: 'Pull a US-listed company's official SEC profile, latest filings and headline financials.' This clearly separates it from generic siblings like lookup_company and counterparty_due_diligence by naming the primary source (SEC EDGAR) and the three payload types.

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 primary-source data on an SEC registrant' gives a clear selection condition tied to data provenance. It stops short of naming an alternative sibling to route away from, so it is not a full 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 safety (readOnly, idempotent, openWorld), so the description's real contribution is the payment handshake: $0.25 per call via USDC on Base x402, and that it returns payment requirements unless payment_signature is supplied. That is behavior an agent cannot infer from annotations or schema, and it also points to a sample. It says nothing about result contents or failure modes, but the paid-call flow is well 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?

The opening and "Use when onboarding or paying a new supplier" restate the same idea, so one full sentence is largely redundant. It is nevertheless short and front-loads the purpose and the routing cue before the pricing details.

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

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

With no output schema, the description should indicate what the compliance check returns (e.g. registry match, sanctions hits, export-control flags). It instead leaves the response shape entirely to the x402 payment requirements note, which is a meaningful gap for a compliance-aggregation tool.

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

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

Schema description coverage is 100% and every parameter has a self-explanatory description (LEI, VAT, EORI, name, country, payment_signature), so the baseline is 3. The description adds no parameter-level detail such as which identifier is most authoritative when several are supplied.

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 new supplier") and the scope of checks in the title (VAT, EORI, Company, Sanctions, Export Control). The "in one call" phrasing distinguishes it as an aggregate check versus the single-purpose siblings like check_vat or check_eori, though it never explicitly names the very similar counterparty_due_diligence.

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 onboarding or paying a new supplier" gives a clear triggering context. It stops short of exclusions or naming alternatives, so an agent choosing between this and counterparty_due_diligence or batch_sanctions_screen gets no routing rule.

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

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

Annotations only cover the safe-read profile (readOnly, openWorld, idempotent). The description adds the non-obvious behavioral layer: paid per-call access at $0.10 USDC on Base via x402, and the crucial flow that it returns payment requirements rather than data unless payment_signature is supplied. That payment/auth behavior is nowhere in the structured fields.

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

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

Five short, front-loaded sentences: what it does, when to use it, cost/payment behavior, then a sample reference. No filler, and the routing information comes before the pricing mechanics.

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 9-parameter, no-required-args read tool with full schema coverage and no output schema, the definition covers purpose, trigger, and payment mechanics. It does not describe the returned notice shape or result limits/ordering, but annotations and the sample path partly cover the 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 description coverage is 100%, with rich per-parameter docs (CPV divisions, Brussels-time since window, ECB conversion for min_value, notice_type semantics), so the schema carries the burden and 3 is the baseline. The description only clarifies the conditional role of payment_signature, adding little beyond what the schema already 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 ('Get the new EU public tenders') plus the defining scope: notices matching a company's criteria since the last check. The incremental 'new since last check' framing cleanly separates it from siblings like search_tenders and search_tender_awards.

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 situation ('daily tender alert or bid-pipeline feed'), which tells an agent when this tool fits. It stops short of naming the alternative siblings (search_tenders / search_tender_awards) or stating when not to use it, so there is no exclusion 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 cover safety (readOnly, idempotent, openWorld), and the description adds substantial context beyond them: the $0.003 price, the x402 payment model on Base, and critically that the call returns payment requirements unless a payment_signature is supplied. That auth/payment flow is exactly the kind of behavioral detail annotations cannot express.

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

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

Purpose is front-loaded, followed by usage, then pricing/payment behavior and a sample reference. Dense but each sentence carries information; the pricing parenthetical and sample path are slightly list-like but not wasteful.

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

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

For a read-only lookup with no output schema, the definition covers the key operational facts: coverage limits, cost, and the payment handshake. It does not sketch the shape of the decoded result, which is a minor gap given no output schema exists to carry that.

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

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

Schema description coverage is 100%, so the schema already documents vin, recalls, and payment_signature fully. The description only reinforces the payment_signature behavior ('Returns the x402 payment requirements unless payment_signature is given'), which is marginal added value over the structured field.

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: identify a vehicle from its VIN and check safety recalls. No sibling tool performs VIN decoding, so there is no ambiguity to disambiguate, and the enumerated use cases (purchase, listing, insurance quote, repair) sharpen the purpose further.

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 selection condition ('Use when a VIN is all you have') and a coverage caveat ('best for US-market vehicles'). No alternatives exist among siblings, so the absence of explicit when-not-to-use routing is acceptable, but it stops short of the full 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 readOnlyHint, openWorldHint and idempotentHint, so the safety profile is covered. The description adds valuable context the annotations do not: the $0.006 per-call price on USDC/Base via x402 and the payment-requirements-returned behavior when no signature is supplied. It does not describe rate limits or response shape, but the payment flow disclosure is a meaningful addition.

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 compact and front-loaded, leading with what the tool returns before giving usage context, price and sample path. Sentences are efficient, though the pricing/payment sentence is fairly dense with x402 jargon.

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 weather lookup, the description covers purpose, use cases, cost, and the payment handshake, which is what an agent needs to invoke it correctly. The lack of any note on return format (current vs. daily fields) is a minor gap given no output schema exists, but the payment flow is fully explained.

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 six parameters are already well documented in the schema (lat/lon alternatives, days range 1-9, country disambiguation, payment_signature semantics). The description adds no parameter detail beyond the schema, 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: 'Get current weather and a 7-day forecast for any city or coordinate.' This is much more specific than a tautology and covers the data provided. It does not, however, distinguish itself from the sibling airport_weather tool, leaving ambiguity about which weather tool to pick.

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?

Provides clear situational guidance: 'before travel, logistics, events or field work' and 'Use when a plan depends on the weather in the coming days.' This gives concrete context for when to reach for it, though it offers no explicit alternatives or when-not-to-use conditions relative to the sibling weather tool.

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