Sirenic

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

Annotations already mark the tool read-only and open-world; the description adds beyond that by disclosing the official AMF open-data source, daily refresh cadence, and the x402 payment requirement with a $0.01 cost. These are non-obvious behavioral traits not inferable from 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?

Three sentences pack purpose, use case, data source, freshness, and payment cost with no filler. The core action is front-loaded in the first sentence, and every clause carries useful 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 paid, four-parameter tool with an output schema and read-only/open-world annotations, the description covers the key selection and invocation facts: what it checks, who it is for, where the data comes from, how fresh it is, and what it costs. Missing pieces like payment-quote behavior and parameter requirements are already covered in the input 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 the schema already explains that nom is the name to screen, siren is the 9-digit SIREN for PSAN/SGP lookup, and api_key/x_payment handle payment. The description's 'by name or SIREN' phrase restates the schema rather than adding new parameter meaning, so the baseline of 3 applies.

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

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

States a clear verb-resource pair: 'screen a name against the official AMF blacklists' and 'look up PSAN crypto-provider registrations and licensed asset-management companies (SGP) by name or SIREN.' The French-regulator scope and scam-check framing distinguish it from sibling tools like screen_sanctions_lists and search_eu_financial_authorisations.

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 when to reach for it: 'Use before trusting an investment site, a crypto provider or an asset manager operating in France.' It gives a clear trigger context but does not spell out exclusions or alternative sibling tools, so no full when-not-to-use 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 goes well beyond the readOnlyHint/openWorldHint annotations: it details the exact return composition (cross-table, per-axis rankings, comparabilite block), explicitly warns that it 'NEVER returns an overall winner', explains why that matters, and discloses billing behavior including the per-SIREN pricing formula. This gives the agent crucial expectations for interpreting 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 dense but every sentence carries distinct value: use case, return contents, a critical interpretive caveat, and billing. It is front-loaded with the most important routing information and avoids fluff or repetition of schema details.

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

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

Given the output schema exists and annotations cover read-only/open-world behavior, the description is complete for selection and invocation. It covers what the tool returns, what it deliberately does not return, when comparisons may be invalid, and the billing model. An agent has enough to decide when to call it 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?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by explaining how the sirens parameter drives cost ('$0.12 per company... unit price times the number of SIREN') and by framing the sirens list as a comparison batch. This pushes it above baseline, though the schema already covers the core meaning of each parameter.

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

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

The description opens with a precise use case: 'compare, rank or choose between 2 to 5 French companies (suppliers, candidates, competitors)'. This states the verb, resource, and scope clearly, and the focus on comparison/ranking distinguishes it from the many single-company retrieval siblings like get_french_company_profile or get_french_company_financials.

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 tells the agent when to use the tool ('Use when asked to compare, rank or choose between 2 to 5 French companies') and states a hard size limit. It does not explicitly name alternative tools for single-company lookups or for comparisons outside the range, so it misses the 'when-not/alternatives' element 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?

The description reveals substantial behavior beyond annotations: daily Sirenic monitoring, BODACC and other event sources, Ed25519-signed webhook/e-mail delivery, pollable bearer token, expiry reminder, x402 payment flow, quote behavior when x_payment is omitted, no pro-rata refund, and the spendControls rejection pitfall. This far exceeds what the annotations alone communicate.

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 every sentence earns its place: purpose, usage condition, monitored data, delivery, expiry, payment model, pricing, refund policy, and a critical client-side configuration caveat. It is front-loaded with the core purpose and use-case before descending into operational details.

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

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

For a paid, recurring watch creation tool with external side effects, the description covers selection criteria, what gets monitored, delivery mechanisms, authentication alternatives, payment amounts, refusal conditions, and the required client-side payment configuration. Nothing needed to call this tool safely is missing.

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

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

Even though schema description coverage is 100%, the tool description adds real semantic value: it explains pricing per duration, the unit-price-per-target calculation, the distinction between api_key and x_payment, and the critical spendControls caveat that can cause the client to reject the quote before calling the service. This materially helps an agent use the parameters correctly.

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 and resource: create a surveillance watch over French companies and/or directors. It further distinguishes itself from one-off check tools by framing the use case as 'when the relationship OUTLASTS the check', which is unambiguous.

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

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

It gives an explicit selection condition — use when the relationship outlasts the check, with concrete examples like supplier, borrower, or portfolio company. It does not explicitly name sibling alternatives for one-off checks or for managing existing watches, 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?

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?

With only readOnlyHint and openWorldHint in annotations, the description carries the behavioral burden and delivers: return format (PDF as base64), expected payload size (1-10MB), and cost disclosure (x402, $0.10 in USDC or EURC). Parameter descriptions add payment semantics: prepaid credits via api_key, 'the signed payment wins' precedence, and the credits-error behavior on insufficient balance. Downloading is consistent with readOnlyHint; no contradiction.

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

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

Four sentences, each with a discrete payload: action and source, ID provenance, return format and size, payment and cost. The verb is front-loaded and there is zero filler; voluminous details like enum values and payment mechanics are correctly left to 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?

For a paid tool with 4 params and no output schema, the definition covers the essentials: source registry, return format, size estimate, cost, and two payment methods (x402 and prepaid credits). The only gap is that the two-step x402 flow — call once to receive a quote, then resubmit with a signed payment — must be inferred from the x_payment and api_key parameter descriptions rather than stated once as an explicit workflow.

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 — all four params already have meaningful help text, including the enum values for type and the provenance of document_id. The description reinforces that document_id comes from the list tool, but adds no syntax, format, or value details beyond the schema, so it neither needs nor earns more.

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

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

States a specific verb ('Download'), a specific resource ('official company document (PDF) from the INPI RNE registry'), and concrete document types (statutes, general-meeting minutes, filed annual accounts). The registry source and PDF nature distinguish it from related siblings like get_french_company_pdf_report or get_french_company_file, so an agent can tell what it does without opening the schema.

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

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

The description establishes the prerequisite workflow explicitly: 'Use IDs from list_french_company_documents,' telling the agent exactly which sibling produces its inputs. It does not name alternatives or exclusions (e.g., when to prefer get_french_company_pdf_report for a synthesized report), so it stops short of full when/when-not guidance.

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

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

Annotations already carry readOnlyHint=true and openWorldHint=true, so the safety profile is covered and the bar is lowered. The description adds valuable behavioral context beyond annotations: the paid nature of the call ('Paid via x402 ($0.05 in USDC or EURC)'), the data-source limitation ('duration amendments are absent from the source'), and the nuance that end dates reflect initial declared duration only. No contradiction with annotations — the read-only, anticipatory framing is fully consistent.

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 sentences, front-loaded with purpose and timing logic, then filters, returns, source, and cost — every sentence earns its place. The typographic emphasis ('EXPIRING', 'BEFORE') highlights the two most decision-relevant facts without padding, making this a model of tight, well-ordered tool documentation.

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 6 parameters, a payment mechanism, and an output schema, the description covers the key operational facts: the 4-9 month re-tendering insight, the data-source caveat, the cost, and a return summary. The api_key/x_payment dual payment paths and detailed output structure are already present in structured fields, so nothing an agent needs to invoke this tool correctly is missing.

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

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

Schema description coverage is 100%, with every parameter (cpv, page, api_key, x_payment, departement, fenetre_mois) already documented in the input schema. The description recaps the window default and CPV/department filters but adds no parameter semantics beyond what the schema provides, so the high-coverage 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 opens with a specific verb and resource — 'Tender anticipation for France: public contracts EXPIRING within a window' — and sharpens scope with the 1-24 month window, CPV/department filters, and return contents. The phrase 'surfaces opportunities BEFORE any notice is published' clearly differentiates it from notice-based siblings like search_bodacc_announcements and get_french_company_public_procurement. This is a precise, unambiguous purpose 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 supplies strong decision context: buyers re-tender 4 to 9 months before expiry, so the tool is for proactive tender anticipation rather than post-publication search. It does not explicitly name sibling alternatives or state when-not-to-use conditions, but the emphasis on 'BEFORE any notice is published' implicitly demarcates it from published-notice tools. This is clear context without formal 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 mark the operation read-only and open-world, and the description adds meaningful behavioral details: deposits are immutable, the returned format depends on publication date, and the call is paid via x402 at a fixed price. 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?

