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

With no annotations, the description carries the full behavioral burden. It discloses the underlying mechanism: it asks the PartnerAuthentication service whether the key is registered and active, and contrasts that with the misleadingly permissive heartbeat endpoints. This adds real behavioral context beyond the tool name.

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?

Two sentences with no filler. The main purpose is front-loaded in the first sentence, and the second sentence earns its place by explaining why this endpoint is necessary despite heartbeat endpoints accepting any key.

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 zero-parameter validation tool with an output schema, the description is complete. It tells the agent exactly what the tool checks, why that check is necessary, and which service it contacts. No additional detail is needed for correct invocation.

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?

The tool has zero parameters, so the baseline is 4. The description adds useful context about the 'configured' key even though no input is required, which is sufficient for an agent to understand how invocation works.

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 specific verb-resource pair: 'Validate the configured LIS API key.' It also distinguishes this tool from the sibling data-retrieval tools by framing it as the only real authentication check, so an agent can immediately tell what it is for.

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 explains why this tool matters ('heartbeat endpoints accept any key, so this is the only real check'), giving strong contextual guidance for when to call it. It does not explicitly name sibling alternatives or exclusions, but none of the siblings perform API-key validation, so the context is sufficient.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It explains meaningful semantics: patrons are grouped by role, and a sessions list with two entries means the bill carried over from the even-year into the odd-year session. It does not mention error cases or authentication, but this is a detail-retrieval tool and the framing strongly implies a safe read operation.

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 compact and front-loaded, with the main purpose in the first sentence. The follow-up notes on patrons and sessions are specific and useful, with no filler or repeated schema information.

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?

An output schema exists, so the description does not need to spell out return values. It supplies the key interpretive details that the schema cannot convey, such as session carryover meaning and patron role grouping. The main gap is parameter guidance, but for a two-parameter getter this is a modest omission.

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 is the only place to explain bill_number and session_code, but it never does. It indirectly refers to 'one bill' and 'session lineage,' but does not explain the expected format of bill_number, what session_code represents, or how the two parameters interact.

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 'Full detail for one bill' and enumerates the returned fields: title, status, dates, patrons, and session lineage. It clearly distinguishes itself from get_bill_patrons by noting that sibling returns the same patron list with member ids.

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 phrase 'Full detail for one bill' establishes when to use this tool, and the explicit comparison with get_bill_patrons helps route an agent between similar endpoints. It does not exhaustively contrast with other siblings like get_bill_summaries or get_bill_text, but the context is clear enough for typical selection.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses LIS data quirks (passage dates null in detail, committee recorded only here), defines field semantics (is_passage meaning, status after each event), and explains the vote_id → get_roll_call linkage. This exceeds what annotations would typically convey.

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 front-loaded in one clear sentence, and the second paragraph organizes field explanations densely — every sentence carries unique value (quirks, semantics, routing). It is slightly long for a 2-parameter read tool, but the density justifies most of the length.

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 output schema exists, the tool's read-only nature, and 21 siblings, the description covers the core behavior, data quirks, response field semantics, and one cross-tool route. The notable gap is parameter documentation (0% schema coverage, no compensation in prose), though the parameter names are reasonably self-evident.

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 never mentions bill_number or session_code, so it does nothing to compensate for the uncovered schema. The parameter names are somewhat self-evident, but the rubric requires the description to fill low-coverage gaps, and none of the requested-parameter semantics are addressed.

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 first sentence states a specific verb and resource — 'Chronological action history for a bill' — and the scope ('from prefiling to governor action') is explicit. This is clearly distinguishable from sibling tools like get_bill, get_bill_votes, get_bill_summaries, and get_bill_text.

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 gives implicit routing context: 'Passage dates live here' with the note that bill-detail passage fields are 'always null in LIS,' and 'this is the only place LIS records which committee holds a bill.' It also explicitly routes vote_id to get_roll_call. However, it never names an alternative for plain bill detail or states when not to use this tool.

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

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

