Sirenic

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

Annotations already declare readOnlyHint and openWorldHint. The description adds value by stating the data is official AMF open data refreshed daily, and notably discloses the x402 payment requirement ($0.01 in USDC or EURC). This is beyond what annotations provide and reveals a non-obvious cost side effect.

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 compact sentences, front-loaded with the core purpose and then providing essential details (scope, use case, data source, refresh, payment). No filler words or redundancy with 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 tool has a rich output schema, readOnly/openWorld annotations, and clear param descriptions, the description covers use case, data provenance, freshness, and payment. The conditional nom/siren requirement is already in the schema descriptions, so the tool is fully specified.

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 descriptions already cover all three parameters (100% coverage). The tool description explains how nom and siren fit the dual lookup purpose ('by name or SIREN') and mentions the x402 payment, linking to the x_payment parameter. This adds semantic context beyond the schema's field 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 uses specific verbs (screen, look up) and identifies exact resources (AMF blacklists, PSAN registrations, SGP licensed companies). It clearly distinguishes the tool from siblings like screen_sanctions_lists and search_eu_financial_authorisations by focusing on French AMF data.

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 explicit use-case context: 'Use before trusting an investment site, a crypto provider or an asset manager operating in France.' It does not explicitly compare against alternative tools or state when not to use, but the scenario is clear 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?

The description discloses behavioral traits beyond the readOnlyHint and openWorldHint annotations: the comparability block that flags non-comparable companies, the deliberate refusal to return an overall winner, and the billing rule. These non-obvious behaviors are essential for correct interpretation of results.

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 four dense sentences, each earning its place: usage, output contents, critical caveat, and billing. It is front-loaded with the use case and contains no filler, making it highly efficient.

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

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

With an output schema and annotations present, the description supplies the decision-relevant context (comparability, no overall winner, pricing) without restating structured data. It covers all necessary usage and behavioral nuances needed for selection and 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?

The input schema already covers both parameters (sirens array with pattern and min/max, x_payment header with omission meaning 'quote') at 100% coverage. The description adds only pricing detail, not parameter syntax or format, so it stays at the baseline for fully schema-covered 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 use case ('compare, rank or choose between 2 to 5 French companies'), clearly distinguishing it from single-company sibling tools like get_french_company_profile. It explicitly names the returned artifacts (cross-table, per-axis rankings), making the 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?

It explicitly states when to use the tool ('Use when asked to compare, rank or choose') and provides critical usage warnings: it never returns an overall winner and highlights that a holding vs. industrial group comparison could be misread. This implicitly excludes single-company lookups and guides agents away from misuse.

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 discloses rich behavioral details: daily monitoring frequency, specific data sources (BODACC, AMF-blacklist, PSAN/SGP, etc.), delivery via signed webhook or email digest, pollability with bearer token, and pricing formula. This goes well beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) and adds context about side effects, cost, 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?

Despite its length, every sentence contributes crucial information: purpose, use case, monitoring details, delivery, payment, and no-account model. It is front-loaded with the core action and usage context, and the structure is logical. No redundant 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?

The description fully covers the tool's complexity: when to use, what targets are accepted, what monitoring entails, how results are delivered, cost, and authentication/payment mechanism. It leaves no major gaps, especially given the existing annotations and output schema.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the x402 payment flow ('Omit to receive the payment quote'), the pricing formula ('$0.05 per target per 30 days'), and how cibles and webhook/email work together. This supplements the schema descriptions meaningfully.

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: 'create a 30-day watchlist over French companies and/or directors' — a specific verb and resource. It also distinguishes from sibling tools by framing it as ongoing monitoring for relationships that outlast a one-time check, which differentiates it from get/renew/stop surveillance 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?

Usage guidance is explicit: 'use when the relationship OUTLASTS the check (supplier, borrower, portfolio company)'. This defines when to use the tool but does not explicitly name alternatives or provide a 'when not to use' statement, though the implication is clear for one-off 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 readOnlyHint and openWorldHint are supplemented with concrete details: 'Deterministic pattern matching; the text is never stored or logged' and 'FREE' with price outputs. These disclosures add privacy and determinism context beyond the annotations and do not contradict them.

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: starts with 'FREE', states purpose and capabilities, gives usage guidance, and closes with a privacy guarantee. Every sentence 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?

With a single input parameter and an output schema present, the description adequately covers the tool's role, input examples, outputs (identifiers, recommended call, price), and behavioral guarantees. It doesn't enumerate every checksum nuance, but that level of detail is unnecessary for tool 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 already documents the 'texte' parameter with maxLength and minLength (100% coverage). The description adds real-world input examples (email, invoice, contract, web page), enriching meaning beyond the schema's plain 'Raw text to scan'.

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 detects French/EU company identifiers (SIREN, SIRET, VAT, LEI) from pasted text, and goes further by specifying it provides the recommended Sirenic call and price. This distinguishes it from sibling tools like validate_eu_vat_number by framing it as a first-pass detection 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?

Explicitly instructs to 'Use this FIRST whenever a company appears in your workflow' with concrete scenarios (supplier onboarding, payment, due diligence). It conveys strong when-to-use guidance but does not explicitly name alternative tools for cases where identifiers are already structured, lacking a full when-not-to-use comparison.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true. The description adds that the tool returns a PDF as base64, typical file size (1-10 MB), and the x402 payment mechanism. This provides useful 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?

The description is a single paragraph that front-loads the action and source, includes examples, file size, and payment note—all relevant. No redundant information, every sentence adds 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 tool has three parameters, no output schema, and medium complexity, the description adequately explains the return format (PDF as base64) and payment model. It could mention potential errors or more about the payment flow, but overall it's sufficiently complete.

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

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

Schema coverage is 100% with descriptions for all three parameters. The description reinforces the use of type and document_id from list_french_company_documents and clarifies that omitting x_payment yields a payment quote. This adds value beyond the schema.

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

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

The description clearly states the tool downloads an official company document (PDF) from the INPI RNE registry, lists example document types (statutes, minutes, accounts), and mentions using IDs from list_french_company_documents. This distinguishes it from sibling tools that list documents or retrieve other data.

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 says to use IDs from list_french_company_documents, indicating a prerequisite. It also mentions the payment requirement (x402, $0.10). While it doesn't explicitly state when not to use the tool or list alternatives, the context is clear enough for an agent to infer usage.

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 and openWorldHint annotations already signaling safety and open-world semantics, the description adds valuable behavior context: deposits are immutable, older filings return an official PDF base64, and payment is required via x402. This goes beyond the annotations and helps the agent understand side effects and data format. 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 a single, dense sentence that front-loads the main purpose and then efficiently tucks in format details, reference source, immutability, and payment. Every clause carries essential information with no wasted words, making it highly scannable.

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 lack of an output schema, the description covers the key aspects: what data is returned, for which date range, and the reference source. It also discloses immutability and payment costs. It doesn't describe error cases or rate limits, but for a single-deposit fetch tool this 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 coverage is 100% with descriptive text for all parameters, so the baseline is 3. The description further clarifies the 'reference' parameter by stating it comes from list_belgian_company_filings, and explains 'x_payment' in the context of 'Paid via x402'. This adds meaningful context beyond the raw 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 clearly states it retrieves a single Belgian annual-account deposit, distinguishing it from list_belgian_company_filings and other country-specific filing tools. It specifies the data source (NBB CBSO Authentic Data) and the output format by date (structured JSON for post-April 2022, PDF base64 for older). This is a specific verb+resource with clear scope.

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

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

The description explicitly says 'Reference comes from list_belgian_company_filings,' establishing a clear prerequisite workflow. It also mentions the x402 payment requirement, which is essential usage context. However, it does not explicitly contrast this tool with sibling alternatives like get_danish_company_filing, though the reference to list_belgian_company_filings implies a typical flow.

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 behavioral details beyond annotations: data is aggregated at issuer level over rolling 12 months, individuals are never named, and breakdowns are withheld to prevent singling out. It also discloses the x402 payment requirement and cost, which annotations do not cover. No contradiction with readOnlyHint/openWorldHint.

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 tool's purpose, followed by data scope, privacy behavior, use case, and pricing in four sentences. Every sentence carries distinct information without redundancy.

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 input schema is fully described, the description covers return content (notification counts, gross amounts, net flow, breakdown), use case, privacy constraints, and payment. The tool's complexity is moderate, and the description is sufficient for an agent to select and 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 coverage is 100% (id, depuis, x_payment all documented with descriptions). The description adds context for the 'depuis' default by mentioning 'rolling 12 months' and explains the payment parameter via 'Paid via x402 ($0.02 in USDC or EURC)', but does not substantially alter parameter meaning beyond the schema.

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

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