Two tight sentences plus a payment clause; the main capability, format split, source requirement, immutability, and cost are all stated with no filler. Front-loaded with the primary 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?

No output schema exists, so the description's statement of JSON-vs-PDF return format is important and sufficient at a high level. Payment behavior and reference provenance are covered; only finer error/quote-flow details are left to the parameter descriptions, which is acceptable.

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 four parameters, and the description adds the key provenance cue that reference must come from list_belgian_company_filings. It also reinforces the payment context of x402, though the schema already documents api_key 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 opens with a specific action and resource: 'One Belgian annual-account deposit as filed', then clarifies exactly what is returned (structured JSON vs official PDF depending on filing date). This distinguishes it from list_belgian_company_filings and other European filing 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?

It states the required input provenance ('Reference comes from list_belgian_company_filings'), which effectively tells the agent to first list filings before retrieving one. It does not explicitly mention when not to use the tool or compare against alternatives, but the list-vs-get relationship 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 goes well beyond the readOnlyHint and openWorldHint annotations by disclosing that no individuals are ever named, the breakdown is withheld when it would single someone out, the data covers a rolling 12-month period, and access is paid via x402. These are meaningful behavioral details an agent could not infer from annotations or schema alone.

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 each sentence contributes: scope, output contents, privacy constraints, intended use, and payment. It is somewhat longer than strictly necessary, but no sentence is pure 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 rich schema descriptions, output schema, and annotations, the description covers the remaining operational context: privacy redaction, rolling time window, aggregations, intended use, and payment mechanism. Nothing critical for selecting or invoking the tool correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents all parameters including id, depuis, api_key, and x_payment. The description only adds high-level payment context ($0.02 via x402) and does not meaningfully extend parameter-level meaning.

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

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

The description clearly states the specific resource: insider transactions at a Belgian listed company under MAR Article 19, as notified to the FSMA. It lists exact aggregate outputs such as notification counts, gross buy/sell amounts, net flow, and declarer-category breakdown, which distinguishes it from sibling country-specific tools like get_german_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 gives a clear use case: 'Use it as a governance signal before investing in or contracting with a listed Belgian company.' It does not, however, explicitly state when not to use it or name alternative sibling tools for non-Belgian companies.

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 already set, the description adds valuable behavioral context: data sources (EBA, EIOPA, ARCEP), daily refresh, the fact that absence of authorisation is itself a valid outcome, and the x402 payment requirement with its cost. This goes beyond the annotations and helps the agent set expectations, though it does not detail return-shape nuances.

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

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

Two dense sentences carry the full purpose, scope, use case, data sources, and commercial terms without redundancy. The most decision-relevant information is front-loaded, and every clause 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?

For a read-only lookup with one required parameter, full schema coverage, an output schema, and clear annotations, the description is complete. It covers what data is returned, which registers are consulted, freshness, the 'no licence' case, and how payment works — everything an agent needs to decide whether and how to invoke it.

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

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

Schema description coverage is 100%, and each parameter already has a meaningful description. The tool description adds context about the SIREN-based lookup and payment method, but it does not add new semantic meaning to the individual parameters beyond what the input schema already provides.

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 returns — regulatory authorisations of a French company by SIREN — with a concrete enumeration of regulator types and registers. It is highly specific about scope and content, though it does not explicitly distinguish itself from the related sibling search_eu_financial_authorisations and is phrased as a nominal description rather than a verb-led 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 concrete use cases: 'Use it before paying, onboarding or contracting with a regulated counterparty.' It also clarifies that a negative result is meaningful ('Not authorised is an answer too'). However, it does not state when not to use it or explicitly name alternative tools, such as the broader EU authorisation search.

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 meaningful behavioral context beyond the readOnlyHint/openWorldHint annotations: it discloses the paid nature ('$0.02 in USDC or EURC'), the official DECP open-data source, and the 3-year lookback window. The payment-quote flow when x_payment is omitted is left to the parameter schema, but the schema covers it, so there is no contradiction.

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

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

Two dense sentences efficiently convey the value proposition, the matching logic, the output contents, the data source, and the payment method. There is no filler, and the essential purpose is front-loaded before the supporting 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?

For a read-only tool with one required parameter and a provided output schema, this description is complete enough for an agent to select and invoke the tool correctly. It covers purpose, scope, time window, output highlights, source, and pricing, while the schema handles parameter-level details.

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

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

Schema description coverage is 100% and each parameter already has a clear description, so the baseline is solid. The tool description adds extra semantic value for siren by explaining that it is the company whose CPV segments are used to discover rival contractors, which goes beyond the schema's plain '9-digit SIREN' label.

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 leads with a specific deliverable ('competitive intelligence on French public procurement') and precisely defines the mechanism: matching the same CPV segments as a given SIREN and returning top rival contractors with counts, amounts, and shared segments over 3 years. This clearly differentiates it from related sibling tools like get_french_company_public_procurement or get_eu_procurement_awards.

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

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

The intended use case is clear: use this when you need to see which other companies win contracts on the same CPV segments as a French company identified by SIREN. It does not explicitly name alternative tools or list when-not-to-use scenarios, so it falls just short of fully explicit routing guidance.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds substantial behavioral detail: events capped at 100 recent per case, truncation flags, the explicit no-proceeding positive answer, stale-collection 503 behavior, GDPR-driven natural-person exclusion, and x402 payment. This goes far beyond the structured metadata and gives the agent reliable expectations.

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

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

The description is dense but each sentence carries meaningful behavioral or scoping information — no filler. It is front-loaded with the core identity of the tool, and while the paragraph is long, the length is justified by the number of edge cases an agent must know.

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 the tool's complexity, the description covers all important operational behaviors: data source, date range, cap and truncation indicators, no-procedure semantics, staleness handling, legal-person restrictions, and payment options. An output schema exists to detail the return structure, so the description is complete for selecting and invoking 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%, so the baseline is 3. The description adds meaning beyond the schema by clarifying that the ico must belong to a legal person and that natural-person IČOs are rejected, plus the payment flow for api_key and x_payment. This added context justifies a score above baseline.

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

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

The description states a specific resource (Czech insolvency record from the official ISIR register) and a clear purpose: retrieving every proceeding for a company. It differentiates itself from sibling insolvency tools by naming its country, jurisdiction, and data scope, so an agent can select it correctly.

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

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

The description gives clear usage context: it is for Czech legal-person companies and explicitly excludes natural persons, whose IČOs are refused. It does not name an alternative tool for natural persons or other countries, so it stops short of the explicit when-not/alternative guidance that would earn a 5.

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

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

Annotations already provide readOnlyHint, so the safety profile is covered. The description adds valuable behavioral detail: null revenue means not published rather than zero, amounts are in the filing currency, prior-year comparatives come from the same filing, and the official XBRL document URL is included. This goes well beyond what the annotations or name alone communicate.

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 with the core function and returned fields front-loaded. The payment information is relevant and the use of a colon-delimited field list keeps it scannable. No filler or repetition of schema 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?

An output schema exists, so detailed return-format documentation is unnecessary. The description covers scope, input sourcing, key null/currency semantics, and payment mechanics, giving an agent everything needed to call the tool correctly. The reference to list_danish_company_filings closes the main contextual 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?

The schema already covers all 4 parameters at 100%, so the baseline is 3. The description adds extra semantic value by instructing that date_cloture comes from list_danish_company_filings and by clarifying the fiscal-year meaning. It also adds currency context that affects interpretation of returned values.

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

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

The description uses a specific verb ('get') and resource ('Danish company filing') and enumerates the exact financial fields returned, making its function unmistakable. It explicitly references the sibling list_danish_company_filings for the closing date, which distinguishes the retrieval tool from the listing tool. Country and filing scope also separate it from other country-specific get_*_filing 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 tells the agent that date_cloture must come from list_danish_company_filings, giving a concrete prerequisite and routing signal. It also explains payment behavior between x_payment and api_key. It stops short of enumerating when-not-to-use cases for all sibling tools, so it is clear but not exhaustive.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses many non-obvious behaviors: mandate election details, active-versus-ended defaults, the 300/200 cap with exact counts and the `tronque` flag, GDPR minimization, the absence of beneficial owners, and the payment mechanism. This goes well beyond what annotations alone convey.

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

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

