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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuine value beyond that: it discloses scope limits ('ce qui n'est pas prévu'), that Flytel pricing is excluded ('sans ses prix'), and cites the authoritative source URL. It does not describe the shape of the returned answer, though the output schema exists.

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 resource and scope are front-loaded and every clause carries substantive content (scope, legal basis, eligibility, alternative brand). It is a single dense run-on sentence, though, which makes scanning harder than a short structured list would.

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 no-parameter, read-only knowledge lookup with an output schema, the description supplies everything needed: what the rule covers, who may subscribe, what falls outside, the legal basis, the source URL, and where to redirect users not served by this content.

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?

Zero parameters, and the description explicitly confirms 'Aucun paramètre', matching the empty schema – the baseline for a 0-param tool.

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 names a concrete resource – the published Comontel cross-border usage rule – and enumerates its exact content (daily usage on the other side of the border, day-counting logic, legal basis in Regulation 2016/2286 art. 4, observation period, exclusions, Swiss/Andorran contracts, eligibility). However, it never distinguishes itself from the knowledge-retrieval siblings (get_faq, get_guide, search_comontel_knowledge, get_border_zone), which an agent could plausibly choose instead.

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?

A concrete invocation trigger is supplied verbatim ('je travaille tous jours à Genève, ma ligne pro est-elle prévue pour cela ?'), plus a routing rule: salaried users wanting a personal line should go to Flytel. This gives real when-to-use context and one explicit alternative destination, but no exclusion against the other sibling lookup tools.

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