With no annotations, the description carries the behavioral burden. It does disclose useful behavior: output is in LIS display order, role is restricted to three values, and member_id is a chainable key to related tools. It does not mention edge cases like empty results or any call limitations, but for a read-only list endpoint this is acceptable.

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 compact and front-loaded with the core purpose. Every sentence earns its place: the role enumeration is valuable, the chaining note is actionable, and the get_bill comparison prevents tool-selection confusion. There is no filler or repetition.

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 tool is simple, an output schema exists, and the description covers ordering, role values, and chaining relationships. However, the absence of any parameter guidance combined with 0% schema coverage leaves a real gap for an agent selecting and invoking this tool correctly. It is usable but not fully complete.

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% for the two required parameters, and the description adds no input parameter meaning. It explains output concepts like role and member_id, but says nothing about bill_number or session_code formats, validation, or interpretation. The description was expected to compensate for the missing schema descriptions and did not.

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 states exactly what the tool returns: every patron of a bill with their member ids, in LIS display order. It also differentiates from get_bill, which lists the same names grouped by role but without ids, so an agent can immediately tell the two apart.

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 implies when to use this tool: when you need member ids that can chain into get_member, get_member_bills, get_member_votes, and get_member_committees. It also names get_bill as the alternative when ids are not needed. The guidance is clear but implied rather than stated as an explicit when-to-use rule.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses meaningful result behavior: the `is_active` field marks the current summary, and an empty list indicates no summary exists for that bill/session. This goes beyond return format details into practical interpretation, though it does not mention side effects or failure conditions.

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?

Every sentence earns its place: first the resource, then the important `is_active` and empty-list semantics. No filler or repetition.

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 read-only list tool with an output schema, the core resources and empty-result semantics are covered. However, missing parameter documentation and usage guidance leave an agent less able to confidently construct and interpret calls, especially given the 0% schema coverage on parameters.

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 only indirectly refers to 'bill' and 'session'; it does not explain what bill_number should look like, what session_code values are valid, or how they combine. The parameter names are self-explanatory only at a basic level.

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 states the resource ('plain-text summaries of a bill') and gives examples of the summary variants ('as introduced, as passed, ...'), so the purpose is clear. It doesn't explicitly differentiate itself from sibling tools like get_bill_text or get_bill, but the resource is distinct enough by name and content.

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 about when to use this tool versus alternatives such as get_bill_text or get_bill. The description only explains output semantics, not the context in which this summary endpoint is appropriate.

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

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

With no annotations, the description carries full behavioral burden and does so thoroughly. It discloses HTML stripping, default-to-most-recent-version, 15,000-character truncation with a 'truncated' flag, and flattening of amendment markup. These are meaningful behaviors an agent would otherwise not know.

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?

Compact and well-structured: the core purpose leads, followed by parameter guidance, return behavior, and formatting nuances. Every sentence earns its place with no filler or repetition of schema data.

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 moderate complexity, no annotations, and no output schema, the description covers the essential return behaviors: full text, truncation, truncated flag, and amendment handling. It is missing only minor details like response envelope or error cases, which are not critical for selecting and invoking the tool correctly.

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 adds useful semantics and examples for document_code, but says nothing about bill_number or session_code beyond their schema titles. Two of the three parameters remain underexplained, leaving a notable 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?

States a specific verb and resource: retrieving the full plain-text content of a single bill version. The phrase 'one bill version' distinguishes it from bill metadata, summaries, history, and votes among siblings. It also clarifies the HTML-to-plain-text transformation, making the tool's core purpose unmistakable.

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 clear context on how to select a version and the default behavior, but does not explicitly contrast with sibling tools like get_bill, get_bill_summaries, or get_bill_history. The intended use is implied by 'Full text' rather than explicitly stated as when-to-use versus alternatives.

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

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

With no annotations at all, the description carries the full burden and does well: it explains is_roll_call semantics, voice votes, block votes, bills_in_vote, and the request cost per vote. This is far beyond what the raw schema or annotations would provide.

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?