The description clearly states the tool's function: retrieving issuer-level insider transaction data for Belgian listed companies under MAR Article 19, with specific outputs (notification counts, buy/sell amounts, net flow). It distinguishes itself from sibling tools like get_belgian_company_filing by its exclusive focus on insider 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 provides explicit use-case guidance: 'Use it as a governance signal before investing in or contracting with a listed Belgian company.' It does not explicitly name alternatives or when-not-to-use, but given the sibling list, no other tool covers insider transactions, so the context is clear.

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

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

Beyond the readOnly/openWorld annotations, the description discloses data freshness ('refreshed daily'), a pricing model ('$0.02 in USDC or EURC' via x402), and an important behavioral outcome ('Not authorised is an answer too'). No annotation contradictions.

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 information. The first sentence packs a wealth of specific detail without fluff, and the second gives actionable usage and cost info.

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 present, description need not explain return values. It covers scope, sources, use cases, data freshness, and payment, making it complete for a tool of this complexity.

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

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

Schema coverage is 100%, so parameters are already well-documented. The description adds no additional semantic detail beyond what the schema provides, which meets the baseline for high 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 specifies the exact resource: regulatory authorisations of a French company by SIREN. It lists concrete authorisation types (payment institution, e-money, etc.) and data sources (EBA, EIOPA, ARCEP), clearly distinguishing it from sibling company-data 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?

Provides explicit use cases: 'Use it before paying, onboarding or contracting with a regulated counterparty.' It does not mention when not to use or name alternative tools, but the context is clear.

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

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

The description adds substantial context beyond the annotations: event list capped at 100 most recent events, truncation flags, 404 for natural persons, 503 for stale stock, GDPR minimization, and x402 payment. These details disclose real behavioral traits and edge cases without contradicting the readOnlyHint or openWorldHint 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 dense but every sentence provides value: source, content, truncation behavior, legal person limitation, stale data handling, payment. It is front-loaded with the core purpose and structured with clear clauses. While a bit long, it avoids fluff and earns its length.

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 present, return values are covered elsewhere. The description completes the picture with edge cases (no proceeding, 404, 503), data history, legal scope, event truncation, and payment. It is highly complete for a tool with this complexity.

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

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

Schema description coverage is 100%, so both parameters (ico and x_payment) are already documented. The description adds minimal extra parameter meaning, only reinforcing that ico must be a legal-person identifier and that x_payment is tied to the paid access. Baseline 3 is appropriate since the schema carries the burden.

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 explicitly states the tool retrieves insolvency records for a Czech company from the official ISIR register. It details specific content (case number, court, status, dates, event trail) and clearly differentiates from country-specific siblings like get_uk_company_insolvency and get_latvian_company_insolvency.

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 implies usage for Czech companies and explicitly states exclusions (natural persons, sole traders). It provides context on data coverage (since 2008, compulsory publication) and payment requirements (x402). It does not explicitly name alternative tools, but the country-specific scope is clear from the tool name and sibling list.

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 discloses the $0.05 x402 payment requirement, null-as-not-published semantics, filing currency, and inclusion of the official XBRL document URL. It also clarifies that revenue is never zero when published, adding important interpretation 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?

The description is a dense, well-structured paragraph that leads with the core purpose, lists the returned metrics, and adds essential context about currency, payment, and the relationship to the list tool. Every sentence carries information without redundancy.

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 and readOnly annotation, the description covers the essential use context: what data is returned, the payment cost, the null convention, and the prerequisite list call. It is sufficient for an agent to invoke this tool correctly in a multi-country filing scenario.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by specifying that date_cloture should be obtained from list_danish_company_filings, and clarifies the meaning of 'null' values in the output, which relates to what the parameters retrieve. It doesn't add significant new detail for id or x_payment 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 exactly what the tool does: decodes financial statements from a Danish company's XBRL annual report for one fiscal year, listing the specific metrics returned. It distinguishes from sibling tools by explicitly naming Denmark and referencing list_danish_company_filings as the source for the closing date.

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 instructs that the closing date parameter comes from list_danish_company_filings, providing a clear prerequisite. The tool is implicitly positioned as the Danish-specific filing lookup among many country-specific siblings, though it doesn't explicitly state when not 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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses concrete behavioral constraints: mandate caps (300 active / 200 ended) with a `tronque` flag, GDPR data minimisation (no address, no identifier, no DOB), and payment requirement via x402. It even clarifies that beneficial owners are never guessed, adding trust and predictability. 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 concise despite its length, with each sentence delivering functional value: source, data coverage, default behavior, optional parameter semantics, limits, exclusions, privacy, and cost. It is front-loaded with the primary purpose and maintains high information density without redundancy.

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 (multiple officer types, mandate dates, caps, payment, privacy constraints), the description covers all critical operational aspects: what data is returned, how pagination/truncation works, what is intentionally omitted, and required payment. Since an output schema exists, return formatting is already documented, leaving no major 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 input schema already provides descriptions for all parameters (100% coverage), so the baseline is 3. The description adds extra value by explaining the semantics of inclure_anciens ('adds ended mandates, which is where founders normally are') and the behavior of the `tronque` flag in relation to capped boards. This enriched understanding helps the agent choose correct parameter settings.

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 retrieves Danish company officers and directors from the official CVR registry, listing specific roles (executive board, board, auditors) and explicitly distinguishing from beneficial owners. The verb 'get' plus resource 'danish_company_officers' is unambiguous and differentiated from sibling tools like get_latvian_company_officers by country and content.

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 implicit usage guidance: it's for Danish company officers, with active mandates by default and the optional parameter to include ended mandates (where founders appear). It explicitly states beneficial owners are NOT exposed, advising against using this tool for that purpose. However, it does not explicitly name alternative tools for other jurisdictions or beneficial owner lookups, so it falls short of full 'when-to-use vs alternatives' guidance.

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

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

Discloses rich behavioral traits beyond annotations: data source (RIK), license (CC BY 4.0), refresh period (monthly), handling of null values (null = not published, never zero), separation of statutory/consolidated figures, PDF-only exclusion, and payment cost via x402. This significantly exceeds the readOnlyHint/openWorldHint 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 dense and information-rich, covering all essential aspects in a single paragraph. However, it is structured as one long run-on sentence with multiple clauses, which could hinder quick scanning. Every sentence earns its place, but better formatting would improve clarity.

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, the description is remarkably complete. It covers data source, scope, limitations, payment, and output field semantics. The output schema exists, so detailed return format is not needed in the description. This is more than sufficient for an agent to select and 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 already provides 100% coverage for both parameters. The description adds value by specifying the payment cost ($0.02 in USDC or EURC) for x_payment and clarifying that null values in output are genuine non-publications. It does not add extra meaning for registrikood beyond the schema's example.

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: retrieving Estonian company annual account key figures from the official e-Business Register. It lists specific data fields (balance sheet, revenue, profit, etc.) and the scope (every published financial year since 2019), which distinguishes it from sibling country-specific account 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?

