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

Annotations already declare destructive/not-idempotent/open-world, and the description adds substantial extra context beyond them: the final status is controlled by Avito (async uncertainty), the ad must be re-read after acknowledgement, and automatic retries are forbidden. This directly complements the non-idempotent and destructive hints with operational guidance.

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, dense sentences with zero filler, front-loading the action and following with the two most important operational caveats. Every sentence carries 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?

For a mutation tool whose safety profile is already in annotations and with no output schema, the description covers the key gaps: uncertain outcome, verification via re-reading, and retry prohibition. Remaining minor gap is the semantics of confirm, but overall it is complete enough to call safely.

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 50%: adId is documented in the schema (distinct from the public listId), while confirm has no schema description. The phrase 'après accord explicite' loosely maps to confirm=true, but the description adds no further parameter syntax or meaning, 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 verb and resource ('Demander l'activation d'une annonce du compte'), and the framing as a request rather than a guaranteed state change is clear. It does not explicitly name its inverse sibling avito_deactivate_ad, so it stops short of full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear precondition ('après accord explicite') and an explicit when-not rule ('Ne jamais réessayer automatiquement en cas de résultat incertain'). It does not, however, name the alternative action (e.g. deactivate) or contrast scenarios, leaving that to the agent.

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 useful context that results are 'publiques' and what fields the payload contains, but says nothing about rate limits, result caps, or how the dynamic values should be consumed.

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 action and free of filler. The second sentence is slightly vague ('identifiants et valeurs dynamiques') but still carries real information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, read-only tool with no output schema, the description covers the return contents (categories, cities, types, parameters) and the discovery purpose, which is enough to call it correctly. The missing piece is any guidance on the query string itself.

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 never addresses the single 'query' parameter. The autocomplete framing implies a partial search string, but neither the 1-200 character bounds nor whether it accepts partial text or category fragments is conveyed, so the description does not compensate for the coverage gap.

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 ('Obtenir') and resource ('suggestions publiques de recherche') and enumerates what comes back: catégories, villes, types, paramètres. It is clearly distinguishable from sibling search tools like avito_search_ads by being a suggestion/autocomplete endpoint, though it never names a sibling 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?

The second sentence ('Permet de découvrir des identifiants et valeurs dynamiques') implies the intended use case: resolving dynamic IDs/values, presumably before a real search. There is no explicit when-not or named alternative, so usage remains implied rather than 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 destructiveHint=true, readOnlyHint=false, idempotentHint=true and openWorldHint=true, so the mutation and safety profile is largely covered. The description adds that it 'modifies the blocking state' and acts on the connected account, but does not disclose reversibility (via unblock), auth requirements, or side effects beyond what the annotations imply.

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 zero filler; the action is stated first and the disambiguation hint follows. Nothing 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 one-parameter mutation whose annotations fully cover the safety profile and whose single parameter is schema-documented, the description is essentially sufficient. A brief mention of the unblock counterpart 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 there is a single required parameter (conversationId) documented directly in the schema. The description adds no format, sourcing, or constraint detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (bloque) and resource (conversation Avito) and scopes it to the connected account, which is enough to distinguish it from the inverse unblock sibling and from the read-only conversation tools. It stops short of naming those siblings explicitly, so it lands just under a full 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The warning 'ne pas confondre avec une simple lecture' implies this is a state-changing operation rather than a fetch, giving some usage context. However, it never says when to block versus unblock (avito_unblock_conversation) or what prerequisites exist, leaving the routing decision implicit.

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 operation as read-only, idempotent, open-world, and non-destructive. The description adds that it works 'sans connexion' (without login), which is useful context, but it does not describe return format, pagination, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences front-load the core action and include a specific usage tip. Every sentence earns its place with 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 tool with 19 parameters, low schema coverage, nested objects, and no output schema, the description is too sparse. It covers the high-level purpose and one parameter tip but leaves most filter semantics and expected output unexplained.

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 only 21% across 19 parameters, so the description carries a heavy burden. It only repeats the isPremium guidance already present in the schema and says 'filtres' generically, failing to compensate for the many undocumented 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?

States a specific verb ('Compter') and resource ('annonces publiques') with the scope of filters and no login needed. It also names the sibling avito_search_ads and clarifies the relationship via isPremium:false, though it does not fully distinguish all counting scenarios from 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?

