HelpMyAgent

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

The description goes beyond the annotations by explaining that eligibility results are indicative, not official, and by detailing the meaning of 'potentially_eligible' and the limitations around workforce, company-age, size-text, and fine-grained geographic criteria. It also notes that very local schemes can be omitted. This gives the agent an accurate mental model of the tool's output reliability and edge cases.

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

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

The description is well-structured with the core purpose front-loaded, followed by clearly labeled Use when, Avoid when, Limitations, and Price sections. Each segment provides necessary decision-making information without redundancy. The length is justified by the rich selection and limitation context.

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

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

Given the tool has an output schema and covers a complex domain, the description is complete: it explains purpose, usage boundaries, result interpretation, limitations, and cost. An agent has enough information to select, invoke, and correctly interpret the result of this tool without significant gaps.

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

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

Schema description coverage is 100%, so the schema already fully documents all three parameters: limit, project, and identifier. The description adds contextual meaning around 'profile, location and project' and hints at how criteria are matched, but it does not add parameter-level details beyond the schema. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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

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

The description opens with a specific verb and resource: 'Finds and ranks French public funding programs potentially relevant to a company based on its profile, location and project.' It clearly differentiates the tool from general company data or procurement siblings by focusing on public Aides-entreprises funding programs. The 'Avoid when' clause further clarifies the boundary, making the tool's purpose unmistakable.

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

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

The description provides explicit 'Use when' and 'Avoid when' guidance, naming concrete scenarios such as needing explainable matching reasons and known/unknown eligibility criteria, versus needing official eligibility decisions or automatic grant applications. This is strong routing guidance that helps an agent decide when to invoke this tool versus other options.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the description does not need to restate those. The description adds useful limitations about coverage depending on public sources, a price note, and a legal-use disclaimer. It does not explain edge behaviors like missing data handling or latency, but the output schema and annotations carry some of that burden.

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

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

The description is reasonably short and uses labeled sections, which aids scanning. However, the 'Use when' line is a verbatim duplicate of the first sentence, making it redundant. The limitations and price sections are useful and earn their place, but the redundancy keeps this from being a tightly written definition.

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

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

The tool has three parameters, one required, and an output schema, so the description does not need to detail return values. However, it leaves parameter semantics unexplained and provides no sibling differentiation within a large family of company_fr_* tools. An agent selecting between benchmark, peers, compare, and competitors would need more context to invoke this tool correctly.

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

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

Schema description coverage is 0%, so the description carries full responsibility for explaining parameters. It does not define identifier, scope, or peer_limit. While peer_limit can be inferred from 'public peers' and scope enum values are self-explanatory, identifier type and meaning are unclear beyond the regex pattern. The description fails to compensate for the lack of schema documentation.

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

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

The description clearly states the tool benchmarks a company against public peers and lists the specific metrics used (revenue, net income, growth, margin). This is a specific verb+resource combination that conveys the core function. However, it does not distinguish this tool from siblings like company_fr_peers or company_fr_compare, which could plausibly overlap.

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?

There is a 'Use when' section, but it merely repeats the main benchmark sentence and adds no new routing information. The 'Avoid when' section only addresses legal, regulated credit, and fraud-free decisions rather than identifying when to prefer an alternative tool. No guidance is given for choosing between company_fr_benchmark, company_fr_peers, or company_fr_compare.

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 annotations by disclosing coverage limitations, the possibility of partial results when a source is temporarily unavailable, and that source validity/status fields remain authoritative. This is useful behavioral context that complements the annotations rather than merely repeating 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 compact and well-structured with labeled sections for use, avoidance, limitations, and price. The main purpose is front-loaded, and every sentence provides actionable information without redundancy.

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

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

Given the tool has one required parameter, an output schema, and relevant annotations, the description covers the remaining context: when to use it, what it supports, what its limitations are, and its cost. Nothing essential is missing for an agent to invoke it correctly.

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

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

The input schema already provides 100% coverage for the single `identifier` parameter, including its pattern and description. The tool description does not add parameter-specific detail, but none is necessary given the schema's completeness, so a baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Aggregates and normalizes public certifications and qualifications available for a French company,' and names concrete examples (RGE, organic certification, Qualiopi). It also differentiates the tool from a broader registry through the 'Avoid when' clause, which clarifies exactly 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 'Use when' and 'Avoid when' sections give explicit conditions for selecting this tool versus alternatives, including 'You need one normalized response combining the supported public certification sources.' This leaves little room for an agent to misuse the 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 are present but provide only generic hints (readOnlyHint false, destructiveHint false). The description adds valuable behavioral context: a limitation that coverage depends on public sources, a price per call, and a caution against using it for legal/credit/fraud-free decisions. No contradiction with annotations was found.

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 short and organized into labeled sections, but the 'Use when' field duplicates the opening sentence verbatim, wasting a section that could have offered alternative routing guidance. The remaining content is compact 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 single-parameter tool with an output schema, the description covers the key aspects: what is compared, the non-winner behavior, limitations, and pricing. It does not explicitly name SIREN/SIRET as the identifier format, but the regex pattern covers that. The tool is simple enough that an agent can invoke it correctly with this description.

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

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

