Agent Decision & Evidence Tools (MCP + x402)

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

Beyond the readOnlyHint and destructiveHint annotations, the description adds concrete behavioral details: fixed cost per call, hard input/message/output limits, upstream model disclosure, and a signed receipt in the result. This gives the agent useful expectations for invocation and response contents, without contradicting the annotations.

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

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

Two dense sentences front-load purpose and cost, then cover the prerequisite, limits, disclosure behavior, and receipt. Every clause carries decision-relevant information and there is no filler.

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

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

For a 3-parameter tool with an output schema, the description covers purpose, prerequisite, pricing, hard limits, and response guarantees. It would benefit from explicitly naming the parameters and briefly distinguishing when to use micro/plus, but the essential invocation context 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%, and the description does not explain `prompt`, `system`, or `max_tokens` individually. The OpenAI-compatible framing and hard limits map loosely to `prompt` and `max_tokens`, but `system` is entirely unaddressed, so the description fails to compensate for the missing schema descriptions.

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

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

The description states a specific task ('OpenAI-compatible general chat and summaries'), the exact per-call price, and hard limits, so an agent knows what this tool produces. It identifies the basic tier and the required prepare step, but it does not explicitly contrast with agentllm_micro or agentllm_plus, so sibling differentiation is only implicit.

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

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

It gives a clear prerequisite: 'Run prepare_agentllm with tier basic first.' It also scopes the tool to chat and summaries and provides cost information. However, it does not state when to prefer micro/plus or when not to use this tool, so alternative selection guidance is missing.

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

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

Annotations already signal read-only and open-world behavior, and the description adds valuable context: exact cost per call, OpenAI compatibility, free JSON validation, and no required account/API key. These are meaningful behavioral traits beyond the annotations, especially the billing implication and access model.

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 concise sentences with no filler. Key information—capabilities, cost, compatibility, validation, and auth requirements—is front-loaded and each 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?

The description covers the main purpose, cost, access, and validation workflow, and an output schema exists so return values need not be explained. However, it lacks parameter documentation and explicit guidance on when to choose micro over the sibling agentllm tools, leaving an agent with some ambiguity in a crowded tool family.

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 carries the burden of explaining prompt, system, and max_tokens. It offers no direct parameter info; only the phrase 'OpenAI-compatible' hints at standard chat-completion semantics. Parameter names are somewhat self-explanatory, but this does not compensate for the complete lack of explicit descriptions.

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

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

The description states a specific set of use cases (classification, extraction, routing, short summaries) with a clear resource and cost, making the tool's purpose evident. It does not explicitly name sibling tools like agentllm_basic or agentllm_plus, so differentiation relies on the 'micro' title and the fixed low price rather than an explicit 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 implies usage context: small, cheap, OpenAI-compatible tasks and a free JSON validation step with no account or API key. However, it does not explicitly say when to prefer this tool over agentllm_basic/plus, nor does it state any exclusions or conditions when another tool should be used instead.

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

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

Annotations already mark it read-only and non-idempotent; the description adds valuable behavior beyond that: exact price per call, the mandatory prepare step, hard input/output limits, upstream-model disclosure, and a signed receipt in the result. No contradictions with 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?

A single dense sentence that front-loads the core capability and price, then adds the prerequisite and limits. Every clause earns its place; there is no fluff or rephrasing of the schema.

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

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

Given the output schema covers return shape and annotations cover safety, the description is complete: it states the prerequisite, cost, hard limits, model disclosure, and receipt. An agent has enough to decide and invoke correctly without further lookups.

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 carries the burden, but it does not systematically explain prompt, system, and max_tokens. The 'OpenAI-compatible' label supplies standard API semantics and the hard-limit sentence maps input bytes and output tokens to schema constraints, which is helpful but leaves system and the 16-message limit implicit.

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

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

States it performs OpenAI-compatible drafting, analysis, and longer summaries — a concrete inference capability — and differentiates itself from the basic/micro siblings by branding itself 'stronger' and 'longer.' The tool name and title are reinforced rather than merely restated.

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

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

Gives clear context: use when stronger drafting/analysis/longer summaries are needed and prepays via prepare_agentllm with tier plus first. It does not explicitly name the cheaper siblings as alternatives or state when not to use it, so it stops short of a full when/when-not guide.

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

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