Provides clear context: data source, monthly refresh, and a notable exclusion (PDF-only filings are not served). It also mentions the payment requirement. However, it does not explicitly name alternative tools or state 'use this for Estonian accounts', though the context is implied by the tool name and coverage.

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 far beyond the annotations (readOnlyHint, openWorldHint) by disclosing intricate behavioral details: the semantics of alerte, nombre_alertes, and types_non_qualifies, fail-closed handling of unknown state codes, the distinction between a positive empty answer and a 404, and the payment mechanism via x402. This level of transparency is exceptional.

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 sentence earns its place: it front-loads the core purpose, then explains field logic, edge cases, and payment. There is no redundant or filler content. The structure is logical and appropriately sized for the tool's complexity.

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 fully complete for the tool's complexity. It explains return behavior (positive answer vs 404), the meaning of key fields, the open-world hint (zero is not 'no warning'), and payment requirements. Given the presence of an output schema, the description covers all necessary contextual aspects.

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 already covers both parameters (x_payment and registrikood) with descriptions, giving 100% coverage. The tool description adds no parameter-level meaning beyond that; it mentions payment as a behavior, not as a parameter semantic. Thus the baseline score of 3 applies.

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

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

The description specifies exactly what the tool does: retrieves registry rulings (määrused) of an Estonian company from the official e-Business Register open data. It enumerates the types of rulings (registry entries, orders to remedy defects, warnings of striking-off, etc.), distinguishing it clearly from sibling tools like get_estonian_company_accounts or get_french_company_legal_alerts.

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: it is specifically for Estonian company registry rulings, with details about data source and edge cases (e.g., struck-off entities return 404). However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of a full 5.

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

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

Adds rich behavioral context beyond readOnlyHint/openWorldHint: identifier matching (SIREN/SIRET variants), coverage limitations, payment requirement (x402), and the open-world caveat about empty results. 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?

Four dense sentences, each adding distinct value (purpose, identifier/coverage, sibling relation, payment). No filler or redundancy.

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?

Despite having an output schema, the description still lists return fields (buyer, country, subject, amount, CPV codes, links), covers payment, caveats, and alternatives. Fully equips the agent to decide and invoke 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 covers both parameters fully (100%), so baseline is 3. Description adds only the SIREN/SIRET matching nuance, which is about behavior rather than parameter format; x_payment is already described in the schema.

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

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

Purpose is explicit: lists EU public procurement awards won by a French company from TED data, with specific data fields. Distinct from sibling get_french_company_public_procurement by mentioning EU vs French DECP and above-threshold vs below-threshold.

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

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

Clearly states when to use: for EU-level TED award notices, and explicitly names the complementary sibling tool for French DECP below-threshold. Also provides coverage caveats (eForms since 2023-10-25, ~57% identifier coverage) and clarifies that empty list is not proof of absence.

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 indicate readOnlyHint and openWorldHint, and the description adds valuable context: the tool is paid via x402 ($0.01 in USDC or EURC), the response follows the same schema for all countries, and the availability of certain jurisdictions is conditional ('when enabled'). It does not contradict the annotations and provides useful operational details beyond the structured fields.

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

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

The description is a single, dense sentence but is well-organized: main purposedash, then schema consistency, then country list, then fallback, then payment. The country list is long but necessary for a coverage-sensitive tool. It is not overly verbose and each component earns its place, though the dense parentheses could be slightly better structured for 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?

Given the tool's complexity (multiple countries, registries, payment requirement) and that an output schema exists, the description is quite complete. It enumerates covered jurisdictions, lists the key return fields, specifies the fallback via GLEIF, and mentions the payment requirement. Minor gaps remain, such as what 'normalized status' means or how the payment quote flow works, but the presence of an output schema reduces the burden on the description.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds extra meaning by explaining that 'pays' and 'id' together identify the company ('by country and national register ID') and by specifying the exact payment amount and currency for the optional x_payment parameter, which goes beyond the schema's generic description. It reinforces country-registry mappings but does not fully override schema detail.

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 ('lookup') and resource ('European company profile'), and distinguishes itself from the many country-specific sibling tools (e.g., get_french_company_profile) by emphasizing its multi-country unified coverage and consistent JSON schema. The list of supported registries and GLEIF fallback makes the tool's scope 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 description provides clear context for when to use the tool: when a unified European company profile is needed by country and national register ID. It also notes coverage specifics (e.g., 'Denmark/UK when enabled' and 'elsewhere via GLEIF'), which helps set expectations. However, it does not explicitly contrast with sibling tools or state when to prefer a country-specific getter, so it lacks formal exclusion guidance.

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

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

The description discloses critical behaviors: revenue is never zero and null means not published, prior-year comparatives are included, and the service costs $0.15 paid via x402. This adds value beyond the readOnlyHint/openWorldHint annotations. 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?

Two sentences convey all essential information: what data is returned, null semantics, comparatives, source, and payment. No redundant words; front-loaded with the core purpose.

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, return format is covered. The description provides purpose, source, data semantics, comparatives, dependency on list_finnish_company_filings, and payment. It sufficiently covers the tool's usage context for an agent, though it could mention error behavior if no filing exists.

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?

All three parameters have schema descriptions with full coverage. The description adds a workflow hint that the closing date comes from list_finnish_company_filings, which aids selection of date_cloture. This is helpful but marginal beyond the schema's own 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 clearly identifies the tool as fetching a single Finnish fiscal year's financial statements decoded from the company's PRH XBRL filing. It specifies scope (one fiscal year) and resource (Finnish company filing), distinguishing it from other country-specific filing tools and list_finnish_company_filings.

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 that the closing date comes from list_finnish_company_filings, guiding the agent to first use that sibling tool to obtain the required date_cloture parameter. It also mentions the x402 payment requirement, giving usage context. However, it does not explicitly exclude alternative country filing tools, though the Finnish scope is clear.

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

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

The description adds substantial behavioral context beyond the annotations: it is AI-extracted from PUBLIC articles of association, reconstructed from filed deeds, includes confidence scores and source documents, and importantly discloses the paid nature ($0.35 via x402). This goes well beyond the readOnlyHint and openWorldHint 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?

Every sentence delivers specific value: data content, source, limitations, and pricing. The description is front-loaded with the core purpose and remains compact despite the amount of context provided. No fluff or redundancy.

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 present and read-only annotations, the description still enriches the context by enumerating the exact returned fields (shareholders, roles, birth year, ownership %), the source document, and the confidence level. It also alerts the user about the payment requirement, which is essential for successful 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?

The input schema already fully describes both parameters, including the payment header behavior. The description adds no extra parameter semantics; it only reinforces the French company context. Since schema coverage is 100%, the baseline score of 3 is appropriate.

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

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

The description clearly states it provides share capital and ownership structure of a French company, listing specific data points such as share capital, legal form, shareholders, and ownership percentages. It explicitly distinguishes itself by noting it is NOT a beneficial-ownership register, which differentiates it from sibling tools like get_uk_beneficial_owners.

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 about the data source (INPI registry) and explicit exclusions (not RBE or beneficial-owner identification). However, it does not directly name alternative tools for when the user needs beneficial ownership or other capital-related data, leaving some room for interpretation.

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 openWorldHint annotations, the description adds meaningful behavioral disclosures: it returns an empty list when no new announcements exist, orders results reverse-chronologically, and mentions the x402 payment cost. This is valuable context not inferable from annotations.

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

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

The description is four concise sentences, each earning its place: purpose, behavioral distinction, empty-list behavior, and payment requirement. It is front-loaded with the core purpose and contains no 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?

With a good input schema, helpful annotations, and an output schema present, the description covers the essential edge case (empty list), payment cost, and behavioral expectations (not field-level edits). This is complete for a monitoring tool of this complexity.

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 already documents all three parameters with descriptive text (9-digit SIREN, date format, payment header), achieving 100% coverage. The description adds little beyond echoing the 'since a given date' concept, so a baseline 3 is appropriate.

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

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

The description clearly states the tool monitors French BODACC gazette announcements since a given date, with a specific verb+resource+scope. It explicitly distinguishes from siblings by noting it detects new publications, not field-level edits, which sets it apart from profile or alert 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 provides clear context for when to use the tool: poll-mode surveillance for a portfolio, and states an exclusion (not field-level edits). However, it does not explicitly name alternative sibling tools, so it stops short of full 5.

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

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

The description discloses the scoring methodology, return contents (score, band, each component with threshold, confidence level), the BODACC override, the decision-support-only caveat, and the payment cost. Annotations indicate readOnly, and the added behavioral context goes well beyond those structured hints.

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: definition, methodology, output contents, caveat, and payment. Each sentence earns its place and the most important purpose 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 description covers time horizon, input data sources, hard overrides, output fields, confidence level, limitations, and payment. With annotations and an output schema already present, this is more than sufficient for an agent to decide when and how to call the 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?

