get_member

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

No annotations are provided, so the description carries the transparency burden. It clearly states the operation is a read ('Reads the session roster') and discloses an important behavioral quirk: the by-id endpoint answers nothing for some members, making the roster authoritative. It does not detail auth or error behavior, but for a read-only lookup with an output schema this is solid.

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 with no filler: the first defines the return content, the second gives the data source and rationale, and the third routes to siblings. Information is front-loaded and each sentence earns its place.

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 simple two-parameter lookup, the definition covers purpose, source, output fields, and alternatives, and an output schema exists so return values need not be described. It falls just short of fully complete because the two parameters are not explained beyond their names, and the description relies on the agent inferring how to obtain session_code.

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 needed to define member_id and session_code, but it only alludes to them via 'session roster.' The parameter names are somewhat self-explanatory, but no format, source, or relationship to list_sessions is provided, leaving a real semantic gap.

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 opens with a concrete summary of the returned object ('One member's roster record: name, chamber, party, district, status, contact') and adds the verb 'Reads the session roster,' making the operation clear. It also distinguishes itself from get_member_committees, get_member_bills, and get_member_votes by stating those cover other data. This is specific enough to separate it from all sibling tools.

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?

It explicitly says to use get_member_committees for seats, get_member_bills for patronage, and get_member_votes for the voting record, giving clear alternative routing. It also explains the roster is the authoritative source because LIS's by-id endpoint fails for some sitting members, which tells the agent why this tool is preferred.

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