Annotations already establish a read-only, non-destructive operation; the description adds valuable context that transfers are reported unclassified and no tax treatment is applied, so an agent knows the statement is evidence rather than a compliance conclusion. The verb 'Create' could be misread as a write operation, but the rest of the description makes clear it is generating a report artifact, so there is no true contradiction with readOnlyHint.

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 front-load the deliverable and its contents, then add the essential boundary condition about unclassified transfers and tax treatment. Every clause carries information, with no filler, repetition, or restating of annotations.

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 output content, available formats, and the classification boundary, and an output schema exists to document return structure. However, the missing semantics for the days parameter create a real ambiguity about the time window, which is important for an agent deciding whether this tool meets a request for a specific period.

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 the burden of explaining parameters. It partially compensates by identifying the wallet as an agent wallet and mentioning JSON/CSV output, but it never explains the days parameter, its default of 30, or its maximum of 3650. The phrase 'complete ... record' may even mislead an agent into expecting all history rather than a configurable window.

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

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

The description names a specific deliverable: a complete Base USDC outflow and transfer record for an agent wallet, enumerating contents (transfers, recipients, transaction references, dated ECB EUR conversion) and formats (JSON or CSV). It clearly differentiates this from sibling tools like wallet_balance or tx_status, which cover balances or individual transactions.

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 clear context for when to use it—compiling spend evidence for an agent wallet—and explicitly states it does not assign VAT, reverse-charge, or deductible-expense treatment, which is a useful when-not. It does not name sibling alternatives, but the coverage and boundary conditions make the intended use fairly unambiguous.

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

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

The description adds useful behavioral context beyond annotations: the privacy-first hash-only path and the limitation that it attests declared origin rather than detecting AI. The word 'Create' is slightly ambiguous against readOnlyHint, but it reads as generating a returned artifact rather than mutating persistent state.

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 with no filler. The primary action and resource are front-loaded, and the second sentence earns its place by preventing a common misuse case.

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 provides enough domain context for tool selection and communicates the privacy and limitation boundaries. The output schema covers return values and annotations cover read-only/idempotency, leaving only parameter-level semantics underspecified.

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, but it names none of the seven parameters explicitly. 'German/English disclosure' hints at the language parameter and 'hash-only path' hints at content_sha256, but kind, model, deployer, content, and model_provider receive no explanation.

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 concrete action and resource: creating a signed Article 50 provenance record and German/English disclosure for AI-generated content. It also clarifies a non-goal—this does not detect AI in arbitrary content—which meaningfully distinguishes it from other tools.

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

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

The intended use is clear from the first sentence: use this when a provenance/disclosure record is needed for declared AI origin. The second sentence provides an explicit exclusion for arbitrary-content AI detection, though it does not name a specific sibling alternative.

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

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

Beyond the readOnlyHint and destructiveHint annotations, the description adds valuable behavioral context: it explicitly names the external VIES source, aggregates three distinct checks, and discloses that the output is condensed into a traffic-light verdict with reasons and a recommendation. This gives the agent a clear expectation of the tool's behavior and output style. No contradiction with annotations is present.

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 sentence that front-loads the core components and the nature of the result. Every phrase contributes meaning, and there is no padding or repetition of structured data.

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 presence of an output schema covers return-value expectations, but the tool has 8 parameters with zero schema descriptions and the description does not fill that gap. It gives a good high-level summary but is insufficient for confident, correct invocation, especially for business-context parameters like b2b, own_country, and relationship.

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 8 parameters, and the description only indirectly mentions VAT and IBAN. It provides no explanation of b2b, name, type, country, own_country, or relationship, nor their formats, requirements, or interplay. An agent cannot reliably determine how to populate most fields from this definition.

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 what the tool does: it combines VAT ID validation (VIES), sanctions screening, and IBAN check into a single call, producing a traffic-light verdict with reasons and a recommendation. This composition distinguishes it from sibling tools like validate_vat, screen_sanctions_eu, and validate_iban, making its purpose 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?

The phrase 'in one call' implies this tool should be used when a combined KYB/due-diligence check is needed, and the traffic-light verdict suggests it suits holistic assessments. However, the description does not explicitly say when to use this over the individual sibling validators, nor does it state any exclusions or conditions under which separate tools would be preferred.

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

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

Annotations already signal read-only and non-destructive behavior. The description adds useful behavioral context beyond annotations: the response separates the score from extra context, mentions multi-exchange median aggregation, and explicitly states that a still-filling archive is labelled and excluded from the score. No contradiction with annotations exists.

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-loads the main purpose, with no filler. However, its single long sentence with multiple embedded clauses, especially the archive caveat, is somewhat dense and could be more readable if split into two sentences.

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 an output schema exists and the tool has only one optional parameter, the description covers the core calculation, included output context, and an important edge case about the filling archive. It is mostly complete, with the only notable gap being the lack of explicit symbol guidance.

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% for the single symbol parameter, and the description does not mention the parameter at all. The parameter name 'symbol' is self-explanatory, but the description fails to compensate for the low schema coverage, leaving the agent without explicit guidance on what values are accepted or how the symbol relates to the calculation.

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 and resource: 'Calculate a disclosed crowded-long/short score from current Hyperliquid funding and premium.' This is clearly distinct from generic market-data siblings like market_data, perp_market_data, or spot_price, so an agent can tell this tool's unique purpose.

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

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

