ScoreConso — service documentaire

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: 'Ne transmet rien et n'envoie aucun courrier' (transmits nothing and sends no mail), which clarifies side-effect-free behavior beyond the annotations. This is a meaningful addition.

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, front-loaded with the main action and immediately clarifying the non-transmission behavior. Every word earns its place; no fluff.

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 tool has an output schema, so return values are documented elsewhere. The description covers the core behavior and side-effect-free guarantee. It doesn't explain what the action plan contains or how it relates to sibling tools like scoreconso_route_case, but for a read-only, idempotent builder with an output schema, this is largely 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 0%, so the description carries the burden for parameter semantics. The description mentions 'faits confirmés' which maps to the 'facts' parameter, but it doesn't explain the 'as_of' parameter or the structure of DeliveryFacts. With 0% coverage, the description should compensate more, but the 'facts' parameter is at least referenced. Baseline 3 is appropriate given the schema is self-explanatory for the main parameter.

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 verb ('Construit') and resource ('l'ordre des démarches documentaires') and clarifies it is based on confirmed facts. It distinguishes itself from sibling tools by focusing on building an action plan rather than routing, scoring, or checking deadlines. However, it doesn't explicitly name a sibling alternative, so it's clear but not fully differentiated.

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: use this tool when you have confirmed facts and need to build the order of documentary steps. It doesn't explicitly state when not to use it or name alternatives like scoreconso_route_case or scoreconso_score_dossier. The context is clear enough for an agent to infer, but explicit exclusions are missing.

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, and destructiveHint. The description adds meaningful behavioral context beyond that: the tool deliberately refuses to fabricate a deadline and requires both a valid starting point and an applicable RulePack. No contradiction with 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?

Two dense sentences, no filler. The main behavior and constraint are front-loaded, and every clause adds signal.

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?

Despite strong annotations and an output schema, the tool accepts a large DeliveryFacts object with 24 undocumented properties. The description explains the core legal gate but does not guide the agent on which facts are relevant, how 'RulePack' is determined, or what constitutes a valid starting point. This is thin for the complexity involved.

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 0%, and the description does not mention 'facts', 'as_of', or any individual schema field. It provides domain-level concepts that map conceptually to fields like contract_resolved_under_l216_6 and contract_date, but it does not help the agent know which parameters to populate or how.

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 ('Calcule'), a precise resource ('le repère de quatorze jours'), and a narrow condition ('résolution explicitement confirmée au titre de l'article L216-6'). This clearly differentiates it from broader sibling tools like score_dossier or route_case.

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 gives explicit when-to-use context: only for the fourteen-day benchmark after an explicit L216-6 resolution. It also states the negative condition ('Sans point de départ valide ou RulePack applicable... aucun délai n'est inventé'), though it does not name alternative sibling tools.

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 tool as read-only, idempotent, and non-destructive, covering the safety profile. The description adds useful context about the content of the result (declared evidence present/missing, discriminating facts), but does not disclose additional behavioral traits such as filtering logic or assumptions about the 'first path'.

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, concise sentence that front-loads the main action and key outcomes. It is efficient, though the term 'premier parcours' is ambiguous without domain context, slightly reducing clarity.

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 complex nested input schema and many sibling tools, the description is under-specified. It neither explains the meaning of 'premier parcours' nor how the evidence checklist relates to other workflow steps. Since an output schema exists, return-value details are not required, but input requirements and usage context are 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 0%, and the description says nothing about the two parameters ('as_of' and 'facts') or how to construct the complex DeliveryFacts object. The description's mention of 'preuves déclarées' is not enough to guide the agent in populating input values.

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 clear verb ('Retourne') and resource (evidence checklist for the first path), and mentions both present and missing evidence plus remaining discriminating facts. While it does not explicitly name a sibling tool, the function is distinct enough from tools like score_dossier or get_rule to avoid confusion.

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. The description does not mention conditions, prerequisites, or contrast with sibling tools such as 'get_rule' or 'build_action_plan', leaving the agent to infer usage.

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, and the description is consistent with them — no contradiction. The description adds value beyond annotations by disclosing that the output is a 'canonical' normalized rule carrying editorial status and official sources, which is useful behavioral context an agent could not infer from the schema alone.

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, both earning their place: the first front-loads the core purpose and return contents, the second clarifies the most domain-specific parameter. There is no filler and no repetition of what the annotations or schema already provide.

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 not be described, and annotations cover the safety profile — allowing the description to focus on purpose and parameters. The only meaningful gaps are the undocumented as_of parameter and the absence of tool-selection guidance, but for a read-only 3-parameter tool with one required parameter this is otherwise adequate.

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?

With 0% schema description coverage, the description carries the burden and notably clarifies applicable_on as 'la date du contrat ou des faits à examiner,' adding domain meaning that the bare parameter name would not convey. However, as_of is left entirely unexplained despite its temporal significance in a 'versioned rule' tool, and rule_id is only self-evident by name — so compensation is partial.

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 uses a specific verb ('Retourne') tied to a specific resource ('une règle canonique') and enumerates exactly what is returned: application period, editorial status, and official sources. This is a clear statement of purpose, though it does not explicitly distinguish itself from siblings such as scoreconso_get_template or scoreconso_get_evidence_checklist; differentiation relies on the title and the domain-specific return contents.

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 use case is implied rather than stated: the description never tells an agent when to choose get_rule over a sibling, nor does it name any alternative. The only guidance, 'applicable_on désigne la date du contrat ou des faits à examiner,' is a parameter clarification that hints at the intended scenario but offers no explicit when/when-not rules.

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. The description adds meaningful context beyond that: 'La trame reste générique et aucune expédition n'est possible,' confirming the tool produces no real-world side effects and stays in template space. No contradiction with 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?

Two compact sentences with the purpose front-loaded and zero filler. Every clause earns its place, though the second sentence could have been used to clarify parameters instead of restating genericness.

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 to cover return values, and annotations carry the safety profile. But with 0% parameter coverage in both schema and description, the tool is incomplete for correct invocation — as_of and template_id semantics are entirely undefined.

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 0%, so the description must compensate for the undocumented parameters, but it never explains as_of or template_id — despite template_id having an informative default ('delivery_execution_then_resolution'). An agent can't infer parameter semantics or formats from either source.

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: 'Retourne les conditions, avertissements et sources d'une trame ScoreConso.' The note that the template 'reste générique' and that 'aucune expédition n'est possible' helps distinguish it from the many route_*/score_* sibling tools, though it never names a specific alternative.

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 on when to use this tool versus the routing, scoring, or lookup siblings. It doesn't state prerequisites, conditions for selection, or exclusions — an agent must infer its role from the name and title alone.

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, openWorld, idempotent, non-destructive), so the description doesn't need to repeat that. It adds useful behavioral context beyond annotations: the search is exact, only the number is transmitted to the official API, and the result confirms a published identity rather than financial or website-ownership facts.

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 short sentences communicate the operation, the transmission boundary, and the output's limits without filler. The core action is front-loaded, and each sentence earns its place by adding a distinct fact an agent needs.

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 simple two-parameter read-only lookup with an output schema and strong annotations, the description is nearly complete: it specifies input format, exact-match behavior, official source, and what the result does not certify. The only notable gap is the undocumented role of as_of, which is minor given the schema title and the tool's scope.

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 0%, so the description must compensate. It meaningfully clarifies the identifier parameter by specifying SIREN or SIRET and exact matching. However, the optional as_of parameter is never mentioned, leaving its historical-reference semantics to be inferred solely from the schema title and type.

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 opens with 'Recherche exacte d'un SIREN ou SIRET dans l'API Recherche d'entreprises', naming a specific verb, resource, and input type. It clearly distinguishes this identity-verification lookup from the sibling routing, scoring, and lookup tools by scoping it to exact matches against an official administrative registry.

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 use when an agent needs to verify a published administrative identity via exact SIREN/SIRET lookup. It also gives explicit exclusions: the result never establishes reliability, solvency, or website ownership, which prevents the agent from misusing the tool for those judgments. It does not name sibling alternatives, but the boundary it draws is enough to guide selection.

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 mark the tool read-only, idempotent, and non-destructive. The description goes beyond them by explaining that the search runs against a dated local snapshot and by warning that sectoral exploration is never proof of mediator designation or membership – an important non-obvious limitation for an agent relying on the result. No contradiction with 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?

Three short sentences, each carrying information: the search scope, an epistemic caveat, and the selector constraint. The most action-relevant content is front-loaded.

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 five optional parameters, no required fields, and an output schema, the description is serviceable but not complete: it lacks a tie to the sibling lookups and does not explain how a 'référence de médiateur' is actually checked or matched. The output schema covers the return structure, but the decision of when to use this tool versus match_enterprise_mediator_evidence remains 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 0% and five parameters exist, so the description has to compensate. It does identify the meaningful selectors ('nom, site, code secteur, catégorie') and states the exclusivity rule, which the schema does not enforce. Yet it leaves 'as_of' and 'limit' unexplained and does not map 'query' precisely to name/site.

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 action ('Recherche localement'), a precise resource ('snapshot daté de l'annuaire CECMC'), and the fields it can search ('un nom, un site, un code secteur ou une catégorie'). It is clear enough to distinguish the tool from lookup_enterprise_identity or product recall, though it does not explicitly contrast itself with a sibling 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?

The text gives two operationally useful constraints: only one selector is allowed, and a sectoral hit does not prove the professional designated or joined a mediator. However, it never says when to prefer this tool over an alternative or what the other scoreconso_* tools are for.

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, and destructiveHint=false, but the description adds substantially: no external service is called, the code is not retained, the snapshot fingerprint is returned, and no-result does not prove safety. These disclosures go well beyond what structured annotations convey.

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 compact and front-loaded: the core lookup purpose comes first, followed by behavioral caveats. Each of the three sentences contributes distinct information with no filler or repetition.

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 rich output schema and strong annotations, the description is mostly complete: it covers exactness, snapshot dating, privacy, no-result semantics, and the GTIN-exclusion rule. The only notable gap is the lack of explicit guidance on the as_of parameter and on choosing this tool among sibling lookups.

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 0%, so the description must carry parameter meaning. It clarifies that the gtin parameter is matched exactly and that recalls without GTIN are excluded from the game. However, it does not explain the optional as_of parameter or specify the expected GTIN format, leaving a real gap for one of the two parameters.

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 verb and resource: 'Recherche exacte d'un GTIN dans le snapshot officiel daté de RappelConso V2'. It clearly identifies a product-recall lookup operation and distinguishes it from sibling tools such as lookup_enterprise_identity by focusing on GTIN/RappelConso. The exact-match qualifier adds useful precision.

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 when the tool is appropriate: verifying whether a GTIN appears in the RappelConso snapshot. It also adds a meaningful caveat that absence of a result never proves product safety. However, it does not explicitly name alternatives or state when not to use this tool versus the sibling lookup tools.

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 readOnly, idempotent, and openWorld annotations already covering safety, the description adds valuable behavioral detail: it verifies exact company identity first, compares only the mediator name or URL, and forbids inference from APE code or sector. This goes beyond the annotations and helps prevent misuse.

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 focused sentences carry the main flow first and the critical negative constraint second, with no filler or repetition of schema fields. Every clause earns its place.

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 readOnly/idempotent annotations and the presence of an output schema, the description covers the core decision logic and the real-world evidence sources needed for correct invocation. The main gap is parameter-level detail for required fields like evidence_reference, which the schema names but the description does not clarify.

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 adds meaning by mapping evidence_type values to concrete document types ('contrat, CGV, bon de commande, page de médiation') and clarifying mediator_name/mediator_url semantics ('le nom ou le site du médiateur'). However, with 0% schema description coverage, it still leaves evidence_reference, evidence_observed_at, and as_of semantically unexplained, so compensation is only partial.

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 operation ('Vérifie l'identité administrative exacte d'une entreprise, puis compare...') and a specific resource ('snapshot CECMC'), while restricting matching to the observed mediator name or URL in listed evidence documents. The explicit 'N'infère jamais un médiateur depuis le code APE ou le secteur' also distinguishes it clearly from sibling lookup/route tools.

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 states the input context clearly: evidence of a mediator name or URL observed in a contract, CGV, order form, or mediation page. It also gives a hard negative rule ('N'infère jamais...'), though it does not explicitly name a sibling alternative such as scoreconso_lookup_mediator_reference.

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 mark the tool as read-only, idempotent, and non-destructive. The description adds valuable behavior beyond that: it states the result is passed 'sans le modifier' (without modification) and, without MCP Apps support, it returns the same structured result as text. This gives the agent knowledge of input-output symmetry and fallback behavior, which annotations do not cover.

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 compact: two sentences for the core action and workflow plus one for the fallback. Every sentence carries necessary information—what to pass, from which tools, how to pass it, and what happens without MCP Apps. No filler or redundancy is present.

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 tool has one complex parameter but a rich output schema, the description provides the essential workflow context, source tool list, and fallback behavior. The output schema exists, so the return format is already defined elsewhere. The description is complete enough for an agent to invoke the tool correctly without needing additional guidance.

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 has zero description coverage for the single parameter 'result', so the description must compensate fully. It does so by specifying that the parameter must be the structuredContent from one of the named routing tools and must be passed unmodified. This adds critical provenance and handling instructions beyond the raw schema definition.

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 that the tool renders a complete result produced by a specific list of routing tools into a cockpit, using the verb 'Rend' and naming the exact source tools. This distinguishes it from sibling tools like the routing tools themselves and other utility tools such as scoreconso_build_action_plan. The title reinforces this purpose, so an agent can understand it is a display/rendering 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?

The description explicitly tells the agent to first call the appropriate routing tool, then pass its structuredContent unmodified to this tool. It lists the six routing tools it depends on, making the when and how clear. It also covers a fallback behavior when MCP Apps is not supported, leaving no ambiguity about usage context.

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 read-only, idempotent, and non-destructive behavior. The description adds valuable context by specifying the checks performed (cancellation initiator, special orders, reciprocity, nonperformance) and explicitly stating what it will never automatically decide (abusive clause, certain refund, due balance, compensation). This goes beyond annotations without contradicting them.

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, zero filler. The main purpose is front-loaded, followed by the list of checks and the negative guarantee. Every clause earns its place, making it highly efficient.

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 tool has a complex input schema with many fields and an output schema, yet the description gives only a high-level overview. It does not mention the `as_of` parameter or explain how to structure the `facts` object, though the schema itself is self-documenting. The description covers core behavior but leaves operational details to the schema; a bit more guidance on essential facts would improve completeness.

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 0% – the description does not reference any parameter names or fields. It mentions checks on the cancellation initiator, special orders, reciprocity, and nonperformance, which map to schema fields, but it never explains how to populate the `facts` object or what `as_of` means. Given the large schema, the description fails to compensate for the lack of parameter documentation.

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 uses a specific verb ('route') and a precise resource ('annulation après versement d'arrhes, d'un acompte ou d'une somme non qualifiée'), clearly distinguishing it from sibling routing tools focused on guarantee, marketplace, payment fraud, or subscription cases. It also enumerates the exact checks performed (author, special orders, reciprocity, nonperformance), making the purpose unmistakable.

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 scope is clearly limited to cancellations after advance payment, which implicitly separates it from other routing tools. However, it never explicitly states 'use this when the case involves arrhes/acompte' or names alternatives, nor does it state exclusions or conditions. An agent can infer the appropriate usage, but explicit guidance is missing.

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 convey readOnly, idempotent, non-destructive behavior. The description adds a specific behavioral nuance: if facts.contract_date is provided, no current rule is applied retroactively when its historical version is missing. This goes beyond the structured annotations and gives the agent an important edge-case rule.

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 wasted words. The main purpose and output are front-loaded, and the conditional rule is given as a clear secondary point. Ideal length for a tool with an existing 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?

The description lists the key outputs (missing facts, rules, temporal check, uncertainties, next step, procedural timeline) which helps the agent understand what to expect. It also covers the notable contract_date exception. Given the output schema exists and the input is a well-defined facts object, this is fairly complete, though it could elaborate on the as_of parameter or required prerequisites.

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 0%, so the description must compensate. It only references one parameter field (facts.contract_date) and does not explain the purpose of 'as_of' or the broader 'facts' object beyond the implicit 'structured facts'. The many fields in the schema are self-titled but lack any semantic guidance from the description.

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 uses a specific verb ('Route') with a precise resource ('un cas de colis indiqué livré mais non reçu') and enumerates the output (missing facts, possible rules, temporal control, uncertainties, next step, procedural timeline). It clearly differentiates from sibling route_* tools which target other case types (e.g., guarantee, subscription).

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 clearly states the scenario (package marked delivered but not received) and that it works from structured facts, providing clear context for when to use it. However, it does not explicitly name alternatives or state when not to use it, so it stops short of full 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 indicate read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context by listing the internal checks and explicitly stating that the tool never automatically chooses a refund or resolution, which is beyond what the annotations convey.

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 concise sentences, front-loaded with the core purpose, followed by the key checks and a critical behavioral constraint. Every sentence earns its place with no 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 routing tool with rich annotations and an output schema, the description covers the essential context: when to use it, what it checks, and what it will not do. It is slightly incomplete in not addressing how it relates to the more general route_case sibling, but this is a minor 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?

Schema description coverage is 0%, so the description must compensate. It does provide domain-level meaning by referencing the seller, the two-year period, the 24/12-month presumption, the 30-day benchmark, and secondary remedies. However, it does not explain the structure of the facts object or the as_of parameter, leaving much of the parameter semantics to inference.

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 is specific: it routes a refusal of the legal guarantee of conformity or a referral to the manufacturer. It names the exact legal scenario and the checks performed, making it easy to distinguish from sibling routing tools like route_marketplace_case or route_subscription_case.

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 first sentence clearly states the triggering context: a refusal of a legal guarantee of conformity or a referral to the manufacturer. However, it does not explicitly state when not to use this tool or compare it with route_case, leaving some ambiguity about edge cases.

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, covering the safety profile. The description adds a valuable caution that it never concludes platform liability solely from the platform's title, which is a non-obvious limitation beyond the annotations. However, it does not elaborate on other behavioral aspects like return format or side effects.

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 concise sentences, front-loaded with the primary action and a clear caution. No wasted words; the description is appropriately sized for the tool's purpose.

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 complex routing tool with a rich facts schema and many siblings, the description is incomplete. It does not explain input expectations, when to invoke it, or how it differs from other route_* tools. Although an output schema exists, the lack of input guidance and usage context leaves the agent under-informed 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?

The schema has 0% description coverage, and the description does not explain any parameters. The `facts` object is complex with many enums, but the description provides no guidance on how to populate it. The schema itself is self-documenting, but the description should have at least summarized the required facts or the purpose of the `as_of` field.

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 the tool's function: distinguishing contractual seller, professional/private status, declared platform role, invoice issuer, and claim target. The marketplace-specific scope is evident from the name and title, though it does not explicitly contrast with sibling routing tools.

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 the many sibling routing tools (e.g., route_advance_payment_case, route_guarantee_case). It lacks any conditions, prerequisites, or mention of alternatives, leaving the agent to infer usage solely from the name.

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, destructiveHint=false, and idempotentHint=true. The description adds context beyond annotations: it only calculates a reference when territorial and temporal facts are sufficient, and it explicitly does not promise automatic reimbursement. These are meaningful behavioral constraints not present in the 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?

The description is exactly two sentences, front-loaded with the core purpose and followed by a conditional behavior. There is no filler, and every phrase contributes meaning. It is appropriately sized for the tool's complexity.

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 tool's complex schema (nested facts object with 18 fields) and the presence of an output schema, the description is far too thin. It does not explain what the computed repère is, what 'sufficient territorial and temporal facts' means, or how the output is structured. The optional as_of parameter is unaddressed, leaving significant gaps for an agent to call this correctly.

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 0%, and the description mentions none of the parameters. The required 'facts' object contains 18 fields with no explanatory text, and the optional 'as_of' parameter is ignored. With no compensation from the description, the agent must rely solely on property names, which are insufficient for correct invocation.

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: structuring a contested payment by distinguishing unauthorized operation from payment under deception. It also mentions calculating a reference only under sufficient facts, which is a precise behavior. This distinguishes it from other routing tools by specifying the payment-fraud domain, making its purpose unambiguous.

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 it is for payment fraud cases but does not explicitly state when to use it over alternatives like route_guarantee_case or route_subscription_case. There are no exclusions or references to other tools, leaving the selection logic to the agent's inference from the tool name and title.

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 establish read-only, idempotent, and non-destructive behavior. The description adds a valuable domain invariant beyond those annotations: online termination never automatically removes notice periods, commitments, fees, or supporting documents. It also communicates the analysis dimensions the tool applies, which helps the agent predict how the tool will treat the case.

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 two sentences with no filler: the first sentence scopes the analytical dimensions, the second adds a key behavioral rule. It is front-loaded and every clause earns its place.

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 tool taking a very rich 25-field facts object, the description provides the analytic axes but not enough operational guidance about how to populate the facts or what routing outcome to expect. The existence of an output schema covers return values, but the overall definition remains minimal given the complexity of the input.

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 0% and the description gives no direct guidance on the 'facts' object or the 'as_of' parameter. The listed legal dimensions only loosely map to the schema fields, which does not compensate for the complete absence of parameter documentation. An agent must rely solely on mostly self-explanatory property names and enums.

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 uses a specific verb ('Distingue') and lists the subscription-related aspects it separates: electronic termination, contract conditions, tacit renewal, notification proof, and conditional refund. The title reinforces the resource ('abonnement impossible à résilier'). It does not explicitly name a sibling for differentiation, but the tool name and title make the subscription scope clear.

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 for subscription cases is implied by the tool name, title, and the listed legal dimensions, but the description never states 'use this when...' and does not contrast it with sibling routing tools like route_guarantee_case or route_marketplace_case. No exclusions or prerequisites are 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 readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds genuine behavioral context beyond annotations: the score represents material preparation out of 100, is distinct from the coverage rate, and explicitly excludes legal/compensation measures. This meaningfully clarifies what the returned number signifies.

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 with the core concept front-loaded. The key information (measures material preparation out of 100, separates from coverage rate) comes first, and the exclusions are packed efficiently into a single sentence with zero wasted words.

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 safety, so return format and side-effect profile are handled. The description explains the score's conceptual meaning well, but the parameter semantics are not explained - especially the 'responses' nested object. For a tool with a nested object and an enum, the conceptual clarity doesn't fully compensate for the lack of parameter documentation.

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 0%, so the description must compensate for the schema's silence, but it doesn't mention any of the three parameters (topic_id, responses, as_of). Parameter names and the enum are mildly self-explanatory, but the 'responses' object structure (yes/no/unknown values) is left entirely undocumented in both schema and description, a real gap for an agent constructing the call.

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 verb (mesure), resource (dossier), and scale (sur 100), and explicitly separates the score from the coverage rate. It also lists what it does NOT measure (responsabilité, indemnisation, chance de gagner), which sharpens the purpose. However, it doesn't differentiate itself from the sibling scoreconso_score_offer_transparency, leaving ambiguity among the two scoring tools.

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 negative exclusions (what the score doesn't measure), which helps prevent misuse for responsibility/compensation decisions. But it gives no positive guidance on when to call this tool versus scoreconso_score_offer_transparency, and doesn't state prerequisites or context for invocation.

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?

Even though annotations already signal read-only and idempotent behavior, the description adds substantial non-obvious traits: it downloads no pages, retains no content, separates score from coverage, produces a private dated result, and explicitly excludes judging seller reputation or quality. This goes well beyond the structured 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?

Three tight sentences deliver the method, input, behavioral constraints, and scope exclusions without repetition or filler. Every sentence adds distinct value, and the most important usage constraint is front-loaded.

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 rich input schema and output schema, the description covers the essential context: what input to provide, privacy and retention behavior, and what the score does not represent. It is slightly incomplete in not situating the tool relative to similar scoring/route siblings, but it is sufficient for safe 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 0%, so the description carries the burden of explaining parameters. It maps generally to 'observation' via 'constats structurés déjà relevés par le client,' but it never names or explains 'as_of' or the nested assessment structure. The description does not compensate enough for the missing schema descriptions.

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 the tool's purpose: applying the ScoreConso Lens method to structured observations to measure visible offer transparency. It is specific about the resource (offer transparency) and the input (client-collected observations), but it does not explicitly name a sibling tool for differentiation, relying instead on scope boundaries like 'never rates the seller.'

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 phrase 'constats structurés déjà relevés par le client' implies the tool is for use after factual observations have been gathered, and 'ne télécharge aucune page' implies it is not a page-fetching tool. However, no explicit when-to-use or when-not-to-use guidance is given, and no sibling alternatives are named.

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