Schema description coverage is 0%; the schema only provides a regex pattern for identifiers. The description does not explain that identifiers should be SIREN/SIRET numbers or how they map to French companies. It repeats the 2-to-5 bounds already present in minItems/maxItems, failing to compensate for the missing parameter documentation.

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 ('Compares'), a bounded subject ('2 to 5 French companies'), and a clear scope ('public administrative, financial and legal-risk fields'). It also adds a key discriminator, 'without producing a global winner', which distinguishes this tool from benchmarking 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' section is a verbatim repeat of the main description, adding no new guidance. The 'Avoid when' section gives a meaningful exclusion for legal/credit/fraud decisions, but does not explain when to choose this tool over related siblings like company_fr_benchmark or company_fr_peers. Usage context is implied rather than explicit.

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

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

The description discloses important behavioral traits beyond the annotations: the result is inferred and not official, coverage depends on public sources, and there is a per-call price. These are valuable caveats about reliability and cost. It does not elaborate on side effects, but neither the description nor the annotations suggest destructive behavior, and there is no contradiction.

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

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

The description is structured with headings and includes useful price information, but the 'Use when' block repeats the opening two sentences verbatim. This redundancy is not offset by additional content, making the description less concise than it appears.

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

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

The schema supplies defaults, an enum, and an identifier pattern, and the output schema exists, so basic invocation is possible. The description adds limitations and pricing. However, it fails to clarify parameter semantics and does not route the agent among the numerous sibling company_fr_* tools, leaving the definition minimally viable rather than complete.

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

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

Schema description coverage is 0% and the description does not explain any of the three parameters. It alludes to SIRENE and geography criteria, which hints at identifier and scope, but it never states what identifier refers to, what scope values mean, or how limit behaves. With no schema parameter descriptions, this is a significant gap.

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

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

The description starts with a specific verb and object ('Finds probable competitors') and identifies the concrete criteria: shared SIRENE activity, size, and geography. It also adds the key qualifier that the relationship is inferred, not official. However, it does not explicitly contrast with sibling tools like company_fr_peers or company_fr_public_contract_competitors, so differentiation is implicit rather than explicit.

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 is a verbatim repeat of the opening description, so it provides no additional scenario guidance. No sibling alternatives are mentioned, and the 'Avoid when' clause is a legal/credit disclaimer rather than a tool-selection condition. An agent only gets the implied use case of finding probable competitors.

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 what the sparse annotations provide: it warns that NO_PUBLIC_ALERT_FOUND is not a compliance guarantee, explains that inferred matches are explicitly marked with confidence, and notes that a domain is checked as a separate subject. It also discloses the cost per call, which is relevant 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 and front-loaded purpose. There is minor redundancy between 'No match must be interpreted as a guarantee of compliance' and the later NO_PUBLIC_ALERT_FOUND limitation, but the overall length is justified by the complexity and usage 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 output schema exists, the description does not need to explain return values. It covers purpose, when to use, when to avoid, alternative tools, limitations, and pricing. This is complete enough for an agent to confidently select and invoke the tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful clarification for the optional domain parameter by explaining that it is checked separately and is not considered officially associated with the company. The identifier parameter is sufficiently described by the schema's pattern and description.

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

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

The description clearly states the tool 'Checks a French company against multiple public alert and sanctions sources,' identifying both the resource and the specific compliance purpose. It also distinguishes itself from sibling tools by explicitly contrasting with company/fr/risk for insolvency or deregistration 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?

Provides explicit 'Use when' and 'Avoid when' sections with concrete conditions, including the specific alternative company/fr/risk. It also clarifies unsupported use cases like full AML/KYC decisions and beneficial-owner screening, leaving no ambiguity about 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 description adds behavioral context beyond the annotations: the indicator is deterministic and explainable, not an official credit score, and coverage depends on public sources. The deterministic claim is in mild tension with idempotentHint=false and openWorldHint=true, but the coverage limitation explains that the underlying public data can change. No direct annotation contradiction exists.

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

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

The description is short and front-loaded with the core purpose, and the Avoid/Limitations/Price sections are efficient. However, the 'Use when' section is a verbatim repetition of the opening sentence, adding no information and wasting a line. This redundancy prevents a higher score.

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

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

An output schema exists, so return-value documentation is not necessary, and the description covers important caveats: non-official status, legal-use restriction, source-dependent coverage, and price. But it omits parameter semantics and does not situate the tool relative to sibling risk-related tools, so an agent may still be unsure how to invoke it correctly or choose it confidently.

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 0% and the description never explains what the identifier parameter means, what formats are accepted, or that it refers to a French company identifier such as SIREN/SIRET. The regex pattern in the schema is the only hint, but the description does nothing to compensate for the lack of parameter documentation.

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

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

The description clearly identifies a specific deliverable: a deterministic, explainable public-data default-risk indicator, and explicitly disclaims that it is not an official credit score. This gives an agent a solid sense of what the tool does. However, it does not explicitly differentiate this tool from the sibling company_fr_risk, leaving some overlap ambiguity.

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

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

