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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds the useful qualifier that the profile belongs to the account that authorized the application (the authenticated identity), but says nothing about auth failures, scopes, or token prerequisites.

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 well-formed sentence with the key concept front-loaded. Nothing is wasted and nothing essential is buried.

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-parameter read of the authenticated account with no output schema, the description conveys what comes back (profile and identifier) and whose account it is. Only the exact return shape remains unspecified, which is minor for such a simple 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?

The tool takes zero parameters, which is the baseline-4 case. The description correctly implies no input is needed because the account is derived from the authorization context.

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 ('Obtiene') and resource ('perfil e identificador de la cuenta que autorizó la aplicación'), so an agent knows exactly what it returns. It does not explicitly distinguish itself from siblings such as meli_api_request or meli_user_product, which is why it stops short of a 5.

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

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

There is no statement of when to call this versus an alternative, no prerequisites, and no exclusions. The only implicit guidance is that it concerns the authorizing account, which the agent must infer.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description still adds real context beyond them: the operation is paginated (one page at a time) and the scan mode is the path for result sets above 1000. It says nothing about what the returned marking looks like or how the scroll_id lifecycle works.

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 clause states the action and the marking behavior, followed by the scan caveat — no filler. It is arguably under-specified rather than bloated, but as a structural matter every sentence 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, no parameter descriptions and no title, the description should explain the return shape (what field marks an item as having a price rule) and the scroll_id continuation contract. Neither is present, so an agent cannot confidently chain pages or parse results from this definition alone.

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% across all four parameters, so the description carries the full burden. It explains scan (>1000 items) and implies paging via limit/offset, but scroll_id — the least self-explanatory parameter — is never mentioned, and no defaults or units are given.

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+resource: it fetches a page of active listings and marks which of them have a local price rule, which is a distinctive capability an agent can recognize. It does not name or contrast with any sibling (meli_list_items, meli_get_items), so an agent must infer the difference from the phrasing alone.

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

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

"usa scan para más de 1000" gives one conditional usage hint, but only for a parameter, not for the tool as a whole. There is no statement of when to pick this over meli_list_items or meli_get_items, and no prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so 'sin escribir' reinforces rather than adds. The useful added context is the explicit scope boundary (no earnings or co-financed discount computation), which tells the agent not to expect financial results. Still, nothing is said about what the evaluation actually returns or what conditions cause ineligibility.

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 compact sentence with the core purpose front-loaded and the negative scope trailing. It earns its words, though the semicolon construction packs two distinct ideas in a way that would read better as two short clauses.

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?

A two-required-parameter tool with zero schema documentation, no output schema, and no parameter explanation in the description leaves the agent guessing at input formats and return shape. For a pre-flight validation tool whose whole value is the verdict it returns, that is a significant gap.

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

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

Schema description coverage is 0%, so both item_id and deal_price are undocumented in the schema, and the description does not mention either one. The agent gets no guidance on deal_price format (string — currency? decimal? locale?), which is a real ambiguity for a price parameter.

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

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

States a specific verb+resource: 'Evalúa elegibilidad DOD' (evaluates Deal-of-Day eligibility) plus local rules. This distinguishes it from the sibling meli_apply_deal_of_day, which presumably acts on eligibility. The title being null means the description alone carries the naming burden, and it does so adequately, though 'DOD' and 'reglas locales' remain somewhat opaque.

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 'sin escribir' (read-only) framing and the exclusion 'no calcula ganancias ni descuentos cofinanciados' imply this is a pre-check step before applying. However, the sibling meli_apply_deal_of_day is never named as the alternative, and there is no explicit 'use this when...' statement, leaving the agent to infer the sequence.

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 and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-annotated behavior: it only publishes if the question is still unanswered, and it serializes agents sharing the same state folder (a concurrency guarantee). It still omits what happens when the question is already answered, whether the call errors or no-ops, and what the state folder mechanism entails.

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 compact sentence that front-loads the action and the guard condition, with no filler. It is efficient; the problem is under-specification rather than verbosity.

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, open-world mutation with three required parameters, zero schema descriptions and no output schema, the description does far too little: it never explains 'explicitly_requested', does not say what is returned or what happens on an already-answered question, and gives no indication of required permissions. The Spanish-only text in an otherwise English tool surface also adds friction.

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% across all three required parameters, and the description says nothing about any of them. In particular 'explicitly_requested' is an opaque boolean that is documented nowhere — neither schema nor description — leaving the agent to guess its meaning and correct 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 names an action ('Publica una respuesta') and a condition ('si sigue sin responder'), so the agent can infer it posts an answer to a pending question. However, it never states the resource explicitly (a MercadoLibre buyer question) and 'respuesta real' is vague — it does not distinguish this from siblings such as meli_question_attempt or meli_unanswered_questions.

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

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

'Si sigue sin responder' implies a precondition for use, but there is no explicit when-not guidance and no named alternative. The agent must guess how this relates to meli_question_attempt / meli_clear_question_attempt, which appear to be the attempt-tracking siblings referenced obliquely by the state-folder clause.

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 openWorldHint=true, destructiveHint=true, and readOnlyHint=false, so the main safety profile is supplied. The description adds useful context that writes produce real changes and that only specific documented headers are accepted, but it does not cover authentication, rate limits, or side-effect details beyond that.

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

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

The description is short and front-loaded, stating the core action before adding path and header constraints. It is efficient, though the phrase about consulting documentation is somewhat vague rather than directive.

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?

This is a high-complexity generic API caller with 7 parameters, no schema descriptions, no output schema, and destructive write capability. The description gives only a few safety and path hints, leaving the agent without enough information about how to construct most requests correctly.

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

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