No guidance is given about when to choose this tool over alternatives, nor are any exclusions or sibling references provided. The intended usage is only implied by the purpose statement, leaving the agent to infer when a crowded-positioning brief is preferred over other market-data 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?

Beyond the readOnlyHint annotation, the description adds that data is 'live' and that the tool does not claim wallet ownership, which is a behavioral limitation. It discloses what is inspected (bytecode, balance, tx count, block) without contradicting 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?

A single dense sentence delivers purpose, inputs, and output classification with no filler. The caveat about ownership is appended without bloating the description.

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

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

The description covers the key behavioral aspects and output classification, and the output schema fills in return-value details. It does not explicitly map the `chain` parameter to network selection, but the enum in the schema makes that unambiguous.

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 burden falls on the description to explain parameters, but it does not mention `address` or `chain` at all. The address format and chain enum in the schema carry the semantics, but the description adds no parameter-level guidance.

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 'Inspect' with concrete resources (runtime bytecode, native balance, transaction count, observed block) and names the exact classification outputs. This clearly distinguishes it from sibling read-only tools like wallet_balance by focusing on classification rather than raw balances.

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 use case is implied through the return values: an address is classified as deployed_contract, eoa_or_empty, or precompile_or_system_address. However, there is no explicit guidance on when to choose this over alternatives like token_status or rpc_read_batch, nor any 'use this instead' 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?

Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context beyond annotations: it discloses that missing evidence is reported rather than inferred, and that some parameters are conditionally required depending on the selected VAT rule. This helps the agent predict the tool's handling of incomplete input.

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 information-dense, with no filler or repetition. The first sentence front-loads the core outputs, and the second sentence covers input requirements and behavioral policy. Every sentence 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 an output schema exists, the description appropriately focuses on inputs and behavior rather than return structure. It covers the main decision outputs, required jurisdictions, conditional evidence, and the no-inference policy. The only notable gap is the absence of any mention of the b2b parameter, which is central to VAT treatment, though its name and default are reasonably self-explanatory.

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 0% schema description coverage, the description must compensate, and it does partially: supplier/customer are characterized as jurisdictions, customer_vat_valid is mapped to 'customer VAT validity', type is glossed as 'transaction type', and above_oss_threshold is glossed as 'OSS-threshold evidence.' However, the b2b parameter is not explained, and the format or expected values of the string parameters are not described.

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 enumerates concrete outputs—place of supply, reverse charge, intra-Community supply/export, rate, VAT category code, exemption reason code, and invoice wording—making it clear this is a VAT decision engine. It could be stronger with an explicit verb like 'determines' or 'calculates,' but the resource and outputs are specific and distinguishable from validation-only sibling tools.

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

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

The description states input requirements and conditional evidence needs, but it does not explicitly say when to prefer this tool over siblings such as validate_vat, check_counterparty_eu, or validate_einvoice_eu. There is no when-not-to-use guidance or reference to alternative tools, leaving the agent to infer selection 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?

Annotations already establish the tool is read-only and non-destructive, so the description does not need to restate safety. It adds useful behavioral context by disclosing the conditional estimate behavior and that excluded rollup components are explicitly stated in the result. No contradiction with annotations exists.

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 entire description is one dense, front-loaded sentence with no redundant filler. Every phrase earns its place by adding conditional behavior, scope, or output nuance.

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 presence of an output schema, read-only annotations, and a simple parameter list, the description covers the core behavior and the key conditional usage. It could be more explicit about which parameters constitute the 'transaction fields' and what 'excluded rollup components' means, but the available schema and annotations fill most gaps.

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

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

Schema description coverage is 0%, so the description should compensate for missing parameter documentation. It only refers generically to 'transaction fields' and does not explain to, data, sender, value_native, or chain semantics, defaults, or formats. This leaves the agent to infer most parameter meaning from names and the schema 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 names a specific verb ('Return'), a clear resource ('current gas price'), and a conditional richer behavior ('eth_estimateGas plus an execution-fee estimate') when transaction fields are supplied. It also adds rollup-specific nuance, making the tool's scope distinct from generic gas tools.

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

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

The description gives clear usage context: call it without transaction fields for the current gas price, or supply transaction fields to get the full estimate. It does not explicitly rule out alternatives or name a sibling like tx_preflight, but the conditional guidance is 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?

