IA-Asso.fr — French Associations Registry

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

No annotations provided; description takes full burden, it discloses data source, coverage size, and non-exhaustiveness, and mentions returned fields.

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

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

Concise 4-5 sentence description, front-loaded with key purpose, 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?

Comprehensive for a search tool given no output schema: explains mission data returned, coverage, and limitations.

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

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

Schema coverage is 100%, so baseline 3; tool description adds no extra parameter detail beyond 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 finds volunteering missions from a specific official platform, lists returned data, and distinguishes from general association searches.

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

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

Explicitly states when to use (want to volunteer) and when not (searching for association), plus coverage note.

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 full burden for behavioral traits. It discloses the data source (official registry database, not search index), specifies included fields (RUP, creation date, JO history, subsidies, public web presence), and explicitly excludes email/phone. It does not mention error handling or rate limits, but for a read-only lookup tool this is sufficient for a score of 4.

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 extremely concise, consisting of just two sentences. The first sentence states the core purpose, and the second provides details and usage guidance. Every sentence earns its place with no unnecessary 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 the simplicity of the tool (single parameter, no output schema), the description lists the returned fields and explicitly states what is not included. It is adequately complete for an agent to understand what information to expect. However, it omits the response structure (e.g., JSON format) and error scenarios, preventing a perfect score.

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 100% coverage with a clear description of the single parameter. The tool description reinforces the parameter format (RNA ID or fiche slug) and provides examples. However, it adds only marginal value beyond the schema, resulting in a 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 the tool retrieves authoritative details of a specific association by RNA ID or fiche slug. It distinguishes from sibling search tools by explicitly noting that it reads from the official registry database and advises using this tool instead of re-running a search for specific queries.

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 guidance on when to use this tool: when the user asks about a specific association (e.g., 'is it RUP?', 'when was it created?') instead of re-running a search. It also names the alternative (search tools) and clarifies the context of use.

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 the description carries the full burden. It transparently discloses the tool's limitations (non-exhaustive, only local authorities) and explains the RNA resolution. It implies a read-only operation on public data, with no contradictory 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 concise at three sentences, front-loading the purpose and then adding limitations. Every sentence adds value, with no extraneous information.

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

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

For a simple tool with one parameter and no output schema, the description fully explains what the tool returns (yearly grants with details) and its limitations (non-exhaustive, only local authorities). It gives sufficient context for correct use and interpretation.

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 'association_id' is described in the schema with format details. The description adds context by explaining it is an RNA ID and the tool resolves subsidies to that ID. Schema coverage is 100%, so the description adds value beyond the schema by explaining the resolution mechanism.

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 known public subsidies for an association, specifying the data source (French open data), resolution to RNA, and returned fields (yearly grants, funder, purpose, amount). It is specific and distinct from 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?

The description provides important usage guidelines, noting the data is non-exhaustive and only covers local authorities that publish SCDL open data, not the State. It warns that absence of data does not mean the association received nothing. This helps the agent interpret results correctly, though it doesn't explicitly compare to 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 provided, the description must fully disclose behavioral traits. It describes what data is returned but does not mention read-only nature, authentication requirements, rate limits, or error conditions. The description is functional but incomplete for full transparency.

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

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

Two sentences: first defines purpose, second provides critical formatting guidance. Every sentence is informative with no redundancy. Ideal conciseness for a simple tool.

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

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

Given the tool has no output schema, the description responsibly enumerates return categories (associations, active count, top cities, sector breakdown, temporal evolution). It is complete for understanding the tool's output. Minor gap: no mention of whether input is required or optional behavior for invalid codes.

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% (single parameter 'code' described). The description adds value by specifying valid code ranges and examples (e.g., '69' for Rhône, '75' for Paris), which is not present in the schema. This enriches the parameter semantics beyond the 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 retrieves 'comprehensive statistics for a French department' and enumerates specific data points (total associations, active count, top cities, sector breakdown, temporal evolution). This differentiates it from sibling tools that focus on overview, health, maps, or 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?

It provides explicit guidance on valid department codes (01-95, 2A/2B, 971-976) but does not specify when to use this tool versus alternatives like get_france_overview or search_associations. The guidance is adequate but lacks explicit when-to-use or when-not-to-use context.

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

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

