Mitoyens, pesticides près de chez vous

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

Annotations already declare readOnly/idempotent/closed-world, so the safety profile is covered. The description adds genuinely non-obvious behavior: rows with ambiguous or unresolvable codes return an "options" field of candidate communes with their département instead of indicators, which changes how an agent must handle the response.

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 first sentence is dense and front-loaded with the essential contract, including the error/fallback shape. The second paragraph is provenance and licensing metadata; it is short and arguably relevant to non-commercial use, but it is the least load-bearing part of the 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?

With no output schema, the description carries the burden of describing the return shape and does so, including the alternate "options" response. Data vintages (RPG 2025, BNVD 2024) help interpretation; only row ordering/field naming details are left unstated.

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

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

Schema coverage is 100% and the single parameter already documents 2–5 INSEE codes or slugs, so the description's "Codes = INSEE ou slug" is essentially a restatement. It adds only the connection between code ambiguity and the fallback output, not new parameter semantics.

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

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

States a concrete output (aligned comparison table) over a specific resource (2 to 5 communes) with named indicators (exposition, parcelles, bio, écoles, achats BNVD). This is clearly distinct from single-commune siblings like get_commune_exposure or get_school_proximity, though no sibling is named explicitly.

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 2–5 cardinality and accepted code formats are stated, and the ambiguous-code fallback is described, but there is no explicit guidance on when to pick this over rank_communes or the per-indicator tools. Usage is implied by the shape of the output rather than stated.

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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. What the description adds beyond them is genuinely operational: the CC BY-NC 4.0 non-commercial licence, the upstream source (Mitoyens), and per-dataset vintages (RPG 2025, BNVD 2024 frozen at 31 Dec 2024, Rigal & Perrot 2025 covering 2013-2022, SISE-Eaux 2025), which tell the agent the data is historical rather than live.

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 payload enumeration is front-loaded and dense, and each clause carries distinct content. The provenance block is long for a license/vintage footnote but every element in it (source, licence, four dataset vintages) is information the agent cannot get from the structured fields, so it earns its space.

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 carries the full burden of describing the return value, and it does — listing the three result sections and the sub-fields inside the crop profile. Combined with annotations covering the safety profile and a fully documented single parameter, an agent has enough to call it correctly and interpret the response.

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?

There is one parameter with 100% schema description coverage, so the schema already explains the metropolitan department code and gives an example ('33'). The description adds nothing about the parameter, not even that overseas/non-metropolitan codes would fail — baseline 3 applies.

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

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

The description names a specific resource and enumerates its payload precisely: exposure index, BNVD tonnages broken out by CMR/herbicides/fungicides/insecticides, and per-crop treatment profile with IFT, dominant function and substances. The department-level scope separates it from the commune-level siblings, though that distinction is carried mostly by the name rather than stated explicitly.

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 sentence states when to reach for this tool versus get_commune_exposure, rank_communes or search_communes. Usage is only implied: the word 'départemental' plus a single 'dept' parameter signals this is the department-level rollup, while every sibling is commune-scoped. An agent can infer the routing but the description does none of the routing work itself.

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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered; the description adds real context beyond that: the data sources and vintages (RPG 2025, BNVD 2024 as of 31 Dec 2024, Rigal & Perrot 2013-2022, SISE-Eaux 2025), the non-commercial CC BY-NC licence, and the ambiguous-input fallback behavior.

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

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

Purpose and the identifier rule are front-loaded in the first two sentences, with attribution and data vintages trailing. The source/licence block is long but serves a genuine compliance and trust role; it could be tightened without losing information.

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

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

For a read-only, idempotent single-record lookup with 100% schema coverage and no output schema, the description covers what is returned (the exposure-sheet components), the ambiguous-input path, the data vintage of each source, and licensing — enough for an agent to call it correctly and interpret the result.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds semantics the schema does not encode: the mutual exclusivity rule ("un seul parmi insee, code_postal ou slug") is absent from the schema, which marks all three as optional with no oneOf/anyOf, and the shared-code_postal → "options" response is explained only here.

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 states a specific verb+resource: it produces an exposure sheet for a single commune, and enumerates the exact content (combined Rigal & Perrot index, farmland within 1 km, nearby schools, BNVD purchases, chemical profile). That content list implicitly separates it from compare_communes, rank_communes and search_communes, but no sibling is named explicitly, so it stops short of a 5.

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

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

