Capucine

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

The description candidly discloses the important behavior — content is erased, not just the request marked cancelled — and scopes it to unconfirmed requests. But this directly conflicts with the annotation destructiveHint=false, which tells the agent the tool performs only additive updates; a permanent erasure is the opposite, and idempotentHint=false / openWorldHint=true add little clarity in the description.

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 sentence, front-loaded with the verb and resource, then the precondition, then the effect. No filler.

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 an irreversible cancel-and-erase operation, the description omits whether the action_id becomes unusable afterward, what happens if the request was already confirmed, and whether failures are reported. Annotations partially cover safety, but their destructiveHint conflicts with the stated erasure, so the description does not fully close the 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?

There is a single required parameter with 100% schema description coverage, including its origin ('Identifiant secret renvoyé par proposer_demande_rappel'). The description adds nothing about the parameter (e.g., whether the id is consumed/invalidated after cancellation), 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 (annule) and resource (une demande préparée non confirmée), plus the side effect (efface son contenu). It is clearly distinguishable from confirmer_action and proposer_demande_rappel, though those siblings are not named in the description itself (only the schema mentions proposer_demande_rappel).

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 qualifier 'non confirmée' implicitly defines the only valid case (an unconfirmed draft), which is useful context. However, there is no explicit guidance about what to do when the request is already confirmed, nor a named alternative such as confirmer_action or statut_actions, leaving the agent to infer the boundary.

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, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real context beyond that: personal details are withheld server-side behind an opaque token, which is a meaningful privacy disclosure for an advice tool. It stops short of describing latency, freshness, or how 'à surveiller' is determined.

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, front-loaded with the verb and the shape of the answer, with the privacy guarantee placed last where it reads as a reassurance. The parenthetical item list is a bit terse and slightly cryptic, but nothing is truly redundant.

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 full input schema, an output schema, and complete annotations, the description only needs to add orientation and any non-structural caveats — which it does via the opaque-token privacy note. A brief note on how it differs from recommend_look would close the remaining 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 100% and every parameter (question, limit, detail_level, include_products, include_conversion) is documented in the schema itself. The description only faintly echoes behavior via the mention of 'sources', which maps loosely to detail_level=full, but adds no syntax, defaults, or constraints of its own — baseline 3.

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?

Names a specific action ('je diagnostique une question de style') and enumerates what the response covers (look nommé, capsule, à surveiller, sources), so the agent knows this is an open style-advice query tool. It does not, however, distinguish itself from siblings like recommend_look or recommend_weather_look that plausibly compete for the same style questions.

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 only implied through the phrasing of a natural-language style question and the capsule vocabulary (pièce, ancre, chaussures, sac, bijou). There is no explicit when-to-use, when-not, or pointer to recommend_look / shop_the_look as alternatives, which matters given several overlapping style siblings.

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, so the safety profile needs no restating. The description adds a genuine behavioral detail — the editorial rule for which URLs get cited — but says nothing about whether citations are persisted, how the limit interacts with ranking, or what the returned payload looks like.

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?

It is short — two sentences — and the purpose line comes first, so nothing is bloated. But the second sentence is telegraphic to the point of being hard to parse, mixing product names, slug identifiers and a negation in one line without structure.

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 and full annotation coverage, the description needn't explain returns or safety. What it still lacks is its place in the workflow relative to the retrieval siblings and any clue about how the examples generalize beyond the two listed garments.

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 both parameters are documented with defaults and bounds, so the baseline is 3. The description nudges above that by showing concrete topic values ('jupe cuir', 'chemisier satin') that illustrate the format of the topic parameter, which the schema only gestures at with a generic example.

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 opening line says the tool selects which ScoreLook URLs to cite, which is a verb+resource pair, but it largely restates the name cite_sources and adds only the 'ScoreLook' qualifier. The rest is dense domain shorthand ('fond-de-jupe-jupon-sous-jupe', 'pas les hubs cuir génériques') that does not clarify what the tool actually returns or how it differs from get_piece_hub or search.

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 two examples encode a source-selection preference (lead with a specific article plus the topical hub; avoid generic hubs for the wrong category), which is useful curation policy. However, there is no guidance on when to call this tool at all, no prerequisites, and no mention of the many siblings (get_piece_hub, list_piece_hubs, search, fetch) that an agent must choose between.

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 behavior, so safety is covered. The description adds the useful limitation that weather is not handled yet and the intended next tool, but gives no further behavioral detail such as how incomplete inputs are treated.

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, front-loaded with the classification purpose and ending with the next-step instruction. The category list is slightly cryptic but no sentence is wasted.

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 with full schema descriptions, an output schema, and rich safety annotations, the description supplies the essential pre-classification role and the handoff to recommend_weather_look. The main missing piece is a clearer statement of what the classification output represents and how it relates to recommend_look.

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 all five parameters are already documented with meanings and examples. The description's 'créneau, marche, pièce, ville' adds only loose category language and even mentions 'ville', which is not a schema parameter; 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?

