Sirenic

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

Annotations declare readOnlyHint=true and openWorldHint=true, so the description doesn't need to restate safety. The description adds value by mentioning official AMF open data, daily refresh, payment via x402 at a fixed price, and the api_key alternative. This gives the agent useful expectations about data source, freshness, and how the transaction works.

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

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

The description is reasonably meaty, front-loads the core purpose in the first sentence, and uses a short imperative for use cases. The payment sentence is slightly dense, but it earns its place because it clarifies billing behavior. It could be trimmed without much loss, but it does not feel 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?

The tool has meaningful complexity: multiple register types (blacklists, PSAN, SGP), dual lookup keys (nom/siren), and a dual payment path (x402/api_key). The description covers all of these, and the output schema exists to explain return data. The only minor gap is that it doesn't explicitly say that providing both nom and siren is discouraged, but the schema already implies the either/or requirement.

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

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

Schema coverage is 100%: the schema already documents nom, siren, api_key, and x_payment with clear descriptions. The tool description adds a little semantic context by explaining that the tool screens names against blacklists and lookups by SIREN, but it doesn't go beyond the schema's parameter descriptions. Baseline 3 is appropriate because the schema carries the load.

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 ('screen... against official AMF blacklists' and 'look up PSAN crypto-provider registrations and licensed asset-management companies'), a clear resource (French AMF official data), and defines the exact scope. It is easily distinguished from sibling tools like screen_sanctions_lists or search_eu_financial_authorisations because it names AMF, PSAN, SGP, and the scam-check use case explicitly.

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

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

The description gives an explicit use case: 'Use before trusting an investment site, a crypto provider or an asset manager operating in France.' This is clear context for when to choose this tool. It doesn't explicitly name alternative tools to exclude, but the AMF-specific scope and the 'Use before trusting' instruction provide enough orientation.

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

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

Even though readOnlyHint and openWorldHint already cover basic safety, the description goes far beyond: it discloses the cross-table contents, the comparability block, the never-returns-an-overall-winner rule, ranking eligibility statuses, and the prohibition on self-ranking when a ranking is interdit. These are exactly the non-obvious behaviors an agent must know.

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 purpose and output summary, followed by caveats and billing. It is dense and contains a very long sentence around ranking statuses, which could be split for readability, but every sentence carries substantive decision-relevant information 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?

Given the tool's complexity, the rich output schema, and the annotations, the description is complete: it covers purpose, output axes, comparability limitations, ranking restrictions, no-winner behavior, and billing. Nothing an agent needs for correct invocation or interpretation 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 schema already documents all three parameters adequately. The description adds billing semantics tied to SIREN count and x402, but it does not add meaningful semantic detail per parameter 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 opens with an explicit trigger: 'Use when asked to compare, rank or choose between 2 to 5 French companies'. It names the resource type and scope precisely, and the comparison/ranking focus clearly separates it from the many single-company get_french_company_* siblings.

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

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

It gives a clear when-to-use rule with concrete use cases (suppliers, candidates, competitors) and batch size constraints. However, it does not explicitly name alternative sibling tools or state when not to use it, so the routing guidance is strong but not fully complete.

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

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

Beyond the annotations, it discloses daily monitoring cadence, signed webhook/email delivery, bearer-token polling, a 7-day expiry reminder, pricing per target and duration, no pro-rata refund, and the x402 spend-control cap failure mode. These are material behavioral traits the annotations alone do not convey.

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

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

The definition is dense and front-loaded with purpose and use case. It is long because of genuinely useful pricing and spend-cap details rather than repetition, though splitting payment guidance into a separate paragraph would improve scannability.

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, long-running watch creation tool, it covers what is monitored, how events are delivered, how polling and expiry work, cost calculation, auth options (x402 vs api_key), and a known client-side payment-cap pitfall. Nothing essential for a correct call 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. The description adds meaningful value by linking duree to unit prices, cibles to the 1-100 target count and max cost, api_key to the credits fallback, and x_payment to the quote-vs-payment behavior.

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 verb and resource: 'create a 30, 90 or 365-day watchlist' over French companies and/or directors. It also frames the tool as ongoing monitoring 'when the relationship OUTLASTS the check,' which distinguishes it from one-shot sibling lookups.

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

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

It explicitly states when to use the tool — when the relationship outlasts a single check — with concrete examples such as supplier, borrower, and portfolio company. It stops short of naming the alternative check tools or stating an explicit 'do not use this for one-off checks.'

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

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

readOnlyHint=true already signals non-mutating behavior, but the description adds genuinely useful behavioral context: 'Deterministic pattern matching' and 'the text is never stored or logged.' It also discloses the free pricing angle. These details go beyond what annotations provide and reassure an agent about side effects and persistence. 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 front-loaded with 'FREE' and organized in three purposeful sentences: what it detects, when to use it, and how it behaves. Every sentence contributes, but 'FREE.' partly repeats the title's '(free)' marker, and the routing sentence is slightly long. Still, it is compact and readable.

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

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

For a read-only, single-parameter detection tool with an output schema, the description covers input flexibility, identifier types, validation characteristics, recommended follow-up, and privacy. There is no missing information an agent would need to decide to call it 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?

The single parameter 'texte' already has 100% schema description coverage with min/max length. The description adds helpful examples of acceptable input ('email, invoice, contract, web page') and reinforces 'any text,' but for a single simple parameter this adds modest value rather than essential semantics. 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 ('detect'), a precise resource ('text'), and a well-defined set of identifiers: SIREN, SIRET, EU VAT, and LEI. It also clarifies the free and advisory nature ('recommended Sirenic call and its price'), which distinguishes it from the many get_/search_ sibling tools. An agent can tell exactly what this tool does and what it does not do.

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

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

The description gives explicit, concrete usage guidance: 'Use this FIRST whenever a company appears in your workflow' with examples like supplier onboarding, payment to send, and due diligence. It clearly tells the agent when to invoke the tool, but it does not name a sibling alternative or state when not to use it, so it falls just short of full routing completeness.

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=true, the description adds substantial behavioral context: legal deeds carry personal data, authentication failure returns 401 and charges nothing, insufficient balance returns a credits error rather than an x402 quote, output is base64 PDF, and typical size is 1–10 MB. 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 sentence earns its place: purpose, prerequisite IDs, type-specific rules, authentication failure behavior, return format, size, and cost. It is front-loaded with the core purpose and avoids 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?

Despite having no output schema, the description fully covers the return format (base64 PDF), expected size, cost, payment methods, and failure modes. Given the tool's complexity around document types and payer eligibility, this is complete enough for an agent to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics: it explains what each type enum represents (bilans = filed annual accounts; actes = statutes, general-meeting minutes), which types require an api_key, and that document_id must come from the list tool. This goes beyond the schema without repeating it verbatim.

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

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

The description clearly states the verb (Download), the resource (official company document PDF from INPI RNE registry), and connects to the list tool for IDs. It is specific enough to understand what this tool does, though it does not explicitly distinguish itself from similarly named siblings like get_french_company_pdf_report or get_french_company_file.

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

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

The description gives explicit when-to-use guidance: use IDs from list_french_company_documents, and explains type-specific eligibility (bilans for any payer, actes reserved to identified Sirenic accounts). It also clearly states what happens if requirements are not met (401 compte_requis) and names payment alternatives (x402 or api_key).

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, so the description carries the behavioral burden and delivers substantially. It discloses nuanced return semantics: firm price vs ENVELOPE meaning, framework-agreement amount as a MAXIMUM CEILING not spend, and the data limitation that duration amendments are absent from the source. It also discloses the x402 payment mechanism and pricing, going well beyond structured fields.

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

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

The description is dense but every sentence earns its place: purpose, filter guidance, return semantics, caveats, source, and pricing. The core value proposition is front-loaded and the technical caveats (ENVELOPE, ceiling, missing amendments) are necessary to prevent misinterpretation of returned data. Slightly long, but justified by the semantic complexity.

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

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

For a tool with 6 optional parameters, an output schema, and a paid access model, nothing critical is missing. Filter options, payment flow, data source, and return-field semantics are all covered. Pagination and parameter details are already in the schema, and the output schema obviates the need to describe return structure.

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 connecting the filters to the use case ('Filter by CPV prefix (45 = construction) and department') and by framing the window parameter with its default and strategic timing rationale. The payment semantics ($0.05) also enrich the api_key and x_payment parameters beyond their schema descriptions.

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

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