It gives a strong constraint on how to call it — exactly one of insee, code_postal or slug — and explains the shared-postal-code fallback returning an "options" field. It never says when to prefer this tool over compare_communes or show_commune_map, so the guidance is implied by the data returned rather than stated.

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?

Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: nearest-field results are capped at 5, the radius is 500 m, and ambiguous postal codes return an 'options' envelope instead of failing. The licensing line ('usage non commercial', CC BY-NC 4.0) is a real usage constraint, but no error/permission or empty-result behavior is described.

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 first two sentences are dense, front-loaded and every clause earns its place. The closing provenance block, however, lists BNVD 2024, the Rigal & Perrot index and SISE-Eaux tap-water data — sources unrelated to this tool's outputs — which is padding that competes for the agent's attention.

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?

There is no output schema, and the description compensates by enumerating the returned fields (distance, direction, crop, 500 m parcel count, area, organic parcels, dominant crops with readable labels) plus the 'options' response shape. Missing only failure behavior: what happens with no identifier, an unknown INSEE code, or a commune with no schools.

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

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

Schema coverage is 100%, so the baseline is 3; the description goes beyond it by stating the mutual exclusivity of insee/code_postal/slug (one identifier only), a constraint the schema itself does not express. It also frames school as a name filter matching on substring, consistent with 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 first sentence names a precise resource (school ↔ agricultural parcel proximity for a commune) and enumerates the returned measures: nearest-field distance, direction, crop, count of parcels within 500 m, area, organic RPG parcels, dominant crops. The resource is unmistakable, though the phrasing is nominal ('Détail de…') rather than an explicit verb, and no sibling is named to sharpen the boundary.

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

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

It gives a real operational rule: exactly one of insee, code_postal or slug must be supplied, and a shared postal code returns an 'options' field listing candidate communes — that is exactly the decision an agent needs before calling. The school filter is also flagged as optional narrowing. It stops short of stating when-not-to-use or pointing to an alternative tool (e.g. search_communes for resolving identifiers).

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false. The description adds useful behavioral context beyond that: absence of withdrawal does not mean approval, shared names return an options object, and SANTE records include all CAS entries after arbitration of shared CAS numbers.

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 main paragraph is front-loaded and informative, but the source/provenance paragraph includes unrelated platform datasets such as Parcelles RPG and SISE-Eaux tap water, which add clutter for a substance lookup. The tool-specific information is dense and useful, but the description could be trimmed.

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 does a good job listing the substantive fields and caveats an agent should expect. It does not specify what happens if neither cas nor name is supplied, and the exact return shape for normal versus shared-name cases is only partially described.

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 two parameters are already documented. The description still adds meaning by naming the accepted name sources (EFSA name, BNVD French label, water-control label, SANTE name) and by explaining the shared-name options behavior.

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 identifies a substance/metabolite lookup and enumerates the specific content returned: toxicity, endocrine-disruptor status, EU withdrawal/non-renewal, SANTE records, and parent molecules. This is far more specific than a restatement of the title and makes the resource distinguishable from the commune/water-focused siblings.

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

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

It gives concrete identifier guidance: CAS number is the safest identifier, with name as fallback, and it explains that shared names such as “cuivre” return an options field. It does not explicitly state when not to use the tool or name alternatives, but no sibling tool covers the same substance-lookup purpose.

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?

Annotations already declare readOnly, idempotent and closed-world, so the description is not carrying the safety burden. It still adds genuinely useful behaviour a schema cannot: the four possible "état global" values, the fact that a shared postal code returns an "options" field of candidate communes instead of data, and the post-treatment/not-individual-exposure caveat. It does not cover limits such as rate limits or empty-data handling, so it is not a 5.

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 first paragraph is well front-loaded: payload, then scope caveat, then identifier rule — exactly the order an agent needs. The trailing source block, however, mixes relevant freshness facts (SISE-Eaux 2025) with material about RPG parcels, BNVD purchases and the Rigal & Perrot index that has no bearing on tap-water pesticide results, padding the definition with noise.

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?

There is no output schema, so the description must carry the return shape, and it largely does: status enum, counter fields, networks, detected substances with annual peak against the quality limit, parent molecules, detail link, plus the "options" shape for ambiguous postal codes. What is unstated is behaviour on an unmatched commune or an entirely absent dataset beyond the "pas de données" status value.

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

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

Schema coverage is 100%, so formats are already documented and the baseline is 3. The description earns above that by imposing mutual exclusivity ("un seul parmi insee, code_postal ou slug") which the schema does not encode at all — all three properties are optional with no oneOf — plus the concrete consequence of an ambiguous code_postal. What remains unexplained is any precedence when several identifiers somehow arrive.

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?

States a specific verb and resource: sanitary control results (SISE-Eaux) for pesticides and metabolites in the tap water of a commune, followed by an enumeration of what the payload contains (global status, analysis counters, production networks, detected substances, parent molecules, link). The resource is unambiguous, but the description never names how it differs from close siblings such as get_commune_exposure or get_substance, leaving overlap to inference.

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?