The description is front-loaded with the core purpose and packed with dense, relevant caveats about limits, exclusions, GDPR, and payment. Every clause earns its place, and the structure moves from what the tool does to how it behaves to how it is paid for.

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 fills all meaningful gaps: mandate types, default behavior, truncation semantics, missing beneficial owners, GDPR constraints, and payment details. An agent has enough to select and invoke the tool correctly without needing external context.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds useful meaning beyond the schema, especially for inclure_anciens (ended mandates, where founders normally appear) and the payment flow (x402, prepaid credits, and error behavior). It does not restate every parameter but enriches several.

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

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

The description names a specific verb ('get'), a precise resource (Danish company officers and directors), and the authoritative source (CVR/Ehvervsstyrelsen). It enumerates the exact mandate types returned, clearly distinguishing it from sibling officer tools for other countries.

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

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

It gives clear context for when to use the tool: for Danish officers and directors, with active mandates by default and ended mandates via inclure_anciens. It also notes beneficial owners are not exposed, which signals a limitation, though it does not explicitly name alternative tools or state 'use this only for Denmark'.

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

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

Annotations already declare readOnlyHint=true, but the description adds substantial behavioral context: the data is from the official RIK open data with CC BY 4.0 license, refreshed monthly, and all figures are in EUR as published (null means not published, never zero). It also discloses that payment via x402 is required ($0.02 in USDC or EURC) and explains the handling of PDF-only filings. This goes well beyond the annotation and gives the agent a complete picture of the tool's behavior and side effects.

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 but is front-loaded with the core purpose and specific fields. Each clause adds important information: data source, refresh cadence, scope, exclusions, and payment. While it is long, it is well-organized and every sentence contributes value; nothing is wasted. The structure could be broken into clearer points, but efficiency is high.

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: the exact data returned (list of fields), the source and license, refresh frequency, handling of missing values, statutory vs consolidated, exclusions, and payment mechanism. An output schema exists (though not shown here), so return-format details are presumably structured there. For an agent to select and invoke this tool correctly, nothing critical is missing.

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

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

The input schema covers all three parameters with detailed descriptions: registrikood has a pattern and example, and api_key and x_payment are fully explained. With 100% schema description coverage, the tool description does not need to add parameter-level detail. The description does mention payment, but that is a tool-level property, not a parameter semantic. A baseline score of 3 is appropriate, as the description adds no extra 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's function: retrieving Estonian company annual accounts with a specific list of financial fields. It distinguishes itself from siblings by explicitly naming the country (Estonian) and the data source (official e-Business Register), and contrasts with PDF-only filings that are not served. This makes it unambiguous versus 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 provides concrete usage context: it returns all published financial years since 2019, distinguishes statutory from consolidated figures, and notes that PDF-only filings are excluded. However, it does not explicitly reference alternative sibling tools (e.g., get_latvian_company_accounts) or state when to prefer them, leaving cross-country routing implicit. Still, the exclusions and scope give clear guidance for the intended use case.

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

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

Far exceeds what annotations provide (readOnlyHint=true, openWorldHint=true). It discloses genuinely non-obvious behaviors: the fail-closed counting logic for nombre_alertes (unknown etat_codes count, only L is excluded), the deliberately closed warning-type list behind alerte, the types_non_qualifies guard so a zero is never misread as 'no warning', and the 404-instead-of-false-clean-sheet behavior for struck-off entities. No contradiction with the read-only annotation — this is a pure query tool.

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

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

The description is dense and long, but every clause earns its place — the alert-counting semantics, fail-closed behavior, and 404 distinction are all load-bearing for correct invocation and interpretation. Core purpose and data source are front-loaded before the intricate flag details. Slightly over-packed as a single paragraph, but there is zero filler.

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

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

For a tool with an output schema, annotations, and genuinely tricky edge-case semantics, the description is exceptionally complete: it covers data source and licensing, the closed warning-type list, counting exclusions, the positive-answer vs 404 distinction, and pricing. An agent knows what to expect in every outcome state (registered-with-rulings, registered-no-rulings, struck-off, unknown-state) without probing the live API.

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

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

Schema description coverage is 100% with detailed per-parameter descriptions (api_key explains the credits fallback and precedence over x_payment; registrikood gives the 8-digit pattern and example). The description adds some complementary context by explaining the x402 payment flow and $0.02 cost, but it doesn't need to compensate for schema gaps since none exist. 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 states a specific verb and resource — retrieving registry rulings (määrused) of an Estonian company from the official e-Business Register open data — and details exactly what kinds of rulings are included (remedy orders, strike-off warnings, dissolution warnings, annual-report fines). It is clearly differentiated from siblings by resource type (rulings vs accounts, filings, officers) and jurisdiction (Estonia vs French/Belgian/etc. 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 behavioral context about when meaningful answers are returned (explicit positive answer for a registered entity with no rulings; 404 for struck-off entities), but it never explicitly states when to choose this tool over alternatives or when not to use it. The closest sibling, get_estonian_company_accounts, is never mentioned, so an agent must infer selection from the resource name alone.

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 declare readOnlyHint and openWorldHint; the description adds crucial behavioral context: identifier-matched only with SIREN/SIRET variants, coverage limitations, the payment mechanism via x402, and the API-key fallback. It also clarifies error behavior for insufficient credits. 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 dense but every clause carries value: source, data fields, matching constraints, coverage caveat, sibling differentiation, and payment terms. It front-loads the core purpose before limitations and alternatives.

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 tool has only one required parameter, the description is complete. It covers the meaning of results, data source, identifier limitations, empty-result interpretation, the sibling alternative, and payment/commercial behavior. Nothing essential is missing.

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

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

Schema description coverage is 100%, so the parameters are already well documented and baseline is 3. The description adds extra meaning for the siren parameter by explaining identifier matching including spaced variants, which clarifies how the 9-digit input is used in practice.

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

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

The description states a clear, specific purpose: retrieving EU public procurement award notices won by a French company from official TED data, with enumerated fields (buyer, country, subject, amount, CPV codes, links). It also distinguishes itself from the sibling get_french_company_public_procurement, so an agent can tell them apart without opening the schema.

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

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

It explicitly names the complementary sibling and contrasts their scopes: EU TED above-threshold eForms vs French DECP below-threshold. It also supplies practical coverage guidance, including the date threshold, the ~57% identifier coverage, and the warning that an 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?

The annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context: it is a paid x402 tool at $0.01, it returns the same JSON schema across countries, and it falls back to GLEIF for non-covered countries. No contradiction with the annotations.

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

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

The description is front-loaded with the core purpose and then enumerates covered countries, output characteristics, and payment in a compact sentence. While dense, every element earns its place because the country list is not expressed anywhere in 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 multi-country complexity and the presence of an output schema, the description is complete: it specifies supported countries, the unified schema, the fallback via GLEIF, and the payment requirement. There is no critical decision-making information missing.

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

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

Schema description coverage is100%, so the baseline is 3. The description reinforces that 'id' is a national register identifier and 'pays' is a country code, but adds no new parameter semantics beyond what the schema already documents.

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

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

The description uses a specific verb and resource: it is a European company registry lookup returning a unified profile by country and national register ID. It clearly distinguishes itself from siblings like get_french_company_profile and search_european_companies by defining the exact input and scope, and by enumerating the covered registries.

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 this tool when you have a country code and national register ID and want a standardized company profile. It does not explicitly name alternatives for cases like searching without an ID, so it misses the top score, but the coverage caveat for Denmark/UK and GLEIF fallback provides useful boundary conditions.

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

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

The description adds meaningful behavior beyond annotations: null revenue means 'not published, never zero', values are EUR, prior-year comparatives are included, and a $0.15 x402 fee applies. This is consistent with readOnlyHint and openWorldHint, and there is no contradiction.

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

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