Annotations already state readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: the READY_FOR_BUYER_APPROVAL outcome is explicitly limited (does not prove delivery, internal approval, duplicate-ledger status, or bank-account ownership), and the tool costs 1.00 USDC per completed dossier after a free input check. This goes beyond the schema and annotations and helps an agent set expectations.

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 well-structured: it leads with the decision outcome, then input formats, then validation scope, then limitations, then cost/payment. Every sentence carries meaning, though it is a bit long and could be tightened in places without losing value.

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 output schema exists and the 13 parameters are mostly self-describing, the description covers the key behavioral context an agent needs: accepted formats, validation coverage, limitations of a positive verdict, and pricing. It is complete enough for a tool of this complexity, especially with readOnlyHint=true and an output schema 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 explains the accepted input formats (UBL/CII XML or ZUGFeRD/Factur-X with one embedded invoice XML), clarifies the oneOf between invoice_xml and document_base64, and mentions trusted IBAN match, VIES, and VAT treatment. It gives the agent enough context to understand what the key parameters mean even though it doesn't enumerate every 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: it evaluates an EU invoice before payment and returns one of three decisions (READY_FOR_BUYER_APPROVAL, HOLD_FOR_REVIEW, DO_NOT_PAY). It also distinguishes its input scope (UBL/CII XML or ZUGFeRD/Factur-X with embedded XML, not ordinary/scanned PDFs) from sibling tools like validate_einvoice_eu or must_verify_before_pay.

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 input requirements and scoping (accepts structured XML-based invoices, excludes PDFs), and notes a free input check first, which helps an agent decide when to call it. It does not explicitly name alternatives such as validate_einvoice_eu, but its unique decision-output and attached file requirements are sufficient for most selection contexts.

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

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

Annotations already establish read-only, non-destructive, open-world behavior. The description adds that the data is a 'live' extraction from official registers, which is useful, but it does not disclose rate limits, freshness behavior, or any caveats beyond country coverage. No contradiction with 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 two tight sentences with no filler. It front-loads the core behavior, lists countries and fields, and then adds a concise, relevant limitation. Every sentence 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?

With an output schema and read-only annotations, the description covers the main lookup behavior and availability. However, because the schema has zero parameter descriptions and id/name are left unexplained, the overall package is not fully self-sufficient for an agent deciding how to invoke the tool correctly.

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

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

The input schema has 0% parameter description coverage, and the description only implicitly documents the 'country' parameter by listing supported countries. The optional 'id' and 'name' parameters are not explained at all, so an agent has little guidance on how to construct a lookup beyond choosing a country.

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

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

The description names a specific action ('Live extract') and a precise resource: official national registers in six named countries. It also lists the returned fields and explicitly excludes Germany and Austria, which helps an agent distinguish it from broader EU company lookups.

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 clear scope and explicit non-coverage: it is for company register data in France, Norway, Czechia, Finland, Slovakia and Poland, and not Germany or Austria. It does not name an alternative tool such as check_counterparty_eu, but the supported-country list and exclusion effectively 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?

Annotations already cover readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the description only needs to add context beyond those. It adds useful behavioral detail: results are computed, carry source coverage and freshness, provide a stable repeat URL, and include a do-not-repurchase-before time, which clarifies the non-idempotent cache/repurchase semantics. No contradiction with the annotations.

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

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

Two sentences with no filler and the main action is front-loaded. The 'Base gas' phrase creates a slight parse ambiguity, and the long tail of output attributes makes the first sentence dense, so it is not quite a perfect 5.

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

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

With only one optional enum parameter and an output schema available, the description is mostly sufficient for invocation. It covers the key exception (soft commodities) and the unusual repurchase/caching behavior. The main completeness gap is the absence of routing guidance among similarly named market tools, but this is a selection issue more than an invocation issue.

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 provides only an enum for `product` with no descriptions (0% coverage), so the description must compensate. It names all three values (market_brief, gas, yield) and adds 'Base' as context for the gas choice, but it does not explicitly mention the parameter name, default behavior, or what each indicator contains. This is partial compensation, not complete.

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

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

States a concrete action ('Return') and names the exact resource types ('market_brief', 'gas', 'yield') that correspond to the product enum. The sentence also routes soft-commodity requests away to soft_commodity_stress, which helps differentiate from one key sibling. However, 'Base gas' is ambiguous and the description does not distinguish market_data from other market siblings such as spot_price, gas_estimate, or market_history.

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 only explicit usage rule is the final sentence: soft commodities should use soft_commodity_stress. The first sentence implies the tool is for computed fresh indicators, but it never states when to prefer market_data over spot_price, gas_estimate, market_history, or perp_market_data. This leaves selection among the many market-related siblings to inference.

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

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

Annotations already cover non-destructiveness and read-only status. The description adds meaningful behavioral context beyond that: the decision has a 15-minute expiry, includes evidence-coverage confidence, risk flags, and invalidation conditions. This tells the agent the result is time-sensitive and conditional, useful context the annotations do not convey.

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

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

