get_seller_reputation

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

With no annotations, the description carries the full burden and does disclose behavior beyond the schema: it explains that omitting user_id yields the authenticated account, that other sellers return public data, and that metrics cover 'the last period'. It does not mention auth requirements, rate limits, or error behavior for invalid user_ids, so it falls short of a 5.

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

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

The purpose and default/override behavior are front-loaded, and the following sentences earn their place by decoding fields the schema cannot (level_id color scale, power_seller_status tiers, metric list). It is dense but not padded; only the level_id explanation is slightly more verbose than strictly needed to invoke the tool correctly.

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

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

There is no output schema, and the description compensates by enumerating the returned payload (nickname, registration date, transaction totals, metric rates/values) and interpreting the enum-like fields (1_red through 5_green, silver/gold/platinum). An agent has everything needed to call it and interpret the result.

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

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

Schema coverage is 100% and the single parameter's schema text already says 'omit to check the authenticated account', so the description largely restates it. It adds only the 'public data' nuance. Per the rubric, the baseline is 3 when the schema does the heavy lifting.

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 ('Get a seller's reputation profile on Mercado Livre') and immediately disambiguates the two operating modes: the authenticated account by default vs. any seller via user_id. No sibling tool in the list covers seller reputation, so the agent can place it unambiguously.

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

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

It states the purpose ('Use this to check the seller's reputation thermometer and service metrics') and the condition that selects the parameterized mode (user_id for public data on any seller). It does not name a when-not case or a sibling alternative, but no sibling overlaps this capability, so the gap is minor.

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