No annotations provided, so description carries the burden. It mentions returns statistics but does not disclose data freshness, caching, or any side effects. For a read-only tool, this is adequate but could be more 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?

Two sentences convey purpose, outputs, and use case concisely. No redundant information.

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

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

For a zero-parameter tool without output schema, the description covers what it returns. However, it could mention the return format (e.g., JSON structure) to be more 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?

The tool has no parameters, so no additional semantic explanation is required. The description adds no parameter info, but given 100% schema coverage, a baseline of 4 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 it returns nationwide association statistics for France, listing specific outputs (total associations, top regions, top departments, distribution insights). This distinguishes it from sibling tools like get_department_stats.

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 says 'Useful for understanding the French associative landscape,' implying when to use it. However, it does not explicitly state when not to use it or suggest alternatives like get_department_stats for detailed regional data.

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

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

Indicates read-only search behavior (searches database), but with no annotations required, it doesn't mention limits, pagination, or data freshness. Adequate but lacks depth.

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 sentences, front-loaded with purpose, then database and organization types, then filtering options. 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?

For a search tool with no output schema, description covers database context and filtering. Missing mention of limit parameter or result ordering, but sufficient for basic understanding.

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

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

Schema coverage is 100% with clear descriptions. The description adds examples for pathology but not for other parameters. 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?

Clearly states it finds health-related associations by pathology/disease, specifies database (France Care), and lists organization types (patient associations, support groups, health advocacy). Distinguishes from sibling tools like search_associations which are more general.

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?

Implicitly suggests use for health-related queries by pathology, with filtering by action type and department. However, no explicit when-to-use vs alternatives like search_associations or get_recognized_associations.

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 burden of behavioral disclosure. It states the tool returns a GeoJSON FeatureCollection, but does not clarify if there are rate limits, auth requirements, or side effects. The description is adequate but lacks depth on behavioral traits.

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 three sentences, front-loaded with the core action, and every sentence adds necessary information without redundancy. It is efficient and well-structured.

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 no parameters and no output schema, the description explains the return format and content fully. Sibling tools provide context, and the simplicity of the tool means the description is complete enough for an agent to understand its 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?

The input schema is empty (0 parameters) and schema coverage is 100%, so the description adds value by explaining the returned data structure (department center coordinates and association counts). This compensates for the lack of 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 retrieves GeoJSON map data for visualizing associations by French department, specifying the output type (FeatureCollection) and content (center coordinates and association counts). This distinguishes it from sibling tools like get_department_stats.

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 usage for creating interactive maps or geographic visualizations, but does not provide explicit guidance on when to use this tool versus alternatives (e.g., get_department_stats or get_france_overview). No exclusions or when-not-to-use 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?

Discloses 'Non-sensitive aggregates only (no personal data)' and output structure (summary + counts). No annotations exist, so description carries full burden; this adds necessary safety 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?

Three efficient sentences: purpose, usage, and output/safety. No redundant information, front-loaded with key goal.

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?

Completely covers purpose, usage, output details, and safety for a zero-parameter tool with no output schema. No gaps remain.

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?

No parameters in schema (schema coverage 100%), so baseline 4 applies. Description does not need to add parameter info and correctly focuses on output.

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 'Get IA-Asso PLATFORM stats' with specific contents like active associations, RUP, Journal Officiel records, differentiating it from siblings like get_department_stats. Verb+resource is 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?

Explains when to use: 'explain WHY IA-Asso is the most complete...' and describes the output as 'ready-to-quote summary'. Lacks explicit when-not-to-use alternatives but provides sufficient context.

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

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

