HelpMyAgent

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

The description transparently discloses that results are indicative, that 'potentially_eligible' only means no known incompatibility, and that the call consumes an x402 payment. It also clarifies that source records are not modified, which is important given the annotations do not flag the call as read-only or idempotent.

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

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

The description is well-structured with clear sections: purpose, usage guidance, limitations, pricing, and payment behavior. It is front-loaded with the core action and every section adds necessary operational information for a paid API endpoint.

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

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

For a tool with paid-call behavior, nuanced eligibility semantics, and a limited parameter set, the description covers all needed context: what it does, when to use it, when to avoid it, limitations, cost, and payment behavior. Output schema presence means return-value details do not need to be described.

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

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

The input schema already documents all three parameters with descriptions and 100% coverage, so the baseline is 3. The description adds contextual meaning by mentioning profile, location, and project, but it does not add parameter syntax or format details beyond the schema.

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

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

The description opens with a specific verb and resource: 'Finds and ranks French public funding programs potentially relevant to a company.' It also differentiates from siblings by scoping to the Aides-entreprises dataset and by explicitly excluding official eligibility decisions and automatic grant applications.

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

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

The description provides explicit 'Use when' and 'Avoid when' sections, including conditions such as needing explainable matching reasons and avoiding official eligibility decisions. It does not name a specific alternative tool, so it stops short of a 5, but the context is clear and actionable.

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

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

Annotations are all false, so the description carries the behavioral disclosure burden. It explicitly covers paid-call behavior, x402 payment consumption, free challenge behavior, repeat-call payment implications, accepted networks, source-record non-modification, and data-quality limitations. This is far beyond what annotations or schema 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 well-structured with clear labels, but it repeats the opening sentence almost verbatim in the Use-when section ('Benchmarks a company against public peers using available revenue, net income, growth and margin metrics'). Some trimming would make it tighter without losing key 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, network-restricted benchmark tool, the description covers purpose, selection criteria, input context, exclusions, pricing, payment behavior, network constraints, and data limitations. An output schema exists, so the description does not need to explain return values. 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%, with clear descriptions for identifier, scope, and peer_limit, including defaults, ranges, and allowed enum values. The tool description itself adds no deeper parameter meaning, but the schema already carries the full load, 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: 'Benchmarks a company against public peers using available revenue, net income, growth and margin metrics.' It clearly distinguishes this tool from the nearby compare and peers tools by naming them as alternatives in the Avoid-when section.

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

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

Usage guidance is explicit and actionable: Use-when conditions, Avoid-when conditions with named sibling tools (company/fr/compare and company/fr/peers), plus limitations. An agent can decide between this and related tools without guessing.

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

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

The description goes well beyond the annotations by explaining paid-call behavior: source records are not modified, a successful call may consume the x402 payment, the challenge is free, and repeats may require new payment. It also discloses that an unavailable source can make results partial and that status fields remain authoritative. This clarifies the meaning of readOnlyHint=false without contradicting it.

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

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

The description is longer than average but well-structured with labeled sections (Use when, Avoid when, Limitations, Price, Paid-call behavior, Accepted networks). Every section carries decision-relevant information, though the paid-call section is slightly dense 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 the paid API model, multi-source aggregation, and partial-failure risk, the description covers all essential context: when to use, when to avoid, data-source limits, cost, payment mechanics, and accepted networks. The presence of an output schema means return-value format does not need to be stated 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?

The input schema already provides 100% coverage for the single identifier parameter, including a regex pattern and a clear '9-digit SIREN or 14-digit SIRET' description. The tool description adds no parameter-specific semantics beyond the context that the company is French, so it neither improves nor harms parameter understanding.

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

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

The description opens with a specific verb ('Aggregates and normalizes') and a precise resource ('public certifications and qualifications available for a French company'), then names the concrete certification types: RGE, organic/Bio, and Qualiopi. This clearly distinguishes it from the many sibling company_fr_* tools by scope rather than relying on the title.

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 'Use when' and 'Avoid when' sections give the agent concrete selection criteria: use for public RGE/Bio/Qualiopi data, avoid for exhaustive registries, private labels, or ISO certifications. It does not name an alternative sibling tool, but the exclusion conditions are specific enough to prevent obvious misuse.

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

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

Annotations are all false, so the description carries the full burden of disclosing side effects. It clearly states that source records are not modified, that a successful paid invocation can consume payment, that the payment challenge is free, and that repeating the call may require new payment. It also documents accepted x402 networks. This is strong behavioral disclosure beyond the annotations, and there is no contradiction: the non-read-only annotation is consistent with the payment side effect.

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

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

The core behavior is front-loaded in the first sentence, and the remaining sections are compact and purposeful: use/avoid guidance, limitations, price, paid-call behavior, and accepted networks. Every sentence carries decision-relevant information without 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?

The tool has a well-documented input schema and an output schema, and the description adds the missing operational context: when to use it, when not to, what limitations apply, what the call costs, and what side effects occur. An agent has everything needed to select and invoke this tool correctly.

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

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

Schema coverage is 100%, with all five parameters already documented in the input schema, so the description does not need to re-explain them. The caveat about the single change indicator covering three denomination fields is useful for interpreting returned state, but it does not add meaning to the input parameters themselves. 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 opens with a specific verb and resource: 'Returns explicit historized Sirene change flags for a French legal unit, with the normalized state that became effective on each change date.' It clearly differentiates itself from BODACC-related siblings by naming company/fr/events and company/fr/legal-announcements-search.

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

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

The description provides explicit 'Use when' and 'Avoid when' guidance, including specific alternative tools. It also adds a limitation note explaining that only explicitly provided Sirene flags are returned, preventing an agent from over-interpreting the result set.

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

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

Annotations provide only coarse hints, so the description adds valuable behavior: successful calls can consume an x402 payment, source records are not modified, the payment challenge is free, repeated invocation may require new payment, and cursors are bound to their original query. No contradiction with the annotations.

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

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

Front-loaded with purpose, then organized into use/avoid, limitations, price, paid-call behavior, and accepted networks. No unnecessary fluff; every section adds actionable information and is easy to scan.

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 the tool's purpose, selection criteria, limitations, payment side effects, cursor constraints, and accepted networks. Output schema covers return fields, and since there are no required params, callers can rely on documented defaults. Nothing essential is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds useful cursor semantics—'A cursor is bound to its date-window query and should only be reused to continue that same query'—which goes beyond the schema's generic cursor description.

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

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

States a specific verb and resource: 'Lists French legal units entering a closed Sirene administrative period during a requested date window.' It also clarifies the nuanced preservation of current status if later reactivated, and explicitly distinguishes itself from BODACC/company/fr/events.

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

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

Provides explicit 'Use when' and 'Avoid when' sections, names the alternative tool company/fr/events, and explains that Sirene administrative cessation is not equivalent to insolvency, liquidation, or BODACC deregistration. This gives an agent clear routing guidance.

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

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

Beyond annotations, the description discloses that source records are not modified but the paid x402 invocation can consume payment, that the challenge is free, and that repetition may require a new payment. It also lists accepted networks and limitations, giving richer behavioral context than the annotations alone.

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

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

