IA-Asso.fr — French Associations Registry

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 provided, so description carries burden. It adds factual context (number of records, date) and tax benefits, but lacks details on authentication, rate limits, or response behavior, which are common for list endpoints.

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 no redundant information. First sentence defines purpose, second gives factual count, third ties to business value. Efficient and front-loaded.

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

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

Given no output schema and 4 parameters, description provides useful context (RUP status, tax implications, use cases). Missing details like response structure or pagination, but acceptable for a list 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 description does not add extra meaning beyond field names and types. Baseline of 3 is appropriate as description does not elaborate on parameter usage or formatting.

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 lists associations with RUP status, a specific subset. This distinguishes it from siblings like search_associations or get_health_associations, which cover broader or different categories.

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

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

Provides explicit use cases such as mecenat and B2B research, offering context for when to use. However, it does not explicitly exclude other scenarios or compare with siblings, leaving some ambiguity.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It accurately conveys a read-only nature through 'Search... Returns association details' and mentions the data source (RNA database with 1.26M+ associations). It does not mention rate limits or authentication, but for a search tool, this level of detail is sufficient.

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 serving a distinct purpose: purpose and filters, data source, and return fields. There is no redundant information, and it is front-loaded with the main action. It is appropriately concise for a search tool with 5 parameters.

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 complexity (5 parameters, no output schema), the description covers the essential aspects: what it does, how to filter, and what is returned. It lacks mention of error handling or result limits beyond the schema, but for a straightforward search tool, it is largely complete.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the full-text search context and providing concrete examples for each filter (e.g., 'department code (e.g., '69' for Rhône)'). This enriches the schema descriptions and helps the agent understand parameter usage beyond syntax.

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: 'Search for French associations using full-text search.' It identifies the specific database (RNA) and the types of filters available (keywords, department, region), and lists the returned fields. This distinguishes it from sibling tools like 'search_near_location' which focuses on geographic proximity.

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 keyword-based searches with optional filters, but does not explicitly guide when to use this tool over alternatives like 'search_near_location' or 'search_premium_associations'. The agent can infer context from the capabilities described, but lacks clear when-to-use and when-not-to-use 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?

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?

The description discloses that results are fewer but richer, includes specific fields (verified contacts, FAQ, social media), and gives a count estimate. With no annotations, the description carries full burden and does well, though it does not explicitly state read-only nature 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?

Four concise sentences, front-loaded with the core purpose. Every sentence adds valuable information: scope, criteria, use case recommendation, and expected richness of results. No wasted words.

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

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

Given no output schema and 5 parameters with 100% schema coverage, the description provides context on result quality and quantity. It mentions output fields partially. Could be more complete on filtering behavior, but sufficient 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?

100% schema description coverage already documents all parameters. The description adds context for the query parameter by specifying the search scope (enriched/RUP subset), but does not elaborate on limit, offset, region, or department usage beyond what schema provides. Baseline 3 applies.

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

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

Description clearly specifies the verb 'Search' and the resource 'enriched/RUP associations', distinguishing it from the sibling search_associations by explicitly stating it is a subset ('ONLY enriched/RUP') and contrasting with 'standard 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?

Provides explicit when-to-use guidance: 'Recommended for agent grounding when noise should be minimized'. Contrasts with standard search using numbers (4k vs 1.26M), clearly indicating when this tool is preferred over the alternative.

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.