The input schema already documents both parameters fully: SIREN with a 9-digit pattern, and x_payment with omit-to-receive-quote semantics. The description adds the $0.10 USDC/EURC cost but no new parameter-level meaning; with 100% schema coverage, the baseline 3 is appropriate.

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

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

The description names the exact resource: a default-risk score (0-100) for a French company at ~12 months, with a clear verb implied in the tool name. It distinguishes itself from sibling tools by specifying credit/insolvency risk scoring from financial ratios, company age, and a BODACC override.

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: use for a French company's ~12-month default-risk/insolvency assessment, and explicitly warns it is not a solvency opinion or credit rating. It does not name alternative tools or provide an explicit when-not-to-use scenario beyond the caveat, so it falls just 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?

Beyond the readOnlyHint annotation, the description discloses the paid nature (x402 cost), the data sources (INPI/Banque de France), and the scope of up to 10 fiscal years. It does not cover error cases or pagination, but with annotations provided, this is sufficient.

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, front-loading the core data content and appending the payment detail. Every sentence contributes essential information without unnecessary verbosity.

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 and the tool's moderate complexity, the description adequately covers data type, sources, and payment. A minor omission is the explicit behavior when x_payment is omitted, but the schema already addresses this.

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

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

The schema already provides full coverage for both parameters. The description adds context for x_payment by mentioning the cost and payment mechanism, but it does not meaningfully expand on parameter semantics beyond what the schema already states.

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 specifies the tool's function: retrieving annual accounts, financial statements, and tax-form line items for a French company, with concrete metrics (revenue, EBITDA, net income) and data sources (INPI/Banque de France). This distinguishes it from sibling tools like get_french_company_profile or get_french_company_capital.

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 for financial data retrieval and explicitly notes the x402 payment requirement, providing context on how to use the tool. However, it does not explicitly contrast this tool with alternatives or state when not to use it, leaving some room for improvement.

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 discloses important non-obvious behaviors: results are cached for 7 days, the tool is paid via x402 costing $0.15 in USDC/EURC, and output is in French. These traits go beyond the annotations and provide crucial operational 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?

The description is a single, well-structured, front-loaded sentence that covers purpose, language, data source, output components, caching, and cost without redundant wording. Every part 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 presence of an output schema and annotations for read-only/open-world, the description covers the remaining essential context: cost, caching, language, and data source. It is complete for practical use by an agent.

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 already fully documents both parameters (siren pattern and x_payment usage). The description adds value by specifying the exact cost ($0.15) and cache freshness, which are not in the schema, helping the agent understand the implications of using siren and x_payment.

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 tool produces an AI-generated business-health and risk summary for a French company, listing specific components (strengths, warning signs, activity trend, confidence level) and noting it is in French from official data. This is more specific than the tool name alone, but it does not explicitly contrast with sibling risk tools like default risk or industrial risk.

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 implied context for use (synthesized health/risk overview from official data) and mentions caching and cost, which help an agent decide if this tool is appropriate. However, it does not explicitly state when to choose this over alternatives or provide exclusions.

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

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

Annotations already cover read-only and open-world aspects. The description adds valuable behavioral context: the return of level 'aucun' when no classified facility exists (and that this is a meaningful signal), plus the x402 payment requirement. It does not over-explain beyond 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 efficiently structured: purpose, data contents, edge-case behavior, and payment. Every sentence contributes new information without redundant or vague phrasing.

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 tool with an output schema and two well-documented parameters, the description covers the essential context: data source, specific fields, no-result behavior, and payment. It does not need to explain return values because the output schema exists.

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

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

Schema coverage is 100% with descriptions for both parameters, so the baseline is 3. The description adds cost and payment context for x_payment ('Paid via x402 ($0.01...)'), which helps the agent understand the financial side of invocation beyond the schema's technical header description.

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: retrieving industrial-risk and environment (ESG) profiles of French companies from the ICPE register. It enumerates the specific data elements (Seveso status, authorisation regime, IED flag) and notes the per-SIREN risk synthesis, distinguishing it clearly from sibling tools like default_risk or health_summary.

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 context is clear: use when you need industrial-risk or environmental data from the official ICPE register. It does not explicitly name alternatives or exclusions, but the specificity of the domain provides strong implied guidance. The payment note adds a practical usage requirement.

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 indicate readOnlyHint and openWorldHint, so the bar is lower. The description adds valuable behavioral details: patent inventor names (natural persons) are never returned, and the service requires a $0.03 x402 payment in USDC or EURC. This goes beyond the structured fields and 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?

The description is three concise sentences with no wasted words. It front-loads the core purpose and data source, then adds a usage signal, and finally states the limitations and cost. 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 presence of an output schema and complete parameter schema, the description still manages to convey the key context: the source (INPI), the categories of IP, the nature of output (counts and recent items with specific fields), the non-return of inventor names, and the payment requirement. This is complete for a tool of this complexity.

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 covers both parameters completely: siren is fully described as a 9-digit SIREN, and x_payment is explained as an optional payment header to omit for a quote. The description adds no extra parameter-specific semantics, but with 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description clearly identifies the tool as fetching the intellectual-property portfolio of a French company from INPI open data, listing the specific IP types (trademarks, patents, designs) and output fields (counts, recent items with number, title, status, date, classification). This specific scope distinguishes it from the many other French company tools in the sibling 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 description explicitly positions the tool as 'an R&D/brand-value signal,' which gives clear guidance on when to use it. It does not name alternatives or state when not to use it, but it provides a clear context for usage in evaluating research and brand strength.

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 far beyond the readOnlyHint/openWorldHint annotations. It discloses the x402 payment requirement ($1.00), the deterministic verdict categories, the auditable Ed25519 signature, as_of dates per block, and that omitting x_payment returns a payment quote. This is rich behavioral context that 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 long but front-loaded with the primary use case and then a compact, comprehensive list of report blocks. Each item contributes useful information about the tool's capabilities, but the density of clauses could be slightly overwhelming. It earns a 4 for being well-structured and not repetitive.

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 and the existence of an output schema, the description covers everything an agent needs to know: when to use it, what data is returned, the verdict logic, the auditable signature, and the payment mandate. The only missing element is explicit error handling, but that is not required given the output schema.

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

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

Schema coverage is 100% and both parameters (siren, x_payment) already have clear descriptions in the schema. The main description does not add new meaning beyond the schema, though it reinforces the live VIES VAT check context. Baseline 3 is appropriate since the schema already handles parameter details.

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 clear 'Use for a GO/NO-GO decision (credit, investment, partnership)' and defines the tool as producing a comprehensive 'Company INTELLIGENCE report'. It lists the exact blocks covered, distinguishing it from narrower sibling tools like get_french_company_financials or get_french_company_legal_alerts, and explicitly labels it 'The flagship due-diligence 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?

It explicitly states when to use the tool (GO/NO-GO decisions) and implies it is the comprehensive all-in-one alternative to the many single-block siblings by saying 'every Sirenic block cross-referenced in one call'. However, it does not explicitly name alternatives or state when not to use it, leaving some room for interpretation.

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 rich behavioral detail beyond the readOnlyHint and openWorldHint annotations: per-company billing at $0.105 (30% off), charge calculation via unit price × SIREN count, behavior for non-diffusible SIRENs (trouve=false and billed), and per-block provenance. 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?

The description is five sentences, each adding essential information: core function, pricing, edge-case handling, provenance, and ideal use case. It is front-loaded with the main purpose in the first sentence and wastes no words.

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 likely defines return structure, the description covers all necessary operational aspects: batch size limits, pricing details, edge-case behavior, provenance, and recommended usage. The readOnlyHint/openWorldHint annotations further assure the agent this is a safe read operation. It is complete for a batch-lookup tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining the billing formula ('unit price times the number of SIREN'), which clarifies the commercial impact of the sirens parameter. It also explains the edge-case behavior for invalid SIRENs, which is not in the schema. The x_payment parameter is adequately covered by the schema's own description.

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 explicitly states the tool performs batch KYB lookups for 2 to 100 French companies, using a specific verb ('Batch KYB') and resource ('full KYB files'). This clearly distinguishes it from sibling tool get_french_company_kyb_file, which handles a single company.

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 with 'Ideal for prospecting and compliance agents processing lists' and specifies the batch size constraint (2 to 100). However, it does not explicitly name the alternative single-company tool or state when not to use this batch version, so it stops short of full exclusionary guidance.

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

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