Two tight sentences. The first front-loads the decision output and key metadata; the second enumerates the combined inputs. There is no filler or repetition of the title.

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

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

Given there are no parameters and an output schema is present, the description only needs to convey what the tool decides and what it covers. It names the decision categories, confidence component, risk flags, invalidation conditions, expiry, and the combined market inputs, so an agent can select it appropriately.

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

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

The tool has zero parameters and the input schema is an empty object, so there is no parameter information for the description to add. The description does not need to compensate for schema gaps because there are no parameters.

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 and resource: 'Return ENTER_RISK, WAIT or REDUCE_RISK with score, evidence-coverage confidence, reasons...' This clearly defines the tool's output and decision categories. It also differentiates itself from data-focused siblings like market_data and market_history by stating it combines regime, gas, APY, spot prices, perps, and seven-day history into one decision pack.

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?

There is no explicit when-to-use/when-not-to-use guidance or named alternatives. The phrase 'One call combines...' implies the tool is intended as an all-in-one decision substitute for multiple data calls, but this is left to inference rather than stated directly.

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

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

Annotations already mark readOnlyHint=true and destructiveHint=false; the description goes further by disclosing that fewer than two usable points produce an uncharged error, and that incomplete archives are never sold as a series. This tells the agent that failure modes are billed differently and that results are only meaningful with sufficient data.

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 deliver the core behavior and the key caveat with no padding; the primary action 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?

The output schema exists, so return shape needs no description. Error behavior and minimum-point requirements are covered, but the acceptable product strings are only loosely enumerated, which is a real gap for a string parameter with no enum.

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 must carry parameter meaning. It explains resolution by contrasting raw observations with daily medians and broadly scopes product to gas, yield, commodity, or market-brief. The days parameter remains unexplained, and no concrete product values are listed.

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 ('Return') and a scoped resource: the service's own archived gas, yield, commodity, or market-brief series. Mentioning 'archived' and 'the service's own' separates it from live-data siblings, and 'raw observations or daily medians' states the deliverable clearly.

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?

While the archived-vs-live distinction implies when to reach for this tool, no sibling is named and there is no explicit 'for live prices use spot_price' style guidance. The error condition provides a threshold for when not to trust results, but not which tool to choose instead.

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

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

Annotations already mark the tool as read-only and non-destructive. The description adds meaningful behavior beyond that: 'Deny is the default' and the decision carries a signed receipt, plus the 'live' nature of VIES validation. It does not contradict the annotations.

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

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

Two sentences, zero filler, with the core result ('allow or deny') front-loaded before supporting detail. Every clause adds information.

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

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

The core purpose and required inputs are clear, and the output schema can carry return-value details, but optional parameters remain ambiguous and no alternative-tool routing is provided. Adequate for simple calls, yet incomplete for informed use of all six parameters.

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 0% schema description coverage, the description must compensate for all parameters. It implicitly covers payee_name, payee_vat, and payee_iban through the screening/VIES/IBAN checks, but amount, country, and currency are left entirely 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 is specific: it returns an allow/deny decision before payment, backed by sanctions screening, VIES validation and IBAN evidence. This clearly separates it from sibling validators like screen_sanctions_eu, validate_vat, and validate_iban by presenting it as a composite 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 explicitly states the trigger condition: 'before an agent pays a counterparty'. It does not name alternatives or exclusions, but the context is clear enough for an agent to select it over single-check 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?

Beyond the readOnly/openWorld annotations, the description discloses meaningful behavior: results are returned only when every promised source answers, source failures are uncharged errors rather than partial paid results, and Twitter/X/TikTok are intentionally excluded. This materially informs an agent about failure and billing semantics.

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 no filler. The first sentence identifies the core behavior and source coverage, the second adds critical edge-case behavior, and the third closes with exclusions. Every sentence 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 multi-source search tool, the description covers source selection, query-shape constraints, failure behavior, billing implications, and exclusions. An output schema exists, so return structure need not be described. Minor ambiguity remains around the exact interpretation of 'a single public tag' and how `limit` applies across sources.

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 carry parameter meaning. It does valuable work for `query` by distinguishing phrase search from a single public tag and mapping which sources apply to each. The `limit` parameter receives no prose explanation, but its schema constraints are self-explanatory.

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

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

The description names a specific verb (Search), concrete resources (Bluesky, Hacker News, Mastodon), and explicit exclusions (Twitter/X, TikTok). This makes the tool's purpose unmistakable and distinguishes it from any non-search sibling tool.

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 clear usage context: use for open-network social search, with Mastodon only for a single public tag and not for phrase search. It also states deliberate exclusions, though it does not name an alternative tool for excluded networks.

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?

