get_member_voting_history

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

No annotations are provided, so the description carries the burden. It does reveal that this is a read-only lookup ('조회') and that limit caps at 100, which is useful. However, it does not describe behavior when both name and bill_id are provided, when neither is provided, or what shape of data is returned beyond the existence of an output schema.

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 purpose is stated in one sentence, and the Args list is compact and front-loaded. Each line earns its place. The format is slightly redundant with the parameter names, but it is still efficient and readable.

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?

The description covers the two common query modes and all parameter meanings, but leaves an important gap: all parameters are optional in the schema, yet the description never states whether at least one of name or bill_id must be provided. It also does not mention pagination limits beyond the limit parameter, but the outpt schema helps retern.

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%, and the description fully compensates. Each parameter gets a Korean explanation with usage context: name for a member's history, bill_id for who voted how on a bill, age for assembly session, and page/limit for pagination with max 100. This is more meaningful than the schema alone.

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 that the tool retrieves a legislator's plenary voting record or a specific bill's individual member voting status. The verb '조회합니다' and the resource '표결 기록/표결 현황' are specific. It does not explicitly distinguish itself from sibling tools like get_bill_voting_results, so it misses a point for sibling differentiation.

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 Args section gives useful context for when to use name vs bill_id, but this focuses on parameter selection rather than tool selection. It never mentions alternatives among siblings or states when not to use this tool. Usage context is present but not complete.

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