Annotations provide readOnlyHint and openWorldHint. The description goes beyond by disclosing payment requirement (x402, $0.15), provenance metadata (official register, licence, version, as_of), and precision_as_of semantics. It adds significant behavioral context 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?

The description is dense but well-structured: purpose, usage guidelines, provenance, and pricing in four sentences. Each sentence provides valuable information, though it is slightly verbose for a tool with rich schema. Front-loaded with the core purpose.

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 bundle tool with an output schema, the description covers key aspects: what data is included, provenance, pricing, and alternatives. It does not need to explain return values due to output schema presence. Could mention limitations, but openWorldHint covers that.

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

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

Schema covers 100% of parameters with descriptions (siren pattern, x_payment optional). The description does not add parameter-specific detail beyond schema, but baseline is 3 due to high schema coverage. Payment context is mentioned, but not parameter syntax.

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: 'Complete KYB file for a French company in one call — a comprehensive BUNDLE consolidating identity, officers, BODACC legal alerts, filed financials, sanctions screening, VAT number and completeness score.' It lists components and distinguishes from siblings by naming dedicated alternatives.

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 guidance is given: 'Use this when you want the whole due-diligence picture at once; if you only need one part, call the dedicated tool instead... they are cheaper.' This states when to use and when to choose alternatives.

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

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

Annotations already mark readOnlyHint and openWorldHint. The description adds valuable context: results are grouped most recent first, sourced from BODACC, and require a payment via x402. This goes beyond the structured 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, front-loaded sentence that efficiently conveys purpose, source, content, ordering, and payment. No unnecessary words or structure.

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 relatively simple read tool with an output schema, the description covers the key context: source, event types, grouping, recency, and payment. It doesn't explain return shape, but the output schema covers that. Not all alternative tools are referenced, which is a minor gap.

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

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

Schema description coverage is 100% for both parameters (siren pattern and x_payment header semantics). The description does not add parameter-level detail beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool provides legal alerts and legal notices for a French company from BODACC, listing specific event types. This distinguishes it from sibling French company tools by source and content.

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 the tool (for BODACC legal events) and includes the payment requirement, but it does not explicitly name alternatives or exclusion scenarios. The clear context earns a 4.

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 and openWorldHint, but the description adds important behavioral context: the data source (HATVP), the meaning of `inscrit: false`, the scope ('Organisation-level only'), and the payment requirement via x402 with cost. This goes beyond what annotations provide and helps the 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 a single dense paragraph that lists many data points, but every sentence contributes value: purpose/contents, scope (organisation-level), meaningful false, and payment. It is longer than the high-caliber example but not wasteful; it could be slightly more compact but is structured logically.

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 present, the return format is covered. The description sufficiently explains the data source, field categories, semantics of false results, and payment requirement. It doesn't mention pagination or rate limits, but given the complexity and output schema, this is adequate. Sibling comparison is implicit through the exclusive focus on lobbying.

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

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

Schema coverage is 100%, with both parameters already described ('9-digit SIREN' and 'Optimal signed x402 PAYMENT-SIGNATURE header value'). The description adds context about the payment mechanism and cost, which reinforces the x_payment parameter semantics, but doesn't introduce new parameter details 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 clearly states it provides a 'Lobbying and transparency profile of a French company' from the official HATVP register, with a specific list of data points. This distinguishes it from sibling tools like get_french_company_profile or get_french_company_intelligence, which cover broader company data.

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 (for lobbying/transparency data from HATVP) and includes a meaningful exclusion: 'Organisation-level only — no personal data.' It also notes that `inscrit: false` is a meaningful answer, indicating that false results are valid and informative. However, it doesn't explicitly name alternative tools for cases where this tool is not appropriate.

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

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

The description adds useful behavioral context beyond the annotations: the tool is paid ($0.50 via x402), returns the PDF as base64, and conditionally includes the AI health summary when cached. The readOnlyHint and openWorldHint annotations are not contradicted by these details, and the payment side effect is clearly 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 compact, front-loaded with the core purpose, and every sentence adds value: content, output format, and payment terms. There is no wasteful repetition of schema or annotation information.

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

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

For a tool with no output schema, the description adequately explains the return value (base64 PDF) and payment flow. However, it does not clarify how the payment quote flow works in relation to x_payment, and it leaves overlap with get_french_company_kyb_file unexplored, 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 100%, so the parameters are already well-documented in the schema. The description only adds that the report is for a French company and mentions the x402 payment, which aligns with the x_payment parameter but does not add significant new 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 clearly identifies the tool as producing an on-demand PDF report of a French company, with a specific output format (base64) and content list (identity, officers, legal alerts, financials, sanctions screening). This distinguishes it from sibling tools that return raw data or structured KYB files rather than a shareable PDF dossier.

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

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

Usage context is implied: this is for when you need a formatted, shareable due-diligence PDF rather than raw data. However, it does not explicitly state when to prefer this over sibling tools like get_french_company_kyb_file, nor does it mention any exclusions or alternatives.

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

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

Annotations already say readOnlyHint=true and openWorldHint=true, so the description doesn't need to state safety. It adds valuable context: the exact cost of the paid x402 call ($0.005), the authoritative data sources (INSEE Sirene / INPI RNE), and an important interpretation note about the IDCC codes (9999 meaning 'no collective agreement'). These go beyond the structured fields and prevent misuse. It does not mention rate limits or auth, but that's not required given the existing annotations and output schema.

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

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

The description is 133 words, but each segment earns its place: the data field list gives a quick overview, the IDCC note prevents a common lookup error, and the pricing is essential for a paid tool. It's front-loaded with the most important information. Slight redundancy exists ('Full official company profile' vs 'core company data lookup'), but overall it's efficiently packed and readable.

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, the presence of an output schema, and annotations, the description is thorough. It covers what data is returned, the data source, the use case (KYB/due diligence), a special field nuance, and the payment requirement. There is no obvious missing context that would prevent an agent from selecting or invoking this 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?

Schema description coverage is 100%: both siren and x_payment are already fully described in the schema. The description only echoes 'by SIREN' and mentions the payment cost, adding no new semantics for parameter usage beyond the schema. Thus the baseline of 3 applies.

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

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

The description clearly states the tool retrieves the full official company profile from the French company registry by SIREN, listing the exact data fields (legal name, legal form, head office, NAF code, workforce, officers, collective agreements, VAT). It distinguishes itself from sibling tools by framing itself as 'The core company data lookup for KYB and due diligence on France,' making it clear this is the primary profile tool and not a specialized financial, legal, or batch 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 provides clear use-case context ('KYB and due diligence on France') and positions the tool as the core lookup, which implies it should be the first stop for French company profiles. However, it does not explicitly name alternatives or state when not to use this tool (e.g., for financials or capital changes), so it stops short of the explicit when/when-not guidance required for 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 annotations declaring readOnlyHint and openWorldHint, the description adds the critical behavioral detail of payment via x402 ($0.01 in USDC or EURC), which is not in the annotations. It also mentions the data source (official DECP), providing context beyond the structured fields. 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 concise sentences, front-loaded with the core purpose and followed by key context (data fields, cost). Every word adds value and there is 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?

Given the tool has an output schema and annotations, the description adequately covers the core function, scope, data source, and payment requirement. It omits non-essential details like potential limitations, but is complete for a focused single-purpose 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?