Schema description coverage is 0% across 7 parameters, so the description must compensate. It explains that path is an absolute route and that headers are restricted, but it leaves method enum semantics, body, query, catalog_confirmed, and explicitly_requested unexplained.

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 that it calls an additional resource of the official API, which gives a specific verb and resource type, and clarifies that path is an absolute route rather than a URL. However, it does not clearly differentiate this generic escape-hatch tool from the many specific sibling tools beyond the vague word 'adicional'.

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 says to consult documentation to broaden coverage, but gives no explicit guidance on when to use this tool instead of the many specific MELI sibling tools. It also does not state when not to use it or what prerequisites are required for writes.

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 and openWorldHint=true, so the safety profile is known. The description adds real context beyond that: the mutation specifically rewrites the item's effective price and demands an explicit-instruction gate plus eligibility check. It stops short of stating reversibility or what happens to existing DOD participation.

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 the action front-loaded and the precondition second. Every clause earns its place; nothing is padded.

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 mutation with no output schema and 0% param coverage, the description covers purpose, precondition, and rough param intent. It leaves concrete restrictions/eligibility criteria and the effect on existing price/deal state unspecified, which an agent would want before firing a destructive call.

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

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

Schema coverage is 0%, so the description must carry parameter meaning. It names the item and price and frames the explicit-instruction requirement (mapping to explicitly_requested), which partially compensates, but gives no format/units for deal_price nor clarifies that explicitly_requested is a boolean gate that must be true.

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+effect: it enrolls a candidate in a Deal of the Day (DOD) and changes the effective price. An agent can tell this is a write operation on a specific promotion type. It does not name meli_analyze_deal_of_day as the eligibility counterpart, so sibling differentiation is only implied.

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?

'Requiere instrucción explícita para ítem y precio; verificar elegibilidad y restricciones primero' gives a clear precondition: only act on explicit item+price instructions and check eligibility first. This effectively routes the agent to an analysis step before applying, though it does not name the alternative tool explicitly.

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, openWorldHint=true and destructiveHint=false. The description adds a meaningful behavioral directive beyond them – the returned content is private and must not be exposed – but says nothing about auth requirements, rate limits, or whether rules can be absent.

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 resource stated first and the privacy constraint second. The referent of "Su contenido" is slightly ambiguous but the total length is justified.

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 carries the burden of explaining what a "local rule/policy" record contains and what an empty result means. It covers the privacy obligation but leaves the shape of the returned data 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?

The tool takes zero parameters and schema coverage is 100%, so there is nothing for the description to clarify. Baseline for a no-parameter tool 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 ("Lista") and resource ("reglas y políticas locales de la cuenta autorizada"), so an agent knows this is a read of account-level rules. It does not reference the related siblings meli_save_business_policy or meli_active_rules_status, so it misses a 5.

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

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

There is no statement of when to call this versus meli_active_rules_status or meli_save_business_policy. Usage is only implied by the verb "Lista"; nothing tells the agent when this tool is the right choice.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered by structured data. The description adds nothing behavioral beyond the purpose sentence: it does not say what eligibility criteria are evaluated, whether the check is per-marketplace/site, or what the answer looks like. With annotations carrying the safety burden a 3 would be reachable, but no extra context is actually supplied.

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

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

One short sentence with the purpose front-loaded and zero filler. It is efficient, though the brevity borders on under-specification rather than being maximally informative.

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

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

The tool has no output schema, so the description is the only place a caller could learn that the result is presumably a yes/no eligibility verdict (and whether reasons are included). That is never stated, nor are any prerequisites or seller/site scoping, leaving a read-only eligibility check that an agent can call but not fully anticipate the response of.

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% for the single required parameter, so the description must compensate. It does partially, implying via 'una publicación' that item_id is a listing identifier, but it never states the expected format (e.g. an MLA-style item id) or whether the id must belong to the caller's own listings.

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 ('Comprueba') and a specific subject ('si una publicación puede participar en catálogo'), so the agent knows this is an eligibility check rather than a search or a catalog listing read. It does not explicitly distinguish itself from nearby siblings like meli_search_catalog, meli_catalog_product, or meli_compare_catalog, which prevents a 5.

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

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

There is no when-to-use guidance, no when-not-to-use, and no named alternative. Given the cluster of catalog-related siblings (meli_search_catalog, meli_catalog_product, meli_compare_catalog), an agent must infer on its own when an eligibility check is the right call versus those tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that — no mention of rate limits, auth needs, or what a catalog product record contains.

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

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

A single efficient sentence with no waste, front-loading the verb and resource. It is concise but borders on under-specification rather than being tight.

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 catalog lookup with undocumented parameters, no output schema, and several ambiguous siblings, the definition leaves too much to inference. It lacks the product_id format and the distinction from search/get tools, which an agent needs to call it correctly.

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

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

Schema description coverage is 0% for the single required product_id, and the description does not explain its expected format (e.g., a catalog product ID like MLB…), where to obtain it, or whether it differs from an item ID. The description fails to 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 ('Consulta') and resource ('un producto del catálogo de Mercado Libre'), making the intent clear. However, it gives no differentiation from nearby siblings such as meli_search_catalog, meli_get_item or meli_compare_catalog, which an agent must disambiguate on its own.

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

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

There is no guidance on when to use this tool versus alternatives (search_catalog, get_item, catalog_eligibility, compare_catalog), nor on prerequisites. The agent must infer selection purely from the tool name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered elsewhere. The description adds almost nothing beyond that: it implies two response modes (category data vs. attributes/requirements) without clarifying behavior, error cases, or that results are public catalog data.

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

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

A single short sentence with no waste, but it is under-specified rather than concise. The most decision-relevant fact, the attributes toggle, is absent rather than front-loaded.

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

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

With no output schema and zero parameter documentation, the description is the only place the two-mode behavior and ID format could be explained, and it isn't. For a lookup tool that is otherwise simple, annotations cover safety but the description leaves the calling contract underspecified.

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 the parameter burden, and it largely does not. It alludes to an "attributes" mode but never explains that the `attributes` boolean toggles it, nor what format `category_id` takes (e.g. MLB1234) or that it is required.

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

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