Every sentence earns its place: scope, vote type coverage, classification semantics, companion tool routing, and cost. The main purpose is front-loaded and the additional details are compact.

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 is behaviorally rich and an output schema exists, so return values do not need elaboration. It is missing parameter-format guidance, but for a simple two-parameter tool with sibling tools like list_sessions and list_bills, the invocation path is adequately discoverable.

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 does not explain bill_number or session_code formats, sources, or examples. The only parameter-related hint is 'on a bill,' which is too weak to compensate for the lack of schema descriptions.

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 states a specific verb and resource: it returns every recorded vote on a bill, in both chambers, in chronological order. It also distinguishes itself from get_roll_call by explaining that this tool provides votes while get_roll_call provides member-by-member records.

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 gives clear context for when to use this tool: to see all floor, committee, and subcommittee votes for a bill. It explicitly points to get_roll_call when member-level detail is needed, though it does not mention alternatives like get_member_votes or get_bill_history.

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

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

With no annotations, the description carries the behavioral disclosure burden. It reveals LIS ordering with chair first, partial-name matching, ambiguity handling, and the meanings of meeting_note and subcommittees. It does not discuss authentication or read-only guarantees, but the tool name and roster semantics make side effects unlikely.

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 three dense sentences with the main purpose front-loaded. Each sentence adds value: the first defines the output, the second explains identifier semantics, and the third clarifies output fields and subcommittee handling. No filler or repetition.

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 output schema covers return structure, and the description adds solid context for lookup semantics, ambiguity, ordering, and output fields. However, the required session_code parameter is not adequately explained, and there is no explicit tool-selection guidance relative to sibling tools, leaving some gaps for an agent invoking this tool.

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 compensates well for committee and chamber, including formats and disambiguation. However, session_code is a required parameter and is only indirectly referenced as 'for a session'; its format or source is not explained, leaving a meaningful 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 clearly states that the tool returns a committee roster with each member's role, party, and district for a session. It is distinguishable from siblings like list_committees and get_member_committees by the focus on a single committee's roster, though it does not explicitly name those alternatives.

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 provides useful guidance for ambiguous committee names by telling the caller to pass a chamber or number, but it does not explicitly state when to choose this tool over list_committees or other committee-related siblings. The intended usage is implied rather than stated.

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

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

No annotations are provided, so the description carries full behavioral burden. It does disclose a non-obvious behavior: during the interim it returns the upcoming session, not the one just ended, and explains that 'continued bills and new prefiles accumulate there.' However, it omits other behavioral details such as read-only nature, auth requirements, or error behavior. For a simple get with no parameters, the added interim nuance is valuable but the overall disclosure is only partial.

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?

Two sentences total: the first front-loads the core purpose, the second adds the critical usage nuance. Both sentences earn their place with no redundancy or filler. The structure is clean and highly 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?

For a zero-parameter tool with an output schema (the schema is not shown but is indicated), the description is nearly complete. It covers the key semantic nuance of what 'current' means during interim, which is the main source of confusion. It doesn't explicitly state the returned object's shape or mention error conditions, but the output schema handles return details. An agent can call this correctly without additional information.

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?

The tool has zero parameters, so per the rubric the baseline is 4. The description adds context about the session itself (e.g., interim behavior) but there are no parameters to document; the schema already covers the empty parameter list. No additional value is needed or provided.

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 returns 'The General Assembly's current working session' – a specific resource. It distinguishes from siblings by explaining the interim nuance and directing retrospective work to 'other tools', though without naming a specific alternative. That's clear, but stops short of naming the exact sibling tool, so a 4 rather than 5.

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?

Explicitly explains when to use this tool (for the current working session, including interim where it is the upcoming session) and when not to: 'For retrospective work on a finished session, pass that session's code to the other tools instead of relying on this default.' This gives direct yes/no usage conditions and points to an alternative category, satisfying the highest bar.

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

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

