TrustyData

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

With no annotations, the description discloses key behaviors: uses OSM data (requires ODbL mention), requires Business plan, and returns specific output components. Lacks details on read-only nature, rate limits, or error handling, but the essential safety and attribution info 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?

Two sentences: first packs core functionality and output, second gives alternative usage. No filler, information density is high, and key points are 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?

Covers main inputs (origin/destination), outputs, plan, and attribution, but omits input format details (partial coordinates, XOR requirement) and any response structure. With no output schema and no annotations, the description should be more explicit about input constraints.

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

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

Schema coverage is 0%, yet the description only mentions 'origine' and 'destination' generically, failing to explain the lat/lon/address structure or XOR constraint. The schema itself provides some hints (min/max for lat, minLength for address), but the description adds no value beyond naming the parameters.

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

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

The description clearly states the tool computes a complete road route (car, France, OpenStreetMap) and lists output components (distance, duration, steps, bounding box, geometry). It distinguishes from sibling route_matrix by directing simple bulk distances to the latter.

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 guidance: 'Pour de simples distances en masse, préfère route_matrix' provides a when-not-to-use and alternative. Also specifies plan minimum (Business) and OSM attribution requirement, setting clear usage constraints.

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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states it retrieves details (implying read-only) but omits information about permissions, rate limits, or what constitutes 'détail complet'. The inclusion of 'Plan minimum : Discovery' is unclear and adds no value.

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 long, efficiently stating the core purpose and context. The 'Plan minimum' phrase could be removed without loss, but the description remains front-loaded and reasonably concise.

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 explains the tool's role as a drill-down but fails to describe the output format or field details, which is significant given the absence of an output schema. It also does not mention any limitations or prerequisites beyond the ID source.

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 has no parameter descriptions (0% coverage), so the description compensates by explaining that address_id comes from search or verify, giving meaningful context about its source and format.

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 complete address details using an ID from search_address or verify_address, distinguishing it as a drill-down tool distinct from sibling search/verify tools.

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

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

The description explicitly specifies where to obtain the required address_id (from search_address or verify_address) and frames the tool as a drill-down, though it does not explicitly state when not to use it or compare with alternatives.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It thoroughly covers response structure (root vs unite_legale), plan-dependent field availability, the caveat that absent fields may be out-of-plan, and the semantics of opposition_prospection including the distinction between null and false. This is exemplary transparency for a data retrieval tool.

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

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

The description is relatively long but information-dense. It is logically structured: identifier usage, response layout, plan tiers, field absence semantics, and a privacy flag caveat. Every sentence adds value, though a bit more concision could improve scannability.

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

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

Despite lacking an output schema, the description provides a complete picture: what the response contains, how it varies by plan, how to interpret absent fields, and where special data (opposition_prospection) is served. It successfully covers all key contextual aspects for a tool with a single parameter and no structured output metadata.

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 only provides company_id as a string with 0% description coverage. The description compensates completely by explaining that the same identifier accepts either a 14-digit SIRET (returns that establishment) or a 9-digit SIREN (returns the headquarters), adding precise 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 clearly states the tool provides a detailed record of a French company or establishment (SIRENE base). It goes beyond a simple identifier by explaining the dual SIRET/SIREN usage, and its focus on retrieving detailed records distinguishes it from sibling search tools like search_company.

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

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

The description clearly implies when to use the tool: when you have a SIRET or SIREN identifier. It also explains the plan-level constraints and the meaning of the input. However, it does not explicitly mention alternatives (e.g., use search_company if you lack an identifier), so it falls short of a 5.

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

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

With no annotations provided, the description carries the full burden. It reveals that the tool computes a matrix without geometry (so no route shapes), is limited to car travel, requires a minimum plan, and mandates attribution. It does not mention read-only or mutation status, but the function is clearly a read operation.

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 convey all essential information: purpose, constraints, output details, plan requirement, and attribution. No wasted words.

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

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

Given no output schema and minimal parameter descriptions, the description covers the key aspects: what it calculates, limits, mode, network, output type, and legal requirements. It could mention that the output is a matrix of distances/durations, but that is implied by 'matrice de distances et durées'.

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%, meaning the description adds no information about parameters. Though the schema itself has some descriptions in the address field, the description does not explain the origins and destinations structure or the XOR relationship. The agent would need to infer from schema 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 clearly states it calculates a matrix of distances and durations between N origins and M destinations up to 25x25, for car travel on the France network. It distinguishes from sibling tools like compute_route which computes a single route.

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 constraints (max 25x25, car only, France, no geometry, plan requirement, OSM attribution) but does not explicitly say when to use this tool versus alternatives like compute_route. The usage context is implied but not directly stated.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains that results are ranked by relevance, includes scoring, and describes the three postal lines per candidate. It could mention error handling or more about response structure, but for a search tool this is fairly transparent.

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 four sentences, each adding value: main purpose, alternative tool, output fields, and plan requirements. It is front-loaded with the core function and avoids unnecessary detail.

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 moderate complexity with three parameters and no output schema. The description covers the primary use case, alternative tool, result fields, and plan tiers. It lacks explanation of 'limit' and 'details', but overall it provides sufficient context for an agent to decide when to use it.

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

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

Schema description coverage is 0%, so the description must clarify parameters. It adds meaning to 'query' by describing it as free text (even partial), but does not explain 'limit' or 'details' at all. With only one of three parameters semantically described, the description insufficiently compensates for the schema 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 clearly states the tool searches French addresses from free text and returns ranked candidates. It uses specific verb 'Recherche' and resource 'adresses françaises', and distinguishes itself from verify_address.

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

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