The schema already fully describes both parameters (siren pattern and x_payment header semantics). The description adds the cost and the fact that payment is required, enriching the meaning of x_payment beyond the schema's literal description.

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 retrieving French public procurement data (government contracts and tenders won by a French company) from official DECP data, listing the key output fields (buyers, amounts, dates). It is distinct from siblings like get_eu_procurement_awards and other French company 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 context for when to use it: when seeking French public procurement for a specific French company, and it notes the x402 payment requirement. It does not explicitly mention alternatives or exclusions, but the scope is obvious from the wording and sibling tool names.

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 indicate readOnlyHint and openWorldHint, but the description adds valuable behavioral context: the aggregate-only nature ('Aggregates only, no personal data'), the conditional availability of financial metrics ('when at least 5 companies file public accounts'), and the payment mechanism ('Paid via x402 ($0.05 in USDC or EURC)'). This goes well beyond the structured 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 densely packed but every clause earns its place: purpose, metrics, threshold condition, secondary use case, privacy safeguard, and pricing. It is front-loaded with the core function and structured with em-dashes and semicolons. No redundant or filler 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?

Considering the tool's complexity (multiple metrics, conditional data, payment flow), the description is remarkably complete. It covers input format ('any level'), output content (though output schema exists), the minimum threshold for financial data, aggregate privacy, and the payment process. There is no critical missing context that would prevent an agent from invoking it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description reiterates the schema's note about 'any level' for code_naf and gives examples (68, 68.2, 68.20, 68.20B), which adds a small illustrative benefit. However, the x_payment parameter is described identically in the schema ('Omit to receive the payment quote'), so no new meaning is added 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 clearly states the tool's function: 'Sector benchmarks and sector statistics for a French NAF activity code'. It enumerates specific metrics (active companies, company age, workforce distribution, financial ratios) and distinguishes itself from sibling tools that focus on individual companies (e.g., get_french_company_financials). This is a precise verb+resource+scope statement.

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

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

The description gives a clear context for use: provide a French NAF code at any level, and it produces sector benchmarks. It also mentions a secondary use case ('Peer comparison: place a company against its peers'), implying when this tool is relevant. However, it does not explicitly state when to prefer alternatives or exclusions (e.g., 'for company-level data, use get_french_company_financials').

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

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

Adds substantial behavioral detail: null revenue means not published (never zero), figures preserve original currency and rounding, statutory versus consolidated separated, daily refresh, and a paid x402 fee. These details go beyond the read-only annotation and help interpret results.

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?

Description is packed with necessary detail and avoids filler, though the long dashes and semicolons create a dense run-on structure. Every clause provides useful information, balancing conciseness with completeness.

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 present and thorough behavioral caveats (currency, rounding, nulls, consolidation), the description fully equips an agent to understand the tool's output and payment flow. No significant 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 covers both parameters with descriptions; the description adds value by explaining the payment cost and currency for x_payment and clarifies the null semantics that affect interpretation of the response, though it doesn't add much about regnr 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?

Clearly states it retrieves Latvian company annual accounts from official VID filings, specifying the content (balance sheet, P&L, cash flow, employees) and geographic scope. The name and description distinguish it from sibling tools like get_estonian_company_accounts and get_latvian_company_officers.

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?

Description implies the use case (getting Latvian financial statements) and notes data source/refresh cadence, but does not explicitly compare to alternative tools or state when not to use. The context is clear but exclusions are absent.

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 readOnly and openWorld annotations by disclosing the official data source, daily refresh, empty list behavior for registered companies, GDPR minimisation of personal data, and the x402 payment requirement. These are critical behavioral traits not captured in structured metadata.

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 concise at three sentences, with each sentence serving a distinct purpose: stating the data source and fields, explaining empty list semantics, and disclosing GDPR constraints and payment. It is well-structured and free of redundancy, though slightly dense with detail.

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 and annotations, the description covers all crucial aspects: the data source, refresh cadence, empty list behavior, personal data handling, and payment. There are no apparent gaps that would prevent an agent from using 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 already provides full descriptions for both parameters (regnr and x_payment). The description adds value by specifying the exact cost ($0.02 in USDC or EURC) and clarifying the payment mechanism, which enriches the understanding of the x_payment parameter 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 clearly states the tool retrieves beneficial owners of a Latvian company from the official Uzņēmumu reģistrs, specifying the exact fields (name, nationality, country of residence, registration date). It also distinguishes from other country-specific tools by contrasting with France, making its scope unmistakable.

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 that this is for Latvian companies and contrasts it with France, implying it is the correct tool for Latvian UBO data. However, it does not explicitly list alternatives or state when not to use it, so it falls short of a perfect score.

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

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

Adds substantial behavioral context beyond the readOnlyHint/openWorldHint annotations: null end date means ongoing, no proceeding returns an explicit positive answer (aucune_procedure: true), data is a daily national photo since 2008, and the register is authoritative. It also discloses the x402 payment requirement with a fixed cost. 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 three well-structured sentences, front-loaded with the core resource and source, and every sentence adds value: data content, interpretation rules, negative-case behavior, and payment. No filler or redundancy.

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

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

Given the tool's simplicity (2 params, output schema present) and good annotations, the description is complete: it covers data provenance, time coverage, key field semantics, no-proceeding case, and payment flow. Nothing essential is missing for an agent to select and 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 coverage is 100%: regnr has a pattern and example, x_payment has a clear description including the 'omit to receive payment quote' behavior. The description adds tool-level cost context but no additional per-parameter meaning, so baseline 3 is appropriate.

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

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

The description clearly states it returns Latvian company insolvency and legal-protection proceedings from the official Uzņēmumu reģistrs open data, listing dates, resolution, court, and case number. This clearly differentiates it from sibling tools like get_latvian_company_accounts or get_czech_company_insolvency.

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 tool's scope is clear: use for Latvian insolvency/legal-protection records. It also provides important usage semantics such as null end date meaning ongoing and the explicit positive answer when no proceeding exists. It does not explicitly name alternative tools or when not to use, but country and subject specificity make the context 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?

Beyond the readOnlyHint and openWorldHint annotations, the description adds valuable behavioral context: GDPR minimization (never personal identity number, only birth month/year when published), payment via x402 with exact cost, and daily refresh from official open data. These are meaningful operational details not covered by 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 only two sentences, dense but well-structured. It front-loads the core purpose and data scope, then adds privacy and payment details without redundancy or 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?

The description covers data content, official source, refresh frequency, GDPR handling, and payment requirement. Since an output schema exists, return-value details are not needed. This is complete for a simple retrieval tool with existing structured metadata.

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

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

Schema coverage is 100% for both parameters. The description adds semantic value for x_payment by specifying the cost ($0.01 in USDC or EURC) and that it is a paid operation, which the schema does not mention. For regnr, it adds no new info beyond the schema's pattern and example.

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 specifies it provides Latvian company officers and directors from the official Uzņēmumu reģistrs, listing specific roles (board members, chairs, liquidators) and data fields (role, governing body, representation rights, registration date). This clearly distinguishes it from sibling tools like 'get_latvian_company_accounts' or 'get_uk_company_officers'.

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 explicit when-to-use or alternative tool references are given, but the country and focus on officers imply its use case. It does not mention exclusions or compare with other officer-related tools, so guidance is only implicit.

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

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

The description goes well beyond the readOnlyHint and openWorldHint annotations by explaining the data freshness (live latest, accumulated history), the source's behavior (only serves the latest year), the no-currency-conversion policy, the exclusion of banks/insurers, and the payment cost. This provides rich behavioral insight.

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, densely packed with essential information: purpose, data scope, content, source, limitations, currency, and payment. It is front-loaded with the purpose and avoids any filler or repetition.

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 and annotations, the description covers all critical context: official source, data freshness, content breakdown, currency, exclusions, and cost. It is complete enough for an agent to select and invoke the tool correctly without needing additional 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?

The input schema fully documents both parameters (id and x_payment) with descriptions and a regex pattern. The description does not add further parameter semantics, but with 100% schema coverage, the baseline of 3 is appropriate as the schema carries the burden.

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 provides annual accounts of a Norwegian company from the official Regnskapsregisteret, specifying the exact data elements (balance sheet, P&L). It distinguishes itself from sibling tools by naming the Norwegian source, the live fetch of the latest fiscal year, and the accumulation of earlier years, as well as the currency handling.

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: it fetches the latest filed fiscal year live and accumulates earlier years since 2026-07, implying when it is appropriate to use. It explicitly states a limitation: banks and insurers are not served by the source, serving as a 'when not to use' cue. It does not name alternative tools, but the context is sufficient.

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

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