No annotations are present, so the description carries the full burden. It discloses the returned content: bills, sections, actions, and vote_id. However, it does not state read-only behavior, possible empty results, pagination, permissions, or limitations. For a read tool this is minimal but adequate.

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 concise sentences, front-loaded with the core definition and then linking to related tools. Every clause carries useful information with no filler.

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 one-parameter tool with no output schema, the description covers the input source, the shape of results, and the downstream step to get_roll_call. It is nearly complete, though it could explicitly confirm that the result includes the bill numbers and session codes needed for that downstream call.

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%, but the description compensates by explaining that calendar_id comes from list_floor_calendars and serves as the key to the specific floor calendar. This adds real meaning beyond the raw integer type, though it could add more detail about format or validation.

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?

Opens with 'One floor calendar' and immediately defines the resource and scope: 'the bills up for action, by section, with the votes taken.' This is specific and distinguishes it from list_floor_calendars (which enumerates calendars) and get_roll_call (which retrieves a single vote).

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 establishes a clear call flow: calendar_id comes from list_floor_calendars, and vote_id plus bill number and session code are routed to get_roll_call. This gives an agent strong context on how this tool fits with siblings, though it does not explicitly state when not to use it or contrast with all alternatives.

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

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.

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains the is_chief_patron marker, role filtering, query semantics (case-insensitive substring match), limit cap at 200, and offset pagination. This is thorough for a read operation, though it stops short of describing the exact response structure.

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, each earning its place. The core purpose is front-loaded, and the parameter behaviors are packed into two sentences with zero fluff. The use of backticks around variable names aids readability.

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 tool with no output schema and no annotations, the description covers the essential context: what it returns, how to filter by role and keyword, pagination limits, and why it's needed (co-patronage). It omits the response format and required-parameter reminders, but those are minor given the schema already marks the required fields.

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 is the only source of parameter meaning. It clarifies role, query, limit, and offset, including the cap and pagination behavior. It doesn't discuss member_id and session_code, but those are self-evident identifiers. This meaningfully compensates for the schema's silence.

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?