Explicitly says 'Pour confirmer UNE adresse précise, préfère verify_address', providing an alternative for a different use case. Also notes minimum plan Discovery, giving context on subscription requirements.

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 bears full responsibility and excels: it discloses that results are always SIRET, explains grouping behavior, warns about 'classement_pertinence' affecting best match, clarifies that 'diffusible: false' is legal masking not missing data, and specifies plan restrictions. No contradictions.

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

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

The description is packed with useful information in a single paragraph, but lacks visual structure (e.g., bullet points). However, every sentence adds value, and it is front-loaded with the main purpose. Could be slightly more concise, but overall effective.

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

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

Given the complexity (13 params, no output schema, no annotations), the description covers essential behavioral aspects and usage nuances. It explains the establishment-vs-company subtlety, result ordering, data masking, and plan requirements. It does not describe the response format, which would be helpful given no output schema, but remains fairly complete for the tool's intended use.

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 must compensate. It lists and explains many parameters (query, siren, city, postal_code, naf_code, lat/lon/radius_m, group_by_company) and their effects on behavior. However, it does not systematically cover all 13 parameters (e.g., page, per_page, status, address are not explicitly described), leaving some gaps.

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

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

The description clearly states the verb 'Recherche' and resource 'entreprises et établissements français dans la base SIRENE', listing multiple search criteria. It distinguishes from sibling tools like get_company_details by mentioning it as the next step, and implicitly differentiates from other search tools by focusing on company data.

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 when-to-use guidance, including that results are always establishments, how grouping works, interpretation of 'classement_pertinence', handling of 'diffusible: false', the authority of empty lists, and plan requirements for proximity search. It directs to use get_company_details for more details.

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?

No annotations provided, so description carries full burden. It explains that the tool searches and returns commune details (code INSEE, postal code, population, etc.), and notes that department names are normalized. However, it does not discuss pagination, rate limits, or data freshness, leaving some behavioral aspects implicit.

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 numbered usage modes and an example, making it easy to scan. Each sentence adds value, but the length is slightly long for a tool with many parameters; some details could be tightened.

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

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

Given 10 parameters, no output schema, and 0% schema coverage, the description provides useful context but lacks details on pagination (the limit parameter is not explained) and the exact return structure (e.g., whether it returns a list or single object). The mention of 'Plan minimum : Discovery' is ambiguous.

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 has 0% description coverage on parameters, so description must compensate. It explains key parameters like query, department_code, population_min, population_max, and mentions postal_code and region_code. However, some parameters (e.g., limit, details) are not fully detailed, and INSEE code is referenced as a query option but is not in the schema.

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

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

The description clearly states it searches and lists French communes, with two distinct modes: finding a specific commune via query parameters (name, postal code, INSEE code) and filtering communes by department/region with optional population range. This specificity differentiates it from sibling tools like search_address or search_company.

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

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

Explicitly describes when to use each mode with concrete examples (e.g., 'communes du Pas-de-Calais de plus de 100 000 habitants') and recommends preferring department_code over department_name. Provides clear guidance on parameter selection, though it does not explicitly exclude 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?

Despite no annotations, the description fully discloses behavior: return fields (distance_m, enrichments like statistical_grid), pagination details (offset, total_estime, tronque flag, 5000 address cap), and address resolution. No contradictions.

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

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

Exceptionally concise and well-structured. First sentence defines purpose, followed by logical groupings: center specification, output details, pagination instructions. Every sentence adds value with no 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?

Covers return fields (distance_m, enrichments, resolved address), pagination behavior, and radius constraints. Lacks explicit error handling for invalid parameter combinations and doesn't mention the limit parameter. Overall, sufficient for a search tool but could be slightly more thorough.

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 has 0% description coverage, but the description explains key parameters: radius_m range, mutual exclusivity of address vs lat+lon, and offset for pagination. However, limit and default values are not explicitly described, leaving a minor 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?

Clearly states the tool searches addresses from the official BAN repository within a radius, sorted by distance. Distinguishes from sibling tools like search_address and verify_address by specifying the proximity search and the resolution of free addresses.

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 usage guidance: the central point must be either a free address or lat/lon pair, never both. Includes pagination advice (use offset=next_offset, reduce radius if truncated) and mentions the minimum plan requirement (Growth).

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 fully carries the burden: it details the response structure (verdict, canonical lines), plan-dependent data (GPS, IRIS, INSEE stats), and a per-call limitation. It also implies a read-only verification without stating it.

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

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

The description is dense and front-loaded, with the core purpose in the first sentence and additional details organized logically. Every sentence adds value.

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 thoroughly explains the output format, plan tiers, and constraints. Since there is no output schema, this compensates well, though error handling or authentication are not mentioned.

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 adds only a constraint 'une adresse par appel' related to the address parameter, but says nothing about 'details' or 'max_results' parameters, leaving their semantics unclear given the schema has no descriptions.

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

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

The description clearly states the tool verifies and normalizes French postal addresses against the official BAN, returns a match verdict and canonical address lines. This distinguishes it from sibling tools like search_address or get_address_details.

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 clear context for when to use the tool (to validate/normalize an address) and even gives a pragmatic guideline to use the returned lines as-is. It does not explicitly exclude alternatives, but the purpose is distinct enough.

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