Skip to main content
Glama

avito_execute_boost

Destructive

Purchase and activate an Avito.ma boost for a specific quote using WALLET credits. Call only after explicit user approval, as one attempt consumes the quote and may debit credits immediately.

Instructions

Acheter et activer le boost du devis via le portefeuille WALLET. Peut débiter immédiatement des crédits Avito. Appeler uniquement après accord explicite de l'utilisateur sur ce devis. Une tentative consomme le devis; ne pas réessayer automatiquement.

Input Schema

NameRequiredDescriptionDefault
confirmYes
quoteIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.1/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.