IA-Asso.fr — French Associations Registry

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

With no annotations, the description carries the full burden. It discloses that it returns live missions with specific fields (organization, commitment, places left, minor eligibility, signup URL, association link), and notes that coverage is non-exhaustive and limited to JeVeuxAider. It does not mention rate limits or auth, but the read-only nature is implied adequately.

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 that are front-loaded with the core purpose and then provide supplementary details. Every sentence adds value with no redundancy, though it could be slightly 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 6 parameters, no output schema, and no annotations, the description covers tool purpose, usage context, parameter roles, return fields, and coverage scope. It adequately equips the agent to decide when and how to use 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%, but the description adds value by clarifying parameter meanings: e.g., location is a French city or 5-digit postal code, query includes example keywords, and remote implies location is ignored. This enriches understanding 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 finds open volunteering missions near a French city or postal code from the official platform JeVeuxAider.gouv.fr. It specifies the verb 'find' and the resource 'volunteering missions', and distinguishes from searching for associations in general, leaving no 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?

Explicitly states 'Use this when someone wants to BE a volunteer (donner de son temps), not when searching for an association in general.' It also notes coverage limitations (JeVeuxAider missions only). While it doesn't name sibling tools, the context is clear enough to guide appropriate 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 description fully carries the transparency burden. It discloses data source (official registry, not search index), specific data fields returned (legal status, JO history, subsidies, public web presence), and explicitly excludes private data (email/phone). No contradictions. Minor gap: could mention potential latency or need for exact match.

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

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

Description is three sentences, front-loaded with core purpose and key data details. Could be slightly more concise by combining some clauses, but no wasteful phrases. Information is well-organized.

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, description sufficiently explains what the tool returns (legal status, creation date, JO history, subsidies, public web presence) and explicitly states what is excluded (email/phone). For a single-parameter detail tool, this provides complete understanding of capabilities 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% for the single parameter 'association_id'. Description adds meaning by specifying the exact format (RNA ID: W + 9 chars, or fiche slug), which aids correct input construction beyond schema's generic 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?

Description clearly states verb 'Get', resource 'detail of ONE already-identified association', and explicitly distinguishes itself from search tools. It specifies input format (RNA ID or fiche slug) and data included (RUP, creation date, etc.).

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: when user asks about a specific association (e.g., 'is it RUP?', 'when was it created?'). Advises against re-running search, providing clear context for choosing this tool over siblings 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?

No annotations are provided, so the description carries full burden. It transparently discloses that data is non-exhaustive, limited to local authorities, and that RNA only covers loi-1901 associations. While it doesn't explicitly state it's a read-only safe operation, the context implies it. The limitations are well communicated.

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 highly concise, starting with the verb 'Get' and main purpose. It efficiently lists return fields and uses capitalization for important caveats ('IMPORTANT: NON-exhaustive'). Every sentence adds necessary information 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 only one parameter and no output schema, the description adequately covers input and output semantics. It describes the return content (yearly grants with funder, purpose, amount) and important limitations. However, it does not specify the exact JSON structure or pagination, which might be helpful for parsing.

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' has full schema coverage (100%) with a description. The tool description adds value by clarifying the RNA ID format (W followed by 9 chars) and providing an example ('W751000001'), which helps ensure correct invocation beyond the schema's 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 retrieves public subsidies for an association, resolved to RNA from French open data. It specifies return fields (yearly grants, funder, purpose, amount) and distinguishes it from sibling tools that handle volunteering, general association info, or statistics.

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

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

Description provides critical caveats about non-exhaustiveness and data source limitations (only local authorities publishing SCDL). It implicitly guides when to use (when subsidy info needed) and warns against over-interpreting absence of data. However, it does not explicitly mention alternative tools or 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 must disclose behavioral traits. It mentions the tool returns statistics, implying a read operation, but does not explicitly state it is read-only, nor does it discuss auth needs, rate limits, or data freshness. The description is adequate but not explicit.

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: one stating purpose and output, one giving input guidance. No unnecessary words, and information 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 the single parameter and no output schema, the description provides a good overview of what the tool returns and valid input. Minor gaps exist, such as not mentioning whether results are paginated or if any restrictions apply, but overall it is sufficiently informative.

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 'code', which already provides examples. The description adds value by specifying valid code ranges (01-95, 2A/2B, 971-976) beyond the schema, helping the agent select correct inputs.

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 'Get comprehensive statistics for a French department' and details the data returned (total associations, active count, top cities, sector breakdown, temporal evolution). It also specifies valid department codes, distinguishing it from sibling tools like get_france_overview or get_association.

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 valid department codes (01-95, 2A/2B, 971-976), but does not explicitly state when to use this tool versus alternatives like get_france_overview or get_platform_stats. However, the purpose is clear enough to infer the appropriate 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 the full burden. It clearly indicates a read-only operation ('Returns...') with no mention of mutation or destructive behavior. While it does not disclose rate limits or performance, for a simple query tool with no parameters, the behavioral context is sufficiently 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 consists of two concise sentences with no redundancy. The first sentence states the action and output, and the second provides a use case. Every word contributes 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?