The description uses a specific verb ("Consulta") plus the resource ("una categoría") and names the secondary payloads (attributes and requirements). However, it never says how this differs from nearby catalog tools such as meli_catalog_product or meli_catalog_eligibility, and "requisitos" stays undefined.

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 rather than meli_search_catalog, meli_catalog_product or meli_catalog_eligibility. The description also fails to say that the mode changes with the `attributes` flag, so the agent gets no routing signal at all.

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 and openWorldHint=true, so the safety profile is covered. The description adds genuinely new context: the removal is scoped to a LOCAL lock and produces no outbound message to the buyer, which is exactly the side-effect boundary an agent needs before invoking a destructive tool. It still doesn't say what state is lost or whether the operation is reversible.

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

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

One compact sentence with two clauses, the destructive action front-loaded and the side-effect disclaimer trailing it. No filler, nothing repeated from 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?

This is a destructive mutation with no output schema, two undocumented required parameters, and no explanation of what the lock is, what verifies the "uncertain result", or what the boolean guard does. For a destructive cleanup tool the description leaves too much of the call contract unstated.

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

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

Schema description coverage is 0% and the description never mentions either parameter. The required boolean "explicitly_requested" is entirely opaque — presumably a confirmation gate for a destructive operation, but nothing here says so, and "question_id" linkage to a prior meli_question_attempt call is only guessable from the tool name.

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 object ("Elimina un bloqueo local") plus the trigger condition ("tras verificar un resultado incierto"), which is enough to tell it apart from meli_question_attempt or meli_answer_question. It stops short of naming the sibling it supersedes, and "bloqueo local" remains domain jargon an 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?

The phrase "tras verificar un resultado incierto" implies the precondition for calling it, and "no envía respuesta al comprador" rules out one expectation. But there is no explicit when-not, no statement of what to do first (e.g. run meli_question_attempt), and no mention of what happens if the result turns out to be certain.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The phrase 'no asocia ni inventa atributos' adds real behavioral context: the tool returns raw data without fabricating or linking attributes, which matters for an agent reasoning about result trustworthiness. It stops short of describing scope or result shape, so a 3 fits.

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

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

A single sentence that front-loads the resource list and appends the behavioral caveat, with no filler. Efficient, though its terseness trades off some clarity.

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

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

For a two-param, no-output-schema read tool the description is thin: it never explains what the two inputs identify or what 'comparison' entails. Annotations cover safety, but parameter meaning and expected result nature remain 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 description coverage is 0% for two required parameters, so the description must carry the burden. It only implicitly maps 'ítem' and 'producto de catálogo' to item_id and product_id without explaining format, source, or constraints, leaving the parameters effectively undocumented.

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 verb ('Consulta') and three resources (ítem, elegibilidad, producto de catálogo) and frames the goal as human comparison. However, it doesn't clearly distinguish this combined lookup from siblings like meli_catalog_product or meli_catalog_eligibility, which appear to do overlapping sub-parts. Purpose is discernible but muddled by the sibling overlap.

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?

'para comparación humana' implies a usage context, but there is no explicit when-to-use vs meli_catalog_product / meli_catalog_eligibility, no exclusions, and no prerequisites stated. The agent is left to infer the routing decision.

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 and openWorldHint=true, so the description owes context about consequences — which it omits entirely (no notion of irreversibility, no auth/permission notes, no failure modes). It adds one useful behavioral fact: the payload shape is dictated dynamically by the category, but says nothing about the catalog_confirmed flag, which materially changes what the call does.

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 action; nothing is wasted. However, the brevity here comes at the cost of omitting essential detail rather than from disciplined editing.

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 high-risk write tool with a free-form nested object, no output schema and 0% parameter documentation, the description is thinner than the complexity demands. It does communicate the one non-obvious concept (category-driven required fields), but omits the catalog_confirmed semantics and the typical preceding lookup step.

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 'data' is a free-form nested object with additionalProperties:true, so the description is the only source of shape information. It correctly signals that required fields come from the category rather than from the schema, but leaves catalog_confirmed completely undefined and gives no example of the payload.

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: 'Crea una publicación' (creates a listing). An agent can tell this is the creation counterpart to meli_update_item / meli_get_item. It stops short of naming any sibling or clarifying scope (e.g. catalog vs. traditional listing) 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?

No explicit when-to-use / when-not-to-use guidance and no named alternatives among the many siblings (meli_update_item, meli_search_catalog, meli_catalog_eligibility). The phrase 'campos exigidos por la categoría' only implies that a category lookup (meli_category) should precede the call, without saying 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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that — no mention of behavior when the listing has no description, no language/localization notes despite the Spanish text, no rate-limit or auth context.

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

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

A single short sentence with the verb front-loaded and no wasted words. It is efficient, though its brevity borders on under-specification rather than crispness.

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?

This is a simple single-parameter read tool with annotations covering safety and no output schema, so the bar is modest. Still, the description leaves item_id format and the fact that the return is a description text unresolved, which is the minimum an agent needs.

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% for the single required parameter item_id — the schema gives only a type with no explanation. The description does not explain what an item_id is or in what format it is expected (e.g., an MLA-style ID), so it fails to 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?

The description states a specific verb and resource ("Obtiene la descripción de una publicación"), so the core action is clear. However, "publicación" is not defined as a MercadoLibre item listing, and it does not distinguish this read from the sibling meli_update_description or from meli_get_item, which likely also surfaces description data.

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 meli_get_item (which typically returns item data including descriptions) or meli_update_description. No prerequisites, no context about when a separate description fetch is warranted.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description contributes by naming the payload (attributes and status), but says nothing about error behavior for invalid/missing item IDs or about freshness/latency of an open-world lookup.

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 no filler; the returned data is stated immediately after the action. It is efficient, though there was clearly room to add one more clause about the identifier without bloating it.

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 tool with annotations and no output schema, the description covers the action and the shape of the result. It leaves gaps on the item_id format and on failure modes, which matter for an open-world single-resource lookup.

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

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