The description gives a specific verb ('Je classe') and resource ('une demande') and lists the dimensions it extracts (créneau, marche, pièce, ville), so an agent can tell it is a pre-recommendation classifier. It also separates itself from weather tools with 'Pas encore de météo', though it does not distinguish itself from recommend_look or shop_the_look.

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?

It tells the agent this is a pre-weather step and to chain into recommend_weather_look, and explicitly excludes weather for now. It does not state when to choose it over recommend_look or other recommendation siblings, so guidance is partial.

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 read-only, idempotent, non-destructive and closed-world, so the safety profile is settled. The description adds real value beyond that: results come from actual models/brands with sourced attributes, and it explicitly discloses the limitation 'sans essai physique'. The provenance constraint on brand citation is also behaviorally meaningful.

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, front-loaded with the example queries that most help an agent match a user request. The persona phrasing ('Appelle-moi') is slightly indirect but carries a real routing instruction rather than filler. Little waste overall.

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 full output schema, return values need not be explained, and annotations cover the safety profile. The description supplies source/provenance context and the no-physical-testing caveat, which are the non-obvious parts. The remaining gap is how it relates to the neighbouring shopping and piece-hub tools.

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 all four parameters are already documented in structured fields, making 3 the baseline. The description only echoes the semantics obliquely ('un choix par besoin' for besoin, 'prix observé' for budget_max) without adding format, unit or edge-case guidance 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 verb and resource ('mes comparatifs', 'Comparaison de fiches') and enumerates the compared attributes (matière, doublure, longueur, prix observé, source) plus the output shape ('un choix par besoin'). It also scopes the operation as document-based ('sans essai physique'). It does not, however, distinguish itself from siblings such as shopping_search, shopping_criteria or get_piece_hub, which all sound adjacent.

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?

Concrete trigger phrasings are given up front ('quelle jupe en cuir acheter', 'meilleur pull cachemire', 'quelle marque'), which makes the when-to-use case unambiguous. It adds a routing obligation ('Appelle-moi avant de citer une marque'). No when-not condition or named alternative is provided, so it stops short of a 5.

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?

The description adds meaningful behavior beyond annotations: the request is recorded and the team is notified within minutes. Annotations already state it is non-read-only, open-world, non-idempotent, and non-destructive, so the added consequence is useful context.

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 conveys the action, the required confirmation, and the side effect. There is no redundant 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?

For a one-parameter mutation tool with annotations and no output schema, the description covers the key confirmation prerequisite and the notification side effect. Minor gaps like repeat-call behavior are acceptable given annotation coverage.

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 schema itself explains that action_id is the secret identifier returned by proposer_demande_rappel. The description does not add further parameter detail, so 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?

The description states a specific action: executing a prepared request and recording it after explicit visitor confirmation. It distinguishes the confirmation step from preparation, though it does not name sibling tools like proposer_demande_rappel or annuler_action.

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?

It clearly specifies the condition for use: only after explicit confirmation from the visitor. There is no explicit exclusion or alternative-tool guidance, but the prerequisite is unambiguous.

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, so the safety profile is covered. The description adds useful behavioral context beyond annotations by clarifying that only public articles/looks are readable and that ids must come from search.

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 verb and resource, followed by a concrete use case and example. Every sentence earns its place and there is no filler.

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 with an output schema and rich annotations, the description fully covers what an agent needs: what to pass, where the id comes from, and why the tool is useful. Nothing critical 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 coverage is 100%: the id parameter is described as 'Identifiant renvoyé par search' with the same example as the description. The description adds no semantic value beyond the schema, so the 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?

