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

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly: hard input/output limits, non-streaming behavior, no hidden system prompt, response contents, and exact payment terms are all disclosed. The mention of a signed receipt and a fixed USDC payment is particularly valuable for an agent deciding whether to call this 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 every clause earns its place: purpose, prerequisite, limits, streaming behavior, response contents, and pricing are all included without filler. The semicolon-separated structure makes the constraints 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?

The description is largely complete for a small inference tool given no output schema and no annotations: it explains preparation, hard limits, output characteristics, and payment mechanics. It could add a bit more about the exact response payload or failure behavior, but the essential call-time guidance is present.

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

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

The schema gives no parameter descriptions, so the description must compensate. It usefully adds hard input size and output token limits and clarifies the no-hidden-system-prompt stance, but it does not explicitly explain the relationship between prompt, system, and max_tokens beyond what the schema already implies.

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 AgentLLM Micro as an OpenAI-compatible text inference tool for concrete tasks (classification, extraction, routing, short summaries), so an agent can recognize both the resource and the job. It also distinguishes itself from the sibling preparation tool by explicitly saying to run prepare_agentllm_micro first.

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 when-to-use context through the listed task types and provides a critical prerequisite: run prepare_agentllm_micro with identical arguments first. It does not discuss exclusions or alternative LLM tools, but no other LLM sibling exists, so the guidance is sufficiently 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, 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?

With no annotations provided, the description carries the full behavioral burden and does unusually well: it discloses the per-dossier cost, the x402 payment mechanism, the no-subscription model, the critical-source-failure MCP error behavior, the trust boundary ('IBAN ownership is not claimed; missing evidence is never approval'), and the scope boundary of READY. The only untold behavioral trait is what happens if the tool is re-invoked with the same invoice after a dossier already paid.

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 first sentence is a sharp executive summary, and the structure is front-loaded: purpose, outputs, checks, input constraints, exclusions, prerequisite step, error handling, pricing. It is dense but each clause carries information not present in the schema or annotations. The safety-caveat clauses ('Missing evidence is never approval; IBAN ownership is not claimed') add genuine behavioral specificity rather than padding.

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?