States exactly what it does: 'Every bill a member patrons in a session, in any role.' The addition about co-patronage distinguishes it from sibling tools like list_bills or get_bill_patrons, making the purpose unmistakable.

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 explicitly explains when to use this tool: 'The session bill list names only chief patrons, so this is the route to a member's co-patronage.' It gives clear context about the tool's role among siblings, though it doesn't name alternatives directly or state when not to use it.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the underlying multi-request behavior, the cold-request counts, and the caching behavior, which is valuable context beyond the schema. It does not mention failure modes or rate limits, but the disclosed behavior is substantial.

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 compact and front-loaded: the first sentence states the core purpose, and the second sentence adds essential behavioral context. Every sentence earns its place with no filler.

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 is complete for a read-only lookup tool: it explains the purpose, the data returned, and the performance characteristics. The output schema exists, so return values need not be described. It could be more complete by explicitly naming sibling alternatives, but the context is sufficient for an agent to call the tool correctly.

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 for the schema's lack of parameter documentation. The description explains the member_id and session_code implicitly (member and session), and mentions include_subcommittees by noting the 67-request cost with subcommittees. However, it does not explicitly define each parameter's format or meaning, so the compensation is partial.

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 states a specific verb and resource: it returns every committee seat a member holds in a session, with the role. This distinguishes it from sibling tools like get_member_bills and list_committees, though it does not explicitly name those alternatives.

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 explains why this endpoint exists (LIS has no member-first committee endpoint) and gives concrete context about the request cost (14 requests cold for a House member, 67 with subcommittees, cached afterwards). It implies when to use it—when you need a member's committee seats—but does not explicitly state when not to use it or name alternative tools.

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

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses row semantics for block votes, the effect of exclude_block_votes, the distinction between total_matching and distinct_votes, omission of attendance roll calls, and LIS ordering, along with a hard limit cap.

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 information-dense and well-structured, front-loading the core purpose before explaining nuances. Every sentence adds meaningful operational detail, including edge-case behavior and pagination, without redundancy.

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 there is no output schema and no annotations, the description provides a remarkably complete picture: scope, row cardinality, block-vote behavior, counting semantics, exclusions, ordering, and pagination limits. An agent has enough context to invoke and interpret the tool correctly.

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 clarify parameters itself. It does: member_id and session_code are implied by 'one member' and 'in a session', bill_number by 'votes on one bill', exclude_block_votes by its explicit effect, and limit/offset by pagination guidance and the 200 cap.

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 precise verb and resource: it retrieves every vote one member cast in a session, or their votes on a single bill. This clearly distinguishes it from bill-centered sibling tools like get_bill_votes by making the member the primary axis.

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 clearly defines when to use the tool and what scope options exist, including filtering to one bill via the bill context. It does not explicitly name alternative tools or state 'use X instead', but the member-vs-bill framing provides strong contextual guidance.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses grouping under yea/nay/abstain/not_voting, the special meaning of statements, that the recorded response still stands, and that voice/block votes are omitted. These are non-obvious behaviors an agent needs to interpret results correctly.

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 front-loaded with the main purpose and then adds dense, useful detail: grouping, statement semantics, exclusions, and vote_id narrowing. Every sentence earns its place and there is no filler.

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 there is no output schema, the description adequately defines the return structure: one entry per vote, grouped by stance, with party and district, and with statements explained. The main gap is the lack of semantic explanation for the required bill_number and session_code parameters, but the overall behavior is well covered.

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 only clarifies vote_id (“narrows the result to one vote”), while the required bill_number and session_code are left entirely to their schema titles with no additional meaning, format, or relationship explained.

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 opening sentence clearly identifies the resource and purpose: “Who voted which way on a bill, with party and district, one entry per vote.” It also distinguishes this tool from get_bill_votes by explicitly saying voice votes and block votes are excluded.

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 gives explicit when-to-use context: it covers only recorded member votes, not voice or block votes, and names get_bill_votes as the sibling that includes those. It also explains that vote_id narrows the result to one vote, giving a concrete usage condition.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It reveals meaningful behavior: query is case-insensitive substring matching against specific fields, limit is capped at 200, offset enables paging, and total_matching reflects all matches. This goes well beyond what the schema alone communicates.

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 three compact sentences with no filler. It front-loads the main purpose, then adds parameter and pagination details, with every sentence contributing useful information.

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 list tool with an output schema, the description covers search behavior, pagination, and result-count semantics well. Minor gaps remain, such as explicit guidance on obtaining session_code and sort order, but these are partially addressed by sibling tools and the output schema.

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 adds real meaning for query, limit, and offset by defining matching semantics and pagination behavior. However, it does not explain session_code beyond the phrase 'in a session,' even though it is the only required parameter.

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 'List bills in a session, optionally filtered by a search term,' which names a specific verb, resource, and scope. This clearly distinguishes it from singular tools like get_bill and from list_sessions.

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 gives clear context for when to use the tool: listing bills within a session, with optional filtering and pagination. It does not explicitly name alternatives or exclusion cases, but the context is sufficient to avoid confusion with sibling tools.

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

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

With no annotations, the description carries the behavioral burden. It meaningfully discloses that the list is current rather than session-scoped and that membership is intentionally excluded, which are not inferable from the schema alone. It does not mention potential limitations like authentication or rate limits, but for a simple read-style list tool this is acceptable.

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 three compact sentences with no filler. The primary purpose is front-loaded, followed by the key scoping distinction and useful cross-references to related tools, so every 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?

