list_itinerairesDes parcours dont l'ordre des étapes est calculé de proche en proche et les distances mesurées, pas estimées. Utile pour répondre à « que voir en trois jours dans la Loire ».
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No |
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 disclose a meaningful behavioral trait: routes are ordered locally and distances are measured rather than estimated. However, it does not mention language behavior, response format, source of data, or limitations, leaving some behavioral transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence defines the resource and its key behavior; the second provides a concrete usage example. Every sentence earns its place and the main point is 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 is simple with only one optional parameter, so a short description is reasonable, and the core purpose and usage context are present. Yet there is no output schema and no annotations, and the description does not indicate what the returned data looks like or how the language parameter affects results. These omissions are not fatal for a simple list tool but leave moderate gaps.
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 contains a single optional 'lang' parameter with an enum of 'fr', 'en', 'de', which conveys possible values. However, schema description coverage is 0% and the description does not mention 'lang' at all, nor does it clarify default language behavior or how the parameter affects results. With low schema coverage, the description needed to compensate and did not.
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 identifies the resource as multi-day itineraries ('deux ou trois jours') and adds a defining characteristic: the order of stops is computed stepwise and distances are measured, not estimated. It is distinguishable from sibling tools such as get_chateau, list_evenements, and search_chateaux, although it does not use an explicit imperative verb like 'list'.
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 clear use case: answering queries like 'que voir en trois jours dans la Loire'. This signals when to call the tool. It does not explicitly state exclusions or compare alternatives, but the context is strong enough for an agent to select it over the sibling tools.
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 different resource: one château detail, one château search, one event list, one itinerary list. The 'list_evenements' vs 'list_itineraires' pair could seem similar at first, but the descriptions clearly separate time-bound events from computed routes.
All tools use a consistent snake_case verb_noun pattern: get_chateau, list_evenements, list_itineraires, search_chateaux. Mixed singular/plural in French nouns is natural and does not affect consistency.
Four tools is a focused, intentional set for a read-only encyclopedia server. It falls comfortably within the 3–15 tool range and each tool provides a unique capability without redundancy.
The domain of château information is covered by search + detail retrieval, with events and itineraries extending the surface nicely. There is no way to fetch a single event or itinerary by ID or filter events by château, but these are minor workarounds for agents.