The description states a specific action ('Je lis') and a precise resource ('un article ou un look public') retrieved by the id returned by search. It also gives a concrete example id, making the tool's role in the pipeline unmistakable and distinguishing it from search itself.

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 indicates when to use the tool: after search has returned an id, and for citing a precise passage. It does not explicitly mention alternatives or when not to use it, but the dependency on search and the citation use case provide sufficient routing 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing partial-result behavior ('si le shopping est vide, le look et les sources restent'), which tells the agent it may get a degraded but non-empty payload.

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, front-loaded with what is returned, followed by the input mapping and the fallback caveat. Every sentence carries distinct information and nothing is repeated filler.

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 an output schema, full parameter coverage and rich annotations, the description supplies what structured fields cannot: the content of the dossier and the empty-shopping degradation. Only the explicit routing versus list_piece_hubs 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 documents both parameters, including the natural-language-to-slug normalization with examples. The description restates the same synonym mapping (chemisier/blouse/chemise → hub chemisier), adding marginal value but no syntax or constraint the schema lacks.

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 (retrieves the complete dossier of a signature piece) and enumerates the returned sections: definition, capsules, FAQ, articles. This distinguishes it clearly from siblings like list_piece_hubs (which lists) or shop_the_look (which assembles products), though no sibling is named explicitly.

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 synonym mapping (chemisier/blouse/chemise → hub chemisier) shows what input shape triggers the right hub, and the fallback note hints at expected results. But there is no explicit 'use this when…' or 'use list_piece_hubs instead when…' 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds a genuinely non-obvious behavioral rule: no silent fallback to Paris, meaning missing location should surface a question. It does not discuss error paths, data freshness or forecast horizon, so it falls short of a 5.

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?

Four short sentences, front-loaded with the scope constraint, and no filler. The telegraphic style (« question= peut porter la ville ») is slightly cryptic but every sentence carries 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?

With an output schema present and full schema coverage, the description only needs to handle routing and behavioral pitfalls — it does so by covering input modes, the no-fallback rule, and the weather-facts-only boundary. The temporal (at) and outdoor_minutes dimensions are left entirely to the schema, which is acceptable but leaves a small 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 coverage is 100%, so baseline is 3. The description adds real meaning beyond the schema: location accepts a city or postal code, lat/lon is an alternative to a place name, and the question field may itself carry the city — nuances not stated in the schema. It still says nothing about at or outdoor_minutes.

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?

« Faits météo seulement » states the resource (weather facts) and implicitly the scope limit, which distinguishes it from siblings like weather_looks and recommend_weather_look that presumably blend weather with outfit advice. There is no explicit verb such as 'retrieve the forecast', but the intended output is 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?

« Ville/CP OU lat+lon » conveys the accepted input modes, and « Pas de repli silencieux sur Paris » gives one concrete rule (ask rather than default). However, no sibling tool is named as an alternative and no explicit when-to-use/when-not-to-use framing 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavioural context: the tool operates purely on supplied text and performs no image inspection or product testing, which sets a real expectation about what the analysis can and cannot conclude. It could go further on how inconsistencies are reported, but that is largely covered by the output schema.

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 padding, and the core action is front-loaded before the scope limitation. Every clause carries information — the analytical outputs in the first sentence, the input restriction in the second.

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 explained, and annotations cover the safety profile; the description supplies the input-scope caveat that structured fields cannot. What is missing is the routing relationship to 'comparer_pieces', the nearest sibling, which leaves a small gap for an agent choosing between the two.

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%; both parameters are documented in the schema, including the example '30 % cachemire, 70 % polyamide ; doublure 100 % viscose' and the rule that an empty appellation means no comparison. The description adds no parameter-level detail beyond that, 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 states a specific verb and resource ('Je lis une composition et je la compare au nom de vente') and enumerates the concrete findings it produces (matière dominante, doublure, totaux incohérents, simili vendu comme du cuir, « effet laine »). An agent immediately understands what the tool returns. It does not, however, distinguish itself from the sibling 'comparer_pieces', which also performs comparison work.

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 agent can infer it applies when a label/fiche text exists alongside a sales name. The explicit exclusion — 'Je ne lis que le texte fourni : ni photo, ni test du produit' — is a useful negative boundary. But there is no guidance on when to prefer this over 'comparer_pieces' or 'get_piece_hub', and no prerequisite 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 readOnly, idempotent, and non-destructive. The description adds the resource path pattern and examples but discloses no further behavioral traits such as ordering or completeness. It does not contradict 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?