The description leads with a specific verb and resource: 'Tender anticipation for France: public contracts EXPIRING within a window (1-24 months, default 12)'. It clearly differentiates itself from siblings by stating it 'surfaces opportunities BEFORE any notice is published', which sets it apart from award-based tools like get_eu_procurement_awards and get_french_company_public_procurement.

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: buyers re-tender 4 to 9 months before expiry, so this is for anticipating opportunities before notices exist. However, it does not explicitly name alternative tools or state when NOT to use it, leaving the exclusion logic 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?

The description adds substantial behavioral context beyond the readOnlyHint and openWorldHint annotations: the output format (structured JSON vs base64-encoded PDF) is unpredictable, deposits are immutable, the call incurs a $0.15 x402 fee, and the reference must come from a prior list call. These details inform the agent's expectations about output handling, caching, and cost.

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?

Five compact sentences, each carrying a distinct piece of information: the resource and return formats, the unpredictability of the format, the reference source, immutability, and the payment requirement. The core function is front-loaded in the first sentence, and there is no redundant or filler text.

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

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

With no output schema, the description adequately conveys the dual return format and the high-level content ('Belgian company financial statements'). It also covers cost, immutability, and the dependency on list_belgian_company_filings. A minor gap is the lack of detail about JSON fields, but for a single-filing retrieval tool this 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?

The input schema covers 100% of parameters with detailed descriptions, including reference provenance, api_key vs x_payment priority, and the payment-quote behavior. The tool description only adds the fee amount and reinforces the reference provenance, neither of which materially changes how parameters are populated, so the baseline 3 applies.

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

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

The description states a specific verb+resource: 'One Belgian annual-account deposit as filed (NBB CBSO Authentic Data)' and clearly distinguishes itself from the list sibling by using 'One' and by stating 'Reference comes from list_belgian_company_filings.' This leaves no ambiguity about what the tool retrieves or how it differs from the many country-specific 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 explicitly establishes a precondition: 'Reference comes from list_belgian_company_filings,' which routes the agent to call the list tool first. It does not explicitly enumerate when-not-to-use alternatives, but the country and deposit specificity in the name and description make the intended usage context clear.

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

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

readOnlyHint=true already covers the safety profile; the description adds genuinely non-obvious behavior: rolling 12-month aggregation window, the privacy guarantee that no individual is ever named, and that the breakdown is withheld when it would single someone out. It also discloses the x402 payment cost. No contradiction with annotations.

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

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

Five compact sentences where each carries distinct information: purpose, output composition, privacy caveat, usage context, and cost. The purpose is front-loaded. Slightly longer than strictly necessary — the 'are its managers buying or selling?' flourish restates the first sentence — but nothing is 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 documenting returns, annotations covering the read-only safety profile, and 100% parameter coverage, the description adequately fills the remaining gaps: legal basis, aggregation semantics, privacy withholding, use case, and cost. The only missing piece is explicit sibling routing for non-Belgian jurisdictions.

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

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

Schema coverage is 100% with detailed parameter descriptions (id pattern and KBO/BCE meaning, depuis format and default, api_key payment fallback, x_payment precedence). The description reinforces the rolling-12-month default and payment cost but adds no new parameter-level semantics, so the baseline 3 applies.

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

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

States precisely what the tool returns: insider transactions of Belgian listed companies' managers under MAR Article 19, FSMA-notified, at issuer-level aggregate (notification counts, gross buy/sell amounts, net flow, declarer-category breakdown, underlying notifications). The explicit 'Belgian' + 'FSMA' scoping distinguishes it immediately from sibling 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?

Gives a clear trigger: 'Use it as a governance signal before investing in or contracting with a listed Belgian company,' and the territorial scoping (Belgian, FSMA) implies the boundary with country-specific siblings. It stops short of explicitly naming alternatives or stating when-not-to-use cases, such as routing German requests to get_german_insider_transactions.

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

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

Beyond the readOnlyHint annotation, the description adds valuable behaviors: data freshness ('refreshed daily'), the semantic claim that 'Not authorised is an answer too' (absence of a license is a meaningful result), and the x402 payment cost. These details help an agent set expectations about output interpretation and the paywall — all without contradicting the annotations.

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

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

Three tightly written sentences each earn their place: the first lists covered authorisation types and sources, the second gives the decision use case, the third clarifies the meaning of absence and the payment method. No redundant or filler content 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?

For a tool with one required parameter, a rich output schema, and read-only annotations, the description covers all critical aspects: data scope, source registers, refresh cadence, use case, and payment mechanism. Nothing essential 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 baseline is 3. The description references 'by SIREN' and mentions x402 payment, but the schema already fully explains siren, api_key, and x_payment, including the 9-digit pattern and the credit-vs-x402 fallback. The description adds no parameter-level detail 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 opens with a precise, action-oriented statement: 'Regulatory authorisations of a French company by SIREN' and enumerates concrete categories (payment institution, e-money institution, insurance undertaking, etc.) with their source registers. This clearly distinguishes the tool from broad French company profile tools and EU-wide search tools among the siblings.

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

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

The description gives an explicit use case: 'Use it before paying, onboarding or contracting with a regulated counterparty,' and clarifies that a 'Not authorised' result is meaningful. However, it does not name alternatives or state when not to use this tool (e.g., when an EU-wide search would be more appropriate), leaving some routing to the agent's inference.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses key behavioral facts: the tool is paid via x402 at a specific cost ($0.02), uses official DECP open data, covers a 3-year window, and returns counts, amounts, and shared segments. This adds meaningful operational context 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 a single dense sentence that front-loads the core value proposition, then adds the source, timeframe, and payment details without any fluff. Every clause earns its place and the structure is easy to parse quickly.

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

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

Given the output schema exists, return values do not need explanation. The description covers purpose, input concept (SIREN), data source, time window, payment requirement, and high-level outputs. It lacks explicit sibling routing, but the core calling context is sufficiently complete.

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

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

Schema description coverage is 100%, so all three parameters are already documented. The tool description mostly repeats 'SIREN' and adds no new parameter-specific meaning; the baseline of 3 applies because the schema handles the heavy lifting.

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

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

The description clearly states a specific purpose: identifying rival contractors who win French public procurement contracts on the same CPV segments as a given SIREN, with counts, amounts, and shared segments. This differentiates it from sibling tools like get_eu_procurement_awards or get_french_company_public_procurement by emphasizing competitor analysis rather than contract lists or 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 use case is implied through phrases like 'competitive intelligence' and 'top rival contractors', so an agent can infer when to choose it. However, it never explicitly names alternative tools or states when NOT to use it, leaving the decision to inference rather than clear 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 mark read-only and open-world, and the description adds substantial behavioral context: daily snapshot, ordering, specific filing types, no document delivery, the measured-fact semantics of 'aucun_depot', and payment via x402 with exact pricing. 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 dense sentences front-load the core scope and output, then add the crucial metadata-only caveat and pricing. Every clause adds useful information with no padding.

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

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

Given an output schema exists and the input schema is fully documented, this description provides the remaining operational context an agent needs: source, freshness, ordering, scope of results, payment requirements, and a precise data-quality note. Nothing required to invoke 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?

Input schema covers all three parameters with rich descriptions (OIB format, optional api_key and x_payment semantics), so the description adds no additional parameter-level meaning. Baseline 3 applies because schema coverage is 100%.

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 resource ('Croatian company annual-accounts filings'), source registry ('Sudski registar'), and exactly what is returned (filing type, consolidation flag, period, filing date, newest first). This distinguishes it from sibling tools by explicit content scope and metadata-only nature.

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

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

Clearly defines the use case: retrieving Croatian annual-accounts filing metadata, with a firm exclusion ('metadata only, never the document'). It does not name alternative tools for documents, events, or insolvency, so it stops short of full when-to-use-vs-alternatives guidance.

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

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

Annotations already provide readOnlyHint and openWorldHint, but the description adds substantial behavioral detail: it is a paid tool via x402 ($0.02), the published text is restricted to certain entry types (texte_retenu), and court decisions have a specific format (court, reference, date). This goes beyond annotations and helps the agent understand non-obvious behavior.

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: the first sentence defines the resource and scope, the second covers text restrictions and payment. It is front-loaded with the core purpose, and each clause adds necessary information, though it could be slightly more streamlined.

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 (payment, text restrictions, 108 types) and the presence of an output schema, the description covers the essential aspects: data content, payment mechanism, and special formatting. It does not mention pagination or rate limits, but these are minor given the output schema exists.

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

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

Schema description coverage is 100%, so the schema fully documents oib, api_key, and x_payment. The description does not add parameter-level semantics beyond what the schema already provides, 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?