The description includes an explicit 'Avoid when' clause stating not to use it for legal, regulated credit, or guaranteed fraud-free decisions, and it mentions source-dependent coverage limitations. The 'Use when' section, however, simply repeats the main description rather than providing a concrete trigger or routing to an alternative tool, so the guidance is only partially useful.

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 says the tool 'Searches public French company director mandates', which implies a read-only operation, yet the annotations set readOnlyHint=false. This is an annotation contradiction. The description does add caveats about homonyms and coverage, but the contradiction overrides that contribution.

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 short and uses labeled sections, but the first sentence is repeated verbatim under 'Use when', which wastes a sentence. The limitations and price lines are useful, but the redundancy lowers the structural quality.

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 includes price, source-coverage limitations, and important caveats about homonyms and identity proof, and an output schema exists so return values are covered structurally. However, missing alternative guidance and weak parameter semantics leave the overall context only minimally adequate.

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 0%, so the description needs to supply parameter meaning beyond the schema. It only says searching 'by name' and mentions homonyms; it does not clarify that last_name is required, how first_names is used, or the pagination semantics of page and limit.

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

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

The description clearly states the operation: it searches public French company director mandates by name, and it adds the homonym caveat. It does not explicitly differentiate from the sibling company_fr_directors, so it is clear but not fully disambiguating.

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 simply repeats the main description verbatim and provides no conditions for selecting this tool. The 'Avoid when' section is really a warning about misinterpreting results, not guidance about choosing an alternative tool such as company_fr_verify or company_fr_directors.

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

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

The description adds useful behavioral context beyond the annotations: it discloses source limitations, the possibility of missing or incomplete person/role fields, and the per-call price. The readOnlyHint=false annotation is not contradicted by the description, though the 'Returns' language implies a query operation; the description still refrains from promising no side effects.

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

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

The description is compact, front-loaded with the main purpose, and organized into clear sections for usage, limitations, and pricing. Every sentence adds actionable 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?

For a single-parameter tool with an output schema and existing annotations, the description covers purpose, routing, limitations, and cost. An agent has enough context to decide when to call it and what to expect without needing additional clarification.

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

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

Schema coverage is 100% for the single parameter, including a pattern explanation of 9-digit SIREN or 14-digit SIRET. The description adds only a slight contextual reminder that the input is a French company identifier, which already exists in the schema. This meets the baseline but does not go beyond it.

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

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

The description opens with a specific verb and object: 'Returns publicly listed directors and legal representatives of a French company from a SIREN or SIRET.' This clearly identifies the resource, the type of data returned, and the required input. It also differentiates from ownership-related siblings by explicitly stating that beneficial owners and ownership registers are not covered.

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 concrete negative cases such as needing beneficial owners, shareholder ownership information, or personal contact details. This gives an agent clear routing guidance without needing to inspect 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?

The description adds meaningful context beyond the annotations by stating that results reflect public BODACC dataset availability, that events are factual source records, and that they do not constitute legal advice or a risk score. This is useful for an agent deciding how to frame results. readOnlyHint=false is not contradicted, but the description doesn't elaborate on potential side effects or cost implications beyond the price line.

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 a precise one-sentence purpose, then compact use/avoid/limitations/price sections. Every section earns its place, and the structure makes it easy for an agent to quickly scan for decision-relevant 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 full input schema, output schema, clear usage guidance, explicit sibling alternatives, limitations, and pricing, the description is complete for an agent to select and invoke the tool correctly. No critical information is missing.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters well. The description only lightly reinforces the 'since' parameter as an optional publication-date filter and references limit/date filters generically; it does not add substantial meaning beyond the schema.

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

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

Description starts with a specific verb and resource: 'Returns the latest normalized public BODACC events for a French company from a SIREN or SIRET.' It clearly distinguishes from siblings by explicitly naming company/fr/risk and company/fr/profile as alternatives, leaving no ambiguity about what this tool is for.

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. It tells the agent exactly when to choose this tool (recent normalized BODACC events, optional event timeline) and when not to (risk interpretation, administrative profile), naming the exact sibling tools to use instead.

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

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

The description discloses source-dependent availability, incomplete histories when accounts are missing or confidential, and explicitly disclaims being a credit assessment or audit opinion. These caveats add real behavioral context beyond the annotations. It does not contradict the annotations; readOnlyHint=false is not inconsistent with the described data-returning 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 uses clear labeled sections—summary, use when, avoid when, limitations, price—which front-load the core action and make caveats easy to scan. The writing is efficient, and any repetition of 'available' or 'public' is minor and does not reduce clarity.

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

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

For a one-parameter financial lookup with an output schema present, the description covers what is returned, when to use it, when not to use it, data limitations, and cost. An agent has enough context to decide whether to call this tool and what to expect from the response.

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

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