ReadOnly/destructive hints already signal a safe read, so the bar is lower. The description adds useful behavior beyond the annotations: the result is sourced from Hyperliquid, carries source and timestamp, and can be returned either for one coin or for the top markets by volume. No annotation contradiction.

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?

One dense, front-loaded sentence with zero filler: it states the resource, lists all data fields, explains the two selection modes, and adds return metadata (source and timestamp). 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?

With only two optional parameters, an output schema present, and annotations covering safety, this description is sufficient for an agent to invoke the tool correctly. The main ambiguity (both coin and top provided) is minor given the tool's read-only nature and the 'or' phrasing.

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 prose must define the parameters. It does so by mapping coin to 'one coin' and top to 'the top markets by volume', giving meaning the bare schema lacks. It does not explain interaction when both are supplied, but the either/or phrasing is reasonable.

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 the verb 'Return' and names a concrete resource: Hyperliquid perpetual-futures market data (mark/oracle prices, funding, OI, 24h volume, premium, max leverage). The 'one coin or top markets by volume' scope makes it distinguishable from generic siblings like market_data and spot_price without opening the schema.

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

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

The description implies it is the perp-specific market-data tool and shows how to scope by coin or by top volume, but it never states when to prefer this over siblings such as market_data, spot_price, or coin_positioning_brief, and gives 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?

Beyond the readOnly/idempotent annotations, it discloses deterministic behavior, exact-price routing, absence of model invocation or charging, and a ready_to_buy continuation gate. This materially changes how an agent would use the tool and adds information the annotations do not convey.

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

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

Three sentences deliver the value proposition, tier guidance, and critical behavioral caveat with no filler. Key constraints are front-loaded so an agent can decide without reading deeply.

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 output schema exists, so not describing return values is acceptable, and the description covers cost, determinism, tier choice, and the ready_to_buy gate. It could be more explicit about the subsequent step (calling agentllm_* after ready_to_buy), but that is inferable from 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?

Description explains the tier enum well (Micro for classification/extraction/short summaries, Basic for general chat, Plus for drafting/analysis/longer summaries). With 0% schema coverage, however, it leaves prompt, system, and max_tokens to be inferred from names and defaults, 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 first sentence names a specific action (validates arguments, routes exact price) and resource (all AgentLLM tiers), and the tier list maps use cases. This clearly differentiates it from actual model-calling siblings like agentllm_basic and from prepare_agentllm_micro.

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

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

It states this is a free pre-flight that doesn't call a model and that the caller should continue only when ready_to_buy is true, making the intended use obvious. It does not explicitly name sibling tools as the 'when not' alternative, but the no-call/no-charge framing implies the boundary.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior; the description adds meaningful context by stating it enforces input/output limits and does not call a model or charge anything. This goes beyond the annotations by clarifying side-effect-free validation semantics.

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, front-loaded with the most important fact (free validation), with zero filler. The first sentence states the exact scope and the second explains the behavioral guarantee without repeating the title.

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

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

For a simple 3-parameter tool with an output schema and strong safety annotations, the description supplies the core operational context: what is validated, when it applies, and that it is free/no model call. It does not explain the return shape, but the output schema covers that; no critical gap remains.

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

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

Schema description coverage is 0%, but the description maps the three relevant concepts (AgentLLM prompt, system instruction, token limit) to the prompt/system/max_tokens parameters. It does not add details on defaults, ranges, or formatting beyond what the schema already provides, so it only partially compensates for the lack of per-parameter descriptions.

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

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

The description opens with a specific verb+resource combination: 'FREE validation of the exact AgentLLM prompt, system instruction and token limit before purchase.' This clearly distinguishes the tool from paid or model-calling siblings like agentllm_basic/agentllm_micro by emphasizing it is a no-cost pre-purchase validation step.

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

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

It gives a clear context: use this before purchasing/using AgentLLM to validate limits, and it explicitly states no model call or charge occurs. It does not name sibling alternatives or state when not to use it, but the 'before purchase' condition is enough to route an agent 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?