Three dense but purposeful sentences cover what the tool returns, a key input source, and pricing. There is no filler, and the primary purpose is front-loaded in the opening clause.

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 full parameter schema, output schema, and annotations, nothing essential is missing: required inputs are identified, the source of a required value is given, cost is disclosed, and key null semantics are clarified. The tool can be invoked correctly from this description alone.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description adds the useful hint that date_cloture comes from list_finnish_company_filings, but it does not substantially expand parameter semantics beyond what the schema provides.

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

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

The description states a specific verb and resource: returns financial statements for one Finnish fiscal year from the company's PRH XBRL filing. It lists the exact fields returned, which clearly distinguishes it from list_finnish_company_filings and from other countries' filing 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?

It gives clear workflow context by stating the closing date comes from list_finnish_company_filings, telling the agent where to obtain a required input. It does not explicitly enumerate alternatives or exclusions beyond that, but the one-fiscal-year scope and companion-list relationship provide sufficient guidance.

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

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

Annotations already indicate readOnlyHint and openWorldHint, and the description adds meaningful behavioral context: data is AI-extracted, reconstructed from public filed deeds rather than an official beneficial-ownership register, includes confidence and source document, and costs $0.35 via x402. This goes well beyond the annotations and helps the agent set expectations about reliability, provenance, and payment.

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

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

The description is compact and front-loaded with the core purpose, then adds the critical caveat about not being a beneficial-ownership register, and finally notes the payment requirement. Every sentence adds essential information without fluff 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 annotations, fully documented input schema, and presence of an output schema, the description provides everything an agent needs to select and invoke this tool correctly: source, content, caveats, pricing, and payment context. Nothing critical is missing.

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

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

The input schema has 100% description coverage, with detailed explanations for siren, api_key, and x_payment. The tool description does not need to repeat parameter semantics; the baseline of 3 applies because the schema already carries the full 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 the tool returns ownership/share capital structure extracted from French public articles of association, including specific data fields. It distinguishes itself from beneficial-ownership registers, though it lacks a strong verb phrase and does not directly contrast with other French company data tools like get_french_company_profile.

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: when share capital, legal form, or shareholder details from INPI-filed articles are needed. It also explicitly says it is NOT a beneficial-ownership register, which is a useful exclusion, but it does not name alternative tools or state clear when-to-use versus when-not-to-use guidance beyond that caveat.

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 readOnlyHint/openWorldHint, the description discloses that results are reverse-chronological, that no new announcement yields an empty list, that detection is at publication level rather than field edits, and that calls are paid via x402 at $0.01. This gives agents concrete expectations 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 core behavior is front-loaded in the first sentence, followed by a single clarifying sentence covering detection granularity, empty-list behavior, and payment. Every sentence earns its place with no filler.

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

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

For a read-only polling tool with annotations and an output schema present, the description covers purpose, return expectations (empty list, reverse-chronological), payment/auth context, and detection scope. Nothing critical is missing for correct 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 schema already covers all four parameters with descriptions at 100% coverage, so the baseline is 3. The description adds cost context ($0.01 via x402) and clarifies that `depuis` is used for repeated poll-mode surveillance, but it does not substantially extend parameter-level meaning.

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

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

The description names a specific resource ("new official BODACC gazette announcements") and action ("Detects new BODACC publications") for a French company since a date. It also distinguishes itself from related tools by noting it is poll-mode watchlist surveillance and explicitly not field-level profile edits.

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 intended context: monitoring a portfolio of French companies by polling BODACC announcements since a date. It includes a scope exclusion ("not field-level edits of the profile") but does not explicitly name alternative tools or state when-not-to-use, so it stops short of a 5.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses meaningful behavior: scoring inputs, the hard BODACC override, the returned components, the decision-support caveat, and the x402 payment requirement. No annotation contradiction 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 dense but efficient: it front-loads the core purpose and scoring basis, then covers output, caveats, and payment. Each clause adds information, and the longest sentence is still purposeful rather than padded.

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 rich input schema, output schema, and annotations, the description is complete: an agent can determine the required SIREN, the payment options, the expected output, the scoring logic, and the decision-support limitation. Nothing essential to invoking the tool correctly is missing.

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

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

Schema description coverage is 100% for all three parameters, so the schema already explains siren, api_key, and x_payment. The tool description adds pricing context and the payment flow, but it does not add new semantic meaning to the parameters beyond what the schema provides.

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

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

The description states a specific outcome: a 0-100 default-risk score for a French company at ~12 months, built from financial ratios and BODACC data. It goes beyond a generic 'get risk' statement by naming the output composition (score, band, components, confidence) and explicitly carving out that it is not a solvency opinion or credit rating.

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

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

The description makes the intended use clear: scoring French company default and insolvency risk from filed financial ratios and a BODACC insolvency override. It also gives a when-not signal ('NOT a solvency opinion or credit rating'), but it does not name alternative sibling tools or explicitly say when to pick this over a health summary or financials tool.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true. The description goes far beyond them by detailing cost per block, total cap, block-level error naming with a closed list of reasons (aucune_donnee, non_diffusible, panne_amont), and the 503/no-charge behavior when all blocks are down. It also explains payment methods (x402, api_key) and precedence rules. This richly discloses behavior 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 compact yet information-dense: it states purpose, cost model, error behavior, alternative, and payment in rapid succession. It is front-loaded with the main purpose and every sentence carries necessary information. 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?

For a tool with many blocks, pricing, and error handling, the description covers all operational concerns an agent needs to decide and interpret results. The output schema exists, so return format is covered. It includes the 503 case, payment methods, and the block failure reason list, making it fully actionable.

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

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

