Les missions de bénévolat ouvertes, relayées du réseau public API Engagement. Chaque mission porte l'URL de sa source : la candidature se fait chez l'organisateur, jamais ici.
| Name | Required | Description | Default |
|---|---|---|---|
| limite | No | ||
| commune | No | Code INSEE | |
| departement | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It usefully discloses that missions are relayed from an external public network and that applications happen at the organizer, not through this tool. Missing details include pagination behavior, response format, data freshness, and whether the listing is read-only in a technical sense.
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 compact and front-loaded: the first sentence states the resource and source, the second adds the critical behavioral note. It contains no filler. It could be improved by adding an explicit action verb, but it is appropriately sized.
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 tool with optional parameters and no output schema, the description is too thin. It explains where applications happen and that each mission has a source URL, but it does not clarify the three filter parameters, what the returned object looks like, or any limits on results. An agent would need to guess or inspect another source to use the tool reliably.
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 only 33% and the description adds no parameter meaning. 'limite' and 'departement' remain undocumented, and 'commune' only has a bare 'Code INSEE' hint in the schema. The description does not compensate for this gap at all, leaving an agent without enough information to correctly construct filter parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: open volunteering missions relayed from the public API Engagement, and notes that applications happen externally. It does not use an explicit verb like 'list' or 'search', but the meaning is unambiguous and the tool is distinguishable from siblings like associations or commune by its focus on missions.
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: consult these missions and do not submit applications here, because each mission carries the source URL. However, it does not state when to prefer this tool over alternatives such as 'chercher' or 'catalogue', nor does it mention any prerequisite or exclusion context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource or action: commune code lookup, search, category vocabulary, association registry, and volunteer missions. There is mild overlap between `chercher` and `associations` for finding associations, and between `associations` and `missions` in associative life, but the descriptions draw clear boundaries.
Names are short, lowercase, and readable, with most being French nouns (`associations`, `catalogue`, `commune`, `missions`). However, `chercher` is an infinitive verb, breaking the otherwise mostly nominal pattern; there is no consistent verb_noun or action_noun scheme.
Five tools is well-scoped for a read-only French local-life lookup server. Each tool earns its place: a code resolver, a general search, a category helper, an association registry query, and a volunteer-missions feed.
The set covers the main workflows implied by the server's purpose: `chercher` handles local searches, `commune` prepares INSEE codes, `catalogue` guides vocabulary, `associations` answers association questions, and `missions` covers volunteering. Minor gaps exist, such as no detailed view for a single result and no reverse postal-code lookup, but core use cases are supported.