The description states a specific verb and resource: it retrieves Croatian company statutory entries from the official Sudski registar. It enumerates 108 entry types, which distinguishes it from siblings like get_croatian_company_accounts or get_croatian_company_insolvency by content.

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

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

The description implies usage for statutory entries from the court register but does not explicitly name alternative tools or state when not to use it. The context is clear, but there are no direct exclusions or cross-references to other Croatian-specific 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 readOnly/openWorld annotations, the description reveals important behavior: it never returns decision text, `aucune_procedure: true` is a measured fact on the complete snapshot, unknown identifiers produce 404 because deleted subjects are unpublished, and the call is paid via x402. This is substantive, non-obvious behavioral context that helps the agent 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 essential purpose is front-loaded, and the extra clauses about source, output scope, the no-procedure flag, 404 semantics, and pricing are each informative. The long first sentence is dense but not wasteful; a small structural cleanup would make it very strong.

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, paid, country-specific insolvency lookup, the description covers data source, output content limitations, key flag semantics, error behavior for unknown identifiers, and cost. With the output schema and annotations also available, nothing an agent needs to call and interpret 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?

The input schema already describes all three parameters with 100% coverage, so the baseline applies. The description reinforces that OIB/MBS strings are valid and mentions payment-related handling, but it does not add material meaning beyond the schema.

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

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

The description names a specific verb and resource — retrieving Croatian insolvency status from the official Sudski registar — and enumerates the covered procedures and court decisions. This scope clearly differentiates it from country-specific siblings such as get_croatian_company_accounts/events and other countries' insolvency 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 Croatian court-register subject matter gives clear context for when this tool is appropriate, and the 404/unknown-OIB behavior plus payment requirement set expectations. It does not explicitly name alternative siblings or state 'when not to use', but the country/data-source framing makes the intended use obvious.

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

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

The annotations only declare readOnlyHint and openWorldHint, while the description adds substantial behavioral context: monthly snapshot semantics, 503 fail-closed behavior, sorting order, lack of natural/corporate distinction, and the $0.01 payment requirement. No contradiction with annotations exists.

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

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

The description is front-loaded with the core purpose and contains no true filler, but the opening sentence is dense, combining source attribution, license, role enumeration, sorting, and a field reference. It is justified information but would benefit from clearer separation.

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 officer lookup with a rich schema and output schema, the description covers return semantics, source limitations, unsupported legal forms, payment behavior, and failure mode. No significant decision-relevant information 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 already documents all three parameters with 100% coverage. The description reinforces the HE/AE interpretation and adds that invalid entity classes are refused before payment, but it does not materially expand meaning beyond what the schema provides, 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?

The description states a specific resource and scope: Cypriot company officers from DRCOR, with the exact officer types returned and the role-family structure. This clearly distinguishes it from sibling tools like get_danish_company_officers or get_uk_company_officers.

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

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

It gives explicit boundaries: only HE/AE legal persons are accepted, business names/partnerships/BN are refused, and the source lacks appointment dates and personal details, helping an agent decide when this tool is not appropriate. It does not name a specific alternative sibling, but the entity-type and country exclusions are clear.

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

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

The description adds substantial behavioral detail beyond the readOnlyHint and openWorldHint annotations: event lists are capped at 100 most recent events, truncation is indicated by evenements_tronques, stale data return 503 rather than a stale clean answer, and natural persons get a 404 rather than a clean result. These are non-obvious behaviors an agent needs to interpret responses 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?

Although fairly long, the description is dense and front-loaded: it states the resource first, then enumerates the returned data, then critical edge cases. Every sentence conveys necessary operational information such as truncation, staleness handling, legal-person restrictions, and payment.

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

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

Given the tool's complexity and the presence of an output schema, the description is remarkably complete. It covers input constraints, error semantics (404 for natural persons, 503 for stale stocks), truncation behavior, absence-of-proceeding representation, collection timing, and payment mechanism. An agent has enough information to invoke the tool correctly and interpret its results.

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 three parameters with descriptions, so the baseline is 3. The description adds meaningful semantic value by clarifying that the ico parameter must belong to a legal person, that natural-person IČOs will be refused, and that the tool is paid via x402 at a known cost. This goes beyond the schema's pattern and example.

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

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

The description clearly identifies the tool's purpose: retrieving a Czech company's insolvency record from the official ISIR register, with a specific list of included data such as case numbers, courts, statuses, dates, and document links. It is easily distinguished from sibling tools like get_uk_company_insolvency and get_latvian_company_insolvency by naming the Czech register and country explicitly.

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 when-to-use context, explicitly stating that legal-person debtors are the only supported subjects and that natural persons' IČOs will be refused with a 404. It does not name alternative tools for natural persons or other countries, but the exclusion and error behavior effectively guide the agent away from invalid usage.

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

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

Annotations already mark readOnlyHint and openWorldHint; the description adds valuable caveats beyond that: revenue is 'null = not published, never zero', amounts are in the filing currency (mostly DKK), and the official XBRL URL is included. No contradiction with the read-only annotation — the description consistently describes a read operation. The payment detail (x402, $0.05) is also disclosed, which the 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?

Two sentences carry all essential information: what data is returned, null semantics, currency, URL inclusion, the prerequisite list call, and pricing. No filler, no repetition of schema details — each clause earns its place.

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

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

An output schema exists, so return values need no explanation in the description. The description covers the input workflow (list first), output contents, currency caveat, null semantics, and payment mechanism, making it complete for an agent to call this read-only 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%, so all parameters (id, api_key, x_payment, date_cloture) are already documented in the schema. The description adds a workflow hint connecting date_cloture to list_danish_company_filings, but does not add meaning beyond that, matching the baseline of 3 for 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?

The description states a specific verb+resource+scope: it decodes one Danish fiscal year's financial statements from the company's XBRL annual report (Erhvervsstyrelsen) and enumerates the exact fields returned. It distinguishes itself from the sibling list_danish_company_filings by referencing it as the source of the closing date. The Danish-specific framing and CVR-based id separate it from country-specific siblings like get_french_company_filing and get_belgian_company_filing.

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

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

The description gives an explicit workflow cue — 'Closing date comes from list_danish_company_filings' — telling the agent to list filings first and then call this tool with the chosen date. It does not explicitly state when-not-to-use or name alternative tools, but the Danish scope and the list-then-get pattern provide clear usage context.

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

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

Beyond the readOnlyHint annotation, the description discloses substantial operational behavior: long boards are capped at 300 active and 200 ended mandates and flagged by tronque while counts stay exact, GDPR minimisation means no address or personal identifier is returned, beneficial owners are never guessed, and the output is paid via x402 at $0.01. This goes well beyond what the 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 dense but front-loaded with the core purpose, and every subsequent sentence adds non-obvious operational context: mandate defaults, cap behavior, GDPR privacy constraints, exclusions, and payment. There is no filler and no unnecessary repetition of the schema.

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

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

For a 4-parameter tool with an output schema and readOnlyHint/openWorldHint annotations, the description covers data scope, defaults, limitations, privacy, exclusions, and payment. Nothing needed to correctly select and invoke 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 coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema. It clarifies that active mandates are the default, that inclure_anciens is where founders are normally found, and that capped results are flagged by tronque while counts remain exact.

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 Danish company officers and directors live from CVR, with an explicit list of included body types and data fields such as name, body, role, and mandate dates. It also differentiates itself by explicitly disclaiming beneficial owners, which separates it from sibling beneficial-owner 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 context: live CVR data, active mandates by default, and when the inclure_anciens parameter is needed — ended mandates, where founders usually appear. It explicitly states an exclusion, that beneficial owners are not exposed by this access, but it does not name alternative sibling tools or offer explicit when-to-use/not-use routing.

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 substantial behavioral context: data source (RIK, CC BY 4.0), monthly refresh, null semantics (null = not published, never zero), statutory/consolidated separation, PDF-only handling, absence of default-risk score, and payment via x402. It also explicitly warns not to misread score_defaillance as a low score, which is critical for correct interpretation.

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 well-organized: it opens with the core purpose, then lists covered figures, then notes on PDF and default risk, and ends with payment. Every sentence adds value; there is no fluff. It is not as short as possible but appropriate for the information density. Front-loaded with the main purpose.

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

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

For a data-retrieval tool with an output schema (which explains return values), the description covers all operational aspects an agent needs: data source, refresh cadence, coverage, null handling, statutory/consolidated, PDF limitation, default-risk caveat, and payment. No critical usage information 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 parameter descriptions are already detailed (e.g., api_key payment method, x_payment header, registrikood pattern). The description adds the exact cost ($0.02) and clarifies that payment is via x402, and reiterates that registrikood is an 8-digit code. This goes slightly beyond schema, justifying a 4 rather than baseline 3.

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+resource: 'Estonian company annual accounts — annual-report key figures'. It clearly distinguishes from siblings by country (Estonia) and scope (every financial year since 2019). It also notes statutory vs. consolidated figures and PDF-only limitation, further refining its purpose.

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

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