"Eau du robinet après traitement : ce n'est pas une mesure de l'exposition individuelle" gives an explicit boundary that steers the agent away from exposure-oriented siblings. The identifier rule is also given (exactly one of insee, code_postal, slug) along with the fallback when a postal code is ambiguous. Missing is any positive statement of when to prefer this over get_commune_exposure for a given user question.

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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds the caveat that several communes from one department can appear in results, plus data provenance and vintage, but says nothing about ordering stability, empty-result behaviour, or how the 100-item cap works. With annotations present this 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.

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

The first paragraph front-loads the purpose, but then spends most of its length re-enumerating parameters already in the schema. The second paragraph is a long source/licence attribution listing four datasets and their vintages — legitimate for attribution, but heavy relative to the selection-relevant content.

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 an output schema present, the description needn't explain return values, and it does cover the parameters, defaults and the multi-result nuance. It leaves open what happens when `dept` is omitted (all departments?) and never mentions the limit ceiling, though the schema supplies that bound.

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 all five parameters are already documented, including defaults and enum values. The description restates the same parameter set and the sort/order interplay (asc + population = least populated) that the schema's own `order` description already contains, adding little beyond it.

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 states a specific verb and resource ('Classement paramétrique des communes par exposition') and lists the ranking criteria, so an agent knows it returns an ordered list rather than a single commune. It never names a sibling such as search_communes or compare_communes, so differentiation is implied by 'classement' rather than stated.

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 parameter walkthrough implicitly conveys usage ('taille du top', the sort/order pairing), and the note that several communes of the same department may be returned signals this is a multi-result ranking. But there is no explicit when-to-use / when-not statement and no pointer to search_communes or compare_communes for alternative needs.

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?

Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered. The description adds genuinely behavioral detail beyond that: prefix rather than substring matching, a hard result cap of 20 with a default of 5, and the fact that ambiguous names return multiple candidates. The licensing/dataset paragraph adds provenance but little invocation value.

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 first paragraph is well front-loaded and tight. The second paragraph is source/licensing boilerplate naming RPG 2025, BNVD 2024, SISE-Eaux and Rigal & Perrot — datasets this tool does not return — which dilutes the signal for an agent deciding whether to call it.

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 an output schema present, the description needn't explain return values, and it still summarizes them briefly. Annotations plus full schema coverage mean the agent has what it needs to call correctly; the only missing piece is a pointer to which sibling to use once a commune is identified.

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%, and the schema already states the default of 5, the maximum of 20, minLength 2 and prefix semantics. The description restates these rather than adding format examples (e.g. whether postal code '75' matches Paris) or edge-case behavior. 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 gives a specific verb and resource ('Recherche de communes françaises par nom ou code postal') plus the matching mode (préfixe, ≥2 caractères), which an agent can act on directly. It does not explicitly contrast itself with siblings like compare_communes or rank_communes, but those operate on already-identified communes, so the lookup role is still inferable.

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?

Usage is only implied: the reader must infer this is the discovery step that precedes department_profile, get_commune_exposure, etc. The ambiguity handling note ('un même nom existe souvent dans plusieurs départements') hints at the case where the caller should raise limit, but no explicit when-to-use or when-not-to-use statement is 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?

Goes well beyond the readOnly/idempotent annotations by disclosing dual response modes (native render in MCP Apps clients vs. data + map link elsewhere) and the edge case where an ambiguous postal code returns an 'options' field. Data provenance and vintage (RPG 2025, BNVD 2024, SISE-Eaux 2025) are also stated, which matters for trusting the result.

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?

Purpose is front-loaded, but the identifier paragraph partially restates the schema's own resolution rule and examples, and the source/licensing block is a long trailing list of dataset versions. Licensing attribution is defensible, yet roughly a third of the text is provenance rather than invocation guidance.

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 carries the return-value burden and does so: it says the response either renders a map or contains data plus a map link, and flags the 'options' field for ambiguous postal codes. What the returned data actually contains (parcel attributes, halo geometry) is left unspecified.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real value: it explains the resolution precedence for 5-digit codes with a concrete collision example (59175 = Templemars CP vs. Dimont INSEE) and the fallback 'options' payload for shared postal codes. This is meaningfully more than the schema's brief 'INSEE en priorité' note.

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?

States a specific verb and resource: an interactive map of agricultural parcels within a 1 km halo of a commune, including 'bio' parcels. It is unmistakably the visualization tool among siblings that return data (get_commune_exposure, rank_communes), though no sibling is named explicitly.

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?

Usage is implied (you want a visual map of parcels around one commune), and it explains rendering behavior across client types, but there is no explicit when-to-use/when-not guidance relative to search_communes or get_commune_exposure. The agent must infer that this is the 'render' tool rather than the 'query' tool.

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