With no output schema, the description explains the return content (total associations, top regions, top departments, distribution insights). It provides a high-level overview but lacks specific structure details. Given the tool's simplicity and zero parameters, this level of completeness is 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?

The tool has zero parameters, and the schema coverage is 100%. The description adds meaning by explaining what the tool returns, which is value beyond the empty schema. According to guidelines, zero parameters default to a baseline of 4.

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 'Get' and the resource ('nationwide association statistics for France'). It specifies the return content (total associations, top regions, top departments, distribution insights). This differentiates it from sibling tools like get_department_stats (single department) and get_platform_stats (platform-wide).

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 'Useful for understanding the French associative landscape,' which implies when to use this tool. While it does not explicitly state when not to use it or name alternatives, the context from sibling tools provides differentiation. The guidance is clear but could be more 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?

No annotations provided; description carries full burden but fails to disclose behavioral traits such as authentication requirements, rate limits, or whether results are limited to specific regions beyond mention of department code.

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 concise sentences: purpose, context, and filtering options. No redundancy, every sentence adds 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?

Adequate for a search tool with decent schema coverage, but lacks explanation of return format or scope of 'health-related associations'. Given no output schema and many sibling tools, could benefit from more details.

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

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

Schema descriptions are present for all 4 parameters. Description adds value by providing example values for pathology and type_action, and clarifying department code format (e.g., '69', '75').

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 it finds health-related associations by pathology or disease, specifying the resource and action. It includes examples and mentions the France Care database, distinguishing it from broader search 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?

No guidance on when to use this tool versus siblings like search_associations or get_similar_associations. The description lacks context for selecting this over 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?

No annotations are provided, so the description alone must convey behavioral traits. It clearly states the output is a GeoJSON FeatureCollection with department data, which is a read-only operation. There are no contradictions, and the description is transparent about what the tool returns.

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 long, each adding value: purpose and return type, details of the data, and a common use case. There is no redundancy or unnecessary 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 with no output schema, the description adequately explains the return structure (GeoJSON FeatureCollection with coordinates and counts). It does not cover edge cases or error handling, but for a simple data retrieval tool, this is sufficient.

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

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

The tool has no parameters, so the description need not add parameter semantics. Schema coverage is 100% (no parameters to describe). Baseline for 0 parameters is 4, and the description does not need to provide additional parameter context.

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 explicitly states it retrieves GeoJSON map data for visualizing associations by French department, specifying the return type (FeatureCollection) and content (center coordinates and association counts). This distinguishes it from sibling tools like get_department_stats (which returns statistics) and search_near_location (which returns associations by location).

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 the tool is useful for creating interactive maps or geographic visualizations, providing context for when to use it. However, it does not explicitly state when not to use it or compare it to alternatives, but the purpose is clear enough to avoid confusion.

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 full burden. It states the tool returns 'non-sensitive aggregates' and 'no personal data', and outlines the output as a summary plus counts. It does not mention side effects, but the read-only nature is implied.

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, each substantive. Front-loaded with action and resource, then usage context, then output details. No redundant or vague phrasing.

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 parameters and no output schema, the description fully covers what the tool does, why to use it, and what it returns. It is self-contained and complete for a simple stats 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 tool has zero parameters, so baseline is 4. The description adds value by listing the types of statistics included, which is not in the empty 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 returns 'IA-Asso PLATFORM stats' including specific counts like active associations and coverage. It distinguishes from siblings by focusing on global, public, sales-oriented figures.

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 advises using it to explain the platform's completeness and AI-agent usability. It implies this tool is for broad statistics, but does not compare with siblings 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?