Provides clear context: 'EVERY published financial year since 2019 in one call' and notes limitations ('Filings submitted as PDF only... are not served', 'No default-risk score is computed for this country yet'). While it doesn't name alternative tools explicitly, the country-specific naming and coverage statements make usage intent clear. It lacks explicit 'use instead' guidance but is still strong.

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

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

The description goes well beyond the readOnlyHint and openWorldHint annotations: it discloses the current-mandates-only limitation, absence of end dates/history, GDPR redaction rules, the 404/payment cancellation for FIE, the no-role marker, and the x402 payment cost. This is rich behavioral disclosure with no contradiction to 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 long but exceptionally information-dense, with the core purpose front-loaded and every clause contributing a constraint or behavioral detail. The phrasing is occasionally awkward, but there is no fluff and no sentence fails to earn its place.

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

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

An output schema exists, so return-value details are already covered. The description adds coverage of data source, refresh cadence, role taxonomy, current-mandate scope, GDPR limitations, legal-person restriction, error behavior, and payment mechanism. An agent has everything needed to decide 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 description coverage is 100%, so the baseline is 3. The description adds meaningful context by clarifying that registrikood must belong to a legal person (FIE is rejected) and by explaining the x402 payment flow that governs the x_payment parameter.

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

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

The description clearly identifies the resource as officers and governance of an Estonian company and enumerates the exact role categories returned. This distinguishes it from Estonian siblings like get_estonian_company_accounts and get_estonian_company_shareholders, as well as from other countries' officer tools.

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

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

The description gives clear context: it is for Estonian companies only, returns current mandates only, and explicitly excludes sole proprietorships (FIE), which are refused with a 404. It does not name alternative sibling tools, so it falls short of full routing guidance, but the usage conditions are unambiguous.

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

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

Even with readOnlyHint=true and openWorldHint=true, the description adds substantial behavior beyond annotations: fail-closed counting for unknown etat_code codes, the distinction between alerte and nombre_alertes, the explicit positive answer for a still-registered entity with no ruling, the 404 for struck-off entities, and the x402/prepaid-credit payment behavior.

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 front-loaded with the core resource and scope, then proceeds to nuanced edge cases and payment details. It is long, but every sentence carries decision-relevant information about result interpretation or failure behavior; only slight restructuring would improve readability.

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

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

Given the tool's complexity, the description covers data source, ruling types, status fields, counting semantics, no-data cases, struck-off behavior, and payment options. With the output schema also provided, an agent has everything needed to call the tool correctly and interpret its response.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters well. The description adds useful contextual information about payment and output semantics, but it does not materially deepen the meaning of the parameters themselves, matching the baseline for 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?

The description identifies a specific resource (Estonian company registry rulings from the official e-Business Register open data) with a clear read operation and enumerated content types: registry entries, warnings, fines, and orders. This distinguishes it from siblings like get_estonian_company_accounts and other country-specific tools without ambiguity.

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 strong contextual guidance for when the tool applies: it targets Estonian companies, includes both no-ruling and struck-off edge cases, and specifies the data source and licensing. It does not explicitly name alternatives or state when not to use it, but the scope is clear enough for an agent to route 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?

Annotations only declare readOnlyHint and openWorldHint. The description adds substantial behavioral context: GDPR restrictions (natural persons never named), corporate holder naming rules, the meaning of 'aucun_associe_inscrit', payment requirements (x402, USDC/EURC), refusal cases, and data freshness ('refreshed daily'). This goes far beyond the annotations and clearly informs the agent of edge cases 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 long sentence with semicolons, but every clause adds essential information—data fields, GDPR rules, legal entity scope, payment, and edge cases. It is dense but not redundant, and it front-loads the core purpose before diving into specifics. A slightly more structured formatting (e.g., bullets) would improve readability, but the content is efficient.

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

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

Given the complexity of the tool (payment, GDPR, legal entity rules, multiple output fields) and the presence of an output schema, the description covers all necessary aspects: data source, refresh rate, legal constraints, payment method, refusal conditions, and special register facts. An agent can fully understand when and how to invoke this tool without needing additional clarification.

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 describes all three parameters with 100% coverage, including the pattern for registrikood and the purpose of api_key and x_payment. The description does not add parameter-specific detail beyond what the schema provides, but it does mention the payment mechanism contextually. Since the schema covers everything, a baseline score of 3 is appropriate.

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

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

The description explicitly states the tool returns members and shareholders of an Estonian company from the official e-Business Register, with detailed specifics about the data (holding percentage, nominal value, ownership type, etc.). This clearly distinguishes it from siblings like get_estonian_company_officers or get_estonian_company_accounts by naming the resource and scope.

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

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

The description gives explicit when-not conditions: 'Legal persons only: sole proprietorships are refused (404, payment cancelled)' and clarifies that natural persons are only counted, not named. However, it does not mention alternative tools for other jurisdictions or related data (e.g., beneficial owners), so it lacks explicit alternatives. Overall, it provides clear usage context without naming 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 annotations (readOnlyHint, openWorldHint), the description discloses critical non-obvious behavior: only ~57% of award notices carry a usable identifier, so an empty list is not proof of absence; coverage starts at 2023-10-25; and the tool is paid via x402 at $0.02. It also clarifies the identifier-matching behavior (SIREN/SIRET with spaced variants). This goes well beyond the annotations and no 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 well-organized: scope and content first, then coverage caveat, then complementary tool, then payment. Every sentence earns its place; it is slightly long with embedded clauses, but no waste and no 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?

An output schema exists, so return-value details are unnecessary. The description covers purpose, coverage limitations, the empty-result caveat, the complementary sibling, and cost. The payment flow is further detailed in the parameter descriptions, and no essential context for correctly 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%, with siren, api_key, and x_payment all documented in the schema. The tool description adds identifier-matching nuance but no additional parameter-level meaning or syntax beyond what the schema already provides, so the baseline score of 3 applies.

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

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

The description states a specific verb and resource: retrieving European public procurement awards won by a French company from official TED data. It enumerates the returned content (buyer, country, subject, notice-level amount, CPV codes, links) and explicitly differentiates itself from the sibling get_french_company_public_procurement, so an agent can immediately tell what this tool does and how it differs.

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 names the alternative tool explicitly ('Complements get_french_company_public_procurement (French DECP, below-threshold)') and supplies coverage conditions: eForms notices since 2023-10-25, above EU thresholds, identifier-matched. This gives a clear context for when to choose this tool over the French national one, though it could be even more explicit about 'use this when you need EU-wide above-threshold awards.'

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, so the description doesn't need to restate safety. It adds valuable behavioral context beyond annotations: the matching is by national identifier in all its TED forms, the coverage rate varies by country (40–86%), `nombre_avis: 0` is a non-conclusive absence, the query is live but cached 24h, and payment is via x402 with a cost. It does not fully describe the output schema, but the output schema exists and the description lists the main fields. The only minor gap is not detailing pagination or error behavior beyond the credits error, but the description is rich.

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

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

The description is dense but every sentence earns its place: scope, matching method, coverage caveat, sibling routing, caching, and payment. It is front-loaded with the core purpose. It is slightly long, but the density of useful information justifies the length. A small deduction for the parenthetical coverage measurement date and the detailed payment sentence, which could be trimmed, but overall it is well-structured.

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

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

Given the tool's complexity (4 params, output schema, payment mechanism, country-specific coverage), the description covers all essential aspects: what it returns, how matching works, the non-conclusive absence semantics, caching, payment, and sibling alternatives. The output schema exists, so return values need not be fully enumerated. 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%, so the baseline is 3. The description adds meaning beyond the schema: it explains that `id` is the 'national register identifier' and that it is matched in 'every form it takes on TED (`variantes_identifiant`)', which clarifies the semantics of the id parameter. It also explains the `pays` parameter by listing the exact allowed country codes in prose. The payment parameters are already well described in the schema, and the description adds the cost context. This exceeds the 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 verb ('get'), a precise resource ('European public-procurement contract awards won by a company from [10 listed countries]'), and the data source (TED). It also names the sibling alternatives for France and the UK, which distinguishes it from get_eu_procurement_awards and the country-specific procurement tools. The scope 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?

