Flytel

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

Annotations already declare read-only, idempotent, non-destructive, non-open-world behavior. The description adds genuinely new behavioral context: figures are read directly from flytel.fr, and the result deliberately excludes estimation and proration of partial months. That 'no proration' clause is important for interpreting the returned amounts and is not expressed anywhere in the schema or annotations.

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 front-loaded sentence with the verb 'Calcule' first and the computed outputs as a parallel list; every clause carries information. It is dense but not padded, with only minor cost in readability from packing four items into one sentence.

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?

An output schema exists and annotations cover the safety profile, so the description need only ground the computation. It does that plus the no-estimation/no-proration disclaimer and lists the computed components, leaving only the source/pagination-style edge cases unaddressed.

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 description coverage is 100%, with defaults (esim, today's date), a plan_id pattern example, and enumerated allowance values documented inline. The description only restates these at a high level (eSIM ou carte SIM, date de souscription, recharges), adding no syntax or format detail beyond the schema, so the baseline 3 applies.

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 gives a specific verb (calcule) and resource (ce que coûte un forfait Flytel) and enumerates the four outputs computed: order-time cost, monthly TTC price by subscription date, billing start, and a month with top-ups. This is far more specific than a sibling like get_plan, but it never names an alternative tool, so it stops short of full sibling differentiation.

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?

Usage is implied by the enumeration of computed outputs and by the closing constraint 'sans estimation ni prorata', which hints that estimation-style tools exist elsewhere. However, there is no explicit statement of when to call this versus compare_plans, flytel_estimer_donnees, or flytel_tarifs_pays.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond them: the from-CH / to-CH / roaming distinction and the fact that the answer depends on where the phone physically is versus the destination number. It does not describe pagination or edge cases (e.g. no coverage), but the output schema carries the return shape.

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 the from/to/roaming framing are front-loaded, and the routing sentence to flytel_tarifs_pays closes it cleanly. It is slightly long and partially repeats the usage_type enum from the schema, which is wasted text.

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?

An output schema exists, so return values need no explanation, and all three required parameters plus the conditional destination_country are covered. For a filtered-lookup tool this is close to complete; only edge behavior (unsupported combinations) is left implicit.

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 75%, and the description meaningfully disambiguates the two country parameters — country_of_use is where the phone is, destination_country is the called party — a distinction the schema describes but the roaming framing sharpens. It also repeats the usage_type enum already in the schema, which adds nothing.

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: tells whether a given usage_type is included in a Flytel plan, scoped by country_of_use and destination_country. It explicitly distinguishes the three relevant cases (« depuis la Suisse », « vers la Suisse », itinérance), which an agent cannot infer from the name alone.

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 routing rule — use it for any « est-ce compris ? » question about calls, SMS or data — and names the sibling to use instead when the question is about out-of-plan pricing (flytel_tarifs_pays). When-to-use and the alternative are both stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the result character (a field-by-field diff with per-plan values plus identical fields), but since an output schema exists this is largely redundant, and it says nothing about behavior with unknown or duplicate IDs.

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 front-loaded sentence that states the action, the cardinality constraint and the return structure with zero filler. Nothing could be removed without losing information.

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 one-parameter, read-only comparison tool with rich annotations and an output schema, the description is nearly sufficient: it conveys scope and result shape. It stops short of explaining error behavior or the relationship to the other plan-oriented siblings, which is the only real gap.

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 description's 'deux à cinq' mirrors the schema's minItems=2/maxItems=5, reinforcing the cardinality rule. The schema itself already documents plan_ids with an example and a pointer to list_plans, so the description adds little semantic detail beyond the count constraint; a baseline 3 is appropriate.

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 (compare) and resource (forfaits Flytel) plus the scope (two to five) and the shape of the result (what differs, value per plan, what is identical). It is clear and unambiguous, but it never names or contrasts with the closest siblings (get_plan, list_plans, find_best_plan), so the differentiation is left to inference.

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 'deux à cinq forfaits' boundary implies the usage context and rules out one- or many-plan cases, which is useful. However, there is no statement of when to choose this over find_best_plan or check_usage_compatibility, and no prerequisites (e.g. that valid IDs come from list_plans).

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

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

Annotations already declare the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds useful behavioral context beyond that: it returns the full document text (not a snippet) and includes the address to cite, which is a real output-side trait.

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?

One taut sentence, front-loaded with the action and resource, with the citation detail attached. No padding or boilerplate; only minor overlap with the title.

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 single-parameter read tool, an output schema is present (so return values needn't be explained) and annotations carry the safety profile. The description supplies the missing context — the link to `search` and the nature of the returned content — leaving only explicit usage sequencing unstated.

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 description coverage is 100%, so the sole `id` parameter is fully documented in the schema, including the 'forfait:confort' example format. The description adds nothing about the parameter beyond what the schema already provides, which is the expected baseline when the schema does the heavy lifting.

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 (rend / returns) and resource (full text of a flytel.fr document), enumerating the document types (forfait, guide, question fréquente) and noting it also returns the address to cite. It ties itself to the sibling `search` as the source of the id, which differentiates it cleanly even though the bare name 'fetch' is generic.

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?

Usage is implied rather than stated: the description makes clear this reads a document previously found by `search`, so an agent can infer it must call search first. There is no explicit when-not or exclusion guidance, leaving the sequencing to inference.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real behavioral content beyond them: the result is a compatibility list with no 'best' designation and includes non-matching plans with a stated reason, so the agent knows to expect two buckets in the response.

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?

Three compact sentences, front-loaded with the operation and its scope, then the domain rule, then the routing rule. Only mild redundancy from restating the Switzerland/Europe envelope rule already present in the schema.

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?

With an output schema present, return values need not be described, and annotations plus full schema coverage carry the structured burden. The description supplies the missing business logic (shared CH/EU allowance, no ranking, rejection reasons), leaving little an agent needs that isn't available somewhere.

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 description coverage is 100% and every one of the 7 parameters is documented in the schema, so the baseline is 3. The description's most valuable addition — that Switzerland and Europe share a single allowance distinct from France — is already asserted in the europe_data_gb schema description, so it largely restates rather than extends the schema.

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 (returns Flytel plans compatible with a stated need) and enumerates the dimensions considered: GB/month in France, Switzerland, Europe; calls to/from Switzerland; eSIM. It also explicitly marks the boundary of its own scope (it does not rank one plan as best), which separates it from a ranking-style tool like compare_plans.

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 routing rule: use this when the needs are quantified, otherwise use flytel_conseil_forfait. Naming a sibling and the condition that selects it is exactly the guidance an agent needs; it also effectively states when NOT to use it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered by structured data. The description adds one useful behavioral detail beyond that — that the tool also returns verification steps for the phone — but says nothing about lookup scope, fallback behavior for unknown models, or result format.

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?

One compact sentence with no filler, front-loading the core answer (compatibility) ahead of the secondary benefit (how to verify). Nothing wasted, though it is arguably too terse to carry usage context.

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 1-parameter, read-only lookup with no output schema, the description covers both what is returned (a compatibility verdict plus verification steps) and the input domain. It lacks only edge-case behavior for unsupported or unknown models, which is minor at this complexity.

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 description coverage is 100% and the single 'telephone' parameter is already documented with concrete examples ('iPhone 13', 'Galaxy S21'). The description adds no syntax, format, or normalization guidance beyond the schema, so the baseline of 3 applies.

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 gives a specific verb and resource: it says whether a phone model accepts Flytel's eSIM, plus that it explains how to verify it on the device. That is enough to distinguish it from plan/pricing siblings, but it does not explicitly separate itself from the similarly named 'check_usage_compatibility', which an agent could confuse with this tool.

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?

There is no statement of when to use this tool versus alternatives, no prerequisites (e.g. model must be known/supported), and no exclusions. The agent must infer all routing from the name and one-sentence purpose.

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

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

Annotations already declare the safe read-only, idempotent, closed-world profile, so the burden is low. The description goes beyond them by disclosing the deterministic decision rule ('la règle de la page « Quel forfait choisir »') and the tie-breaking default ('dans le doute, le Confort'), which is genuinely useful behavioral context an agent would otherwise have to guess.

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?

Dense but well front-loaded: purpose first, then the rule, then the routing conditions. The parenthetical default and the two sibling comparisons each carry weight, though the sentence is long and could be split for readability.

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?

With a single enum parameter, a 100%-covered schema, and no output schema, the description supplies everything needed: input meaning, the deterministic mapping rule, the fallback, and sibling routing. Only a brief note on what the recommendation returns would make it airtight.

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 sole enum parameter is fully documented in the schema, so the baseline would be 3. The description beats the baseline by explaining what the ambiguous enum value 'ne_sait_pas' resolves to in practice (the Confort plan), adding decision semantics not present in the schema.

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 (conseille) and resource (forfait Flytel) and immediately scopes the input to current monthly data usage with the three possible states. It is distinguishable from siblings because it names find_best_plan and flytel_estimer_donnees as the tools for other input shapes.

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?

Explicitly states when to use ('quand la personne ne connaît que sa consommation actuelle') and gives two named alternatives with the condition that selects each (besoins chiffrés → find_best_plan; usages comme visio/vidéo → flytel_estimer_donnees). No inference required.

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

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

Annotations already declare the safety profile (readOnlyHint, non-destructive, idempotent, closed-world), so the description is not burdened with that. It does add one useful behavioral note: the dates are relative to 'aujourd'hui', i.e., the result is dynamic and recomputed as of today. It says nothing about the response format or the number of dates returned.

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 with no padding, and the key outcome (first and last possible dates) is front-loaded. Efficient, though it could be marginally tighter given there is only one concern to express.

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?

With no output schema, the description carries the return-value burden and does so by naming what is returned (first and last possible dates). Annotations cover the safety profile. It stops short of describing the date format or optionality of the single parameter, but for a one-param, read-only lookup this is close to 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?

Schema description coverage is 100%, and the enum for 'carte' is fully documented in the schema, so the baseline is 3. The description's phrase 'selon la carte choisie' merely confirms the parameter drives the result without adding syntax, default, or format detail beyond the schema.

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 states a specific resource and result: the first and last possible dates for transferring a number to Flytel, conditioned on the chosen card. An agent can understand exactly what the tool produces. It does not, however, differentiate itself from siblings like flytel_souscrire or flytel_verifier_rio, which also touch the portability journey.

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?

There is no explicit when-to-use, no prerequisites, and no mention of alternatives. The caller must infer that this tool is for planning/reference before a transfer, but nothing in the text confirms that or excludes other tools. Comparable to the update_drive calibration, which earned a 2 for the same absence of guidance.

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

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

Annotations already declare this a safe, read-only, idempotent, non-open-world computation, so the safety profile is covered. The description usefully adds that the calculation matches flytel.fr and that a covering forfait is part of the result (valuable since there is no output schema), but it says nothing about the computation's assumptions elsewhere or precision/limits.

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 purpose is front-loaded in the opening clause and the routing condition closes the text; every sentence carries information. The first sentence is long and dense, stacking inputs and outputs together, which costs some readability but not correctness.

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?

With only two fully documented parameters, strong annotations and no output schema, the definition covers what an agent needs: what it computes, from which inputs, and that the answer includes a recommended Flytel forfait. Nothing material is missing for correct invocation.

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 description coverage is 100%, including the nested per-usage hour keys, so the baseline is 3. The description's mention of visioconférence, musique, vidéo and appels par application loosely maps to those keys but adds no syntax, units or defaults beyond what the schema already states.

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 specific verb and resource ("Estime la consommation de données mobiles en Suisse par mois") and enumerates the drivers of the estimate (usages, jours par semaine). It goes further by promising the Flytel forfait that covers the estimate. It never names a sibling (e.g. calculate_monthly_price or check_usage_compatibility) to differentiate itself, so it stops short of a 5.

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?

"À utiliser quand la personne décrit ses usages sans connaître sa consommation" is an explicit when-to-use condition tied to the user's state of knowledge. There is no when-not guidance and no named alternative for the case where the user already knows their consumption, so it is clear context without exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context: no subscription is executed through the tool and the transaction happens entirely on flytel.fr, which is the single most important thing an agent needs to know here.

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 short sentences with no filler; the restriction (order happens off-conversation) is stated plainly. It is efficiently sized for a one-parameter helper 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?

There is no output schema, so the description correctly carries the burden of describing what is returned (the order URL and prerequisites). It resolves the potential confusion between the mutating-sounding name 'souscrire' and the read-only behavior, leaving little an agent needs beyond it.

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 description coverage is 100% and the single 'forfait' parameter is documented in the schema with an example. The description's mention of the 'forfait présélectionné' corroborates but does not extend the schema, so the baseline of 3 is appropriate.

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 makes clear what the tool yields: the URL of the online order page with the plan preselected, plus a checklist of what to have on hand. This is a specific output, not a tautology, though it is phrased as a description of the content rather than a direct verb+object action, and it does not explicitly differentiate itself from siblings like get_plan or list_plans.

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 closing sentence 'La commande se fait sur le site, jamais dans la conversation' implies the intended use: retrieve the link so the user completes the order externally. However, it never states when to call this tool versus compare_plans or find_best_plan, nor any prerequisite (e.g. a plan must already be chosen). Usage is implied rather than spelled out.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so safety and idempotency are covered structurally. The description adds useful framing by enumerating what the answer contains (in-plan status plus call/SMS/MMS/data pricing), but says nothing about behavior for an unknown or misspelled country or any error/fallback handling. Adequate, not rich.

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, no filler, and the routing instruction comes last where it is most useful. The purpose is slightly buried inside a colon-list construction rather than front-loaded as a single verb, but overall it is efficient and readable.

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?

With no output schema, the description carries the burden of saying what comes back, and it does: in-plan status plus per-channel pricing and mobile-data treatment. Combined with a single well-documented parameter and full annotation coverage, this is nearly complete; only edge-case behavior for unknown countries is missing.

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?

There is one parameter with 100% schema description coverage, and that schema description already specifies accepted forms (French country name, e.g. « Maroc », or ISO alpha-2 code, e.g. « MA »). The description only says 'pour un pays donné' and adds no normalization or ambiguity guidance beyond the schema, so the baseline 3 applies.

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 resource and scope ('pour un pays donné : compris dans le forfait Flytel ... ou non, et sinon les prix des appels, SMS, MMS et ... données mobiles'), so an agent knows exactly what it returns. It also names the sibling it is not (check_usage_compatibility), making it unambiguous against the alternatives.

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?

Explicit when-to-use ('À utiliser pour les prix hors forfait d'un pays') paired with an explicit alternative and its selecting condition ('pour savoir si un appel précis est compris (depuis où, vers où), check_usage_compatibility'). Nothing is left to inference.

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

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

With readOnlyHint/idempotentHint/destructiveHint already covering the safety profile, the description adds real value beyond annotations: it clarifies that nothing is stored and the check runs in memory, and that the RIO check is a key/checksum validation. It does not describe the response shape, but the read-only nature is fully conveyed.

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 tight sentences, purpose front-loaded, with the non-persistence guarantee immediately following. No filler or redundancy.

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 read-only verification tool with rich annotations and a fully documented 2-param schema, the description covers intent and behavior sufficiently. The only gap is that it does not spell out the exact outcome returned (e.g. the possible verdicts), though with no output schema this is a minor omission.

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 description coverage is 100%, so the baseline is 3. The description echoes the RIO 'clé' concept already explained in the schema, and adds no format or parsing guidance for the optional 'rio' or the required 'numero' beyond what the schema states.

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+resource: it reports whether a mobile number can be ported to Flytel and whether the RIO code matches, plus mention of the checksum/key check. The purpose is unmistakable and no sibling tool performs RIO verification. It does not explicitly contrast itself with siblings, keeping it just short of a 5.

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?

Usage is implied by the purpose (a pre-portability verification step) but there is no explicit when-to-use, when-not, or pointer to alternatives such as flytel_souscrire or flytel_dates_transfert. An agent can infer the context but is given no routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint false, and destructiveHint false, covering the safety profile. The description enumerates the information returned, which adds some behavioral context, but since an output schema exists, this is largely redundant. No additional behavioral traits such as authentication needs, rate limits, or error handling are disclosed.

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, front-loaded sentence that lists the returned information. It is efficient and avoids unnecessary preamble, though the enumeration is lengthy and includes items like contractual links that may not aid tool selection.

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?

Given the presence of an output schema and comprehensive annotations, the description provides sufficient context about what information is returned. The missing element is usage guidance relative to sibling tools, but that is covered separately. For a simple read-only getter with full schema support, the description 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?

Schema description coverage is 100% for the single plan_id parameter, so the schema fully documents its format and examples. The description adds no parameter-specific information, which is the baseline case when schema coverage is high.

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 identifies the resource: all official information for a Flytel plan. It is specific about the type of data returned (price, fees, volumes, calls/SMS, eSIM, network, etc.), but it does not explicitly distinguish itself from siblings like list_plans or compare_plans. The purpose is clear from the tool name and description, though no verb like 'retrieve' is included.

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?

No guidance is provided on when to use this tool versus alternatives. It does not mention list_plans as the source for plan_id or suggest using compare_plans for comparisons. Usage is only implied by the nature of a get-detail tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds domain context about separate France and Switzerland/Europe data volumes, but does not add operational behavior such as auth, pagination, rate limits, or response ordering.

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 purpose is front-loaded, but the description is a single long sentence with nested parenthetical detail that duplicates much of what the output schema likely provides. It is information-dense but less structurally clean than an ideal description.

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?

With rich annotations, an output schema, and zero parameters, the description is largely complete for a read-only listing tool. It explains the plan data and the important France versus Switzerland volume distinction, though it could better address ordering or when to prefer get_plan.

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 takes zero input parameters, and the rubric sets a baseline of 4 for no-parameter tools. There are no parameter semantics to clarify, so the description neither helps nor harms this dimension.

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 gives a specific verb and resource: 'Liste les forfaits Flytel commercialisés.' It also enumerates the returned plan attributes, making the tool's scope clear. However, it does not distinguish this listing tool from siblings like get_plan or compare_plans, so it falls short of a 5.

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?

There is no guidance on when to use list_plans versus alternatives such as get_plan or compare_plans. The listing intent is implied, but no explicit when-to-use, when-not-to-use, or alternative routing is provided.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world. Beyond that, the description adds genuinely useful behavior: the search returns only document metadata (id, titre, adresse) rather than full content, so a follow-up fetch is required — a two-step workflow the annotations do not convey. It stops short of disclosing result counts or ranking/fuzzy-match behavior.

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, no filler: scope and return shape come first, then the routing/next-step guidance. Every clause carries actionable information for an agent.

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 single-parameter search with a full output schema, the description covers the domain it searches, the shape of what is returned, and the follow-up step. Nothing needed to invoke it correctly is missing.

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 description coverage is 100% and the schema already specifies the query format, length bounds and the French-language preference with an example. The description adds nothing about the single parameter beyond that, so the baseline 3 applies.

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 ("cherche") and resource ("le contenu officiel de flytel.fr") and scopes the resource with concrete content types (forfaits, guides, FAQ). It also names what is returned (id, titre, adresse), which lets an agent distinguish it from fetch and the pricing siblings without opening a schema.

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?

Explicitly routes the agent: use fetch to read a document, and prefer get_plan / calculate_monthly_price / check_usage_compatibility when a precise price or inclusion is needed. That is real alternative-naming, but it doesn't cover the remaining siblings (compare_plans, find_best_plan, list_plans, flytel_tarifs_pays) nor state an explicit when-not-to-use condition.

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