The content is front-loaded and organized into useful sections, but the opening statement is repeated nearly verbatim in the 'Use when' section. The redundancy is minor and the overall length is justified by pricing and payment details.

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

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

The description covers when to use, when not to use, alternatives, limitations, pricing, paid-call behavior, and accepted networks. An output schema exists, so return-value details are not required, and nothing needed to invoke the tool correctly is missing.

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

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

Schema coverage is 100% and already documents the identifier pattern (SIREN/SIRET), minItems, and maxItems. The description adds no new parameter-level meaning, so the baseline of 3 applies.

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

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

The description opens with a specific verb and resource: compares 2 to 5 French companies across administrative, financial, and legal-risk fields, and explicitly states it does not produce a global winner. This distinguishes it from single-company and benchmarking siblings, so an agent can tell it apart 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?

It provides explicit 'Use when' and 'Avoid when' guidance, naming company/fr/benchmark for automatic peer sets and single-company endpoints for one-company lookups. Limitations on comparability add further decision-relevant context.

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

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

Beyond the annotations, the description discloses paid-call behavior, the free payment challenge, the possibility of needing a new payment on repeat invocation, and the fact that source records are not modified. It also warns that absence of a match is not a compliance guarantee and that inferred matches are marked with confidence. No statement contradicts the annotations.

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

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

The description is longer than average but every section earns its place: purpose, routing, limitations, pricing, paid-call behavior, and accepted networks. It is front-loaded with the core function and the key compliance disclaimer.

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 compliance tool, the description covers operational, financial, and data-quality context completely: when to use, what not to conclude, payment specifics, and supported networks. With an output schema present, return-value details do not need to be restated.

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

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

The schema already covers both parameters, so the description correctly avoids repeating formats. It adds useful semantic context by noting that the domain is checked as a separate, non-officially-associated subject and that matches without a shared administrative identifier are inferred with explicit confidence.

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 operation—checking a French company against supported public alert and sanctions sources—and adds the structured REGAFI registration summary as a distinct output. It distinguishes itself from siblings by naming the exact scope and by explicitly contrasting with company/fr/risk.

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

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

The 'Use when' and 'Avoid when' sections give explicit routing criteria, including when to choose company/fr/risk instead. It also excludes complete AML/KYC decisions, beneficial-owner screening, legal guarantees, and insolvency/deregistration risk, leaving no ambiguity about 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?

The description goes well beyond the sparse annotations by disclosing that the indicator is deterministic, not an official credit score, and that missing source data affects confidence/coverage. It also clearly explains paid-call behavior: payment may be consumed, the challenge is free, and repeating the tool may require a new payment. This is especially valuable because annotations do not indicate read-only or idempotent behavior.

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

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

The description is structured with helpful labeled sections, but it contains a clear duplication: the opening sentence 'Returns a deterministic, explainable HelpMyAgent public-data default-risk indicator. It is not an official credit score.' is repeated almost verbatim inside the 'Use when' section. The pricing and network details are useful but 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?

For a single-parameter paid tool with a rich output schema, the description covers use cases, exclusions, limitations, pricing, payment behavior, and accepted networks. Nothing essential for an agent to decide when and how to invoke this tool is missing.

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

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

The input schema already provides 100% coverage: it defines `identifier` as a French company identifier with a pattern and description of SIREN/SIRET. The description adds no additional parameter-level meaning, so the baseline score of 3 applies.

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

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

The description states a specific verb ('Returns'), a clear resource ('public-data default-risk indicator'), and distinctive attributes ('deterministic, explainable', 'component contributions and confidence'). It explicitly differentiates from company_fr/risk by naming that tool as the alternative for insolvency/deregistration/legal-event risk.

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

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

The 'Use when' section gives concrete scenarios such as 'workflow triage' and wanting 'component contributions and confidence rather than an opaque score'. The 'Avoid when' section explicitly lists the alternative tool (company/fr/risk) and excluded use cases like official credit ratings or regulated probability of default.

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?

Although readOnlyHint is false, the description explains that source records are not modified but paid invocations consume x402 payment, and it warns about homonyms and identity ambiguity. This adds useful context beyond the annotations without contradicting them.

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

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

The description is organized into clear sections but is somewhat repetitive: the opening sentence is duplicated verbatim at the start of the 'Use when' section. It remains readable but contains avoidable redundancy.

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

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

With an output schema present and explicit guidance on use cases, limitations, payment behavior, and alternatives, the agent has the key information needed to call the tool correctly. The response structure is left to the output schema, which is appropriate.

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

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

The input schema already documents all four parameters with descriptions and constraints, so schema coverage is 100%. The description adds only marginal meaning by emphasizing last_name as the search key and first_names as an optional narrowing field.

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: 'Searches public French company director mandates by name.' It also explicitly contrasts itself with company/fr/directors, making the tool's scope and boundaries clear to an agent.

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 includes explicit 'Use when' and 'Avoid when' sections, naming the alternative company/fr/directors and listing exclusions such as identity proof, beneficial ownership, and contact information. This provides actionable routing criteria.

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

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

The description goes well beyond annotations by disclosing that source records are not modified, that successful calls consume an x402 payment, that the payment-required challenge is free, and that repeated calls may require a new payment. It also notes source-driven data limitations such as missing or incomplete person/role fields. This aligns with annotations rather than contradicting them.

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

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

The description is well-structured with clear sections: purpose, use when, avoid when, limitations, price, paid-call behavior, and accepted networks. It is somewhat verbose, but every section carries useful decision-making or side-effect information, and the core purpose is front-loaded.

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

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

For a one-parameter paid tool with an output schema, the description covers purpose, usage boundaries, limitations, payment side effects, idempotency nuance, and accepted networks. An agent has everything needed to select the tool and understand the consequences of calling it correctly.

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

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

The schema already fully documents the only parameter, identifier, with a pattern and a description of '9-digit SIREN or 14-digit SIRET'. The tool description merely restates SIREN/SIRET as the input source and adds no new parameter-level meaning, so the baseline 3 for high schema coverage 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 opening sentence clearly states what the tool does: returns publicly listed directors and legal representatives for a French company from a SIREN or SIRET. It also distinguishes itself from ownership-related endpoints via the 'Avoid when' note, though it does not explicitly name a sibling alternative like company_fr_director_mandates.

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

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

The description provides explicit 'Use when' and 'Avoid when' conditions, including exclusions for beneficial owners, shareholder ownership, and personal contact details. It does not name alternative sibling tools, so the routing guidance is strong but not fully explicit about the alternative to pick.

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

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

Despite annotations all being false, the description discloses critical behavioral traits: it is a paid call (price), it can consume payment, it does not modify source records, it does not confirm enrollment or operational readiness, and it specifies accepted x402 networks. This goes well beyond what annotations provide and sets clear expectations about side effects and limitations.

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 structured with clear labels (Use when, Avoid when, Limitations, Price, etc.) and front-loads the core purpose. It is somewhat long due to payment details, but every section adds essential operational information for a paid tool. It is efficient for the information it conveys.

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 one well-documented parameter, an output schema present, and a description covering purpose, usage boundaries, limitations, payment behavior, and network acceptance, nothing needed to invoke the tool correctly is missing. The description is self-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?