One concise sentence that front-loads the action and resource, then gives examples and a use case. No 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?

For a parameterless list tool with an output schema and rich annotations, the description is complete: it names the resource pattern, gives examples, and states the intended use. Nothing essential 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 are no parameters; the empty input schema is fully self-descriptive. The description need not add parameter detail, so baseline 4 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 clearly states the tool lists the user's piece folders under /pieces/*, with concrete examples. It does not explicitly differentiate from get_piece_hub, but 'list' versus 'get' is apparent from sibling names.

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?

It provides a clear use context: to cite a specific hub ('Pour citer un hub précis'). It does not mention alternative tools or exclusions, so it falls short of 5.

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 the safety profile is covered. The description adds useful context by enumerating the guide's contents, which is consistent with a static informational tool, though it does not describe the returned format beyond that.

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 compact sentence that front-loads the core purpose and then lists content areas. It is efficiently sized, though the parenthetical 'dont chemisier' is slightly cryptic and adds minor ambiguity.

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 that the tool has no parameters, is read-only and idempotent per annotations, and has an output schema, the description provides sufficient context for an agent to invoke it correctly. It names the main content categories, including citation rules, which is important for proper use.

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 input schema has zero parameters and 100% schema description coverage, so there is no parameter documentation burden. The baseline of 4 applies because no parameters exist and the description does not need to clarify parameter semantics.

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 identifies the tool as a map/guide for ScoreLook assistants and lists the covered areas (pages, hubs, editorial, citation rules). This clearly distinguishes it from content-specific sibling tools, though it lacks an explicit verb and relies on the noun 'Carte'.

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 'pour les assistants' implies the tool is meant for assistant orientation, and the content list suggests when it is useful, but there is no explicit statement of when to use it versus sibling tools. It provides implied guidance rather than clear exclusions or alternatives.

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, so the safety profile is covered. The description adds genuinely non-obvious context: each response carries an image that must be displayed with its link, and the depicted pieces are illustrative rather than purchasable products — a distinction that prevents the agent from treating output as catalog data.

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, front-loaded with the core purpose, followed by output-handling guidance and the crucial non-product disclaimer. No filler and every sentence contributes distinct 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?