The single identifier parameter is already fully documented in the schema with a regex and the explanation '9-digit SIREN or 14-digit SIRET'. The description reinforces this by saying the tool works from a SIREN or SIRET, but adds no new format or syntax details. With 100% schema description coverage, the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and object: it returns available public financial data for a French company from a SIREN or SIRET, and explicitly names revenue and net income. It clearly distinguishes this tool from sibling tools like profile and verify by stating what it does and does not provide. This goes well beyond merely restating 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 concrete decision criteria, including normalized multi-year financial history and simple revenue-growth/net-margin calculations. It names sibling tools company/fr/profile and company/fr/verify as the right alternatives for administrative identity or status. This is exemplary 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 well beyond the annotations by disclosing tolerance for temporarily unavailable sources, reported partial coverage, the fact that it aggregates existing services rather than creating new data, and a concrete price. These are important behavioral traits not visible in the schema or annotations.

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

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

The description is structured with clear headings (Use when, Avoid when, Limitations, Price) and every sentence contributes essential operational information. It is detailed without redundancy.

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

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

Given the tool's aggregator complexity, two parameters, many sibling alternatives, and an output schema, the description covers selection criteria, exclusions, failure tolerance, limitations, and cost. Nothing critical is missing for an agent to decide when 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 coverage is 100%, so the schema already documents both parameters well. The description adds useful semantic context by explaining that the included sections correspond to existing Company intelligence services and that availability of sections is not guaranteed, which directly informs how an agent should interpret the 'include' 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 states a specific verb ('Aggregates') and a concrete resource ('existing French company intelligence services into a single call'). It clearly differentiates this aggregator from the dedicated sibling tools by emphasizing selectable sections and tolerance for unavailable sources.

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, including when to call dedicated endpoints directly and when the aggregator's partial-coverage behavior is unacceptable. This gives an agent clear selection criteria versus its 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 provide readOnlyHint=false, but the description adds meaningful behavioral context: it is informational, should not be used for regulated decisions, coverage depends on public sources, and it costs 0.050 USD. These details go beyond the structured annotations and help set expectations about reliability and cost.

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

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

The description is compact and uses labeled sections (Use when, Avoid when, Limitations, Price), which aids scanning. However, the 'Use when' line repeats the first sentence verbatim, wasting words without adding 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?

The presence of an output schema covers return-value expectations, and the description includes limitations and price. However, the complete absence of parameter semantics is a major gap for a tool with only two inputs, and the description does not clarify how to choose between 'identifier' and 'domain'.

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 0%, and the description offers no explanation of the two parameters. The required 'identifier' has a numeric pattern but no stated meaning (e.g., SIREN/SIRET or company registration number), and 'domain' is similarly unexplained. An agent cannot infer correct values from the description alone.

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 ('Aggregates') and names the exact resource categories (public identity, directors, financials, legal-risk, compliance checks) that combine into one KYB dossier. This clearly distinguishes it from sibling tools like company_fr_financials or company_fr_risk, which focus on individual components.

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 only restates the tool's purpose rather than giving situational guidance or pointing to specific siblings. The 'Avoid when' caveat about legal/regulated decisions is useful, but there is no explicit direction for when to choose this aggregate dossier over, say, company_fr_profile or company_fr_compliance.

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

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

Annotations already indicate this is not read-only, not idempotent, and open-world, and the description does not contradict them. It adds a useful limitation (coverage depends on public sources) and the cost per call, but does not disclose rate limits, authentication, or data freshness. With annotations present, this is adequate but not rich.

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

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

The description is short and front-loaded, but the 'Use when' sentence is a verbatim repeat of the first sentence and adds nothing. The remaining metadata lines are compact and useful.

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 endpoint with many sibling tools, the description fails to explain when to choose this over company_fr_search or procurement_fr_search. It covers price and coverage limitations, and an output schema exists, but the missing alternative routing and exact parameter formats make it incomplete.

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 description supplies semantics for family_code, since/until, and department by naming them as filters, which matters because schema description coverage is 0%. However, limit is not mentioned and no concrete value formats for family code or department are given, leaving agents to infer some parameter handling.

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 a concrete resource ('BODACC public announcements'), then names the three filtering dimensions (family, date window, department). This makes the tool's function clear and distinguishes it from broader siblings like company_fr_search or procurement_fr_search, though the first clause largely restates 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?

There is no meaningful when-to-use guidance: the 'Use when' line merely repeats the first sentence. The 'Avoid when' note is a compliance caveat, not a tool-selection criterion, and no alternative tool is mentioned.

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 portrays a pure search/read operation, while annotations declare readOnlyHint=false and idempotentHint=false. If readOnlyHint=false is interpreted as 'not read-only', the description contradicts the annotation and does not disclose what side effects, if any, occur. The coverage caveat and price add some operational context, but they do not resolve the contradiction.

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

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

The main sentence is front-loaded and useful, and the price/limitation lines add value. However, the 'Use when' section duplicates the description exactly, and the 'Avoid when' disclaimer is generic rather than actionable, so 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?

The output schema covers return structure, and parameter constraints are present in the input schema, but the tool still lacks meaningful parameter descriptions and clear selection guidance. The read-only annotation contradiction and the lack of sibling differentiation leave the definition under-equipped for reliable invocation.

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

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