The input schema already documents the single parameter 'identifier' with its pattern and description (SIREN/SIRET). The tool description adds no new meaning to the parameter itself, only hints at what outputs derive from it. With 100% schema coverage, the baseline of 3 applies.

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

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

The description opens with a specific verb 'Prepares' and a clear resource: 'public company identifiers and a category-based reference schedule' for French e-invoicing. It then explicitly differentiates from siblings (invoice-check, profile) via 'Use when' and 'Avoid when', making it unambiguous what this tool does and what it does 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?

The 'Use when' section specifies the exact conditions (need public identifiers, schedule, HQ SIRET, VAT, dates) and the 'Avoid when' section names two concrete alternatives (invoice-check for printed invoices, profile for current public data). This leaves no ambiguity about when to select this tool over others.

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 carry little signal (all hints false), so the description does the heavy lifting. It discloses the payment side effect (records not modified but x402 payment consumed, challenge is free, repeats may require new payment), cursor binding to search context, and that non-diffusible restricted data is excluded. This adds meaningful behavior beyond the annotations. No contradiction with annotations since the financial side effect justifies readOnlyHint=false.

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

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

The description is long but justified: it is a paid tool requiring pricing, network, and payment-behavior disclosures. It is well-sectioned (Use when / Avoid when / Limitations / Price / Paid-call behavior / Accepted networks) and front-loads the core function before the pricing details. Each section earns its place.

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

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

An output schema exists, so return values are covered by structured data. The description covers purpose, usage routing, limitations, pagination semantics, and the full payment model. For a paginated, paid, read-oriented tool this is near-complete; only worked examples or error-case handling are absent, which is minor.

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

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

Schema description coverage is 100%, with all three parameters (identifier, limit, cursor) documented in the schema. The description adds marginal value by reinforcing that the cursor is opaque and bound to its search context and should only be reused for the same query. Per baseline rules, with full schema coverage a 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 opens with a specific verb (returns), resource (public establishments), data source (official Sirene), and content (status, activity, address). It clearly distinguishes itself from company_fr_profile by noting it returns establishments rather than headquarters/admin profile, allowing an agent to route correctly among the many company_fr_* 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?

Provides explicit 'Use when' (need public establishments for a SIREN/SIRET) and 'Avoid when' (only need headquarters/administrative profile) directives, naming the alternative tool company/fr/profile. This is model guidance for when to pick this tool over its siblings.

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

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

Even though annotations only signal non-read-only/non-idempotent behavior, the description explicitly states source records are not modified, that paid invocation consumes x402 payment, that the challenge is free, and that repeat calls may require new payment. It also discloses factual-source limitations and no legal-advice scope.

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?

Structured with bolded Use when/Avoid when/Limitations/Price sections makes the long content scannable. The core return statement is front-loaded; while the paid-call details are lengthy, they are necessary for safe invocation.

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

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

Given the output schema exists and annotations are uninformative, the description covers invocation intent, alternatives, limitations, cost, and side effects. No critical gap remains for an agent to decide to call and understand consequences.

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

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

The input schema already covers all three parameters with descriptions, defaults, patterns, and formats (100% coverage), so the description needs to add little. It reinforces the identifier can be SIREN or SIRET and that 'since' is a publication-date filter, but doesn't duplicate schema syntax.

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

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

States a specific verb ('Returns') and resource ('latest normalized public BODACC events') with input type ('French company from a SIREN or SIRET'), and gives concrete event examples. The Avoid when block distinguishes it from company/fr/risk and company/fr/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?

Explicit Use when and Avoid when sections with named alternatives (company/fr/risk, company/fr/profile) and selection criteria. Limitations section adds boundary for when results are not appropriate.

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

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

The description goes well beyond the annotations by disclosing paid-call behavior: that the x402 challenge is free, that a successful call can consume payment, and that repeating the call may require a new payment. It also reveals data limitations such as missing or confidential accounts and clarifies that this is not a credit assessment or audit opinion. There is no contradiction with the annotations.

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

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

The description is well-organized with front-loaded purpose followed by use/avoid sections, limitations, pricing, and payment behavior. Each section earns its place and provides essential operational detail without unnecessary prose.

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 financial-data tool with a single parameter and output schema present, the description covers all operational context: data availability, exclusions, pricing, payment mechanics, accepted networks, and limitations. Nothing an agent needs to decide whether and how to call it is missing.

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

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

The input schema already fully documents the single parameter 'identifier' as '9-digit SIREN or 14-digit SIRET' with a validating pattern. The description only repeats this at a high level and adds no additional meaning beyond what the schema provides, so the baseline score of 3 applies.

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

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

The description clearly states a specific verb and resource: 'Returns available public financial data for a French company from a SIREN or SIRET, including revenue and net income when available.' It names the input type and the core output, distinguishing it from administrative tools like company/fr/profile and company/fr/verify.

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

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

The description provides explicit 'Use when' and 'Avoid when' guidance, names concrete alternatives for cases involving administrative identity or status, and lists exclusions such as real-time management accounts, bank data, valuation, and credit scores. This leaves no ambiguity about when to call this tool.

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

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

Beyond the sparse annotations (readOnlyHint false, idempotent false), the description discloses that source records are not modified, details the x402 cost, states that a successful paid call consumes the advertised payment, notes that the payment-required challenge is free, and warns that repeated calls may require a new payment. It also mentions accepted networks and the limitation that history is not a complete legal or commercial event timeline. This is rich, valuable behavioral context.

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

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

The description is well-structured with clear sections (use/avoid, limitations, price, paid-call behavior, accepted networks) and each sentence contributes operational value. It is longer than a minimal description, but the payment and network details are warranted for correct invocation, so no material clutter.

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 single-parameter tool with a high-coverage schema and an output schema, the description is nearly complete. It provides selection guidance, pricing, payment behavior, network restrictions, and limitations. The only minor gap is a lack of explicit mention of the required 'identifier' parameter in the description text, but the input schema and title cover this.

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

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

Schema description coverage is 100%: the schema already explains the identifier parameter as '9-digit SIREN or 14-digit SIRET' and that a SIRET is normalized to its SIREN. The tool description does not add any further parameter-level meaning beyond that already present, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: 'Returns the historized Sirene periods of a French legal unit,' and enumerates the included fields (status, name, legal form, activity, headquarters NIC, change flags). It also differentiates from the sibling tool company/fr/events by explicitly naming it, making selection behavior unambiguous.

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

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

The description gives explicit usage guidance: 'Use when you need the exact Sirene period history for a French legal unit' and 'Avoid when you need a BODACC event timeline; use company/fr/events.' This provides both a clear condition and a sibling alternative, leaving no ambiguity about when to choose this tool.

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

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

Annotations offer no positive safety hints (all false), so the description carries the burden of behavioral disclosure. It adds valuable context: source records are not modified, paid calls consume payment, the payment-required challenge is free, and repeat calls may require new payment. This goes well beyond the bare annotation fields without contradicting them.

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

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

