meli_active_rules_status

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.