get_member_bills

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains the is_chief_patron marker, role filtering, query semantics (case-insensitive substring match), limit cap at 200, and offset pagination. This is thorough for a read operation, though it stops short of describing the exact response structure.

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?

Three sentences, each earning its place. The core purpose is front-loaded, and the parameter behaviors are packed into two sentences with zero fluff. The use of backticks around variable names aids readability.

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 tool with no output schema and no annotations, the description covers the essential context: what it returns, how to filter by role and keyword, pagination limits, and why it's needed (co-patronage). It omits the response format and required-parameter reminders, but those are minor given the schema already marks the required fields.

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%, so the description is the only source of parameter meaning. It clarifies role, query, limit, and offset, including the cap and pagination behavior. It doesn't discuss member_id and session_code, but those are self-evident identifiers. This meaningfully compensates for the schema's silence.

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?

States exactly what it does: 'Every bill a member patrons in a session, in any role.' The addition about co-patronage distinguishes it from sibling tools like list_bills or get_bill_patrons, making the purpose unmistakable.

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?

The description explicitly explains when to use this tool: 'The session bill list names only chief patrons, so this is the route to a member's co-patronage.' It gives clear context about the tool's role among siblings, though it doesn't name alternatives directly or state when not to use it.

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