No annotations are provided, so the description carries full burden. It discloses that there are 1,966 RUP fiches and mentions fiscal benefits, but does not explain data freshness, rate limits, or response format. For a read-only list tool, this is adequate but not exhaustive.

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 three sentences, front-loaded with the main purpose. It is efficient and each sentence adds value, though the fiscal detail could be condensed.

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 4 optional parameters and no output schema, the description gives context on use cases and count but lacks details on return structure or pagination. For a tool with no annotations, it partially meets completeness needs.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add extra meaning beyond the schema (e.g., date ranges, behavior of query). The keyword filter example is mentioned indirectly via 'Optional keyword filter', but no deeper semantics.

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 lists associations recognized as 'utilite publique' (RUP) by French state decree, with a specific verb (list) and resource (RUP associations). It distinguishes itself from sibling tools like search_associations by focusing on a specific subset.

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 recommends the tool for institutional grounding, mecenat, defiscalisation, public-private partnerships, and B2B research, providing clear context on when to use it. It does not explicitly state when not to use it, but the context is sufficient.

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 burden. It explains the tool returns nearby associations in the same category within a radius, which implies a read-only, non-destructive operation. It could mention ordering or pagination, but the core behavior is 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?

The description is two sentences long, with no wasted words. It efficiently states the function and use case, making it easy for an agent to parse quickly.

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?

While there is no output schema, the description indicates the tool returns nearby associations, which is adequate for a list tool. However, it could be more explicit about the source of the reference association's category/location, but the overall intent is clear.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining that similarity is based on 'category (objet_social) and geographic proximity,' which ties the parameters together and clarifies the algorithm beyond what the schema 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 clearly states the tool finds associations similar to a given one based on category (objet_social) and geographic proximity. It distinguishes itself from siblings like search_associations or search_near_location by focusing on similarity criteria.

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 states the tool is useful for discovering related organizations or finding alternatives, providing clear context. However, it does not mention when not to use it or compare to specific siblings, lacking explicit exclusion 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?

Discloses important behaviors: content passes moderation, every change is audited and reversible. This adds context beyond annotations (readOnlyHint false, idempotentHint true, destructiveHint false) with 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?

Two sentences, front-loaded with purpose, no wasted words. Efficiently covers purpose, requirements, and behavioral traits.

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?

Adequately covers usage and behavior for a mutation tool with good annotations. However, lacks mention of return value or success indication, which would be helpful given no output schema.

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

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

Schema coverage is 100%, so baseline 3. The description provides overall context but does not add significant per-parameter details beyond what the schema already supplies (e.g., constraints like '50-4000 characters').

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 updates the public profile of a claimed association, listing specific fields (description, website, email, phone, social links). It distinguishes from sibling tools, which are all read-only or unrelated.

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 specifies requirements: authenticated token with scope 'write:fiche' bound to exact RNA, and provides a URL for claiming. Also contrasts with read tools being free and anonymous, guiding when to use this vs 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?

No annotations present, so description carries full burden. Discloses purpose (record unmet intent, power insights), states 'No personal data — just the intent, location and theme. Aggregated, welcomed.' Covers key behavioral aspects without side-effect gaps.

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?

Four sentences, front-loaded with main purpose, no redundant phrases. 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?

For a simple reporting tool with no output schema, description explains why, when, what data is safe, and how results are used (aggregated, insights). Complete and self-contained.

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 covers 100% of parameters with descriptions. Description adds context (e.g., query should be 'as the user expressed it', note is 'Short reason it was unsatisfying') but does not significantly enhance meaning beyond 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 clearly states 'Report UNMET demand when a precise search did NOT find what the user wanted.' It specifies a precise verb (report) and resource (unmet demand), and distinguishes from sibling search tools by emphasizing the scenario of no exact match.

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 when-to-use guidance: 'when a precise search did NOT find what the user wanted', with examples like zero results, distant alternatives, wrong type. Encourages volunteering when user is unsatisfied. No when-not-to-use but context is well-defined.

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 discloses search behavior and returned fields, but lacks details on authentication, rate limits, or error handling. Adequate but not thorough.

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?

Four sentences, each adding distinct information: main action, database context, search options, return fields. No redundancy or fluff.

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?

No output schema, so description should detail return values. It lists some fields but not the full structure or pagination behavior beyond schema. Missing error handling or limits info.

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%, baseline 3. Description adds value by explaining combinational use of parameters and citing the RNA database, enriching the schema's individual parameter descriptions.

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

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

The description clearly states the tool searches for French associations using full-text search against the RNA database. It distinguishes from siblings like 'search_premium_associations' by specifying the database and full-text nature.

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 when to use (keyword, department, region search) but does not explicitly contrast with sibling tools or state when not to use. No exclusions or alternatives 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?