In a tool with 13 parameters, no annotations, no output schema, and 0% schema description coverage, this description manages to cover the decision values, the return payload (reason codes, evidence, timestamps, safe next actions, signed receipt), accepted input formats, failure-to-error mapping, and cost. The remaining gaps are the invoice encoding parameter ambiguity and the unexplained b2b, supply_type, and purchase_order_reference fields, which are material at this coverage level.

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 does explain trusted_payee_iban ('match against the buyer's trusted payee IBAN'), infers the expected_* parameters through the amounts/VAT/supplier checks, and describes the accepted invoice formats (UBL/CII XML, ZUGFeRD/Factur-X with one embedded XML). However, it leaves the three encoding parameters (invoice_xml, document_base64, filename) ambiguous and says nothing about b2b, supply_type, purchase_order_reference, expected_supplier_name, or expected_buyer_vat.

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

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

The description opens with a specific verb-resource ('one signed decision before an EU invoice is paid') and names three exactly defined outcomes (READY_FOR_BUYER_APPROVAL, HOLD_FOR_REVIEW, DO_NOT_PAY). It enumerates the combined checks (EN 16931 validation, totals/VAT arithmetic, live VIES, EU/UN/UK sanctions, VAT treatment, trusted IBAN match), which clearly separates it from the component sibling tools like validate_einvoice_eu, validate_vat, screen_sanctions_eu, and validate_iban.

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

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

The description gives explicit sequencing guidance: 'Run the free prepare_invoice_to_pay_eu tool first', plus a precise context ('before an EU invoice is paid'). It also states clear when-not conditions: no ordinary/scanned PDFs, no delivery/internal approval/duplicate-ledger assertions under READY. It stops short of naming alternatives for those exclusions, which keeps it a 4 instead 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?

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?

With no annotations, the description carries the full weight of behavioral disclosure. It explicitly states that the tool does not call a model or charge anything, and it names the exact checks (2,400 UTF-8-byte limit, 8-message limit, 300-output-token limit). It doesn't describe error behavior or return structure, but the 'ready_to_buy' gate is a meaningful behavioral clue.

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 with no filler; it defines the purpose, the parameter expectations, and the decision rule to continue to the sibling. Every sentence contributes necessary information and the core behavior is 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?

Given no output schema and no annotations, the description provides the essential operational details: what to supply, what is checked, and what to do after (proceed only when ready_to_buy is true). It is slightly ambiguous about where ready_to_buy comes from but sufficient for an agent to invoke and interpret partially.

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 covers all three parameters: 'the exact prompt' (prompt), 'optional system instruction' (system), and 'max_tokens.' The mention of the 300-output-token limit adds context to max_tokens beyond the raw 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 opens with a specific, actionable purpose: 'FREE request validation before buying AgentLLM Micro.' It explains it validates prompts against explicit limits and clearly distinguishes itself from the paid sibling agentllm_micro by framing this as a pre-purchase gate.

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 indicates exactly when to use this tool ('before buying') and instructs to proceed to agentllm_micro only when ready_to_buy is true, effectively naming the sibling and the activation condition. It doesn't list alternative scenarios or explicitly state when not to use it, but the usage context is strong.

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 disclosure burden and meets it thoroughly: it discloses pricing behavior ('Unreadable or incomplete input is never charged'), rate limits ('subject to daily abuse protection'), what it checks (format, limits, input sufficiency), what it intentionally hides ('does not reveal the compliance decision'), and format limitations (only UBL/CII XML or ZUGFeRD PDF). These are genuinely useful runtime-behavior traits beyond what the schema could ever 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?

Every sentence earns its place: format, required data, check scope, non-disclosure, exclusions, routing, pricing, rate limiting. The key 'free' and 'before' framing is front-loaded. It is slightly dense as one wall of text and repeats the 'free' concept three times, but it is efficiently packed and flows from what→how→when→caveats.

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 output schema and no annotations, the description is strong: it explains the flow, the eligibility flag, the charging rule, and the format restrictions. It does not describe the return shape beyond 'eligible' (e.g., status codes or validation reason fields), and it ignores several optional parameters; still, the core context needed to invoke it safely is present.

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

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

Schema description coverage is 0%, so the description must compensate. It adds semantic context for roughly half the parameters (UBL/CII XML for invoice_document, base64 XML/ZUGFeRD PDF for document_based64, trusted IBAN from buyer master data, plus the four required fields). However, seven inputs are left undocumented (e.g., purchase_order_reference, supply_type, b2b, expected output_vat, unicode_legal_name), and the string types of expected_amount/expected_currency get no format/no-comma guidance. Meaningful but incomplete 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 states a specific function: a 'FREE input and safety check before' the paid EU Invoice Payment Guard flow. It names the resource ('EU Invoice Payment Guard'), the activation/modifies it can result in ('If eligible=true, call invoice_to_pay_dossier_eu'), and clearly distinguishes itself from siblings by stating what it does not do ('does not reveal the paid compliance decision'). This is a specific verb+resource+scope combination that differentiates it from the paid counterpart.

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

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

Explicit routing guidance: 'If eligible=true, call invoice_to_pay_dossier_eu with the same inputs', plus an explicit exclusion ('Ordinary and scanned PDFs are not supported') and the positioning as a pre-buy check. It does not explicitly tell the agent when to use a different free sibling (e.g., validate_iban / validate_vat instead), which leaves a small ambiguity, so the 'when-not' guidance is not fully 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?

No annotations are provided, so the description carries the full burden. It discloses that this is a free, local input and safety check, and that it returns an opaque job_id and recovery_secret. However, it does not explicitly state whether the tool persists data, has side effects, or what happens on failure (e.g., if ineligible). The term 'prepare' implies some record creation, but this is not articulated, leaving behavioral transparency moderate.

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 dense but well-organized paragraph (~90 words). It frontloads the purpose, then lists inputs, constraints, outputs, and usage instructions. No redundant sentences; every clause adds information. It is concise for a tool with 16 parameters, though it could be slightly more compact.

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 high complexity (16 params, nested risk_answers object) and absence of an output schema, the description covers the essential aspects: what the tool does, what it accepts, what it returns, and how to use the result with sibling tools. It lacks details on error conditions (e.g., what makes an item ineligible) but provides enough for an agent to decide whether to call it and what to expect. This is adequate for a preparation 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?

With schema description coverage at 0%, the description compensates by naming the key inputs: manufacturing origin, product/material/use, customs value, quantity, importer use, merchant forwarding policy, and explicit yes/no/unknown answers. It also scopes dispatch and destination countries. It does not define each parameter's exact meaning but covers all required ones, and clarifies that URLs are not accepted. This adds meaningful guidance beyond the raw 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 clearly states the tool's function: a free pre-check for the US Import Readiness Guard. It specifies the exact inputs required and the output (job_id and recovery_secret). It also explicitly differentiates from the sibling tools us_import_readiness_guard and recover_us_import_readiness, making the resource and action 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 explicitly instructs when to use: 'before buying the US Import Readiness Guard' and 'Use both with the same facts in us_import_readiness_guard.' It also clarifies what it does not do ('No product URL is accepted or fetched') and mentions the recovery scenario, effectively guiding the agent on when to call this vs. the recovery tool. This is explicit and actionable.

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?

With no annotations, the description carries the full burden. It discloses that this is a recovery (not a new lookup), that it guarantees a settled result, and that it's free. These are meaningful behavioral guarantees beyond the name. It doesn't detail failure modes, but for a recovery tool these disclosures are substantial.

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

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

Two sentences, no fluff. The key purpose is front-loaded, inputs are stated, and behavioral constraints are given. Every clause earns its place.

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

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

For a recovery tool with only two parameters and no output schema, the description covers purpose, inputs, and behavioral guarantees. It implies the return value is the original result (by saying it 'recovers' and 'never returns an unsettled result'). It could mention error handling, but it's adequate without it.

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

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

Schema coverage is 0%, so the description must explain the parameters. It states that job_id is an opaque job identifier and recovery_secret comes from the free prepare call, providing critical context about their origin. It doesn't specify formats or error behavior, but it compensates for the empty schema better than most.

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 verb (recover), the resource (a US Import Readiness Guard result), and the specific condition (x402 settlement succeeded, response lost). It also explicitly distinguishes itself from siblings by stating it never performs a new lookup and never returns an unsettled result, making it unambiguous which tool this 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?

The description states the prerequisite inputs (job_id and recovery_secret from the free prepare call) and the exact scenario where it applies (settlement succeeded but response lost). It stops short of explicitly naming an alternative tool for new lookups, but the contrast 'never performs a new lookup' 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?

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?

No annotations exist, so the description fully carries the behavioral disclosure burden. It explicitly states 'Read-only, no transaction broadcast and no follow-up charge', explains that missing evidence is never treated as approval, and discloses that it is a paid tool. This gives an agent a reliable understanding of side effects, costs, and trust boundaries.

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 organized: purpose, check list, returned information, safety guarantees, supported chains, pricing. Each sentence earns its place. It is a little long and packs many facts into one paragraph, but nothing here is wasted or 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 what the tool does, what it returns (decision, evidence, unknowns, limitations, safe next actions), supported chains, cost, and safety profile. The main gap is that the eight parameters are not individually explained and there is no output schema to compensate. Still, for a preflight utility the description is largely sufficient for an agent to select and attempt a 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?

The schema has zero description coverage, so the description is the only source of semantic cues. It does connect parameters indirectly: 'gas vs balance' implies value_eth/chain, 'ERC-20 allowance' implies token/spender/amount, and 'recipient' implies to. However, it does not clarify fields like whether amount is a decimal amount, how data and value_eth interact, or the exact token address format. This is partial compensation rather than full parameter 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 is immediately specific: it defines the tool as a transaction guard deciding whether an agent should proceed, review, or block, and enumerates the six checks it performs. It clearly distinguishes itself from transaction status or single-domain check tools by combining multiple preflight checks in one call.

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 states clear context for use: run this 'before any gas is spent' and when an agent needs to know whether to proceed with a transaction. It also notes the tool is read-only and does not broadcast, which helps avoid misuse. It does not explicitly name sibling alternatives or describe when-not-to-use cases, 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?

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?

There are no annotations, so the description carries the full responsibility. It is highly transparent about the cost (0.25 USDC via x402), about non-binding/non-authoritative behavior, about the error semantics ('invalid input or official-source failure is an MCP error and is not settled'), about the limited ordinary-duty calculation, and about the three distinct result states. This is unusually honest and useful for an agent deciding what to in-authenticate.

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 rather than structured bullets, but every clause contributes distinct information: the product, the process, the non-goals, the precondition, the failure mode, and the pricing. It earns its length given no annotations and a complex paid API, though a more structured layout would improve scanability.

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 does explain the main workflow, expected outcomes, cost, and failure mechanics, which is good. However, with 18 input parameters and no output schema, it still leaves out crucial operational details: what values merchant_forwarding_policy can take, how job_id and recovery_secret are obtained beyond 'run prepare first', and whether other required fields are restricted. For a paid tool with this complexity, the agent would still have to guess about several important execution details.

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% across 18 parameters, and the description does not compensate. It explains the role of hts_code and risk_answers, but it does not explain job_id, recovery_secret, importer_use, merchant_forwarding_policy, customs_value_usd, or other fields. Without these meanings, the agent still must rely on parameter names alone, which is not sufficient for many of those fields. Some self-explanatory fields help, but a 2 is appropriate because the description leaves the bulk of 18 parameters unexplained.

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

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

The description gives a specific verb and object pair -- it validates/computes a signed US import readiness dossier -- and clearly delineates its scope: Germany/Austria to the US, ordinary goods, simple duty, CPSC checks, and three outcome values. It also distinguishes itself from the sibling tool by saying 'Run the FREE prepare_us_import_readiness tool first' and naming what it deliberately does not cover.

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 explicitly states that prepare_us_import_readiness must be run first, which is a clear and useful precondition. It also tells the agent what this tool does not do (quote shipping, guarantee importability, place orders, etc.), clarifying when it is not the right tool. It does not, however, mention or contrast other siblings such as recover_us_import_readiness, so the guidance is strong 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?

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?

With no annotations present, the description carries the full disclosure burden. It goes beyond the tool name by revealing that registry data is not always available and explicitly warns that it 'never proves account ownership or existence'. This is valuable, well-communicated behavioral context.

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

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

Two dense sentences contain all key information: free access, validation scope, registry-linked BIC/bank lookup, and an important limitation. The content is front-loaded and there is almost no wasted text.

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 one-parameter tool without an output schema, the description does a solid job: it explains what will be validated, what extra data may be returned, and a critical limitation. The main remaining gap is an explicit statement of the output format or return contract, which the agent has to infer from the validation context.

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 describes only 'iban' as a string with zero description coverage, so the description must compensate. It names the content of the parameter implicitly ('validate an IBAN'), but it does not specify expected formatting (spaces, uppercase, country prefix) or acceptable variants. It adds some but not full 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?

The description states a specific verb ('validate') and resource ('IBAN'), scopes it to 'checksum and country structure, all countries', and adds a secondary behavior ('identify BIC/bank name where the local registry has data'). This clearly distinguishes it from siblings like validate_vat or validate_einvoice_eu.

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 makes the usage context clear: this is a free, full-country IBAN validation tool that may also return BIC/bank info. It does not explicitly name when to prefer an alternative, but 'validate an IBAN' plus 'all countries' gives the agent enough context to choose it over VAT/company/entity 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 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.