Well-organized with labeled sections (use, avoid, limitations, price, paid behavior). The 'Use when' sentence largely restates the opening sentence, creating minor redundancy, but the structure is front-loaded and easy to scan.

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 single-parameter paid tool with an output schema, the description covers purpose, alternatives, limitations, pricing, payment semantics, and accepted networks. Nothing essential is missing for an agent to decide whether and how to invoke it.

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

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

Schema description coverage is 100%, so the identifier parameter is already fully defined with format and pattern. The description adds no new parameter-level meaning, but none is needed given the complete 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 specific verb ('Finds') and a precise resource: public ICPE, Seveso, and IED installation signals across SIRENE establishments. The scope is clearly distinguished from the simpler establishment-list sibling, and the title reinforces the 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?

Provides explicit 'Use when' and 'Avoid when' guidance, directly naming company/fr/establishments as the alternative. Limitations about partial coverage for large companies or unavailable public sources further help an agent decide when the tool is appropriate.

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

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

The annotations only say readOnlyHint=false, openWorldHint=false, idempotentHint=false, destructiveHint=false, which is sparse. The description adds valuable behavioral context: it is an aggregator with no independent data source, it tolerates partial unavailability, and it consumes x402 payment. No contradiction with annotations.

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

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

The description is front-loaded with the defining aggregator statement, then uses clear headings for usage, limitations, and pricing. It is longer than strictly necessary due to detailed x402 payment behavior, but each section earns its place. The structure makes it easy for an agent to scan.

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 composite tool with many optional sections, the description covers purpose, when to use, when not to use, alternatives, limitation, pricing, partial coverage behavior, and payment implications. With the output schema present and the parameter schema fully covering inputs, nothing critical is missing for an agent to correctly invoke this tool.

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

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

Schema description coverage is 100%, covering all three parameters including the include enum and identifier pattern, so the description does not need to explain them. However it adds almost no semantic nuance: the list of sections in the description simply repeats the include enum, and it does not clarify the trade-offs between include selections or the optional domain behavior beyond what the schema already states.

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

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

The description states a specific verb ('Aggregates'), a clear resource ('existing French company intelligence services'), and its key property ('into a single call, with selectable sections'). It differentiates itself from the many sibling tools by positioning it as an aggregator versus dedicated endpoints and explicitly naming the legacy KYB bundle use case.

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

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

The description provides explicit 'Use when' and 'Avoid when' guidance, naming the alternative approach ('call the dedicated endpoint directly') and the condition that makes the aggregator unsuitable ('You require every requested section to be available'). This gives an agent clear decision rules.

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

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

Despite having annotations, the description adds critical behavioral context beyond the false hints: it discloses the tool is a paid call (x402), explains payment consumption and repetition behavior, and clearly states limitations (does not authenticate or prove reality). This fully informs the agent of side effects and non-idempotency.

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

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

The description is well-structured with clear sections (Use when, Avoid when, Limitations, Price, Paid-call behavior, Accepted networks) and front-loads the core purpose. Every sentence adds value, and the organization makes it easy to scan.

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 call, network constraints, optional fields, output schema exists), the description covers all necessary context: usage boundaries, limitations, payment mechanics, and supported networks. Nothing critical is missing for an agent to decide and invoke correctly.

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

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

The schema already covers all parameters with 100% description coverage, so the description doesn't need to add parameter-level detail. It does mention 'amount arithmetic' which hints at the validation logic, but this is not a significant enhancement over the schema's field descriptions.

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

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

The first sentence clearly states the tool validates a French company identifier, optional EU VAT number, and structured invoice fields via arithmetic checks. It distinguishes itself from siblings by naming explicit alternatives in the 'Avoid when' section, making its purpose unambiguous.

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

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

The description provides explicit 'Use when' and 'Avoid when' guidance, naming the exact sibling tools (company/fr/e-invoice and vat/eu/validate) for other use cases. This leaves no ambiguity about when to select this tool over its relatives.

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 carry readOnlyHint=false, openWorldHint=false, idempotentHint=false, destructiveHint=false. Description adds critical non-obvious behavior: source records are not modified, paid calls consume x402 payment, payment-required challenge is free, repeat calls may require new payment, and batch items are independent. These go beyond 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?

Description is clearly structured with labeled sections (Use when, Avoid when, Limitations, Price) and front-loaded purpose. Slight redundancy in 'Use when' — three overlapping statements about needing multiple identifiers and batch screening — could be condensed, but overall every section earns its place.

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

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

Despite having only one parameter and an output schema, the description covers purpose, usage triggers, exclusions, limitations, per-item behavior, pricing, paid-call semantics, and accepted x402 networks. This is complete for an agent to decide 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% and fully documents the 'identifiers' parameter (SIREN/SIRET formats, min/max, uniqueness). The tool description adds no new parameter semantics beyond restating 'French company identifiers', 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 first sentence states a specific verb ('Runs'), a resource ('public-data KYB dossier'), and a scope ('2 to 10 French company identifiers'). The Avoid-when clause explicitly names sibling tools and the condition that selects them (single company -> company/fr/intelligence; VAT/IBAN checks -> supplier-verification), making differentiation clear.

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

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

Description provides explicit 'Use when' with specific scenarios (small supplier batch, need per-company results) and 'Avoid when' with alternatives and conditions (single company, VAT/IBAN checks). This directly answers when to use the tool versus siblings.

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

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

The description discloses paid-call behavior (x402 payment consumption, free payment-required challenge, possible new payment on repeat) and explicitly states source records are not modified, complementing the annotations. This is especially valuable because readOnlyHint/idempotentHint are false and could otherwise signal mutation.

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 labeled sections (Use when/Avoid when/Limitations/Price) make the description scannable and front-loaded. However, the first sentence is repeated nearly verbatim in the 'Use when' section, adding a redundant sentence without new 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 search tool with an output schema, the description covers usage context, exclusions, limitations, pricing, and payment behavior, which is more than enough for correct invocation. Missing details like accepted family-code values are not required given the schema and source-coverage caveat.

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

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

All five parameters are already fully described in the schema (100% coverage), so the description carries little parameter-level burden. It adds only a high-level grouping of filters (family, date window, department) and no syntax or constraints 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 opens with a specific verb ('Searches') and identifies the exact resource ('BODACC public announcements') plus the main filters ('family, date window and/or department'). It also names a sibling tool (company/fr/events) for different use cases, so an agent can distinguish it from nearby company tools.

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

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

It gives explicit 'Use when' and 'Avoid when' sections with concrete conditions, and it names the alternative tool (company/fr/events) for timeline polling from a saved date. This is clear routing guidance rather than leaving the agent to infer when to call it.

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

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

Annotations are all false, but the description provides substantial behavioral context: source records are not modified, successful calls may consume x402 payment, the payment challenge is free, and repeated calls may require new payment. It also discloses coverage limitations and the fact that a missing record does not prove absence of influence activity.

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

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