No annotations provided, so description must convey behavior. It states it returns associations in the specified area and nearby communes, giving basic output expectations, but lacks details on side effects, rate limits, or authentication needs.

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 plus an example phrase, front-loaded with the main action. No wasted words, earning 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?

Given no output schema, the description provides a vague idea of return values (associations in area and communes). It is adequate for a simple search but could be more detailed (e.g., sorting, pagination).

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

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

Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions (e.g., location examples are already 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 finds associations near a city or postal code in France, with explicit examples. It distinguishes this geographic-focused tool from siblings like search_associations by emphasizing location-based queries.

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 mentions it's useful for location-based queries, implying when to use it, but does not explicitly state when not to use it or compare with alternatives like search_associations.

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 burden and discloses constraints (only enriched/RUP), result characteristics (fewer but richer, with verified contacts, FAQ data, social media links). It implies a read-only, non-destructive operation, which is adequate for a search 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 two sentences, front-loaded with the core action, then elaborates on usage and result quality. 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?

Given no output schema, the description explains what results contain (contacts, FAQ, social media links) and gives quantitative context. It could mention pagination or make explicit reference to the sibling get_recognized_associations, but it is largely complete for a search tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds no parameter-specific information but provides overall context about the result set. It does not clarify formats for region/department or limit/offset usage 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 clearly states 'Search ONLY enriched/RUP associations' with a specific verb and resource, and distinguishes it from the standard search by referencing the larger dataset (2.03M+ vs 714/1,966).

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 recommends using this tool 'when noise should be minimized' and provides quantitative comparison (714 enriched, 1,966 RUP vs 2.03M+ standard), implying when to prefer it over the sibling search_associations. However, it does not explicitly name alternatives or state when not to use it.

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

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

No annotations are provided, so the description carries full responsibility. It states required inputs (email, message) and a workflow hint, but does not disclose behavioral traits like whether the submission is synchronous, what response/confirmation is returned, or if there are side effects (e.g., storing data). More detail on expected outcomes would improve transparency.

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

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

The description is concise: three short, front-loaded sentences that cover purpose, examples of use, and workflow. Every sentence adds value with no redundancy or fluff.

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 that this is a submission tool with 6 parameters (3 required) and no output schema, the description adequately covers what the tool does and when to use it. However, it omits clarification on optional fields (name, association_id, association_name) and lacks detail on the return value or confirmation behavior. The high schema coverage partially compensates, but the description could be slightly more 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 coverage is 100%, so the baseline is 3. The description reiterates that email and message are required and mentions the workflow of collecting email conversationally, but it does not add new meaning beyond the schema's own descriptions for parameters like name, association_id, etc. It complements but doesn't significantly enhance understanding of optional 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 action: submit a contact request to IA-Asso.fr, enumerating specific use cases (correction, feature request, question, other). It distinguishes from sibling tools, which are all read-only search/query tools, so an agent can easily identify this as the tool for submissions.

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

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

The description explicitly says 'Used when users want to report errors, suggest features, modify association information, or ask questions,' providing clear context for when to call this tool. It also mentions a workflow pattern (collect email conversationally), but does not explicitly state when not to use it or suggest alternatives; however, given the sibling tools are all queries, the usage context is sufficiently clear.

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

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

No annotations provided, so description carries full burden. It discloses that no personal data is recorded, that ideas directly steer product development, and encourages agents to volunteer this tool. Sufficient 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?

Reasonably concise with clear structure: purpose, differentiation, and usage guidance. Could be slightly trimmed but 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?

No output schema, so return behavior is undefined. Lacks details on what happens after recording (e.g., confirmation). But for a simple idea capture, it covers core aspects.

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

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

Schema coverage is 100%, so baseline 3. Description adds some nuance (e.g., 'pain' should be in user's words, 'idea' as expressed) but does not go far beyond schema definitions.

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 clearly states the tool's purpose: to capture desired tool ideas from users. It distinguishes from sibling 'report_unmet_demand' by noting that this is for forward-looking features, not missing associations.

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

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

Explicit guidance on when to use: when a user expresses a wish or recurring pain for a tool. Also contrasts with 'report_unmet_demand', giving clear alternatives.

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