Schema description coverage is 0%, and the description only adds meaning for latitude/longitude via 'geographic coordinates'. It does not explain radius_km, limit, activity_code, or activity_section, leaving an agent without enough semantic grounding for four of the six 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 first sentence states a precise action — searching French companies around geographic coordinates — and identifies the official geolocation endpoint, which clearly signals a location-based lookup. It does not explicitly distinguish itself from siblings like company_fr_search, but the geographic-coordinate framing makes the purpose reasonably 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?

The 'Use when' section merely restates the tool description verbatim, providing no real decision guidance. The 'Avoid when' section is a generic legal disclaimer about credit/fraud decisions rather than guidance on when to prefer another tool, and no alternatives are mentioned.

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 key behavioral constraints: PUBLIC_AID is only produced when a project is provided, tender matching is conservative and relies on CPV codes plus vocabulary, and source coverage may be partial. It also states that aid results are indicative, not official eligibility decisions.

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 into purpose, use-when, avoid-when, limitations, and price, with the main function front-loaded. Every sentence adds useful selection or invocation information without redundancy.

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

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

For a ranked-opportunities tool with a 100%-documented schema and an output schema, the description covers selection context, matching behavior, limitations, and cost. Nothing needed to decide when to call it or how to interpret its output is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds valuable extra semantics by explaining that project context is used for public-aid matching and that PUBLIC_AID output depends on a project being provided. This clarifies the optional project parameter's real effect beyond its schema description.

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

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

The description states a specific verb and resource: it 'Ranks actionable French public funding and open procurement opportunities' for a company based on profile, project, and historical contracts. This distinguishes it from broad tender search and neighboring company_fr_* tools by emphasizing company-specific ranking.

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?

Has explicit 'Use when' and 'Avoid when' guidance, including a named alternative ('use procurement/fr/search') for broad open-tender searches and a clear exclusion for cases where a guarantee is needed. This leaves little 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?

Annotations already cover the safety profile; the description adds useful behavioral context: the endpoint is advisory only, coverage depends on public sources, and there is a per-call cost. No contradiction with annotations is present.

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 useful sections, but the 'Use when' section repeats the opening two sentences verbatim, which is redundant. Limitations and price are valuable, but the duplication prevents a higher score.

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

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

Given the output schema and annotations, the description covers the primary purpose, limitations, and cost. It remains incomplete because neither parameter is explained and no alternative tool is suggested, leaving the agent to infer the role of 'domain' and the identifier.

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 0% and the description says nothing about the 'identifier' or optional 'domain' parameters. The required identifier's SIREN/SIRET semantics and the meaning of 'domain' must be guessed from the schema regex and parameter name, so the description adds no parameter-level meaning.

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

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

States a specific action ('Returns structured public counterparty context') and a clear use domain (automated B2B payment). It also immediately distinguishes itself from decision-oriented tools by saying it never approves or recommends a payment, separating it from siblings like risk, default_score, or 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?

Provides explicit 'Use when' and 'Avoid when' guidance: use before an automated B2B payment, avoid as a legal, regulated credit, or guaranteed fraud-free decision. However, it does not name alternative sibling tools, so it stops short of a 5.

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

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

Annotations are sparse and mostly negative (readOnlyHint=false, idempotentHint=false), so the description carries some burden. It adds useful operational context with 'Coverage depends on the public sources listed for this endpoint' and the per-call price. It does not elaborate on the implications of the non-read-only/non-idempotent hints, but it does not contradict them.

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

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

The core description is one clear sentence followed by useful limitation and pricing notes. However, the 'Use when' line is an exact duplicate of the first sentence, wasting space in a definition that should stay tight.

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 presence of an output schema and a self-describing identifier/scope/limit schema make this a fairly simple tool, and the description covers cost and coverage caveats. It is not fully complete, though: an agent navigating the large sibling list still lacks guidance for choosing this over company_fr_competitors, company_fr_compare, or company_fr_benchmark, and 'administratively comparable' is left undefined.

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 0%, and the description gives no parameter-specific guidance for identifier, limit, or scope. It only implies that the identifier refers to a French company; it does not explain the SIREN/SIRET pattern, the meaning of scope values, or the acceptable limit range beyond what the schema already encodes.

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 concrete action and target: 'Finds administratively comparable French companies for later comparison or benchmarking.' The verb and resource are clear. It does not explicitly distinguish this from sibling tools such as company_fr_compare or company_fr_competitors, so it misses the top score.

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 merely repeats the first sentence verbatim rather than adding selection criteria. The 'Avoid when' section is a legal disclaimer rather than a comparative usage guideline, and no sibling alternatives are mentioned.

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

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

Adds meaningful behavioral limitations beyond annotations: profile fields can be null when the public source does not expose them, and the endpoint does not replace specialized endpoints. It also discloses pricing. While readOnlyHint is false, the description does not affirm mutation, so there is no contradiction; it could have been more explicit about auth/rate limits, but it adds substantive 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 organized into short labeled sections: 'Use when', 'Avoid when', 'Limitations', and 'Price'. Each segment contributes clear selection or invocation information with no filler.

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

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