Provides a concrete instruction for one parameter: 'Utiliser isPremium:false pour compter le flux principal de avito_search_ads.' This implies the tool is for counting rather than listing, but does not explicitly state when to use it versus avito_search_ads or other 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 destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context: it does not delete the account, it requires the user's explicit consent, and it must not be retried automatically on an uncertain result — all non-obvious operational constraints.

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 action, followed by the scope constraint and the retry rule. No filler or repetition of the name.

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 destructive, non-idempotent mutation with a nested reason object and no output schema, the description covers consent, non-deletion and retry behavior adequately. It omits what state the ad ends in and whether the action is reversible, which would be useful for a destructive operation, but the core is 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 only 33%, so the description must carry weight; it does explain the intent behind 'reason' (motif choisi par l'utilisateur) and 'confirm' (accord explicite). However, the adId parameter and the nested reason enums are left entirely to the schema, so it only partially compensates for the low coverage.

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 ('Désactiver une annonce précise du compte') and immediately scopes it by requiring a reason and explicit user consent. It is clearly a deactivation/mutation tool, distinguishable from read siblings like avito_get_my_ad, though it does not name the counterpart avito_activate_ad 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?

It implies usage through 'avec le motif choisi par l'utilisateur et son accord explicite' and gives a behavioral rule ('Ne jamais réessayer automatiquement en cas de résultat incertain'), but never states when to prefer this over alternatives such as not deactivating or editing the ad. Usage context is implied rather than spelled out.

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

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

Annotations already flag destructiveHint=true and idempotentHint=false, but the description adds the operational consequences that annotations cannot: immediate credit debit, one-attempt-consumes-the-quote semantics, and a no-auto-retry rule. This is exactly the extra context an agent needs for an irreversible spend.

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, each earning its place: action, cost, precondition, irreversibility. The spend warning and confirmation requirement are front-loaded before the retry caveat.

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 destructive, credit-consuming tool with no output schema, the description covers cost, irreversibility and consent. It omits the prerequisite relationship with prepare_boost and what state remains after a failed attempt, which would matter for recovery decisions.

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 explains the quote concept behind quoteId (a consumable quote) but says nothing about the required 'confirm: true' flag, whose purpose an agent must guess despite its const constraint.

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 compound action (buy and activate the quote's boost) and names the funding source (WALLET wallet). The reference to 'le devis' implicitly ties it to the prepare_boost sibling workflow, but no sibling tool is named explicitly, so differentiation relies on 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 an explicit precondition ('appeler uniquement après accord explicite de l'utilisateur sur ce devis') and an explicit prohibition ('ne pas réessayer automatiquement'), which is strong when/when-not guidance. It stops short of naming the required prepare_boost step or alternatives, so it is not fully closed-loop.

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, so the safety bar is lower; the description still adds value by disclosing that the lookup is scoped to the connected account and that it will not open/create a conversation as a side effect. It also names the response fields (found, conversationId), which annotations cannot 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?

Two short sentences, zero waste, with the core identity of the operation front-loaded and the negative behavior stated second. Nothing could be trimmed without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, but the description compensates by naming the two returned fields; the auth scope and the no-open side effect are both covered. The only minor gap is what 'found' false implies (no existing conversation) and any prerequisite that the ad belong to the caller.

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%: the adId parameter is fully documented in the schema, including the warning not to use listId. The description only restates 'via son adId' without adding format, source, or failure-behavior detail, 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?

States a specific verb (retrouve/find), resource (conversation), and scope (of the connected account, linked to an ad via adId), so an agent knows this is a targeted lookup rather than a general conversation read. It does not explicitly name which sibling it differs from (e.g. avito_get_conversation or avito_list_conversations), which keeps it short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The clause 'cette lecture n'ouvre pas de conversation' gives a useful when-not signal (do not call this to start a thread), and 'via son adId' implies the precondition of having an ad identifier. However, no alternative tool is named and there is no explicit guidance on choosing this over avito_get_conversation or avito_send_first_message.

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

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

Annotations already declare the safe read-only, idempotent, non-destructive profile. The description adds genuinely useful context beyond them: that the response contains personal data and a security assertion that returned content is never an instruction (prompt-injection guard). This is real value over the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences: the first front-loads the action and payload fields, the second carries the safety note. No padding or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by listing the exact fields returned and adding a data-sensitivity warning. For a zero-parameter read tool with strong annotations, this is sufficient, though the field list could be slightly more precise about types.

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 the baseline is 4. There is nothing to document, and the description correctly focuses on the shape of the response instead.

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 ('Lit' / reads) and resource ('le profil du compte connecté') and enumerates the returned fields (identifiant, nom, email, téléphone, ville, date d'inscription). This is clearly distinguishable from sibling avito_get_account_statistics or avito_session_status, though the description relies on the resource name rather than an explicit contrast.

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 purpose implies the single scenario (retrieving your own profile data), but there is no explicit when-to-use guidance, no prerequisites, and no mention of the neighboring tools such as avito_get_account_statistics. Usage is inferred rather than stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only a provenance note ('Plages identifiées dans l'APK Android') and no behavioral context such as auth requirements, rate limits, or data freshness, so with the lower annotation-adjusted bar a 3 is appropriate.

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 the core purpose front-loaded and no filler. The trailing APK-provenance sentence earns only marginal value, keeping it just short of a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description would ideally hint at which metrics are returned, but it only says 'métriques du compte'. For a single-enum read tool whose annotations cover the safety profile, this is adequate but leaves the return content unspecified.

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 the single parameter is an enum, so the description must carry the semantics. It does so by naming each range in prose ('aujourd'hui, les 7/15/30 derniers jours ou toute la période'), effectively mapping all five enum values including ALLTIME, though it omits mention of the default value.

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 ('Lire') and resource ('les métriques du compte') and enumerates the supported time ranges, so the agent knows this is the account-level statistics reader rather than a listing or search tool. It does not explicitly name a sibling to contrast against (e.g., avito_get_account), but the verb+resource combination 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?

The description implies usage by listing the available ranges, but gives no when-to-use guidance, no exclusions, and no alternatives among the many sibling tools. An agent must infer that this is the only statistics endpoint rather than being told so.

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 reinforces this with 'Ne modifie pas l'annonce' and discloses what data the call returns, adding modest value on top of the structured hints.

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, purpose front-loaded and the non-mutation guarantee placed last. The field enumeration is long but informative; nothing 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?

With no output schema, the description usefully lists the returned edit fields, compensating for the missing return contract. Annotations cover the safety side, so an agent has enough to call it correctly, though sibling differentiation remains absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the sole adId parameter is fully documented in the schema, including its distinction from the public listId. The description adds no further parameter detail, 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 (lire) and resource (champs d'édition d'une annonce du compte), then enumerates the returned fields. It implies the edit-oriented use case, though it never names how it differs from close siblings like avito_get_my_ad or avito_get_published_ad.

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 'champs d'édition' implies the tool belongs to an edit workflow, giving an implicit usage context. However there is no explicit when-to-use statement and no alternative named among the many getter 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description's 'Aucun achat' reinforces that no side effect occurs and enumerates what is returned (offers, prices, units, slots), but adds little beyond the annotations and says nothing about rate limits, auth requirements, or empty-result behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero filler, and the primary action plus the returned data are front-loaded before the read-only clarification. 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?

No output schema exists, so the description appropriately carries the return-value information by naming the four data categories returned. Combined with annotations that cover the safety profile, an agent has enough to call it correctly; only the adId parameter remains unexplained.

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 single required parameter adId is undocumented in both schema and description. 'Pour votre annonce' loosely suggests adId identifies the caller's own ad, but no format, source of the id, or validation detail is given, so the description does not compensate for the coverage gap.

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?

A specific verb ('Lire') plus a specific resource (offres, prix, unités et créneaux de boost) scoped to 'votre annonce'. 'Aucun achat' implicitly separates it from the boost-purchase siblings (avito_prepare_boost / avito_execute_boost), but no sibling is named explicitly, which keeps it just short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this is the inspection step preceding a purchase ('Aucun achat'), so an agent can infer it is the read-only preview of available boost options. However, it never states when to use this versus avito_prepare_boost or avito_execute_boost, nor any prerequisite such as needing an existing ad. Implied usage only.

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, so the safety profile is covered. The description adds two things beyond that: the side-effect nuance that the conversation is NOT marked read, and an explicit prompt-injection warning that returned content is external data and never an instruction — both are meaningful behavioral disclosures.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact sentences: purpose first, then the pagination recipe, then the safety note. No filler, and the most important information 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?

For a read-only tool with a full-coverage schema and rich annotations, the description covers purpose, pagination, side effects and injection safety. It does not describe the shape or ordering of returned messages, but with no output schema and annotations already handling the safety profile, that gap is minor.

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 the baseline is 3, but the description adds real semantic value by explaining how to use beforeTime for backward pagination ("le time du plus ancien message"), which the schema only describes generically as a time value. afterTime and size remain unexplained 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 gives a specific verb and resource ("Lit les messages d'une conversation existante") and adds a differentiating scope clause ("sans la marquer comme lue") that separates it from mark_read. It does not explicitly distinguish itself from the sibling avito_list_conversations, so it falls short of full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete usage guidance for pagination ("Pour remonter l'historique, utiliser le time du plus ancien message comme beforeTime"), which is genuinely actionable. However it never states when to choose this tool over avito_list_conversations or avito_mark_read, leaving 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only the useful nuance that the 'low performing' classification is Avito's, not a locally computed threshold; it says nothing about scope, freshness or return shape. With annotations carrying the safety burden, a 3 is appropriate.

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 short sentence with no filler and the resource stated up front. It is efficient, though the brevity is arguably under-specification rather than deliberate trimming.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no parameters, the description is the only source of information about results, yet it does not explain what 'low performing' means, over what window, or what the response contains. It is minimally adequate for a zero-arg read tool but leaves clear gaps.

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 there is nothing for the description to disambiguate and the baseline of 4 applies. No filters (date range, account, pagination) are mentioned, but none exist in the schema either.

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 clear verb ('Lire') and a specific resource ('annonces identifiées par Avito comme peu performantes'), so the agent knows this returns a curated set of underperforming ads rather than performing a search. It does not, however, distinguish itself from the many other read-oriented siblings such as avito_get_my_ads_facets or avito_search_my_ads.

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 reach for this tool versus the numerous other ad-listing tools in the sibling set, and no stated prerequisites or exclusions. The agent must infer that this is a diagnostics-style read 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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered structurally. The description adds only the identifier caveat and says nothing about return shape, whether the ad must be owned/active, or error behavior, so it clears the lowered bar without excelling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with zero filler, and the essential disambiguation is placed in a parenthetical right after the parameter is named. Nothing could be trimmed without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only single-parameter tool whose annotations already convey safety, this is close to sufficient. It omits where adId comes from, whether only the caller's own ads resolve, and any hint about the returned detail object, which leaves gaps for an agent working without an output schema.

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 one parameter at 0% schema description coverage, the description carries the burden and does address the key ambiguity: 'à partir de son adId (pas listId)'. However, it does not explain the format, length limit, or where to obtain an adId, so compensation is partial rather than complete.

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 ('Lire le détail d'une annonce du compte') and pins down that the lookup is scoped to the authenticated account's ad. It stops short of naming which sibling it replaces (e.g. avito_get_published_ad or avito_get_ad_for_edit), so it is 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?

Usage is implied by 'du compte' — use it when you want details of one of your own ads — and the adId/listId caveat steers the caller to the right input. There is no explicit when-not guidance or mention of the competing read tools (get_published_ad, get_ad_for_edit, search_my_ads) 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, covering the full safety profile. The description adds no behavioral context beyond this — no mention of pagination, rate limits, or what the counters represent. It essentially restates the purpose without new behavioral 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?

A single clean, front-loaded sentence with no filler. It is efficient, though its brevity borders on under-specification rather than disciplined conciseness.

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 11-parameter, zero-required, no-output-schema tool with 18% schema coverage, one sentence is inadequate. An agent lacks the detail needed to invoke it correctly, especially around the params/adTypes cross-references the schema alludes to.

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 only 18%, so the description must compensate for 11 largely undocumented parameters, but it says nothing about page, pageSize, status, priceMin/priceMax, cityIds, etc. The vague word 'filtres' loosely maps to the params concept but adds no usable 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 states a specific verb and resource ('Lire les filtres et compteurs disponibles pour les annonces du compte'), making clear it returns facet/aggregation data rather than ad listings. However, it offers no differentiation from close siblings such as avito_search_my_ads or avito_count_ads, which the agent must infer.

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 the many search/count siblings. No prerequisites, no conditions, no alternatives are named, leaving the agent to guess 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 establish that this is a read-only, idempotent, non-destructive operation. The description adds that the result includes both store information and credits, which is useful context, but it does not disclose return format, pagination, or auth-related constraints.

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 definition is a single front-loaded sentence with no filler. It immediately states the action and scope without unnecessary detail.

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 read-only tool with full schema coverage and complete annotations, the description is nearly sufficient. It states the broad return content ('informations et crédits'), though it does not elaborate on the response shape, which is acceptable given the absence of an output schema.

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 single optional parameter storeId is already documented with its fallback to AVITO_STORE_ID. The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb ('Lire') and specific resources ('informations et crédits de la boutique') scoped to the connected account. It implicitly distinguishes this from the public-store sibling via 'du compte connecté', though it does not name the alternative 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 guidance on when to use this tool versus alternatives such as avito_get_public_store or avito_get_account. The phrase 'du compte connecté' implies it is for the authenticated user's store, but no when/when-not conditions or alternatives are 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuinely new behavioral context beyond the annotations: 'sans connexion' tells the agent no authentication is required, which is important for routing. No rate-limit or failure behavior is described.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with the resource first, then the ID source and condition. Every clause 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 simple one-parameter read-only public lookup with no output schema, the description covers the action, the parameter origin, and the no-auth condition. Nothing essential to correct invocation 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 0%, so the description must compensate. It does add meaning by explaining that storeId comes from a public ad, telling the agent where to obtain the value, but it gives no format/length/validation guidance beyond what the schema enforces (minLength 1, maxLength 100).

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 (Lire), resource (le profil public d'une boutique Avito), the ID source (à partir du storeId d'une annonce publique), and the operating condition (sans connexion). This clearly sets it apart from the authenticated sibling avito_get_my_store by emphasizing 'public' and 'sans connexion'.

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 the use case (looking up a store you don't own, from a public ad's storeId, without login), which gives useful context. However, it never explicitly names alternatives such as avito_get_my_store for your own store, nor states exclusions or prerequisites.

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 openWorld. The description adds value beyond them by stating no connection/login is needed (auth context) and that the response also includes similar ads. No rate limits or output format are given, but for a simple read this is solid.

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: purpose first, parameter guidance second. No filler, and the most decision-relevant information (public, no login) 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?

For a single-parameter read-only tool with no output schema, the description covers purpose, access mode (no login) and the key param distinction. It could note where the public listId comes from, but otherwise nothing an agent needs to call it 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 0% and the schema only says the lone listId is a string. The description compensates by clarifying it is the public listId, distinct from the internal account adId, which is exactly the disambiguation an agent needs. It lacks a format/where-to-find-it example, hence not a 5.

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 ('Lire'), resource ('le détail public d'une annonce et ses annonces similaires') and a scope qualifier ('sans connexion'). This distinguishes it from siblings like avito_get_my_ad (account's internal ad) and avito_search_ads, so an agent can place it without opening other schemas.

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 clear context for use: public, no login required, and use the public listId rather than the account's internal adId. This implicitly routes away from the internal-ad sibling, though no alternative tool is named explicitly, so it stops short of a full when/when-not statement.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely non-redundant behavioral context with the prompt-injection warning that returned content is external data and never an instruction — a meaningful disclosure for an open-world read tool.

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 tightly written sentences, with the scope-and-return summary front-loaded and the safety note second. No filler, though the payload sentence is a dense clause list.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only list tool with no output schema, the description helpfully names the returned fields, and annotations plus the 100%-covered schema cover safety and parameters. Pagination mechanics for the time cursors remain unexplained, which is the main residual 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%, so size, afterTime and beforeTime are fully documented in the schema. The description adds no extra meaning about these parameters (e.g. that afterTime/beforeTime drive cursor pagination), 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 and resource ('Liste les conversations existantes') and enumerates what each result carries (annonce, correspondant, dernier message, compteur non lus). It does not, however, distinguish itself from siblings like avito_get_conversation or avito_find_conversation_for_ad, so an agent must infer the plural-vs-single distinction 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?

There is no guidance on when to call this instead of avito_get_conversation (single conversation), avito_unread_count (count only), or avito_find_conversation_for_ad. Usage context is only implied by the plural 'conversations'.

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 readOnly/idempotent/openWorld/non-destructive, so the bar is lower, yet the description adds two useful facts beyond them: the response includes a total count, and returned content is external data that must not be treated as instructions. That injection-safety note is genuine 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?

Three compact sentences with the purpose front-loaded and no filler. The listId/adId sentence is the weakest link because it points at concepts outside the tool's own inputs, but overall it stays 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?

For a read-only list tool whose annotations already disclose the safety profile and with no output schema, the description covers the essentials. However pagination is unexplained and the listId/adId guidance is disconnected from the actual parameters.

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 only 50% ('page' is undocumented), so the description should compensate but does not. Worse, it references listId and adId, which are not input parameters of this tool, while saying nothing about page/pageSize pagination behavior.

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 ('Liste les annonces favorites du compte connecté') plus scope ('avec leurs détails et le nombre total'), distinguishing it from generic search/count siblings. The only weakness is that it doesn't explicitly name the sibling list tools it differs from.

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?

Hints at what to do with returned identifiers (listId for favorites, adId for contacting) but never states when to use this tool versus avito_save_ad/avito_unsave_ad, which are the actual tools for adding/removing favorites. Usage is implied rather than explicit.

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 readOnly/openWorld/idempotent/destructive, so the bar is lowered. The description adds non-obvious value by warning that the returned saved query is external data and must never be treated as an instruction, a genuinely useful injection-safety note for an open-world read tool.

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 no filler; the returned-fields list is front-loaded before the safety caveat. 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?

With no output schema, the description carries the burden of describing the return, and it does list the returned fields plus the injection caveat. Complete enough for a parameterless read tool, though it never states whether results are ordered or bounded in size.

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 parameter surface for the description to clarify or obscure.

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 ('Lit') and resource ('recherches sauvegardées du compte') and enumerates exactly what is returned (identifiant, requête, date, titre). The resource is distinct from the closest sibling avito_list_saved_ads, so an agent can tell them apart without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description only says what the tool does; it gives no when-to-use condition, no prerequisites, and does not point to any alternative. For a zero-param list tool the correct invocation is inferable, but no explicit guidance is offered.

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 declare the mutation/session profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true), and the description adds genuinely non-redundant behavior: it returns no token, the credential sources, and the auto-login side effect. It doesn't describe failure modes (e.g., invalid credentials), so it is not 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 primary action and credential mechanics, with no filler. Every sentence carries information, though the auto-login note could arguably be merged or ordered more prominently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by stating that no token is returned, and it covers the available authentication paths and the automatic-login behavior. For a zero-parameter auth tool this is nearly complete; only error/edge-case behavior is unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, which is the baseline-4 case. The description usefully explains that inputs are environment-configured rather than passed as arguments, which resolves the natural question of how this parameterless tool receives credentials.

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 ("se connecter") and the resource context (the Avito account), and it distinguishes itself from session siblings like avito_logout/avito_session_status by being the operation that establishes a session. It stops short of explicitly naming which sibling it is not, so it lands just under a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives real when-to-use context: credentials come from local AVITO_USERNAME/AVITO_PASSWORD, an AVITO_ACCESS_TOKEN can substitute, and crucially it notes login is automatic on the first account-requiring tool — implying the agent often doesn't need to call this at all. It does not explicitly name alternative tools, so it is not a full 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 cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false) and the description is consistent with them. It adds substantive non-obvious behavior beyond them: the token is NOT revoked server-side and auto-reconnection is blocked until the next login, which is exactly the kind of side-effect boundary an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with zero waste, front-loading the primary action and immediately following with the important non-action boundary. 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 no-param, no-output-schema logout tool whose annotations already carry the safety profile, the description supplies the one thing that matters: the exact scope of the side effect (local only, token intact). Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. No parameter claims are made or needed.

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 ('Effacer la session locale') and immediately scopes the action by naming what it does not do ('Ne révoque pas le jeton côté Avito'). An agent can distinguish it from avito_session_status and avito_login without inspecting anything else.

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 reconnection behavior is tied explicitly to the sibling flow ('jusqu'au prochain avito_login'), which tells the agent the natural sequencing. It stops short of an explicit when-to-use vs alternative statement, but the context is clear for a terminal logout 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 annotations already declare a write operation (readOnlyHint false, destructiveHint true, idempotentHint true). The description adds useful context by stating that the unread message counter is modified, but it does not explain permissions, reversibility, or the full side effects of the update.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It states the operation and its effect directly, which is appropriate for a one-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple mutation with one required parameter and no output schema, the description covers the main action and its result on the unread counter. It is missing usage guidance and return-value expectations, but those gaps are minor given the tool's low complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema fully documents the single conversationId parameter, including that it must be an existing Avito conversation identifier. The description adds no parameter-specific meaning beyond what the schema already provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a clear verb and resource: it marks an Avito conversation as read and modifies its unread message counter. It does not explicitly differentiate itself from related sibling tools such as avito_unread_count or avito_get_conversation, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use or when-not-to-use guidance is provided, and no alternative tools are named. The word 'explicitement' hints at a manual marking action, but it does not tell an agent when this tool is preferable to alternatives like avito_list_conversations or avito_get_conversation.

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 destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the quote expires in five minutes and no purchase occurs, which explains why idempotentHint=false. This is meaningful behavioral disclosure not present in structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences, front-loaded with the purpose ('Préparer un devis... sans achat') followed by the presentation instruction. Every clause carries weight with no filler, though the second sentence slightly compresses what could be procedural detail.

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 prepare-step tool with no output schema, the description adequately conveys purpose, the temporal constraint, and what data to surface to the user (the quote contents). It does not explain the full response structure or the exact handoff to execute_boost, leaving a minor gap for a workflow-position tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75% (adId, packId, executionSlotId documented in the schema). The description lists items to present (annonce, pack, prix, unité, créneau) but does not map these to parameter inputs or clarify executionDay, which is required yet undocumented in both places. Baseline 3 is appropriate since the schema does most of the work.

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 ('Préparer un devis de boost') and adds a key scope qualifier ('sans achat' / valable cinq minutes) that separates it from the actual purchase flow. It does not explicitly name the sibling avito_execute_boost, but the 'no purchase' framing implies the distinction clearly enough.

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 second sentence implies a workflow: present the quote to the user to obtain confirmation, which implies this is a pre-step before executing. However, it never names avito_execute_boost or avito_get_boost_packages explicitly, nor states when NOT to use this. Usage is implied rather than spelled out.

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

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

Annotations already declare readOnly/idempotent/openWorld/destructive=false, so the safety profile is covered. The description adds genuinely useful context beyond them: the output is a link meant to be opened on the external Avito.ma site rather than returned data, which explains the openWorldHint and steers the agent away from expecting ad results.

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 tightly written sentences with the core action front-loaded and no filler. The second sentence is purely routing, which is worthwhile content but slightly displaces behavior about the built link.

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, no-output-schema builder tool, the description covers what it produces and where to go for actual results, and annotations cover safety. The missing piece is any description of the 'query' parameter or what the returned link looks like.

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 only 50% (citySlug is documented with slug examples, query is not). The description mentions no parameters at all, so it fails to compensate for the undocumented 'query' parameter (maxLength 200, format unknown). Marginal value over the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Construire un lien de recherche') and immediately distinguishes itself from siblings by naming avito_search_ads and avito_search_my_ads. An agent can identify this as a link-builder rather than a data fetcher without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: to retrieve public ads use avito_search_ads, for account ads use avito_search_my_ads, implying this tool is for when you only need a shareable/openable link. Both alternatives and the selecting condition are named.

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

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

Annotations already declare the safety profile (readOnly=false, destructive=true, idempotent=true, openWorld=true), so the bar is lower. The description still adds real value beyond them: it states that the connected account is required (auth implication) and that the return is Avito's acknowledgement string, plus advising a follow-up favorites check to confirm state. It does not reconcile the counterintuitive destructiveHint=true for a 'save' action, which is the main remaining gap.

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 zero filler; the core action is front-loaded and the second sentence efficiently bundles the return value with the verification advice.

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 mutation with no output schema, the description covers action, identifier, authentication context, and the exact nature of the return value, so an agent has most of what it needs. It stops short of covering failure behavior or the meaning of the destructive/idempotent hints flagged by annotations.

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 explains listId thoroughly, including that it is distinct from adId. The description merely repeats 'via son listId' without adding format, source, or example detail, 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 names a specific verb and resource – it explicitly adds an ad ('annonce') to the connected account's favorites ('favoris') – and specifies the mechanism (via listId). It is clearly distinguishable in substance from siblings like avito_unsave_ad or avito_list_saved_ads, but it never names or contrasts with any of them, so it falls short of the 5 benchmark.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use / when-not-to-use statement and no alternative tool is named. The only guidance is procedural ('consulter les favoris pour vérifier leur état'), which implies a verification workflow but says nothing about when this tool is the right choice versus unsave or list operations. Usage is therefore only implied.

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 genuinely new behavior: it returns two streams (35 main + 3 premium) plus details and continuation cursors, and it discloses the constraint that filters/sort must remain unchanged during a continuation. That is meaningful context beyond the annotations, but it omits rate limits or failure 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 sentences, front-loaded with purpose then return shape then the continuation rule. No filler. It is dense but each sentence adds a distinct fact, so only minor trimming is possible.

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 23-parameter, heavily nested search tool with no output schema, the description explains what is returned (two streams, details, cursors) and the pagination contract, which is the most important omission. But the large low-coverage filter surface (category params, location IDs, boolean flags) is left largely unexplained in both description and schema, so completeness is only 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?

Schema description coverage is only 26% across 23 parameters, so the schema does not carry the full burden. The description names the parameter families (texte, catégorie, type, prix, filtres, tri, pagination par curseurs), giving useful mapping, but it does not explain the nested params/listMatch/rangeMatch/singleMatch structure or how cursor fields relate to responses. Partial compensation warrants a 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?

States a specific verb (Rechercher) and resource (annonces publiques Avito) with scope ('sans connexion'), which implicitly separates it from account-based siblings like avito_search_my_ads. It also enumerates the main input dimensions, so an agent can tell what it does. It stops short of explicitly naming the sibling it differs from, so not a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Sans connexion' implies it works without authentication, and the closing sentence gives a real usage rule (filters/sort must stay identical across continuations). However, there is no explicit when-to-use-vs-alternative guidance, e.g. pointing to avito_autocomplete_search for obtaining categoryId or to avito_search_my_ads for private listings. Usage is implied rather than 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 the read-only, idempotent, non-destructive profile, so the safety burden is lifted. The description adds one real behavioral note ('Conserve adId et listId distincts'), which warns about identity handling in results, but says nothing about pagination semantics or result size.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact sentences, filter scope front-loaded, with the facet dependency and the adId/listId caveat trailing appropriately. No padding.

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 11-parameter tool with 18% schema coverage and no output schema, the description covers the main filter axes and the facet sourcing but omits pagination controls, keyword, boosted, and the status enum. Adequate but with clear gaps.

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 only 18%, so the description must compensate. It names the filter families (statut, catégorie, ville, prix, paramètres, type) and explains that params/adTypes come from facets, but leaves keyword, boosted, page, and pageSize undocumented and does not enumerate the status 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?

States a specific verb (Rechercher) and resource (annonces du compte) plus the filter dimensions covered. The qualifier 'du compte' implicitly separates it from the public avito_search_ads, but 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?

Gives one actionable directive — consult facets for filter IDs, pointing at avito_get_my_ads_facets — but says nothing about when to prefer this over avito_search_ads, avito_count_ads, or avito_get_my_ad, and offers no 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 declare destructiveHint=true and idempotentHint=false, and the description reinforces the non-idempotent risk by warning to verify the conversation before retrying after an error or timeout. It also discloses side effects (conversation creation/reuse), a write constraint (no bulk, no attachments), and a safety precondition 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?

Three dense sentences, front-loaded with the action and target, followed by the gating condition and the failure-recovery rule. 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?

For a non-idempotent mutation with explicit annotations and fully documented parameters, the description covers purpose, gating, exclusions and retry safety. Minor gaps: no mention of authentication/session prerequisites (siblings include avito_login/session_status) and no hint of what a successful call returns, though there is no output schema to carry that.

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 both parameters already carry detailed descriptions, including the adId vs listId caveat. The description only restates that adId identifies the ad, adding no format or syntax detail beyond the schema, so 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 (envoie un premier message texte) and resource (au vendeur de l'annonce adId), plus the side effect of creating or reusing the conversation. This clearly distinguishes it from the sibling avito_send_message, which handles subsequent messages in an existing conversation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit precondition ('seulement si l'utilisateur a explicitement demandé cet envoi'), exclusions ('aucun envoi en masse ni pièce jointe'), and a retry protocol after error/timeout. It does not, however, name the alternative tool (avito_send_message) or state when to prefer it over this one.

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=false, destructiveHint=true, idempotentHint=false and openWorldHint=true, and the description reinforces this with concrete operational caveats beyond the annotations: no bulk sending, no attachments, and a duplicate-avoidance/retry policy that directly explains the non-idempotent risk. That is meaningful context layered on top of the structured hints.

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, each carrying a distinct load (action, precondition, exclusions, retry policy), with the primary action front-loaded and the alternative-routing placed mid-message. 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 two-parameter mutation with no output schema and annotations covering the safety profile, the description supplies the remaining operational context an agent needs: explicit-user-request precondition, bulk/attachment exclusions, sibling routing, and duplicate-avoidance on failure. Nothing material 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%, so both parameters (text, conversationId) are already fully documented in the schema, including the 10,000-char local limit and Avito's possibly lower limit. The description adds no further parameter syntax or format detail, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Envoie immédiatement le texte fourni dans une conversation Avito existante') and explicitly distinguishes itself from the sibling avito_send_first_message for the no-conversation case. An agent can identify the exact action without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states when to call ('seulement si l'utilisateur a explicitement demandé cet envoi'), when not to (no mass sending, no attachments), names the alternative (avito_send_first_message), and adds retry guidance (do not auto-retry after error/timeout; verify the conversation first). This is explicit when/when-not/alternative coverage.

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, yet the description adds real behavior beyond them: no network call, no secret exposed, and no token validation against Avito. That last point is valuable since it tells the agent the status may be stale relative to server state.

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 action and then the key constraint. No filler, every clause carries 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 no output schema and no parameters, the description covers the safety profile well but never hints at what the returned 'état local de connexion' actually contains (e.g. logged-in flag, account identity, expiry). An agent knows how to call it but not what to expect back.

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, which is the baseline-4 case per the rubric; there is nothing for the description to disambiguate.

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 (Lire) and resource (état local de connexion), and the 'sans appel réseau' qualifier sharply distinguishes it from the sibling network-facing tools like avito_login and avito_get_account. It does not name a sibling explicitly, but the local-vs-remote scope makes the distinction inferable.

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?

Implies the use case (checking local session state without a network round-trip) and adds a useful boundary ('ne valide pas le jeton auprès d'Avito'), but never states when to prefer this over avito_login/avito_logout or which conditions call for it.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true, and openWorldHint=true. The description adds some context by saying it modifies the blocking state and is not a simple read, which reinforces the non-read nature but does not elaborate on what exactly is destroyed, reversibility, or required permissions. With annotations carrying the safety profile, the added behavioral detail is modest.

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 consists of two short, front-loaded sentences with no wasted words. It immediately names the action and then adds the key clarifications without 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 one-parameter mutation tool with no output schema and rich annotations, the description is largely complete. It notes the connected account context and that the tool modifies state rather than reading, which are the key operational facts. It omits explicit mention of idempotency or destructive scope, but annotations cover those aspects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the single conversationId parameter is fully documented in the schema. The description adds no syntax or format details beyond what the schema already provides, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Débloque explicitement une conversation Avito' (explicitly unblocks an Avito conversation). It also clarifies that it changes the blocking state and is not a read, helping distinguish it from read-oriented siblings like avito_get_conversation or avito_list_conversations. However, it does not explicitly name the inverse sibling avito_block_conversation, so it stops short of full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'ne pas confondre avec une simple lecture' gives an implied usage boundary against read-only tools, but the description does not state when to use this tool versus alternatives such as avito_block_conversation, nor does it provide prerequisites or exclusions. Usage is implied rather than explicitly instructed.

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, so the safety profile is covered and the bar is lower. The description adds one useful behavioral fact: the value comes from Avito's own counter rather than a locally computed tally, which hints at possible staleness, but it says nothing about scope (whole account vs per-ad), rate limits, or refresh cadence.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with no filler, front-loading the verb and resource, then qualifying the data source. Nothing is redundant with the schema or annotations.

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 zero-argument read counter this is nearly complete; the main residual gap is that no output schema exists and the description never says what the count is returned as (a bare number, an object with conversation vs message breakdowns). The rest — scope, data source, safety profile — is adequately covered.

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 nothing for the description to clarify beyond the implicit scope of "du compte Avito connecté".

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 ("Compte") and resource ("conversations/messages non lus du compte Avito"), making it clearly a count rather than a listing tool. It is distinguishable from avito_list_conversations and avito_mark_read by the word "Compte", though it never names those siblings 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 only implied: an agent can infer this is the tool for checking an unread badge before deciding to list or mark conversations. There is no explicit when-to-use statement, no mention of alternatives like avito_list_conversations, and no preconditions (e.g., must be logged in).

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 destructive, idempotent, openWorld and non-readOnly. Beyond those, the description usefully discloses the return value (Avito's acknowledgement string) and recommends verifying state via the favorites list, which matters since there is no output schema. It does not, however, note whether re-unsaving an already-unsaved listing is a no-op, despite the idempotent hint.

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 action and scoped to the connected account, followed by the verification note. Every clause 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 single-parameter destructible tool with no output schema, the description covers the action, its effect on the connected account's favorites, the return value, and how to verify state. Annotations carry the safety profile, so only the idempotency nuance is left unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already documents listId as the Avito-returned identifier distinct from adId. The description merely repeats 'via son listId' without adding format or constraint detail, so the schema does the heavy lifting and a 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 (Retire/removes) plus resource and scope: 'une annonce des favoris du compte connecté', which clearly separates it from siblings like deactivate_ad or get_ad_for_edit. It stops short of naming the counterpart (avito_save_ad) or the alternative list_saved_ads, so it doesn't guide via explicit sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Retire explicitement' and the advice to 'consulter les favoris pour vérifier leur état' imply the workflow and how to confirm the result, but there is no explicit statement of when to use this versus save_ad or when not to use it. Usage is inferable rather than stated.

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