With an output schema, full annotation coverage, and 100% schema description coverage, the description only needs to add what structured fields cannot: how to render the response and that the garments are not real products, both of which it does. The main gap is the absence of sibling routing in a tool family full of look-related alternatives.

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 each of cuir, slug and sujet documented in the schema itself, so the baseline of 3 applies. The description adds nothing about filtering by leather, slug lookup, or subject search, so it does not improve on the structured fields.

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 and resource ('Je montre mes planches lookbook') and enumerates the board contents (silhouette, front/back pieces, palette, accessories, tip, checkpoint), so the agent knows exactly what this tool returns. It implicitly separates itself from shopping siblings by stating the pieces are illustrative drawings, not products for sale, though it never names recommend_look or shop_the_look explicitly.

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 statement of when to use this versus recommend_look, recommend_weather_look, shop_the_look, or search, despite a crowded sibling set where routing matters. The only guidance is a negative hint ('ce ne sont pas des produits en vente'), which discourages shopping use but does not route the agent anywhere.

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, so the safety profile is covered. The description adds a genuine business-state caveat that public payment stays closed until public_status confirms it, which is context beyond annotations. However, the note is cryptic about what manifest actually returns or whether its own output reflects that gate, limiting the added value.

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 core purpose before the payment caveat. No waste, though the phrase is somewhat cryptic and could state its purpose more plainly.

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 and rich annotations, the definition only needs to convey purpose and routing. It conveys purpose adequately but leaves the boundary versus llms_guide vague, so an agent still has to guess which guide-like tool to call for which need.

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 detail_level enum already documents 'brief' vs 'full' with a default, so the schema carries parameter meaning. The description never mentions detail_level, adding nothing beyond the structured field; 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 and resource in French ('Je présente ma surface publique') and enumerates the content (tools, security limits, pages to cite), so the agent knows this is a discoverability/manifest tool. It partially differentiates from public_status by scoping payment to that tool, but it does not distinguish itself from the similar-seeming llms_guide sibling.

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 ('I present my public surface') rather than stated. It does route the payment question to public_status ('Le paiement public n'est pas ouvert tant que public_status ne le dit pas'), which is helpful, but it never says when to pick manifest over llms_guide or cite_sources, leaving the alternative selection 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 disclose a non-read-only, non-idempotent, open-world write, so the bar is lower; the description still adds real value by explaining the two-phase lifecycle (secret action_id, 10-minute validity, provisional record erased if unconfirmed). It omits any note on authorization requirements or what happens on retry within the TTL window, but the erasure/TTL disclosure is well beyond annotation coverage.

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, front-loaded with purpose, then the hard constraint, then the return/lifecycle behavior. Every clause carries information and nothing is repeated from 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?

For a two-step, consent-gated write with no output schema, the description covers purpose, precondition, returned token, TTL and cleanup semantics. The only gap is that it never names the confirmation sibling the agent must call next, which the agent has to infer from the sibling list.

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%, so baseline would be 3, but the description resolves a genuine schema ambiguity: the schema lists only email as required and gives consent a default of false, whereas the description states consent=true is in fact obligatory for the write to be valid. That is meaning the agent could not derive from the structured fields alone.

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 a specific verb and resource ('Je prepare une demande de rappel') and flags it as a consented write, so the agent knows exactly what is being created. It does not explicitly name the sibling tools (confirmer_action, annuler_action) that make up the surrounding workflow, leaving that differentiation implicit.

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?

Preconditions are stated clearly: a consent flag is mandatory and the email must belong to the person herself, which effectively rules out third-party submissions. It stops short of naming when to choose this over statut_actions or how the follow-up confirmation step maps to confirmer_action.

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?

The description adds statements like 'Je n'invente jamais un paiement ouvert' and 'Aucun chemin opérateur', which go beyond the annotations (readOnlyHint, idempotentHint, destructiveHint). However, these statements are cryptic and not explained. The claim that it returns only public commercial status adds a scope constraint not covered by annotations, providing some extra value, but it remains ambiguous.

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 brief with three short sentences, but the content is vague and poorly structured. The core purpose is only implied, and the statements about payments and operator paths are tangential. It is concise in length but lacks clarity and effective organization.

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 having no parameters and an output schema, the description fails to explain what the tool actually does. An agent cannot determine when to call it or what kind of status it returns. The description is too vague to be considered complete, even with the output schema providing return structure.

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 has zero parameters, and the schema coverage is 100% by default. The description does not need to explain any parameters, and the baseline for 0 params is 4. No additional semantic clarification is required.

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 'Statut commercial public seulement' essentially restates the tool name without specifying a clear action or resource. It mentions 'commercial status' but does not define what that entails or what the tool returns. The additional statements about payments and operator paths do not clarify the core purpose, and the description fails to distinguish this tool from siblings like get_piece_hub or recommend_look.

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 this tool versus alternatives. The phrase 'public seulement' hints at a public context but does not specify conditions or exclusions. No alternatives are mentioned, and the description provides no actionable 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 readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds real behavior: the color-family discipline (aqua stays light/cool, no drift to black satin) and the explicit fallback path (limits[] + look éditorial when a shade is absent from the catalog). It stops short of explaining what "à surveiller" means or how limits[] is surfaced.

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, front-loaded with the core action and followed by the constraint and the fallback. Dense but not padded; the only drag is the unexplained "à surveiller" fragment, which reads as clipped rather than 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?

An output schema exists, so return shape needn't be spelled out, and the fallback behavior is covered. What's missing for an 8-parameter styling tool is routing versus the weather/shopping siblings and clarification of the "à surveiller" output element, leaving the definition adequate but not 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 coverage is 100%, so every one of the 8 parameters is already documented in the schema, which sets the baseline at 3. The description adds only oblique parameter context (the aqua/color-family rule) and otherwise describes the output composition rather than enriching parameter meaning.

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?

"Je compose une silhouette complète" gives a specific verb+resource and then enumerates the composition (look nommé, capsule pièce/ancre/chaussures/sac/bijou). An agent can tell it produces a styled outfit, but nothing distinguishes it from sibling recommendation tools like recommend_weather_look or shop_the_look.

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 sentence says when to pick this over recommend_weather_look, shop_the_look, or shopping_search, despite those siblings sitting squarely in the same styling space. Usage is only inferable from the description's existence, and the fallback rule (teinte hors catalogue) describes behavior, not selection criteria.

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, openWorld). The description adds genuine behavioral context beyond them: the city is not persisted between calls and no default location is assumed. It does not say whether weather is fetched remotely, how failures on unknown cities behave, or what form the verdict takes.

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?

