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 side effects, API calls, potential errors, or whether the tool actually executes searches or just provides queries. The phrase 'to run next' hints at behavior but leaves ambiguity. This is insufficient for a composite tool.

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

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

The description is a single, grammatically complete sentence that front-loads the primary verb ('Create') and resource, then lists components concisely. It avoids redundancy and is easy to parse.

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

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

With no output schema, the description must explain what the returned brief contains. It lists main components but does not specify the structure, format, or behavior (e.g., whether it returns a plan or an executed brief). The term 'to run next' is vague and could mislead. More detail is needed for a tool of this complexity.

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

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

Schema coverage is 100% for the single parameter `code_insee` with description 'Commune INSEE code.' The tool description adds no extra meaning beyond this, so the baseline of 3 applies. No examples or format hints are given beyond the schema.

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

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

The description clearly states it 'Create[s] a source-oriented local-risk brief for a commune' and lists specific components (geo.api identity, Géorisques links, data.gouv search queries). This distinguishes it from sibling tools that perform individual operations like get_sources or search_data_gouv, making the purpose unambiguous.

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

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

The description implies a composite use case (brief with multiple sources) but does not explicitly specify when to choose this over calling individual sibling tools. It lacks 'use this instead of X' guidance. Only a general context is provided, so it is not fully explicit.

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

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