Given the tool's low complexity, an output schema is present, and the description covers purpose, scoping, and downstream usage, this is complete. An agent has enough contextual information to call list_committees correctly and know how the result connects to other tools.

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 does: 'one or both chambers' explains the chamber parameter, and 'optionally with subcommittees' explains include_subcommittees. It doesn't restate the enum values or defaults, but those are already visible in the schema, and the natural-language semantics are clear.

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 identifies the resource (standing committees), the scope (one or both chambers), and the optional subcommittee inclusion. It also distinguishes this list from get_committee by noting that membership is handled elsewhere, so an agent can tell which tool to use.

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 explains when this tool is appropriate: it is not session scoped and lists committees that exist now. It explicitly routes membership questions to get_committee and tells the agent how to use a committee's number or name with get_committee, list_meetings, and list_dockets, giving clear context and alternatives.

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

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

With no annotations, the description carries the full burden. It discloses the ordering behavior, the fact that both docket and schedule times are reported, and the caching cost ('one request per docket cold, cached afterwards'). It does not mention pagination or error conditions, but these are minor given the read-only nature implied by 'list'.

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 concise and well-structured: a clear first sentence stating the purpose, followed by essential details (ordering, House alternative, parameter format, time discrepancy, cost). No superfluous words.

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 2-parameter tool with no output schema, the description covers the essential aspects: what a docket is, its order, the House alternative, the committee format, the time discrepancy, and cost. It omits a definition of session_code but that is a minor gap; the tool is otherwise well-specified.

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 the committee parameter as a Senate committee number or name, but does not describe session_code beyond it being an integer. Since session_code is required but undefined, this is a 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 clearly states the tool lists a Senate committee's dockets for a session, with each meeting and its bills. It distinguishes itself by noting the House has no dockets and directs to get_bill_history and list_meetings instead. This is specific and actionable.

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_bill_history and list_meetings for House-related queries, making clear when not to use this tool. It also provides the ordering (newest first) and mentions the potential time discrepancy between docket and schedule, giving context for interpretation.

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

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

No annotations are present, so the description carries the burden of behavior disclosure. It adds useful domain behavior: calendars are 'one per sitting' and 'several calendars can share a date,' which warns against assuming date uniqueness. However, it does not disclose ordering, pagination, access constraints, or any other runtime behaviors; the presence of an output schema helps but does not fully compensate.

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 compact and front-loaded: the core purpose appears in the first sentence, followed by a necessary domain definition and a brief pointer to get_floor_calendar. Every sentence earns its place, and there is no repetition of schema details or annotation-style content.

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?

With an output schema present and only two simple parameters, the description is nearly complete: it defines the domain, clarifies cardinality, warns about shared dates, and routes the agent to get_floor_calendar. The main omission is guidance on how to obtain or format session_code, though an agent could infer it from sibling get_current_session/list_sessions.

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 for the undocumented parameters. It only loosely hints at 'session' and does not explain how session_code is formatted or obtained; chamber is only visible as the H/S enum in the schema, and calendar_id is mentioned even though it is not a parameter of this tool. This is a meaningful gap for a two-parameter endpoint.

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?

States a specific verb (list) and resource (floor calendars) scoped by chamber and session, and clarifies cardinality with 'one per sitting.' It also distinguishes itself from the sibling get_floor_calendar by pointing out that the latter consumes a calendar_id to retrieve the bills on it.

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 clear context: this tool lists a chamber's floor calendars for a sessionprint, and if you need the bills on a specific calendar, you pass its calendar_id to get_floor_calendar. It does not explicitly enumerate when to choose this over sibling tools like list_dockets or list_meetings, but the handoff to get_floor_calendar gives useful routing guidance.

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

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

There are no annotations, so the description carries the full behavioral burden. It discloses meaningful traits: inclusive date handling, large result counts, cancelled meetings remaining in results with a 'cancelled' flag, the free-text nature of 'time', and the limit cap. This goes well beyond a generic listing description, though it does not mention permissions or read-only guarantees.

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 a single dense paragraph with front-loaded purpose and no filler. Every sentence serves a purpose: constraints, parameter explanations, and behavioral notes are all packed efficiently. Backticks and examples improve readability without bloating length.

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 is thorough for a list tool with no output schema and no annotations. It explains core behaviors, response hints (cancelled flag, time field), and important constraints. The only notable gap is the undocumented 'meeting_type' parameter companions, which could affect how an agent decides to filter results.

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?