Schema description coverage is 0%, so the description carries the burden for item_id, yet it never mentions the parameter, its expected format (e.g. site-prefixed IDs), or what an invalid value does. The link between 'publicación' and item_id is inferable but not made explicit.

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 ('Consulta') and resource ('el detalle de una publicación') and enumerates what is returned (atributos y estado). It does not distinguish itself from close siblings such as meli_get_items, meli_get_description or meli_list_items, so an agent must infer the singular-vs-batch distinction from the name alone.

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

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

There is no guidance on when to use this versus meli_get_items, meli_list_items, or meli_get_description, and no stated prerequisites or exclusions. The agent is left to infer usage from the tool name and the surrounding sibling set.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that the call goes through the bulk resource, which implies batching semantics, but it omits the max number of IDs per call, how invalid IDs are handled, and whether partial results are returned.

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

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

A single front-loaded sentence with no filler, naming the verb, scope and mechanism immediately. It is efficient but borders on under-specified rather than trimmed.

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 batch read with annotations covering safety and no output schema, the description is minimally adequate but leaves the key operational facts (ID format, batch ceiling) unstated. An agent could pick the tool but might call it with an oversized or malformed ID list.

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

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

There is one parameter with 0% schema description coverage, so the description carries the full burden and does not meet it. It never states that item_ids are Mercado Libre item identifiers (e.g. MLA...) or gives any count limit or format 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 verb (consulta) and resource (varias publicaciones) plus the mechanism (recurso bulk), so an agent knows this is a batch read of multiple listings. The plural 'varias' implicitly distinguishes it from meli_get_item, though no sibling is named explicitly.

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

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

Usage is only implied: 'varias' plus 'bulk' suggests batching multiple IDs, but the description never says when to prefer this over meli_get_item or meli_list_items, nor any batch-size limit or precondition. No explicit exclusions or alternatives are given.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered elsewhere. The description adds nothing beyond that: no mention of auth requirements, rate limits, error behavior for invalid IDs, or what an 'order' includes.

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 single short sentence contains no waste and is trivially front-loaded, but its brevity is under-specification rather than efficiency — there is nothing to structure because nothing is said.

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 tool the annotations cover safety, and the absence of an output schema means return values need not be explained. However, the order_id format and the distinction from meli_search_orders are missing, which are the two things an agent actually needs to call this correctly.

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

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

Schema description coverage is 0%, so the single order_id parameter is undocumented everywhere. The description does not state the expected ID format, whether it is a Meli order ID or an external reference, or any constraint, leaving the agent to guess.

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 "Obtiene una orden de venta" restates the tool name meli_get_order almost verbatim, adding only that the order is a sales order. It gives no differentiation from the sibling meli_search_orders, which an agent could easily confuse with this one.

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

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

There is no guidance on when to use this tool versus alternatives. With meli_search_orders and meli_get_shipment in the sibling set, the agent is left to infer that this fetches a single order by ID rather than searching.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds nothing beyond that: no mention of auth/scope requirements, response shape, error behavior for unknown IDs, or that the lookup is a live external API call (openWorld).

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

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

It is a single short sentence with no filler and the key concept is front-loaded, but the extreme brevity comes at the cost of substance rather than from disciplined editing.

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

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

The tool is simple (one required string param, read-only annotations, no output schema), so it does not need much, but with zero schema descriptions and no output schema the description should at least characterize the identifier or the returned shipment shape. As written, an agent knows only the bare minimum.

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 schema description coverage at 0%, the description carries the burden and does little: it says lookup is "por identificador" but never explains the expected format of shipment_id, where a shipment ID comes from, or whether it is the same ID returned by meli_search_orders.

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 ("Obtiene un envío" – get a shipment) plus a lookup key (identifier), so the operation is identifiable. However, it does nothing to distinguish it from siblings that also read order/shipment-like resources (meli_get_order, meli_search_orders), leaving the agent to infer scope from the name alone.

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

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

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites or required identifiers, and no exclusions. The only implicit cue is "por identificador," which merely restates the single required parameter.

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 non-destructive behavior, so the safety profile is covered. The description adds that the result is an image or formula, which is useful, but says nothing about return format, size, or error behavior. Given the annotation coverage, 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 compact sentence with no wasted words; the retrieval action and number dependency are 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 lookup with no output schema, the description supplies the missing parameter meaning and the source for the número. It does not describe output details, but those are not strictly necessary here.

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

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

Schema coverage is 0%, so the description must carry the burden. It explains that 'numero' is the guide number and points to meli_guia_seccion for how to find it, which is meaningful semantics beyond the bare integer 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 ('Muestra') and resource ('una imagen o fórmula de la guía') retrieved by número. It also implicitly distinguishes itself from the section-lookup sibling by pointing to it. Lacks a title, but the description itself is clear.

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

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

Explicitly tells the agent where to obtain the required número ('consúltalo en meli_guia_seccion'), which is a useful routing instruction. It does not explain when to use this instead of meli_guia_indice or meli_guia_seccion, but the dependency is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so safety is fully covered structurally. The description adds only the detail that the content is user-supplied ('aportada por el usuario'), which hints at per-user scoping but is not elaborated. No further behavioral context is offered.

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 the verb front-loaded and no filler. The enumeration of six topics is somewhat long but each item carries information about what the index contains.

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

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

With an output schema present, zero parameters, and complete annotations, the description needs only to state what the tool returns and for whom, which it does. The one gap is the missing pointer to meli_guia_seccion for retrieving an actual section's content.

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. The description correctly signals a no-argument call by describing only what is returned.

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 ('Lista') and resource (the guide index) and enumerates the sections it covers: optimización, ventas, objetivos, consultas, reputación, publicidad. It does not explicitly contrast with the sibling 'meli_guia_seccion' or 'meli_guia_imagen', so the index-vs-section relationship is only implied by the word 'índice'.

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 guidance, no prerequisites, and no mention of the obvious alternatives (meli_guia_seccion to drill into a topic, meli_guia_imagen for visuals). An agent must infer the entry-point role 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, non-destructive and closed-world, so the safety profile is covered. The description adds that the returned section includes references to images and formulas, which is useful content context, but says nothing about size, pagination or how images are referenced (by id vs URL).

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 padding, with the core action front-loaded and the selection hint second. Every sentence carries information.

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

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