No annotations are provided, so the description carries the full burden. It states it 'explains', which implies a safe, read-only operation, but it doesn't mention any side effects, network requests, or response format. For a simple explanatory tool, this is acceptable but not deeply transparent. It doesn't contradict annotations (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.

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

The description is a single, focused sentence with no filler. It front-loads the core purpose and usage guidance. Every word earns its place, making it appropriately concise.

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

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

Given the tool's trivial complexity (no params, no output schema), the description provides enough context for an agent to know when to call it. It would be slightly better if it hinted at what the explanation covers (e.g., list of sources or usage patterns), but it is sufficiently complete for its simple role.

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

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

The tool has zero parameters, so the baseline is 4. The description doesn't need to explain parameters since there are none. It correctly omits parameter details.

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

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

The description clearly states the tool's purpose: it explains what the MCP is useful for and how to combine sources. The verb 'explain' and specific resources ('MCP', 'sources') make it distinct from sibling tools that fetch data. It's unambiguous and differentiates from the other tools.

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

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

The description implies usage: it's for an agent to understand how to combine sources, likely before using other tools. However, it doesn't explicitly state when not to use it or name alternatives. The guidance is clear enough for this self-explanatory meta-tool, though it could explicitly say 'use this to get an overview before querying data'.

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

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

No annotations are provided, so the description carries the full burden. 'Fetch' implies a read-only operation, but the description does not explicitly state side effects or permissions. While it is likely harmless, the absence of explicit non-mutating language makes it only moderately transparent.

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

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

The description is concise, consisting of two sentences that clearly state the action and provide a usage tip. It is front-loaded with the primary purpose and includes no unnecessary details.

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

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

The description is sufficient for a simple two-parameter tool. It explains what to do and how to specify the source. Though no output schema is given, the phrase 'short text excerpt' implies the return type. It does not overly elaborate but covers essential information.

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

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

Both parameters are well described in the schema: source_key explains its possible formats ('index, title keyword, or URL fragment'), and max_chars defines its bounds. The tool description reinforces this by specifying that source_key comes from get_sources. This exceeds the baseline for high schema coverage.

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

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

The description clearly states the tool's function: to fetch a short text excerpt from a curated source URL. It uses the verb 'Fetch' and specifies the resource (source URL), making the purpose unambiguous. It also differentiates from sibling tools by focusing on excerpts.

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

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

The description provides a specific usage hint: 'Use source_key as a number, title keyword, or URL fragment from get_sources,' which guides the user on how to obtain the required parameter. It implies when to use this tool (when an excerpt is needed) but does not explicitly contrast it with alternatives like get_sources for full lists.

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

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

With no annotations provided, the description carries full behavioral burden. It does disclose the external dependency (geo.api.gouv.fr), which is a useful signal for availability/latency expectations. However, it doesn't note behavior on ambiguous or multi-match inputs (e.g., returns multiple candidates via limit), error handling for unknown codes, or rate-limiting concerns with the third-party service. The external URL mention earns it a 3, but richer behavior around matching/failures is undocumented.

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

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

Two sentences, no filler. First sentence delivers the core action and contract; second provides usage timing. Every word earns its place, and the structure front-loads the most important information about resolution semantics.

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

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

No output schema exists, so a description of what the resolution returns (e.g., a commune identifier/code that other tools consume) would add value. For a 2-parameter lookup tool, the description is nearly complete, but noting the return semantics would close the loop on its utility for chaining into sibling tools. It's adequate but not exceptional.

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

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

Parameter schema coverage is 100% with clear inline examples for query and a description for limit. The description's phrase 'by name, INSEE code, or postal code' reinforces the query parameter's purpose, but the schema already captures this with examples. The limit parameter is self-explanatory with a clear constraint hint in the schema. This meets the baseline with marginal added value.

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

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

Description uses a specific verb ('Resolve') with a clear resource (French commune) and enumerates the identifier types (name, INSEE code, postal code). It distinguishes this tool from siblings like local_risk_france_commune_brief by positioning it as the resolution step for other commune-specific queries. The phrase 'Useful before querying local risk sources' further anchors its unique role in the pipeline.

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

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

Description says it's 'useful before querying local risk sources,' which conveys clear workflow context for when to invoke it. However, it doesn't name specific alternatives from the sibling list (e.g., local_risk_france_search_data_gouv or local_risk_france_search_risk_datasets also deal with searching) or explain when NOT to use this tool, such as when a search-like tool would be more appropriate. It stops short of a 4 because there's no explicit exclusion or alternative naming, though the positional guidance is genuinely useful.

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

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

No annotations are provided, so the description carries full responsibility for disclosing behavior. It says 'Inspect' (implying read-only) and 'using the official public API' (suggesting no auth), but it doesn't explicitly confirm data is not modified, nor does it mention any potential limitations like response size or rate limits. This is insufficient for a tool with zero annotation coverage.

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

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

The description is a single, concise sentence that conveys the essential purpose and method. There is no extraneous information, making it efficient and front-loaded.

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

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

The tool has a single parameter, no output schema, and no annotations. The description adequately covers the core operation and context, but it could be slightly more complete by stating what the inspection returns (dataset metadata) or any prerequisites. However, for a simple get operation, it's mostly sufficient.

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

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

The input schema already describes the only parameter ('Dataset slug or id') with 100% coverage. The description adds no further meaning—it merely repeats the concept of identifying a dataset. Per the rubric, high schema coverage sets a baseline of 3, and no extra value is provided.

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

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

The description clearly states the tool's function: to inspect a single data.gouv.fr dataset by slug or id. The verb 'Inspect' and the resource 'dataset' are specific, and the mention of 'slug or id' distinguishes it from sibling tools like search or get_sources.

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

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

The description clearly implies the tool is for direct lookup of a specific dataset by identifier, which differentiates it from search-oriented siblings. However, it doesn't explicitly state when not to use it or mention alternative tools for other use cases, so it stops short of full guidance.

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

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

No annotations are provided, so the description carries the burden. It does convey that the output consists of official, public links and that the tool is appropriate for authoritative risk review, implying a safe, read-only operation. However, it does not disclose behavior such as whether network calls are made, how links are returned, or what happens with invalid INSEE codes.

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

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

Two short sentences communicate the action, target, scope, and intended use without wasted words. The description is front-loaded with the core purpose and ends with a value statement.

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

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

The tool is simple: one required parameter, no output schema, and no nested objects. The description explains what is built and why it is useful, which is largely sufficient. A small gap is the lack of explicit return format or error behavior, but the low complexity makes this non-critical.

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

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

Schema description coverage is 100%, so the schema fully documents the code_insee parameter, including its pattern and example values. The description only reinforces that the parameter is a single commune INSEE code, adding no meaning 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.

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

The description uses a specific verb ('Build') and resource ('official Géorisques and related public links') for a clearly scoped input ('one commune INSEE code'). This distinguishes it from sibling tools that fetch sources, search datasets, or retrieve risk values, as the focus here is specifically on generating official links.

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

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

The description gives clear context: the tool is for building official links for a single commune INSEE code and is suitable for authoritative risk review. It does not explicitly name alternatives or state when not to use it, but the use case is clear enough given the sibling tool names and the explicit single-commune scope.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It correctly identifies the tool as a fetch (read operation) and notes that v1 is public without token, which is helpful. However, it does not describe what the response contains, how errors are handled, or any potential rate limits or side effects, leaving the agent with incomplete transparency.

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

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

The description is exactly two sentences, front-loaded with the core purpose. The note about public endpoints is concise and relevant. There is zero redundancy or filler, making it highly efficient.

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

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

Given the tool's simplicity (one required parameter, no output schema, no annotations), the description provides the essential information: what it fetches and the authentication requirement. It omits details about the response format or error behavior, but these are less critical for a straightforward fetch operation. The description is sufficiently complete for an agent to use the tool without confusion.

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

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

The input schema already fully describes the sole parameter (code_insee with pattern and description 'Commune INSEE code.'). The tool description repeats this but adds no additional meaning or nuances. With 100% schema coverage, the baseline of 3 is appropriate, as the description adds no extra value beyond the schema.

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

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

The description clearly states the action (fetch), the resource (official Géorisques v1 radon potential), and the specific scope (for a commune INSEE code). This distinguishes it from sibling tools that handle other risk types or data sources, making the purpose immediately unambiguous.

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

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

The description implicitly signals when to use the tool (when radon potential for a commune is needed) but does not explicitly contrast it with alternatives or mention exclusions. The note about v1 endpoints being public without token provides some context but does not address when to prefer this over sibling tools like get_seismic_zoning.

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

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

No annotations are present, so the description carries the full burden. It discloses that v1 endpoints are public (no auth required), which is a useful behavioral trait. However, it does not mention error handling, response format, or any side effects, so it's only partially transparent.

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

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

The description is extremely concise: two sentences. The first sentence states the action and resource clearly, and the second provides a key detail (public access). No filler words or redundant information.

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

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

The tool is a simple read-only fetch with one parameter and no output schema. The description covers the purpose and access requirements. It lacks explicit mention of return format or error behavior, but for such a simple tool, it is mostly complete. The public-access note adds context beyond the schema.

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

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

The schema already fully describes the single parameter (code_insee) with type and pattern. The description adds no additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate given 100% schema coverage.

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

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

The description clearly states the action ('Fetch official Géorisques v1 seismic zoning') and the specific resource (a commune INSEE code). It is unambiguous and distinguishes from siblings like get_radon or get_georisques_links by the specific data type.

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

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

The description implies usage context (need seismic zoning for a commune) but does not explicitly state when to choose this over alternatives. The note about 'v1 endpoints are public without token' provides some guidance on access, but no exclusion criteria or comparative advice are given.

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

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

No annotations are provided, so the description must carry the burden. It discloses that the list is curated (implying a selection bias) and that the tool is read-only ('List'), but it does not mention any limits, pagination, or whether the sources are static or dynamically fetched. Basic transparency is present, but more detail would be needed.

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

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

The description is a single concise sentence that is front-loaded with the verb and object. Every word contributes: 'curated' and 'high-value' add value, and the geographic scope is clear. No wasted text.

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

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

This is a very simple tool with no parameters and no output schema. The description fully covers what the tool does in a way that is sufficient for an agent to select it and understand its basic behavior. For a list endpoint, no further details about return format are strictly necessary given the tool's simplicity.

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

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

The tool has zero parameters, so the description does not need to elaborate on parameter meanings. The baseline of 4 applies because with no parameters, there is nothing to clarify beyond the schema, which is already empty.

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

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

The description clearly states the action (List), the object (curated official and high-value sources), and the scope (for local risk France). It is specific and distinguishable from sibling tools that retrieve datasets or specific links, making the purpose immediately apparent.

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

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

The description implies this tool is used to get an overview of curated sources, but it does not explicitly state when to use it versus alternatives such as get_georisques_links or search_risk_datasets. There is no guidance on exclusions or context, leaving the agent to infer usage from the name and sibling list.

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

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

With no annotations provided, the description carries the full burden. It only says 'when available', implying variability but without specifying what happens if unavailable, whether it's a read operation, or what kind of data it returns. For a tool that lists items, this is insufficient.

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

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

The description is a single compact sentence that states the tool's function without fluff. It is appropriately sized for a zero-parameter tool, though it could be slightly more explicit about the output.

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

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

Given the simplicity (no parameters, no output schema), the description is minimally adequate. However, it lacks detail on what 'reference items' specifically are, which could confuse an agent. It doesn't explain additional context like whether these are static or dynamic, but for a simple listing tool it's acceptable.

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

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

The tool takes zero parameters manageable by the schema. Since there are no parameters, there is nothing for the description to add beyond what the schema shows. Baseline for 0 parameters is 4, and the description doesn't mislead.

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

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

The description clearly states the verb 'List' and the resource 'built-in reference items for this MCP', which distinguishes it from sibling tools that fetch external data. However, 'when available' introduces ambiguity about whether it always returns something, slightly reducing clarity.

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

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

No guidance is given on when to use this tool versus alternatives like get_sources or search_data_gouv. It simply states its purpose without context or exclusions.

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

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

With no annotations provided, the description should disclose behavioral details such as read-only nature, pagination, rate limits, or output format. It simply states 'search' with no additional context, adding nothing beyond the tool name itself, which is nearly a tautology.

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

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

The description is a single, concise sentence that is front-loaded and free of fluff. It earns its place by conveying the core action, though it could be more informative without sacrificing brevity.

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

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

This is a simple tool with only two parameters and no output schema, but the description fails to explain what the response will look like or any constraints on usage. Without annotations or output schema, it is insufficiently complete for an agent to fully anticipate outcomes or limitations.

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

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

Schema description coverage is 100%, so the parameters 'query' and 'page_size' are already documented. The description adds no extra semantic value beyond the schema, which meets the baseline but does not enhance the agent's understanding of parameter nuances.

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

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

The description clearly states the tool searches public datasets on data.gouv.fr using the official API, with a specific verb and resource. However, it does not distinguish itself from sibling tools like 'local_risk_france_search_risk_datasets', which likely serves a similar purpose, so it misses the mark for full differentiation.

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

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

There is no guidance on when to use this tool versus alternatives. The description merely states what it does without any context on preferred scenarios, prerequisites, or tools to avoid, leaving the agent to infer usage.

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

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

With no annotations provided, the description must carry the burden of explaining the tool's behavior. It clearly states the tool searches data.gouv.fr and combines search terms, which is useful context. However, it doesn't disclose expected behavior around edge cases, such as what happens when no place is provided, how results might be ordered, or if there are any rate limits or authentication requirements. The description is functionally informative but lacks deeper behavioral disclosure.

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

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

The description is a single, concise sentence that efficiently conveys the tool's primary function. It avoids unnecessary details and is appropriately brief for a tool with a well-defined schema. The structure is clean and directly addresses the core functionality without extraneous information, though it could potentially add a note about its relationship to sibling tools without becoming too long.

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

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

The description is complete for a simple search tool with a well-defined schema and no output schema. It knows its target API and general behavior. However, it lacks clarity on the connection to the sibling tool 'local_risk_france_search_data_gouv', and doesn't explain the value proposition of this specific tool over its sibling, which would be valuable context for an agent choosing between them.

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

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

The input schema offers 100% coverage with descriptions for all three parameters. The description adds minimal value beyond the schema's parameter descriptions, essentially restating the combination logic for 'topic' and 'place'. Since the schema is comprehensive, a baseline score of 3 is appropriate, and the description doesn't need to repeat the information.

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

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

The description uses a specific verb ('Search') with a clear resource ('data.gouv.fr for local-risk datasets') and indicates a two-part query construction ('combining a risk topic and optional commune/departement context'). This provides a solid understanding of the main function. However, it doesn't explicitly differentiate itself from the sibling 'local_risk_france_search_data_gouv', which could be a closely related search tool, creating some ambiguity about the exact distinction.

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

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

The description implies its usage context by mentioning the combination of topic and place, suggesting it's for when both dimensions are relevant. However, it provides no explicit guidance on when to use this tool versus its siblings like 'local_risk_france_search_data_gouv' or 'local_risk_france_get_sources'. There's no mention of when not to use this tool or what alternative tools might be more appropriate in different scenarios.

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