Sirenic

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

The description adds substantial context beyond the read-only/open-world annotations: the data is official AMF open data refreshed daily, the tool is paid via x402 at $0.01 in USDC or EURC, and results should be cited verbatim. These are operationally important traits not present in the annotations or schema.

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

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

The description is dense but front-loaded with the core purpose, then adds usage timing, data freshness, payment model, and citation requirement. Every sentence carries useful information for selecting and invoking 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?

Given the presence of a full output schema and annotations, the description covers what the tool does, when to use it, source freshness, cost, and citation expectations. An agent has enough information to decide whether and how to call it without needing return-value details in the description.

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

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

Schema description coverage is 100%, so parameter meanings are already well documented. The description reinforces the two lookup paths, name screening versus SIREN-based register lookup, but does not add much beyond the schema's parameter descriptions.

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

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

The description states specific verbs and resources: screening names against AMF blacklists and looking up PSAN/SGP registrations by name or SIREN. It clearly distinguishes this French regulator-specific check from broad company search or generic sanctions screening tools in the sibling list.

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

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

It gives a clear trigger: use before trusting an investment site, crypto provider, or asset manager operating in France. It does not explicitly name when not to use it or which alternatives to prefer, so it falls short of a full 5 under the rubric.

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 the readOnlyHint: discloses per-company pricing ($0.12 × SIREN count via x402), the all-or-nothing 400 refusal that is never charged plus the sirens_refuses payload and replay guidance, and the deliberate design decision to never return a winner. These are exactly the operational facts an agent cannot get from annotations or schema and that change how it plans the call.

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-loading is good — trigger sentence first, output shape second, caveats after. But the middle section is a single 150-word sentence riddled with nested French identifiers (eligibilite_classements, axes_communs, statut/raison/type/donnee/perimetre/exercices/couverture) that is hard to parse on first read and repeats the eligibility idea twice (once in rankings, once in solidite.classement_risque).

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 an output schema already existing, the description still orients the agent on the response's shape and the comparability/eligibility contract, and it covers the payment, refusal and citation obligations. Nothing needed to call it correctly or interpret it responsibly 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 still adds real meaning by tying cost to the SIREN count and by explaining that a single invalid SIREN (sole proprietorship, restricted diffusion, group without legal personality) rejects the whole batch rather than that item. The api_key and x_payment parameters are handled entirely by their schema descriptions, which 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?

States a specific verb set (compare, rank, choose) against a specific resource (2-5 French companies as customers/prospects/suppliers/competitors) and enumerates what comes back (cross-table, per-axis rankings, comparability block). This is clearly distinguishable from single-company siblings like get_french_company_default_risk or get_french_company_financials.

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

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

"Use when asked to compare, rank or choose between 2 to 5 French companies" gives a clear trigger, and it explicitly forbids a wrong path ("NEVER rank companies from solidite.score_risque or the ratios yourself when it is interdit"), routing the agent to the internal ranking output instead. It does not name sibling tools to prefer for single-company lookups or batch-only identity/risk endpoints, so the boundary with the ~30 other French tools 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?

Goes far beyond the annotations: daily polling cadence, exact event categories (BODACC, sanctions/AMF, PSAN/SGP, Seveso/ICPE, procurement awards, decision_tcom_rattachee), Ed25519-signed webhook plus e-mail digest, bearer-token polling, and a 7-day expiry reminder. It also discloses the non-obvious cost model (per target × per duration, no pro-rata refund) and the client-side x402 spend-cap trap that would otherwise silently block the call — exactly the kind of context annotations cannot carry.

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

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

One enormous paragraph with deeply nested parentheticals enumerating every event subtype, mixed with pricing and payment-client mechanics. The purpose is front-loaded, but the single block is hard to scan and several clauses (e.g. the mandats_partiels edge case) belong in docs rather than a tool description.

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

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

For a paid, stateful, open-world mutation tool this covers everything an agent needs: what it creates, how events arrive, how to poll, when it expires, what it costs, how payment is authorized, and the instruction to cite the returned `citation` verbatim. An output schema exists, so return-shape detail is correctly omitted.

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 each field, but the description adds a formula not present in schema: total = unit price × number of targets, with the resulting $50 ceiling at 100 targets and its consequence for spendControls. It also reinforces the target-count bounds and the company-vs-director targeting split.

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 ('create a 30, 90 or 365-day watchlist over French companies and/or directors') with an explicit scope restriction to France and to relationship-driven monitoring. An agent can immediately distinguish this recurring subscription tool from the one-off lookup siblings like check_french_regulator_alerts or 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?

Gives a clear selection criterion: use it 'when the relationship OUTLASTS the check', with concrete role examples (customer, borrower, supplier, portfolio company). It does not name the lifecycle siblings (get_surveillance_watch, renew_surveillance_watch, stop_surveillance_watch) that an agent would need to manage or cancel a watch, so the routing is implicit rather than exhaustive.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses that matching is deterministic, that checksums are actually validated (Luhn, ISO 17442), that the output includes the recommended next call and its price, and that text is never stored or logged. That privacy guarantee is exactly the kind of context an agent needs before pasting sensitive text.

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 'FREE.' and organized around purpose, usage, and behavior in three tight sentences. Slightly dense with parenthetical lists, but no sentence is wasted.

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 needn't be explained, and the annotations cover the safety profile. Combined with the privacy, determinism, and cost-signaling details, an agent has everything needed to call this correctly as a first step.

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

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

Schema coverage is 100% and the single parameter is documented, but the description adds useful meaning by naming the kinds of input to paste (email, invoice, contract, web page). The 10,000-char limit is left to the schema, so it adds value without fully duplicating.

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 (detect) and resource (French/EU company identifiers), then enumerates the identifier types (SIREN, SIRET, EU VAT, LEI) with their validation methods. It is clearly distinguishable from siblings like validate_eu_vat_number or verify_french_invoice, which each target a single identifier rather than scanning free text for all of them.

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

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

Explicitly says 'Use this FIRST whenever a company appears in your workflow' and lists concrete scenarios (onboarding, prospect list, supplier invoice, due diligence). It implies the downstream path ('each with the recommended Sirenic call') but does not name specific sibling tools as alternatives, 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 already mark it read-only and open-world, but the description adds substantial operational detail: returns base64 PDF (1-10 MB), charges $0.10 via x402 or API key, requires api_key for actes (else 401 compte_requis, nothing charged), and returns 404 diffusion_partielle without charge for partially published sole traders. This is rich 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 purpose is front-loaded in the first sentence, and subsequent sentences carry necessary payment, auth, and error details. The final sentence about diffusion_partielle is dense and could be split, but every sentence earns its place given the tool's legal and billing 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?

Covers prerequisites (IDs from list tool), payment methods, authentication differences by document type, return format and size, and specific error outcomes with charge implications. No output schema exists, but the description sufficiently explains what an agent needs to invoke and interpret the 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 coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema: it explains that type=bilans is annual accounts open to any payer, type=actes is legal deeds reserved to identified Sirenic accounts, and clarifies api_key necessity and payment precedence. This materially helps parameter selection.

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: 'Download an official company document (PDF) from the INPI RNE registry.' It also names the sibling tool that supplies IDs, so an agent can distinguish it from list_french_company_documents without inspecting schemas.

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

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

Explicitly says to use IDs from list_french_company_documents and explains eligibility by document type (bilans vs actes) with authentication requirements. It does not compare against other document-fetching siblings like get_french_company_pdf_report, so it falls short of full when/when-not guidance.

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

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

Beyond the readOnly and openWorld annotations, the description discloses payment via x402 at $0.05 in USDC or EURC, the official DECP data source, and detailed output semantics such as framework-agreement amounts being maximum ceilings and envelope versus firm-price amounts. It also instructs the agent to cite the `citation` field verbatim.

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 most important information is front-loaded: what the tool finds and why it matters. The description is dense and long, but most clauses earn their place by clarifying output fields, payment, or citation requirements.

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, read-only search tool with a full output schema, the description covers purpose, filtering, result semantics, payment, and citation expectations. Nothing essential is missing for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the input schema already documents all six parameters. The description reinforces CPV prefix and month-window usage but adds little parameter meaning beyond what the schema already provides.

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

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