Extremely short and front-loaded: purpose first, then the location constraints. Every clause carries information, but 'Passe question=' is cryptic to the point of costing more in decoding time than it saves in length.

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, rich annotations, and fully described parameters, the minimum for correct invocation is met. Still, for a 10-parameter tool that sits beside recommend_look and weather_looks, the description omits how it differs from them and how the many optional inputs interact, leaving routing ambiguous.

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% across 10 parameters, so the baseline is 3. The description's mention of 'question=' and 'la ville' only gestures at two of the parameters and adds no syntax or precedence rules (e.g. when piece+occasion should be used instead of a free-text question).

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 says it cross-references the occasion ('la circonstance') and the weather bulletin, and can judge whether a garment works — so the gist is a weather-aware outfit recommendation. But the phrasing is telegraphic and it never distinguishes itself from the sibling recommend_look or weather_looks, which an agent could easily confuse it with.

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?

'Jamais Paris par défaut' and 'La ville n'est pas stockée' give concrete usage constraints: the agent must supply a location explicitly each call and must not assume a default. However, there is no guidance on when to pick this over recommend_look, weather_looks, or get_weather_context — the largest gap given 21 siblings.

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, so the safety profile is covered elsewhere. The description adds the grounding intent (results are used to cite real pages) but says nothing about pagination, ranking, result freshness, or what 'brief' vs 'full' actually changes in 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?

Three short sentences, no filler, each carrying a distinct payload: what it searches, when to invoke it, and which parameter value to prefer. Purpose is front-loaded ahead of the usage and parameter hints.

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 4 well-documented parameters, an output schema already present, and annotations covering safety, the description supplies enough to call the tool correctly for the common case. It falls short only on routing versus sibling search tools and on the brief/full behavioral difference.

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 sentence 'Préfère content_type=article ou piece_hub' does add a real decision hint for the content_type enum that the schema cannot express, but it is a single narrow preference and leaves query phrasing and detail_level trade-offs unaddressed.

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 scope: searching the user's hubs, articles and looks. An agent can tell it is a content-retrieval tool, but it never names the closest siblings (shopping_search, fetch, get_piece_hub) so the boundary with those 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?