With no annotations, the description carries full burden. It discloses the current count (1,966) and timestamp (2026-08-18), and explains that the tool retrieves a list (read-only). It does not detail pagination, ordering, or rate limits, but the core behavior and data significance are well communicated.

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 with zero wasted words: purpose, data freshness, and contextual significance. The most critical information (what the tool does) is front-loaded. Every sentence contributes meaningful knowledge.

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 output (list of RUP associations) and its business context but omits details like pagination behavior, default sort order, or how multiple filters interact. Given no output schema and a list operation, it adequately covers purpose and usage but leaves operational behavior implicit.

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 parameters. The description adds value by providing example query values ('cancer', 'patrimoine') but doesn't elaborate on region/department semantics or how parameters combine. 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 clearly states the verb ('List') and resource ('associations officially recognized as utilite publique (RUP) by French state decree'), fully distinguishing from sibling tools like search_associations (general) and get_association (single entity). The specificity of RUP status is unique.

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

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

The description gives explicit use cases: 'institutional grounding -- mecenat, defiscalisation, public-private partnerships, B2B research' and explains the significance of RUP status (tax deduction benefits). While it doesn't say when NOT to use it, the context is sufficient for appropriate selection among 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 are provided, so the description bears full responsibility. It correctly implies a read-only operation and explains the similarity logic but does not disclose return format, error handling, or any side effects. It lacks depth but is not misleading.

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, each essential: purpose, mechanism, and use case. No redundant or ambiguous phrasing. Excellent front-loading of key information.

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

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

Given the tool's simplicity (3 parameters, no output schema), the description covers the core behavior and typical use cases. However, it could benefit from a brief note on return format or potential limitations (e.g., no results scenario).

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 value by explaining how the parameters relate to the search criteria (category and proximity), giving context beyond the 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?

The description clearly states the verb 'Find' and resource 'associations similar to a given association', and specifies the criteria (category and geographic proximity). It distinguishes from sibling tools like search_associations and search_near_location by focusing on similarity to a reference association.

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 (discovering related organizations, finding alternatives) but does not explicitly state when not to use or mention alternative tools. The context is clear and sufficient for most use cases.

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

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

Beyond annotations (idempotentHint=true, destructiveHint=false), the description reveals that content passes a moderation gate before publication, every change is audited and reversible. This adds useful behavioral context, though it doesn't cover potential error conditions or rate limits.

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, front-loaded with the main action and purpose. Every sentence provides essential information without redundancy or verbosity.

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 (6 parameters, nested objects) and absence of an output schema, the description covers authentication, prerequisite steps, moderation, and auditability. It is thorough but could mention return values or error scenarios.

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 each parameter. The description reinforces the purpose of the parameters but adds minimal new semantic value beyond what is in the schema, earning a baseline 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 uses a specific verb ('Update') and identifies the resource ('public profile of YOUR claimed association'), explicitly listing the modifiable fields (description, website, email, phone, social links). It clearly distinguishes from sibling tools, which are primarily read-only or search functions.

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 the prerequisite: an authenticated token with scope 'write:fiche' bound to the RNA, and provides a link to claim the association. It contrasts with read tools that are free and anonymous, guiding the agent when to use this tool versus siblings.

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

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

No annotations provided, so description carries full burden. It discloses no personal data, aggregated use, and that data powers insights. Does not detail auth needs or rate limits, but sufficient for a low-risk 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?

Description is well-structured with a clear first sentence. Slightly verbose with explanatory paragraphs, but every sentence adds value. Could be trimmed without losing meaning.

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 data usage and aggregation. For a simple logging tool, it covers intent, usage, and data handling adequately.

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. Description provides extra context for parameters (e.g., 'precise unmet intent'), but parameter descriptions in schema are already clear. No added semantic value beyond what schema offers.

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's purpose: recording unmet demand when a precise search fails. It specifies the verb 'Report' and the resource 'UNMET demand', and distinguishes it from siblings like search_associations by focusing on intent capture.

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 usage context: when precise search yields zero results, distant alternatives, or wrong type. Encourages volunteering. Lacks explicit when-not-to-use or alternatives, but the context is clear enough for an AI agent.

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 exist, so the description must disclose behavior. It reveals the database size (2.03M+ associations) and search scope but does not confirm read-only nature or mention rate limits, performance, or side effects. Adequate but not comprehensive.

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 and front-loaded: it states the purpose in the first sentence. Every sentence adds meaningful 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 no output schema, it summarizes return fields (name, object, location, RNA ID, SIRET). It covers filter capabilities well. Minor omissions include pagination behavior details and authentication needs, but overall sufficient for the tool's 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 coverage is 100%, and all schema descriptions are clear. The description adds value by providing concrete examples for each filter (e.g., department codes, region names), enhancing semantic understanding beyond the schema.

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

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

The description clearly states the tool searches for French associations using full-text search against the RNA database. It specifies the verb 'search' and the resource 'associations', and distinguishes from siblings like 'get_association' and 'search_near_location' by scope.

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 explicitly lists supported search modes (keywords, department, region) and gives examples. However, it does not contrast with alternatives like 'search_premium_associations' or 'get_similar_associations', leaving some ambiguity on 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?