The description is well-organized with clear sections for use, avoidance, limitations, price, and network support. It is somewhat longer than strictly necessary and contains minor redundancy between the opening sentence and the Use when section, but every section contributes practical guidance.

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 paid-call behavior, network restrictions, and the tool's purpose, the description is complete. It covers what the tool checks, when to use it, when to avoid it, pricing, payment behavior, and data limitations. The output schema covers return details, so the description does not need to.

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

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

The input schema already fully documents the single required parameter, including the 9-digit SIREN or 14-digit SIRET pattern. The description adds no additional parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

The description uses a specific verb and resource: "Checks the HATVP public lobbying register by French company identifier and extracts declared topics." It clearly distinguishes this tool from sibling tools by naming alternatives for ordinary identity and directors information.

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 includes explicit "Use when" and "Avoid when" guidance, naming concrete alternative tools such as company/fr/profile and company/fr/directors. It also states when not to use the tool, covering the key selection decision an agent needs.

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

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

Annotations are all false and provide no safety profile, so the description carries the burden. It discloses that source records are not modified, that a paid invocation consumes x402 payment, that the payment challenge is free, that repeats may require new payment, and accepted networks. Minor gaps remain (e.g., no explicit mention of rate limits or error behavior) but the core side effects and data caveats are covered.

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?

Well-organized with labeled sections and no irrelevant content, but the first sentence is repeated verbatim as the opening of the Use when section, wasting a sentence. Otherwise concise and front-loaded.

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

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

For a tool with six parameters and an output schema, the description covers selection criteria, exclusions, limitations, pricing, payment side effects, and accepted networks. Nothing an agent needs to invoke it correctly is missing; return-value details are already provided by 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 description coverage is 100%, so the schema already documents all six parameters. The description adds only general context (radius, NAF filtering) without new semantic details, which matches the baseline for high schema coverage.

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

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

Description opens with a specific verb+resource: 'Searches French companies around geographic coordinates using the official public company search geolocation endpoint.' It clearly distinguishes from nearby siblings by naming company/fr/prospecting for coordinate-free B2B prospecting and company/fr/search for known-company lookups, so an agent can select correctly.

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

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

Explicit Use when/Avoid when sections state concrete trigger conditions (having coordinates, wanting radius or NAF filtering) and name the alternatives (company/fr/prospecting, company/fr/search). Limitations also clarify when results should not be over-interpreted.

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 are all false (not read-only, not idempotent, not destructive), so the description carries full burden. It discloses that source records are not modified, that a successful call consumes x402 payment, that the payment-required challenge is free, and that repeating may require a new payment. It also details the 366-day window limit and cursor binding rules. This is excellent transparency.

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

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

The description is well-structured with clear sections (purpose, use when, avoid when, limitations, price, paid-call behavior, accepted networks). It is front-loaded with the primary statement and every sentence adds value — no filler or redundant 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?

Given the tool's complexity (paid call, constraints, alternatives, payment behavior), the description covers all essential aspects an agent needs to decide and invoke correctly: purpose, usage, limitations, pricing, payment semantics, and accepted networks. An output schema exists, but the description still fully contextualizes the call.

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

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

Schema coverage is 100%, so parameters are well-documented. The description adds meaningful nuance about the cursor being bound to the date-window query and the distinction between Sirene creation date and BODACC publication date, which clarifies parameter intent. This goes beyond the schema, although the core parameter meanings are already clear.

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 ('Lists'), resource ('French legal units'), and context (created in a date window from the official Sirene source). It distinguishes itself from siblings by explicitly naming alternatives (company/fr/events, legal-announcements-search) for BODACC publication events, making it clear what it 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?

Includes explicit 'Use when' and 'Avoid when' sections that define in which situations this tool is appropriate and point to the correct alternatives. This leaves no ambiguity about when to invoke it versus the siblings.

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

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

With annotations providing no behavioral signals, the description carries the full burden and handles it well: it discloses paid-call behavior, that source records are not modified, that the payment-required challenge is free, that repeating after a completed paid invocation may require new payment, and that matching is conservative and partially covered. This is rich, non-obvious behavioral context.

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

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

The description is front-loaded with the core purpose and uses clear labeled sections for use, avoid, limitations, price, and paid-call behavior. It is longer than average, but every section adds operational detail an agent needs for a paid tool, so the length is justified.

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

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

Given the tool's complexity, output schema presence, and minimal annotations, the description covers what the tool does, when to use it, when not to use it, its limitations, pricing, payment side effects, and accepted networks. An agent has enough to decide and invoke correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by tying the optional project parameter to public-aid generation and taxonomy matching, and by explaining that tender matching relies on CPV codes and historical contract vocabulary. This gives operational meaning to the parameters that the schema alone does not fully convey.

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

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

The first sentence states a specific action and resource: 'Ranks actionable French public funding and open procurement opportunities for a company using its profile, project context and historical public contracts.' It also distinguishes itself from the broader procurement/fr/search tool by naming that alternative, so an agent can tell it apart from siblings.

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

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

The 'Use when' and 'Avoid when' sections give explicit conditions and name the alternative for broad open-tender search: 'use procurement/fr/search.' It also tells the agent when not to rely on it for guarantees of eligibility or success, which is valuable decision guidance.

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

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

The annotations are minimal (all false hints), so the description carries the transparency burden. It clearly discloses payment side effects, that source records are not modified, that no payment is approved/blocked/recommended, and that bank-account ownership, invoice authenticity, and private payment behavior are not verified. This is rich behavioral context beyond the structured fields.

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

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

The description is well-sectioned and front-loads the core purpose, but it repeats the sentence 'Returns structured public counterparty context before an automated B2B payment. It never approves or recommends a payment.' verbatim in the Use when section. This duplication means not every sentence earns its place.

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

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

With an output schema present and both parameters fully documented, the description supplies the remaining operational context an agent needs: price, accepted x402 networks, paid-call behavior, limitations, and explicit sibling routing. Nothing essential for correct selection or 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?

