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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the 'leitura' label adds little. The description does add batch-execution semantics for ids, marketplace_ids, product_ids, and subscription_ids, but it does not explain pagination behavior, cursor usage, or return payload shape. There is no contradiction between the description and annotations.

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

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

The description is front-loaded with a domain statement and uses compact semicolon-separated lists, but it is over-inclusive for this specific tool. Most of the action list describes sibling tools rather than the 'activities' action, and the 'Flattened action: activities' line adds jargon without 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?

This is a high-complexity tool with 20 parameters, no required fields, no output schema, and no schema-level descriptions, so the description must carry substantial context. It provides some parameter mapping and batch behavior, but it fails to explain what the response looks like, how pagination/cursor works, or which action actually applies to this tool. The description is not complete enough for reliable autonomous 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?

With 0% schema description coverage, the description partly compensates by naming filter groups, YYYY-MM-DD date formats, the sub enum values, and bulk array parameters. However, it leaves 'account' undocumented, and action-specific parameter requirements are ambiguous because the schema has no required fields and no action-selector 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?

The description opens with the generic 'Vendas/transações no Guru (leitura)' and then lists six actions (search, get, activities, order_bumps, etickets, by_marketplace), rather than stating that this tool specifically provides transaction activities. The 'Flattened action: activities' marker is cryptic, and the description does not distinguish this tool from sibling tools like guru_transactions_get, guru_transactions_search, or guru_transactions_order_bumps.

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 or when-not-to-use guidance. The action list reads like endpoint documentation rather than tool-selection guidance, and it never tells the agent to use this tool for activity retrieval or to use sibling tools for other transaction operations. The batch-support note implies a use case, but no exclusions 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.