With 0% schema description coverage, the description must explain parameters itself. It covers start_date/end_date (format, inclusiveness), committee (number or name), chamber (disambiguation), limit (cap), and offset (paging). However, it does not explain the 'meeting_type' parameter at all, even though the schema enum gives some clue. The description also adds useful output-field context ('time', 'cancelled') 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 identifies the resource ('meetings on the master schedule') and the operation (listing within a date range), and mentions the scope ('committees, floor, caucuses'). It distinguishes itself from sibling list tools like list_bills or list_committees by the 'master schedule' wording, though it does not explicitly name alternatives.

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 concrete usage context: date format and inclusive range, a warning to keep ranges short due to volume, committee name/number filtering, chamber disambiguation, and pagination behavior. It does not explicitly state when not to use the tool or name alternative tools, but the context is clear enough for an agent to select it appropriately.

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

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

With no annotations provided, the description carries the full burden and does so well. It discloses query matching semantics, case-insensitivity, inclusive roster behavior for departed members, the meaning of service_end_date/service_end_reason, and the role of member_id. This is meaningful behavioral context beyond a simple 'list members.

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 compact and front-loaded: a clear one-line purpose statement, then parameter behavior, then roster rationale, then the key takeaway. Every sentence adds value without redundancy or filler.

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 query semantics, roster inclusion rationale, and identifies member_id as a key, which is strong given the lack of annotations and output schema. It falls slightly short by not addressing the chamber parameter or the full set of returned fields, but overall an agent can safely invoke this tool.

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 thoroughly explains the query parameter with examples and omission behavior, and clarifies member_id's role. However, session_code and chamber are not explicitly described, leaving the meaning of those parameters to inference from their names and the enum.

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 identifies the tool as returning the session's member roster, searchable by name, and distinguishes it from sibling member tools by noting that member_id is the key for the member tools. The verb and resource are specific and the scope—session members, including those who departed—is explicit.

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 gives concrete usage guidance: query matches any part of a name, case-insensitive, omit for whole roster. It also explains why departed members are included, which prevents incorrect assumptions, but it does not explicitly state when to prefer this tool over get_member or other sibling tools.

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

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

No annotations are present, so the description carries the burden. It discloses the reference history reaching back to 1994 and explains the return format (code examples). It does not disclose whether the endpoint returns an empty list for years before 1994, requires an API key, or enforces a maximum year; these are typical gaps for a list tool without annotations.

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 short (2-3 sentences) and front-loaded with the main purpose, then adds concrete examples and the historical range. No filler words or verbosity; the examples earn their place by making the session-code format concrete.

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?

There is an output schema available, so the description need not explain the return shape in detail. The main gaps are not explaining the valid year range, not stating the relationship/alternatives to get_current_session, and no error behavior or API-key context. For a one-parameter list tool with an output schema, this is acceptable but not complete.

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?

The schema provides only the parameter name 'year' and type 'integer' with 0% coverage, so the description must carry the meaning. The description explicitly states that year corresponds to a calendar year and shows how codes are built from it (20261 = 2026 Regular Session), which adds semantic meaning beyond the bare schema. It could specify the supported range or that only years 1994+ are valid, but the core semantics are covered.

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?

States a specific verb ('Returns') and resource ('Legislative sessions for a calendar year') and gives concrete code examples. It doesn't explicitly distinguish from get_current_session, but the mention of a calendar-year list versus a 'current' session is clear enough for an agent to infer the difference.

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?

Implied usage: supply a calendar year to get that year's session codes. There is no explicit when-to-use or when-not-to-use statement, nor a pointer to get_current_session for the current session. The examples help, but the guidance is thin given that sibling tools like get_current_session exist.

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