Récupère la fiche complète d'un produit par son slug. Inclut : nom, marque, catégorie, description, verdict éditorial, prix, note rédaction, note Amazon, ASIN, URL produit gluten-free.fr et URL achat Amazon affiliée.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Slug produit (ex 'rummo-spaghetti-sans-gluten'). Liste complète disponible via search_products. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description explicitly states a read-only retrieval action ('Récupère') and enumerates the data returned. It does not mention permissions or error scenarios, which are less likely for a simple get; the behavior is transparent for its scope.
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, efficient sentence that lists the included fields without superfluous words. It is well-structured and 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?
The description tells the user exactly what data is included, which is sufficient for understanding the tool's output. It does not specify output format or potential limitations, but given the simple nature of the operation and lack of an output schema, it is adequately complete.
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 'slug' parameter with an example and a reference to search_products. The description adds no additional semantic detail beyond that, matching the baseline for 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 it retrieves a complete product sheet by slug and lists the specific fields included. It distinguishes itself from siblings like search_products (which searches) and list_comparatifs (which lists comparisons).
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 when a slug is available and full product details are needed. It does not explicitly contrast with sibling tools, but the slug-based lookup is clear. A minor addition about when to prefer this over search_products would have earned a 5.
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.