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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by bounding the data scope ('Ne réserve ni ne vend rien, ne renvoie aucun contenu de séance ni de conversation'), which tells the agent what this tool will never surface. It does not discuss failure modes for unknown identifiers, but the enum makes that largely moot.

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 identifier source are front-loaded, then return contents, then usage conditions and exclusions – a sensible ordering. It is dense but not padded, though the exact per-service language counts (4 langues / 18 langues) are detail an agent rarely needs to choose or call the tool.

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?

One enum parameter, no output schema, and full annotation coverage: the description compensates for the missing output schema by describing the shape of the response (summary, addresses with provenance tracking, pricing, payment mode). Nothing needed to select or correctly invoke the tool is absent.

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 enum already constrains the single parameter, so the baseline would be 3. The description goes further by attaching meaning to specific enum values – sml as 'analyse d'une conversation de couple, tableau de bord gratuit puis rapport payant' and rendez_vous_visio as reserved for French-speaking users – which the schema itself does not convey.

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 ('Décrit un service en détail à partir de son identifiant') and enumerates the returned content: résumé, adresses avec suivi de provenance, adresses par langue, tarifs en euros, zone francophone et mode de paiement. It also anchors the identifier to its source ('valeur renvoyée par list_services'), which cleanly separates it from list_services and from the content-oriented siblings like get_test or get_article.

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?

Gives an explicit conditional trigger ('À appeler avant de recommander ScanMyLove ... ou le rendez-vous en visioconférence') plus a negative guardrail ('Ne pas orienter vers un service payant une personne en détresse ou en crise'). What it lacks is routing guidance for the other siblings (get_test, get_article, get_book), so the agent must infer when describe_service is preferred over those.

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