Beyond the annotations (readOnly, idempotent, non-destructive), the description adds significant behavioral detail: it is free, local, checks format/limits/context, does not perform VIES/sanctions lookups, does not return the paid decision, and is subject to daily abuse protection. This gives the agent a clear safety and side-effect profile.

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. The core value proposition ('FREE local input and safety check before purchase') is front-loaded, followed by input requirements, behavioral limits, and rate-limit note. Every sentence 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's complexity (13 parameters, oneOf input, output schema), the description does a good job covering input formats, required parameters, behavioral boundaries, and rate limiting. It falls short only in not explaining optional parameters and not explicitly routing to siblings, but the output schema covers return values and the annotations cover safety.

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 two input alternatives (invoice_xml vs document_base64), the ZUGFeRD/Factur-X requirement, and names the four required parameters. However, it does not describe optional fields like b2b, supply_type, expected_buyer_vat, expected_supplier_vat, expected_supplier_name, or purchase_order_reference, leaving their meaning and use unclear.

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 a free local pre-purchase safety check for EU invoices, naming accepted formats (UBL/CII XML or embedded XML in PDF) and required context. It also distinguishes itself from paid decision tools and external vetting by stating it does not reveal the paid decision or query VIES/sanctions.

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 tool is intended 'before purchase' and clarifies what it is not for: it does not reveal the paid decision or query VIES/sanctions. This gives useful context for choosing it over siblings, though it does not explicitly name alternative tools or provide a clear when-not-to-use condition beyond these 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 readOnlyHint, openWorldHint, idempotentHint, and destructiveHint already declared, the description adds useful behavior context: the check is local and free, does not fetch URLs, requires explicit regulated-attribute answers, and yields an opaque job ID plus recovery secret. No contradiction with annotations; it stops short of discussing rate limits or failure modes.

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 tightly written sentences: the first front-loads the purpose and scope, the second lists requirements, a key exclusion, and the output. Every clause adds information without repeating schema or annotation content.

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

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

For a complex 16-parameter tool, the description covers what it does, the geographic scope, the key input categories, the no-URL rule, and the output shape, which is sufficient given an output schema exists. It could be more explicit about the fact that the free check does not return a final compliance verdict and how the recovery secret is later used, but these are minor gaps.

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

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

Schema description coverage is only 19%, so the description has to compensate. It groups the required inputs into 'product, material, intended-use, origin, value and explicit regulated-attribute answers' and adds the no-URL constraint, which is helpful. It leaves many parameters (importer_use, merchant_forwarding_policy, quantity, dispatch country, etc.) to be inferred from enum names, so the guidance is adequate but not comprehensive.

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

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

The description names a concrete action and resource: a 'FREE local completeness and safety check' for US import readiness from DE/AT. It differentiates itself from sibling tools by explicitly rejecting product URLs and by describing its output as the precursor to the paid guard, so an agent can distinguish it from read_url and us_import_readiness_guard.

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 clearly scopes usage to ordinary goods dispatched from DE/AT to the US and states the tool will not accept or fetch a product URL, which functions as an exclusion. The mention of an output 'for the paid guard' implies it is the preparation step, but it does not explicitly name the sibling tools or state when to prefer recover_us_import_readiness.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description adds meaningful behavioral context beyond that: it is free, performs only strict syntax/shape validation, returns a canonical fingerprint and policy fields, and explicitly does not contact the target, read a wallet, or attempt payment. This gives the agent a clear safety and side-effect profile.

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

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

A single dense sentence communicates the tool's purpose, scope, limitations, and outputs without redundancy. Every clause earns its place, and the most important qualifier ('FREE') 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?

With only one parameter, a rich output schema, and annotations covering safety and idempotency, the description is complete for correct invocation. It also clarifies the relationship to the paid guard and lists key behavioral boundaries, leaving no critical gap for an agent deciding whether to call this tool.

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

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

Schema description coverage is 0%, so the description must compensate. It does by specifying that 'payment_required' is the raw base64/base64url PAYMENT-REQUIRED header, which explains the expected format and meaning beyond the schema's bare string field. It stops short of detailing edge cases like expected header prefix handling, but for a single parameter this is adequate.

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 a specific verb ('check'), a specific resource ('raw base64/base64url PAYMENT-REQUIRED header'), and the distinguishable scope ('FREE strict syntax and supported-v2-shape check'). It also differentiates itself from the paid guard by stating it does not reveal the paid decision, which is a clear separation from sibling x402_purchase_guard.

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 when to use this tool: it produces 'the policy fields required by the paid guard,' so an agent can infer it is a preliminary/free preparation step. It also lists exclusions ('without contacting the target, reading a wallet or attempting payment'), but it does not explicitly state 'use this before x402_purchase_guard' or name exact alternative conditions.

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

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

Beyond the readOnlyHint and destructiveHint annotations, the description discloses a key behavioral guardrail: it refuses internal and private addresses. It also states that the output is a cleaned Markdown or text representation, which tells the agent what kind of content to expect. This adds meaningful behavioral context beyond the annotations.

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

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

A single sentence that front-loads the core action and output format, then adds the safety constraint and usage context. Every clause earns its place with no redundancy 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?

