get_legislator_propose_bills

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 mentions 'Raises: 例外時回傳中文錯誤訊息字串' (returns Chinese error messages on exception), which is some transparency. However, it does not disclose behavioral aspects like pagination behavior, response structure, idempotency, or whether it is a read-only operation. The description is mostly a parameter listing with minimal behavioral context.

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 well-structured with Args, Returns, and Raises sections, which is positive. However, it is verbose, listing all 21 parameters explicitly with examples. This is not concise for an agent to parse quickly. It front-loads the purpose but then provides a long list that could be trimmed or summarized. The structure is good but the length reduces conciseness.

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's complexity (21 parameters, 2 required), the description enumerates all parameters and provides return/error info. An output schema exists, so return details are not required in the description. However, it lacks guidance on how the filter parameters are combined (e.g., are they all applied concurrently?) and does not explain when to use some parameters over others. It is complete in coverage but lacks operational semantics for effective usage.

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 the baseline is 3. The description adds examples for several parameters (e.g., 'term: 屆，例：11'), which aids understanding. However, it largely duplicates the schema descriptions without adding new semantic depth, such as explaining how multiple filters interact (e.g., AND vs OR) or the relationship between 'term' and 'bill_term'. It does not clarify the meaning of 'bill_flow_status' vs 'bill_status' which could be confusing.

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 list of bills where the member is the proposer). This is a specific verb+resource combination. It implicitly distinguishes from the cosign tool by mentioning 'propose' but does not explicitly name the sibling 'get_legislator_cosign_bills' as an 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?

There is no guidance on when to use this tool versus alternatives. The description solely lists parameters and the return type. It does not mention that for bills where the legislator is a cosigner, one should use 'get_legislator_cosign_bills'. No context is provided for typical use cases or prerequisites beyond the required 'term' and 'name'.

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