Annotations only say readOnlyHint and openWorldHint. The description adds substantial behavioral detail: live re-checking at call time, explicit positive answer (aucun_evenement: true) when no events exist, meaning of origine_date vs. date_au_plus_tard, and the 3-year republication limit. It also discloses payment via x402 and refusal of non-legal entities, going well beyond 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 dense but every sentence earns its place: scope, behavior, source limitations, exclusions, and payment. It is front-loaded with the core purpose and then fills in critical edge cases, with no filler or repetition.

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 and presence of an output schema, the description covers the key decision-relevant context: what events are included, how no-event is represented, date semantics, time window, entity eligibility, and pricing. This is complete for an agent to select and 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?

Schema coverage is 100%: the only parameter (id) has a detailed regex and example, and x_payment is described. The description adds no additional meaning to the parameters themselves, but since the schema fully documents them, the baseline 3 is appropriate.

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

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

The description clearly states a specific verb+resource: it provides legal events (bankruptcy, voluntary winding-up, compulsory winding-up, strike-off) for Norwegian companies from the official Enhetsregisteret. It also names exact source and license (NLOD 2.0), and distinguishes itself from French BODACC, making the scope unambiguous relative to 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 provides explicit exclusions (natural-person forms, estates named after individuals, unrecognized forms are refused), and a clear context: Norwegian data is coarser than French BODACC, with a 3-year window except for still-open procedures. It lacks a named sibling alternative, but the when-not and limitations are clearly stated.

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?

Even though annotations declare readOnlyHint, the description adds substantial behavioral context beyond that: the semantics of `aucun_evenement: true` for both non-existent numbers and quiet companies, the `existence` block, the gap-free observation window, the GDPR design that discards free text, and the `date_source_inferee` flag. These details reveal edge cases and data handling practices that are not otherwise visible.

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 long but well-structured: it opens with the core event list, then explains the observation window, the existence-check caveat, GDPR constraints, and the paid nature. Each sentence conveys distinct information and earns its place. However, it is dense and could be streamlined; a more compact version might preserve clarity with shorter 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?

The description is exceptionally complete for a complex tool. It covers the data source, event types, response characteristics (observation window, `existence` block), limitations (no retroactive history, no existence check), GDPR compliance, and pricing. It even describes elements of the output schema (e.g., `date_source_inferee`, register section, wpis number) even though an output schema exists, making it easy for an agent to decide when to invoke this tool and what to expect.

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 already documents both parameters with 100% coverage: `krs` includes a pattern and example, and `x_payment` explains it's an optional signed header. The description adds minimal parameter-specific value beyond behavioral notes (e.g., that a non-existent number returns a specific response, which is more about output behavior than parameter semantics). Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: 'Registry EVENTS of a Polish company, derived from the official KRS daily bulletin (Krajowy Rejestr Sądowy, Ministry of Justice)' and enumerates the specific event types covered (liquidation, bankruptcy, restructuring, etc.). This distinguishes it from sibling tools that handle other countries' registry events (e.g., get_swedish_company_registry_events), and the specific source and scope make the 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 description provides explicit usage guidance, including a critical caveat: 'this endpoint does NOT check that the KRS number exists' and directs users to an alternative: 'get_european_company_profile (pays=PL) settles existence with a 404.' It also explains payment requirements ('Paid via x402') and the register's limitation ('the register publishes no retroactive event history'), giving clear when-to-use and when-not-to-use context.

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 discloses payment via x402 ($0.03), null handling for net turnover, euro-only amounts, and that data is never converted. These are valuable behavioral details not captured by 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 dense but well-structured: first sentence covers purpose, then data details, source/scope, and payment. The long enumeration of financial items is justified as it informs the agent about the exact content returned.

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 present, the description need not explain return values. It covers key context: data source, payment requirement, default scope, currency, and null semantics, making it complete for an agent to select and invoke the 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 covers all parameters, so baseline is 3. The description adds context about how date_cloture is used (from list endpoint), the default perimetre, and the payment cost, which enriches understanding 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 clearly states the tool decodes a Slovak fiscal year from structured filings with RÚZ, listing specific financial items. It distinguishes itself from sibling country-specific filing tools by naming Slovakia and the RÚZ registry.

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 mentions that the closing date comes from list_slovak_company_filings, implying a prerequisite call. It also notes the default statutory scope, but does not explicitly exclude alternatives or state when not 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?

Beyond the readOnlyHint and openWorldHint annotations, the description reveals important behavioral traits: DNI/NIE and sole-shareholder names are redacted, results are limited to 100 with total count, data since 2009, and a payment cost via x402. This significantly exceeds what annotations provide and helps the 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 information-dense but well-organized, starting with the main resource and then covering content, temporal scope, redaction, attribution, and payment. The Spanish attribution line is ancillary but not distracting; each 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 output schema exists, the description covers all necessary context: data source (BORME), content types, time range, ordering and limits, redaction policy, and payment requirement. This makes the tool fully actionable for an agent without needing to infer missing behavior.

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

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

Schema coverage is 100% with descriptions for both parameters. The tool description reinforces the hoja parameter with a concrete example (VI-23141) and ties it to search_european_companies, adding value beyond the schema. The x_payment parameter semantics are left to the schema, which 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?

Description clearly identifies Spanish BORME company acts as the resource, lists the specific event types (incorporations, officer changes, capital changes, mergers, dissolutions, insolvency), and specifies the unique identifier (hoja registral) and jurisdiction (Spain). This distinguishes it from sibling country-specific 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 how to obtain the required hoja key via search_european_companies, describes the data flow (daily, newest first), and mentions the result limit. It does not explicitly call out when not to use the tool or name alternatives, but the Spanish-specific scope and sibling names make this implicit.

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

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

Annotations already mark readOnlyHint and openWorldHint; description adds meaningful context: 'Free — the surveillance_id token IS the capability,' disclosing cost and capability-based auth. No contradictions.

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 short sentences that immediately state purpose, provenance, cost, and capability model. Zero filler or repetition.

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 a simple 1-param read tool, output schema present, and annotations covering safety, the description fully covers purpose, cost, creation linkage, and capability. No missing context needed to invoke 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 covers the single parameter with 'Token returned at creation' at 100% coverage. Description adds the key nuance that the token 'IS the capability,' reinforcing security/carrying meaning beyond 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?

Description states specific verb+resource: 'Status and accumulated events of a watchlist created with create_surveillance_watch.' This clearly distinguishes from sibling tools like renew_surveillance_watch and stop_surveillance_watch by focusing on read/status.

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?

Implies use after creating a watch with create_surveillance_watch, providing clear context. It does not explicitly contrast with renew/stop alternatives, but the read-only status/events purpose is evident.

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 significant behavioral context beyond the annotations: coverage limits, null meaning for turnover (K2 abridged, never zero), filing currency (SEK), all years in one call, and payment details. It aligns with readOnlyHint and openWorldHint, explaining why a company may be absent (paper filing). 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 dense and well-structured: starts with the core purpose, then lists key fields, then covers important caveats with clear warnings (IMPORTANT COVERAGE LIMIT). Every sentence provides distinct information; no fluff. Length is appropriate for the tool's complexity.

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 all essential aspects: data source, scope, field semantics, coverage limitations, excluded data (officers), currency, and payment. Combined with the provided output schema and annotations, the agent has complete context to decide when and 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?

Schema coverage is 100% for both params, but the description adds value by explaining the payment requirement (x402, $0.03 in USDC/EURC) and the null semantics for turnover which helps interpret the orgnr param's result. The orgnr param itself is already well-documented in the schema, so the description complements rather than repeats.

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 retrieves annual accounts of a Swedish company from official iXBRL filings, with specific fields listed. It also explicitly distinguishes from related tools by noting officers are not available, avoiding confusion with get_swedish_company_registry_events or other country-specific account 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?