For a simple two-parameter fetch tool with a rich annotation set and an output schema, the description covers the essential operational context: what it fetches, what it returns, what it refuses, and when to use it. Nothing critical is missing for an agent to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It effectively maps 'a public web page' to the url parameter and 'Markdown or text' to the format parameter, while adding the 'clean' transformation detail. It does not explicitly mention the format default, but the schema already declares that, so the description provides adequate semantic support.

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 ('Fetch'), the resource ('a public web page'), the output format ('clean Markdown or text'), and a distinctive safety scope ('refusing internal and private addresses'). This makes it immediately distinguishable from the many finance and compliance-focused siblings in the tool list.

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 phrase 'suitable for reading evidence before an agent acts on a link' provides a clear and concrete usage context. It does not name an alternative tool or explicitly say when not to use it, but the context is strong enough 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?

The description goes well beyond the annotations by disclosing that it performs no model call, network lookup, payment, or target-tool execution, and never returns supplied secret values. This gives the agent a precise safety and side-effect profile that annotations alone do not convey.

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

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

Two tight, front-loaded sentences convey the tool's role, invocation pattern, output shape, and behavioral guarantees without redundant or vague filler. Every sentence 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?

The description, combined with the output schema and annotations, gives the agent enough to select and call the tool correctly: what it does, what filters it accepts, what it returns (one to three tools with exact prices, required inputs, and a safe workflow), and what side effects it avoids. The short output schema also removes the need to document return fields in prose.

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 only 13%, so the description must compensate, and it does partially by naming category, country, chain, price cap, and available input names. It also adds the important semantic rule that available input names are supplied without their values, though max_results and prefer_free are only implied rather than explicitly described.

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-resource relationship: it is a deterministic router over the published Agent Card that returns one to three matching tools. It clearly differentiates itself from the many sibling tools by describing its meta-selection role rather than a domain-specific operation.

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 clear invocation context: describe the job and optional category, country, chain, price cap, and available input names. It does not name explicit alternatives or state when not to use it, but its router-over-Agent-Card framing makes the intended triggering condition reasonably clear.

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

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

Annotations already communicate read-only, idempotent, non-destructive behavior, and the description adds context beyond those: it returns only the already-settled result, involves no new charge, and is free recovery rather than a fresh operation. It stops short of describing behavior on invalid secrets or missing recovery data, but the annotation coverage lowers the burden.

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 no filler. It front-loads the most decision-relevant facts: free recovery, the exact condition, what is returned, and what is explicitly not done.

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 simple two-parameter shape, the read-only/idempotent annotations, and the presence of an output schema, the description covers the essential behavior and boundary conditions. An agent selecting among many siblings has enough context to invoke this tool correctly without additional detail.

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 meaning for the parameters. It does so by identifying both parameters together as the 'opaque job ID and recovery secret' tied to the already-settled result. While it doesn't elaborate on the recovery_secret format or where these values come from, the phrasing gives enough role context for the two self-named parameters.

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 ('recover') and a precise resource ('settled US Import Readiness result') and defines the exact trigger condition: an x402 settlement succeeded but the signed response was lost. It also explicitly distinguishes itself from a fresh lookup by saying it 'never performs a new lookup or creates a new charge.'

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 says when to use the tool: when an x402 settlement succeeded but the signed response was lost. It also provides a strong when-not signal by stating it never performs a new lookup or creates a new charge, which guides an agent away from using it for new readiness checks.

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

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

Annotations already set readOnlyHint=true and destructiveHint=false, but the description adds meaningful behavior beyond that: the call is paid, it supports public-node failover, it returns decoded Error/Panic reverts and source evidence, and it refuses state-changing methods. This materially changes what an agent should expect from invocation. It does not contradict the annotations. Minor gaps remain on rate limits and cost structure, keeping it from a 5.

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

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

Three tight sentences with zero filler. The core action and scope are front-loaded, the chain-configuration rule follows, and the final sentence packs features and exclusions without redundancy. Every clause earns its place and nothing repeats the schema verbatim.

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 40-sibling toolset with a complex batch input and an output schema present, the description covers the essentials: chain span, batch size limits, cost, chain override mechanics, failover behavior, revert error decoding, and unavailable operations. Gaps are the unenumerated method allowlist, the vague 'source evidence' phrase, and absent cost/rate-limit details, but the output schema carries return-value documentation.

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

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

Schema coverage is roughly 50%, and the schema itself already documents chain, id, method, params, and jsonrpc with usable descriptions. The description adds genuine composite semantics — the default-chain-plus-per-request-override mental model and the allowlist framing — which helps an agent craft a correct batch. However, it doesn't elaborate individual parameter details beyond what the schema states, so a 3 (baseline-plus) is appropriate.

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

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

The description opens with a specific verb and resource: 'Run 1-20 standard read-only JSON-RPC requests as one paid call across 28 EVM mainnets.' This precisely scopes what the tool does and distinguishes it from specialized single-purpose siblings like tx_status, wallet_balance, and market_data, which are all singular reads rather than a multi-chain batch RPC facility.

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