Schema description coverage is 100%, and the schema already documents each parameter in detail (e.g., api_key's role, x_payment handling). The description adds value by explaining the cost implication of the 'blocs' parameter (each block costs what its dedicated endpoint costs, capped at $0.35) and the block-level error reasons. This enriches parameter meaning beyond the schema, so a 4 is appropriate.

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

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

The description opens with 'Full French company file in ONE call' – a specific verb, resource, and scope. It clearly distinguishes itself from dedicated endpoints and names the sibling intelligence tool as an alternative. The list of available blocks and the cost structure make the purpose 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?

It states the exact condition for use: 'when you need several things about the same company and do not want to chain calls.' It also gives an explicit alternative: 'For a verdict rather than raw blocks, use get_french_company_intelligence.' This is clear when-to-use and when-not-to-use guidance.

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

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

Annotations already indicate readOnlyHint and openWorldHint. The description adds valuable behavior context: the data source (filed accounts via INPI/Banque de France), the 10-fiscal-year limit, the inclusion of structured tax-form fields, and the $0.01 x402 payment requirement. This goes beyond what annotations provide.

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 core purpose and followed by pricing. There is minor redundancy ('financial statements data' after 'Annual accounts') and the first sentence is dense, but every sentence earns its place and no filler exists.

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 rich annotations, the description covers the essential gaps: data source, included items, time window, and cost. Payment-flow details (e.g., omit x_payment to get a quote) are covered by the schema descriptions, so nothing critical is missing for calling 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 description coverage is 100%, and the description itself adds no parameter-level detail beyond what the schema already states for siren, api_key, and x_payment. Baseline 3 is appropriate since the schema fully documents each parameter.

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

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

The description names a specific verb ('get') and a precise resource ('French company financials'), then lists concrete data elements: revenue, EBITDA, net income, ratios, and the full liasse fiscale. This clearly distinguishes it from sibling tools like get_french_company_profile or get_french_company_health_summary by focusing on annual accounts and tax-form line items.

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 this tool when you need French company annual accounts, financial statements, or liasse fiscale data from INPI/Banque de France. It does not explicitly name alternatives or exclusion conditions, but among the many French company siblings the scope is evident enough from the name and listed data.

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 readOnlyHint/openWorldHint annotations: bilingual output, official-data-only sourcing, the model/guardrail behavior with divergences_modele, the non_concluant fallback, 7-day caching, and x402 payment. It fully discloses the tool's behavioral contract.

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: purpose, output composition, model-governance behavior, edge-case behavior, alternative routing, caching, and pricing. It is structured logically from core function to caveats to operational details.

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

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

For a tool with one required parameter and a rich output schema, the description covers all essential invocation context: what the tool returns, when it returns non-conclusive results, when to prefer a sibling, and cost/payment. Nothing an agent needs to decide or understand before calling is missing.

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

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

Parameter schema coverage is 100%, so the schema already documents siren, api_key, and x_payment in detail. The description adds economic context ($0.15 payment, cache) but does not deepen meaning of the parameters themselves. Baseline 3 is appropriate given full 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?

States a specific verb and resource: a business-health and risk read-out of a French company. Explicitly lists the output components (verdict, strengths, warning signs, activity trend, confidence level, reconciled grid), and distinguishes itself from get_french_company_profile for identity-only needs.

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

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

Gives clear context on when to use the tool (business-health/risk analysis) and explicitly names an alternative for a different need ('call get_french_company_profile instead if you only need identity'). Also describes the non-conclusive edge case for entities that file no accounts, so an agent can predict the outcome.

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?

Goes well beyond the readOnly/openWorld annotations: discloses on-demand derivation, 24-hour snapshot freshness, 'nothing stored,' the unprovable-null semantics, lower-bound counting caveats (brand names and temp agencies not counted), the method-reference field methode.comptage, and the privacy boundary that only aggregated signals are returned. 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 but every clause adds operational value: signal semantics, counting caveats, data freshness, privacy restrictions, use cases, and payment path. The single-paragraph structure slightly reduces scanability, but the content is front-loaded with the core hiring signal and is not padded.

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 signal-heavy tool with an output schema, the description is remarkably complete: it enumerates all returned signal categories, explains null and lower-bound semantics, discloses freshness and storage behavior, gives payment options, and states the intended use cases. An agent has enough to decide whether and how to invoke it.

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

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

Schema covers 100% of parameters, including descriptions for siren, api_key, and x_payment, so the baseline is 3. The description adds behavioral matching context around SIREN and company-name matching but does not add new per-parameter semantics beyond what the schema already provides.

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

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

States a specific verb ('get') and resource ('hiring signals for a French company'), then lists the exact signal types (actively-hiring, active-postings count, ROME families, contract mix, pay display share, Egapro index, workforce bracket). It clearly stands apart from sibling French-company tools such as get_french_company_financials or get_french_company_intelligence.

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 says 'Use for sales intelligence (a hiring company is an active company) and HR/expansion signals,' giving clear context for when the tool is appropriate. It does not explicitly name alternatives or conditions when not to use it, so it stops short of a 5.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description adds meaningful behavioral details: companies with no classified facility return level `aucun` as a clean signal, and the tool is paid via x402. These are not obvious from annotations or the schema and help set expectations correctly.

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

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

Three sentences deliver the tool's purpose, key output fields, empty-result semantics, and pricing without filler. The dense first sentence is front-loaded with the most important information, and each subsequent sentence adds distinct 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?

For a tool with one required parameter, a rich output schema, and full schema description coverage, the description provides everything an agent needs: the data source, the relevant fields, the no-facility edge case, and the payment requirement. No critical contextual gaps remain.

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

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

Schema description coverage is 100%, with siren, api_key, and x_payment already well documented. The description adds no new parameter details; it only reuses the per-SIREN concept. The baseline of 3 applies because the schema carries the parameter-semantics 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 identifies the tool as providing an industrial-risk and environment (ESG) profile from the official ICPE register, with specific content details such as Seveso status, authorisation regime, activity state, IED flag, and per-SIREN synthesis. This distinguishes it from other French-company tools that cover financials, legal alerts, or health summaries.

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 the tool: when an industrial-risk or environmental profile is needed, sourced from Géorisques/DGPR. It does not explicitly name alternatives or exclusions, but the domain and official source make the intended use unmistakable among the sibling French-company tools.

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

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

Beyond the readOnly/openWorld annotations, the description discloses the data source, the returned content shape, a notable privacy constraint (inventor names never returned), and the payment mechanism with its exact cost. These are practical behavioral details an agent needs before invoking.

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

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

Three compact sentences front-load the core resource and contents, then add signal context, privacy caveat, and pricing. There is no filler or duplication of schema information.

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

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

The schema, annotations, output schema, and description together give an agent everything needed: input, cost, source, contents, privacy caveat, and read-only safety. No practical gap remains.

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

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

Schema description coverage is 100%, so the description correctly avoids restating parameter details; the baseline of 3 applies. The payment mention is adjacent to x_payment/api_key but adds no parameter-level semantics beyond what the schema already provides.

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

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

The description states a specific verb and resource: retrieving a French company's intellectual-property portfolio from INPI open data. It enumerates the asset classes and returned fields, which clearly distinguishes it from sibling get_french_company_* tools focused on financials, changes, or 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?

It gives a usage context — 'An R&D/brand-value signal' — but does not explicitly name alternatives or state when not to use it. In a large sibling family, the selection criteria are implied rather than explicitly spelled out.

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 present, the description adds substantial behavioral context: deterministic verdicts, closed-list signals traced to register sources, as_of dates, offline auditability via Ed25519 signature, and payment/credits behavior. This goes well beyond the annotations and helps the agent set expectations for the response.

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 appropriately so for a flagship aggregation tool; the use case is front-loaded and every phrase adds useful detail about data blocks, return values, provenance, and auditability. No filler sentences are present.

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 decision context, the scope of data included, the nature of the output, the register traceability, the verdict scale, payment options, and offline verification. Given that an output schema exists, nothing essential for selecting or invoking the tool is missing.

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

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

Schema description coverage is 100%, and the schema already documents siren, api_key, and x_payment in detail. The tool description adds general context about the report being paid and comprehensive, but it does not add meaningful new parameter-level meaning beyond what the schema already provides.

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 — GO/NO-GO decisions on a French company — and names the resource as a comprehensive company intelligence report. It distinguishes itself from the many granular sibling tools by stating it cross-references every Sirenic block in one call and calling itself '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 tells when to use the tool: for a GO/NO-GO credit, investment, or partnership decision. It implies the alternative to calling many single-purpose siblings by saying 'every Sirenic block cross-referenced in one call,' but it does not explicitly name which siblings to use for narrower needs.

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 billing per SIREN, the $0.105 effective unit price, the behavior and billing for non-diffusible SIRENs, per-block provenance, and the x402 spendControls trap that can cause the caller's own client to reject the quote. This is exceptionally transparent about cost, failure modes, and output traits.

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 dense, and nearly every sentence carries operational necessity: scope, pricing, edge-case billing, provenance, use case, and a critical spendControls warning. It is front-loaded with purpose and only mildly verbose in the final payment-cap warning, which is justified by severity.

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

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

The description covers what the tool does, when to use it, how billing works, what happens for missing companies, provenance guarantees, and the payment-configuration pitfall an agent must handle before calling. With an output schema present, no return-format explanation is needed, so the tool description is effectively 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%, so the baseline is 3. The description adds extra semantic value by explaining that cost scales with the number of SIRENs, that a SIREN without a diffusible company yields trouve=false but still bills as one lookup, and how the x402 payment flow relates to the optional api_key and x_payment 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 'Batch KYB: full KYB files for 2 to 100 French companies in one call', which names a specific verb, a concrete resource, and a precise scope. It naturally differentiates from the sibling get_french_company_kyb_file by emphasizing the batch dimension.

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 points to 'ideal for prospecting and compliance agents processing lists', giving a clear when-to-use context. It does not name an explicit alternative or exclusion, so it stops short of a full 5, but the batch context is unambiguous versus the single-company sibling.

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 with readOnlyHint and openWorldHint annotations present, the description adds substantial behavior: it explains provenance metadata on every block, the meaning of precision_as_of, and the x402 payment cost. This enriches the agent's understanding of what the call returns and what side effects or payment obligations exist.

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 every sentence earns its place: what the bundle contains, when to use alternatives, provenance behavior, and pricing. Important context is front-loaded before billing details.

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

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

For a complex bundle tool with an output schema, the description covers purpose, alternatives, returned-data provenance, and cost. Nothing critical is missing for an agent to decide whether and how to invoke it correctly.

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

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

Schema description coverage is 100%, so the input schema fully documents the three parameters. The description does not add parameter-level detail beyond the schema, but that is acceptable given the schema already carries the burden. 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 states a clear, specific purpose: retrieving a complete bundled KYB file for a French company, and enumerates exactly what the bundle contains (identity, officers, legal alerts, financials, sanctions, VAT, completeness score). It also distinguishes itself from sibling tools by positioning itself as the comprehensive one-call version.

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 when-to-use guidance is provided: use when you want the whole due-diligence picture at once. It names specific alternative tools for partial needs and notes they are cheaper, which is actionable routing information an agent can rely on.

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

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

Annotations already declare readOnly=true, lowering the burden. The description adds valuable behavioral context: results are grouped and most recent first, and the tool is paid via x402 at a specific price. This goes beyond the annotations and makes cost/ordering expectations clear.

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

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

Two sentences with no filler: the first captures scope, source, content types, and ordering; the second captures payment. Every sentence earns its place and the key differentiators are front-loaded.

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

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

Given an output schema exists and parameter documentation is complete, the description covers the essential selection and cost details for a read-only data retrieval tool. It could be more complete with one explicit alternative-routing sentence, but nothing critical is missing for 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 description coverage is 100%, with thorough documentation for siren, api_key, and x_payment. The description mentions payment via x402 but does not add meaning beyond the schema's own parameter descriptions, so 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 states a specific verb+resource (legal alerts for a French company), identifies the authoritative source (BODACC, the official French gazette), and enumerates concrete content types (insolvency proceedings, court filings, deregistrations, business sales). This clearly distinguishes it from broad search or other regulatory alert tools without needing the schema.

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

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

The description implies when to use the tool: when a French company's BODACC legal notices are needed, by SIREN. It does not explicitly provide exclusions or name alternatives like search_bodaac_announcements or check_french_regulator_alerts, so the routing guidance is implied rather than 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?

Annotations already indicate readOnlyHint and openWorldHint, but the description adds valuable behavior beyond that: it clarifies that an unregistered company returning `inscrit: false` is a valid outcome, not an error. It also discloses the x402 payment requirement and cost, which is important behavioral context. The 'no personal data' scope further manages expectations about what the tool will and will not return.

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

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

The description is compact and front-loaded, leading with the core purpose and data source, then listing contents, scope, a meaningful-result caveat, and cost in a logical flow. Every sentence carries useful information with no filler or repetition of schema details.

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

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

The tool has a rich output schema, 100% parameter schema coverage, and annotations, so the description does not need to explain return values or basic safety. It covers the remaining contextual essentials: source authority, data scope, meaningful absence of registration, and payment mechanics. An agent has enough to select and invoke 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%, with all three parameters (siren, api_key, x_payment) already documented in the input schema. The tool description adds no parameter-level semantics beyond what the schema provides, but it doesn't need to because the schema is self-sufficient. 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 a specific verb ('get'), a specific resource ('Lobbying and transparency profile of a French company'), and a distinct data source ('official HATVP register of interest representatives'). It enumerates the contained fields (registration status, expense brackets, subjects, clients, affiliations), making the tool's purpose unambiguous. It also differentiates from siblings by explicitly scoping to organisation-level 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 clearly signals when to use this tool: when an agent needs French company lobbying/transparency data from the HATVP register. It also provides an exclusion ('Organisation-level only — no personal data') and notes that `inscrit: false` is meaningful, which guides interpretation. It does not explicitly name alternative tools or state when not to use it, but the context and sibling list make the use case clear.

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

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

Annotations already provide readOnlyHint and openWorldHint. The description adds valuable behavioral context beyond that: the tool is paid via x402 at a set price, returns the PDF as base64, and conditionally includes the AI health summary only when cached. No contradiction with the annotations exists.

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

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

A single well-structured sentence front-loads the purpose, then packs the dossier contents, output format, and payment model without filler. Every part earns its place and the most important information appears first.

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 covers return format (base64 PDF), dossier contents, conditional inclusion of health summary, and payment model. Remaining details like the quote flow and insufficient-balance behavior live in the schema. The only notable gap is not disambiguating from get_french_company_kyb_file.

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 even without parameter details in the description. The description adds only the payment context ($0.50 in USDC or EURC) and does not meaningfully explain the parameters beyond what the schema already provides.

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 an on-demand PDF report of a French company and lists the dossier contents (identity, officers, legal alerts, financials, sanctions screening). It is specific about verb and resource, but it does not explicitly distinguish itself from the very similar sibling get_french_company_kyb_file, so it misses full sibling differentiation.

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

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

The use case is implied by 'shareable due-diligence dossier' and 'on-demand PDF report', which signals when an agent would want this tool. However, it gives no explicit when-to-use versus alternatives, no exclusions, and does not mention the closest sibling get_french_company_kyb_file.

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, and the description adds meaningful behavioral context: the payment requirement via x402 with a specific cost, the official registry sources (INSEE Sirene / INPI RNE), and a critical interpretation caveat that conventions_collectives_notes contains technical IDCC codes where 9999 means 'no collective agreement assigned.' This goes beyond the annotations and prevents a likely misuse.

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

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

The description is dense but efficient: it leads with output scope and fields, includes the important 9999 caveat parenthetically, then gives use-case positioning and payment details. Every part earns its place, and nothing is redundant with the already-rich schema and annotations.

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

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

Given that an output schema exists, parameter schema coverage is full, and annotations are present, the description is largely complete: it covers source, content, cost, and a decoding caveat. It does not explicitly differentiate from the large French company sibling set, but the 'core data lookup' positioning provides enough contextual grounding for an agent to select it for general KYB.

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

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

Schema description coverage is 100% and the schema already documents siren, api_key, and x_payment with helpful details. The main description adds little about parameter semantics beyond mentioning lookup 'by SIREN' and the paid x402 flow, so the schema carries the weight. 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 starts with a specific verb and resource: 'Full official company profile of a French company by SIREN' and lists concrete fields (legal name, legal form, head office, NAF code, workforce, officers, VAT number). It also positions itself as 'the core company data lookup for KYB and due diligence on France,' which helps distinguish it from specialized siblings, though it does not explicitly name an alternative.

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

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

The phrase 'The core company data lookup for KYB and due diligence on France' provides clear usage context and implies this is the default profile tool for French company data. However, it does not explain when to prefer a related sibling such as get_french_company_financials or get_french_company_health_summary, so it stops short of explicit when-not guidance.

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

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

Annotations already declare read-only behavior, and the description adds valuable behavioral context: the tool is paid via x402 at a fixed $0.01 cost and uses official DECP data. It does not contradict the annotations, and the payment detail is important for correct invocation.

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 short sentences that front-load the core purpose and then add the critical payment fact. There is no filler, and every piece of information contributes to correct tool understanding.

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 fully described schema, an output schema, and read-only/open-world annotations, the description covers the essential purpose, data contents, and paid nature of the tool. An agent has enough context 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 description coverage is 100%, and the schema already documents siren, api_key, and x_payment in detail, including the quote-vs-payment behavior. The description adds no parameter-level information, which is acceptable given the schema's completeness.

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

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

The description names a specific resource (French public procurement using official DECP data), a specific scope (contracts and tenders won by a French company), and the key data fields (buyers, amounts, dates). This distinguishes it from broader siblings like get_eu_procurement_awards and get_french_company_profile.

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 explicit: use this tool for French public procurement won by a French company. It does not explicitly list exclusions or alternative sibling tools, so it misses the strongest form of usage guidance, but the domain scope is clear enough to guide selection.

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

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

Annotations already mark the tool as read-only and open-world, and the description adds meaningful behavioral context beyond them: it names the official data source (DECP open data) and discloses the monetization mechanism and exact price ($0.02 via x402). This helps the agent anticipate side effects and cost without contradicting the read-only hint.

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 resource and key input before listing the output contents and the data source. It is efficient, but the long list of deliverables in one sentence makes it slightly harder to parse than a structured breakdown would be.

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 fully documents parameters, the description covers everything an agent needs to decide and invoke correctly: the target resource, required key, expected output contents, use case, data source, and pricing. No critical operational detail is missing.

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

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

Schema description coverage is 100%, so the schema already fully documents siret, api_key, and x_payment. The description only echoes 'by SIRET' and does not add parameter-level nuance beyond what the schema provides, 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 precisely defines the tool as returning a procurement profile for a French public buyer keyed by SIRET, and then enumerates the exact data points included. This clearly distinguishes it from sibling tools like get_french_company_public_procurement, which targets the procurement activity of a company rather than the buying profile of a public buyer.

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 use case ('the buying habits to know before a sourcing meeting'), so an agent understands when this profile is relevant. However, it does not explicitly state when to prefer this over related siblings such as get_eu_procurement_awards or find_expiring_french_public_contracts, nor does it provide any exclusion criteria.

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

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

Beyond the readOnlyHint annotation, the description discloses that results are aggregates only, contain no personal data, require a minimum of 5 companies filing public accounts for financial metrics, and are paid via x402 at a specific cost. This gives the agent important behavioral expectations that annotations do not cover.

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 yet information-dense: it front-loads the core purpose and metrics, then explains the peer-comparison use case, privacy properties, and payment cost. Each sentence contributes new 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 rich input schema, output schema, and annotations, the description covers what the tool returns, the required input format, the threshold condition for financial metrics, the aggregate/privacy nature, and the payment mechanism. No critical operational concern is left unaddressed for an agent deciding whether and how to call this tool.

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

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

Schema coverage is already 100%, so the baseline is 3. The description adds meaningful semantics by clarifying accepted NAF code granularity with concrete examples (68, 68.2, 68.20, 68.20B) and by stating the USD/EURC cost associated with the payment flow, which complements the schema's parameter descriptions.

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

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

The description clearly states the resource type (sector benchmarks/statistics for a French NAF activity code) and enumerates the metrics returned, so an agent can understand what this tool does. However, it does not explicitly distinguish itself from sibling tools like compare_french_companies or get_french_company_financials, relying instead on the sector-level framing to imply differentiation.

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 context: querying sector-level statistics by NAF code and performing peer comparison against aggregate benchmarks. It does not explicitly state when not to use it or name alternative sibling tools, so exclusions are missing, but the intended usage is well implied.

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, so the bar is lower, and the description adds substantial value beyond them: the privacy behavior ('No individual is ever named, and the breakdown is withheld when it would single someone out'), the payment requirement ('Paid via x402 ($0.02 in USDC or EURC)'), and the data-retention constraint ('BaFin keeps 12 months'). These are real behavioral traits an agent could not infer from the annotations alone.

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 with no wasted sentences — purpose, payload, query key, privacy, and payment each earn their place. It is slightly long, but every clause carries information an agent needs before calling the tool, so the density is justified.

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 one required parameter, the description covers everything needed to invoke correctly: how to identify the issuer, what the rolling window is, what aggregates come back, the privacy redaction rule, and the payment path including the $0.02 price and fallback api_key method. Nothing essential is missing.

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

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

Schema coverage is 100%, so the baseline is 3, and the description goes further: it explains why the id must be LEI/ISIN rather than a company register number, clarifies that 'depuis' defaults to the rolling 12 months and is capped by BaFin's retention, and describes the api_key/x_payment distinction (prepaid credits vs signed x402 payment). This adds meaning beyond the schema fields.

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

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

The description names a specific verb+resource: insider transactions at German listed companies, with the legal basis (MAR Article 19) and regulator (BaFin). It states the delivered payload (notification counts, gross buy/sell amounts, net flow, declarer-category breakdown, underlying notifications), which fully distinguishes it from siblings like get_belgian_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 gives clear selection context: German listed issuers, queried by LEI or ISIN, over a rolling 12-month window. It explains why the query key is limited to LEI/ISIN ('BaFin publishes no company register number') and covers the default time scope. It does not explicitly name alternatives or when-not-to-use it, but the scope is precise enough for an agent to select correctly.

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

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

Beyond the annotations (readOnlyHint, openWorldHint), it discloses the daily refresh cadence, CC0 licensing, the critical 'revenue null = not published, never zero' convention, EUR/LVL currency handling, THOUSANDS rounding units, statutory-vs-consolidated separation, and the $0.03 x402 cost. No contradiction with annotations; these are exactly the behaviors that would otherwise cause an agent to misread 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?

A single dense sentence front-loads the core purpose before the caveats, and every clause earns its place (source, scope, null semantics, currency, rounding, consolidation, cost). It is long but logically sequenced; splitting into two sentences would improve readability without adding 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?

With an output schema present (return values need no description) and annotations covering the safety profile, the description covers all operational gotchas an agent needs: data freshness, currency/rounding units, null semantics, consolidation separation, and the required payment flow. Nothing essential is missing.

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

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

Schema description coverage is 100% — regnr, x402, and x_payment are each already documented there, so the baseline 3 applies. The description's payment note adds cost context to x402 but adds nothing about regnr beyond the schema's own pattern and 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 names a specific verb+resource ('annual accounts from official VID filings') and enumerates exact contents (balance sheet, P&L, cash flow, employees) with explicit scope ('EVERY filed fiscal year in one call'). It is clearly distinguishable from sibling country-account tools like get_estonian_company_accounts or get_swedish_company_accounts by the explicit Latvian source and data specifics.

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 via the country+resource in the name and the enumerated contents, which signal 'use for Latvian company financial statements'. However, no alternative tools are named and nothing states what it does not cover (e.g., officers, insolvency — handled by siblings) or when to prefer a different tool.

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

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

Annotations provide readOnlyHint and openWorldHint, and the description adds substantial behavioral context: empty lists can still reflect a registered company, data is CC0 and refreshed daily, GDPR minimisation excludes personal identity numbers, and payment is via x402 at $0.02. These details go well beyond the structured annotations and explain important edge cases.

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: core function, data source/freshness, empty-list semantics, privacy constraints, and payment model. It is front-loaded with the primary purpose and does not waste 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?

With a rich input schema, output schema, and annotations already present, the description covers the remaining practical concerns: register semantics, GDPR redactions, and payment requirements. An agent has enough information to select and invoke 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?

The input schema already has 100% coverage with detailed descriptions for regnr, api_key, and x_payment, including format, example, and payment flow. The description adds pricing and GDPR context, but little parameter-specific meaning beyond what the schema provides, 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 names a specific verb and resource: 'Beneficial owners ... of a Latvian company from the official Uzņēmumu reģistrs open data.' It also lists the exact data fields returned (name, nationality, country of residence, registration date), which makes the tool's function unambiguous. The country-specific framing and contrast with France's registry depth help distinguish it from 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 clearly scopes the tool to Latvian companies identified by Latvian registration number, and explains the open-data source and daily refresh. It does not explicitly name alternatives such as get_uk_beneficial_owners or state when not to use it, but the country-specific context makes the intended use 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 readOnlyHint and openWorldHint annotations, the description discloses the data license and update cadence ('CC0, daily national photo since 2008'), the null end-date semantics, the explicit no-proceeding response ('aucune_procedure: true'), and the payment mechanism and price. This gives an agent substantial behavioral grounding beyond what annotations alone provide.

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

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

Three dense sentences each earn their place: source and content, open-world behavior, and payment/quoting requirement. Information is front-loaded and there is no filler or repetition of schema fields.

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 lookup tool: it covers source authority, temporal scope, field semantics including null end date, the no-proceeding case, and payment expectations. The presence of an output schema means return-value details do not need to be restated.

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 input schema already documents regnr, api_key, and x_payment. The description adds useful domain context about the official register and payment model but does not need to explain parameter semantics further.

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 ('Latvian company insolvency record'), the authoritative source ('official Uzņēmumu reģistrs open data'), and the specific content ('insolvency and legal-protection proceedings with dates, resolution, court and case number'). This clearly separates it from the many country-specific 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 gives useful context about the data source, open-world handling, and authoritative status, but it does not explicitly say when to use this tool versus the other insolvency or Latvian company tools. Usage must be inferred from the tool name and country/domain focus rather than stated directly.

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

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

Annotations already mark the tool as read-only and open-world, and the description adds valuable behavioral context: the official CC0 source, daily refresh, GDPR minimisation rules, and the x402 payment requirement. 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 well structured: the core purpose is front-loaded, followed by the data scope, privacy note, and payment method. Every sentence carries useful information with no fluff or repetition of schema 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?

Given the existing output schema and annotations, the description is complete: it names the source, refresh cadence, legal/privacy constraints, payment expectation, and the general output categories. No critical missing usage information remains for an agent to invoke it correctly.

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

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

Schema description coverage is 100% and the schema already documents regnr, api_key, and x_payment in detail. The description adds context about the registry and payment but does not describe parameters beyond what the schema already provides, 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 uses a specific verb and resource: 'Latvian company officers and directors from the official Uzņēmumu reģistrs open data'. It enumerates the concrete content (board members, chairs, liquidators, representation rights) and distinguishes itself from sibling Latvian company tools (accounts, beneficial owners, insolvency) by focusing on 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?

The description gives clear context for when to use the tool: when Latvian company officer/director data is needed. It does not explicitly name alternatives or exclusions, but the data scope is specific enough to route an agent correctly among the country- and subject-specific siblings.

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 and openWorld annotations, the description discloses significant behavioral traits: live retrieval of the latest fiscal year, historical accumulation since 2026-07, the register's limitation to only the latest filing, currency behavior (published filing currency, possibly USD, never converted), and source exclusions. This gives the agent strong expectations about data freshness, historical depth, and output semantics.

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

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

The description is dense but every sentence earns its place: source, scope, temporal behavior, financial statement contents, currency, exclusions, and payment. The core purpose is front-loaded, and no redundant or boilerplate text is present.

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 this complexity, the description covers selection criteria, data scope, data freshness, currency behavior, exclusions, and payment model. Since an output schema exists, the description does not need to explain return values, and nothing critical is missing for an agent to decide correctly 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 description coverage is 100%, and the parameters (id, api_key, x_payment) are already well-documented in the input schema. The description adds billing context (x402, $0.02 in USDC or EURC) but does not meaningfully explain the parameters themselves beyond what the schema provides, so it remains at 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 names the exact resource ('annual accounts of a Norwegian company') and the official source (Regnskapsregisteret/Brønnøysundregistrene), making the tool's function unmistakable. The country scoping and exclusion of banks/insurers distinguish it clearly from sibling country-accounts tools like get_swedish_company_accounts or get_uk_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 provides clear context: use this for Norwegian official annual accounts, with the latest fiscal year fetched live and earlier years accumulated since 2026-07. It also gives an explicit exclusion ('banks and insurers are not served by the source'), though it does not name a specific alternative tool to use 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 live re-checking of flags, the explicit positive answer (aucun_evenement: true), the absence of ruling text/court/insolvency practitioner compared to BODACC, the date semantics (origine_date, date_au_plus_tard), and payment error behavior. This adds significant behavioral context that annotations alone do not provide.

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

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

The description is dense but well-structured: it starts with the core purpose, then details the event types, limitations, edge cases, and payment. Every sentence provides necessary information; there is no redundant phrasing. The length is justified by the complexity of the tool's behavior.

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

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

Given the tool's complexity (multiple event types, legal-person restrictions, payment options, live verification, date semantics), the description covers all needs an agent might have for correct invocation and interpretation. The existence of an output schema further reduces the need to explain return values, and the description complements it effectively.

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

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

Schema coverage is 100%, so all three parameters (id, api_key, x_payment) are already documented in the schema. The description adds contextual details about payment interplay and error handling, but does not add new meaning to the parameters themselves. Per the rubric, a baseline of 3 is appropriate when schema covers all parameters.

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

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

The description states a specific verb ('get'), a precise resource ('legal events of a Norwegian company'), and the official source (Enhetsregisteret). It enumerates the event types (bankruptcy, winding-up, strike-off) and explicitly compares to the French BODACC, which helps distinguish it from sibling tools for other jurisdictions.

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 on when to use the tool (for Norwegian legal persons) and exclusions (natural-person forms, estates named after individuals, unrecognised forms). It also explains the 3-year window and that open procedures are always served. However, it does not name specific alternative tools (e.g., get_norwegian_company_accounts) for other needs, though the country-specific siblings are implicitly implied.

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 annotations. It discloses that the endpoint does NOT validate KRS existence and that a non-existent number returns the same response as a quiet company, requiring an `existence` block check. It explains GDPR design (no officers/PESEL), the no-free-text policy, the observation window gap-free construction, and the payment mechanism (x402). These are non-obvious behaviors an agent must know to interpret results correctly.

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 every sentence carries critical operational information: the event types, the observation window, the existence caveat, GDPR constraints, and payment. It is front-loaded with the core purpose and then expands on caveats. Slightly verbose but not wasteful; information density is high.

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 payment, existence-check caveats, and compliance constraints, the description is remarkably complete. It covers input behavior (non-existent KRS), output guarantees (gap-free window, event types, dates, wpis number), and exclusions (no officers, no free text). With an output schema present, the agent has everything needed to call and interpret 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%, so `krs`, `api_key`, and `x_payment` are already documented with patterns and semantics. The description adds no additional parameter-level detail beyond what the schema provides (it does mention the existence caveat which relates to `krs` semantics, but that's already partially implied). Since the schema does the heavy lifting, 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 states a specific verb-resource pair ('Registry EVENTS of a Polish company'), names the exact data source (KRS daily bulletin), and enumerates the event types covered (liquidation, bankruptcy, restructuring, etc.). This clearly distinguishes it from sibling tools like get_swedish_company_registry_events or get_european_company_profile.

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 purpose makes clear when to use it (need Polish company registry events). It also gives an explicit pointer to get_european_company_profile for existence verification when the KRS number is uncertain. However, it doesn't explicitly state when NOT to use it (e.g., for other countries) or alternatives for related queries, but the context is sufficient for an agent to choose correctly.

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 meaningful behaviors: null means 'not published' and never zero, amounts are in euros and never converted, the scope default, prior-year comparatives come from the same filing, and payment is via x402 at $0.03. This gives the agent a much richer behavioral model than the annotations alone.

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 carries load: the item list defines the exact output scope, the null/euro notes prevent misinterpretation, and the workflow reference to the list tool is a concise prerequisite. The most important framing is front-loaded.

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

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

Given the output schema exists and the annotations cover read-only/open-world behavior, the description supplies everything else needed to invoke the tool correctly: prerequisite source for the date, default scope, payment mechanism, currency rules, and null semantics. No major invocation question is left unanswered.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description adds useful cross-reference semantics by stating that date_cloture comes from list_slovak_company_filings and that perimetre defaults to the statutory filing, which goes slightly beyond the schema text.

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

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

The description opens with a specific verb and resource: 'One Slovak fiscal year decoded from the structured statements filed with the RÚZ', listing the exact financial items returned. It also distinguishes itself from the related listing tool by stating that the closing date comes from list_slovak_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?

It gives clear context: use this for a single Slovak filing's profit/loss and balance-sheet items, source the closing date from list_slovak_company_filings, and note that scope defaults to the statutory filing. It does not explicitly state when not to use it versus other country-specific filing tools, but the name plus Slovak-specific wording make that differentiation mostly self-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?

Annotations already mark readOnlyHint and openWorldHint, and the description adds substantial behavior beyond that: newest-first ordering, '100 max + total count', redaction of DNI/NIE and sole-shareholder names with '« […] »' markers, coverage since 2009, and $0.02 x402 payment. This is the kind of operational context an agent needs before invoking.

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

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

Purpose is front-loaded in the first clause, and subsequent clauses each carry operationally relevant information: content types, recency/ordering, redaction, attribution, and pricing. It is denser than a two-sentence definition but contains no filler.

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

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

With an output schema present, the description need not recap the return shape. It covers source authority, input prerequisite, coverage start, ordering and limits, redaction policy, and payment method, so nothing essential for selecting and calling this tool is missing.

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

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

Schema coverage is 100% and the schema already documents all three parameters well, so the baseline is 3. The description adds value by explaining that hoja is the register key from search_european_companies and clarifying the x402/api_key payment interaction, reinforcing the schema without repeating it.

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?

Opens with a specific verb+resource ('Spanish company acts... by hoja registral') and enumerates the act types returned (incorporations, officer appointments and dismissals, capital changes, mergers, dissolutions, insolvency). The country/source specificity (BORME, Registro Mercantil, Spain) distinguishes it clearly from the many sibling 'get_*' country 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 the triggering input: a hoja registral key 'returned by search_european_companies for Spain', which tells the agent exactly where the prerequisite identifier comes from. It does not explicitly list when not to use this tool among siblings, but the Spanish source and key requirement make the intended context clear.

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

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

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.