For a one-parameter tool with an output schema, the description covers when to use, when to avoid, the identifier type, nullability limitations, and cost. It does not spell out authentication or error behavior, but the explicit routing and limitations make it sufficiently 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?

The input schema already covers the single parameter with a description and regular expression ('9-digit SIREN or 14-digit SIRET'), and the description repeats 'SIREN or SIRET' without adding additional format details beyond the schema. Since schema coverage is 100%, 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?

States the exact operation ('Returns the public profile of a French company') and the input key ('SIREN or SIRET'), then enumerates the contained fields (headquarters, activity, legal-form, creation-date, employee-band, establishment-count). This clearly distinguishes it from search, verify, financials, and other sibling tools.

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

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

Contains explicit 'Use when' and 'Avoid when' guidance, routing the agent to company/fr/verify for existence checks and to dedicated endpoints for directors, financials, risk, and compliance. This is exactly the alternative routing an agent needs to select the right 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 annotations, the description adds useful behavioral context: coverage depends on public sources, and there is a per-call price of 0.020 USD via x402. The safety disclaimer about legal/credit/fraud-free use is also valuable. The 'Searches' language is roughly consistent with a non-destructive operation and does not directly contradict the readOnlyHint=false annotation, though it does not explain why that hint 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 compact and front-loaded with the core search purpose. It loses structure points because the 'Use when' section is a verbatim repeat of the opening sentence, which wastes one of its few sentences.

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

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

For a 14-parameter tool with zero schema descriptions and no enums, the description is not complete enough to support correct invocation without additional lookups. The output schema covers return values and the price/limitations notes are helpful, but parameter semantics and code-list sources are missing, and no pointer to sibling tools like list_categories is given.

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 0% across 14 parameters, so the description must compensate but only does so at a high level. It maps broad filter categories (activity, geography, size, certifications) to some parameters, but leaves cryptic parameters like bio, rge, qualiopi, legal_form_code, and employee_band_code without value semantics or code-list guidance, and query/page/limit are not mentioned at all.

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 active French companies using structured public B2B filters such as activity, geography, size and supported certifications.' It makes the tool's scope and filtering nature clear, but it does not explicitly distinguish this from close siblings like company_fr_search or 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?

It provides an explicit avoidance boundary ('Do not use this endpoint as a legal, regulated credit or guaranteed fraud-free decision') and a limitations note, which helps set expectations. However, the 'Use when' line simply repeats the first sentence, and it never names alternatives or says when one of the other company_fr_* tools would be better.

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

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

The description adds meaningful behavioral context beyond annotations: results are inferred matches, coverage depends on listed public sources, and there is a per-call monetary cost. The 'Finds' wording suggests a read-style operation while `readOnlyHint` is false, but the x402 payment side effect helps explain the non-read-only classification, so this is not a clear contradiction.

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

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

The opening sentence is focused and the labeled sections are compact. However, the 'Use when:' line duplicates the first sentence verbatim, wasting a slot that could have provided real usage guidance. The structure is otherwise clean and readable.

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

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

The description covers interpretation caveats and pricing but omits when to prefer this tool over the closely related `company_fr_competitors`. Parameter semantics are under-specified, and while an output schema exists, the missing usage guidance leaves the agent under-equipped in a large sibling namespace.

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 0%, so the description needed to explain the parameters, but it does not. `identifier` is only indirectly referenced as 'the target company' and its SIREN/SIRET pattern is left for the agent to infer; `limit` is entirely undocumented. This is a significant gap for a two-parameter tool.

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 ('Finds companies winning public contracts') and a precise method (CPV segments shared with the target company, DECP public award data). It is clearly about public-contract-derived competitor discovery, which differentiates it from the broader sibling `company_fr_competitors`, though it does not explicitly name that sibling.

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 merely repeats the main description verbatim, so it provides no practical when-to-use guidance. 'Avoid when:' is a data-interpretation caveat rather than a selection criterion, and no alternatives are referenced. With many sibling tools, an agent gets no help deciding between this and `company_fr_competitors` or `company_fr_peers`.

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

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

The description adds useful behavioral context beyond the annotations: it discloses reliance on the DECP dataset, explains that returned totals describe only matched public records rather than all company revenue, and states the per-call price. It does not contradict the annotations; the readOnlyHint=false is plausibly explained by the paid x402 call and open-world data rather than by state 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 description is well-structured and front-loaded with the core purpose, then organized into Use when, Avoid when, Limitations, and Price sections. Every section earns its place and no repetitive or filler content is present.

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

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