With annotations, an output schema and a single enum parameter, the burden is light, and the description covers what the tool returns and how to pick a section. A brief note on what the numbered sections or 'fuentes' contain 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 coverage is 0% and the single parameter is an enum of "1"-"7" plus "fuentes", whose meanings are opaque without the index tool. The description compensates only by pointing to the index for selection; it does not explain what the numeric sections or "fuentes" contain, which matters since 'fuentes' is not obviously a section.

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: reads a section of the operational guide, including its image and formula references. It also implicitly distinguishes itself from meli_guia_indice by telling the agent to consult the index to choose a section. It stops short of an explicit 'not for listing sections' statement, so it is clear but not maximally 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?

'Consulta el índice para elegirla' gives an explicit discovery path via the sibling meli_guia_indice, which is exactly the routing an agent needs for a tool whose only parameter is a section enum. No when-not-to-use guidance is given, but for a read-only guide reader there is little else to exclude.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no further behavioral context: no indication of what 'quality' metrics or 'recommendations' are returned, what happens if the domain does not support performance, or whether the call errors or returns empty.

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

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

It is a single short sentence with no padding, which is good, but it is front-loaded with an ambiguous conditional clause rather than the concrete object of the call. Brevity here comes at the cost of clarity, not from efficiency.

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 parameter documentation, the description carries the full burden and leaves key questions unanswered: which identifier is expected, what the response contains, and how 'domain supports performance' is determined. It is not sufficient for correct invocation.

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

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

Schema description coverage is 0% and there is one required parameter (item_id), yet the description never mentions item_id or its format. With zero schema documentation the description needed to compensate and does not.

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?

It names an action (consult quality and recommendations) but ties it to an opaque condition ('cuando el dominio admite performance') and never mentions the item resource that the sole parameter implies. An agent can guess it relates to item performance quality, but the purpose is only vaguely conveyed and not distinguished from siblings like meli_get_item or meli_item_promotions.

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 only guidance is a conditional ('when the domain supports performance') with no explanation of how the agent determines that, no when-not-to-use, and no named alternative among the many sibling tools. Nothing tells the caller when to prefer this over meli_get_item.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description does add value by saying the result includes both candidate and existing promotions with prices and status, which tells the agent what kind of data to expect, but it says nothing about permission requirements or result volume.

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 compact sentence with no redundant restatement of the tool name, and the key scope qualifier (candidatas y existentes) appears early. Nothing to trim, though nothing is front-loaded beyond the verb either.

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 lookup with no output schema, the description is close to sufficient: it names the resource, the scope of promotions returned, and the payload contents (precios y estado). Only ambiguity about how to disambiguate it from sibling promotion tools remains.

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 would ideally explain item_id, and it does not. However, item_id is a single, self-evident MELI identifier and the description at least scopes it ('del ítem'), so this is a moderate gap rather than a serious one.

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 (consulta), a specific resource (promociones del ítem) and scope (candidatas y existentes, con precios y estado). It is clear enough to distinguish from list-level siblings, though it never names meli_promotion_items or meli_seller_promotions to disambiguate seller-level vs item-level promotion tools.

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

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

There is no when-to-use / when-not-to-use guidance and no mention of the obvious alternatives (meli_promotion_items, meli_seller_promotions). The agent must infer the usage context purely from the name and the phrase 'del ítem'.

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

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

Annotations already establish read-only, non-destructive, open-world behavior. The description adds useful behavioral context by explaining that scan and scroll_id enable traversal beyond 1000 results, which is not captured in the annotations or schema.

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

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

The description is a single compact sentence with the core purpose and pagination caveat front-loaded. There is no redundant or filler text.

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

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

It adequately identifies the return as a list of IDs and explains deep pagination, which are key aspects of the tool. However, with no output schema and 0% schema description coverage, the description should do more to clarify the non-pagination 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 description coverage is 0%, so the description must carry parameter meaning. It explains scan and scroll_id for deep pagination but leaves seller_id, limit, offset, and status undocumented, which is a significant gap for a six-parameter tool.

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: it lists seller publication IDs, which distinguishes it from sibling tools that fetch item details. It does not explicitly name alternatives, but the purpose is clear enough for an agent to identify the operation.

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 for paginated listing when more than 1000 items are needed via scan and scroll_id. However, it does not state when to use this tool instead of meli_get_items or meli_search_catalog, nor does it provide 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 readOnlyHint, openWorldHint and destructiveHint, so the safety profile is covered. The description itself only restates the tool name's meaning and adds nothing about what the error payload contains, whether errors persist after re-upload, or any rate/availability 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?

A single front-loaded sentence with no padding. It is appropriately terse, though brevity here comes at the cost of substance rather than from efficient packing of 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, no parameter documentation, and no behavioral detail, an agent lacks what it needs to know how to obtain a valid picture_id and what the error response looks like. The description is too thin for a diagnostic 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 description coverage is 0% and the single required parameter picture_id is undocumented in both schema and description — no format, source (e.g., from meli_set_item_pictures response), or validity constraints are given.

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 ("Consulta errores de procesamiento de una imagen"), making clear this retrieves processing-error information for a picture. It is distinct from the picture-centric siblings like meli_set_item_pictures, though it doesn't explicitly name that distinction.

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 versus meli_set_item_pictures or the image-related guide tools, and no mention of prerequisites such as needing a previously uploaded picture. The agent must infer the usage context entirely.

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 usefully adds that no admissibility validation occurs and that both current and proposed values are shown, but it says nothing about result shape, partial failures, or what happens with invalid change keys.

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 no filler; the non-writing, non-validating scope is stated immediately and every clause carries information.

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

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

With a free-form nested 'changes' object at 0% schema coverage and no output schema, the description should explain the shape of the change payload and what the preview returns. Neither is addressed, so an agent cannot reliably construct a correct call from the definition alone.

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 'changes' parameter is a free-form nested object with additionalProperties=true, meaning the agent has no documentation of its expected structure anywhere. The description implies 'changes' holds the proposed values but adds no field-level syntax or format guidance, leaving a serious 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?

