Liste les 8 comparatifs structurés disponibles avec, pour chacun, le slug, le titre éditorial, l'URL et la liste des slugs produits inclus dans le classement (ordre = ranking éditorial).
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It fully discloses the output: exactly 8 items, their fields, and the editorial ordering. The read-only nature is implied by 'Liste' but not explicitly stated, so it misses a little effectiveness despite strong return-value 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?
A single sentence front-loads the verb 'Liste' and packs all essential information (count, fields, ordering) into about 25 words with no filler.
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 parameterless, read-only listing tool with no output schema, the description is complete: it specifies count, exact fields returned, and ordering. No additional context is necessary.
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. There are no parameter details needed or provided, and nothing more is required.
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 a specific action ('Liste les 8 comparatifs structurés disponibles') and enumerates the exact returned fields (slug, titre éditorial, URL, slugs produits). This distinguishes it from siblings get_product and search_products by targeting comparatifs specifically.
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 no guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. It only states what the tool does, leaving the agent to infer appropriate contexts.
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 has a distinct purpose: retrieving a single product by slug, listing comparative articles, and searching products with filters. No overlap or ambiguity.
All tool names follow the same verb_noun pattern with lowercase underscore: get_product, list_comparatifs, search_products. Consistent and clear.
Three tools is minimal but appropriate for a read-only catalogue server, covering the core needs of fetching, listing, and searching. Could be slightly more extensive but not inadequate.
The server provides essential read operations: get by slug, list comparatifs, and search. Missing a generic list all products or an update/create endpoint, but for a catalogue and comparison resource it is largely complete.