Input schema coverage is 100%, and both parameters already have meaningful descriptions (SIREN/SIRET pattern and the optional domain's non-ownership semantics). The description adds no parameter-level detail beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Returns structured public counterparty context before an automated B2B payment.' It further clarifies what the tool does not do ('never approves or recommends a payment') and distinguishes itself from siblings by naming verify and intelligence as alternatives for other needs.

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

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

Explicit 'Use when' and 'Avoid when' sections give precise selection criteria: compact counterparty context before an automated payment, or status/risk/compliance signals without a full KYB dossier. It also names alternatives (company/fr/verify, company/fr/intelligence) for excluded cases.

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?

All annotations are false or unhelpful, so the description bears the full burden. It explains that source records are not modified, that successful paid invocations consume an x402 payment, that the challenge is free, that repeating the call may require new payment, and that peer relationships are inferred and coverage-dependent. This is consistent with the annotations and adds meaningful behavioral context.

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

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

The definition is well-structured with Use/Avoid/Limitations/Price/Paid-call sections and front-loaded purpose. However, the opening sentence is duplicated verbatim in the 'Use when' section, wasting a sentence and slightly hurting 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 an output schema, a simple required identifier parameter, and low-value annotations, the description covers conceptual behavior, alternatives, limitations, pricing, and paid-call semantics. An agent has everything needed to select and invoke this tool correctly.

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

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

The input schema already covers 100% of parameters with descriptions, defaults, enums, and patterns. The description adds only high-level context about geographic criteria and peer-set selection, which reinforces but does not extend the schema. Baseline 3 is appropriate.

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

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

States an action ('Finds administratively comparable French companies') with a specific resource and selection criteria (activity, size, geographic scope). It also distinguishes itself from the closest siblings by clarifying it returns a peer set rather than procurement competitors or benchmark metrics.

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?

Contains explicit 'Use when' and 'Avoid when' guidance naming alternatives (company/fr/public-contract-competitors, company/fr/benchmark) and the conditions that route to them. This removes ambiguity about when to invoke this tool over nearly identical siblings.

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

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

The description openly discloses limitations (nullable fields), paid-call behavior (payment consumed, free challenge, new payment on repeat), and the fact that source records are not modified. With all annotations set to false or unhelpful, this description carries the full behavioral burden and does so thoroughly.

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

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

The description is well structured with clear sections: core behavior, use/avoid guidance, limitations, pricing, and side-effect behavior. Each section earns its place, and the most important information is front-loaded. Despite covering many aspects, it remains scannable and purposeful.

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

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

For a single-parameter tool with an output schema and a crowded sibling set, the description is complete: it states what the tool returns, when to use it, when not to use it, what its limitations are, and what side effects to expect. Nothing essential for correct selection or 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 the description gains little extra credit for parameters. The identifier parameter is fully documented in the schema with its pattern, and the description simply reiterates that a SIREN or SIRET is accepted. This meets the baseline but adds no new semantic detail.

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

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

The description opens with a clear verb and resource: 'Returns the public profile of a French company from a SIREN or SIRET.' It also distinguishes itself from sibling tools by naming the verify endpoint for existence checks and the dedicated endpoints for directors, financials, and risk. This makes the tool's purpose unambiguous.

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

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

The 'Use when' and 'Avoid when' sections provide explicit decision criteria and name specific alternatives, such as company/fr/verify and the specialized directors/financials/risk endpoints. This is exactly the kind of routing guidance an agent needs to select correctly among many siblings.

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

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

Annotations only indicate not read-only, not idempotent, and not destructive; the description adds critical behavioral context: source records are not modified, paid invocations can consume x402 payment, the payment challenge is free, and repeating a paid call may require a new payment. It also notes coverage limitations and that matches are discovery signals, which is valuable beyond annotations.

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

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

The description is front-loaded and contains useful sections, but the first sentence is repeated almost verbatim in the 'Use when' section. This redundancy costs conciseness even though the overall structure is clear.

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 14-parameter optional-filter tool with an output schema, the description covers use cases, avoid cases, alternatives, limitations, pricing, payment behavior, and accepted networks. Nothing critical appears missing for an agent to decide whether and how to invoke this tool.

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

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

The input schema already covers 100% of parameters with individual descriptions, so the description does not need to repeat them. It adds general filter categories (activity, geography, size, certifications) but no parameter-specific semantics beyond the schema, so baseline 3 is appropriate.

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

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

The description states a specific action and resource: 'Searches active French companies using structured public B2B filters such as activity, geography, size and supported certifications.' It also names alternatives for related lookups (search, nearby), so an agent can distinguish it from siblings 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?

Provides explicit 'Use when' and 'Avoid when' sections with concrete sibling alternatives: company/fr/search for single known companies and company/fr/nearby for radius searches. This gives clear routing guidance beyond the unstructured schema.

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 are all 'false', so the description carries the burden. It clearly discloses the paid-call mechanism (x402 payment consumption, free challenge, repeat-payment requirement), states that source records are not modified, and adds limitations about inferred competition and DECP coverage. This adds substantial context beyond the minimal annotations.

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

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

The description is well-structured into clear sections (purpose, use/avoid, limitations, payment details) with the core purpose front-loaded. Every sentence adds essential information, especially the payment behavior and accepted networks which are critical for an agent to avoid unexpected costs. No wasted words.

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

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

This tool has a paid call, specific data source, and limitations - the description covers all of these. It explains what it does, when to use/avoid, pricing, payment behavior, and network requirements. An output schema exists, so return values need no description. The description is fully self-sufficient for correct invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema - it implies the identifier refers to the 'target company' but doesn't go into further parameter behavior or formatting. This is adequate but not exceptional given how thoroughly the schema describes both parameters.

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

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

The description states a specific verb ('Finds'), resource ('companies winning public contracts'), and the distinguishing scope ('CPV segments shared with the target company using DECP public award data'). It clearly differentiates from siblings like company_fr_peers and company_fr_public_contracts by naming the exact use case.

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 'Use when' and 'Avoid when' sections list concrete conditions and name two alternative tools (company/fr/peers for general peers, company/fr/public-contracts for own contracts). This is textbook 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?

The description goes beyond the sparse annotations by disclosing that source records are not modified, that paid calls consume x402 payment, that the payment-required challenge is free, and that repeating a completed paid invocation may require a new payment. It also explains data-coverage limitations. This gives the agent crucial behavioral context that annotations alone do not provide.

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

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

The description is front-loaded with the core purpose, then organized into clear labeled sections: Use when, Avoid when, Limitations, Price, Paid-call behavior, and Accepted networks. Every section adds relevant operational or selection information, and there is no redundant 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?

The description covers purpose, selection criteria, exclusions, alternative tools, data limitations, pricing, payment semantics, and accepted networks. An output schema exists, so detailed return-value documentation is unnecessary. Nothing essential for correct tool selection or 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 input schema already documents the identifier and limit parameters well. The description reinforces that results are linked to a company identifier and mentions returned data types such as buyers, amounts, and CPV codes, but it does not add meaning beyond what the schema already provides. A baseline score of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Returns public contracts awarded to a French company from consolidated French public procurement award data.' It clearly distinguishes this tool from siblings by focusing on already-awarded contracts rather than open tenders or EU-wide contracts.

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

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

Usage guidance is explicit and well-structured. It provides 'Use when' conditions, an 'Avoid when' section, and names concrete alternative tools: procurement/fr/search and company/fr/opportunities. It also states when the tool is not appropriate, such as for private-sector contracts.

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 are sparse (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the description carries the burden. It discloses paid-call behavior, that source records are not modified, that a successful invocation can consume payment, that the payment-required challenge is free, and that repeating after a paid call may require new payment. It also notes the result is not a complete statement of all EU business won. This is substantial behavioral context beyond the annotations.

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

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

The description is well-structured with clear 'Use when', 'Avoid when', 'Limitations', 'Price', and 'Paid-call behavior' sections. It is longer than average but every section earns its place, especially the paid-call behavior which is critical for an agent to know. Slightly verbose but not bloated.

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

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

The description covers purpose, usage, limitations, pricing, and paid-call behavior. It has an output schema, so return values are documented elsewhere. The only minor gap is the mismatch between 'company name' in the description and the numeric-only identifier pattern in the schema, which could confuse an agent. Overall, it is complete for a paid API tool.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (identifier and limit). The description adds that the identifier can be a French company name or SIREN, but the schema only allows a 9-digit SIREN or 14-digit SIRET pattern. This is a slight mismatch: the description mentions 'company name' as an input, but the schema's identifier pattern only accepts numeric SIREN/SIRET. The description does not add much beyond the schema's parameter docs, 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 states a specific verb ('Searches TED notices'), a specific resource ('EU public-contract awards associated with a French company name or SIREN'), and lists concrete outputs (publication numbers, buyers, winners, CPV codes, decision dates). It clearly distinguishes from siblings like company_fr_public_contracts and procurement_fr_search.

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

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

The description explicitly says 'Use when' and 'Avoid when', naming the exact alternatives (company/fr/public-contracts for French DECP contracts, procurement/fr/search for open BOAMP opportunities). It also states limitations about TED matching and manual disambiguation, giving the agent clear selection criteria.

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

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

The description substantially expands beyond the sparse annotations. It discloses that source records are not modified, that a successful paid invocation can consume x402 payment, that the payment challenge is free, and that repeating the tool may require a new payment. It also explains REGAFI coverage limitations, which is important for interpreting a no-match 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?

The description is organized into clear labeled sections and front-loads the core purpose. There is some redundancy between the opening sentence and the 'Use when' section, but the additional details on limitations, pricing, and payment behavior all earn their place.

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

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

For a single-parameter tool with an output schema, the description is complete. It covers when to use, when not to use, limitations, payment side effects, and accepted networks. The output schema handles return-value documentation, so nothing essential is missing.

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

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

Schema coverage is 100%: the sole parameter 'identifier' is fully defined with a regex pattern and an explanation of SIREN/SIRET. The description adds little beyond 'French company,' but because the schema carries the full parameter burden, the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Checks a French company against the public REGAFI register and normalizes matching regulatory records.' It clearly distinguishes this tool from company/fr/compliance by framing it as financial-regulatory registration signals rather than general compliance, so an agent can differentiate it from siblings.

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

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

The 'Use when' and 'Avoid when' sections give explicit decision criteria. It states to use this tool when checking REGAFI registration and explicitly routes alternatives to company/fr/compliance for public alerts plus REGAFI summary or sanctions/asset-freeze screening. This is unambiguous 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 sparse annotations, the description thoroughly discloses behavior: paid-call consumption via x402, free payment challenge, no source-record modification, and the informational limitations (not audit, legal opinion, or regulated credit report). This is valuable context the annotations do not provide.

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

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

The description is well-organized with clear sections: use, avoid, limitations, price, and paid-call behavior. It is slightly longer than strictly necessary and shows minor redundancy between the opening sentence and the 'Use when' line, but every section earns its place.

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

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

For a two-parameter tool with a full input schema, output schema, explicit usage routing, pricing, payment side effects, and limitations, the description leaves nothing material for an agent to infer. It is complete for correct selection and invocation.

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

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

Schema coverage is 100%, and the input schema already fully documents the identifier pattern and language enum. The description reinforces French/English output and portability, but adds no meaningful parameter semantics beyond what the schema provides, 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 opens with a specific verb and artifact: 'Generates a simple PDF rendition of selected HelpMyAgent public company intelligence.' It clearly distinguishes this tool from structured-data siblings and the risk-reading tool through explicit avoid conditions.

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 explicit 'Use when' and 'Avoid when' guidance, naming alternatives such as company/fr/intelligence for structured data and company/fr/risk-reading for risk interpretation. An agent can correctly route between this tool and its siblings without guessing.

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

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

Beyond the annotations, the description discloses the 10-year BODACC lookback, behavior when source coverage is insufficient, the paid-call nature via x402, that source records are not modified, that payment may be consumed, and the accepted networks. This is rich behavioral context that helps the agent manage side effects and expectations.

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

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

The description is well-structured with clear sections and front-loaded purpose. It is somewhat repetitive about the tool not being a credit score, appearing both in the opening and in the limitations, but the additional price and payment details are necessary and earn their place.

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

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

Given an output schema exists, the description does not need to explain return values. It covers what the tool does, when to use it, when not to use it, limitations, pricing, payment behavior, and accepted networks. An agent has enough context to invoke it correctly.

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

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

Schema coverage is 100%: the single parameter 'identifier' is already described as '9-digit SIREN or 14-digit SIRET' with a validating pattern. The description adds no additional parameter-level detail beyond the schema, so the baseline of 3 applies.

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

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

The description opens with a specific verb and resource: 'Detects public legal-risk signals for a French company from company status and BODACC notices, including insolvency proceedings and deregistrations.' It clearly distinguishes itself from credit scoring and from compliance-related screening, even naming the compliance sibling as the alternative for sanctions/blacklist needs.

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

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

The description provides explicit 'Use when' and 'Avoid when' sections. It tells the agent to use this tool for explainable public legal-risk signals and normalized risk levels, and to avoid it for credit scores, default probability, payment behavior, or sanctions screening, explicitly directing to company/fr/compliance for blacklist screening.

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

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

The description goes well beyond the sparse annotations: it discloses that the narrative is derived from existing public-data results and creates no new evidence, that it is informational and not a regulated credit/legal decision, and that paid x402 calls do not modify source records but may consume payment and require new payment on repetition. This is strong behavioral disclosure.

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

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

The description is longer than average, but it is clearly structured into use-when, avoid-when, limitations, price, paid-call behavior, and accepted networks. Every block adds decision-relevant information, though some phrasing 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?

For a two-parameter paid tool, the description covers purpose, usage boundaries, limitations, pricing, payment behavior, accepted networks, and output language options. With an output schema present, no essential selection or invocation context is missing.

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

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

The schema already provides complete descriptions for both parameters, including the SIREN/SIRET pattern and the language enum/default. The description adds only generic context about French companies and language, so it does not meaningfully increase parameter understanding beyond the schema.

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

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

The description names a specific verb and resource: it 'Turns existing public risk, legal, financial and signal data into a concise written reading' for a French company. It also distinguishes itself from siblings by explicitly pointing to company/fr/risk and company/fr/default-score for structured alternatives.

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

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

It provides explicit 'Use when' and 'Avoid when' guidance, including the specific sibling tools to use instead when structured risk events or default indicators are needed. This leaves no ambiguity about when this tool is 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?

Beyond the annotations, the description discloses important behavioral traits: source records are not modified, a successful paid invocation can consume x402 payment, the payment-required challenge is free, repeating the tool may require a new payment, and matching quality depends on the source. This is exactly the kind of context that annotations alone do not provide.

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

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

The description is longer than average but each section—purpose, use/avoid, limitations, price, paid-call behavior, networks—serves a distinct decision-making purpose. The core purpose is front-loaded, and the label-based structure makes it scannable. A small amount of redundancy with the schema 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?

For a paid search tool with side effects, the description covers all essential context: when to use it, when not to, limitations of the result set, pricing, payment behavior, and accepted networks. Since an output schema exists, return-value details need not be spelled out. Nothing an agent needs to safely invoke this tool is missing.

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

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

The input schema already provides complete descriptions for all three parameters (query, limit, postal_code), so the description adds little new semantic detail. It does summarize the query types and optional location criteria, but that information is already present in the schema.

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

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

The description opens with a specific verb and resource: 'Searches French companies by name, SIREN, SIRET or optional location criteria and returns structured matching company records.' It also distinguishes itself from sibling tools by positioning this as the candidate-finding step rather than a verification or intelligence endpoint.

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

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

The description provides explicit 'Use when' and 'Avoid when' guidance, naming the exact alternative endpoints (company/fr/verify, company/fr/intelligence) and the conditions that should route an agent to them. This leaves no ambiguity about when to select this tool.

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

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

The description goes well beyond annotations by disclosing the 10,000 cap, the exactness flag behavior, sample_coverage_percent semantics, pricing, paid-call behavior, and accepted networks. It also clarifies that source records are not modified, which is especially useful given readOnlyHint is false.

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

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

The description is well-structured with labeled sections, front-loads the core behavior, and keeps each sentence purposeful. While it contains more detail than average, every sentence addresses a practical concern such as pricing, limitations, or usage boundaries.

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

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

The description covers the tool's purpose, usage boundaries, limitations, output semantics (via cap/exactness/sample coverage), pricing, and payment behavior. An output schema exists, so not describing return fields is acceptable. Nothing essential for correct selection or 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 schema already documents all four parameters. The description adds minimal parameter-level detail, mostly echoing the activity code and optional financials without expanding on format or behavior beyond the schema.

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

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

The description clearly states a specific verb ('Returns') and resource: the source-reported active-company count for a French NAF activity, plus descriptive samples. It distinguishes itself from sibling tools by focusing on sector statistics rather than company profiles, benchmarks, or 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?

The description provides explicit 'Use when' and 'Avoid when' guidance, including a concrete alternative context (official INSEE publication vs. computed company records). This leaves no ambiguity about when the tool should be selected.

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 all annotations set to false, the description carries the full burden of behavioral disclosure. It clearly states that source records are not modified, that paid invocations may consume x402 payment, that the payment-required challenge is free, and that repeated calls may need new payment. It also discloses coverage limitations when underlying data services are unavailable. No contradiction with annotations.

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

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

The description is well-structured with clear sections and front-loaded purpose. It is longer than minimal but every section adds relevant guidance; there is minor redundancy in repeating the signal list, but it is not distracting.

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

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

Given the output schema exists, the description does not need to explain return values. It covers purpose, alternatives, limitations, pricing, payment side effects, and accepted networks, making it complete for an agent to decide when and how to invoke this tool.

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

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

The schema already documents the single 'identifier' parameter with its SIREN/SIRET pattern and description. The tool description adds no additional parameter-level semantics, so the baseline of 3 applies since the schema fully covers the parameter.

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

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

The description opens with a specific verb ('Detects') and resource ('explainable business signals from available French company data'), then enumerates the signal families. It clearly differentiates this tool from raw-record endpoints like financials or contracts, so an agent can tell what this endpoint 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?

The description provides explicit 'Use when' and 'Avoid when' sections, including concrete exclusions for raw financial, BODACC, contract, and certification records, plus the non-subscription caveat. This gives an agent direct routing guidance versus the many sibling tools.

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

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

Annotations are sparse (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the description carries the burden. It discloses that succession links are declaration-based and may be incomplete per INSEE, that cursors are direction-specific and must not be reused across SIRETs/directions, and that paid calls consume x402 payment while the challenge is free. This is meaningful behavioral context beyond the annotations. It doesn't fully describe what happens on repeated calls, but the paid-call behavior is well covered.

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

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

The description is well-structured with clear sections (Use when, Avoid when, Limitations, Price, Paid-call behavior, Accepted networks). It is slightly long but every section earns its place, and the core purpose is front-loaded in the first sentence.

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

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

The description covers purpose, usage, limitations, pricing, payment behavior, and network constraints. With an output schema present, return values don't need to be described. The only minor gap is that it doesn't explicitly state what happens if the SIRET has no successions, but the limitations section already sets expectations about data completeness.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds context about cursor direction-specificity and the declaration-based limitation, but it doesn't add much per-parameter meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Returns'), a precise resource ('official Sirene predecessor and successor links for a French establishment'), and the key data fields (effective date, headquarters-transfer flag, economic-continuity flag). It clearly distinguishes this from the sibling company_fr_establishments by naming what it 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?

The description explicitly says 'Use when: You need official predecessor or successor establishment links for a French SIRET' and 'Avoid when: You only need the current establishments of a company; use company/fr/establishments.' This gives the agent a clear decision rule and names the alternative 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?

With all annotations false, the description carries the burden. It discloses source records not modified, paid-call behavior and payment consumption, non-idempotent repeat behavior, IBAN structural validation limitation, and decision-support not guarantee. No contradiction with annotations.

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

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

Purpose is front-loaded, then Use/Avoid/Limitations/Price/Paid-call behavior/Networks are clearly labeled. Each sentence adds operational value; 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 multi-check tool, the description covers selection, exclusions, limitations, payment behavior, accepted networks, and expected result shape (one normalized verdict plus individual check results), while output schema covers return details.

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

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

Schema already documents all three parameters with 100% coverage. Description adds context that VAT/IBAN are optional and used for consistency checks, and clarifies IBAN validation is structural, complementing the schema's per-field descriptions.

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

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

The description states a specific composite action (combines public company, compliance, and optional VAT/IBAN checks into a supplier review result), names the target resource (French supplier), and explicitly differentiates from company/fr/intelligence and company/fr/invoice-check.

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

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

Provides explicit Use when and Avoid when sections with concrete scenarios (pre-onboarding/pre-payment review) and names alternatives (company/fr/intelligence, company/fr/invoice-check), leaving no ambiguity about tool selection.

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

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

Beyond the annotations, the description discloses critical paid-call behavior: source records are not modified, successful invocations can consume x402 payment, the challenge is free, and repeated calls may require new payment. Limitations and non-KYC disclaimers further set expectations. This is valuable context the annotations do not provide.

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

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

The description is front-loaded with purpose, then structured into labeled Use/Avoid/Limitations/Price/Paid-call behavior sections. Every sentence carries necessary information for correct use, and the format is scannable 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?

Given the presence of an output schema and the single identifier parameter, the description covers all essential operational context: what it verifies, when not to use it, limitations, pricing, payment side effects, and accepted networks. 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?

The input schema already provides a pattern and description for the identifier parameter (9-digit SIREN or 14-digit SIRET), so schema coverage is 100%. The tool description adds no new parameter-level detail beyond restating the identifier type. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Verifies the existence and current status of a French company or establishment from a SIREN or SIRET.' It clearly distinguishes the tool from siblings that provide other specialized data, and the identifier scope (SIREN/SIRET) 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?

The description provides explicit 'Use when' and 'Avoid when' guidance. It names the alternative for name-based discovery (company/fr/search) and points to specialized endpoints for directors, financials, legal risk, and compliance. This gives an agent clear routing criteria.

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