The description states a clear verb and resource: it reads the listing and presents current versus proposed values. This distinguishes it from meli_update_item, which actually writes changes. It does not explicitly name that sibling, which keeps it from a 5.

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

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

Usage is implied rather than stated: 'without writing nor validating admissibility' signals this is a pre-write inspection step. It does not explicitly say 'call before meli_update_item' or name any alternative, so the agent must infer when to prefer it.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact — that results are cursor-paginated and the returned search_after value must be echoed back — but says nothing about page size behavior, result shape, or what happens when the cursor is exhausted.

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

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

It is a single compact sentence with no padding, which is good, but the brevity is achieved by omission rather than by efficiency — for a 5-parameter tool with 0% schema coverage, one clause about the cursor is too little to front-load.

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, no title, 5 undocumented parameters and a one-sentence description, an agent cannot determine what a page of "candidatos" contains or how to filter it. The pagination hint is helpful but far from sufficient for this tool's complexity.

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

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

Schema description coverage is 0% across 5 parameters, so the description carries the full burden and covers only search_after. It never explains promotion_id, promotion_type, status filtering, or limit, leaving the two required parameters and the filter entirely undocumented.

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 verb ("Consulta") and a pagination behavior, but the resource is stated only as "candidatos", which never identifies what is being listed — promotion items — and is meaningless without reading the tool name. It also does not distinguish this from siblings like meli_item_promotions or meli_seller_promotions.

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

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

There is no statement of when to use this tool versus the promotion-related siblings, nor any prerequisite context (e.g. that a promotion_id/promotion_type must be known first). The only guidance is a mechanical pagination instruction, which is usage of a parameter rather than tool selection guidance.

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

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

The annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context by disclosing the privacy behavior "sin exponer datos de contacto" and that it reads remote status plus the last local attempt, but it does not cover auth needs, error behavior, or other operational traits.

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 repetition or filler. Every phrase contributes either to the query scope or the privacy constraint.

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 low-complexity, one-parameter read-only tool with annotations covering safety, the description is partially complete: it explains the query scope and privacy behavior. But with no output schema and no parameter description, it leaves gaps around question_id semantics and the shape of the returned remote/local attempt data.

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

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

The schema has 0% description coverage, and the single required parameter question_id is never mentioned in the description. The agent gets no added semantics about what question identifier is expected or how it relates to the remote/local attempt lookup, though the single-parameter schema limits ambiguity.

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, "Consulta," and specific resources, "estado remoto y el último intento local," so the read/check purpose is clear. However, it does not distinguish this tool from related siblings such as meli_clear_question_attempt, meli_question_context, or meli_question_detail.

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 no explicit guidance on when to use this tool versus alternatives. It does not mention when to use meli_clear_question_attempt for clearing attempts or meli_question_detail/context for deeper question information; "sin exponer datos de contacto" is an output constraint, not usage guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real value by disclosing the scope of the read (question + live item data + local policies) and confirming it has no write side effects on the answer side, but says nothing about auth scopes, latency, or failure modes for the open-world lookup.

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 two tight clauses; the positive scope comes first and the negative boundary second. Zero 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 read-only tool with no output schema, the description is nearly sufficient: it names the three data sources the bundle contains. It stops short of describing the result structure (e.g., what form the item data and local policies take), which matters more 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?

Schema coverage is 0%, so the description must carry the load. It reveals non-obvious semantics — that a single question_id implicitly drives retrieval of the associated item data and policies — but gives no format, ID source, or validity constraints for the integer question_id.

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 aggregation action ("Reúne pregunta, datos actuales del ítem y políticas locales") rather than restating the name, so an agent understands it builds a context bundle. It partially differentiates from meli_answer_question via the negative clause, but never distinguishes itself from the very similar meli_question_detail sibling.

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

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

The exclusion "no redacta ni envía respuestas" implicitly routes answering to meli_answer_question, which is useful. However, there is no positive "use this when..." trigger and no guidance on when to prefer this over meli_question_detail or when a context bundle is warranted versus a plain question lookup.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral fact beyond the annotations: buyer contact data is excluded from the response, which tells the agent not to expect or promise that information. It stops short of describing behavior on a missing/invalid id or whether answers are included.

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 no filler; the scope caveat is appended where it belongs. It is arguably too short for the tool's complexity, but nothing in it 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 simple one-parameter read-only lookup this is close to adequate, but with no output schema the description could have said what "estado" values exist or whether the response includes the seller's answer. The privacy note partially compensates, leaving it minimally viable rather than complete.

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

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

Schema coverage is 0% and the single parameter question_id has no description in the schema, so the description should compensate; it does not mention the parameter at all. The name is self-explanatory and the tool takes only one required argument, which limits the practical cost of the 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?

Uses a specific verb ("Consulta") plus the resource ("pregunta") and names the returned fields (estado, texto), so the agent knows this is a single-question lookup. It does not explicitly distinguish itself from siblings like meli_unanswered_questions or meli_question_context, but the singular "detail" framing is fairly legible.

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 when-to-use or when-not-to-use guidance, and no sibling is named. The agent must infer that this fetches one question by id rather than listing, answering, or classifying questions.

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

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

The description adds real context beyond annotations: it explicitly says the policy is NOT sent to Mercado Libre, resolving the ambiguity of openWorldHint=true. However, with destructiveHint=true, it never warns that saving may overwrite an existing policy, nor does it describe persistence/confirmation behavior. Useful but incomplete for a destructive write.

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 no waste. Efficient, though brevity comes at the cost of the missing details noted elsewhere.

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 write tool with no output schema and 0% param documentation, the definition should explain valid topic values, overwrite behavior, and what users should expect. It covers only the surface purpose, leaving an agent without enough to call it safely and correctly.

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

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