The description explicitly names alternatives: 'France has get_french_company_eu_procurement, the UK get_uk_company_public_procurement.' It also gives a clear when-to-use signal by listing the exact countries covered and explaining the matching method (national identifier). It implies when not to use it (for France/UK) and points to the right sibling. This is 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 only declare readOnlyHint and openWorldHint. The description adds substantial behavioral context: it warns that no default-risk score is computed and that score_defaillance carries statut non_evaluable ('never read it as a low score'), explains the GLEIF group fields and the financements_ue block for certain countries, and details the payment mechanism (x402 vs api_key). This goes well beyond the annotation hints and discloses edge cases and caveats.

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, very long paragraph with dense information about many countries, blocks, and special cases. While it starts with a clear purpose statement, the rest is a wall of text that is hard to scan. It could be structured with bullet points or separated by country groups. The lack of conciseness reduces its usability despite the richness of 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 tool's complexity (multiple countries, country-specific blocks, LEI and funding data, payment, and no-risk-score caveat), the description covers almost everything an agent needs to call it correctly. It mentions coverage, exceptions, and behavioral notes. An output schema exists, so return values are covered. It is slightly overwhelming but 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% and every parameter has a description. The tool description adds some context about the parameters (e.g., id is the national register identifier, pays is ISO-3166 alpha-2), but it does not substantially extend the schema's own descriptions. It does mention examples in the schema already, and the description does not introduce new parameter-specific constraints beyond what is in the schema. Baseline 3 is appropriate.

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

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

The description clearly states a specific verb ('lookup') and resource ('unified European company profile by country and national register ID'), and lists many countries, which distinguishes it from the numerous country-specific profile tools in the sibling list (e.g., get_french_company_profile). The scope is unambiguous and the 'same JSON schema for every country' conveys a consistent contract.

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 this is the general European profile tool by listing many countries, but it never explicitly says when to use it instead of a country-specific sibling (e.g., get_french_company_profile). It does give some coverage guidance ('Denmark/UK when enabled', 'elsewhere via GLEIF'), but no explicit exclusions or alternative recommendations. Usage context is inferable but not 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 declare readOnlyHint=true and openWorldHint=true, and the description adds meaningful behavioral context: the 24h cache, the 404 for unknown Business ID with no charge, the payment mechanism (x402 or api_key), and the explicit statement that codes and dates only — never a person. It also discloses that procedures_inscrites summarises specific code families. This goes beyond the annotations without contradicting 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?

The description is dense but well-organized: it front-loads the source and scope, then details the content, then the payment and error behavior. Every sentence carries information, though the long parenthetical list of notice types and family codes makes it slightly heavy. It earns its length given the complexity of the data.

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

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

Given the output schema exists and the annotations cover safety (readOnly, openWorld), the description is complete: it explains the data source, coverage, ordering, content, error behavior, and payment. An agent has everything needed to decide whether to call this tool and what to expect. The only minor omission is pagination, but the description says 'every notice' and 'newest first', which is sufficient for a first call.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds value by explaining the payment flow (x402 quote vs api_key prepaid credits) and the 404 behavior tied to the id parameter. It does not repeat the schema's regex or example, but it clarifies the operational semantics of the parameters, which is useful.

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: it retrieves Finnish trade-register notices from the PRH open data, and it enumerates the exact content (date, record number, notice type, register entry codes, procedures_inscrites, register memberships). It clearly distinguishes itself from siblings like get_finnish_company_filing and list_finnish_company_filings by focusing on notices/events rather than filings.

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

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

The description gives clear context: it covers notices since late 2014, newest first, and notes the 24h cache and live data source. It does not explicitly name alternative tools or state when not to use it, but the scope is specific enough that an agent can infer when to select it over filing-oriented siblings. A small gap: no explicit exclusion of when to prefer get_finnish_company_filing.

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

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

Annotations already provide readOnlyHint and openWorldHint; the description adds meaningful behavioral detail beyond them: null revenue means 'not published' rather than zero, prior-year comparatives are as published in the same filing, and payment is via x402. No contradiction with annotations.

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

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

The description is three short, well-structured sentences with no filler. The core scope and data fields are front-loaded, followed by the prerequisite and payment detail. Every clause earns its place.

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

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

Given the output schema exists and the annotations already cover read-only and open-world behavior, the description supplies all critical operational context: data source, exact scope, field null semantics, prerequisite for date_cloture, and payment cost. An agent has enough information to call 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 value by tying date_cloture to the output of list_finnish_company_filings and by clarifying that the filing covers exactly one fiscal year, which gives extra meaning to both required 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 clearly identifies the tool as retrieving financial statements for one Finnish fiscal year from a PRH XBRL filing, and specifies the exact metrics returned. This distinguishes it from list_finnish_company_filings and other national 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 explicitly states that the closing date comes from list_finnish_company_filings, giving the agent a clear preparatory step. It does not enumerate when-not-to-use cases, but the narrow scope of 'one Finnish fiscal year' and the tool name make the intended use case obvious.

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

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

The description goes well beyond the readOnlyHint/openWorldHint annotations by disclosing data completeness semantics (couverture), update cadence, error behavior (503 on stale stock), and payment implications. This is rich, honest behavioral context that an agent needs before invoking the tool.

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

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

The description is dense but every sentence adds value: scope, content, ordering, completeness guarantee, update cadence, error semantics, and pricing. It is somewhat long but effectively front-loaded with the core resource and purpose.

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

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

Given the rich annotations and output schema, the description still contributes essential information: what notices are included, the couverture guarantee, freshness semantics, failure mode, and cost. An agent has everything needed to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents rna, api_key, and x_payment fully. The description adds the RNA-based lookup context but does not need to repeat parameter details; 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 uses a specific verb ('get') and resource ('Official Journal notices (JOAFE, DILA) of a French association by RNA number'), and differentiates the tool by describing the exact notice types, fields, and ordering. The BODACC analogy further distinguishes it from profile or search 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 implies when to use it — when JOAFE official journal notices for a French association are needed — and provides important operational context like weekly loading and stale-stock behavior. It does not explicitly name alternative tools or state when not to use it, but the scope is clear enough for an agent.

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, and the description adds meaningful behavioral context: unknown identifier returns 404 without charge, payment is via x402 or optional API key, and the SIREN appears only when Sirene confirms an association. It also discloses data exclusions. The only minor gap is no explicit statement about rate limits or response delays, but for a read-only profile lookup this is adequate.

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

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

The description is dense but efficient, front-loading the core purpose and resource. Every sentence adds information: data source, field list, SIREN condition, SIREN-less coverage, exclusions, error behavior, and pricing. Only minor trimming could improve flow.

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 tool with an output schema and rich annotations, the description covers the essential context: data source, scope, exclusions, payment model, and error semantics. An agent has enough information to select and invoke it correctly, and the output schema handles return structure.

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 three parameters. The description adds value by clarifying the RNA format (W + 9 characters, e.g. W751004076), the meaning of the API key payment fallback, and the x402 payment flow. It does not repeat the schema verbatim.

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), resource (French association profile), and identifier (RNA number) with an explicit source (Répertoire national des associations) and scope (official profile, loi 1901). The list of fields and the limitation to associations without SIREN distinguish it clearly from sibling tools like search_french_associations 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?

Explicitly tells the agent to use search_french_associations first when only a name is available, and clarifies exclusions (no officer/declarant data, Alsace-Moselle excluded). This directly addresses alternatives and when-not-to-use.

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 data is AI-extracted from public filed deeds, natural persons are never named due to GDPR/CJEU, and results include confidence and source. It also cautions that this is reconstructed public data, not an official register—valuable behavioral context.

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

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

The description is dense but well-structured, front-loading the core purpose and then adding important caveats about GDPR, source reliability, and payment. It earns its length, though the heavy punctuation and caps slightly reduce readability.

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, annotations, and full parameter coverage, the description is complete: it explains the source, limitations, privacy behavior, payment mechanism, and what the data is not. An agent has enough context to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents siren, api_key, and x_payment. The description adds payment context (x402, $0.35) but does not add new field-level meaning beyond what the schema provides, matching the 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 clearly identifies the resource as the ownership/share capital structure of a French company, sourced from public INPI articles. It explicitly distinguishes itself from beneficial-ownership registers, which differentiates it from siblings like get_uk_beneficial_owners.

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

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

The description gives a clear when-not-to-use signal: this is NOT a beneficial-ownership register or beneficial-owner identification. It also specifies the source (INPI articles) and purpose. However, it does not explicitly mention sibling alternatives such as get_french_company_profile or get_french_company_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?

