Get Committee Bills - Bills referred to or reported by a specific committee

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

No annotations are provided, so the description carries the full burden. It discloses the return type (List of bills), the pagination behavior (limit, offset, most_recent logic), and the default ordering behavior. It notes that chamber is inferred if omitted. This adds useful behavioral context beyond what the schema shows, especially the note about the endpoint being oldest-first and the final-page fetch for most_recent.

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 structured clearly with an Args list and a Returns line. It's moderately sized but each line earns its place. The inclusion of the most_recent note is valuable. It could be slightly more concise, but it's well-organized and front-loaded with the main purpose.

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 the tool complexity (5 params, output schema exists, no annotations), the description does a good job. It covers key parameters, explains edge behavior (chamber inference, most_recent), and notes the return type. The output schema exists, so it doesn't need to detail return fields. A minor gap is not mentioning error conditions or rate limits, but for this kind of list tool with an output schema, the description is largely sufficient.

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 must compensate. It explains committee_code (official code with examples 'hsju', 'ssju'), chamber (with allowed values and inference behavior), limit (maximum number), offset (starting record for explicit paging), and most_recent (defaults to True, affects ordering). This adds meaning beyond the schema's field names and types, particularly the inference of chamber and the semantics of most_recent.

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 clearly states the tool's purpose: 'Get bills referred to or reported by a specific committee.' This is a specific verb+resource (get bills by committee), and it distinguishes from sibling tools like get_committee_reports or get_committee_nominations which handle different resources. It doesn't explicitly differentiate from related tools like search_bill_text or bills, but the core purpose is clear.

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 provides usage context: it mentions how to identify a committee (committee_code), and clarifies the 'most_recent' behavior ('When True (default), return the newest referrals first. The endpoint is oldest-first, so this fetches the final page.'). It doesn't explicitly state when not to use this tool or alternatives, but the clarity of the purpose plus the note on the endpoint behavior gives a clear sense of when to call it.

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