Schema coverage is 0%, so the description must carry parameter meaning. The examples (facturación, envíos, garantías) hint at valid topic values, but the rule_text parameter (the actual policy content) is entirely unexplained, leaving half the required inputs undocumented.

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 ("Guarda una política") and clarifies scope with examples (facturación, envíos, garantías). The clause "sin enviarla a Mercado Libre" sharpens what kind of save it is. It does not clearly differentiate from the sibling meli_save_product_rule or meli_business_memory, which is the main gap.

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: store an owner-provided policy locally rather than sending it. The "sin enviarla a Mercado Libre" clause sets a boundary on when this applies, but no explicit when-to-use-vs-alternatives guidance is given (e.g., versus meli_save_product_rule).

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 and openWorldHint=true. The description adds the genuinely useful fact that the write is local-only and has no remote effect on Mercado Libre, which is context not present in the annotations. However, it says nothing about whether an existing rule is overwritten (relevant given destructiveHint=true) or what permissions/state are needed, so it clears the lowered bar without being rich.

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

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

A single compact sentence that front-loads the action and the main payload fields, with the negative scope appended. No filler; the only shortfall is that brevity here is partly achieved by omitting needed 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 mutation tool with 0% schema coverage, no output schema, and destructiveHint=true, the definition does not cover upsert/overwrite behavior, validation constraints on the price and discount strings, or what the caller gets back. The 'does not modify Mercado Libre' note helps, but key operational facts are missing.

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

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

Schema description coverage is 0% across 5 parameters, so the description has to carry the load. It does name the semantics of three fields (price floor, max discount, optional product data covering cost/notes) but leaves item_id and the string-typed numeric formats unaddressed, so it partially compensates rather than fully.

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: saves a seller-side rule containing a public price floor, a max discount and optional product data. The clause 'no modifica Mercado Libre' usefully separates it from the item/promotion mutation siblings. It does not name a closest sibling (e.g. meli_save_business_policy), so it stops short of 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 explicit when-to-use or when-not-to-use guidance and no pointer to alternatives such as meli_active_rules_status or meli_save_business_policy. The only context is the negative scoping clause about not touching Mercado Libre, which is inferred rather than stated as a usage rule.

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 readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered without the description restating it. However, the description adds no behavioral context such as pagination behavior, rate limits, result scope, or authentication needs, despite having limit and offset parameters.

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 sentence with zero waste and the search purpose is front-loaded. It is appropriately sized for the amount of information it chooses to provide.

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

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

For a four-parameter search tool with 0% schema coverage and no output schema, the description is too sparse. It does not explain pagination, return shape, or site-code format beyond one example, leaving important context missing for correct invocation and result interpretation.

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 partially explains q as text and site_id as site with the example 'MLA', but it says nothing about limit or offset, leaving half of the parameters undocumented in both schema and description.

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

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