Provides clear context on when to use: for annual accounts, with all digital fiscal years. It explicitly tells users not to expect officers and warns about coverage limits (digital filing optional, corpus starts 2020). However, it does not name alternative tools for officers or paper-only filings, so exclusion guidance is present but not fully explicit on 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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses critical behavioral details: only ongoing proceedings are published, struck-off companies return procedure_en_cours: false, and the register is authoritative for positive no-proceeding answers. It also clarifies the payment mechanism, providing substantial contextual transparency.

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 longer than the typical tool description, but each sentence serves a purpose: listing what events are included, providing a use case, explaining the no-proceeding response, noting the ongoing-only limitation, and stating the price. It is front-loaded with the core purpose and remains efficient without 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?

Given the complexity of legal registry events, the description covers the data source, inclusion criteria, return semantics for no-proceeding and struck-off cases, and the payment requirement. An output schema exists, and the description complements it by explaining edge cases and authoritative status, making the tool nearly 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?

Schema coverage is 100%, so both orgnr and x_payment already have descriptions. The tool description adds little about parameter syntax beyond what the schema provides, though it does mention the payment cost contextually. This aligns with the baseline of 3 when the schema does the heavy lifting.

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

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

The description clearly states the tool returns registry events (incorporation, ongoing insolvency/restructuring, deregistration) from Bolagsverket's official file for a Swedish company. It names specific verbs and data categories, and the mention of 'Swedish company' distinguishes it from siblings like get_polish_company_registry_events and get_swedish_company_accounts.

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 tells when to use this tool: 'Use it to check whether a Swedish counterparty is bankrupt, in liquidation or already struck off before signing or paying.' It gives a clear use case but does not mention alternatives or when not to use it, so it falls 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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses that data is live from Companies House, that ceased PSCs are excluded by default, that only month+year of birth is provided with no addresses, and that payment is required via x402. This adds substantial 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?

The description is moderately long but every sentence adds value, covering content, exclusions, geographic scope, data limitations, and payment. It's front-loaded with the core purpose.

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, the description covers the tool's scope, source, default behavior, limitations, and payment model. It's sufficiently complete for an agent to select and invoke 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 covers all 3 parameters with descriptions; the description adds context that inclure_cesses includes ceased PSCs with ceased dates, and that payment is via x402, but this mostly restates schema info. No new semantic depth for company_number or x_payment beyond 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 it retrieves UK beneficial owners/PSC data from Companies House, listing specific data points (natures of control, notification dates, PSC statements). It distinguishes from sibling tools by specifying UK-only and PSC focus, not officers or accounts.

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: it's for UK PSC data, and explicitly notes France has no open UBO register, guiding users away. It also explains default exclusion of ceased PSCs and how to include them. However, it doesn't explicitly name alternative tools for France or mention when to use e.g. get_uk_company_officers 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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses important behaviors: null values mean 'not published' and never zero, most small companies file only a balance sheet, and the tool requires payment via x402 ($0.05). It also clarifies that prior-year comparatives are included 'as published', adding nuance not captured by 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 dense yet efficient, front-loading the key scope ('One UK financial year') and then listing concrete contents. Every sentence provides useful information—what is included, null semantics, source of the date, and payment details—without any wasted words.

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 complete for a read-only retrieval tool: it specifies the data scope, expected fields, the optional nature of P&L, null handling, a prerequisite, and payment. An output schema exists, so return values are further specified there. Slight gap: no explicit error conditions, but openWorldHint and the null explanation cover most ambiguity.

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

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

Schema description coverage is 100%, so the schema already explains each parameter. The description adds marginal value by noting that date_cloture is the balance-sheet date and comes from list_uk_company_accounts, but it does not provide additional syntax or format details beyond the schema. This aligns with the baseline for high 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 identifies the tool as retrieving UK company financial statements for one financial year, specifically from iXBRL accounts filed at Companies House. It enumerates the exact contents (balance sheet, average employees, P&L), which distinguishes it from listing tools and other country-specific account 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 implies when to use it (for a specific UK company's financial year) and provides a crucial prerequisite: the balance-sheet date comes from list_uk_company_accounts. However, it does not explicitly name alternative tools or state when not to use it, though the sibling list makes the distinction 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?

Beyond the read-only annotation, the description explains key behaviors: it returns practitioner names/roles only (excluding addresses), provides a positive 'aucune_procedure' response when no case exists, and notes the data is authoritative and live. It also discloses the payment requirement, adding significant operational 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?

The description is three sentences, front-loaded with the tool's core purpose and enriched with essential caveats and payment terms. Every sentence adds value, and there is no redundant or verbose wording.

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 essential operational details: live source, authoritative status, no-case behavior, content limitations (no addresses), and payment cost/method. Since an output schema exists, return value documentation is not required, making this adequate for agent selection and 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?

The input schema already provides comprehensive documentation for both parameters (company_number pattern/example and the x_payment header semantics, including the omit-to-get-quote behavior). The description adds no additional parameter meaning, so the baseline score of 3 applies.

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

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

The description clearly identifies the tool as returning a UK company insolvency record from Companies House, specifying the types of cases and included data (dates, insolvency practitioners). This distinguishes it from sibling tools like get_czech_company_insolvency and get_latvian_company_insolvency by explicitly naming the UK jurisdiction and official source.

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 implies this tool is for retrieving UK insolvency data by naming Companies House and the UK, but it does not explicitly state when to use it over country-specific siblings or mention exclusions. It lacks explicit alternative guidance, though the contextual scope is obvious.

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 annotations by disclosing payment requirements ($0.01 via x402), data minimization (never correspondence address), licensing (OGL v3.0), and the live nature of the data. These are critical behavioral traits for an agent to know, and no contradiction with readOnly/openWorld hints 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 a single, information-dense paragraph with no waste. It front-loads the core function, then efficiently covers key field nuances, counts, license, and payment. Every phrase contributes 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?

With an output schema present and only two parameters, the description provides all necessary operational context: data source, exact fields, payment, licensing, and data minimization. It does not need to explain return structure, and the tool's scope is fully covered.

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

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

Schema description coverage is 100% for both parameters, with clear descriptions for company_number (pattern, example) and x_payment (payment quote behavior). The description adds the cost context but does not need to reiterate parameter details, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool retrieves UK company officers and directors from Companies House, specifying the exact data fields and distinguishing it from sibling tools like get_uk_beneficial_owners and get_danish_company_officers. The resource and source are 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?

Usage context is implied through 'UK company officers and directors, live from Companies House' but no explicit alternatives or when-not-to-use guidance is given. Given many sibling tools, explicit comparison would improve clarity, but the description sufficiently indicates its scope.

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 indicate read-only and open-world behavior. The description adds valuable context: the tool is paid via x402 ($0.01), it returns authentic data 'as published,' and it uniquely exposes Belgian filed accounts. 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 concise and front-loaded, with three sentences each adding value: main purpose, uniqueness claim, and payment requirement. No unnecessary words.

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 list tool with an output schema and strong annotations, the description covers the essential aspects: what it lists, the authoritative source, payment, and output nature. It does not discuss pagination but that is reasonably expected to be in the output schema.

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

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

Schema coverage is 100% and both parameters are well described in the schema (10-digit KBO/BCE format and x402 header behavior). The description adds cost context but no further parameter semantics beyond what the schema provides, so baseline 3 applies.

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

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

The description clearly states the tool lists every published deposit (annual accounts) of a Belgian company at the NBB CBSO, and specifies the output as 'deposit references with filing metadata as published.' It also differentiates from siblings by claiming uniqueness on x402 for Belgian filed accounts.

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

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

Provides clear context for when to use this tool (whenever Belgian filed annual accounts are needed) and asserts uniqueness, but does not explicitly name alternatives or exclusion criteria (e.g., 'for a single filing, use get_belgian_company_filing').

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 openWorldHint annotations, the description discloses critical behavioral traits: the tool is paid via x402 ($0.01), only decoded Danish-taxonomy filings are included, and an empty result may indicate a coverage gap rather than absence of accounts. This adds substantial value 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?

The description is concise and well-structured: it front-loads the core purpose, then adds necessary qualifications and payment details in three sentences. Every sentence contributes meaningful information without redundancy.

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