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

With no annotations provided, the description must carry behavioral disclosure. It adds useful traits: the operation is offline ('no API call') and translates several code categories into plain French. It stops short of describing error behavior, output format, or what happens for unsupported codes, so it 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?

Three short sentences with no redundancy. The primary action and scope are front-loaded, followed by an important execution detail (offline) and a useful usage cue. 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?

This is a minimal single-parameter tool with no output schema. The description covers the code categories, the offline behavior, and the high-level output ('plain French'), which is enough for an agent to decide and invoke correctly. Minor gaps like invalid-code handling do not significantly reduce completeness.

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

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

Schema coverage is 100% and the parameter already includes examples ('62.01Z', '5710', '12', 'A', 'PME'). The description adds semantic meaning by classifying these examples into NAF, legal form, workforce bracket, and administrative status, helping the agent understand what value to pass.

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 ('Translate') and a clearly bounded resource: NAF activity codes, legal forms, workforce brackets, and administrative statuses. This is immediately distinguishable from the sibling tools (search_companies, get_company, list_establishments), which are about company/establishment data rather than code decoding.

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

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

It gives clear context for when to use the tool ('Use this instead of guessing what a code means') and adds the offline constraint. However, it does not explicitly name alternatives or state when not to use it, though the sibling tools are sufficiently different that the guidance is adequate.

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 provided, the description carries the behavioral disclosure burden. It goes beyond a simple 'get' by listing the returned fields and, notably, explaining the `missing` array and warning not to fabricate missing data — important behavioral guidance. It could mention error handling or data freshness, but it is still substantially transparent for a read-only lookup.

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, with the core purpose stated first and the important `missing`-array caveat in the second sentence. Every sentence adds value and there is no redundant or filler text.

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

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

For a single-parameter lookup tool with no output schema, the description is complete: it explains what is returned, mentions the caveat about missing fields, and gives the identifier formats. The agent has enough context to call the tool correctly and interpret 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?

Schema description coverage is 100%, so the schema already fully documents the `identifier` parameter including formats and space tolerance. The tool description does not add parameter-level detail beyond that, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool retrieves a 'full profile for one company' by SIREN or SIRET, naming the returned data categories (legal form, activity, workforce, etc.). This distinguishes it from the sibling tools, especially search_companies, by emphasizing lookup by unique identifier rather than 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 makes the intended usage context clear: use this when you have a SIREN or SIRET and need a single company's full profile. It does not explicitly exclude the sibling tools or state when to prefer search_companies, but the identifier-based lookup is strongly implied.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It meaningfully warns that the registry may return matching establishments rather than an exhaustive list and introduces the `complete` flag to indicate completeness. It also discloses the ordering rule (headquarters first), which adds useful non-obvious behavior.

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

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

The description is two sentences with no filler. The core action and ordering rule are front-loaded, and the critical exhaustiveness caveat follows immediately. Every word earns its place.

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

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

For a simple one-parameter tool with no output schema or annotations, the description covers the main behaviors an agent needs: what is returned, the ordering, and the completeness caveat. It would be slightly more complete with explicit return-value details, but the description is largely sufficient for correct invocation.

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

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

The single parameter `siren` is already fully documented in the schema with 'SIREN, 9 digits', so schema coverage is 100%. The description repeats the SIREN concept without adding substantive new parameter detail, which aligns with the baseline score of 3.

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

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

The description clearly states that the tool lists a company's establishments for a SIREN and notes that headquarters appear first. The resource and scope are specific, and the tool is clearly distinct from the sibling tools by focusing on sites rather than company records. However, it does not explicitly name or contrast itself with siblings like get_company or search_companies.

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 should be used when an agent needs establishment-level data for a given SIREN, rather than company-level details or search results. It does not explicitly provide when/when-not guidance or mention alternative 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?

With no annotations, the description carries the behavioral burden. It discloses fuzzy behavior, compact summary output, and response-depth differences versus get_company. It does not mention pagination behavior or the active_only default, but the search-oriented nature makes the read-only behavior clear.

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

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

Three efficient sentences front-load the search scope, provide a concrete example, route to the correct sibling, and explain filter semantics. No wasted words or repetition of the schema.

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

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

The description covers expected behavior, output granularity, filter semantics, and an alternative tool. It lacks detail on pagination, defaults, and the role of list_establishments, but for a search tool with a small schema these are minor 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 coverage is 71%, and the description adds semantics beyond the schema by showing that the query can be a fuzzy multi-word phrase and that filters are optional and AND-combined. Page and limit are not described in prose, but their names and defaults largely make their behavior clear.

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

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

The description states a specific action and resource: finding French companies by name, trade name, acronym, or officer name. It also clarifies fuzzy matching and explicitly distinguishes itself from get_company, which returns the full 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 gives clear guidance to call get_company when the full profile is needed, and states filters are optional and AND-combined. It does not mention when to prefer list_establishments or explain_code, but the search-versus-lookup distinction is reasonably clear.

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