No annotations exist, so the description carries full burden. It discloses the automatic widening to ±25 km when no exact match is found, and provides semantic guidance about not mixing location with query. However, it does not disclose potential error handling, rate limits, or authentication requirements. The transparency 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 extremely concise with three sentences covering purpose, behavioral trait, and examples. It is front-loaded with the primary action and requires no additional explanation. Every sentence earns its place without any 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 and four parameters, the description provides sufficient context for an agent to understand purpose, key behavioral constraints, and parameter usage. It lacks information about return format or pagination, but for a search tool this is acceptable due to common patterns. It is nearly complete for the tool's complexity level.

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 descriptions for all 4 parameters. The description adds value beyond the schema by explaining the widening behavior (not in schema), reinforcing the correct separation of location and query, and providing example usage. This helps an agent understand the interaction between 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 finds associations near a specific French city or postal code, optionally filtered by theme. It distinguishes from sibling tools like search_associations by focusing on geographic search, and provides concrete examples that ground the purpose.

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 usage context ('useful for location-based queries') and examples, but does not explicitly state when not to use this tool or mention alternative tools for non-geographic searches. There is no direct comparison to siblings like search_associations, which would clarify the intended use case.

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. Discloses filtering criteria (is_enriched_v3=true and RUP), result sizes, and data quality (verified contacts, FAQ, social media). However, it does not mention if results are sorted or if query language affects matching, leaving a minor gap.

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

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

Description is two sentences: first states purpose and criteria, second provides usage guidance and data context. Each sentence adds value, no fluff, and critical information is front-loaded.

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

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

For a search tool with no output schema, it adequately describes inputs (all parameters documented), result nature (richer, verified data), and scale (sample counts). Lacks slightly on output format expectations but this is minor given the 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 coverage is 100% with descriptions for all 5 parameters. The description adds value by explaining the data source and quality, but does not elaborate on parameter-specific behavior (e.g., how region/department filter, special query syntax). Baseline 3 is appropriate since schema handles the heavy lifting.

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 verb 'search' and resource 'premium associations' (enriched/RUP subset). It distinguishes itself from siblings by narrowing the result set to a specific curated subset, making its purpose unambiguous.

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

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

Explicitly recommends usage when 'noise should be minimized' and contrasts with 'standard search' (search_associations) by providing counts (778 enriched, 1,966 RUP vs 2.03M+). This tells the agent exactly when to use this tool vs 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?

No annotations exist, so the description carries full burden. It discloses that email and message are required and implies a non-destructive submission. However, it omits details like confirmation, error handling, or rate limits, leaving some behavioral aspects unspecified.

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 purpose and use cases. Every sentence adds value; no wasted words. It is ideally concise for an agent to quickly grasp.

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 nature of a contact submission and lack of output schema, the description covers purpose, use cases, and required fields. It slightly misses on workflow details (e.g., response handling) but is sufficient for effective tool 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 coverage is 100% with detailed property descriptions. The description adds minimal extra meaning (e.g., 'collect email conversationally'), providing some contextual value but not significantly enhancing understanding beyond the schema.

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

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

The description clearly states the tool's purpose: submitting contact requests (correction, feature request, question, or other). It specifies verb ('submit') and resource ('contact request'), and distinguishes from sibling tools focused on searches and data retrieval.

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 lists explicit use cases (report errors, suggest features, modify info, ask questions) and suggests a workflow ('collect email conversationally'). It lacks explicit exclusions or alternative tools, but the context is clear enough.

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 and that ideas directly steer development. While it doesn't detail persistence or side effects, the description adequately covers the key behavioral aspects for a suggestion 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?

Description is well-structured with clear sentences and logical flow. While slightly verbose, it efficiently conveys purpose, context, and usage 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?

With 3 parameters, no output schema, and no annotations, the description provides sufficient context: purpose, use cases, distinction from sibling, and parameter roles. Minor gap: does not explain confirmation or storage behavior, but acceptable for this tool.

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

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

Schema coverage is 100% and schema descriptions are clear. Description adds slight additional context (e.g., 'the problem it would solve, in the user’s words') but does not significantly enhance understanding 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?

Clearly states it captures desired tool ideas from users, with examples and explicit contrast to report_unmet_demand. The verb 'capture' and resource 'desired tool idea' are specific and 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?

Explicitly says when to use (when user expresses a wish or recurring pain) and when not (different from report_unmet_demand, which records missing associations). Provides both inclusion and exclusion criteria.

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