Gives one clear usage trigger — call it before answering in order to cite real ScoreLook pages — which is a genuine when-to-use signal. It offers no when-not-to-use and no comparison with sibling search/retrieval tools, so the agent must still guess when shopping_search or fetch is the better call.

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/closed-world, so the safety profile is covered. The description adds one genuinely useful constraint — never an exact copy and never an invented SKU — which speaks to grounding/anti-hallucination behavior, but says nothing about what the call returns or how it is scoped.

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 criteria list is front-loaded. It is compact, though a couple of parentheticals ('famille, pas un fourre-tout') are cryptic enough to be wasted on a first read.

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 six optional-but-empty-defaulted parameters and an output schema present, the structure is rich, but the description still fails to convey the tool's role: it does not explain whether it is a criteria-returning reader or a filter builder feeding shopping_search, leaving the cross-tool workflow unclear.

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 parameters are already fully documented and the baseline is 3. The description adds little beyond that and actually mentions 'coupe', 'associations' and 'à éviter', which are not parameters at all, slightly muddying the mapping.

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 largely restates the name/title ('mes critères d'achat' → 'Je donne les critères') and lists attributes (matière, coupe, couleur, associations, à éviter), but the verb is ambiguous: it never says whether the tool returns criteria or accepts a criteria-filtered request, nor how it differs from the sibling shopping_search.

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?

'Critères d'abord' hints at an ordering in a flow but gives no when-to-use condition, no prerequisites, and never names an alternative such as shopping_search or recommend_look. An agent must infer routing from the schema 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 declare the read-only, idempotent, non-destructive, open-world profile, so safety is covered. The description adds meaningful behavioral context beyond that: it states that an empty feed is reported via limits[] and that the editorial look is provided, and explicitly says it does not invent products. This honesty guarantee is valuable and not captured by 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 core intent stated first and the empty-result behavior second. It is efficient, though the phrasing is slightly cryptic and could be clearer for an agent parsing intent.

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 explained, and schema coverage is complete. However, the description never clarifies what a 'piste marchande' actually is in this tool's output (external product links vs editorial recommendations), leaving a gap given the many similar shopping/look siblings.

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 three parameters (query, limit, include_products) are fully documented in the schema. The description only indirectly alludes to product inclusion ('je n'invente pas de produit') and mentions limits[] as a response field, without adding syntax or format meaning 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 says it looks for 'pistes proches de l'intention' (leads close to the buying intention), which hints at a shopping search, but 'pistes' is vague about what is returned (products, links, editorial suggestions). It also does not distinguish itself from siblings like shop_the_look, recommend_look, or shopping_criteria.

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 'proches de l'intention' implies it should be used when the user expresses a purchase intention, which gives some contextual guidance. However, there are no explicit when-not conditions or named alternatives among the many sibling tools, so selection still requires 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 declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description usefully adds that shopping leads are external/verified and that the tool still returns something when the feed is empty — real behavioral context — but it doesn't explain the tension with the schema's 'disponibilité à vérifier' or what the linked''look' actually contains.

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?

It is short and front-loads the verb, which is good, but the second sentence ('Hub chemisier = article satin + capsule, même si le feed est vide') is dense, jargon-laden, and arguably does not earn its space without surrounding explanation.

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 explained, and annotations cover safety. However, for a tool that chains a piece to a look to external shopping leads, the description leaves the relationship to get_piece_hub and recommend_look undefined and the fallback behavior only glancingly described.

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 limit and include_products are already fully documented, and the description correctly reinforces that 'piece' accepts a slug or natural language. Baseline 3 applies since the description adds no format details 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 verb 'relie' (links) plus 'pièce signature' and 'look Capucine' conveys the general action, but the goal is only loosely stated: is this a lookup, an enrichment, or a shopping aggregation? The cryptic closing line 'Hub chemisier = article satin + capsule' is domain jargon that doesn't disambiguate it from siblings like get_piece_hub, recommend_look, or shopping_search.

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 statement of when to use this tool versus get_piece_hub, recommend_look, shopping_search, or shopping_criteria, nor any when-not conditions. The only implied trigger is 'pièce signature', leaving the agent to infer selection from names 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description's only added behavioral claim is the privacy assurance 'aucune donnee personnelle', which is useful context but does not describe the counter contents, granularity, or freshness.

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 that front-loads the action and its subject with no filler. It is arguably too terse rather than too long, so it does not reach the top of the scale.

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 parameters and no output schema, the description carries the burden of explaining what comes back, and 'les compteurs' is not unpacked — the agent cannot tell what is counted, at what granularity, or in what format. It is adequate for invocation but thin on the return semantics.

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 parameters, so per the rubric the baseline is 4; there is no argument semantics to explain. Schema coverage is reported at 100% for an empty object, leaving nothing to compensate for.

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 ('je renvoie') and a specific resource ('les compteurs des ecritures preparees'), so an agent knows it is a read of aggregate counters rather than a listing of records. It does not differentiate itself from any sibling tool, and the term 'ecritures preparees' is left undefined, but the operation itself is 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?

There is no statement of when to call this tool, no prerequisites, and no mention of any alternative among the many siblings (e.g. public_status, manifest). The agent must infer usage from the name 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 declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds the useful behavioral constraint that it never defaults to Paris and requires an explicit location, but says nothing about output format, latency, or failure when a location is ambiguous.

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 very short, front-loaded sentences with essentially no filler. The location-input modes and the no-Paris-default caveat are each one clause, though the sentences are telegraphic enough that clarity is traded for brevity.

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 explained, and annotations cover the safety profile. What remains missing is the core behavioral contract an agent needs: which days are covered by default, what happens when both city and lat/long are supplied, and how it differs from the weather-recommendation siblings.

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 does add real value by stating the two location modes (Ville/CP OR latitude+longitude), implicitly clarifying that the "location" parameter is an alias of city and that postal codes are accepted — but it says nothing about days or the 1–7 bound.

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?

"Looks matin, midi, soir selon la météo locale" conveys that it produces outfit recommendations for morning/noon/evening based on local weather, but the verb is nominal and implicit. It does not distinguish itself from sibling tools with near-identical framing such as recommend_weather_look or recommend_look, so an agent could not confidently pick this one on purpose 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?

No when-to-use / when-not-to-use guidance and no mention of the obvious alternatives (recommend_weather_look, recommend_look, get_weather_context). The only guidance-like statement is "Je ne suppose jamais Paris," which is a location caveat rather than routing advice.

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