The description states a specific verb and resource: it surfaces French public contracts expiring within a defined window. It clearly distinguishes itself from procurement-history siblings by emphasizing that it finds opportunities BEFORE any notice is published.

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 use case ('tender anticipation for France') and gives filtering guidance via CPV prefix and department. It does not explicitly name alternative tools such as get_french_company_public_procurement or get_eu_procurement_awards, so the when-not-to-use guidance is limited.

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 pricing ($0.02 in USDC or EURC, paid via x402), widening behavior under 50 results, how set-aside examples are represented by rank rather than SIREN, refusal error codes that are never charged, a 15-second timeout error, and the requirement to cite `citation` verbatim. These are substantial behavioral details not present in the structured annotations.

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

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

The purpose is front-loaded and the dense single paragraph contains little filler, with each clause adding operational detail about cost, widening, errors, pagination, and citation. However, the run-on structure with multiple semicolons and parentheticals makes it harder to scan than a more structured description would be.

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

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

Given the tool's complexity—paid lookalike search, profile widening, pagination, and output fields—the description covers what an agent needs to invoke it correctly, including payment, error handling, pagination routing, and citation requirements. Since an output schema exists, the description need not explain return values in full, and its brief references to profil fields are sufficient.

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

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

Schema description coverage is 100%, and the description largely restates what the schema already documents: 2 to 5 customer SIRENs, an optional region or departement, and the exclusivity of those geographic filters. It does not add new syntax, format, or edge-case meaning for the parameters beyond the schema, 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 and resource: find French companies that resemble given customer SIRENs, with the customer set excluded from results. It clearly distinguishes this from plain company search by the lookalike profiling logic and explicitly names query_french_companies only for pagination. An agent can identify the tool's unique purpose without opening sibling schemas.

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 usage condition: provide 2 to 5 customer SIRENs, optionally a region or departement, and it explains that next pages are read through query_french_companies (mode lister, page 2 onward). It does not explicitly state when to prefer search_french_companies, prospect_french_companies, or compare_french_companies over this tool, so alternatives are only partially covered.

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

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

Annotations only say read-only and open-world; the description adds material beyond that — deposits are immutable, the exact refusal semantics (404 for sole proprietorships, uncertain legal forms, unknown enterprise numbers, objection-listed names), the 503 collecte_en_cours case, and the payment model ($0.15 via x402 in USDC/EURC). This is precisely the failure-mode and cost information an agent cannot get from 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 core purpose is front-loaded in the first sentence, but the remaining text is one dense run of parentheticals and semicolon chained clauses; phrases like 'the profile's 404' are cryptic and cost the reader without adding clear signal. Information is valuable but the packaging is over-compressed.

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, two-required-parameter tool with no output schema, the description covers return format (base64 PDF), prerequisites, immutability, error codes, and billing — enough to call it correctly. It does not describe how the base64 payload is wrapped in the response envelope or size limits, which is the remaining gap.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning: it explains the provenance of `reference` (must come from the filings list) and introduces the payment/pricing context behind `api_key` and `x_payment`. It does not restate the 10-digit or reference patterns, which the schema already handles.

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: retrieves one Belgian annual-account deposit as filed (NBB CBSO Authentic Data), returned as the official PDF base64-encoded. It also explicitly separates itself from the sibling list_belgian_company_filings (which supplies the reference) and from the REST JSON-XBRL variant, so an agent can pick it out of a crowded country-filing family.

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?

'Reference comes from list_belgian_company_filings' establishes the prerequisite call ordering, and the ?format=json note tells the agent when to prefer the REST route for structured data. What is missing is an explicit statement of when not to use this tool (e.g., versus get_belgian_insider_transactions or other Belgian siblings), so it stops short of a 5.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses that output is aggregated at issuer level, that no individual is ever named, that breakdowns are suppressed for small groups, that incomplete FSMA days are flagged in collecte_incomplete making counts lower bounds, and that the call is paid via x402 at $0.02. It also mandates verbatim citation of the `citation` field. That is exactly the extra context annotations cannot carry.

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 question and scope in the first sentence, then layers on privacy caveats, completeness caveats, use case, pricing and citation duty. Dense and mostly earning its space, though the payment and citation notes could be compressed into a single trailing line.

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 structure needn't be described, yet the description still explains the two response traits an agent must interpret correctly (unnamed/withheld breakdowns, collecte_incomplete lower bounds) and the citation obligation. Nothing needed to call and report it responsibly 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 baseline is 3. The description reinforces the default window ('rolling 12 months') and mentions the periode.depuis_demande bounding behaviour, but the per-parameter meaning of id, depuis, api_key and x_payment is already fully specified in the schema and is not extended here.

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?

Names a specific resource and scope: insider transactions (MAR Art. 19 manager notifications) at a Belgian listed company, with an issuer-level 12-month aggregate. The framing question ('are its managers buying or selling?') plus the Belgian qualifier makes it easily distinguishable from get_german_insider_transactions and from the Belgian filing 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?

Explicitly states the intended decision context ('use as a governance signal before investing in or contracting with a listed Belgian company'), which tells the agent when to reach for it. It does not name a sibling alternative or state when NOT to use it (e.g. single-notification lookup or non-listed entities), so it stops short of full 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 readOnly/openWorld annotations, the description discloses data sources and freshness (EBA PSD2 register refreshed daily, EIOPA, ARCEP), an important interpretation caveat (ARCEP listing is 'not proof of operator status'), what fields are returned (dates, PSD2 services, passporting, withdrawals), payment mechanics, and a citation requirement. This is rich context that materially affects how an agent should use and report the result.

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

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

Despite being dense, it is front-loaded with the resource and scope, then moves to use case, caveat, payment, and citation guidance. The long first sentence earns its length by enumerating the covered authorisation regimes and data sources that define 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?

An output schema exists, so return-value structure need not be explained. The description covers scope, sources, freshness, interpretation caveats, use case, payment, and citation behavior, leaving no material gap for an agent deciding whether and how to call it.

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

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

Schema description coverage is 100%, including detailed documentation of api_key and x_payment, so the schema carries the parameter burden. The description only reinforces that lookup is by SIREN and mentions the x402 payment path; it adds little parameter-level meaning beyond the schema.

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

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

The description states a specific verb and resource ('Regulatory authorisations of a French company by SIREN') and enumerates the covered authorisation regimes and registers, making the scope unusually clear. It does not explicitly distinguish itself from overlapping siblings such as search_eu_financial_authorisations or check_french_regulator_alerts, which keeps it short of a 5.

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 concrete when-to-use context: 'before paying, onboarding or contracting with a regulated counterparty', and clarifies that a negative result is meaningful ('Not authorised is an answer too'). It does not name when to prefer a sibling tool or when this tool is not appropriate.

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

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

Annotations only cover readOnly/openWorld; the description adds genuinely non-obvious behavior: paid via x402 ($0.02 USDC or EURC), sourced from official DECP open data, and an instruction to cite the `citation` field verbatim. It stops short of describing the quote/payment handshake or result-shape constraints, but the value beyond annotations is substantial.

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

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

Two tight sentences: what the tool returns is front-loaded, the data source and price follow, and the citation instruction closes it. 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?

