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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new context: the required scope (financials:read), the risk classification, and the absence of side effects. It also warns that the tool may be unavailable when the scope is not granted, which is exactly the kind of authorization detail annotations cannot express.

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?

Purpose is front-loaded in one sentence, and the metadata line is compact despite the heavy separator formatting. The long parenthetical about authorization causes is slightly verbose but each piece conveys real 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?

The tool is simple (one optional enum param, no output schema), and the description covers return content only as far as "com totais." It does not describe what a bill record contains, ordering, or pagination, and the status-filter behavior remains ambiguous, so it is adequate but not 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?

With a single parameter at 0% schema description coverage, the description carries the burden, and it partially does: "abertas e fechadas" maps to the OPEN and CLOSED enum values. It omits CANCELLED entirely and does not explain whether omitting status returns all states or only 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?

The description names the resource with a plain-language gloss ("Comandas (contas de consumo)") and states the scope of what is returned — open and closed guest bills with totals. However, it never distinguishes itself from close siblings like list_accounts, list_balance_due, or list_payments, which an agent could easily confuse with it.

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 instead of the many other financial list tools, and no prerequisites beyond the scope tag. The only usage-adjacent signal is the "INDISPONÍVEL nesta autorização" note, which tells the agent it may not be callable at all, but this is a runtime-state message 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.