get_member_info

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

Despite no annotations, the description fully discloses behavior: endpoint used, data accuracy (party/district reflect actual assembly affiliation), pagination details (page, page_size, has_more), and return fields. No behavioral traits are hidden.

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?

Well-structured with a brief intro, when-to-use section, and args list. Every sentence adds value. Slightly verbose due to bilingual description (Korean then English), but overall efficient and front-loaded. Could be slightly more concise by merging the bilingual intro.

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 7 parameters, no annotations, and presence of output schema, the description is highly complete. It covers all parameters, return fields explicitly listed (members with field names, count, total_count, has_more), and pagination explained. No gaps remain.

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 0%, so description carries full burden. It provides detailed parameter descriptions with Korean labels, example values, default values, and acceptable range for assembly. Each parameter is explained clearly, going well beyond the schema.

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 it queries National Assembly member information including party, district, committee, contact, photo. It specifies the exact data sources and distinguishes itself from sibling tools by noting it uses the ALLNAMEMBER endpoint for correct per-assembly data across all assemblies (16th-22nd).

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?

Provides explicit guidance on when to use: look up member affiliations, list party members, verify name spelling. Also includes a specific exclusion: for committee rosters, use get_committee_members instead. This helps the agent choose between tools.

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