An output schema exists, so return values needn't be explained, and the citation directive covers the one reporting obligation. Minor gap: the payment flow (when a quote is returned versus a result) is only implied by the parameter descriptions.

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 defines siren, api_key and x_payment in detail. The description adds the framing that SIREN anchors the CPV-segment comparison but no additional parameter semantics, which is the correct baseline-3 outcome.

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 precise verb-and-resource: identifies rival contractors winning on the SAME CPV segments as a given SIREN over the last 3 years, with counts, amounts and shared segments. This is clearly distinguishable from siblings like get_french_company_public_procurement (that company's own awards) and get_eu_procurement_awards (cross-EU 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 scope (same CPV segments, 3-year window) strongly implies when to use it, but there is no explicit 'use this instead of X' routing nor any when-not guidance against the many procurement siblings. Usage is inferable 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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses what is returned (metadata only, never the document), the 404-not-billed edge cases, 'aucun_depot: true' semantics as a measured fact, x402 pricing ($0.01 USDC/EURC), and the obligation to cite the `citation` verbatim. This is a lot of behavioral context an agent cannot get from annotations or schema.

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

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

Front-loaded with the resource and return fields, then the pricing and citation caveats. It is information-dense and earns most of its clauses, but the semicolon-chained phrasing and the pricing/citation bundle make it slightly unwieldy for a single paragraph.

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; the description still covers pricing, error behavior, and the citation requirement. For a 1-required-param lookup with a full output schema and read-only annotations, nothing an agent needs 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 oib, api_key, and x_payment are already documented with examples and precedence rules. The description adds no parameter-level detail (the 'aucun_depot' reference is a return field, not an input). Baseline 3 is appropriate when the schema does all the work.

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 (Croatian company annual-accounts filings at the Sudski registar, daily snapshot) and enumerates exactly what is returned (filing type, consolidation flag, period, filing date, newest first). It clearly differentiates from siblings like get_croatian_company_events and get_croatian_company_insolvency by naming the filing domain and contrasting 'metadata only, never the document' with the document-oriented 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?

Explicitly states when-not conditions: a sole trader (t.p.), an undecided legal form, or a name under objection returns 404 and is not billed. However, it never names a sibling alternative or tells the agent to prefer this over get_croatian_company_events when in doubt, so it falls short of full alternative 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?

With only readOnlyHint and openWorldHint in annotations, the description carries substantive extra context: the closed list governing whether published text is served (`texte_retenu`), the shape of court-decision output, the not-billed 404 behavior, and the payment mechanism and cost. These are behaviors an agent cannot infer from the schema or 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-loads the resource and source register, then layers the retention rule, failure modes, and payment tail. Dense but nearly every clause carries operational value; the parenthetical type enumeration is long but justified by the '108 types' claim.

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, return-value explanation is not needed, and the description still covers source, coverage, retention constraints, failure modes, pricing, and the citation obligation. Nothing needed 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 description coverage is 100%, so the schema already documents oib, api_key, and x_payment in detail. The description adds no parameter-level detail beyond implying the entity scope, so baseline 3 applies.

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

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

Names a specific resource and source register (Sudski registar statutory entries) and enumerates the entry types covered, which is far beyond restating the tool name. It stops short of explicitly distinguishing itself from Croatian siblings such as get_croatian_company_accounts or get_croatian_company_insolvency, even though the mention of dissolution grounds and court decisions overlaps with the insolvency tool.

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

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

Usage is only implied by the resource scope; there is no explicit 'use this when / use X instead' routing versus the many sibling event and Croatian registry tools. The 404 conditions (sole trader, undecided legal form, objected name) do give useful negative conditions, but they describe failure modes rather than when to select this tool over alternatives.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations: discloses data freshness (daily snapshot), the exact negative behavior (decision text is never included), the meaning of `aucune_procedure: true` as a measured fact over the complete snapshot, that deleted subjects are unpublished, which misses are free, the billing channel and price ($0.02 USDC/EURC via x402), and a citation obligation. That is precisely the kind of cost, coverage, and caveat context annotations cannot carry.

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-loads what the tool returns, then tightly packs caveats, pricing, and the citation instruction into a compact block with no filler sentences. It is dense to the point of being clause-heavy, which costs a point, but every clause carries distinct operational information.

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

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

For a paid single-identifier lookup with an output schema and readOnly annotations, the description covers the remaining gaps: what the payload contains and excludes, how completeness is signalled, when a 404 occurs and whether it is billed, and how payment works. Nothing an agent needs before calling is missing, and return-shape explanation is appropriately left to the output schema.

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

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

Schema coverage is 100%, so the schema already documents the OIB pattern, MBS acceptance, the api_key credit path, and x_payment precedence. The description adds little parameter-level meaning — `aucune_procedure` is a response field, not an input — 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?

Names a specific verb and resource (Croatian company insolvency status) and pins it to a named source (Sudski registar, daily snapshot of the open API). The scope is sharpened with what is returned ('running procedure … and every published court decision with its extracted facts') and what is explicitly not ('never the decision text'), which lets an agent separate it from get_croatian_company_accounts and get_croatian_company_events without opening the schema.

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

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

Gives concrete call preconditions and failure routing: unknown OIB/MBS returns 404, a sole trader (t.p.) or undecided legal form returns 404 and is not billed, as is a name covered by an objection — useful for deciding whether a query is even valid. It does not, however, explicitly route the agent to a sibling (e.g. accounts or events) when insolvency is not what is needed, so the alternative-selection guidance is implicit 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?

Goes well beyond readOnlyHint/openWorldHint: discloses the paid x402 path ($0.01) and prepaid-credit alternative, the 45-day staleness contract (`sans_publication_neuve`, `perime` in provenance), the exact 503 fail-closed condition, and that `aucun_mandat_publie` is measured against the complete snapshot. It also names concrete data gaps (no birth date, address, nationality, appointment date; natural vs corporate persons indistinguishable), which directly shapes how an agent should interpret results.

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

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

Front-loaded with what is returned, then constraints, then failure/freshness semantics, then payment and citation — a sensible progression. The sentences are extremely dense with parenthetical stacks (Greek role labels, `role.famille`, provenance keys), so it reads as a spec dump rather than clean prose, but little is genuinely expendable.

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 shape need not be described, and the description instead covers everything an agent cannot infer: source provenance and licence, coverage limits, staleness and 503 behaviour, cost, and the citation obligation. Nothing material 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 description coverage is 100% and the `id` pattern already encodes the HE/AE prefix rule with an example, so the description mostly restates it. The added value is the rationale — non-legal-person identifiers are rejected before payment — plus the note that `api_key` is ignored when `x_payment` is supplied, but the schema itself carries that too. 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?

States a specific verb and resource ('Cypriot company officers from the Registrar of Companies open data'), enumerates the mandate types returned (directors, alternates, secretaries, authorised persons) and the sort order. The jurisdiction plus source identifier (DRCOR, data.gov.cy) cleanly separates it from the many sibling *get_*_company_officers tools without opening any schema.

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

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

Explicitly states the eligibility gate: legal persons only (HE/AE), with business names, partnerships and BN 'refused before payment' — strong when-to-use guidance. It also tells the agent when a zero result is non-conclusive. It does not name a fallback tool for refused entity types, so it stops short of full alternative 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?

Goes far beyond readOnlyHint/openWorldHint: discloses the 100-event cap with the exact fields that signal truncation (nombre_evenements, evenements_tronques), the compulsory-publication rule that makes a clean result meaningful, the collecte_le freshness marker with a 503 on stale stock, the 404 for natural persons under GDPR minimisation, and the $0.02 x402 cost. Error behaviors and response semantics are all disclosed.

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

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

Front-loaded with purpose and source, then progressively adds scope limits, truncation semantics, and legal exclusions. Dense but nearly every clause carries information an agent needs. The first sentence is a long run-on that packs many field names together, costing a little 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 and annotations already present, the description still covers everything an agent must know to call and interpret this tool: coverage period, truncation signaling, the positive-answer field for no proceedings, freshness marker, jurisdiction restriction, and the citation obligation. Nothing material 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 genuine meaning: an IČO belonging to a natural person is rejected rather than returned clean, which changes how an agent should interpret a 404 for the `ico` parameter. It says nothing extra about api_key/x_payment beyond the schema text, keeping it at 4.

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+source: insolvency record of a Czech company from the official ISIR register (Ministry of Justice), since 2008. This clearly distinguishes it from the many sibling insolvency tools (Croatian, Latvian, Polish, UK, etc.) by jurisdiction and register, and from get_czech_company_officers/shareholders by data domain.

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 names the exclusion condition (legal persons only; natural-person IČOs are refused with 404 rather than reported clean), which is a real when-not-to-use rule. Payment mechanics (x402 vs api_key) are also spelled out. It stops short of naming alternative tools for excluded cases or for related Czech queries, so not a 5.

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

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

With readOnlyHint and openWorldHint already declaring safety and openness, the description adds substantial behavioral detail: GDPR rule R1 anonymization of natural persons, legal-person naming with IČO, objection handling via null and ecartes.opposition, 404/503 error conditions, and billing only when served. This is far beyond what annotations alone convey.

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

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

The description is front-loaded with the primary purpose and data source, then layers in GDPR, error, and billing conditions. It is dense but mostly earns its length; minor improvement would come from breaking the single paragraph into structured clauses.

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 annotations cover safety, the description still supplies the critical non-schema context an agent needs: GDPR anonymization rules, null handling for objections, 404/503 conditions, payment method, and citation requirements. Nothing essential appears missing for correct invocation and reporting.

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 ico, api_key, and x_payment with patterns and examples. The description reinforces that ico must refer to a legal person but adds little parameter-level syntax or format guidance 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?

The description names a specific verb and resource (officers of a Czech company) and enumerates the covered bodies and roles. It clearly distinguishes itself from siblings such as get_czech_company_shareholders and get_czech_company_insolvency by focusing on statutory officers and the ISVR source.

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

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

It provides clear usage context: sole traders and undecided forms return 404, stale data returns 503, and billing behavior is explained. However, it does not explicitly route the agent to or away from sibling tools like get_czech_company_shareholders or get_uk_company_officers, so it falls short of full when/when-not/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?

Goes far beyond the readOnly/openWorld annotations: discloses the GDPR R1 rule that natural persons are counted but never named, that legal persons are named with IČO, how art. 21 objections surface as null plus ecartes.opposition, that such answers are still billed, that blocked/unknown names return the same unbilled 404, and the exact price ($0.02 x402). This is the kind of context an agent cannot get from 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?

Front-loaded with the resource and source, and every clause carries distinct information (coverage, GDPR, billing, citation). The long semicolon-chained sentences pack several rules together, which makes it dense to parse 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?

An output schema exists, so return shape need not be described, and the description covers the tricky edge cases (form-dependent coverage, objections, refusals, billing). Remaining gaps are minor: no note on result size limits or any per-call rate constraints.

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 earns extra by explaining the payment model around api_key/x_payment (x402 pricing, billing on served answers) which the schema only hints at. It does not add detail on the IČO format itself, which is left to 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?

States a precise verb+resource ('Members and shareholders of a Czech company') plus the authoritative source (ISVR, Ministry of Justice daily snapshot). It is clearly separable from the sibling get_czech_company_officers by returning ownership rather than officers, and even enumerates which legal forms yield which granularity.

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?

Tells the agent when coverage applies per legal form (s.r.o./v.o.s./k.s. full member list vs a.s./SE sole shareholder only) and when the call fails (undecided forms, sole traders, unknown IČO, objection-blocked names). It stops short of naming alternative sibling tools to use for those refusals, so the routing is inferred 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?

Goes well beyond the readOnly/openWorld annotations: 404 cases that are specifically NOT billed, null-vs-zero semantics for revenue, GDPR art. 21 nulling plus the ecartes.opposition counter and 'block partial' provenance flag, x402 pricing ($0.05 USDC/EURC), API-key vs payment precedence, and the requirement to cite the `citation` verbatim. This is exactly the behavioral context annotations cannot 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?

Purpose and return contents are front-loaded, and nearly every clause carries operational value (error cases, GDPR, billing, citation). It is a dense run-on sentence that could be broken into a field list and a rules block for readability, which keeps it from a 5.

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

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

An output schema exists, yet the description still clarifies the pitfalls (null vs zero, prior-year comparatives, currency, source document URL) and covers billing, failure modes and compliance obligations. Nothing an agent needs to call and interpret this correctly is missing.

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

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

Schema description coverage is 100%, so the schema already defines id (8-digit CVR), date_cloture format, api_key and x_payment. The description adds only the provenance rule for date_cloture (source it from list_danish_company_filings); the revenue null semantics apply to outputs, not inputs. 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?

States a specific verb and resource ('financial statements decoded from the company's XBRL annual report') and enumerates the exact fields returned (revenue, gross/operating/pre-tax/net result, equity, assets, debts, employees). It explicitly separates itself from list_danish_company_filings by noting the closing date comes from there, so the agent can distinguish it from siblings without opening schemas.

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 explicit routing: the closing date must come from list_danish_company_filings, so the agent knows the prerequisite step. It also spells out when the call fails (sole proprietorship, estate, undecided CVR form, unknown number, GDPR objection). No direct comparison to alternative financial-statement tools for other countries, but the country scoping makes that largely unnecessary.

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 readOnly and openWorld; the description adds substantial context beyond them: truncation caps (300 active / 200 ended) flagged by `tronque`, 404-not-billed semantics, x402 pricing, GDPR minimization of fields, and the citation requirement. This is rich behavioral disclosure that materially helps 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?

Front-loaded with what the tool returns, then defaults, limits, exclusions, and payment. Dense but largely purposeful; a couple of trailing items (payment, citation) could be compressed, but no sentence is pure filler.

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

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

With an output schema present and 100% param coverage, the description fills the remaining gaps: truncated-result signaling, 404 edge cases, GDPR field omissions, and payment model. Nothing an agent needs to call this 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, but the description adds real meaning beyond the schema: it explains that inclure_anciens is specifically where founders usually appear, which is not in the schema field description. Payment-parameter interplay and cvr format are left to the schema, so it falls just short of 5.

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 ('Danish company officers and directors, live from CVR') and enumerates exactly what is returned (Direktion, Bestyrelse, partners, auditors). An agent can distinguish this from get_danish_company_filing or get_uk_company_officers without opening any schema.

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

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

Clear operational context: active mandates by default, inclure_anciens to include ended mandates where founders typically sit, and explicit 404 behavior for ENK/PMV/DØD forms. It does not name the sibling alternative for beneficial owners, but it does state they are 'NOT exposed by this access', which effectively routes the agent away.

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, and the description adds substantial context beyond them: monthly refresh cadence, licence/attribution (RIK, CC BY 4.0), null-means-not-published semantics, statutory vs consolidated figures kept apart, 404 not billed, pricing and payment mechanics, and the caveat that score_defaillance is non_evaluable rather than a low score.

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 lead clause front-loads country, resource and source before the field list, and every later sentence carries operational information. It is dense with parentheticals and could be split into short bullets without losing content, but there is no filler.

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

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

For a paid, single-identifier data retrieval with an output schema present, the description covers what is returned, what is not (PDF-only filings, FIE 404), how nulls should be read, and how to treat the non-evaluable default-risk field. An agent has everything needed 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% and all three parameters (registrikood with an 8-digit pattern, api_key, x_payment) are documented in the schema itself, so the baseline of 3 applies. The description adds nothing about the registry-code format or the payment parameters beyond the pricing sentence, which is about billing rather than 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+resource+scope: annual-account key figures from the Estonian e-Business Register, and enumerates the exact line items returned (balance sheet, revenue, employee expense, net profit, FTE). The country qualifier plus the accounts content cleanly separates it from the Estonian officers/shareholders/registry_rulings siblings and from other countries' *_company_accounts 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?

Gives clear conditions of applicability: every published financial year since 2019 in one call, PDF-only filings are not served, FIE/unrecognised legal forms return 404 and are not billed, and the call is paid via x402 ($0.02). It does not say when to prefer a sibling instead (e.g. registry rulings or officers) nor how this differs from default-risk tools, so no explicit alternative 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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses extensive behavioral details: data freshness, GDPR field restrictions, 404 refusal cases with payment cancellation, payment mechanics via x402, and citation requirements. This is unusually thorough and gives the agent full operational context.

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

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

The description is a dense paragraph that front-loads the scope but could be better structured for scanning. While most sentences carry useful information, the length and lack of segmentation reduce readability and conciseness.

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, annotations, and output schema, the description is complete. It covers the data source, refresh cadence, covered roles, refusal cases, GDPR constraints, payment model, and citation requirement—everything an agent needs 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 meaningful constraints tied to the input: legal-person-only restriction for the registrikood, refusal for uncovered identities, and payment-via-x402 semantics for x_payment. It does not add new syntax or format details but meaningfully supplements 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 specifies the verb and resource clearly: retrieving officers and governance of an Estonian company from the official e-Business Register. It enumerates the exact roles covered (management board, procurators, liquidators, etc.) and distinguishes the tool from siblings like get_estonian_company_shareholders and get_estonian_company_accounts by its 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?

It gives clear when-to-use context (legal persons only) and explicit when-not conditions (sole proprietorships refused with 404, uncovered identity copies refused). However, it does not explicitly name sibling tools as alternatives or state which tool to use instead for shareholders/accounts, leaving a small gap.

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, it discloses the daily national photo cadence, 404 semantics for struck-off/uncovered entities, the closed alerte type list with fail-closed counting logic for etat_code, non-billing for uncovered events, and payment via x402. This is unusually complete behavioral disclosure for a read-only 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 front-loaded with what the tool returns and wastes little space, but it is a single dense paragraph with stacked parentheticals and acronyms (FIE, RIK, etat_code) that strains readability. Every clause carries information, yet the block structure could be split for clarity.

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

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

With an output schema present and annotations covering safety, the description still supplies everything an agent needs to interpret edge cases: 404 vs positive-empty answers, photo_le dating, alerte versus nombre_alertes semantics, and the citation instruction. Nothing material appears 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 registrikood, api_key and x_payment all documented in the schema including the 8-digit pattern and example. The description adds only the billing context (x402 $0.02), not parameter-level semantics, so baseline 3 is appropriate.

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

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

The description names a specific resource (registry rulings/määrused), the exact source (Estonian e-Business Register open data, RIK, daily photo) and enumerates the ruling types returned. This distinguishes it cleanly from siblings like get_estonian_company_accounts, officers or shareholders.

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 rich context on when results apply (struck-off entities, FIEs and uncovered legal persons yield 404) and warns that zero alerts must be read alongside types_non_qualifies. However, it never explicitly names an alternative tool or a when-not-to-use condition relative to siblings, so routing relies on 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 only declare readOnlyHint and openWorldHint, and the description adds substantial context beyond them: 404 behaviours with named error codes, GDPR-driven counting (never naming) of natural persons, the aucun_associe_inscrit register fact and how its meaning varies by legal form, nominal values never converted from EEK, and the requirement to cite the returned `citation` verbatim. Payment mechanics ($0.02 via x402, or prepaid credits) are also disclosed.

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

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

It is a single dense block of semicolon-chained clauses that mixes data fields, refusal codes, payment terms and citation rules without front-loading or segmentation. Raw internal identifiers such as `detenu_par_personnes_physiques_pct`, `mandats_non_couverts` and `aucun_associe_inscrit` appear unexplained and in mixed languages. Much of the enumerated field list overlaps with the existing output 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 an output schema exists, return format need not be restated, and everything else an agent needs is present: eligibility rules, failure modes with codes, GDPR handling, pricing, and citation requirements. Nothing material about calling this tool correctly is missing.

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

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

Schema description coverage is 100%, so registrikood's 8-digit format and the api_key/x_payment semantics are already documented in the schema. The description adds no new parameter-level meaning (it does not explain how the payment parameters interact, e.g. that the signed payment wins). Baseline 3 applies when 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 opening sentence states a specific verb+resource: members and shareholders of an Estonian company, from the official e-Business Register share register (RIK). It lists the payload (holding percentage, nominal value, ownership type, pledges) so an agent knows what comes back. It never names a sibling such as get_estonian_company_officers or get_latvian_company_shareholders as the alternative, so sibling differentiation is left implicit.

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

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

It gives real eligibility guidance: legal persons only, sole proprietorships are refused with a 404 and cancelled payment, and legal persons known only from the monthly identity copy are not covered (404 mandats_non_couverts). That tells an agent when this tool will and will not work. It stops short of routing to a different tool when the entity is a sole proprietorship or uncovered person.

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

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

With annotations only covering readOnly/openWorld, the description adds substantial behavioral context: the ~57% identifier-coverage rate, the eForms start date, that co-winners are counted but anonymized by reason, the x402 pricing ($0.02 USDC/EURC), and a citation obligation on output. These are facts an agent cannot obtain from the structured fields.

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

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

Front-loaded with the resource and source, then caveats, then pricing and citation. Dense but nearly every clause carries information; the long nested parentheticals cost some readability without being padded.

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

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

For a paid, coverage-limited lookup with an output schema and annotations present, the description supplies the missing pieces: data provenance, coverage window, identifier-match caveat, pricing, and reporting requirement. An agent has everything needed to call it correctly and interpret an empty 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 documented in the schema; the description only reinforces identifier matching (SIREN/SIRET with spaced variants). Baseline 3 applies since the schema does the heavy lifting and the description adds no new per-parameter detail.

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

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

States a specific verb and resource ('EU procurement awards' from TED for a French company) and enumerates the returned fields (buyer, country, subject, amount, CPV, links, co-winners). It explicitly distinguishes itself from get_french_company_public_procurement (DECP, below-threshold), though it does not differentiate from the similar-sounding sibling get_european_company_eu_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?

Clearly frames when this source applies (identifier-matched SIREN/SIRET, eForms since 2023-10-25, above EU thresholds) and names the complementary DECP tool for below-threshold French coverage. It also warns that an empty list is not proof of absence, which is a genuine usage caveat rather than a restatement.

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 readOnly and openWorld; the description adds pricing ($0.02 via x402, or credits via api_key), 24 h caching, and — crucially — that a 404 for non-legal-person forms is not billed. It also discloses measured identifier-coverage rates (40–94%) so the agent can calibrate confidence in an empty result.

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 purpose and alternatives, and nearly every clause carries operational weight (404-billing, coverage rates, citation instruction). The wall of semi-colon-joined clauses and heavy parenthetical nesting makes it harder to scan than it needs to be.

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

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

An output schema exists so return values needn't be restated; everything an agent needs — payment paths, cache TTL, 404 semantics, coverage caveats, and the verbatim `citation` requirement — is present. Complete for a paid, open-world lookup.

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 genuine semantic value: the `id` is matched by national identifier in every form it takes on TED, and the legal-form restrictions per country explain which IDs will 404. Country list is mirrored from the `pays` enum in prose.

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 (European public-procurement contract awards from TED), the matching key (national identifier, `variantes_identifiant`), and the exact country scope. It explicitly points to the French and UK counterparts, so an agent can place it precisely 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?

Explicitly enumerates the ten covered countries and routes France to get_french_company_eu_procurement and the UK to get_uk_company_public_procurement, so the when-to-use decision is closed. It also states that `nombre_avis: 0` is a non-conclusive absence, which prevents a false negative reading.

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

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

Beyond the readOnly/openWorld annotations, it discloses pricing ($0.01 via x402), that 404 responses are not billed, that certain LEI mismatches return pays_ne_correspond_pas, and that score_defaillance must not be read as a low score. It also explains data freshness differences between local and live registers and the citation requirement, all of which materially affect correct use.

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

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

The first sentence is front-loaded and useful, but the remainder is an enormous semicolon-chained paragraph dense with country-specific edge cases and parentheticals. Much of the detail is relevant, yet the structure makes it hard to scan and is not appropriately concise for an agent-facing definition.

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

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

Given the multi-country complexity, payment model, and output schema, the description is complete: it covers coverage, billing, 404 behavior, field semantics such as groupe_lei and financements_ue, and citation requirements. An agent has enough context to call and interpret 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 substantial meaning for pays and id by listing supported countries, legal-person-only restrictions, entity forms that yield 404, and LEI jurisdiction mismatch behavior; it adds less for the payment parameters beyond noting x402 and api_key fallback.

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 opening sentence states a specific verb and resource: a unified European company profile looked up by country and national register ID, with a consistent JSON schema. Country coverage and returned fields are enumerated, so the tool is distinguishable from country-specific siblings in scope, though no sibling is explicitly named as an alternative.

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

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

The description extensively explains which countries and entity types are served and which return 404, which implicitly guides usage. However, it never explicitly states when to use this tool versus alternatives such as get_french_company_profile or search_european_companies, leaving routing 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?

Goes well beyond the readOnlyHint/openWorldHint annotations: discloses the 24 h cache freshness, the exact 404 triggers (unknown Business ID, foreign branch, out-of-codebook form, GDPR art. 21 name objection) with 'no charge', the x402 billing amount and currency, and the mandatory verbatim citation requirement. It also states an important content boundary — 'Codes and dates only, never a person' — that no annotation conveys.

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 correctly with the resource, and every clause carries real information, but the payload is delivered as one very long semicolon-chained sentence, making it hard to scan. Splitting return shape, error conditions and payment terms into distinct sentences would improve structure without losing 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?

Despite output schema being present (so return values needn't be spelled out), the description covers the gaps that matter for this paid, cached, open-world tool: freshness, failure modes, cost and payment mechanics, and citation obligation. Nothing an agent needs to call it correctly or interpret a 404 is missing.

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

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

Schema description coverage is 100% and all three parameters (id, api_key, x_payment) are already documented in-schema, including the payment precedence rule. The description adds little parameter-level detail beyond reinforcing the Business ID domain and the 404 conditions, so baseline 3 is appropriate.

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

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

States a specific verb and resource ('Finnish company trade-register notices from the PRH open data') and enumerates the exact payload: dates, record numbers, notice types, register entry codes with EN/FI/SV labels, and register memberships. This is far more specific than the sibling 'get_finnish_company_filing' or 'list_finnish_company_filings', but it never names those siblings or explicitly delimits the difference, so differentiation is inferred from the content list rather than stated.

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

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

Usage is implied by the scope ('every notice registered since late 2014, newest first') and the 404 conditions clarify what inputs are outside coverage. However, there is no explicit when-to-use or when-not guidance and no named alternative, so the agent must infer whether this or get_finnish_company_filing / list_finnish_company_filings is the right call.

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

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

Beyond the read-only annotation, the description discloses important behavioral details: revenue null means not published and never zero, prior-year comparatives are as published, amounts are in EUR, the call is paid via x402 at $0.15, and results must cite the `citation` verbatim. These details materially help an agent interpret and report the data correctly.

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

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

The description is front-loaded with what the tool returns, then covers data semantics, the listing dependency, payment, and citation requirements. Each sentence adds useful 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 output schema and annotations, the description is complete for correct selection and invocation: it explains the returned fields, null semantics, currency, dependency on the listing tool, payment mechanism, and citation obligation. Nothing essential is missing.

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

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

Schema description coverage is 100%, so the schema already documents the Business ID format, closing date format, and payment parameters. The description adds that date_cloture is sourced from list_finnish_company_filings, but it does not add meaning beyond the schema for the other parameters, 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?

The description states a specific verb and resource: retrieve one Finnish fiscal year's financial statements decoded from the company's PRH XBRL filing. It enumerates the reported fields (revenue, operating/net result, equity, assets, debts, prior-year comparatives) and distinguishes this tool from list_finnish_company_filings by noting where the closing date comes from.

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 that the closing date must come from list_finnish_company_filings, routing the agent to the right sibling for discovery. It does not explicitly state when not to use the tool, but the usage context is otherwise 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?

Far beyond the readOnly/openWorld annotations: it discloses the couverture window and how to interpret absence, the weekly Tuesday refresh cadence, the 503-on-stale-stock behaviour with no charge, the x402 price and currencies, and the obligation to cite `citation` verbatim. That is exactly the operational context an agent needs before calling a paid, freshness-sensitive endpoint.

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 and each subsequent sentence carries distinct operational information (coverage window, cadence, 503, price, citation). The opening sentence is an overlong run-on listing every returned field, which costs it a point on structure.

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

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

Complete for a paid, freshness-sensitive lookup: it covers what comes back, how to read gaps, refresh timing, failure semantics and billing, and adds a citation requirement the output schema cannot express. Nothing an agent needs in order to call 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 RNA format, api_key precedence rules and x_payment semantics are already fully documented in the schema. The description only restates 'by RNA number' and adds pricing, which is more behavioural than parametric, so baseline 3 applies.

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

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

Names a specific verb and resource (JOAFE/DILA notices for a French association by RNA), enumerates the notice types returned (creations, modifications, dissolutions, corrections) and the fields surfaced. The 'association equivalent of BODACC' framing plus the RNA lookup key separates it cleanly from get_french_association_profile and search_french_associations.

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

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

Usage is clearly implied: you already have an RNA number and want the publication history, not a search or a profile. The 'no notice inside that window is a fact, not a gap' note tells the agent how to interpret results, but no explicit when-not or alternative-naming is given, which keeps it below 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 declare readOnly/openWorld; the description goes far beyond them with pricing ($0.005 via x402 in USDC or EURC), error semantics (unknown identifier = 404, not charged), data freshness (monthly export), and a mandatory reporting obligation to cite `citation` verbatim. These are behaviors an agent cannot infer from structured fields and that materially affect call planning and output 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?

Front-loaded with purpose and identifier, then scope, exclusions, pricing/error, and the citation rule in descending priority. The long enumeration of returned fields is dense but functions as a coverage contract; only the field list could be trimmed if an output schema fully enumerates them.

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, read-only single-identifier lookup with an output schema, everything an agent needs is present: scope boundaries, source and refresh cadence, exclusion caveat that explains SIREN absence, payment mechanism, 404 billing behavior, and the citation requirement for downstream reporting.

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

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

Schema coverage is 100% and the rna parameter already documents the W+9 format and legacy 3-14 character identifiers; api_key and x_payment are fully described in-schema including precedence. The description adds only the general framing 'by RNA number' and the SIREN-confirmation caveat, so it neither compensates for nor extends the schema materially — 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 and resource: an official profile of a French association (loi 1901) keyed by RNA number, with the source register named (Répertoire national des associations, Ministry of the Interior, monthly export). The field list makes its output scope unmistakable and separates it from get_french_company_profile (companies) and search_french_associations (name lookup).

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

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

Explicit routing: 'use search_french_associations first when you only have a name', plus a clear positive scope statement ('Covers associations WITHOUT a SIREN'). Negative scope is also stated — no officer/declarant data, Alsace-Moselle excluded — so an agent knows when to stop looking rather than assume missing data.

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

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

Annotations only declare readOnly and openWorld, so the description carries and delivers the rest: pricing ($0.05 USDC/EURC via x402), the prepaid-credits alternative, error behavior on sole proprietorships (400, never charged), that content is code-generated with no model text, and that each block carries status/age/coverage. It explicitly instructs verbatim copying, which is a real behavioral constraint.

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 resource, format, and block contents before payment details. Dense but nearly every sentence adds operational value; the siren output-instruction sentence and the payment sentence could be tightened but are not waste.

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 fully specifies the return shape (Markdown, per-block status/age/coverage, opening instruction, closing source line) and covers eligibility limits and payment paths. An agent has enough to call it correctly and to know what to expect back.

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 explaining the payment model (x402 cost and currency) and that the output is verbatim Markdown, which contextualizes the api_key/x_payment parameters and the default language 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?

States a specific verb and resource ('briefing on a French company (SIREN)'), and enumerates the exact content blocks (identity without officers, three years of filed accounts, BODACC insolvency, court decisions, public contracts). This scope lets an agent distinguish it from single-facet siblings like get_french_company_financials or get_french_company_court_decisions without opening their schemas.

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

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

Usage is implied by 'returned as Markdown text to read or paste as is' and 'legal entities only (a sole proprietorship answers 400)'. There is no explicit when-to-use versus alternatives guidance, and no sibling (e.g. get_french_company_file or get_french_company_intelligence) is named for contrast.

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

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

Beyond the readOnly/openWorld annotations, it discloses provenance (AI extraction from latest public articles filed at INPI), GDPR-driven handling of natural persons (counted but never named), confidence and source-document output, a specific non-charged 404 case, and payment via x402 at $0.35. These are substantive behavioral traits an agent could not infer from annotations alone.

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

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

The description is front-loaded with the core purpose and avoids wasted sentences; each clause carries operational value, including the RBE exclusion, GDPR note, 404 case, payment, and citation instruction. It is a dense single paragraph, though, and could be easier to scan if structured into short segments.

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 the description need not explain return values, and it already covers the key completeness items: data provenance, GDPR constraints, confidence and source fields, the 404 edge case, payment mechanics, and citation requirements. Nothing essential for correct invocation 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 schema already documents siren, api_key, and x_payment thoroughly. The description adds meaningful input-specific behavior by noting that a partially published SIREN not proven to be a legal person returns 404 diffusion_partielle and is not charged, which helps interpret a failed call.

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

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

The description names the exact resource and contents: ownership/share capital structure of a French company, extracted from INPI-filed articles of association, including share capital, legal form, shareholders, notable clauses, confidence, and source. It explicitly distinguishes the tool from a beneficial-ownership register or beneficial-owner identification, so an agent can tell what it is and is not.

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 when-not guidance by stating this is NOT an RBE or beneficial-owner identification, and it explains the 404 diffusion_partielle case for partially published SIRENs. However, it does not name a specific sibling alternative for beneficial ownership or share-capital-adjacent needs, leaving some routing to inference in a very large sibling suite.

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

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

Annotations only say readOnly/openWorld; the description adds real behaviour: reverse-chronological ordering, empty list when nothing new, contents limited to closed fields (category, officers by role/form, cessation date) with withheld labels counted in `omissions`, and per-call cost ($0.01 USDC/EURC via x402). It also states the citation requirement, which an agent cannot infer from the schema.

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

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

Front-loaded with the core action and scope, then layers ordering, exclusions, content restrictions, pricing and citation guidance. Dense but each clause carries information; the long opening sentence could be split for faster parsing.

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 is present, the description supplies exactly the non-schema context an agent needs: polling semantics, empty-result behaviour, the restriction that person names and judgment text are withheld, and the x402 payment/citation obligations.

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 required parameters and both payment parameters are already documented. The description reinforces the semantic of `depuis` ('SINCE a given date') and the payment model, but adds no format or edge-case detail beyond the schema. 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 a specific verb and resource — new official BODACC gazette announcements for a French company since a date — and explicitly bounds it against neighbours: 'Detects new BODACC publications, not field-level edits of the profile', which separates it from get_french_company_updates_since and search_bodacc_announcements.

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?

Frames the use case concretely ('poll-mode watchlist surveillance for a portfolio') and excludes a tempting but wrong use case (field-level profile edits). It stops short of naming the sibling tool to use instead for that case, so alternatives are implied rather than routed.

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

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

Beyond readOnlyHint/openWorldHint, it discloses that the payload is metadata only (never the text or a person's name), that IDCC codes are cross-checked against Sirene, the exact cost and payment rails, the 400 behavior for sole proprietorships/restricted-diffusion/group entities with no charge, and the requirement to cite the returned `citation` verbatim.

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

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

One dense paragraph that front-loads what the tool returns before caveats and pricing; every clause carries information. The sentences are long and stacked with parentheticals, which slightly hurts scanning, but 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?

An output schema exists, so return values need no explanation, and the description still covers source, coverage limits, error cases, cost, and citation obligations. An agent has everything needed to decide to call it and interpret an empty or 400 response.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: the siren is resolved against Sirene establishments (capped at 25) rather than queried directly, and it explains the x402 payment path ($0.02 in USDC or EURC) that backs the api_key/x_payment parameters.

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

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

The description names a specific resource (company-level collective agreements for a French SIREN published on Légifrance's ACCO fund) and enumerates exactly what is returned: title, nature, DILA themes, dates, IDCC, signatory unions, and Légifrance link. No sibling tool covers this data, and the scope is unmistakable.

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

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

It explains how the lookup works (filing SIRET across at most 25 establishments), warns that an empty result does not mean 'no social dialogue' due to headcount thresholds and unpublished decisions, and lists the entity types that return 400. What's missing is an explicit 'use this when you need X' framing, though with no overlapping sibling that is minor.

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

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

Goes well beyond readOnlyHint/openWorldHint: ~51% coverage caveat, closed-list category nature, exclusion of text/names/amounts, specific 400 error behavior for sole proprietorships / restricted-diffusion / non-legal-personality INSEE 2xxx categories, 'never charged' on that error, x402 pricing ($0.01 USDC/EURC), and a verbatim citation requirement.

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-loads what the tool returns before caveats, pricing and citation rules. Dense but nearly every clause carries decision-relevant information; only the 'no text, no individual's name, no amount' phrasing is slightly redundant with the preceding enumeration.

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 needn't be described. Everything else an agent needs to call correctly is present: data scope, coverage limits, error semantics, billing model, and citation obligation.

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 already documents siren, api_key and x_payment. The description adds only SIREN scope ('linked to a French company') and the failure mode for certain entity categories, which is useful but largely redundant with the schema's own parameter docs.

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 precise verb+resource (commercial-court decisions linked to a French company), the identifier key (SIREN), and the source (Cour de cassation open data / Judilibre). It enumerates exact returned dimensions (counts, closed-list decision types, role, co-litigants, official link), so an agent knows instantly what this differs from, e.g. 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?

Explicitly warns that no result never means no litigation and routes insolvency data partly to get_french_company_legal_alerts, plus instructs reading the decision at the source since no text is returned. It lacks an explicit positive trigger statement ('use this when you need litigation history for a SIREN'), but the context is clear enough.

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 goes much further by disclosing verdict variants, non-evaluable causes, motifs, error statuses and charging behavior, and the citation requirement. This is far beyond what the annotations provide.

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

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

The description is dense and front-loads the primary use case, then layers outputs, caveats, payment, and errors. It is long but mostly earned by the tool's complexity; some clauses are run-on and could be tightened.

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 a 5-parameter tool with an output schema, annotations, and full schema coverage, the description still covers the critical context: verdict categories, failure modes, billing/error behavior, scope limits, and citation handling. Nothing essential for correct invocation 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 parameter meanings are already well documented. The description adds useful semantics by saying montant and delai_jours should be passed together to produce comparaison_demande and by linking payment behavior to x402/api_key context.

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 and verb: indicative credit limit and payment terms for a French legal entity. It explicitly distinguishes itself from sibling get_french_company_default_risk by explaining that the class/score/confidence/model version come from that tool while the amount comes from the formula table.

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 a concrete when-to-use condition and example: asking whether to grant credit to a new customer. It also explains when to pass montant and delai_jours for comparaison_demande, names the related default-risk tool, and notes scope exclusions such as group exposure and officers.

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

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

With only readOnlyHint and openWorldHint declared, the description carries real behavioral weight: cost and currency ($0.10 USDC/EURC), the failure mode and billing guarantee on ineligible entities, the precise nature of the BODACC hard override, the 12-point weighting rule scoped to PME only, and the warning that a silent axis understates rather than improves risk. It also pre-empts the most likely misinterpretation by insisting the backtest AUC and band rates are observed sample rates, never a probability of default for the entity being read.

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?

It is front-loaded correctly — the first sentence delivers score, horizon and inputs before any caveats — and most sentences carry non-obvious information. But it is very long and dense, with parenthetical enumerations (closed-list reasons, backtest date ranges, version identifiers like defaillance-v1.10) that could be compressed, and it re-explains output fields that the output schema already defines.

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 statistical scoring tool with an output schema present, everything an agent needs is covered: eligibility, cost, error semantics, what the score is and is not, how silence on an axis should be read, and the citation obligation on reporting. Return values are over-explained rather than under-explained, so nothing 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 siren, api_key and x_payment are already documented in detail, making 3 the baseline. The description adds value beyond the schema on the payment parameter by disclosing the price and accepted currencies and by reinforcing that a credits error is returned rather than an x402 quote on insufficient balance — information an agent needs to choose between api_key and x_payment.

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

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

The opening sentence gives a precise verb+resource+horizon: a 0-100 default-risk score for a French company at ~12 months, computed from filed financial ratios plus company age plus a BODACC override, and it names the returned artifacts (score, band, components, confidence). That specificity distinguishes it in practice from neighbours such as get_french_company_credit_limit, get_french_company_industrial_risk and get_french_company_health_summary. However, no sibling is named or contrasted, so it stops short of the explicit differentiation a 5 requires.

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

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

The description states the intended use (decision-support), the exclusions (not a solvency opinion, not a credit rating, not an assessment about a person) and the eligibility gate (only fully disclosed legal persons; sole proprietorships, restricted-diffusion units and legal-personality-free groups are refused with a 400 and not charged). It also explains payment routing — api_key ignored when x_payment is supplied. What is missing is explicit routing against alternatives (e.g. when to pick this over get_french_company_default_risk_batch or the credit-limit 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?

Goes well past the readOnlyHint/openWorldHint annotations: discloses per-SIREN billing ($0.07, 30% off unit), which failure modes are charged vs not (unknown SIREN billed as trouve=false; 404 uncharged; 503 BODACC-down batch cancelled; 400 refusal uncharged with sirens_refuses), the default $1.00 x402 spendControls cap that will reject a $7.00 quote, and the ordering/basket semantics of results. No contradiction with the read-only annotation — it scores, it does not mutate.

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 use case, which is good, but the body is a single sprawling block of semicolon-chained clauses mixing output-field semantics (motifs_principaux, qualite_exercice_reference), error codes, pricing, and x402 client-version configuration. Most content earns its place, but the compression into run-ons hurts scannability for an agent.

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?

Output schema exists, so return fields needn't be enumerated, yet the description still explains basket ordering, chainage.surveillance contents, and every error path (404, 400 with sirens_refuses, 503) plus payment mechanics. Nothing an agent needs to call this correctly or interpret the quote is missing.

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

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

Schema description coverage is 100% and all three parameters (sirens, api_key, x_payment) are already documented in the schema, including dedup and per-SIREN billing. The description reinforces billed-line and refusal behavior but adds little parameter-level detail beyond what the schema states; 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 a specific verb and resource (batch default-risk score for 2 to 100 French companies) and scopes it precisely against the single-company sibling by asserting 'each line carries the SAME score, class, confidence and model version as get_french_company_default_risk'. An agent can immediately tell this apart from the single-score and watch 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?

Opens with an explicit trigger ('Use when asked to rank customers or suppliers by default risk') plus a concrete example, and routes to alternatives: create_surveillance_watch for monitoring a subset (with quoted pricing for first N vs whole expose basket), and the single-score tool implicitly by comparison. When-to-use and when-to-use-something-else are both covered.

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 cover readOnly and openWorld, but the description adds substantial behavior the agent could not otherwise know: the call is paid via x402 at $0.02 in USDC or EURC, results are facts-only with no scoring, the absence flag is non-conclusive, and any reported result must cite `citation` verbatim. These are exactly the operational and interpretive constraints that matter before invoking.

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

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

The core payload is front-loaded in the first sentence, with caveats, pricing, and citation requirements following in a logical order. It runs long as a single dense block and the parenthetical enumeration of French role and status values adds bulk, but no sentence 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?

For a paid, open-world lookup with an output schema, the description covers what is returned, how matching works, how to interpret absence, the payment path, and the citation obligation. Nothing an agent needs in order to call it correctly or report its output 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 genuinely useful semantics beyond the schema: the required `siren` is used to resolve a CORDIS-published VAT number rather than matching directly, which explains why coverage is imperfect. That mapping detail is not visible in the input schema and materially changes how an agent should interpret a negative result.

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: EU research and innovation funding received by a French company, sourced from CORDIS, scoped to Horizon 2020 and Horizon Europe. It enumerates exactly what comes back (role, EU contribution, cost, dates, status, CORDIS link) and is clearly distinct from procurement-oriented siblings like get_european_company_eu_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 on when the result is meaningful and how to read it: matching is done via the VAT number CORDIS publishes (~90% coverage) and `aucun_financement: true` is explicitly a non-conclusive absence, not proof of never being funded. It does not, however, name an alternative sibling or state when another tool should be preferred, so it stops short of full 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?

With only readOnlyHint/openWorldHint in annotations, the description carries the burden and does so thoroughly: per-block pricing, a $0.35 cap, a closed list of absence reasons, 503-vs-404 semantics, retry guidance, refusal cases that are never charged, and partial-diffusion nulling rules. Payment mechanics (x402 in USDC/EURC) are disclosed beyond the raw schema.

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

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

The value proposition and the alternative-routing sentence are correctly front-loaded, but the rest is a dense run-on paragraph mashing together pricing, error codes, GDPR edge cases and citation instructions. Every fact arguably matters, yet the packaging makes it hard to scan, and some error-code detail duplicates what a caller would learn from the response 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 multi-block, metered, payment-gated tool with an output schema, the description supplies everything an agent needs before calling: what it costs, what can be missing and why, which failures are retryable, which are uncharged, and how to cite results. Nothing material is left implicit.

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 earns an increment by attaching cost semantics to `blocs` (identity base $0.005, per-block passthrough, $0.35 cap) and by clarifying that payment can go through x402 or prepaid credits. It stops short of describing the exact string format for `blocs`, which the schema already covers.

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 opening states a specific resource and an unusual delivery model: a full French company file assembled in one call from cherry-picked blocks. It explicitly distinguishes itself from `get_french_company_intelligence` (verdict) and implicitly from the single-block dedicated endpoints by explaining that each block costs what its own endpoint costs. An agent can decide between this and siblings without opening a schema.

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

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

The trigger condition is spelled out: 'for when you need several things about the same company and do not want to chain calls', plus an explicit redirect to `get_french_company_intelligence` for a verdict. It also gives when-not cases (sole proprietorship, restricted-diffusion unit, group without legal personality → 400) and when the call fails entirely (503/404, uncharged).

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

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

Annotations already mark it read-only and open-world, but the description adds substantial behavioral context: x402 payment cost, citation requirement, quality grading, excluded-but-retained rows under `exercices_ecartes`, consolidated-account handling, and the analytical lag between filings and ratio datasets. These are exactly the caveats an agent needs before invoking and reporting results.

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

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

The description is dense but front-loads the core purpose and then layers necessary caveats. It is long for a tool definition, but most sentences carry operational meaning; minor tightening could 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 complex financial dataset, output schema, and payment model, the description is complete enough for correct invocation and interpretation. It covers data sources, quality caveats, ranking/lag behavior, interpretability limits, payment, and citation expectations.

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 three parameters are already well documented in the schema. The description adds payment context via x402 but does not add parameter-level semantics beyond what the schema provides, making 3 the appropriate 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?

States a specific resource (French company annual accounts/financial statements) and enumerates contents: revenue, EBITDA, net income, ratios, liasse fiscale, up to 20 balance sheets. It is clearly distinguishable from sibling tools by its financial-statement focus and named sources (INPI/Banque de France).

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 strong guidance on interpreting results, such as reading `qualite` before trusting an amount and checking `interpretabilite` for holding/head-office entities. However, it does not explicitly say when to choose this tool over siblings like `get_french_company_health_summary`, `get_french_company_credit_limit`, 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 annotation it discloses caching duration (7 days), payment mechanics ($0.15 USDC/EURC via x402, credits path, never charged on 400), which entity types are refused with the exact status code, the model-plus-deterministic-guard behavior with divergences_modele, and the citation obligation. This is unusually rich operational context that annotations do not carry.

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?

It is a single dense paragraph, but front-loaded with the purpose and organized so each sentence adds a distinct fact (coverage, guard behavior, fallbacks, pricing, citation). Slightly heavy for one block; splitting pricing/refusal into their own sentences would aid scanning.

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

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

With an output schema present, return-field detail is unnecessary, and the description still covers the tricky semantic cases an agent must anticipate: non-conclusive verdicts, non-evaluable fields, refusals for non-legal-persons, and how to handle the citation. Nothing needed for correct invocation 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 all three parameters (siren, api_key, x_payment) are fully described in-schema, so the description adds no parameter-level meaning beyond stating the input is a SIREN-keyed lookup. Baseline 3 applies when the schema does the heavy lifting.

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

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

The description names a specific verb+resource (business-health and risk read-out of a French company) and enumerates the outputs (verdict, strengths, warning signs, activity trend, confidence level, reconciled grid). It explicitly contrasts itself with get_french_company_profile, so an agent can distinguish it from siblings without opening any schema.

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

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

It states when to use the alternative ('call get_french_company_profile instead if you only need identity') and when the tool is useless (entities with no annual accounts). It does not differentiate against other plausibly overlapping siblings such as get_french_company_default_risk or get_french_company_intelligence, which is the only gap.

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

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

Goes well past readOnlyHint/openWorldHint: discloses the matching path (SIREN-keyed employer page else strict name matching over known locations), that counts are lower bounds with stated exclusions (brands, temp agencies) and where the path is recorded (methode.comptage), that nothing is stored, that failed entity types are never charged, and the x402 price ($0.02 USDC/EURC). It also imposes a post-call obligation (cite `citation` verbatim), which is exactly the kind of behavior an agent cannot get from annotations.

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

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

Front-loaded with what the tool returns, and every clause carries substantive information — nothing is filler. The weakness is structural: the middle is one sprawling sentence with deeply nested parentheticals (lower-bound caveats, methode reference, Egapro, INSEE bracket) that is harder to parse than a short bulleted breakdown would be.

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

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

An output schema exists, so return values needn't be described, yet the description still explains the semantics an agent needs to interpret them correctly: null means absence is unprovable, counts are lower bounds when detail is partial, and which field records the counting method. Payment, error and citation obligations are all covered — nothing essential is missing.

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

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

Schema description coverage is 100%, so `siren`, `api_key` and `x_payment` are already fully documented including the prepaid-vs-x402 precedence rule. The description adds no parameter-level detail beyond the SIREN-keying concept, 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?

Names a specific resource (hiring signals for a French company) plus its exact provenance (France Travail, 24h snapshot, on-demand) and the output shape (yes/no/unprovable, postings count, ROME families, contract mix, Egapro index). That is enough to distinguish it from the many sibling `get_french_company_*` tools without opening any schema.

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

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

Explicitly states the intended use cases (sales intelligence: a hiring company is an active company; HR/expansion signals) and enumerates the entity classes that fail (sole proprietorship, restricted-diffusion, INSEE 2xxx/9200/9210 → 400, never charged). It stops short of naming alternatives — e.g. get_french_company_profile or get_french_company_briefing — so the agent must infer routing from context alone.

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