States a specific verb ('Busca') and resource ('productos de catálogo') with text and site scope, plus an example site code. It does not explicitly differentiate itself from sibling catalog tools such as meli_catalog_product or meli_compare_catalog, so it is clear but not fully sibling-aware.

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, prerequisite, or alternative-tool guidance. The text only implies that this is a catalog text/site search, leaving the agent to infer when it should be chosen over sibling catalog tools.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds only that results are paginated — useful, but it omits the maximum page size, default ordering behavior, rate limits and what an empty result means.

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 scope (seller) front-loaded. It is efficiently written, though efficiency here comes at the cost of substance rather than from trimming 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 four parameters, 0% schema description coverage and no output schema, the description should explain pagination mechanics and sorting options; it does neither. An agent can guess how to call it but cannot call it well, e.g. it has no idea of a safe limit or valid sort keys.

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 and it does not: sort, limit, offset and seller_id have no documented accepted values, ranges or defaults beyond the bare schema titles. Only the phrase 'de un vendedor' loosely implies seller_id's role, and 'paginadas' loosely implies limit/offset.

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 (search a seller's sales orders) plus the pagination nature of the result. It implicitly separates itself from meli_get_order (single order lookup) but never names that 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?

No when-to-use guidance at all: nothing tells the agent to prefer this over meli_get_order for a known order id, nor when pagination is appropriate. The word 'paginadas' hints at bulk listing but no 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 declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety is covered. The description adds the useful pagination behavior ('con cursor para recorrer resultados') but says nothing about return shape, limits, or rate/auth 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?

A single front-loaded sentence with no wasted words. It conveys purpose and pagination efficiently.

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 list operation with annotations covering safety, the description is minimally adequate and mentions pagination. However, with no output schema and zero parameter descriptions, it should do more to explain the promotion_type filter and cursor semantics.

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

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

Schema description coverage is 0%, so the description must compensate for four undocumented parameters. It only hints at seller scope, page size, and cursor traversal; it never explains the promotion_type filter or the expected cursor value, leaving meaningful gaps.

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 ('Lista ... campañas del vendedor'), making the seller-level scope clear. It does not explicitly distinguish itself from nearby promotion tools like meli_item_promotions or meli_promotion_items, but the seller qualifier gives useful 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 only usage guidance is that results are paginated with a cursor. It never says when to use this seller-campaign listing instead of item-level promotion tools, nor does it mention any prerequisites or exclusions.

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

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

Annotations already flag destructiveHint=true and openWorldHint=true, so the safety profile is partly covered; the description still adds the crucial non-obvious detail that this is a full replacement rather than an append, plus the HTTPS-public-URL constraint. It omits return behavior and error handling for invalid URLs (relevant given the meli_picture_errors sibling).

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 compact sentence with the destructive replacement semantics front-loaded, then the retention caveat. 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 destructive two-parameter write with no output schema and 0% parameter documentation, the description covers the replacement semantics and URL requirement but leaves the agent without guidance on failure modes, limits, or what the response contains. 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 0%, so the description must compensate: it does add meaning for picture_urls (must be public HTTPS URLs) and implies full-list semantics, but it never explains item_id or array ordering/max-count constraints. It covers one of two parameters meaningfully.

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 ('Reemplaza la lista completa de fotos') that clearly identifies a mutation of an item's photo list. It distinguishes the operation from read-side picture siblings like meli_picture_errors implicitly through the 'Reemplaza' verb, 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 clause 'incluye todas las fotos que deban conservarse' gives the essential usage condition for a full-replacement call (you must resend the ones you want to keep). It does not name an alternative tool or mention prerequisites/auth, so it stops short of explicit when/when-not routing.

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, openWorldHint=true, and destructiveHint=false. The description adds important behavioral context beyond annotations: results are paginated, and buyer text is explicitly flagged as untrusted data, which is a useful prompt-injection warning.

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

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

The description is a single compact sentence with the core purpose front-loaded and a semicolon-separated security note. There is no wasted language.

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 list tool, annotations cover safety and the description gives purpose plus a security note. However, with no output schema and no parameter descriptions in the schema, the definition leaves gaps around parameter behavior and return semantics.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only implies pagination via 'paginadas' and does not explain seller_id as required, or the meaning/defaults of limit and offset.

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 in Spanish: 'Busca preguntas sin responder' (search unanswered questions). It is clear what the tool does, but it does not explicitly distinguish itself from sibling question tools such as meli_question_detail or meli_question_context.

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

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

Usage is implied by the phrase 'preguntas sin responder', suggesting it is used to find questions that need an answer. However, there are no explicit instructions on when to use this tool versus meli_question_detail, meli_question_context, or meli_answer_question.

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 and openWorldHint=true, but the description never flags that the existing description is overwritten (the old text is lost) nor mentions auth/permission or rate-limit requirements that clearly apply to a live marketplace write. It adds only that the target is an existing publication, which the annotations already 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?

A single front-loaded sentence with no padding. It is appropriately sized for a one-action tool, though its brevity comes at the cost of the missing details above.

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 0% schema coverage, a destructive write annotation, and no output schema, the description should at minimum clarify param formats and the overwrite behavior. Neither is present, leaving the agent under-informed before invoking an irreversible operation.

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% for two required params, so the description carries the full burden and does not compensate: item_id's expected format (e.g. MLA123456) and plain_text's accepted content (plain text vs. HTML/markdown, length limits) are unexplained.

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 (Modifica) and resource (texto de la descripción de una publicación existente), which cleanly separates it from meli_get_description. It doesn't name any sibling or note the scope limitation (single item, existing listings only), but the core purpose 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?

No when-to-use, when-not-to-use, or alternative is given. An agent must infer that meli_get_description reads while this writes, and there is no guidance on whether meli_update_item also touches the description or which one to prefer.

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 and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: it never says whether 'changes' is a partial merge or a full replacement, what an invalid field does, whether the call is reversible, or that catalog items may require confirmation — despite the presence of a catalog_confirmed flag hinting at exactly such a hazard.

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 efficient sentence with the verb and resource front-loaded and no filler. It is perhaps too terse rather than padded, but nothing in it 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 destructive, open-world mutation with a free-form nested object, 0% schema coverage and no output schema, the description is far too thin. The critical unknowns — merge vs replace semantics, the catalog_confirmed flag, and prerequisite flows — are 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 description coverage is 0%, so the description must carry the burden and does not. It lists example field names but no actual keys, types or nesting for the free-form 'changes' object, and it is silent on 'catalog_confirmed', whose meaning and effect on the call are impossible to infer from the schema alone.

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

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

States a specific verb ('Modifica') and resource ('campos de una publicación') and enumerates the updatable fields (precio, cantidad, estado, atributos, variaciones), so the agent knows exactly what the tool touches. It does not, however, distinguish itself from siblings such as meli_create_item, meli_update_description or meli_preview_item_changes.

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 when-to-use guidance, no preconditions, and no mention of the obvious alternative meli_preview_item_changes that exists among the siblings. The agent must infer entirely from the name when an update is appropriate versus a preview or a description update.

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, openWorldHint=true, and destructiveHint=false. The description adds useful context that the User Product's attributes can affect associated publications, but it does not explain permissions, rate limits, or return 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?

The description is short, front-loaded, and contains no filler: the first sentence states the operation and the second adds impact context. It is efficient, though the second sentence is somewhat vague.

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, the description still leaves important gaps: it does not clarify the required user_product_id semantics, describe what is returned, or explain how this differs from related tools. Annotations cover the safety profile, but the rest of the context is thin.

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

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

The schema has 0% description coverage and only the property title 'User Product Id.' The description does not explain the expected ID format, where to obtain it, or how it relates to the returned User Product, so it only minimally implies the parameter's meaning.

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

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

The description uses a specific verb and resource: 'Consulta un User Product.' It clearly identifies the operation as a read of a User Product, and the second sentence adds relevant domain context, but it does not distinguish this tool from nearby siblings such as meli_user_product_stock.

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 consultation of a User Product but gives no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or related sibling tools like meli_user_product_stock.

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 readOnlyHint=true, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds a real behavioral nuance, that stock for 'Full' (fulfillment) may not be editable, which the annotations do not convey. It says nothing about pagination, response shape, or whether stock is per-warehouse.

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?

Very short and front-loaded, but the semicolon-joined second clause is cryptic rather than informative. Brevity here reflects under-specification rather than disciplined concision.

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 should disclose that the response contains stock levels and location/warehouse data — it only alludes to this in Spanish shorthand. Combined with an undocumented required parameter, an agent lacks enough to call this correctly on the first try.

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 user_product_id is never mentioned or explained in the description. With one undocumented parameter the description must compensate and does not — it gives no hint that the ID is a user-product identifier or where to obtain it.

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 verb and resource ('Consulta stock distribuido y ubicaciones') so the basic purpose is inferable, but 'distribuido' and the relationship to the sibling meli_user_product are unexplained. An agent cannot tell from the description whether this returns per-warehouse stock for a user product or something 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?

No statement of when to use this versus the closely named sibling meli_user_product, and no prerequisites stated. The only usage-adjacent hint ('Full puede no ser editable') is a vague caveat rather than routing guidance.

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