EU Compliance Tools (pay-per-call, x402)

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

With no annotations, the description fully discloses behavioral traits: it is a paid tool ($0.02 per statement), payment method (x402), supported chains (Base, Arbitrum, Polygon, Solana), data sources (USDC payments from Base), conversion methodology (ECB reference rate), and outputs (CSV export, signed receipt). This is unusually transparent.

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

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

The description is dense but efficient, with no filler. The first sentence is long but packs relevant details (source, conversion, grouping, VAT, output). The second sentence adds a clear use case, and the third states cost. All sentences earn their place.

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

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

Given the tool's moderate complexity and lack of output schema, the description provides solid context: purpose, method, output, and cost. However, missing parameter semantics for 'days' and 'format' leaves a small gap for fully autonomous invocation.

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

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

Schema coverage is 0%, and the description only implies that 'wallet' refers to the AI agent's wallet address. It does not explain 'days' or 'format', so agents must guess their meaning from defaults alone.

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 ('Turn an AI agent's own crypto spending into a bookkeeping statement') and resource, then details the process (reads USDC payments, converts to EUR, groups by payee, states VAT treatment). This clearly distinguishes it from sibling tools focused on VAT rules or validation.

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

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

The description gives an explicit use case: 'Use it to make agent micro-payments bookable.' It does not mention exclusions or alternative tools, but the use case is clear enough to guide selection.

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

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

With no annotations provided, the description carries the full burden and does substantial work: it discloses the pricing model ($0.01 per call via x402, USDC on specified chains), the free verification path, the attest-only stance, and the hash-only privacy option. It notes the tool attests origin rather than detecting arbitrary AI. It could add behavior about what happens on payment failure or validation statuses of the disclosure, but covers the essential behavioral traits well for an un-annotated paid tool.

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

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

The description is a single compact paragraph that front-loads the tool's identity and legal context, then moves through inputs, outputs, scope limitations, and pricing. Some redundancy exists with the schema defaults (language default 'en' is evident), but overall every sentence serves a purpose. The pricing and scope caveats are valuable and concise.

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?

Given the tool has 7 parameters, no annotations, no output schema, and zero schema coverage, the description covers the critical context: what the disclosure record contains, the paid/free asymmetry, the invocation paths, and the scope boundary. It lacks detail on output structure (since no output schema exists) and on some parameters, but for a disclosure/attestation tool with clear regulatory framing, it is largely self-sufficient.

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

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

Schema description coverage is 0%, so the description must compensate, and it partially does: it explains the content vs content_sha256 choice (the privacy-first hash-only path), and mentions languages (German and English). However, it doesn't clarify the meaning of other parameters like kind, model, model_provider, deployer, or language beyond the implicit defaults. With 7 parameters and zero schema coverage, the description explains only a subset, leaving several parameters unspecified in meaning.

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 uses a specific verb+resource combination ('EU AI Act Article 50 disclosure for deployers') with precise scoping ('in force since 2 August 2026'). It clearly distinguishes what the tool does — attesting origin and producing provenance records — while explicitly stating what it does NOT do ('we do not claim to detect AI in arbitrary text'). This distinguishes it from any potential sibling involved in detection or compliance verification.

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

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

The description clearly states the tool is for deployers needing EU AI Act Article 50 disclosures and clarifies the intended call context. It provides alternatives ('content_sha256 - the hash-only, privacy-first path') and a clear exclusion (does not detect AI in arbitrary text). However, it doesn't explicitly name sibling tools as alternatives or state when NOT to use it beyond the detection caveat, though among these siblings it's clearly the disclosure-specific tool.

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?

No annotations are provided, so the description carries the burden. It does important disclosure work: states it's a 'Paid tool: $0.02 per check via x402' with payment networks, and describes the output type (traffic-light verdict with reasons and recommendation). However, it doesn't disclose behavioral traits like rate limits, response time, or what failure/mock states look like (e.g., unregistered VAT, unreachable VIES).

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

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

The description is front-loaded with the key value proposition, efficiently lists what the tool does in a single compound sentence, then adds usage and pricing context. It's 3 sentences, each earning its place. Could argue the pricing details could be trimmed, but they're operationally important for a paid tool, so the structure is sound.

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?

The tool is moderately complex (4 inputs, combined checks, traffic-light verdict output). The description covers the main input domains and output format, but no output schema exists to supplement. The country parameter being undocumented and the absence of failure-behavior details make it incomplete for a complex multi-check KYB 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 0%, yet the description only references the parameters indirectly ('validates an EU VAT ID', 'screens the name', 'checks the IBAN'). The 'country' parameter is not mentioned at all, and no format/validation guidance is given for any parameter. With zero schema coverage, the description needs to compensate but only partially covers three of four params, leaving 'country' undocumented.

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 clearly states the tool's purpose: 'Counterparty due diligence (KYB) in one call' with specific verbs and resources (validates EU VAT via VIES, screens against sanctions list, checks IBAN). It distinguishes itself from siblings like validate_vat, screen_sanctions_eu, and validate_iban by being an all-in-one tool producing a traffic-light verdict.

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

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

The description gives explicit context: 'Use before onboarding a new supplier, customer or payee.' This clearly signals when to use it. It doesn't explicitly name alternatives/sibling tools to use instead, but given there's no exclusions and the context is clear, this is close to a 5 but falls slightly short of explicit when-not/alternatives language.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool is paid ($0.02 per call via x402), which is a key behavioral trait. It also clarifies that it 'returns' information, implying no side effects. However, it does not explicitly state whether it is read-only or mention any rate limits or failure modes, but the cost and output transparency add significant 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?

The description is two sentences, with the first sentence densely packing all functional details and the second handling the cost. There is no redundancy or fluff; every word serves a purpose. It is front-loaded with the core functionality, making it easy to scan.

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?

Given that there is no output schema, the description fully enumerates the return values, including place of supply, VAT rate, BT-151, BT-121, bilingual wording, and legal article. It also covers supported standards and input parameters. This makes the tool's behavior and expected results completely clear, leaving no critical 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?

The schema has zero description coverage, so the description compensates by explaining the meaning of all four parameters: supplier country, customer country, B2B/B2C, and goods/service. It does not specify formats (e.g., ISO country codes), but it provides enough semantic clarity for an agent to map inputs. The mention of 'type' defaulting to 'service' further clarifies its purpose.

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 clearly identifies the tool as an 'EU VAT decision engine' for invoices and e-invoicing, listing specific inputs (supplier country, customer country, B2B/B2C, goods/service) and outputs (place of supply, VAT charge, rate, EN 16931 code, exemption code, wording, legal article). It distinguishes itself from sibling tools like validate_einvoice_eu by focusing on decision-making rather than validation.

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

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

The description provides clear context for when to use the tool: when an agent needs to determine VAT obligations for cross-border EU transactions. It implies usage through the listed inputs and outputs, but does not explicitly mention alternatives or exclusion scenarios. This is sufficient for an agent to select it appropriately.

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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It does disclose the paid nature ($0.01 per lookup via x402 with specific blockchains) which is critical behavioral context not available elsewhere. It also mentions the signed receipt. However, it doesn't disclose rate limits, error conditions, or what happens for invalid/immature registrations.

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

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

The description is dense but informative, packed into two sentences with no filler or redundancy. Each clause adds value: countries list, return fields, search methods, and pricing. It could arguably separate or structure the pricing info, but overall it's efficient and front-loaded.

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

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

For a tool with no annotations and no output schema, the description does a strong job covering purpose, supported countries, return fields, search inputs, and cost. The paid-tool aspect and payment rail details are essential context for the agent's decision-making. The main gaps are output formatting specifics and parameter format validation, but given the moderate complexity, the description is reasonably 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 0%, with 3 parameters (country required, id and name optional with defaults). The description explains that 'name' searches by name and 'id' by registration number, adding meaning beyond the bare schema labels. However, it doesn't specify the format/validation of the country parameter (e.g., ISO codes vs. full names) or the format of the id parameter, which the agent would need to construct valid calls.

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 clearly states the tool's purpose with specific verbs and resources: 'Company register lookup straight from the official national registers' and enumerates the exact countries and sources. It distinguishes itself by specifying the exact data fields returned (name, registration number, status, legal form, address, registration date) and the normalized output shape. It clearly differentiates from sibling tools like check_counterparty_eu and screen_sanctions_eu which serve different purposes.

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

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

The description provides clear search criteria ('Search by name (not for PL) or by registration number'), which tells the agent when to supply which parameters. It identifies the countries covered and notes that Poland cannot be searched by name. It doesn't explicitly address when to use this vs. sibling tools like check_counterparty_eu, but the country-list and data-returned detail gives strong context for selection.

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

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

With no annotations provided, the description carries the full burden. It does well: discloses it's a paid tool with the pricing range, funding mechanism (x402), supported chains, explains the scoring rule is disclosed per-response for reproducibility, and clarifies it's computed data not a relay. This is strong behavioral disclosure for a tool with zero 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?

The description is a single dense paragraph covering several topics (what it does, products, pricing, reproducibility). It's reasonably efficient but mixes marketing-style language ('disclosed indicator', 'supply-stress score per growing belt') with functional details, and could be restructured with clear breaks between purpose, products, pricing, and behavior.

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?

Given the tool has only 1 parameter, no output schema, and zero annotations, the description provides meaningful coverage: product enumeration, pricing, chains, payment mechanism, and reproducibility guarantee. The main gaps are per-product output descriptions and more precise parameter semantics, but for a 1-param tool it's fairly complete.

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

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

Schema coverage is 0%, so the description must compensate for the single 'product' parameter. It does enumerate valid product values (market_brief, gas, yield, commodities), which is helpful. However, it doesn't describe the default behavior, what happens if product is omitted, the expected output structure per product, or any constraints on the product values.

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 clearly states the tool computes market/commodity indicators rather than relaying raw data, and lists the product types (market_brief, gas, yield, commodities). The purpose is specific and distinguishable from siblings like market_history, though it doesn't explicitly name a sibling for comparison.

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

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

The description gives usage context (paying for computed indicators, not raw relay), and the sibling list suggests market_history might be the alternative for historical data. However, there is no explicit when-to-use vs when-not-to-use guidance or named alternative tool.

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

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

The description honestly discloses that it's a paid tool ($0.008/call via x402, specific chains/crypto payment methods), which is valuable operational context. It also notes that short series are disclosed honestly. However, with no annotations, it does not cover what happens on payment failure, authentication requirements, or data completeness guarantees.

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 information-dense and front-loaded with the core value proposition first. Each sentence adds meaningful content (uniqueness, products, resolution, honesty, pricing). It could be slightly more structured but remains efficient overall.

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

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

For a 3-param tool with no output schema and no annotations, the description does solid work covering the value proposition, products, resolution, honesty disclosure, and payment. However, it lacks parameter-level documentation for 'days' and full 'product' enumeration, and does not describe the return format or how to interpret the response.

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

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

Schema coverage is 0% and there are no enums, so the description carries the full burden. It explains 'resolution' values ('raw' vs 'daily') and product categories, but 'days' and 'product' semantics are left implicit. The description defines resolution well but doesn't explain the range/meaning of 'days' or the exact valid product strings beyond the four named examples.

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 clearly states this provides historical time series data with specific products (gas, yield, commodities, market_brief), distinguishes itself from upstream providers who only sell current values, and defines resolution options. It clearly differentiates from the sibling 'market_data' tool by emphasizing the historical/time-series nature.

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

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

The description explains the value proposition and what makes this tool unique (own archive of historical data), plus gives some context on when it's appropriate. However, it does not explicitly contrast with 'market_data' or other siblings, nor does it state when NOT to use it in favor of 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?

No annotations are provided, so the description carries the full burden. It discloses substantial behavior: deny-by-default semantics, the three checks performed, signed receipt output, offline verification path, and pricing ($0.02 per decision). This is rich behavioral disclosure well beyond a bare schema. It does not mention error handling or what happens on invalid input, but the coverage is strong given no 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?

The description is compact and front-loaded with the core purpose; every sentence adds value including the deny-default behavior, receipt verification, and pricing. The offline verification install/import snippet is slightly verbose but informative. It's well under the reasonable length though the import example could be trimmed.

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

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

This is a moderate-complexity tool: 6 parameters, no output schema, no annotations. The description covers the decision logic, the default behavior, the receipt auditing, and the cost model, which is reasonably complete for gating usage. However, with 0% schema coverage and 6 parameters, it could have explained the role of amount/country/currency in the decision to be fully complete.

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

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

Schema description coverage is 0%, so the description must compensate for all 6 parameters. The description explains the tool's checks (sanctions, VAT, IBAN) which loosely maps to payee_name, payee_vat, payee_iban, but does not explain individual parameters like amount, country, or currency, or why they matter for the decision. It names the mechanism but doesn't give per-parameter guidance, so it only partially compensates.

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 clearly states a specific verb+resource: screens payee against sanctions lists, validates VAT/IBAN, then answers allow/deny with reasons. It distinguishes itself by being a payment 'gate' that produces a final allow/deny decision with a signed receipt, whereas siblings like screen_sanctions_eu or validate_vat are individual checks. Loses a point because it doesn't explicitly name sibling alternatives to contrast against.

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?

Clear context for when to use: before a payment may go out. Explicitly frames it as the final gate and states deny-by-default, which signals it should be called as a gating decision rather than informational. Does not name when NOT to use it or point to alternatives (e.g., individual validate_vat/screen_sanctions_eu when only one check is needed), so no explicit exclusions.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It discloses that internal/private addresses are refused for safety, that it converts to markdown/plain text, and importantly, that it's a PAID tool with specific pricing ($0.003 per fetch) and payment rails (x402 with USDC on specific chains). This payment disclosure is critical behavioral transparency that would otherwise be invisible to the agent.

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 serving a distinct purpose: function, safety posture, and pricing. Well-front-loaded with the core functionality first. The third sentence about pricing could arguably be trimmed, but the cost disclosure is essential behavioral information that the agent needs before invoking, so it earns its place.

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

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

Given the tool has only 2 simple parameters, no output schema, and no annotations, the description covers the essential ground: what it does, safety constraints, and cost. The description adds necessary pricing context (critical for agents) and the safety posture. It could mention response size limits, timeout behavior, or error handling, but for a simple fetch tool the coverage is reasonably 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 0%, so the description must compensate for explaining parameters. The description explains the `format` parameter implicitly ('markdown or plain text') and gives context for `url` (fetches web pages, refuses internal/private addresses). However, it doesn't explicitly enumerate the format parameter's possible values or explain the default behavior in detail, leaving ambiguity about exact accepted values beyond markdown/plain text.

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 clearly states the tool fetches a web page and returns clean markdown or plain text, with internal/private addresses refused. This distinguishes it from sibling tools, which are all focused on EU compliance, IBAN/VAT validation, and transaction status — none of which read URLs. The purpose is clear with a specific verb+resource, though it could more explicitly contrast with siblings.

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

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

The description positions it as 'a reliable read tool an agent can call before acting on a link,' which gives implied usage context. However, it doesn't explicitly state when NOT to use it or mention alternatives among the siblings (though none obviously compete). The 'before acting on a link' framing provides context but lacks explicit exclusion criteria.

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?

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It thoroughly covers data sources, re-indexing frequency, fuzzy matching, output details, signed receipts, and the paid nature with cost and payment method, which is critical for a paid tool.

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

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

The description is dense but not bloated; it front-loads the core purpose and then packs in essential details about data, matching, results, receipt, and cost. Each sentence adds value, though it is longer than strictly necessary.

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

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

The description explains the return format (list, programme, reference, etc.), coverage, and cost, which is essential given no output schema. However, it misses parameter explanations for country and threshold, making it not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It only explains the 'lists' parameter (eu, un, uk) and does not clarify 'name', 'country', or 'threshold'. The 'threshold' likely controls fuzzy matching sensitivity but is left undefined, leaving a significant gap.

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 clearly states the tool performs sanctions screening (AML/KYC) against three specific official lists (EU, UN, UK), which distinguishes it from sibling tools like check_counterparty_eu or verify_compliance_receipt. The verb 'screening' and resource 'sanctions lists' are explicitly defined.

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

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

The description provides clear usage context (AML/KYC screening) and notes that the optional 'lists' parameter narrows the search, but it does not explicitly mention alternative tools or when not to use this tool. It also mentions the cost, which helps in deciding whether to use it.

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?

No annotations provided, so the description carries the full burden. It transparently discloses that this is a paid tool ($0.002 per call via x402), that it's live with no node needed, and names all 5 supported chains. This is strong cooperative disclosure for a financial-cost tool. The only gap is not describing error behavior or latency, but for a read-only status check this is adequate.

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 dense sentences with zero filler. The description front-loads the core purpose, then chains, then pricing. Every clause earns its place—even the pricing detail is relevant because it warns of financial cost. Could arguably be tightened, but it's efficient for the information density.

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 read tool with no output schema and no annotations, the description covers the business purpose well but leaves gaps. Return format is unspecified (what does the response look like—booleans, balances, both?). Param formats for token/spender/owner aren't given, and there's no guidance on what 'amount' defaulting to 0 means semantically. It's a solid description but not fully complete for a paid chain 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 0%, so the description must compensate. It explains the semantic meaning of owner (holds balance), spender (allowance grantee), and amount (threshold to check) through the framing of 'does this owner hold enough, and has it approved enough'. However, chain, token, and spender formats (addresses? symbols?) and the meaning of 'amount' as a threshold aren't explicitly clarified, leaving ambiguity.

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 clearly states it returns ERC-20 balance AND allowance in one call, specifically answering whether the owner holds enough and has approved enough for a spender. The verb+resource ('balance and allowance from the chain') is specific and distinguishes this from sibling tools like tx_status and market_data which deal with different on-chain concerns.

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

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

The description implies usage context (checking token balance/allowance for a transaction) but doesn't explicitly state when to use this vs alternatives. It names supported chains and mentions it's paid, giving some context, but doesn't offer exclusions or when-not-to-use guidance beyond the implicit scope of ERC-20 tokens.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does this well: it discloses chains supported, pricing ($0.005 via x402 with payment currencies), and that it returns a 'straight send / do-not-send verdict with every reason.' It also notes the simulation decodes revert reasons into plain text. This is strong behavioral transparency for a paid, multi-chain tool.

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

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

The description is a single dense paragraph that front-loads the core question and the six-check list, then appends operational details (chains, pricing). Every sentence earns its place with concrete information: no fluff, no redundant restating of the tool name, and the structure moves from purpose to mechanics to logistics efficiently.

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?

The tool is complex (8 params, 6 checks, multi-chain, paid) with no annotations and no output schema. The description covers purpose, all six behaviors, supported chains, pricing, and payment mechanism thoroughly. The main gap is the unexplained 'spender' parameter and no explicit return-structure detail beyond 'send / do-not-send verdict.' Given the complexity, this is strong but not exhaustive coverage.

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

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

Schema description coverage is 0%, so the description bears full responsibility for parameter meaning. The description adds context for the core parameters: sender, to, token, amount, value_eth, and data all relate to the transaction being simulated, while chain is enumerated. However, 'spender' is not explained in the description, leaving its purpose ambiguous (presumably for the ERC-20 allowance check). Given 8 parameters at 0% coverage, the description helps significantly but leaves spender unexplained, so a 3 is fair.

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 very specific purpose: 'Will this transaction go through?' and enumerates exactly six checks performed (gas vs balance, simulation with decoded revert reason, stuck nonces, recipient type, ERC-20 allowance, sanctions screen). It clearly distinguishes itself from sibling tools like tx_status (which checks a transaction's status) and screen_sanctions_eu (single-purpose sanctions check) by offering a comprehensive six-in-one preflight.

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

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

The description clearly frames when to use it: before spending gas, to get a go/no-go verdict. It lists the six checks, which implicitly tells the agent this is the comprehensive preflight option versus narrower tools like check_counterparty_eu or screen_sanctions_eu. It doesn't explicitly state when NOT to use it or name alternatives, but the six-check scope makes the usage context clear.

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

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

With no annotations provided, the description carries the full burden, and it does a good job: it discloses the paid nature ($0.002/call), the x402 payment mechanism with currency options, and the exact output contents including decoded revert reason. It doesn't mention rate limits or auth setup for x402, but the payment disclosure is a significant transparency win that most tool descriptions omit.

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 tightly packed sentences deliver high information density: output contents, chain support, and pricing/payment. There's zero filler. It could arguably split chains/pricing into clearer subsections, but for the density it achieves, the structure is efficient.

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 transaction-query tool with only 2 parameters and no output schema, the description covers the essentials: input semantics, output fields, chain scope, and cost. It doesn't describe pagination (unlikely needed for a single-tx lookup) or error formats, but the tool's simplicity means the coverage is near-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 0%, so the description must carry semantic weight. It explains tx_hash is the identifier and chain is the network selector with a default of base. The chains list effectively documents the chain parameter's valid values even without enums in the schema. This meaningfully compensates for zero schema coverage.

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 clearly states the verb+resource (status of an on-chain transaction by hash) and enumerates exactly what information is returned: mined/pending state, success/revert with decoded reason, gas used, block, and confirmations. It also lists the supported chains, distinguishing this from sibling tools like tx_preflight (pre-tx check) and token_status (token-focused).

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

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

The description specifies the chains where the tool applies and explicitly notes it's a paid tool with per-call pricing. It gives clear context for when to use it, though it doesn't explicitly name alternative tools for when NOT to use it—but the supported-chains list and paid status provide useful boundary conditions. The price disclosure also helps the agent weigh this against free sibling tools.

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

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

With no annotations provided, the description fully carries the transparency burden. It discloses what the tool checks (mandatory fields, arithmetic consistency, VAT rules), that each finding includes a BR-.. code, that a signed compliance receipt is returned, and that it is a paid tool ($0.10 via x402). This is highly transparent.

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 reasonably concise and well-structured, with the core purpose first, followed by detailed checks and then pricing. Sentences are information-dense 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?

The description covers the tool's purpose, checks performed, output (compliance receipt), and pricing. While it lacks an explicit return schema, it clearly summarizes the output, and the absence of an output schema makes this sufficient. It does not mention error handling or input limits, but these are not critical for this validation 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 0% and the description does not explicitly explain the 'xml' parameter, but with a single required parameter named 'xml' and a description about invoice validation, it is obvious the parameter should contain the invoice XML. The description adds domain context but does not directly elaborate on parameter syntax or requirements.

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 clearly states a specific verb ('Validate') and a specific resource ('an electronic invoice against EN 16931'), listing supported formats. This distinguishes it from sibling tools like validate_vat or verify_compliance_receipt.

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

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

The description provides clear context for when to use the tool (for validating e-invoices under EN 16931) and includes cost/payment details. It does not mention explicit alternatives or exclusions, but the scope is well-defined enough for an agent to select this tool appropriately.

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?

No annotations are provided, so the description carries the full burden. It adds value by disclosing that the tool is free and what it validates (checksum and country structure), but it does not mention output format, side effects, or whether it is purely local validation. For a simple validation tool, this is moderate coverage but leaves room for ambiguity.

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 a single, front-loaded sentence that immediately conveys the free status and purpose. Every word adds value, and there is no redundant information, making it highly efficient.

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?

Given the tool's simplicity (1 parameter, no output schema), the description is adequate but incomplete. It does not explain what the tool returns (e.g., boolean, error details) or behavior on invalid input. For an agent to invoke it correctly, knowing the output would be valuable, but the description stops short of 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?

The schema has one parameter (iban) with no description. The description clarifies that the parameter is an IBAN and mentions the validation logic, but it does not specify format requirements (e.g., spaces, case sensitivity, length). With 0% schema coverage, this partially compensates but is not thorough.

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 clearly states the tool validates an IBAN, specifying the validation aspects (checksum and country structure) and scope (all countries). This distinguishes it from sibling tools like validate_vat and validate_einvoice_eu, which target different entities.

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

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

The description implies use for IBAN validation and mentions it is free and covers all countries, but it does not explicitly state when to use this tool over alternatives or provide exclusions (e.g., 'use validate_vat for VAT numbers'). Sibling names provide some context, but the description itself lacks explicit 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?

With no annotations provided, the description carries the full burden. It adds valuable behavioral context: the tool is free, performs a live check against the VIES register, and returns name/address only when the member state publishes them. This conditional disclosure is important. It does not mention error handling or rate limits, but for a simple validation tool the key behaviors are 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 description is extremely concise and front-loaded with the most important fact ('FREE, no payment required'). It uses two sentences to convey purpose, data availability, and differentiation from paid siblings. Every clause adds value; there is zero fluff.

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

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

For a single-parameter validation tool with no output schema, the description covers the essential context: what the tool does, its cost, the live nature of the data, and the conditional availability of name/address. It also positions itself among siblings. It does not describe the response structure or error behavior, but these are less critical for a simple validate operation, so completeness is high.

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

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

The schema only provides the parameter title 'Vat Id' with no description, and schema coverage is 0%. The description adds the semantic context 'EU VAT ID', which makes clear the parameter is a European VAT identification number. However, it does not specify format requirements (e.g., country prefix) or provide examples, so the agent must rely on general knowledge. The description adds some meaning but does not fully compensate for the lack of schema documentation.

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 ('validate') and direct object ('an EU VAT ID against the live EU VIES register'), and also specifies the result (get registered name and address). It clearly distinguishes itself from sibling tools by positioning as the free entry tool and listing what paid tools add (sanctions screening, counterparty due diligence, VAT rules, e-invoice validation).

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

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

The description provides clear context for when to use this tool (to validate an EU VAT ID and retrieve published name/address) and differentiates it from paid alternatives by explicitly listing what the paid tools cover. It does not explicitly say 'use this instead of X' or provide a strict when-not-to-use, but the positioning is clear enough for an agent to infer the appropriate use case.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does disclose key outputs (authentic, unmodified, valid, signer address) and the free nature, but lacks explicit statements about data handling, read-only status, or potential side effects. For a verification tool, the core behavior is implied, but privacy and processing details remain undertransparent.

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 three sentences, front-loaded with 'FREE, no payment required', and every sentence provides distinct value: what the tool does, how to invoke it, and its use case. There is minimal redundancy, making it concise and well-structured.

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?

Given there is no output schema, the description adequately covers expected returns (authenticity, modification, validity, signer address) and defines the input expectations. It does not mention error handling or edge cases, but for a simple verification tool, the essential information is present. Sibling tool context helps situate it among other EU validators.

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

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

The schema has one parameter (document_json) with zero description coverage, so the description must compensate. It does so by instructing the agent to pass the full JSON result including its 'receipt' field, which adds meaningful semantics beyond the parameter name. While it could include format examples, the guidance is actionable and sufficient for a single parameter.

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 clearly states the tool's function: verifying a compliance receipt issued by eucompliance.tools and returning authenticity, modification status, validity, and signer address. This specific verb-resource pairing distinguishes it from sibling validation tools like validate_vat or validate_einvoice_eu, which target different document 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?

The description provides clear context on when to use the tool: by any third party (auditor, agent) to verify a compliance receipt without trusting or paying the issuer. It doesn't explicitly name alternatives or exclusions, but the context strongly implies it's for receipts from eucompliance.tools only, making usage conditions clear enough.

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