Given the simple 2-parameter schema, full schema coverage, an output schema, and annotations, the description fully covers when to use, when not to use, alternatives, data limitations, and cost. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100%, with both identifier and limit already well documented via pattern, description, default, and constraints. The description adds contextual meaning about company identifiers and historical procurement data, but it does not materially extend the parameter semantics beyond what the schema already provides.

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

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

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 differentiates this from sibling tools by naming what it is not for (open tenders) and pointing to alternatives such as procurement/fr/search and company/fr/opportunities.

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 concrete sibling alternatives and the conditions that select them. It also clarifies the tool is for historical awarded contracts, not open tenders or private contracts, leaving little to inference.

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

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

Annotations provide little behavioral signal, so the description carries the burden. It adds meaningful context: 10-year BODACC lookback, reporting when source coverage is insufficient, normalized low/warning/high/unknown levels, and explicit caveats that this is not a credit score or legal opinion. No side-effect statement, but the tool is clearly a detection/read-style service.

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/Avoid/Limitations sections and every part carries useful information. The phrase 'not a credit score' is repeated three times, which is slightly redundant but reinforces an important boundary.

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 tool with an output schema available, the description covers purpose, selection criteria, alternatives, limitations, pricing, and a high-level description of the result. Nothing needed for correct invocation is missing.

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

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

Schema coverage is 100% and the single parameter 'identifier' is already described with a pattern and SIREN/SIRET explanation. The description adds no further parameter-level semantics beyond implying the company is French, 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?

States a specific verb ('detects') and resource ('public legal-risk signals for a French company'), with concrete examples such as insolvency proceedings and deregistrations. Also explicitly excludes credit scoring, which helps distinguish this tool from financial-risk 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?

Contains explicit 'Use when' and 'Avoid when' sections with concrete conditions. It names the alternative for sanctions/blacklist screening (company/fr/compliance) and lists excluded use cases, so an agent can route correctly without inference.

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

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

The description adds useful behavioral context beyond annotations: matching quality is source-dependent, result ordering is not guaranteed, and the response is a search result set rather than a full company dossier. The readOnlyHint=false is not explicitly contradicted since the description never claims a guarantee of no side effects.

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

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

The description is well-structured and efficient: a front-loaded summary sentence, then clear Use/Avoid sections, limitations, and pricing. Every sentence earns its place and no filler is present.

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

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

For a simple three-parameter search tool with an output schema, the description covers purpose, alternatives, limitations, and pricing. If anything, it is more complete than most tool descriptions of this complexity.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds minor semantic color by clarifying that query can be a name, legal name, SIREN, or SIRET, and that postal_code is a location filter, but it does not provide substantial meaning beyond the schema.

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

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

The description uses a specific verb ('Searches') and identifies the exact resources: French companies by name, SIREN, SIRET, or location criteria. It also distinguishes itself from specialized endpoints by positioning it as a candidate-identifier search tool.

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

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

The description provides explicit 'Use when' and 'Avoid when' guidance, naming concrete alternatives such as company/fr/verify and company/fr/intelligence. An agent can reliably decide when this tool is appropriate versus when a sibling should be used.

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?

It adds useful behavioral context beyond annotations: evaluation happens at request time, it is not a subscription service, coverage can be partial when an underlying data source is unavailable, and it is not a general predictive risk model. The description's 'detects' language is consistent with annotations; no contradiction is apparent.

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 Use when, Avoid when, Limitations, and Price, and it front-loads the core purpose. However, the list of signal families is repeated nearly verbatim in the first sentence and the 'You want to detect supported signals...' sentence, which adds 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?

For a single-parameter endpoint with a provided output schema, this description covers selection criteria, exclusions, limitations, pricing, and request-time behavior. Nothing essential is missing for an agent to decide whether and how to call this tool.

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

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

There is only one parameter, and the schema already fully describes it with a pattern and description, giving 100% schema coverage. The description adds only broad context about French company data, so the high-coverage 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: 'Detects explainable business signals from available French company data,' naming concrete signal families. It also contrasts itself with raw-record siblings by saying these are signals derived from existing public data rather than raw records from one source. This makes the tool's scope unambiguous.

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

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

The description has explicit 'Use when' and 'Avoid when' sections, directing agents to the specialized endpoint for raw records and ruling out use cases like continuous monitoring. This is actionable routing guidance that clearly distinguishes the tool from 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?

Annotations provide limited behavioral signal (readOnlyHint=false, idempotentHint=false, destructiveHint=false), and the description adds valuable context: it is not KYC, it only covers public administrative status, and returned fields depend on what the source exposes. It also discloses the paid nature via price, which is useful beyond annotations. No contradiction with annotations is present.

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, and price. Every section earns its place by helping an agent decide when to use the tool, what to expect, and what not to expect. The most important functional statement is front-loaded.

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

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

Given a single required parameter, a complete output schema, clear usage guidance, explicit exclusions, and limitations, nothing critical is missing. The description adequately covers what an agent needs to select and invoke the tool correctly without duplicating 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?

