mcp-reunion

by Hug0x0

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.4.0
Disambiguation5/5
Each tool has a clearly distinct purpose, with descriptions that precisely differentiate overlapping domains (e.g., multiple election tools separated by election and round, multiple road tools segmented by aspect). No two tools create ambiguity.
Naming Consistency4/5
Tools consistently use the pattern reunion_verb_noun (get/list/search/lookup/inspect/query). The few exceptions like reunion_possession_search_* and reunion_iris_profile are logical deviations based on sub-domain, preserving overall readability.
Tool Count4/5
99 tools is high but justified by the broad scope of La Réunion data (demographics, economy, education, health, tourism, environment, etc.). Each tool serves a specific, non-redundant function; the count reflects the richness of available open data rather than bloat.
Completeness5/5
The tool surface covers virtually all major public datasets for La Réunion: population, income, education, health, transport, environment, tourism, elections, business, housing, culture. No dead ends or obvious gaps for the stated purpose of comprehensive regional data access.
Average 4.1/5 across 97 of 99 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 28 commits in the last 12 weeks
- Last stable release on April 27, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It mentions sorting by vote count descending and the row structure, but fails to disclose that the tool supports filtering via parameters (commune, candidate, polling_station, limit) or that it is a read-only query. No info on performance, rate limits, or side effects is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of four sentences, each carrying distinct, useful information: election specification, candidate list, row structure, and sorting + schema reference. It is front-loaded with the core purpose. The candidate list is slightly verbose but provides helpful context and is not excessive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description adequately covers output structure and sorting, but omits details on return format, error handling, and the effect of parameters (e.g., limit). It mentions schema matches another tool but does not elaborate on that schema. Overall, it is functional but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described in the input schema. The description does not add any additional meaning beyond what the schema already provides for the parameters. Baseline of 3 applies as the description offers no extra semantic value for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides per-polling-station results for a specific election (April 10, 2022 presidential 1st round) in La Réunion, lists the 12 candidates, and explains the row structure. It distinguishes from siblings by noting the schema matches reunion_get_legislative_2022_round1, indicating a parallel but distinct election dataset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like other election tools (e.g., reunion_get_legislative_2022_round1). The mention of schema matching is implicit, but no context on selection criteria, prerequisites, or exclusions is given, leaving the agent to rely on the tool name alone for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does not explicitly state that this is a read-only operation. It mentions returned fields and source but lacks disclosure of behavioral traits like rate limits, pagination behavior, or data freshness. The limit parameter implies pagination is handled, but no details are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences. The first sentence states the primary purpose, the second adds context about QPVs, and the third lists outputs and source. No unnecessary words, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional parameters and no output schema, the description covers the main aspects: what is listed, return fields, source, and a filter option. Minor gaps include lack of pagination handling details and output format, but these are partially compensated by the parameter schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both parameters (commune, limit) are described in the schema. The tool description does not add extra meaning beyond the schema's existing descriptions. Per guidelines, this results in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Quartiers Prioritaires (QPV) in La Réunion, with specific details on what QPVs are and their significance. It distinguishes this tool from sibling list tools (e.g., reunion_list_communes) by focusing on a distinct geographic and policy concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., reunion_list_communes or other list tools). The description explains the tool's purpose but does not specify context, prerequisites, or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes data returned and sorting (date descending). No annotations, but the description implies read-only search. Does not mention rate limits or auth, though for a search tool that is acceptable. No contradiction with annotations (none).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph is reasonably dense but could be more concise. Front-loads purpose but includes some redundant phrasing. Not overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers return fields, sorting, and typical use cases. No output schema, but description compensates by listing fields. 0 required params, all optional. Missing pagination details beyond limit parameter, but that's covered in schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters have schema descriptions (100% coverage). The tool description does not add significant meaning beyond the schema; it lists return fields but not parameter usage tips. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it searches DVF database for real-estate transactions in La Réunion. Lists each returned field and use cases (price analysis, market trends). Distinct from siblings like reunion_search_building_permits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. Does not mention when not to use or provide alternative tool names. The list of sibling tools exists but no comparative advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 discloses what the tool returns and the source, but does not mention side effects, authentication needs, rate limits, or explicitly state it is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and packs essential information without waste. It is front-loaded with the purpose, though a bit dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists return fields (name, type, address, etc.) and source, compensating for the missing output schema. Parameter limit is explained. Minor missing details on ordering or pagination, 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and descriptions are adequate. The description adds some context like pivot_local examples and commune prefix match, but does not significantly enhance meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches 'Annuaire de l'Administration' for local counters of public services in La Réunion, listing specific examples and return fields. It is distinct from siblings like reunion_search_schools or reunion_search_health_professionals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding administrative offices and provides examples of service types, but does not explicitly state when to use this tool versus alternatives or provide 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions the database source ('official La Poste') and that it returns multiple results per commune, but does not disclose any behavioral traits such as read-only nature, authorization requirements, rate limits, or potential side effects. The description is incomplete for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, starting with the main purpose, then explaining a key detail (multiple codes per commune), and finally listing output fields and use case. It is well-structured, front-loaded, and contains no superfluous information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description effectively explains the return fields (INSEE code, commune name, postal code, line 5, delivery label). It also notes the geographical scope and the matching behavior (prefix match for commune, exact for others). The only minor gap is that it does not mention the default limit of 50, which is defined in the schema. Overall, it is sufficiently complete for a simple lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all four parameters, so the baseline is 3. The description does not add significant meaning beyond the schema; it reiterates the output fields and use case but does not provide additional context for the parameters themselves. For example, it does not clarify that 'commune' is a prefix match or that 'postal_code' must be a 5-digit string starting with '974'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a lookup of official La Poste postal-code database for La Réunion communes and hamlets. It specifies the database source, geographical scope, and explains that multiple postal codes per commune are possible. This uniquely distinguishes it from sibling tools, none of which are postal code lookups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the usage context: 'Use to map between INSEE codes, postal codes, and delivery labels for normalization.' However, it does not provide explicit guidance on when not to use this tool or mention alternatives like reunion_search_ban_addresses, which could also provide postal codes. The usage advice is implied but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It indicates a search operation (read-only) and lists returned fields, but does not disclose behavioral traits like pagination, authentication needs, or rate limits. The verb 'Search' implies read-only, but it is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, efficiently stating purpose, scope, and return fields. No unnecessary words; front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complete input schema and no output schema, the description adequately explains what the tool returns and the eligibility context. It lacks details on pagination behavior (e.g., limit default) but is otherwise sufficient for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all parameters with descriptions (100% coverage). The description adds context about the data source and returned fields but does not add new semantics beyond the schema for parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for professional-training organizations and apprenticeship-training centers in La Réunion, with specific eligibility details. It distinguishes from sibling search tools by its focus on training organizations, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching training organizations but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It describes the output fields and sorting order but does not mention authentication, rate limits, or any limitations. It 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of four sentences, efficiently covering purpose and output fields. It is concise but could be more structured (e.g., bullet points) for easier scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 the return fields well and mentions sorting. It provides a comprehensive view of the data breakdown. However, it omits clarification on terms like 'new bachelors' and 'total headcount', slightly reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add significant meaning beyond the schema; the examples in the schema already cover parameter details. The description's additional explanations (e.g., year format) are already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool returns higher-education student enrollment data for La Réunion, breaking it down by multiple dimensions (establishment, diploma, level, discipline, sub-discipline, sex). The verb 'get' and resource 'higher_education_enrollment' are 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for obtaining enrollment data but does not explicitly state when to use it versus alternatives or provide exclusions. Usage context is clear from the domain, but no comparative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses the data source (IGN BD TOPO) and return fields, but does not mention that the operation is read-only, rate limits, or any side effects. The description 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long and front-loaded with the main purpose. It is concise and includes relevant details, though it could be restructured for scannability. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two parameters and no output schema, the description covers the tool's purpose, data source, example types, and return fields. It omits pagination or ordering details, but these are standard for list operations. Adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the schema already documents both parameters. The description adds context by listing example values for 'nature' and mentioning return fields, but does not elaborate on 'limit' beyond schema. Baseline is 3, and the added value is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists cultural and leisure POIs in La Réunion, derived from IGN BD TOPO. It enumerates example types (cinemas, theaters, museums, parks) and explicitly distinguishes from sibling list tools like reunion_list_museums by covering a broader category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions use cases (tourism apps, accessibility analysis, urban-services mapping) but does not explicitly specify when to use this tool over alternatives. No when-not or alternative tool references are provided, leaving the agent to infer context from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool lists trails and discloses the data source (ONF / regional tourism), but does not mention behavioral aspects like read-only nature, pagination, or data freshness. The existence of a 'limit' parameter is not explained in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at about 70 words across 4 sentences, front-loading the core purpose. The source attribution at the end is informative but could be integrated more succinctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description covers the return fields and usage context adequately. It could be improved by clarifying the effect of the 'limit' parameter, but overall it provides sufficient contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'limit', is fully described in the schema (max trails, range, default). The description adds no additional meaning beyond what the schema already provides, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as listing 'sentiers marmailles'—family-friendly walking trails designed for parents with young children. It specifies key traits (manageable length, low elevation, points of interest) and return fields (name, length, duration, trail ID), distinguishing it from sibling tools like reunion_list_hiking_circuits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions usefulness for tourism, family planning, and accessibility studies, implying contexts for use. However, it lacks explicit guidance on when not to use this tool (e.g., for general hiking) or references to alternatives among siblings, leaving usage decisions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns library data and implies a read-only operation, but does not mention any behavioral traits such as authentication needs, rate limits, or data freshness. The description is adequate for a simple list tool 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with three sentences. It front-loads the main purpose and then details return fields and use cases. It is informative but slightly verbose; a more concise phrasing could improve clarity. Overall, it is well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description compensates by listing the returned fields (library code, name, address, etc.) and source. It does not specify response format or types, but for a simple list tool with two optional parameters, the context is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds context about the return fields and use cases but does not provide additional semantic details for the parameters beyond what the schema already offers (e.g., commune as prefix match, limit range). Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists public libraries in La Réunion, specifies the types of libraries (BMVR, médiathèques, etc.), and lists the returned fields. It also mentions use cases (cultural-equipment mapping, accessibility analysis), making the purpose unambiguous and distinct from sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on what the tool returns and its source, but does not explicitly state when to use this tool versus alternatives (e.g., reunion_list_museums for museums). No guidance on exclusions or prerequisites is given, leaving the agent to infer usage solely from the tool name and return fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It does not mention rate limits, authentication, side effects, or pagination behavior. Only the return structure is described, leaving important behavioral traits unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and efficiently conveys purpose, return fields, and use cases. It is front-loaded but could be slightly more structured, but overall concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4 parameters, no required fields, complete schema descriptions, and no output schema, the description provides adequate context about what the tool does and returns. It does not cover errors or limitations, but is complete enough for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all 4 parameters. The description adds value by listing returned fields and giving examples for domain, which aids understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the Joconde national database extract restricted to La Réunion museum collections, specifies the fields returned, and provides use cases. This distinguishes it from sibling tools like 'reunion_search_catalog', which are broader.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for cultural research and art history related to Réunion museum collections, but does not explicitly state when to use this tool versus alternatives. No exclusion criteria or comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It notes that results are sorted by year descending, which is useful, but does not disclose other aspects like read-only nature, potential response size, or performance characteristics. It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose followed by details. Every sentence adds value, no redundancy, and it is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return fields (year, museum name, reference, city, paid visitors, free visitors, total, notes, observations) and includes the data source. Without an output schema, this provides adequate context. Could mention typical row counts or handling of missing years, but the limit parameter is addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with clear descriptions (100% coverage). The description adds that museum uses prefix matching and results are sorted by year descending, but these are minor additions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns annual attendance figures for each Musée de France in La Réunion, broken down by paid vs free admissions. It lists specific fields and distinguishes itself from sibling tools that cover different data (e.g., tourism frequentation, air quality).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the tool is useful for cultural-policy evaluation and tourism analysis, but does not explicitly state when to use it versus alternatives like reunion_get_tourism_frequentation. No guidance on when not to use or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adds value by stating the data is sorted by year descending and sourced from SDES via data.regionreunion.com. However, it does not disclose details such as pagination behavior, whether historical data only or includes projections, or how missing years are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that efficiently conveys the essential information: what is returned, its purpose, breakdown, sorting, and source. It is front-loaded with the key data, avoiding unnecessary detail, though it could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description should specify the return structure (e.g., columns or fields). It mentions 'broken down by product' but not the exact fields. It provides source and sorting but omits other contextual details like temporal range or data refresh frequency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the two parameters (year and limit) with descriptions already. The tool description does not add additional context beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns annual local consumption of petroleum products in La Réunion, broken down by product (gasoline, diesel, etc.), in cubic meters. It also lists use cases (energy-transition monitoring, GHG estimates, transport-policy analysis). The tool is distinct from its siblings, which cover topics like population, air quality, or commune profiles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions it's useful for energy-transition monitoring, GHG emission estimates, and transport-policy analysis, guiding when to use. It does not explicitly state when not to use or compare to alternatives, but the context of the tool and its siblings makes the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral traits like rate limits, authentication, or side effects. For a read-only list, it is adequate but not beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with main action, lists return fields efficiently. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description thoroughly lists return fields. Simple list tool with 3 optional parameters, well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. Description adds minimal new meaning beyond examples for discipline and commune. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists festivals in La Réunion with specific disciplines and return fields. It distinguishes from sibling list tools like museums or canyons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Many sibling list tools exist but description does not differentiate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It lists output fields but does not disclose behavioral traits such as being read-only, authentication needs, rate limits, or pagination behavior. While the tool is likely read-only, this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that efficiently conveys purpose and returned fields. It is front-loaded with the main action. While verbose due to listing fields (necessary without output schema), it is not excessively long and every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly explains what the tool returns (UAI, school name, type, EP label, etc.) and provides context about the EP program. Together with the schema, it gives a complete picture for the agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 three parameters (commune, ep_label, limit). The description adds some context (e.g., 'prefix match' for commune and ep_label) but no significant meaning beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists schools in La Réunion belonging to the Education Prioritaire program (REP/REP+), with a specific list of returned fields (UAI, name, type, etc.). This distinguishes it from sibling tools like reunion_search_schools, which likely cover all schools without the EP filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's context but does not explicitly state when to use it over alternatives (e.g., reunion_search_schools) or when not to use it. The specificity is implied but not directly compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the data source and return fields but omits details about rate limits, authentication, or whether the operation is read-only. This is a significant gap for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, front-loaded with the core purpose, followed by a succinct list of return fields and the source. Every sentence adds value, and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 return fields well. However, it does not clarify pagination behavior or ordering of results, which is important for a search tool with a limit parameter. Mostly complete but has a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 context about the data source and return fields but does not provide additional parameter-level meaning beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for geolocated primary and secondary schools in La Réunion, lists return fields, and specifies the data source. This distinguishes it from sibling search tools like reunion_search_associations or reunion_search_health_professionals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description effectively conveys when to use this tool (to search for schools in La Réunion) but does not explicitly mention when not to use it or suggest alternatives like reunion_list_priority_education_schools. It provides clear context for its use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose whether the tool is read-only, idempotent, or has any side effects. As a search tool, it is likely safe, but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences only, front-loaded with purpose and scope, then details. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return fields comprehensively. Mentions source. Lacks pagination details, but limit parameter covers that. Adequate for a search tool with 4 optional params.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters. Description adds value by providing concrete examples for type and family (e.g., 'Court de tennis', 'Petits terrains en accès libre') and explains limit's default and range. Enhances understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it searches the national sport-equipment registry (RES) restricted to La Réunion. Lists specific examples (stadiums, gyms, etc.) and return fields. Distinct from sibling tools like reunion_list_swimming_pools which is more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for general sport infrastructure search in Réunion but does not explicitly state when to use vs alternatives like reunion_list_swimming_pools. No when-not guidance or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It details the output structure (1 row per year, sorted descending) and lists all returned indicators, providing good behavioral context for a read-only snapshot.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense with relevant information, front-loaded with purpose, and avoids unnecessary words. Could be slightly more structured but is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description thoroughly explains the return fields and behavior. Missing only minor details like pagination or empty-result handling, but sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and descriptions already define 'year' and 'limit' well. The overall description adds context about output rows but does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it provides a comprehensive housing/demographic snapshot of La Réunion department at the department level, distinguishing it from other reunion tools that target communes, iris, or specific datasets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for retrieving department-level housing and demographic data, but no explicit guidance on when to prefer this tool over siblings or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It explains the output fields and that data is per road side. However, it does not explicitly state read-only nature, authorization needs, or side effects. For a read tool, minimal transparency is acceptable but could be improved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no fluff, front-loading the purpose and listing output fields efficiently. A slight improvement could be merging the last sentence with the applications, but it's well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (2 params, no output schema), the description covers the main aspects: what data is returned, units, and use cases. It implicitly limits to Réunion via tool name. It does not explain parameter filtering but schema covers that. Overall quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have descriptions. The description does not add additional meaning beyond the schema; it only mentions 'road number, axis' in the output context. Therefore, it meets the baseline but does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns speed-limit segments on Réunion's national roads, specifying verb (get), resource (speed limits), and scope (Réunion RN). It distinguishes itself from sibling road tools (classification, flow, traffic) by focusing on speed limits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists use cases: routing, speed-compliance, road-safety studies. While it does not explicitly exclude other tools or mention when not to use, the stated applications provide clear context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses the return fields and the special label context. It does not detail filtering behavior beyond schema hints or mention rate limits, but adequately covers core behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one long sentence but front-loaded with the core purpose. It provides necessary context without extraneous words, though could be slightly more condensed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists return fields and explains the label, covering key aspects for a filtered list tool. It lacks mention of ordering or error handling, but is complete enough given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description does not add new parameter details beyond what the schema already provides (e.g., commune and type prefix match, limit defaults).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists schools in La Réunion with the 'Génération 2024' label, explains the label's significance, and lists return fields. This distinguishes it from generic school search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding specific labeled schools but does not explicitly compare to alternatives like reunion_search_schools 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that results are sorted by start date descending and specifies the returned data fields. While it does not cover rate limits or pagination details, the behavioral description is reasonably thorough for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, efficiently packing purpose, scope, returned fields, and sorting order. It is well-structured and free of unnecessary words, though it could be slightly more scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description adequately details the returned fields. It covers the dataset scope, search capabilities, and sorting. It is complete enough for an agent to understand what the tool returns and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter already described. The description adds minimal extra meaning—for example, listing examples for the category parameter. Baseline is 3, and no significant additional semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: searching beneficiaries of the European Regional Development Fund (FEDER/ERDF) for the 2014-2020 period in La Réunion. It lists the specific fields returned, distinguishing it from many sibling search tools that target different datasets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is 'useful to map EU-funded projects, audit transparency, or analyze regional development patterns,' which implies usage context. However, it does not explicitly mention when to avoid this tool or compare it to alternative tools for similar queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the tool returns specific fields and is sorted most recent first, but does not disclose rate limits, authentication, data freshness, or other behavioral traits. The source citation is helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loading the data source and time range, then listing output fields, sort order, and source. No wasted words, clear and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully enumerates returned fields and specifies sorting and data source. Given the simple search functionality and 4 parameters, the description is complete enough to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for all parameters. The description adds context about output fields but does not add meaning beyond the schema for the parameters themselves. Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches road accident records from BAAC for La Réunion, covering 2016-2019, and lists returned fields. It distinguishes from sibling tools like reunion_get_road_classification, which focus on other road data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching accident records, but does not explicitly state when to use this tool versus alternative search tools or other road-related tools. No exclusions or alternative guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It lists the fields returned but does not explicitly state read-only nature, rate limits, or pagination behavior (though limit parameter is documented in schema). The description adds some behavioral context but could be more comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus an embedded list of return fields. The first sentence is somewhat long but effectively communicates scope. No unnecessary words. Well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 5 optional parameters and no output schema, the description covers the search domain, return fields, and provides a sibling reference. Could mention sorting behavior or free-text query capabilities, but overall sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add additional detail beyond what is already in the schema's parameter descriptions. It reiterates examples but does not enhance understanding of parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool searches the SIT Soubik catalog for La Réunion tourism establishments, lists the types of establishments included, and specifies the fields returned. It also explicitly distinguishes from a sibling tool (reunion_search_classified_accommodations) by noting when to use that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: it is for searching tourism establishments in La Réunion with various filters. Explicitly tells the agent when to use an alternative tool (for star-classified accommodations). However, it does not cover when not to use this tool versus other tourism-related tools like reunion_list_hiking_circuits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 states the tool returns data but does not disclose behavioral traits such as rate limits, error handling, or that this is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative, front-loaded with the purpose, and each sentence contributes useful context. It is slightly verbose but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists all returned fields thoroughly. It also provides the regulatory context (mandatory inspections every 2 years). This makes it fairly complete for a search tool with three optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions. The description adds context about returned fields but not beyond what the schema provides. Since schema coverage is 100%, the description adds minimal extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns mandatory vehicle-inspection center prices in La Réunion, with specific details on required inspections and returned fields. It distinguishes itself from sibling tools by its focused topic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions 'Useful for price comparison,' indicating a primary use case. However, it does not discuss when not to use this tool or mention alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses that results are sorted by last-update descending and lists the returned fields. This is fairly transparent for a read-only data retrieval tool, though it does not discuss 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first explains the tool's function and data source, the second lists output fields and sorting. Every sentence adds value, and the description is front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description lists all returned fields and mentions sorting. It covers the key aspects for using the tool, though it could mention whether the data is always recent or any pagination behavior. Overall, it is fairly complete for a simple data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions, including enum values for pollutant. The description adds minimal extra context (e.g., mentioning city as prefix match), but overall the schema already provides adequate semantics, so the description offers limited additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns air-quality station measurements from OpenAQ for La Réunion. It specifies each row represents one measurement at one station for one pollutant and lists the returned fields. This distinguishes it clearly from sibling tools, which cover other topics like commune profiles or search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for environmental monitoring, public-health analysis, or pollution-event tracking but does not explicitly state when to use this tool versus alternatives or when not to use it. No mention of prerequisites or alternative tools for related queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks details on data freshness, rate limits, or response behavior (e.g., empty results). Carries full burden but only covers source and attributes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured sentence that front-loads the key information. No redundancy; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameters, and source adequately for a simple list tool. Could mention default ordering or pagination hints, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds concrete examples for 'type' and 'commune' parameters and explains 'limit' beyond the schema. Adds value despite 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool returns 'Voie Vélo Régionale (regional cycle network) segments' with specific attributes and use cases. Distinguishes from sibling road/traffic tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes use cases (cycling-route planning, infrastructure analysis, mobility studies) and implies context through sibling separation. No explicit when-not-to-use or alternatives given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions sorting by month descending and the structure of results, but lacks details on rate limits, data completeness, or authorization requirements. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all essential information, no fluff. Front-loaded with the key purpose and structure, then use cases. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description explains the return structure in detail. Parameters are fully covered. Minor omission: geographic scope is implied but not explicitly stated. Overall complete enough for a data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully described in the schema (ISO dates, limit range/default). The description adds no additional parameter meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns monthly counts of jobseekers in La Réunion broken down by sex and age group, specifying the columns (total, men, women, six sub-categories). It distinguishes from siblings like reunion_get_jobseekers_by_commune which focus on different dimensions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests use cases (labor-market monitoring, demographic analysis, gender-gap studies) but does not explicitly state when not to use it or compare with alternatives. The context is clear enough to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals sorting order (by date then jobseekers descending) and data source, but with no annotations, it does not explicitly state read-only behavior, rate limits, or authentication needs. It adds value but could be more comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loads the core purpose and return fields, then adds sorting and a combination use case, and finishes with the source. Every sentence is informative and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a data retrieval tool with no output schema or annotations, the description covers purpose, fields, sorting, source, and a use case. It could mention pagination (though limit is in schema) or error handling, but it is sufficient for an AI agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for each parameter, so the description adds minimal extra meaning beyond sorting and source. It does not elaborate on parameter behavior or constraints beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides jobseeker counts per commune in La Réunion, broken down by snapshot date, and specifies the returned fields (date, commune, INSEE code, postal code, count). It distinguishes from siblings like reunion_get_jobseekers_by_age_sex and suggests combining with reunion_get_commune_population.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends combining with reunion_get_commune_population to compute unemployment rates, providing a concrete use case. It does not list when not to use or alternative tools, but the sibling context and clarity of purpose make it adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full burden. It explains the return fields, sorting order (by patient count descending), and data taxonomy. However, it does not disclose whether the tool is read-only, any authentication needs, or rate limits. Still, it provides substantial 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences) and front-loaded: first sentence states purpose, second explains taxonomy, third lists return fields. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description reasonably covers all return fields and ordering. It lacks details on pagination (though limit param exists) and error handling, but for a data retrieval tool this is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage with examples and constraints. The description adds no new meaning beyond the schema's parameter descriptions, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns patient counts and prevalence rates by pathology, sex, and age group, specifying data source (CNAM Cartographie des pathologies) and a 3-level taxonomy. This distinguishes it from sibling tools which focus on other domains like commune profiles, air quality, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples for parameter values (e.g., "diabète", "Tous âges") but does not explicitly state when to use this tool over alternatives like reunion_inspect_dataset or reunion_query_dataset. Usage context is implied but not clarified with when-not or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a read-only list operation and mentions the data source, but lacks details on pagination, rate limits, update frequency, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: purpose then output/use cases. No filler, front-loaded with key info. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 4 parameters and no output schema, the description adequately explains what is returned and the data source. It could mention data freshness or pagination, but it is sufficient for an agent to understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter descriptions in the schema are already clear. The tool description does not add additional meaning beyond listing output columns and use cases, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 5G cell sites in La Réunion from ARCEP data, specifying the resource, location, and source. It distinguishes from all sibling tools, which cover different data domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists use cases like coverage analysis and infrastructure mapping, providing clear context for when to use the tool. It doesn't explicitly exclude alternatives or mention when not to use it, but the specificity makes the usage straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It correctly implies read-only behavior by saying 'List' and mentions redistricting handling, but lacks explicit statements about side effects or requirements. For a list tool, this is adequate but not outstanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a few sentences, though it includes some redundant mentions (e.g., 'electoral cantons'). It is front-loaded with purpose and key details, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter with full schema coverage and the description listing all returned fields, the tool is well-documented. No additional context is needed for effective usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (limit) is fully described in the schema (min, max, default). The description does not add additional semantic meaning beyond what the schema already provides, hence baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists electoral cantons of La Réunion, explains their electoral purpose, and enumerates returned fields. It uniquely identifies the tool among siblings, as no other tool lists cantons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides context for usage (electoral analysis, conseil départemental research) and implicitly indicates when to use it. While it doesn't explicitly exclude alternatives, siblings are distinct enough that this is not needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the tool returns a list with detailed fields (names, durations, flags) and implies a read-only listing operation. It does not disclose rate limits or permissions, but it is transparent about the data returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose and then lists output fields. It is efficient but could be slightly more structured with bullet points. However, it contains no fluff and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 adequately explains the return values (canyon name, durations, flag, etc.) and units. It covers purpose, output fields, and essential usage context, making it complete for a listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 both parameters ('secteur' and 'limit') with descriptions. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List practiced canyoning routes in La Réunion' with a specific verb and resource. It differentiates from sibling tools like reunion_list_hiking_circuits by focusing on canyoning routes, and no other sibling tool covers this niche.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the tool is 'Essential for canyoning planning, safety briefings, professional guides,' which implies usage context but does not provide explicit guidance on when to use versus alternatives or when not to use. No exclusions or alternative tool names are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description partially compensates by noting it's a list with coarse-location filter and describes return fields. However, it lacks details on safety (read-only), rate limits, or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-loaded with purpose, each sentence adds value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description lists all return fields and explains filtering. Sufficient for a simple listing tool. Could mention pagination or default limit behavior more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description adds little beyond schema: 'commune' already has prefix match description in schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists coworking spaces in La Réunion with specific details returned. It differentiates from sibling list tools by focusing on coworking spaces only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions target users (remote workers, freelancers, business travelers) and context. Does not state when not to use, but context implies it's specifically for coworking spaces.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It implies read-only operation ('returns') but does not clarify data freshness, pagination beyond limit, or access permissions. Adequate but not extra.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then context, then return fields and use cases. Every sentence earns its place; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description lists returned fields comprehensively and gives use cases. Missing edge cases like empty results or error conditions. Good for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already describes parameters with examples. Description adds minimal extra meaning beyond mentioning 'open/closed status' in return fields, which hints at open_only parameter. Baseline score appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists main hiking circuits from a specific catalog, giving examples of famous circuits (GR R1, etc.) and listing returned fields, distinguishing it from sibling list tools for other categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides use cases (trip planning, route comparison, ONF closures monitoring) and context about closures, but does not explicitly say when to use this vs alternative tools like reunion_list_family_trails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 does not mention rate limits, authentication, destructive actions, or any side effects. It does describe what the tool returns, but that is output-related, not behavioral. The description is accurate but lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise (three sentences) and front-loaded with the core purpose. It efficiently defines IRIS and lists return fields, though the list is somewhat verbose. Every sentence adds value, but could be slightly trimmed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (list with two optional parameters, no output schema), the description is very complete. It explains what IRIS is, what fields are returned, and how to use it with sibling tools. It covers the necessary context for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline score is 3. The description adds context by stating 'commune name prefix match' for the commune parameter and explaining the limit range, but these are mostly restatements of the schema descriptions. No additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists IRIS zones, defines what IRIS is ('INSEE's fine sub-communal statistical geography'), and enumerates the returned fields (code, name, type, etc.). The verb 'List' and resource 'IRIS' are specific and distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the use case (census, income, poverty, employment data) and explicitly mentions sibling tools 'reunion_iris_profile' and 'reunion_get_income_poverty_by_iris' for cross-dataset analysis, providing guidance on when to combine tools. However, it does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the return includes quarter name and source, but lacks details on authentication, rate limits, or side effects. The tool is simple, but more specific behavioral context (e.g., 'returns exactly 20 items', 'data is static') 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three sentences, front-loaded with purpose, no redundant information. Every sentence serves a purpose: action, context, and output description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 provides adequate context: it lists exactly 20 quarters, mentions administrative use, and tells what fields are returned. Could mention if the data is static or dynamic, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist in the schema, so schema coverage is 100%. The description adds value by specifying the output includes quarter name and source, which is not in the schema. With 0 params, baseline is 4, and description meets that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists the 20 official quarters of Saint-Denis, La Réunion, with specific verb 'list' and resource 'quarters'. It is distinct from sibling tools like reunion_list_communes or reunion_list_cantons due to the geographic specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Context implies it is for retrieving Saint-Denis quarters only, but no alternatives like nearby communes or broader lists are mentioned. Usage is implied but not directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses the data source and returned fields, but does not explicitly state that the operation is read-only or mention any side effects, authentication needs, or rate limits. While likely harmless, the description lacks some transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loading the core purpose and immediately providing essential context. No unnecessary words or repetitions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description lists all returned fields and mentions use cases. It covers the data source, filtering, and granularity. However, it does not mention pagination behavior (though limit param is in schema) or differentiate from similar list tools. Still, it is mostly complete for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for each parameter (commune, type, limit). The tool description does not add additional parameter semantics beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists swimming-pool basins in La Réunion, explains the data source (subset of national sport-equipment registry), granularity (per basin), and lists returned fields. It also mentions use cases, making the purpose very specific and distinguishable from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (for pool-related data in Réunion), but does not explicitly state when not to use it or mention alternatives. However, the context is sufficiently clear for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 does not mention behavioral traits such as read-only, destructive hint, rate limits, authentication requirements, or response format. The description only lists the tool's purpose and parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first lists the types of water management points, and the second states what is returned and typical use cases. No unnecessary information; concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description adequately covers the tool's capabilities. It mentions returned fields and use cases. However, it could mention the limit parameter or pagination behavior, though the schema covers it. Overall, it is complete enough for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the input schema by providing concrete examples for the 'nature' parameter (e.g., Captage, Station de traitement) and explaining the 'origine' parameter (organization that produced the data). However, the schema already describes all parameters completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists points of activity related to water management in La Réunion, specifying the types (water intakes, treatment plants, reservoirs, pumping stations) and returned fields (ID, origin, nature, toponym, importance level). 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for usage (water-resource analysis, infrastructure mapping, environmental studies), but does not explicitly state when to use this tool versus alternatives or when not to use it. Siblings are diverse, so it's clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It mentions the data source and types but does not disclose behavioral traits like rate limits, authentication, or side effects. As a read-only list, the description is adequate but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main purpose, and contains no redundant words. It is concise and well-structured, though slightly more detail on return values could be integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by listing returned fields (MNHN ID, organization ID, zone name, generation) and explains the two zone types, making it complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for both parameters (query, limit). The description adds no new parameter information beyond the schema, so it meets the baseline without additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists ZNIEFF (Zones Naturelles d'Intérêt Écologique) in La Réunion, specifies verb 'list' and resource, and distinguishes from sibling tools by detailing a unique data source and zone types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's use for biodiversity protection and land-use decisions. It provides context but does not explicitly mention when to avoid using it or list alternative tools; however, sibling tools are unrelated, so guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It mentions the data fields and source (IGN / La Poste / DINUM) but does not disclose side effects, read-only nature, or any special behaviors. However, it does state the restriction to La Réunion addresses, which is a key constraint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (four sentences) and front-loaded with the main purpose and scope. Every sentence adds value: definition, data contents, use cases, data source. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return fields (lat/lon, street, number, postal code, INSEE code, position type) and sources. It covers use cases, but lacks details on error handling or response format, which is acceptable given the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with well-described parameters (query, commune, insee, postal_code, limit). The description adds context about the address fields returned but does not enhance parameter understanding beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the Base Adresse Nationale (BAN) restricted to La Réunion, lists the data fields (lat/lon, street name, etc.), and specifies use cases like geocoding and address validation. It distinguishes itself from sibling tools which focus on other domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists use cases: geocoding, address validation, last-mile delivery, mapping. While it doesn't state when not to use it or name alternatives, the context of Réunion-specific BAN data and the clarity of the use cases provide sufficient guidance for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It lists returned fields (stop_id, name, etc.) and mentions GTFS data source, but does not disclose other behavioral traits like idempotency, rate limits, or authentication. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two sentences: first sentence states purpose and context, second adds return fields, sibling reference, and source. No filler, front-loaded info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (4 optional params, no output schema), the description covers purpose, return fields, data source, and related tool. Minor addition could be coordinate format but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and schema descriptions are quite detailed (e.g., 'Free-text search on stop name'). The description adds no additional semantic meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Search bus stops of the Car Jaune network' with specific resource (bus stops) and operator (La Réunion's interurban bus service). It distinguishes from sibling tools by referencing Car Jaune specifically and recommending reunion_list_car_jaune_routes for listing lines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs users to reunion_list_car_jaune_routes for listing bus lines, providing an alternative. However, it does not explicitly state when not to use this tool or cover other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 describes the tool as a search (presumably read-only) and details the output fields and data source. However, it does not explicitly state read-only behavior or side effects, which is acceptable for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, containing four sentences that front-load the purpose and then list returned fields and source. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema, no annotations), the description is fairly complete. It identifies the data source, lists returned fields, and explains the purpose. It could mention pagination or ordering, but the limit parameter covers max results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no additional meaning beyond what the schema provides for each parameter. It repeats schema descriptions for query, commune, year, and limit without extra context or formatting details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for post-baccalaureate programs on Parcoursup in La Réunion, listing specific program types and returned fields. This distinguishes it from sibling tools, which cover different domains like communes, health, or infrastructure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It implies usage for Parcoursup-related searches but lacks guidance on when not to use it or comparisons with other search tools among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It explains the data content and structure but does not disclose whether the operation is read-only, any authentication needs, rate limits, or potential side effects. The description is adequate for a data retrieval tool but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences delivering purpose, data structure, and use cases. No redundant or filler content, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters, no annotations, and no output schema, the description provides sufficient context: it describes the data model (each row's attributes) and typical applications. It is complete for an agent to understand what the tool does and what results to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both 'state' and 'limit' have descriptions in the schema. The tool description does not add new information about these parameters beyond what is already in the schema, so it meets the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns detailed segments of the East-coast coastal trail with specific field-survey attributes (width, length, state, etc.). It distinguishes itself from sibling tools like reunion_list_hiking_circuits by focusing on this specific trail with detailed survey data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions usefulness for trail-maintenance planning, accessibility studies, and hiking applications, indicating when to use. However, it does not explicitly exclude other tools or provide comparative guidance, so it's clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses the sorting order (descending by vote count) and the exact structure of each row. It does not mention data freshness or performance, but the key behavioral traits are communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but front-loads the purpose and key details. It is informative without being verbose, though the dense list of fields could be slightly restructured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully describes the output fields and sorting. It covers the election details and sibling reference. Missing error or pagination info, but acceptable for a data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 no additional meaning beyond what the schema provides for parameters; it focuses on output fields. This is adequate but not enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns per-polling-station results for a specific election (June 12, 2022 legislative, 1st round, La Réunion) and explicitly distinguishes from the round 2 sibling tool. The verb 'get' and resource 'legislative_2022_round1' are precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains which election and round it covers and points to the sibling for round 2. However, it doesn't discuss when to use this tool versus other legislative tools (e.g., 2024 rounds) or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose all behavior. It explains the tool returns specific fields (route, category, etc.) and mentions the data source (DEAL Réunion). However, it omits potential rate limits, authentication needs, or data staleness, which would enhance transparency for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, return fields/source, and combination advice. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a specialized road classification tool with no output schema required, the description adequately explains inputs, outputs, and how it fits into a broader analysis (combining with traffic and speed limit tools).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage on all three parameters (route, classe, limit) with clear examples. The description adds no additional parameter-level detail, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves functional classification of Réunion national-road segments, specifies the returned fields (category, class, etc.), and distinguishes itself from sibling tools like reunion_get_road_traffic and reunion_get_speed_limits by focusing on classification data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description advises combining with reunion_get_road_traffic and reunion_get_speed_limits for full road-segment analysis, implying that this tool alone is for classification. It does not explicitly list when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses data source (DEAL Réunion), sorting order (year then traffic descending), and return fields. No annotations provided, so description carries full burden. Provides good 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise three-sentence paragraph: what it does, what it returns, sorting and source. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with 4 optional parameters and no output schema, the description covers data meaning, source, output fields, and sorting. Complete enough for agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description reinforces parameter meaning (e.g., 'exact national-road code' for route) but doesn't add significant new semantic details beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns traffic counts on Réunion national-road segments with specific fields and sorting. Differentiates from siblings like reunion_get_road_classification by being specific about counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like reunion_get_road_daily_flow or reunion_get_road_classification. Implies it's for annual average daily traffic, but lacks exclusionary context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 clarifies the tool lists data (read-only implied) and describes sorted output, but lacks explicit statements about safety, auth needs, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a use-case sentence. It front-loads the purpose and is free of fluff. Every sentence serves a clear function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, but the description lists all return fields (RP number, area, INSEE, etc.) and explains the data (cadastral parcels, sorted). Given the relative simplicity, it is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds value by explaining prefix matching for quartier, giving ZPU examples, and noting default sort order, which are not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'potentiel foncier' parcels in La Réunion for urbanization/development. It is specific and distinct from sibling tools, which are many but not related to land potential.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for SCOT/PLU work and real-estate planning but does not explicitly contrast with sibling tools or state when not to use it. Guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains the output format (columns, sorting, source) and notes case-insensitivity for the name parameter. While it doesn't cover all edge cases (e.g., default behavior with no parameters), it provides key behavioral details beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact four-sentence paragraph. It front-loads the purpose, then efficiently describes output, sorting, and source. No redundant or wasted language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, the description covers the tool's purpose, scope, output structure, sorting, and data source. For a tool with 4 parameters and no output schema, this is sufficiently complete for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add significant new meaning to parameters beyond what the schema already provides (e.g., prefix match, year range, sex enum). It describes the output but not parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches first names given to babies born in La Réunion by year since 2000, with a specific geographic and temporal scope. It distinguishes itself from sibling tools (e.g., reunion_search_schools) by focusing on baby names, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions usefulness for naming trend analysis and demographic studies, implying appropriate contexts. However, it does not explicitly state when not to use the tool or provide alternatives, leaving the guidance implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return fields and includes specifics like local lieux-dits, cadastral parcels, and timestamps. Does not mention pagination or rate limits, but overall behavior is well explained. No annotations to contradict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Packed with useful information in a few sentences. Could be slightly trimmed but remains clear and front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Good coverage for a 3-param tool with no output schema: explains return fields, data source, and differentiation. Adequate for an agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds slight context (e.g., 'free-text search', 'prefix match') but does not significantly enrich beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it searches the BAL for La Possession, explains what BAL is and its granularity compared to BAN, and lists returned fields. Distinct from sibling tools like reunion_search_ban_addresses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for when to use (for more granular addresses in La Possession) but does not explicitly mention alternatives or exclusions. Sibling tool list includes BAN search, so implication is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It specifies return fields (notice ID, web ID, buyer, awardee, etc.) and sorting by publication date descending. It does not mention rate limits, authentication, or error handling, but the behavioral overview is adequate for a read-only search.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise paragraph that front-loads the purpose, lists output fields efficiently, and ends with sorting and source information. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description enumerates all return fields. It covers the tool's scope (public procurement notices in La Réunion), parameters, and behavior (sorted by date). No critical gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 4 parameters with full descriptions (100% coverage). The tool description does not add new parameter semantics beyond what is in the schema; it only provides examples that are already present. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the BOAMP for public procurement notices concerning La Réunion. It lists specific notice types (open tenders, MAPA, contract awards, etc.) and return fields, distinguishing it from many other search tools on the server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like reunion_possession_search_procurement, which may serve a similar purpose for a different geographic area. The description lacks 'when not to use' or context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses the sorting order (by authorization date descending) and the data fields returned. However, it does not mention behavioral details such as pagination behavior beyond the limit parameter, rate limits, authentication requirements, or the fact that the tool is read-only (likely).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose and scope, followed by a list of return fields and sorting. Every sentence carries essential information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description compensates by listing the return fields. However, it does not explain that all parameters are optional (schema shows no required fields) or describe pagination behavior (e.g., what happens if more results than limit exist). The description is adequate but lacks these operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description's contribution is additive. It explains the meaning of the 'type' enum (PC, DP, PA) in natural language and clarifies that 'commune' expects an INSEE code for exact match, and 'year' refers to the filing year. This adds value beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool searches non-residential building authorizations from the Sitadel database restricted to La Réunion, covering specific permit types (PC, DP, PA) and property categories. This provides a specific verb+resource+scope, and the mention of 'non-residential' clearly distinguishes it from the sibling tool 'reunion_search_residential_permits'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on the tool's purpose and scope (La Réunion, non-residential, Sitadel database) and lists the data fields returned. However, it does not explicitly state when to use this tool versus its sibling (e.g., 'for residential permits, use reunion_search_residential_permits'), nor does it provide exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses the search behavior, returned fields (including geolocation and certification details), and data source. No contradictions; it adequately informs about the tool's read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph front-loaded with purpose and context. It is informative without being verbose, though slight conciseness could be improved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description lists all returned fields and explains the certification's importance. It provides sufficient context for usage, including data source and application.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents parameters. The description adds domain examples but does not fundamentally extend meaning beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for RGE-certified companies in La Réunion, with a specific verb+resource+scope. It distinguishes itself from siblings by focusing on RGE certification and energy-renovation context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (when clients need state aids) and provides contextual background on RGE relevance. It lacks explicit 'when not to use' or alternatives, but the context is clear given sibling tools cover different domains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses output structure (date, benefit type, count), sorting order (date descending), and benefit coverage. It does not reveal potential pagination behavior or update risks, but as a read-only data retrieval, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3-4 sentences), front-loaded, and every sentence adds value. No redundant or missing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description covers essential return structure, sorting, and benefit scope. It also references a sibling tool for deeper analysis. Slightly lacking mention of pagination limits or date format, but the schema covers those.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with thorough parameter descriptions. The tool description adds minimal new parameter info beyond what the schema already provides (e.g., benefit type examples). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns 'Monthly counts of beneficiaries of CAF social benefits in La Réunion' with specific benefit types listed. It distinguishes from siblings by mentioning combination with reunion_get_caf_amounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use (get beneficiary counts) and suggests a complementary tool (reunion_get_caf_amounts). However, it does not explicitly state when not to use or compare to other similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses the return format (base stats and array of lists) and sorting. It implies a read-only fetch without contradiction. However, it does not state explicitly that it is non-destructive or idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise, front-loading the purpose and including essential details about the election date, aggregation, and return fields. It could be slightly shorter, but it adds necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description thoroughly explains the return values: base voting stats and an array of 38 lists with specific fields (panel number, political nuance, etc.) and sorting. This is complete for a zero-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the baseline is 4. The description adds no parameter details because there are none, but it is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns 'Final results of the European Parliament elections' for a specific department and date, which is unique among siblings. The verb 'get' and resource 'european_2024' are specific, and the description adds detail about the dataset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, but the data is unique (European elections for Réunion) so its context is clear. Missing explicit when-not-to-use or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description discloses the return fields and that each row is one observation period, but does not explicitly state it is a read-only operation or mention any behavioral traits like auth requirements 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no redundant words. It front-loads the core purpose and data source, lists return columns, and ends with use cases. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists all return fields (period, housing units, etc.). It provides data source context and use cases. It is complete for a simple retrieval tool, though could mention if results are limited or aggregated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description naturally does not discuss them. Baseline of 4 is appropriate since the tool requires no configuration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns FTTH deployment coverage for La Réunion region, specifying the data source (ARCEP regional dashboards) and the verb 'get'. It distinguishes from sibling tools by focusing on a specific telecom infrastructure dataset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists use cases: digital-divide analysis, infrastructure rollout monitoring, telecom-investment tracking. It does not provide when-not-to-use or alternatives, but the use cases are clear and appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description compensates well by detailing the return structure: base stats and candidate array with fields. It also notes that R1 elections happen rarely, which is useful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is detailed but front-loaded with essential information. Includes background context that may be helpful, but is still relatively concise for the amount of information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return fields (base stats and candidate array) and includes source attribution. It provides sufficient context for an agent to understand what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description. The tool description does not add significant new semantic information beyond the schema's existing description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns results of the 2024 anticipated legislative elections for La Réunion, aggregated per circonscription. It distinguishes from siblings like reunion_get_legislative_2024_round2 and other election tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the specific election context and explicitly directs users to reunion_get_legislative_2024_round2 for round 2. It provides clear context for when to use this tool, though it does not explicitly list exclusions from other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses it returns aggregated data, elected flag, and 'same schema as round1'. No destructive traits, but no mention of auth or limits. Adequate for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with main purpose, no wasted words. Clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Single optional parameter, no output schema, no annotations. Description covers purpose, behavior, and returns adequately. Missing auth or rate limit info but acceptable for simple get tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% with good description. Tool description repeats 'omit to return all 7' which is already in schema. No additional parameter insight beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns results of the 2024 legislative elections 2nd round in La Réunion, aggregated per circonscription, with elected flag for winners. Distinguishes from round1 and sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use to identify the deputies who won.' Provides clear usage context but lacks explicit when-not-to-use or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the data is sorted year descending and returns median values for two streams. However, it does not disclose whether the operation is read-only, what happens if no data exists, or any authentication or rate-limit constraints. Basic 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each serving a purpose: first describes outputs, second lists use cases. No redundant or extraneous information. Front-loaded with key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple data retrieval tool with two parameters and no output schema, the description covers return data, breakdown, sort order, and use cases. It could mention error handling or data source, but overall sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage, so baseline is 3. The description adds value by noting the data is sorted year descending, which is not in the schema. This enhances the agent's understanding of the output ordering.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns median surfaces and unit costs of social housing operations, broken down by year and operation type. It specifies exact metrics (m², price per m², total cost) and distinguishes itself from siblings like reunion_get_housing_overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists use cases (HLM benchmarking, public-spending analysis, cost evolution monitoring), providing clear context. It does not mention alternative tools or when not to use it, but the specificity makes alternatives obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses key behavioral details: data is monthly since 2017, sorted descending, and includes breakdowns. It implies a read-only query operation. While it could mention side effects or rate limits, it adequately covers the data's nature and structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet informative, with no extraneous words. It front-loads the core purpose, then efficiently adds details on breakdown, sorting, source, and use cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although no output schema exists, the description well explains the output: monthly rows with arrivals by four purpose categories and total spending in EUR. It also notes the source and sorting. Minor omission: it doesn't specify the exact column names or data types, but it is sufficient for understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds minimal context beyond the schema (e.g., '2 years' for limit default). It does not significantly enhance understanding of the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves monthly tourism frequentation data for La Réunion, including specifics on arrivals by purpose and total spending. It distinguishes itself from sibling tools by focusing on tourism data with a specific source and structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions use cases (tourism-policy monitoring, seasonal-trend analysis, economic-impact studies), providing good context. However, it does not explicitly state when not to use this tool or compare it to alternatives, which would enhance guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses sorting (by year descending), source (SINOE/ADEME via data.regionreunion.com), and output fields. It doesn't cover pagination or auth requirements, but for a read-only tool, this is sufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph, no wasted words. Front-loads purpose, then details output, ends with usage suggestions. Perfectly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple data-retrieval tool with 3 optional params and no output schema, the description adequately explains output fields, sorting, and source. It lacks pagination behavior or error handling notes, but overall it's comprehensive enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage. Description adds minor value by listing waste-type examples and noting year is 4-digit, but schema already provides parameter descriptions. Baseline 3 is appropriate as description does not significantly enhance parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states tool returns annual tonnage of DMA waste in La Réunion broken down by waste type, with fields like year, waste-type code/label, tonnage, and department. It clearly distinguishes from sibling tools (e.g., commune profiles, air quality) as the only waste-tonnage tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases: 'Use for waste-policy monitoring, recycling rate analysis.' However, it does not mention when not to use the tool or suggest alternatives. Given the unique nature of this tool among siblings, the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, description discloses sort order (date descending), typical observation frequency (every 3 hours), and all returned fields. No missing behavioral traits for a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with clear purpose, format, field list, sort order, and usage tip. Efficient, though the field list could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully explains return fields with units, sort order, and data source origin. No output schema exists, but description compensates completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions; the description adds only minimal additional context (e.g., station name prefix match examples included in schema). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves Météo-France SYNOP weather observations from La Réunion stations, listing specific fields. It distinguishes from the sibling tool reunion_list_weather_stations by mentioning its use for station discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using reunion_list_weather_stations to discover stations. Provides context for typical use but does not explicitly state when not to use or alternatives beyond that one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It lists returned data (schema, fields, types, title, description, record count, features) but doesn't mention error behavior or side effects. However, as an inspection tool, it's inherently read-only, and the description 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded: first states action and outputs, second gives usage context. No wasted words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one parameter and no output schema, the description adequately covers what the tool does, what it returns, and when to use it. Minor omission of error scenarios, but not critical for a read-only inspection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter dataset_id, with a clear description in the schema. The description adds no extra meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool inspects a dataset and returns schema, title, description, record count, and features. It also distinguishes itself by recommending use before reunion_query_dataset, differentiating it from sibling search/get tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this tool before reunion_query_dataset to know which fields to filter on. Provides a clear use case, though it doesn't specify 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided; the description describes a read-only listing operation with no side effects, which is adequate but lacks details on data source or refresh frequency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states functionality, second lists use cases. No redundancy, information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes output (type, coordinates, projection) and domain context, but lacks data source or size. Sufficient for a simple list tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so baseline is 4; description adds no parameter info because none exist, but this is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists geocoded ecolodge candidate sites in La Réunion with type and coordinates, distinguishing it from all sibling tools that cover different datasets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions applicability for sustainable-tourism planning, real-estate scouting, and regional development studies, but does not include when-not-to-use or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It states the tool fetches records (a read operation) and mentions ODSQL operators, but does not disclose potential issues like performance, authentication, or error handling. The description adds value by naming ODSQL, but the schema already describes the where clause format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three sentences, each serving a distinct purpose: stating the tool's function, providing a prerequisite, and listing supported operators. No unnecessary words or redundancies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description covers the essential aspects: what the tool does, its parameters (via schema), and a prerequisite. It could mention that the where clause must be valid ODSQL and that errors may occur for invalid syntax, but overall it is well-rounded. The presence of many sibling tools reduces the need for exhaustive detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 80% schema description coverage, the description adds meaning by explaining that dataset_id refers to any dataset from data.regionreunion.com, and it provides context for the where clause by listing supported ODSQL operators. This goes beyond the schema's terse descriptions, especially for dataset_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a generic escape hatch to fetch records from any dataset with a raw ODSQL where clause. The name 'reunion_query_dataset' combined with the description distinguishes it from the many specialized sibling tools, as it is the only generic query tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises calling reunion_inspect_dataset first to know available fields, providing a clear prerequisite. The phrase 'generic escape hatch' implicitly suggests it should be used when a dedicated tool is not available, but it lacks explicit guidance on when not to use it or when to prefer a specific sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses sorting by classification date descending, the source (Atout France via data.regionreunion.com), and the scope of accommodations (specific typologies). It does not mention authentication or rate limits but is thorough otherwise.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph but is front-loaded with purpose and covers all essentials without wasted words. Slightly more structure (e.g., bullet points for return fields) could improve readability, but it is concise and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 fully explains return values (commercial name, typology, classification, etc.), sorting, source, and scope. It also covers the limit parameter and types of accommodations. No gaps for the intended use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 minimal extra meaning beyond the schema; it confirms parameters are prefix matches and provides context (e.g., 'typology prefix match'). No significant enrichment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states the tool searches for collective accommodations in La Réunion with official Atout France star classification, lists covered accommodation types, and details returned fields. It clearly distinguishes from sibling tools by focusing on classified accommodations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use the tool (searching for classified accommodations) and provides a comprehensive list of what it covers. It does not explicitly state when not to use or mention alternatives, but the sibling context implies the tool's specific niche.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 details the data source (Ministère de la Santé via data.regionreunion.com) and the fields returned, but does not mention behavioral traits like whether it is read-only, rate limits, or response pagination. This is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, fitting into three sentences. It front-loads the core purpose and enumerates key details without unnecessary verbosity, earning its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters and no output schema. The description covers the return fields, data source, and geographic restriction. However, it lacks information on result ordering, pagination, or error behavior. Given the tool's complexity, it is nearly complete but could be slightly more thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds value beyond the schema by providing examples for 'category_label' (e.g., 'Centre Hospitalier') and clarifying that 'commune' uses prefix match. This enhances an agent's understanding of how to use the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches 'the FINESS national repertory of health and social-care establishments, restricted to La Réunion,' listing specific establishment types and returned fields. This distinguishes it from sibling tools that search other datasets (e.g., health professionals, schools).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly provides context by specifying the geographic scope and establishment types, making it clear when to use this tool. However, it does not explicitly state when not to use it or mention alternative tools for similar searches, such as reunion_search_health_professionals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses the data source (INSEE Sirene via data.regionreunion.com), the restricted scope, and the fields returned. However, it doesn't mention pagination behavior, sorting, or rate limits, which would be helpful for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense paragraph with no wasted words. It front-loads the main action, then details the fields and source. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 and 6 parameters, the description covers the main purpose, restriction, and return fields. It could mention pagination limits or that query is free-text, but overall it is fairly complete for an agent to understand the tool's capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 6 parameters (schema_coverage=100%), so the baseline is 3. The description adds context about the registry and field list but does not elaborate on parameter usage beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the SIRENE v3 national business registry, restricted to La Réunion. It explains the SIRET structure and lists all returned fields, providing a specific verb+resource purpose that differentiates it from sibling search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the geographic restriction to La Réunion and the type of data returned. While it doesn't explicitly state when to use vs alternatives, the context of sibling tools (many other search/get tools) and the specific registry focus make usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses the score range, meaning, sort order (IPS descending), and returned fields. It does not mention data freshness, pagination, or authentication needs, but for a simple data retrieval tool, the disclosed behaviors are sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences. The first sentence states the tool's purpose, the second explains IPS, and the third lists output fields and sort order. It is front-loaded and lacks any filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the output fields (school name, UAI ID, commune, sector, school year, IPS value, IPS standard deviation) and sort order, which is complete for a data retrieval tool without an output schema. It provides all necessary context for an agent to understand what will be returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 4 parameters, so the description does not need to add much. It adds overall context about IPS but does not elaborate on parameter semantics beyond what the schema already provides. The baseline of 3 is appropriate because the schema already documents the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it returns IPS scores for middle schools (collèges) in La Réunion, defines IPS as a 50-200 score, and lists the output fields. It clearly distinguishes from siblings like reunion_get_lycee_ips (high schools) by specifying 'collèges' and mentioning the return fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on what IPS is and when to use it (standard tool to assess school social mix and educational inequality), but does not explicitly state when not to use this tool or mention alternative tools. However, the context implies use for middle school IPS only, and siblings like reunion_get_lycee_ips are separate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description compensates by detailing the output structure (one row per commune per census year, columns including INSEE code, names, populations, surface area, EPCI) and the sorting order. It does not discuss rate limits or caching, but the core behavioral aspects are well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (4 sentences) and front-loaded, with each sentence adding unique information: source, population figures, row structure, and sorting. No redundant or unclear language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully describes the return data (columns, sorting) and the data source. It covers all necessary context for an agent to understand what the tool does and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 100%, the description adds value by explaining the meaning of 'year' as census reference year (millésime) and describing the three population types, enhancing understanding of the parameters' purpose and the data they retrieve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns INSEE official millésimé population counts for La Réunion communes, with specific definitions of three population figures. It distinguishes this from sibling population-related tools like reunion_commune_profile by focusing on multiple census years and detailed breakdowns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for population data queries but provides no explicit guidance on when to use this tool versus alternatives like reunion_commune_profile or reunion_compare_communes. No exclusions or context for when not to use are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses data source (Santé publique France), sorting order (most recent first), and what is returned. Though it lacks details on rate limits or authentication, for a read-only data retrieval tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the core function first, then listing data points, source, and sibling tool guidance. Every sentence is necessary and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple data retrieval tool with no nested objects and full schema coverage, the description is complete. It specifies what columns are returned, mentions the source, and suggests complementary tools. No output schema exists, but the description covers return values adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 context (age class breakdown, daily data) but does not explain parameters beyond what the schema already provides. It adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns daily COVID-19 emergency-room attendance and SOS Médecins activity in La Réunion, broken down by age class, listing specific metrics. It also distinguishes from the sibling tool reunion_get_covid_hospital_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions combining with reunion_get_covid_hospital_stats for in-hospital indicators, providing clear guidance on when to use this tool versus alternatives. It does not explicitly state when not to use it, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses the data source (Santé publique France via data.regionreunion.com), sorting order (most recent first), and the specific metrics returned, adding significant context. It does not mention authentication requirements or error handling, but for a read-only data retrieval tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph but is concise and front-loaded with key information. It could be improved with structured lists, but it avoids fluff and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately explains the return values (list of metrics and sex breakdown) and sorting. It does not detail pagination or empty result behavior, but the limit parameter covers pagination. Overall, it provides sufficient context for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 4 parameters, so the description adds no extra parameter-level meaning. The baseline of 3 is appropriate; the description's listing of metrics provides context about what data is returned but does not enhance parameter semantics directly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool provides daily in-hospital COVID-19 indicators for La Réunion, listing specific metrics (occupied beds, ICU beds, discharges, deaths, new admissions, etc.) and sex breakdown, clearly distinguishing it from the sibling tool reunion_get_covid_emergency_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (for in-hospital stats) and directs users to reunion_get_covid_emergency_stats for ER and SOS Médecins data, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the data structure (one station × one day × one channel), fields returned, sorting (date descending), and combination hint. Though it omits explicit read-only or auth notes, the nature of 'measurements' implies non-destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly written in 3-4 sentences with front-loaded purpose. Every sentence adds value: what it returns, row structure, sorting, and cross-tool hint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (2 parameters, no output schema), the description fully covers return fields, ordering, and usage hint. It provides sufficient context for an agent to understand and correctly invoke the tool without gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are clearly described (station prefix match, limit with range/default). The description adds no extra context beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Daily traffic-flow measurements at fixed automatic counting stations on Réunion's national roads' – a specific verb-resource pair. It distinguishes itself from the sibling 'reunion_get_road_traffic' by noting that tool returns annualized averages, making the purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to 'Combine with reunion_get_road_traffic for annualized averages,' providing clear context for when to use this tool vs. its sibling. While it doesn't formally list exclusions, the guidance is actionable and specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It clearly describes what the tool returns (name, tagline, commune, flags for major, national park, UNESCO, reduced mobility accessibility), implying a read-only, informational operation with no destructive effects. However, it does not explicitly state it is read-only or mention any permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences. The first sentence establishes the tool's purpose and source, and the second sentence lists output fields and use cases. No extraneous information; each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description thoroughly enumerates the return fields (name, tagline, commune, flags, characteristics, accessibility). Given the tool's complexity (three optional parameters, no nested objects), the description is complete and provides sufficient context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the schema already documents all three parameters (commune, major_only, limit). The description does not add semantic value to the parameters beyond what the schema provides; it only lists output fields. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists remarkable tourism landmarks in La Réunion from the SIT Soubik catalog. It specifies the types of landmarks (scenic viewpoints, waterfalls, beaches, etc.) and the returned fields (name, tagline, commune, flags), effectively distinguishing it from sibling tools that focus on other data (e.g., museums, hiking circuits).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context, stating it is useful for 'travel guides, must-see lists, accessibility-aware itineraries.' While it does not explicitly exclude alternatives or state when not to use, it implicitly differentiates from sibling tools by focusing on landmarks; the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses sorting by convention date descending and that each year has a separate dataset, but does not explicitly state idempotency, side effects, or authorization needs. It is adequate but not highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph that packs essential information without redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters and no output schema, the description covers all parameters, return fields, sorting, and dataset years. It is complete enough for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions. The description adds value by clarifying that 'year' selects a separate dataset, 'beneficiary' is a substring search, 'min_amount' is inclusive, and 'limit' defaults to 50 with a max of 500. This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches subventions (grants) awarded to associations by the Commune of La Possession for specific years (2022/2023) and lists the fields returned. This distinguishes it from siblings like reunion_possession_search_procurement (procurement) and reunion_search_associations (general associations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it is 'Useful for transparency analysis, association funding research, public-spending audit,' providing clear context. It does not explicitly state when not to use or list alternatives, but the specificity implies appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks behavioral details such as rate limits, authentication, or pagination behavior, though it describes the source and scope adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences front-loaded with main purpose, no unnecessary words; structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 4 well-documented parameters and no output schema, the description covers purpose, parameters, and context (source, sibling) completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; description adds no new meaning beyond the schema descriptions, only implicitly referencing profession/location filtering.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool searches the CNAM Annuaire Santé for health professionals in La Réunion, lists return fields, and explicitly distinguishes from the sibling tool reunion_search_possession_health_pros.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (find health professionals by profession/location) and when-not-to-use (for posted fees in La Possession, use sibling tool).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes return fields but does not disclose data freshness, pagination, rate limits, or side effects. As a search tool, it is implicitly read-only, but lacks explicit behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-loaded with purpose, contrasts with sibling, and includes source. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description adequately explains what the tool returns (fees, rates, reimbursement base) and its data source. Covers purpose, usage, and output, making it complete for an agent to decide and invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds context about return fields relating to parameters (e.g., fees per act) but does not provide additional parameter-level semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches health professionals in La Possession with fees per act, and explicitly distinguishes from reunion_search_health_professionals. Uses specific verb 'search' and defines unique resource 'health professionals in La Possession with posted fees'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit contrast with sibling tool reunion_search_health_professionals, stating when to use this tool (to estimate costs) versus when to use the sibling (directory-only). Also mentions practical use: estimating out-of-pocket costs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses the return fields (equipment name/code, category, commune, EPCI, year, geocoding quality) and explains search behavior (prefix match, free-text). It implies read-only usage but does not explicitly state safety or rates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loading the function and data source. Every sentence adds value: purpose, categories, return fields, and use cases. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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, the description covers return fields, parameter behaviors, data source, and use cases. It is fully self-contained and leaves no obvious gaps for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds context about the data source (BPE) and prefix matching behavior, but each parameter's meaning is already explained in the schema. The description does not significantly enhance parameter understanding beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the INSEE BPE for La Réunion, listing specific categories. It uses a specific verb ('Search') and resource, distinguishing it from sibling search tools like reunion_search_sport_facilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'accessibility/coverage analysis, market studies, urban planning.' It does not specify when not to use or mention alternatives, but the listed use cases give clear context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry behavioral burden. It declares result is sorted by date descending, rows represent aggregated monthly payouts, and the tool is for analysis (implying read-only). Could be more explicit about side effects (none expected) and date range behavior, but sufficient for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with core purpose. Every sentence adds value: purpose, row structure, use cases, sibling reference, sorting order. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 the output shape (rows with month, benefit type, cumulated payout) and suggests analytical use. Could mention limit effect, but schema covers that. Missing details like column names are minor. Complete enough for confident tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are documented in the schema. The description adds context like 'month × benefit type' implying benefit_type filter, but no detailed parameter semantics beyond what schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states what the tool does: returns monthly total amounts in EUR per social-benefit category. It specifies row structure (month × benefit type) and cumulated payouts. Differentiates from sibling reunion_get_caf_beneficiaries by mentioning amounts vs. beneficiary counts, and explicitly names that sibling for deriving averages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states use cases: public-spending analysis and social-policy monitoring. Provides clear guidance on when to use an alternative tool (reunion_get_caf_beneficiaries) for beneficiary counts and averaging. No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the return fields (period, COICOP code/label, etc.) and sorting order ('sorted most recent first'). It implies read-only behavior and no destructive side effects. While it doesn't mention authentication or rate limits, the description is transparent about the data and behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each serving a distinct purpose: source identification, breakdown and use cases, return fields, and sorting order. It is front-loaded with the most critical information and contains no redundant or vague statements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 optional parameters, no output schema, no annotations), the description covers the main aspects: data source, breakdown, use cases, return fields, and sorting. It lacks details on pagination beyond the limit parameter, but the limit parameter is explained in the schema. The description is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds value by providing example values for coicop_code ('01', '02', '00') and explaining the prefix match behavior. This supplements the schema, which only gives generic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the INSEE monthly consumer price index for La Réunion, broken down by COICOP category and population. It specifies the verb ('get'), the resource ('consumer price index'), and the scope ('for La Réunion'). This differentiates it from all sibling tools, which cover other topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states use cases: 'track inflation, deflate nominal values to real, or compare price evolution across categories.' It indirectly indicates when to use it (any CPI-related task). However, it does not mention when not to use it or alternative tools, but given no sibling does CPI, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It lists all returned indicators and notes the reference year (2014), which adds context. It does not mention data freshness or error behavior, but for a data retrieval tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: two sentences with no redundancy. The main purpose is front-loaded, and the alternative tool is mentioned succinctly. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description lists all return fields. It covers the reference year, IRIS definition, and cross-dataset alternative. While it doesn't discuss pagination or error cases, it is sufficient for a straightforward data retrieval tool with a limit parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description explains the concept of IRIS, which adds meaning to the 'iris' and 'commune' parameters, but does not elaborate on the 'limit' parameter beyond what is in the schema. This provides marginal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides INSEE Filosofi income, poverty, and standard-of-living indicators at IRIS level for La Réunion, specifying the reference year and defining IRIS. It distinguishes itself from the sibling reunion_iris_profile by mentioning a cross-dataset alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use reunion_iris_profile (commune module) for a cross-dataset IRIS view,' providing clear guidance on when to use this tool vs. an alternative, which is excellent for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses that it returns multiple IPS values (GT, pro, combined) with standard deviations, and explains the meaning of higher IPS. It does not hide any behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise; it uses four sentences that each add value. Could be slightly shorter but is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly explains the return fields (school year, UAI, name, etc.) and the unique aspect of separate tracks. It provides sufficient context for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description does not add extra meaning to individual parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns IPS for high schools (lycées) in La Réunion, specifying it is different from colleges by providing separate IPS per track. This distinguishes it from the sibling tool 'reunion_get_college_ips'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for high school IPS and contrasts with colleges, but does not explicitly state when not to use it or list alternative tools. However, the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool returns a combination of IRIS metadata and 2014 income indicators, which is transparent about the data source. It does not mention operational aspects like rate limits or read-only status, but the description is clear about what the tool does and returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. First sentence concisely states purpose and return data. Second sentence provides usage guidance. Extremely efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description must cover return data. It lists specific metadata and income indicators comprehensively. It does not mention return format or confirmation of single output, but given the single-parameter tool, it is sufficiently complete. The description provides all essential information for an agent to understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for iris_code. The description adds value beyond the schema by noting that Réunion IRIS codes start with '974', which provides context for valid inputs. This is a useful addition that helps the agent understand the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns a detailed profile of one IRIS area, listing specific metadata and income indicators. The verb 'Returns' and specific resource 'profile of one IRIS' make it unambiguous. It distinguishes from siblings like reunion_get_income_poverty_by_iris by focusing on a single IRIS.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description tells when to use the tool (to get metadata and income data for a single IRIS) and provides explicit guidance: use reunion_list_iris to discover IRIS codes. It does not explicitly state when not to use it (e.g., for multiple IRIS), but the single-profile nature implies it. Alternatives are not directly mentioned but the hint to discover codes is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses return fields, facility types, and data sources. Does not mention pagination details beyond limit, but overall behavior is well described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first defines core functionality and limitation, second details coverage and use cases. No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, scope, and output fields. No output schema, but description lists key fields. Could add pagination behavior, but limit parameter is in schema. Overall sufficient for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions (100% coverage). Description adds context on why only two communes are available and what data is returned, adding value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specifies verb 'list', resource 'early-childhood care facilities', geographic scope (two communes), types of facilities, and return fields. Clearly distinguishes from siblings like reunion_search_schools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'currently the only two communes publishing this dataset', giving clear context on applicability. Does not explicitly mention when not to use, but the constraint 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses return fields (RNA ID, SIRET, title, etc.), sorting (most recent first), and data source. It provides comprehensive behavioral context for a read-only search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative and well-structured, though slightly dense. It front-loads purpose and returns, but could be slightly more concise without losing detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly explains all return fields, sorting, and source. For a search tool with four optional parameters, it covers necessary context for the agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description largely restates parameter descriptions from the schema without adding new information. The baseline of 3 is appropriate as the description adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the RNA for La Réunion, specifies the type of associations (1901 law), lists return fields, and includes source details. It uniquely identifies its purpose among many sibling search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding association data in La Réunion, but does not explicitly mention when to use it over alternatives or provide exclusion criteria. However, the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone carries full burden. It mentions the source (Ministère de l'Intérieur RNE) and indicates read-only search behavior, but lacks details on rate limits or pagination behavior beyond the limit parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose, then lists officials and fields, then cites the source. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description covers purpose, parameters, return fields, and data source. It is complete enough for an agent to decide to use, though it could provide more on read-only nature or typical usage hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 listing return fields and providing examples for function_label, which helps the agent understand query impact beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches the registry of local elected officials for La Réunion, listing specific types of officials and return fields, which distinguishes it from sibling tools like reunion_search_admin_directory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies what types of officials can be searched and the available filters, but does not explicitly mention when not to use this tool or suggest alternatives, though siblings imply different scopes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: parallel fetching, row-per-commune output, and list of indicators. It lacks error handling or rate limit details, but adequately covers the main 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with five short sentences, each adding value, front-loaded with purpose, and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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, the description covers purpose, indicators, parallel fetching, output structure, and provides usage context, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description adds no extra parameter semantics beyond the schema's 'case-sensitive prefix match' detail, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs side-by-side comparison of 2-5 communes on specific indicators, distinguishing it from the sibling reunion_commune_profile for deep dives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use (benchmarking, demographic studies, policy targeting) and when to use an alternative (reunion_commune_profile for deep-dive), providing excellent guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 states the output schema matches round1 and lists key fields (commune, circonscription, bureau de vote, candidate identity, counts, vote share) and sorting order (by vote count descending). This sufficiently discloses what the tool returns without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph that front-loads the tool's purpose and includes essential details without redundancy. Every sentence adds value, and it avoids unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only data retrieval tool with a well-documented schema, the description covers all necessary aspects: election identity, schema reference, field list, sorting, and practical use case. It does not require an output schema because the fields are explicitly listed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 4 parameters with descriptions. The description adds clarifying context beyond the schema, such as commune is a 'name prefix match', circumscription is a 'label prefix match', polling_station is an 'exact code', and limit has a max of 500 and default of 100. This enhances usability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool returns per-polling-station results for the June 19, 2022 legislative elections, 2nd round, for La Réunion. It references the same schema as reunion_get_legislative_2022_round1, clearly distinguishing it from other legislative tools by election and round.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating the tool is useful for identifying elected deputies (top vote per circonscription). It implies when to use the tool but does not explicitly state when not to use it or provide alternatives, though siblings are contextually different.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that it lists administrative attributes and includes year reference. Does not mention side effects, auth, or rate limits, but for a read-only list tool these are typically implied. Adds context beyond raw schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences: first defines purpose and output, second gives usage context and alternative. Every word earns its place; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description fully describes return fields (name, INSEE code, EPCI, etc.) and includes the specific count (24). References a related sibling tool. Complete for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions (epci_name with EPCI list, limit with default and max). The description adds no additional parameter information, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List the 24 communes of La Réunion with their full INSEE administrative attributes', specifying the verb (list), resource (communes), and scope (24, attributes). Distinguishes from sibling reunion_find_commune by explicitly mentioning its use for fuzzy resolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool (for territorial joins, statistical aggregation) and points to an alternative (reunion_find_commune for fuzzy commune resolution). Clearly sets context of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description correctly indicates this is a read-only operation by stating it 'lists' and returns specific data fields. It does not disclose potential side effects or limitations, but for a list tool, the behavior 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the main action, followed by return details and use cases. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description fully explains the tool's output (type, surface, decree) and its relevance. It is complete for an agent to decide when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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% (trivially). Per the guidelines, a baseline of 4 is appropriate since no parameter information is needed beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists official perimeters of Parc National de La Réunion, specifying the two zones (core and adherence) and the returned fields. This uniquely distinguishes it from sibling tools, as no other tool covers national park perimeters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage contexts: 'environmental impact assessment, hiking-permit logic, conservation analysis.' It does not mention when not to use or alternatives, but the context is clear and relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It accurately describes a read operation (search catalog) and mentions scale (~270 datasets). Minor lack of detail on return structure, but sufficient for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second provides usage flow. No redundant information, each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with 4 parameters and no output schema, the description provides sufficient context: catalog size, usage flow, and link to follow-up tools. No gaps that hinder correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 75% of parameters (query, theme, publisher) with clear explanations. The description only echoes 'keywords and/or theme' from schema, adding no significant new meaning beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the full catalog (~270 datasets) by keywords and/or theme, and distinguishes itself from sibling tools by specifying it is for discovering datasets not covered by dedicated tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (discover datasets not wired to a dedicated tool) and what to do next (call reunion_inspect_dataset and reunion_query_dataset), providing clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It discloses data source (Sitadel), sorting (by authorization date descending), and return fields comprehensively. However, it does not explicitly state that the tool is read-only, mention rate limits, or discuss pagination beyond the `limit` parameter. It is adequate but not fully exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose first, then detailed output fields, sorting, use cases, and sibling differentiation. It is concise yet comprehensive, with every sentence adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully compensates by listing all return fields, their format, and sorting. It covers input parameters implicitly, and the tool's use cases and alternative are clearly stated. The description is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so baseline is 3. The description adds minor context (e.g., 'filters out small projects' for `min_dwellings`) but does not significantly enhance parameter understanding beyond the schema. No additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches residential permit applications for dwellings in La Réunion using the Sitadel database. It distinguishes itself from the sibling `reunion_search_building_permits` by explicitly mentioning that for non-residential permits, that alternative tool should be used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool ('housing-supply analysis, market intelligence, developer tracking') and when not to ('For non-residential permits use reunion_search_building_permits'), offering a clear alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses deduplication and timestamp inclusion, but does not mention potential empty response, pagination, or rate limits. However, given zero parameters and simple list behavior, the coverage is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. First sentence delivers core purpose, second sentence provides usage context. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers purpose and usage well. Missing explicit description of output fields beyond 'station name + WMO number + last-observation timestamp', but still sufficient for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (0 params, 100% schema coverage). The description adds no parameter details, which is fine as there are none. Baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List all distinct Météo-France SYNOP synoptic stations active in La Réunion' with specific details (deduped, includes timestamp). Distinguishes from sibling reunion_get_weather_observations by implying a discovery-to-query workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Use this first to discover which stations are available before calling reunion_get_weather_observations with a specific station name', providing direct guidance on when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description describes the output structure and sorting order, sufficient for a safe search tool. No annotations provided, but the description covers expected behavior without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with two paragraphs: first explains purpose and output, second gives sibling guidance. No redundant or confusing sentences, though slightly lengthy for a search tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description lists all returned fields and notes sorting order. All 5 parameters are fully described or exemplified, making the tool's behavior completely understandable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value by providing examples for 'nature' and 'procedure' parameters, clarifying the free-text search on 'query', and stating the default limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches public-procurement contracts awarded by the Commune of La Possession in SCDL format. It lists the fields returned and distinguishes itself from the sibling tool reunion_search_boamp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool vs. the alternative: 'For BOAMP-published notices (broader than just Possession), use reunion_search_boamp.' This provides clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It details the return fields (commune INSEE, zone code, label, type, etc.) and data source (GPU via data.regionreunion.com). It implicitly indicates this is a read-only search, but does not explicitly guarantee no side effects or mention rate limits or error behavior. Overall, it provides good 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each serving a clear purpose: purpose, row structure, returned fields, and use cases. No redundant information, and key details are front-loaded. Perfectly concise for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains the return fields. Parameters are well-covered by both schema and description. The tool's role in urban planning research is clear. While pagination or empty results aren't mentioned, the limit parameter and search nature make these implicit. Overall, it covers all essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter docs. The tool description adds significant value: examples for INSEE codes (e.g., '97411' Saint-Denis) and explanations of zone_type codes (U, AU, A, N). This enriches understanding beyond the schema, especially for domain-specific codes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the permanent PLU zoning database for La Réunion. It specifies the verb 'Search' and resource 'PLU zones', providing distinct context from sibling tools like reunion_search_catalog or reunion_query_dataset. The detailed explanation of each row (zone code, type, etc.) reinforces its unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context, labeling the tool 'Essential for real-estate due diligence, project siting, urbanism research.' It implies when to use but does not explicitly state when not to use or mention alternatives like other search tools. However, the specificity of PLU zones makes the use case obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the data source (GTFS routes.txt) and exactly what fields are returned (route_id, short name, long name, route_type, brand color, official URL). There is no annotation to contradict, and the tool is clearly read-only with no hidden side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise — two sentences. The first sentence states purpose and data source; the second lists return fields and a related tool. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 fully covers what the tool does, what data it returns, and where to go next (reunion_search_car_jaune_stops). It is self-contained and sufficient for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage (empty schema), the tool needs no parameter explanation. The description adds value by defining the scope and output, earning a baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('bus routes of the Car Jaune network'), making the tool's purpose immediately clear. It distinguishes from related tools by suggesting use of reunion_search_car_jaune_stops for finding stops.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use the tool (list all routes) and indirectly guides when to use a sibling tool (find stops via reunion_search_car_jaune_stops). It does not explicitly state when not to use it, but for a zero-param list tool, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 discloses the returned fields (EPCI code, name, current code, type, department, region, year reference) and notes that it handles regroupings. For a list tool with no parameters, this is comprehensive and transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loading the purpose and adding context without redundancy. Every sentence serves a purpose: stating the function, providing regional background, and listing outputs with usage. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains what the tool returns (list of fields) and gives geographic context about Réunion's EPCI structure. It is complete for a simple list tool with zero parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description cannot add parameter details. Baseline for 0 params is 4. The description adds value by explaining the output, which is more than minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List EPCI' with a specific verb and resource, and distinguishes this tool from siblings by explaining its use for aggregating commune-level data at the inter-municipal level. The background about Réunion's five communautés d'agglomération adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use to aggregate commune-level data at the inter-municipal level', providing a clear use case. It does not mention when not to use it or compare to alternatives like reunion_list_communes, but the context is sufficiently clear for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the return fields and context of the designation (scientific standards, public access, inalienability). No annotations exist, but the description sufficiently conveys read-only behavior. Lacks explicit mention of completeness or pagination, but these are inferred for a parameterless list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, front-loaded sentences with no redundancy. Every sentence serves a purpose: statement of function, context of designation, return fields and sibling guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description fully covers what the tool does, what it returns, and how to use related tools. Context about the designation adds meaningful depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema; description adds no param info (not needed). Schema coverage is 100% vacuously. Baseline 4 is appropriate as description adds value through return field listing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly specifies the verb 'list' and resource 'museums with Musée de France designation'. Distinguishes from sibling tools like reunion_get_museum_attendance and reunion_search_joconde_collections by explicitly referencing them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use this tool for museum listing, and use reunion_get_museum_attendance for attendance data or reunion_search_joconde_collections for artwork records.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses key behavioral traits: joining 8 sources in parallel, inline error handling for individual failures, and the specific data included. There is no contradiction with annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative and well-structured, listing the 8 sources compactly and including usage notes. While it is somewhat long, every sentence adds necessary context, so it earns a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parallel sources, inline error handling) and lack of output schema, the description is remarkably complete. It explains what data is returned, how errors are reported, and provides cross-references to related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 clarifying that the commune parameter is a 'case-sensitive prefix match' and provides examples, which goes beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a 'Comprehensive cross-dataset snapshot of one La Réunion commune' and lists the 8 sources joined, making the purpose unmistakable. It also distinguishes itself from sibling tools like reunion_compare_communes and reunion_find_commune.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to 'use reunion_find_commune first if the commune name might be misspelled' and 'For side-by-side multi-commune comparison use reunion_compare_communes', offering 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It thoroughly discloses behavior: fuzzy matching, handling of common variations, and return fields (INSEE code, EPCI, department, region). There is no suggestion of destructive or write behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that efficiently conveys the tool's purpose, handling, and usage guidance. It is appropriately sized and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions return fields, explains fuzzy behavior, and provides usage context. For a simple resolver, it is complete and leaves no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema description covers 100% of the single parameter with examples, the description adds context about the fuzzy matching logic and the types of variations it handles, enriching the semantic understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a fuzzy resolver for La Réunion commune names, specifying the types of variations handled (case, accent, abbreviation, punctuation). It distinguishes itself from sibling tools by stating that it should be called first when uncertainty exists, before using tools requiring exact prefix matches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('always call this first when a user provides a commune name with any uncertainty') and what not to use it for (before passing to commune-filtered tools expecting exact matches). It implies that alternatives are those exact-match tools by stating 'before passing to commune-filtered tools'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

mcp-reunion MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![mcp-reunion MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/Hug0x0/mcp-reunion/badges/card.svg)](https://glama.ai/mcp/servers/Hug0x0/mcp-reunion)

Score Badge

Copy to your README.md:

[![mcp-reunion MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/Hug0x0/mcp-reunion/badges/score.svg)](https://glama.ai/mcp/servers/Hug0x0/mcp-reunion)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Hug0x0/mcp-reunion'

If you have feedback or need assistance with the MCP directory API, please join our Discord server