Beyond the readOnlyHint and openWorldHint annotations, it discloses that results are reverse-chronological, that an empty list is returned when there are no new announcements, that it is paid via x402, and that it does not detect profile edits. This gives the agent concrete expectations about the call outcome 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 compact and information-dense: scope, use case, event types, exclusion, empty-result behavior, and payment are all covered without filler. The structure front-loads the core purpose and then adds supporting 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?

With an output schema present and all parameters documented, the description covers the remaining operational needs: the monitoring use case, the empty-list behavior, and the x402 payment mechanism. An agent has enough information to select and invoke the tool correctly.

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

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

All parameters are already fully documented in the schema, so the 100% schema coverage sets a baseline of 3. The description adds only contextual meaning for the date parameter ('SINCE a given date') and does not provide meaningful additional parameter semantics beyond the schema.

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

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

The description states a specific resource (French company BODACC gazette announcements) and a specific operation (get new announcements since a date). It also explicitly distinguishes itself from profile-level tools by saying it detects new BODACC publications, not field-level edits of the 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?

It clearly frames the intended use case as 'poll-mode watchlist surveillance for a portfolio' and clarifies that it is about new publications, not profile changes. However, it does not explicitly name alternative tools such as search_bodacc_announcements or state when not to use this 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 only declare readOnlyHint and openWorldHint, but the description goes far further: metadata-only scope (never text nor a person's name), a 400 response for sole proprietorships / restricted-diffusion entities that is never charged, and the paid x402 pricing ($0.02 in USDC/EURC). It also discloses the empty-result semantic and the establishment-cap behavior, all of which an agent needs.

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 purpose is front-loaded and every clause (source, scope, payment, error behavior) carries real information. It is a single heavily-parenthesized run-on sentence, which is dense but 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?

Given an output schema exists, the description need not explain return fields, yet it covers scope limits, error/payment behavior, and empty-result interpretation. Nothing material for a correct call 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 both siren and the two payment parameters are already fully documented in the schema, establishing the baseline of 3. The description adds only the pricing model and confirmation that lookups key on SIREN, not new syntax or per-parameter 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?

States a specific verb and resource (company-level collective agreements of a French SIREN) and pins the data source (Légifrance ACCO fund, mandatory since 2017-09-01). It enumerates the returned fields (title, nature, DILA themes, IDCC, signatories, link), which makes it unmistakably distinct from sibling tools like get_french_company_file or get_french_company_legal_alerts.

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

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

It explains the search mechanics (queried via filing SIRET over establishments known to Sirene, capped at 25) and the crucial interpretation caveat that an empty list never means 'no social dialogue'. However, it never states when to prefer this tool over the many adjacent French-company siblings, so routing guidance is implied rather than explicit.

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, it discloses specific behaviors: coverage is partial (~62%), missing results don't rule out litigation, sole proprietorships return 400, and the payment mechanism (x402) and cost are specified. This added context is actionable and not redundant 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 sentence contributes: purpose, content, exclusions, coverage, alternative, error case, and pricing. It is front-loaded with the core purpose and then adds necessary caveats without excessive verbosity.

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

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

The description covers all essential operational aspects: what data is returned, what is excluded, coverage limitations, an alternative tool, error handling for sole proprietorships, and pricing. Given that an output schema exists, the description is comprehensive enough for an agent to invoke the tool correctly.

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

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

Schema description coverage is 100% for all three parameters (siren, api_key, x_payment), so the schema already fully explains them. The description does not add parameter-level detail 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 clearly states it provides commercial-court decisions for a French company (SIREN) from Judilibre, and enumerates the specific content (counts, closed-list nature, role, other companies, official link). It also names a related sibling tool (get_french_company_legal_alerts) for insolvency judgments, helping distinguish it.

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 on what to expect (partial coverage, absence of results doesn't mean no litigation) and mentions an alternative for insolvency judgments (get_french_company_legal_alerts). However, it does not explicitly state when to use this tool versus other siblings beyond that single alternative, so it stops short of a full usage guide.

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

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses the deterministic BODACC override that marks active insolvency/liquidation/closure as proven default, and it fully explains the couverture_axes semantics: silent axes cannot penalise, so fewer computed axes imply possibly understated risk rather than a better score. It also explains payment behavior and the failure mode on insufficient balance, with no contradiction of 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 long but every sentence earns its place: scoring inputs, output fields, the BODACC override, the decision-support caveat, silent-axis interpretation, and payment details. It is front-loaded with the core purpose and remains readable despite the density.

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

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

For a paid, multi-component risk tool, the description is exceptionally complete: it covers scoring inputs, output shape, confidence, override behavior, silent-axis interpretation, decision-support limits, cost, and payment failure mode. The presence of an output schema already handles detailed return structure, so 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?

The schema already documents all three parameters with 100% coverage, including the api_key/x_payment precedence and the siren pattern. The description adds the cost context ($0.10 via x402) but does not materially enrich the meaning of the siren parameter beyond what the schema provides, 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?

The first sentence names the exact resource (French company default-risk score) and scope: a 0-100 score at ~12 months built from financial ratios plus a BODACC insolvency override. This clearly differentiates it from sibling tools such as health_summary or industrial_risk, since the focus is specifically on credit/insolvency default rather than general health or industry risk.

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

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

The description implies its use case — when a default-risk score for a French company is needed — and adds an important caveat that it is decision-support only, not a solvency opinion or credit rating. However, it never explicitly routes to alternatives among the many French-company getters (financials, health_summary, industrial_risk), leaving the agent to infer when to pick this over them.

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

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

Annotations already declare readOnlyHint and openWorldHint, but the description goes further: it discloses the payment mechanism (x402), the VAT matching method, the non-conclusive absence semantics (aucun_financement), and states 'Facts only, no score'. This adds substantial behavioral context beyond the annotations, with 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?

The description is dense but efficient: it front-loads the core purpose, then lists specific output fields, and adds critical caveats (open world, payment) without fluff. It is longer than typical, but every sentence earns its place given the tool's complexity.

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

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

The description covers everything an agent needs to call this tool correctly: data source, matching method, output contents, payment details, the meaning of absence, and licensing. Given the output schema is also provided, no critical information 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 parameter descriptions are already informative (siren, api_key, x_payment). The description adds context about the payment flow (x402 vs api_key) but that is already present in the schema. No extra parameter-level meaning is added beyond what the schema provides, so a 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 states exactly what the tool does: retrieves EU research funding data for a French company from CORDIS, with a precise list of fields and totals. It is clearly distinct from all sibling tools, none of which cover EU research funding, so there is no ambiguity.

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

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

The description clearly implies when to use it (for EU Horizon funding info about a French company) and even notes the payment method and required SIREN. It does not explicitly name alternatives or say 'use this instead of X', but given its unique scope among siblings, the use case is unambiguous. A minor gap is no explicit exclusion of other funding sources.

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?

Despite readOnlyHint/openWorldHint annotations, description goes well beyond: discloses per-block pricing, block-level failure semantics with a closed reason list (aucune_donnee, non_diffusible, panne_amont), 503 on total failure, and the x402 vs api_key payment behavior. This is rich behavioral context that annotations can't capture. 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?

Front-loaded with the core value (one call, pay per block), followed by pricing, error semantics-case. It's dense but every sentence adds info; the key distinctions and failure modes are stated early. Might be slightly long but all content earns its place.

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

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

Given the rich schema describing parameters and annotations covering read-only safety, the description covers selection criteria vs sibling, pricing, failure semanticschen and alternative. No output schema but lifecycle (503, 402, charging) is stated.

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% – parameters siren, blocs, api_key, x_payment already described in the schema. The description doesn't add much beyond that (it restates the block list). Baseline 3 is appropriate; schema carries the load.

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

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

The description clearly states a specific verb+resource: retrieve a French company file by selecting blocks. It differentiates itself from siblings by saying this is the consolidated multi-block call, and it explicitly routes to get_french_company_intelligence when the user wants a verdict. This is a well-scoped, actionable definition.

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?

States when to use: 'when you want several things about the same company' and don't want separate calls. Names the alternative (get_french_company_intelligence) and explains when to prefer it. Also mentions optional api_key vs x402 payment modes, which guides request setup.

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

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

The description discloses important behaviors: duplicated or wrong rows are served under exercices_ecartes rather than silently dropped, consolidated accounts are split out, analytical lag is flagged, ratio interpretability is warned for holdings, and the payment mechanism is clearly explained. These details go well beyond the readOnly annotation and are not contradicted by it.

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 each sentence carries substantive caveats or behavioral details that support correct use. It is structured in flowing prose rather than crisp bullets, so it is not maximally concise, but it remains purposeful.

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 gives a complete picture for an agent: data source, year range, data quality warnings, lag semantics, interpretability limitations, and payment requirements. Combined with the output schema, it covers the important decision-relevant context with no major gaps.

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

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

The input schema already provides full descriptions for all three parameters, including the siren pattern and payment-related behavior of api_key and x_payment. The tool description adds payment context but does not materially improve parameter understanding beyond the schema.

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

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

The description clearly states that the tool returns French company annual accounts and financial statement data, including liasse fiscale line items, for up to 20 fiscal years. This makes its purpose distinct from the many sibling profile, risk, and 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 scope of the data implies when the tool should be used, but the description does not explicitly name sibling alternatives or state when the tool should not be used. Usage guidance is therefore implicit rather than explicit.

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 establish read-only and open-world characteristics. The description adds substantial behavioral disclosure: a model fills a closed evaluation grid, deterministic guards overrule model errors, corrections appear in divergences_modele, non-filing entities get non_evaluable fields, results are cached 7 days, and payment is handled via x402. This goes well beyond the annotations.

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

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

The description is dense but every clause earns its place: purpose, output composition, model-override behavior, edge cases, alternative routing, caching, and pricing. It is front-loaded with the core function and avoids redundant restatement of the schema.

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

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

Given the output schema exists, the description need not restate return values. It covers edge cases, alternative selection, deterministic override behavior, data provenance, caching, and payment flow, making the tool self-sufficient 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 input schema already documents all three parameters thoroughly, including api_key and x_payment semantics. The description adds value by naming the exact x402 price and confirming the prepaid-credit alternative, but much of the parameter-level detail is already in the schema, so this is a modest increment rather than a heavy 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 opens with a specific verb and resource: 'Business-health and risk read-out of a French company', and lists concrete outputs (verdict, strengths, warning signs, activity trend, confidence level, reconciled grid). It also distinguishes itself from identity-focused tools by explicitly recommending get_french_company_profile when only identity is needed.

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 when to use the tool, gives a clear when-not case (entities filing no annual accounts return non_concluant), and names an explicit alternative for identity-only needs. This gives an agent enough routing information without opening sibling schemas.

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 far beyond what annotations (readOnlyHint, openWorldHint) already convey: data is derived on demand from a sub-24h snapshot with nothing stored, the count is a lower bound with brand names and temp agencies excluded, the SIREN-keying vs name-matching fallback path is disclosed, and the x402 payment cost is stated. It even reinforces openWorldHint by explaining that null means absence is not provable. 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?

Front-loaded with the core purpose, and every clause earns its place: data source, freshness, privacy, methodology caveats, exclusions, use cases, and pricing. Deduction only for structure — the opening sentence is a dense run-on with heavy parenthetical asides that could be split for readability.

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 needn't document return values, yet it still enumerates all returned fields. It covers the what, the how (matching methodology and caveats), the when, the privacy posture, and the cost; the parameters are fully documented in the schema. Nothing an agent needs to call or interpret 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 coverage is 100%, so baseline is 3; the description adds meaning on top by explaining how the siren parameter drives behavior (matched via France Travail's employer page when one exists, else strict company-name matching over known locations, yielding a lower-bound count) and by adding the $0.02 x402 price context relevant to the 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 names a specific resource (France Travail data) and enumerates the exact deliverable: hiring signals for a French company, listing every signal type (actively-hiring flag, active-postings count, ROME families, contract-type mix, pay-amount share, Egapro index, INSEE workforce bracket). This uniquely distinguishes it from the 60+ siblings — no other tool covers hiring, so an agent can identify it unambiguously.

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 states when to use: 'Use for sales intelligence (a hiring company is an active company) and HR/expansion signals,' and what not to expect from it ('never posting texts or recruiter contacts'). It does not name alternative tools, but no sibling provides hiring signals, so the when-not guidance carries the weight here.

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, it discloses the payment requirement and cost via x402 ($0.01) and, crucially, the no-classified-facility behavior: return level 'aucun', with the clean answer being the signal. This prevents an agent from treating a legitimate absence as an error. 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?

Three sentences front-load the core output and source, then cover the key edge-case signal and pricing. The data-element list is dense but every item is relevant, and there is no filler.

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

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

Given the output schema and full parameter coverage, the description provides the essential operational context: source, included fields, the 'aucun' sentinel, and payment mechanism. An agent has enough information to call the tool correctly and interpret its key result.

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 siren, api_key, and x_payment are already fully documented in the input schema. The description adds the per-SIREN synthesis framing and payment context but no new parameter-level meaning, 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 names a specific resource — the ICPE industrial-risk and environment profile from the official Géorisques/DGPR register — and lists concrete data elements such as Seveso status, authorisation regime, activity state, and IED flag. This clearly distinguishes it from sibling financial-risk or compliance 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 establishes a clear domain: French industrial-risk and environmental ESG assessment via classified facilities, so an agent can infer when this tool is appropriate over siblings like get_french_company_default_risk or get_french_company_legal_alerts. It does not explicitly name alternatives or state exclusions, so it stops short of perfect 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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses important behaviors: patents are NOT sorted upstream while trademarks and designs are date-descending, every date has a date_nature field, blocks have liste_ordre, patent inventor names are never returned, and the tool is paid via x402 at a specific price. These details materially shape how an agent interprets results and sets 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 every sentence adds necessary context: data source, payload structure, ordering caveats, a conspicuous redaction rule, a usage signal, and payment mechanism. It is front-loaded with the main purpose and then layers on essential caveats without fluff.

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

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

The description covers the data source, what counts and items are included, field-level semantics like date_nature and liste_ordre, sorting exceptions, personal-data redaction, payment options, and the intended analytical signal. With an output schema also available, an agent has everything needed to call and interpret 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 meaningful descriptions for siren, api_key, and x_payment. The tool description adds no parameter-level meaning 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 names a specific resource ('intellectual-property portfolio of a French company from INPI open data') and enumerates the concrete data types and fields returned: trademarks, patents and designs with counts, numbers, titles, statuses, ISO dates, classifications, and trademark registration/expiry dates. This clearly distinguishes it from sibling French-company tools focused on financials, legal alerts, capital, or filings.

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

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

The description gives clear context for when the tool is relevant by labeling it 'An R&D/brand-value signal,' which tells an agent this is the IP-focused lookup among many French company tools. It does not name explicit alternative tools or exclusions, so it falls short of a 5.

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

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

Annotations only provide readOnlyHint and openWorldHint, but the description adds extensive behavioral context: paid via x402 at $1.00, credit-vs-x402 payment precedence, closed-list signals traced to source registers, deterministic verdict codes and capping logic, indeterminate-verdict edge case, reserves/portee/confidence fields, and Ed25519-signed auditable output. Far beyond what annotations disclose, with 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?

The single most important framing (GO/NO-GO due-diligence call) is correctly front-loaded, and most sentences carry real output-semantics value. But the description is an exceptionally long single-paragraph wall packing dozens of field names and version notes, which hurts scanability and pushes well past what is needed to select the tool.

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 highly complex financial tool with an output schema, annotations, and three parameters, the description covers purpose, payment model, verdict semantics, capping/indeterminate edge cases, and auditability comprehensively. An agent has everything needed to decide to call it and interpret the result 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 all three parameters (siren, api_key, x_payment) are already fully documented in the schema. The description adds the pricing fact ($1.00 in USDC or EURC) and payment-model context that is useful for the payment params, but no syntax or format detail beyond the schema, making the baseline 3 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?

States a specific purpose (GO/NO-GO credit, investment, partnership decision) and resource (French company intelligence report), and explicitly positions itself as the aggregator that cross-references every Sirenic block in one call. This clearly distinguishes it from the many single-block siblings like get_french_company_financials or get_french_company_legal_alerts.

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

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

Opens with an explicit use case (GO/NO-GO due-diligence decisions) and calls itself 'the flagship due-diligence call', giving strong context for when to pick it. However, it never names an alternative or states when NOT to use it (e.g. use a granular single-block tool for a narrower question), so routing against siblings is left to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds substantial behavior beyond them: per-company billing at $0.105 with a 30% discount, the trouve=false + billed-as-one-lookup behavior for non-diffusible SIRENs, per-block provenance, and the critical spendControls failure mode where x402 clients reject the quote above $1.00. 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?

Purpose is front-loaded in the first sentence, and the rest of the description packs pricing, edge-case behavior, provenance, and a payment failure mode into roughly 120 words. The final sentence on spendControls is long and dense, but it earns its place because it describes a real client-side failure an agent would otherwise hit blindly.

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 billing, batch processing, and a payment-flow caveat, this description is remarkably complete: output schema covers return values, annotations cover the read-only/open-world profile, and the description covers pricing, missing-company behavior, provenance, target use cases, and the x402 cap fix. Nothing an agent needs to invoke it 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 coverage is 100%, so the baseline is 3 with the schema doing the heavy lifting. The description adds genuine meaning on top: each sirens entry is billed at $0.105, a non-diffusible SIREN still costs one lookup, and the x_payment flow is tied to the $10.50 cap issue. This elevates it above baseline but stops short of 5 since the schema already documents parameter formats well.

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,' a specific verb+resource+scope statement that clearly identifies the batch operation and its bounds. The batch framing cleanly distinguishes it from the single-company sibling get_french_company_kyb_file without needing to name it.

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 when to use the tool: 'Ideal for prospecting and compliance agents processing lists.' The 2-to-100 range and batch framing imply that single-company lookups should go elsewhere, but there is no explicit exclusion or named alternative (e.g., 'use get_french_company_kyb_file for one company'). Clear context, but no explicit when-not.

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 readOnlyHint and openWorldHint annotations already establish that this is a safe read operation, lowering the burden on the description. The description adds useful behavioral context by specifying that every block carries provenance including official register, licence, version, as_of date, and precision_as_of semantics. It does not cover failure modes or latency, but for a read-only annotated tool this is a reasonable gap.

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

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

Every sentence in the description earns its place: the bundle definition, the explicit usage rule, the provenance explanation, and the pricing. The text is dense but not padded, and the most decision-relevant information 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 that an output schema exists, the annotations cover the read-only/open-world profile, and the schema fully documents the parameters, the description is complete enough for an agent to invoke the tool correctly. It covers scope, alternatives, payment path, and provenance semantics.

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 documents all three parameters with 100% coverage, including detailed semantics for api_key and x_payment, so the description does not need to repeat that. The description adds general payment and bundle-content context but not new parameter-level meaning, so the baseline score of 3 is appropriate.

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

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

The description clearly states that this tool returns a complete KYB bundle for a French company in one call and enumerates the consolidated contents: identity, officers, BODACC legal alerts, financials, sanctions screening, VAT number, and a completeness score. It also names the narrower sibling tools, so an agent can easily distinguish it from dedicated single-purpose 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 explicitly says when to use this tool: when the whole due-diligence picture is needed at once, and when not to use it: when only one part is needed, in which case it names the dedicated alternatives and notes they are cheaper. This is direct routing guidance with concrete exclusion conditions.

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

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

Beyond the readOnlyHint annotation, the description discloses meaningful operational behavior: results are grouped and sorted most-recent-first, and the tool is paid via x402 at a specific price. This adds context that structured annotations do not convey, and nothing contradicts the annotations.

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

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

The description is a single compact sentence that front-loads the primary purpose, then appends scoping, content types, ordering, and payment details. Every clause adds information; there is no filler or redundancy.

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

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

Given the output schema, read-only annotation, and full parameter documentation, the description provides all essential context: source (BODACC), scope (specific French company), content types, ordering, and cost. The only minor omission—explicit differentiation from siblings—is covered by the purpose clarity and usage context already present.

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

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

Schema description coverage is 100%: siren, api_key, and x_payment are all documented in the input schema. The tool description only adds a passing mention of payment, which does not meaningfully supplement per-parameter semantics, so the schema bears the full burden and the baseline 3 applies.

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

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

The description states a specific verb ('get'), a clear resource ('legal alerts and legal notices for a French company from BODACC'), and enumerates concrete content types (insolvency proceedings, court filings, deregistrations, business sales). It also adds formatting/scoping details ('grouped, most recent first') that distinguish it from broader BODACC search tools or generic regulator-alert tools.

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

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

The description makes the tool's context clear: it is for French company legal alerts from the official BODACC gazette, which strongly implies when an agent should reach for it. However, it does not explicitly name alternative siblings or state when not to use it (e.g., versus search_bodacc_announcements or get_french_company_changes), leaving some inference to the agent.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description adds vital behavior: `inscrit: false` is a meaningful answer rather than an error, the tool is organisation-level and returns no personal data, and payment occurs via x402 at a known cost. These details materially shape agent expectations and error handling.

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 source, then efficiently lists data fields in a compact flow, followed by two crucial caveats and pricing. Every sentence provides information an agent needs; there is 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?

With an output schema present and one clearly documented required parameter, the description is complete for invocation: it explains scope, data categories, meaningful false semantics, and payment behavior. No critical operational detail is missing for selecting and calling 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 provides 100% coverage with clear descriptions for siren, api_key, and x_payment. The tool description does not add meaning about individual parameters, so the baseline of 3 applies; it neither harms nor significantly improves parameter understanding.

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 returns a 'lobbying and transparency profile of a French company' from the 'official HATVP register'. It enumerates concrete content (status, category, expense brackets, subjects, clients, affiliations) and distinguishes itself from generic company-profile tools by focusing on interest-representation data and organization-level scope.

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

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

The description clearly implies when to use the tool: when an agent needs official French lobbying-register data for an organization. It also states an explicit exclusion — 'Organisation-level only — no personal data' — which prevents misuse for individual searches. It does not name sibling alternatives, but the source and scope are unmistakable.

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 readOnly and openWorld, and the description adds genuinely new behavioral facts: the call costs $0.50 via x402, the result is a base64-encoded PDF, and the AI health summary is included only when cached. This goes beyond the annotation baseline, though it stops short of disclosing generation latency or per-call regeneration semantics.

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

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

Three terse sentences front-load the artifact type and scope before moving to contents, return format, and cost. The parenthetical content list is dense but every clause earns its place; there is no redundant phrasing or filler.

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

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

Given no output schema, the description compensates by stating the return as a base64 PDF and the conditional inclusion of the health summary; the schema fills in the two-step payment flow (omit x_payment for a quote). Minor gaps remain — generation latency and whether each call incurs the fee — but nothing that would prevent a 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?

Schema description coverage is 100% — siren's format is fully specified by pattern and description, and both api_key and x_payment carry detailed behavioral descriptions (prepaid credits vs. the x402 quote flow). The description adds only the price point that contextualizes the payment parameters, so it stays at the baseline for fully covered schemas.

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 produced artifact — an on-demand PDF report of a French company — and enumerates its contents (identity, officers, legal alerts, financials, sanctions screening, cached AI health summary) plus the return format (base64 PDF). It distinguishes the tool from data-returning siblings in the French company group by emphasizing the 'shareable due-diligence dossier' format, though it does not explicitly contrast with the closely named get_french_company_kyb_file.

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 the use case — a shareable due-diligence/KYB dossier — and signals that this is a paid premium report ('Paid via x402 ($0.50 in USDC or EURC)'). However, it never names an alternative or states when not to use it, leaving the agent to infer the boundary against siblings like get_french_company_kyb_file or get_french_company_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?

Even with readOnlyHint true, the description goes well beyond annotations: it clarifies the data sources (INSEE Sirene / INPI RNE), explains the meaning of conventions_collectives and that IDCC 9999 means no agreement, and defines groupe_lei as consolidating parent LEI info rather than capital ownership or beneficial owners. It also discloses the paid nature and api_key/x402 behavior, which 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 long but information-dense; every clause adds semantic value covering data fields, sources, disambiguation of 9999, LEI semantics, and pricing. There is a slight readability cost from long parenthetical clauses and run-on structure, but the main purpose is front-loaded and the detail is justified for this tool's complexity.

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

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

For a read-only lookup with an output schema and fully documented parameters, the description covers what the data is, where it comes from, how payment works, and how to interpret tricky fields (9999, groupe_lei). Nothing essential for an agent to correctly call 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%, so the baseline is 3. The description adds value by detailing the payment flow (x402, $0.005 in USDC or EURC), prepaid api_key credits, and the relationship between api_key and x_payment, though much of that detail also exists in the schema. It does not add new meaning to the siren parameter 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?

States a specific verb and resource: 'Full official company profile of a French company by SIREN', then enumerates exact data points (legal name, legal form, head office, NAF code, workforce, officers, VAT, groupe_lei). The closing line positions it as the core company data lookup for KYB and due diligence on France, which distinguishes it from financials, filings, intelligence, and association tools among siblings.

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

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

The description gives clear context: use this as the core official profile for KYB and due diligence on a French company. It does not explicitly name sibling alternatives or state when not to use it, so it misses the top bar for exclusion guidance, but the contextual cue is strong enough for an agent to select it among many similar tools.

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