The schema already fully documents the single 'identifier' parameter with pattern and a description ('9-digit SIREN or 14-digit SIRET'). The description repeats this concept but does not add meaningful new detail about formatting or edge cases beyond the schema, so the baseline schema coverage 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 uses a specific verb ('Verifies') and names the exact resource: existence and current administrative status of a French company or establishment from a SIREN or SIRET. It also distinguishes itself from siblings by explicitly pointing to company_fr_search for name-based lookup and specialized endpoints for directors, financials, and 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 conditions: having a SIREN/SIRET and needing existence/status confirmation before automation. The 'Avoid when' section names alternatives explicitly, including company/fr/search for identifier discovery and specialized endpoints for other data types, so an agent knows exactly when NOT to invoke 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?

There are no annotations, so the description itself must indicate side effects. It does so with 'This tool does not execute the endpoint,' which tells the agent this is a metadata lookup rather than a live API call. It does not discuss authorization or rate limits, but for a read-only describe operation the non-execution statement addresses the main behavioral risk.

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

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

Two short sentences, with the return-value list front-loaded and the non-execution caveat placed immediately after. No filler or repetition of schema content.

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

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

With a single well-documented parameter and an output schema present, the description covers what the tool returns and the critical non-execution caveat. It stops short of referring the agent to search_apis for discovery or listing error behavior, but these are minor for this simple metadata tool.

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

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

The input schema already documents the endpoint parameter with 100% coverage, including the need for a canonical name exactly as published. The description only reinforces 'one ... endpoint' and adds no new parameter-level semantics. A baseline of 3 is appropriate when the schema carries the load.

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

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

Description opens with 'Return method, executable URL, schemas, price, coverage and documentation for one HelpMyAgent endpoint,' which names a specific verb, resource and output contents. The final sentence, 'This tool does not execute the endpoint,' separates it from data-returning siblings. This is precise and not a tautology.

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

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

The phrase 'for one HelpMyAgent endpoint' gives clear context: this is for a single canonical endpoint, not for discovery or bulk operations. 'This tool does not execute the endpoint' is an explicit when-not, though the description does not name alternatives like search_apis for endpoint discovery. Usage context is clear but sibling routing is left implicit.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It states the operation is a read-only 'List' of public data and specifies the returned information includes category names and endpoint counts, which is sufficient for this simple tool.

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

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

A single sentence conveys the resource, scope, and output content without any redundant wording. Every part of the description is useful.

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 is simple, has no parameters, and the description covers what it lists and what it returns. With an output schema present, nothing necessary 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 tool accepts zero parameters, so parameter semantics are trivially complete. The description adds value by explaining what will be listed, even though no input schema details are needed.

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 ('List') and a specific resource ('public HelpMyAgent API categories') with an additional detail about the number of published endpoints. This clearly differentiates it from sibling tools focused on company data, procurement, or API 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 implies the tool is for browsing categories and their endpoint counts, but it does not explicitly state when to prefer this over alternatives or mention any exclusions. For a zero-parameter tool this is a minor gap, so the implied usage is enough for a baseline score.

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

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

The description adds meaningful behavioral context beyond the annotations: coverage limited to BOAMP, at least one of query/department/buyer is required, and deadlines/notice details can change at the source. The readOnlyHint is false but the description implies a search operation; this is ambiguous but not a direct contradiction.

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

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

The description is concise, well-structured, and front-loaded with the main purpose. Every section—Use when, Avoid when, Limitations, Price—earns its place 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?

Given the presence of an output schema and detailed annotations, the description fully covers selection criteria, exclusions, limitations, required parameter constraints, and even cost. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100%, so the schema already fully documents all five parameters. The description mentions keywords, department, buyer, and minimum deadline, which adds framing but no additional semantic detail beyond the schema.

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

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

The description states a specific verb ('Searches') and resource ('currently open French public procurement opportunities' from BOAMP), and clearly distinguishes this from awarded-contract tools by naming the sibling alternative. An agent can tell exactly what this tool does.

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 a specific sibling tool for awarded contracts, and identifies coverage limitations. This leaves 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?

There are no annotations, so the description carries the burden of behavioral disclosure. It explicitly discloses that the tool 'returns discovery metadata only,' which is a meaningful guarantee that it does not execute or invoke the discovered APIs. It does not mention authentication, rate limits, or pagination, but for a read-oriented discovery tool the key behavioral trait is 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 two concise sentences with the core behavior front-loaded and the critical return-type caveat immediately after. Every word earns its place and there is no redundant restating of the tool name.

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

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

Given a fully documented input schema and the presence of an output schema, the description is largely sufficient for an agent to invoke the tool correctly. The only notable gap is the absence of explicit guidance on when to choose this tool over sibling discovery tools such as list_categories or describe_api.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters: query, country, category, and max_price. The description's phrase 'matching an agent task or intent' loosely aligns with the query parameter but adds no substantial meaning beyond the schema.

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

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

The description uses a specific action and resource: 'Find HelpMyAgent APIs matching an agent task or intent.' It also clarifies the tool's scope by stating it 'returns discovery metadata only,' which separates it from API execution or detail-lookup tools like describe_api.

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

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

The description gives a clear usage context: an agent should use this when it needs to find HelpMyAgent APIs relevant to a task or intent. It does not explicitly name alternatives or exclusion criteria, so it stops short of full routing guidance, but the intended use case is evident.

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