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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context beyond that — that monetary values are in REAIS and that the date range applies to created or last-changed — but says nothing about pagination, result caps, or ordering.

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?

Two tight sentences, front-loaded with what the tool returns and followed by the invocation rule. The trailing 'GET /proposal/list' is endpoint trivia that adds little for an agent, but overall there is no bloat.

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?

For a 4-parameter read tool with no output schema, the description covers filtering and currency but leaves the return shape, pagination, and the failure mode when neither patient_id nor a date pair is given entirely unstated. That last omission is the most consequential gap for correct 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?

Schema coverage is 75%, with patient_id carrying no description in the schema at all; the description compensates by clarifying it identifies one patient. It also expresses the disjunctive requirement (patient_id OR both dates) that the schema's zero required parameters does not convey. date_kind is left entirely to the schema enum description.

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?

Names the resource specifically (treatment/procedure proposals), states the value unit (REAIS), and scopes it to a patient and/or date range. It is clearly distinguishable from siblings like feegow_list_invoices or feegow_list_procedures, though it never explicitly contrasts itself with them.

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?

'Give patient_id, or both dates' communicates the invocation constraint, which is the most important usage fact here. However, it gives no when-not guidance, no mention of what happens if neither is supplied, and no alternatives for related data (e.g., invoices).

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