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

Annotations cover safety (readOnlyHint, idempotentHint, destructiveHint, openWorldHint), so the bar is lower. The description still adds real behavioral context beyond what annotations provide: it discloses the return envelope `{ tabela, count, total, aviso?, registros[] }`, the default and maximum limit (100/2000), empty-list behavior when a table has no records, and that aggregated vs. nominal records depend on the table. It does not detail pagination beyond `limite` or the meaning of `aviso`, minor gaps.

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?

Front-loaded with the core purpose, then efficiently organized into verb+resource, enum enumeration, return shape, and sibling routing. It is fairly dense with three clauses packed per sentence in places, but every sentence carries information an agent needs. Slight density costs a point versus a crisper version.

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?

Given 3 parameters, an enum, an output schema, and rich annotations, the description covers purpose, enum semantics, return shape, limit behavior, filter behavior, and sibling routing. It is essentially complete; the only omissions are the semantics of the `aviso` field and explicit pagination guidance, both minor against an existing 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 description coverage is 100%, so baseline is 3. The description adds value beyond the schema: it explains what each `tabela` enum actually returns (aggregated quantitative vs. nominal list, with per-value examples), which is far richer than the schema's one-line enum description. It also restates `limite` behavior (default 100, max 2000) and clarifies `filtro` matches any field of the record — a small but genuine addition to the schema's example list.

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 exactly what the tool does — returns Senate personnel tables according to the `tabela` parameter — and explicitly enumerates all eight enum values with parenthetical explanations (e.g., `pessoal` = workforce by class/education). It also names the sibling `senado_servidores` for nominal staff records, clearly distinguishing this tool from that alternative.

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 explicitly routes the agent: use this tool for personnel tables driven by the `tabela` parameter, and use `senado_servidores` for the nominal register of permanent/commissioned servers. The enumerated `tabela` values tell the agent which value to pick for each data need, so both when-to-use and the alternative are given.

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