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, the description carries the full burden and does meaningful work: it discloses ordering (oldest first), explains that 'chamber' is the chamber that produced the version rather than the bill's, and decodes the sponsor and disposition vocabularies. It does not cover permissions, rate limits, or emptiness/pagination behavior, but the semantic disclosures go well beyond structured fields.

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 summary is front-loaded ('Every published version of a bill, oldest first') followed by supporting field semantics, and every sentence adds information. It is dense but not padded; the only mild inefficiency is that some content belongs more to the output schema than to the description.

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 return values need not be explained, yet the description adds genuinely useful field semantics and the get_bill_text chaining step. The main gap is that it never helps the agent supply its two required inputs, so it is nearly complete but missing parameter guidance.

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 both parameters are required, yet the description says nothing about bill_number or session_code — no format, no example, no indication of where a session_code comes from (e.g., list_sessions). The names are intuitive, but the description does not compensate for the total lack of schema documentation.

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 ('Every published version of a bill, oldest first, with links to its files') and enumerates exactly what a version covers (introduced, substitute, amendment, engrossed, enrolled, chaptered) and what data each carries. This is clearly distinguishable from sibling tools like get_bill_history (events) or list_amended_bills (a filtered list).

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?

Gives a concrete workflow: 'Pass a document_code to get_bill_text to read that version,' which tells the agent how this tool chains into the next step. It stops short of explicit when-to-use versus related siblings (get_bill_history, get_bill), so it is clear context but without exclusions.

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 and largely does: it discloses the scope (floor, committee, subcommittee), ordering (chronological), request cost (one per vote), and the meaning of the is_roll_call flag including the edge cases of voice votes and block votes that dispose of bills_in_vote bills at once. It omits auth/pagination behavior, hence not a 5.

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?

Purpose and scope are front-loaded in the first two sentences, then the flag semantics, then the routing/cost guidance. It is dense and slightly long, but each sentence carries information an agent needs; nothing is 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?

An output schema exists, so return values need not be described, and the description covers scope, flag semantics and cost well enough to invoke the tool correctly. The remaining gap is the unexplained required inputs (session_code especially), which leaves the agent guessing at argument values.

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?

Both required parameters (bill_number, session_code) have 0% schema description coverage and the description explains neither their format nor their semantics. The only field-level explanation (vote_id, bills_in_vote, is_roll_call) concerns data fields and a different tool's parameter, not this tool's inputs, so it does not compensate for the coverage 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?

Opens with a specific verb+resource and scope: every recorded vote on a bill, both chambers, chronological order. It also implicitly distinguishes itself from siblings by naming the closely related tools (get_roll_call, get_bill_vote_tallies) and the different data each returns.

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?

Explicit routing: pass a vote_id to get_roll_call for member-by-member records, and use get_bill_vote_tallies when the is_roll_call/bills_in_vote flags are not needed (two requests instead of one per vote). That is a concrete when-to-use-which-tool statement with a cost tradeoff.

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 richly: discloses that most voice votes are missing, that there is no pass/fail flag (read description and tally instead), that block votes don't state bill count, what an empty list implies, and the two-request performance profile. This is unusually candid limitation disclosure.

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?

Core purpose and the key sibling contrast are front-loaded, and the sentence fragments each carry information. Slightly literary phrasing ("it knows less") and a few extra clauses keep it from being maximally tight, but little is wasted.

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 return values needn't be re-explained, and the description adds the caveats the schema cannot (missing voice votes, no pass/fail flag, empty-list meaning). The one real gap is the absence of any guidance on the two required input 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 for bill_number and session_code, but it explains neither (no format or expected value for either). It mentions vote_id and referred_to, but vote_id is not an input parameter here (it is for get_roll_call), so it adds no input semantics.

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 upfront ("A bill's votes with their tallies and no members") and explicitly distinguishes itself from the sibling get_bill_votes ("lighter than get_bill_votes and it knows less"). An agent can tell exactly what it returns and how it differs from the richer sibling.

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?

Names it as "the fast route to how a bill fared at each stage" and routes the agent to alternatives: get_roll_call for members, and implicitly get_bill_votes for the fuller picture. When-to-use and when-to-escalate are both explicit.

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?

With no annotations provided, the description carries the full burden and does add real behavioral context: the roster is not session-scoped (names current servers), ``since`` marks assignment start, and LIS provides no phone/email for staff. It stops short of stating auth/permission needs or rate limits, but for a read-style lookup it discloses more than most.

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 the first sentence and the remaining sentences are dense with usable detail. The inline-code formatting and stacked clauses make it slightly harder to scan than it could be, but there is little wasted text.

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 return values need not be explained; the description instead spends its words on filtering behavior and data freshness, which is the right allocation. Both input parameters are addressed, leaving only the ambiguity around the referenced ``role`` as a gap.

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, and it largely does: it gives ``committee`` example values ("H08", "S13"), explains that any part of a name is accepted, and clarifies when ``chamber`` is needed to disambiguate. The mention of ``role`` is ambiguous since no such parameter exists (it appears to be an output field), which slightly muddies the parameter story.

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 states a specific resource (clerks and staff serving a committee) clearly enough that an agent knows what the tool returns. It does not, however, explicitly distinguish this from neighboring tools like get_committee or list_committees, so sibling differentiation is left to inference.

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?

Usage is only implied. The note that "the list is not session scoped" and the guidance on passing ``chamber`` when both chambers share a name are helpful context, but the description never says when to choose this tool over get_committee or list_committees, nor any exclusions or prerequisites.

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 and does so unusually well: it discloses that counts are referrals rather than bills, that columns do not sum, that 'failed' only counts committee-killed referrals, that 'in_subcommittee' is a subset of 'in_committee', and that subcommittees have no rows. It omits auth/rate-limit behavior, but the semantic disclosure of the returned data is rich.

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 core purpose is front-loaded in the first sentence, and each subsequent sentence covers a distinct caveat (column arithmetic, membership relation, subcommittee absence, bill-level alternative). Dense but 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?

An output schema exists, so return values needn't be enumerated, yet the description still supplies the column semantics that make the output interpretable. The main gap is parameter-level guidance for session_code, which neither schema nor description covers.

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 two required parameters, and the description barely compensates. It implies the chamber selector via 'one chamber' but never explains the H/S enum values, and session_code's format or valid range is left entirely to 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 first sentence states a specific resource and scope: referral counts per standing committee of one chamber. It distinguishes itself from per-bill tools by noting get_bill_history is 'the record of where one bill went.' The only weakness is that the verb is implicit (it reads as a noun phrase about data rather than an action).

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 routes the agent away from this tool when a single bill's path is needed, naming get_bill_history as the alternative. It doesn't explicitly state when to prefer this over get_session_statistics, but the 'referrals, not bills' framing makes the aggregate use case clear.

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 and does well: it explains the return shape (statements, bills, chief patrons, document_code), states explicitly that it carries no vote ids, and discloses the May 2024 LIS data cutoff plus the fallback html link for older records. It omits auth or pagination behavior, so not a 5.

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?

Front-loaded with the core statement ('One communication between the chambers'), followed by structured disclosure of return contents and data limits. Every sentence earns its place, though the domain framing is slightly verbose.

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 no output schema, the description usefully describes what comes back and the data-availability caveat, which is what an agent needs to interpret results. The only real gap is how to source the communication_id, a minor omission for a single-parameter lookup.

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 single communication_id parameter has 0% schema description coverage, and the description adds no format, sourcing, or validity guidance for it. The field name is largely self-explanatory, so this lands at the minimum-viable baseline rather than being penalized further.

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: retrieves 'one communication between the chambers,' and immediately scopes it as the statements plus the bills they name. This clearly separates it from list_communications, though it never names that sibling explicitly.

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?

Usage is implied by the singular retrieval framing and the sibling list_communications, but the description never states when to reach for this tool versus listing or other bill tools, nor any prerequisites for obtaining a valid id.

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 full behavioral burden. It usefully discloses that it reads the session roster and that LIS's by-id endpoint returns nothing for some sitting members, which is a real behavioral quirk an agent should know. It does not cover error/not-found behavior or whether lookups are cheap, which keeps it from a 5.

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?

Front-loads the return payload before the routing guidance, and the sibling list, while long, is dense and earns its place. Slightly list-heavy but no filler sentences.

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 return values need not be described, and the sibling routing is complete. However, the two required parameters have zero documentation in either schema or description, leaving an agent without guidance on how to supply session_code 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% for both required parameters (member_id, session_code) and the description adds nothing about them – no explanation of where session_code comes from, whether it is required for historical lookups, or valid formats. With two undocumented required params, the description fails to compensate for the schema 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?

Names the specific resource (one member's roster record) and enumerates the fields returned (name, chamber, party, district, status, contact), which makes it immediately distinguishable from siblings like list_members or get_member_votes. It also states the underlying source (the session roster).

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 routes the agent: get_member_committees for seats, get_member_bills for patronage, get_member_votes for voting record, get_member_office for district office. This is a textbook when-to-use-this-vs-alternatives block.

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, the description carries the full burden. It discloses meaningful behavior: the record is not session scoped (no session code), and many members have no record with found=false. It does not explicitly confirm the operation is a read, but for a simple public getter the missing-record and scoping disclosures are the substantive traits.

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?

Front-loaded with the resource and its returned fields, followed by routing and edge-case notes. Every sentence carries information (fields, sibling distinction, session scoping, found flag) with only mild verbosity in the 'publishes nowhere else' phrasing.

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 return shape needn't be explained, and the description still covers the important found=false edge case and session-scoping absence. Complete enough for a single-parameter getter with a documented response.

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 single parameter member_id has no documentation in either schema or description. The description frames the context as a member but adds nothing about the identifier's origin or format; for an obvious numeric id this is acceptable but not compensating.

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 (get) and resource (member's district office) and enumerates the returned contact fields (postal address, phone, email). It explicitly distinguishes itself from the get_member sibling by noting the Capitol room belongs there, so an agent can separate the two without opening either schema.

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 names the alternative (get_member) and the distinguishing condition (Capitol room vs district office), which routes the agent correctly. It also warns that many members have no record, adding a when-not-available signal, though it does not state an explicit 'use this when you need district contact info' imperative.

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?

No annotations, so the description carries the full burden and does so richly: ~200 records per floor day, limit capped at 200 requiring offset pagination, is_block meaning one motion disposed of many bills, is_voice meaning no named members, and the tally preserving a chair tiebreak the vote record drops. These are exactly the quirks an agent needs.

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?

Front-loaded with the definition, then layered detail on record shape, vote_id routing, field quirks, filtering, and pagination. Dense but every sentence earns its place; 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?

With no output schema and zero schema description coverage, the description supplies field semantics, return granularity, and pagination caps, so an agent can call it correctly. The missing piece is how to acquire the required minutes_book_id.

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 the description must compensate, and it defines limit (capped at 200), offset (pagination), and include_procedural (adds entries naming no bill). The required minutes_book_id is left unexplained, presumably obtained elsewhere, which is the one 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+resource and scope: one minutes book listing every action a chamber or committee took that day, in order. It explicitly contrasts its vote_id semantics with get_bill_history and routes to get_roll_call, so an agent can tell it apart from sibling vote tools without opening a schema.

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?

Clearly implies the context (day's action log) and names the alternatives get_bill_history and get_roll_call with the condition for using them. It explains include_procedural's effect, but never states the prerequisite of obtaining minutes_book_id from list_minutes_books, nor 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, 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, the description carries the full burden and does disclose useful semantics: events are ordered oldest-first and the named milestone labels are explained, plus what projected_date means. However it says nothing about read-only nature, auth requirements, or result shape beyond those field meanings, so it only partially covers behavior.

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, but the bulk of the prose is devoted to explaining return-value fields that an output schema already documents, while the callable input goes unexplained. It reads as informational rather than operational, with wasted allocation.

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 event/projected_date explanations are largely redundant, yet they occupy almost the entire description. Missing is the information an agent actually needs to invoke it: the meaning and source of session_code and how this differs from the sibling session 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% for the single required session_code parameter, and the description never explains what a session code is or its format. Since the schema does not compensate, the description should have, making this a real 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 leads with 'One session with its milestone dates: prefiling, convening, adjournment,' giving a clear verb (retrieve) and resource (a single session) with topical scope. It is distinguishable from list_sessions and get_current_session via the singular 'One session', though it never names those alternatives explicitly.

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 statement of when to use this tool versus get_current_session or list_sessions, and no prerequisites (e.g., where a session_code comes from). The agent must infer from the name alone that this is a single-record lookup by code.

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 and delivers rich behavioral context: row granularity (one row per chamber and type), an edge case (a type with no bills has no row), formula definitions (total = introduced + continued_from_last_session; passed = chaptered + vetoed), and multiple data-reliability caveats about the counts not matching the bill 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?

It is front-loaded with the tool's purpose, then row structure, then caveats, and each clause earns its place. The caveat list is dense but all of it is actionable for an agent deciding whether to trust the numbers.

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 return values need not be explained, and the description adequately covers behavior, edge cases, and reliability warnings. The only real gap is the unexplained `session_code` parameter, which keeps it from being 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 single `session_code` parameter, and the description never explains its meaning or format (it is an integer, not a human-readable session). The tool operates "for a session," but the parameter itself is left undocumented, so the description fails to compensate for the coverage 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 states a specific resource and scope: "LIS's own bill counts for a session, by chamber of origin and legislation type." It distinguishes itself from the sibling `list_bills` by framing itself as the aggregate count source rather than the bill list.

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 gives explicit when-not guidance (counts "do not always agree with the bill list") and names the alternative with the condition that selects it: "Count from list_bills when a number has to be exact." This is exactly the routing information an agent needs to choose between the two 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 full burden and largely succeeds: it discloses the 200-item limit cap, offset-based paging, case-insensitive substring matching, and the enumerated disposition values. It does not address auth requirements or whether the result is read-only, though the 'list_' prefix implies that.

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?

Front-loaded with a one-sentence purpose, then a paragraph that groups related parameters (chamber semantics, document_code, disposition, query, paging). The document_code example (HB1005AH1) and disposition list are dense but each earns its place; nothing reads as 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?

With no output schema, the description correctly compensates by describing the returned amendment fields (document_code, description, disposition). Combined with the parameter guidance and paging rules, an agent has enough to call and interpret the tool, with only session_code left implicit.

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, and it does for 4 of 5 parameters, including the non-obvious gotcha that amended_by selects the chamber that offered the amendment rather than the bill's own chamber. Only session_code is left unexplained, which is a minor omission given it is required and self-evident.

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 states a specific verb and resource with a scoping condition: 'Every bill in a session that carries an amendment, with its amendments.' This distinguishes it from the sibling list_bills by its amendment-only scope, though it never names that sibling explicitly.

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?

Usage is only implied through parameter semantics (use query to search, amended_by to filter by offering chamber). There is no explicit statement of when to reach for this tool versus list_bills, list_bill_versions, or get_bill_history, and no prerequisites or exclusions are given.

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 and does well: it discloses return ordering (newest first), that rows omit bill names, that reference is unique only within a session, and a hard pagination cap (limit 200) with offset paging. It does not mention auth requirements or the shape/fields of returned rows, but for a read-only listing tool this is solid disclosure.

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 core purpose is front-loaded in the first sentence, followed by compact detail on chamber, id routing, reference, and pagination. The illustrative example quote is helpful but slightly verbose; every sentence otherwise 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?

With no annotations and no output schema, the description supplies ordering, pagination limits, and partial return-row semantics (no bill names, unique reference). It stops short of describing full returned fields or auth requirements, but is largely sufficient 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?

Schema coverage is 0%, so the description must compensate and largely does: 'chamber' is defined as the sending chamber, limit is documented as capped at 200, offset is tied to paging, and reference uniqueness is clarified. session_code is only implied by 'in a session' rather than defined, leaving one 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 resource (inter-chamber communications in a session) with sorting behavior ('newest first') and explains the domain concept of a 'communication' precisely. It distinguishes itself from get_communication by noting the rows list no bills and that the sibling returns bill details. An agent can immediately tell what this returns versus its neighbors.

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 routes the agent to get_communication for bill-level detail by passing a communication_id, which is a clear alternative-selection rule. It implies session scoping via the required session_code and chamber filtering, but does not state when-not to use it or any prerequisites (e.g., API key). Clear context, one explicit alternative.

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 and does disclose meaningful behavior: rows contain no conferee names (a real data limitation), `limit` is capped at 200, and paging is done with `offset`. It still says nothing about authentication or the shape/size of returned rows, so it falls short of a 5.

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 lead sentence states the resource immediately, followed by a short definition, then parameter behavior. Every sentence carries information, though the conference-committee explainer is slightly more background than an agent strictly needs to invoke the tool.

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 no output schema and no annotations, the description covers what the rows represent, a known gap in the returned data, and pagination limits. It is adequate for invocation, though it could say more about the row fields returned or default ordering.

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, and it does for 4 of 5 parameters: chamber (chamber of origin), member_id (member's conference seats), limit (capped at 200), offset (paging). Only session_code is left unexplained, though it is required and self-evident.

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 concrete verb+resource: bills of a session that reached a conference committee, and defines what a conference committee is. This clearly separates it from siblings like list_bills, list_amended_bills, and list_most_viewed_bills, which list broader or differently scoped subsets.

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 real selection context: use `chamber` for chamber of origin and `member_id` to narrow to conferences a member sat on. It also routes the agent to a sibling (get_bill_history) for the conferee names this list deliberately omits. It does not state when NOT to use it, but the filtering guidance is strong.

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, the description carries the full burden and does well: it discloses the non-obvious, domain-specific behavior that the roster deliberately includes mid-session arrivals and departures, and that `service_end_date`/`service_end_reason` mark a departure. This is genuinely valuable context an agent could not infer from the schema. It remains silent on pagination/return cardinality and 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?

Front-loads the core purpose, then adds only the qualifiers that matter — query matching semantics, the mid-session inclusion behavior, and the member_id handoff. Every sentence carries information; nothing is padding.

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?

No output schema exists, yet the description still names the salient returned fields (service_end_date, service_end_reason, member_id), which an agent needs to interpret results. Missing are `session_code` semantics and any mention of result size/pagination, but for a filtered list tool this is nearly 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%, so the description must compensate. It does so for `query` (case-insensitive substring matching with concrete examples) but not for `party` (D/R/I), `chamber` (H/S), or the required `session_code`. The enum codes and session identifier are left entirely to the schema titles.

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 — the session's member roster — and names the three filters (name, chamber, party). It also tells the agent that `member_id` is the key for the member tools, which implicitly routes to siblings like get_member. It stops short of an explicit "use get_member for a single member" contrast, but the purpose is unambiguous.

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?

Gives a clear conditional for the main parameter ("omit it for the whole roster") and scopes the tool to a single session. It routes the agent toward the member tools via `member_id`, providing context for when to follow up. No explicit when-not-to-use statement, but the usage context is clear.

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 and does well: it discloses sort order (newest first), the Senate-only floor-book publication rule, that 'In Progress' status means the record can still change, that dates are inclusive, and that limit is capped at 200 with offset paging. It does not discuss auth or error behavior, but the substantive behavioral traits are covered.

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?

Dense and front-loaded with the core purpose in the first sentence, and every subsequent sentence adds routing or parameter detail. The prose is somewhat fragmented across short clauses, but there is little waste.

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 an 8-parameter, no-annotation, no-output-schema tool this covers most of what an agent needs: scope, ordering, filtering axes, dates, and pagination. The unexplained chamber alphabet and session_code are the only notable omissions, and no output schema means return shape is unstated.

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 and largely does: it explains committee (number or name, excluding all floor books), kind (floor vs committee), date format YYYY-MM-DD and inclusive semantics, limit cap of 200, and offset paging. It leaves chamber (H/S) and session_code unexplained, which is the remaining 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+resource ('The published minutes books of a session, newest first') and even defines the domain object ('a minutes book is the clerk's record of what one body did on one day'). It names the siblings it is not for House floor action (list_floor_calendars, get_bill_history), so an agent can route without opening another schema.

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 states when to use alternatives: read House floor action from list_floor_calendars and get_bill_history because only the Senate publishes floor books. It also routes forward ('Pass a minutes_book_id to get_minutes_book for the bills and votes') and explains how committee vs kind select subsets.

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 and does disclose real behavior: results are capped at 100, returned in LIS's own order (i.e., no caller-controlled sorting), and carry the same fields as search_bills. It does not say how limit interacts with the 100 cap or whether results paginate.

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 terse lines with zero filler, and the core identity of the list is stated first. Every sentence adds a fact: what it measures, the cap/ordering, and field parity.

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 two-parameter read tool with no annotations and no output schema, the description covers ordering, cap, and return fields adequately, but leaves limit semantics and session_code format unexplained. Reasonably complete, with a clear gap on the single optional parameter.

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 conveys the meaning of session_code indirectly ('bills of a session') but never explains the limit parameter, its default of 25, or its relationship to the stated 100-item ceiling.

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 resource and scope: bills of a given session ranked by how often LIS site readers open them. The clause 'measures public attention, not legislative weight' distinguishes it semantically from list_bills/search_bills, even though it doesn't name an alternative outright.

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?

No explicit when-to-use or when-not-to-use statement, and no alternative is named as a routing option. Usage is only implied by the semantic note that this reflects popularity rather than legislative importance, which lets an agent infer it is a 'what's trending' list rather than a search 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?

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.

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

With no annotations, the description carries the full burden and delivers: rows carry tally but no members, block votes name no bill, most voice votes are absent, classification 'Attendance' marks a quorum call, limit is capped at 200, and paging is via offset. These are exactly the coverage gaps, edge cases, and limits an agent needs before calling. Only auth/permission behavior is undisclosed.

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?

Purpose is front-loaded in sentence one and every following sentence adds a constraint, edge case, or routing hint rather than restating. It is dense with backtick-formatted field names and packs a lot into a short block, which costs a little readability but not correctness.

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 no output schema, so the description must describe returns, and it does: rows carry the tally and no members, with gaps for block and voice votes flagged. Combined with the parameter coverage, the only residual hole is the meaning of session_code. That is a single, contained gap in an otherwise complete definition.

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 the description must compensate, and it largely does: dates are YYYY-MM-DD and inclusive, end_date defaults to start_date yielding a single day, chamber is the voting chamber (so a row may name a bill from the other chamber), limit is capped at 200, and offset pages. Only session_code is left unexplained in both the schema and the description.

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 with its scope: 'Every vote a chamber took in a date range: floor, committee, and subcommittee.' That scope statement alone separates it from siblings like get_bill_votes or get_member_votes, which are bill- or member-scoped rather than chamber-scoped. An agent can place this tool without opening the schema.

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 gives real usage context ('Keep the range short, since a chamber takes about 50 votes on a session day') and names an explicit alternative with its trigger: pass a row's bill_number and vote_id to get_roll_call for member-level data. It stops short of when-not guidance against other vote-adjacent siblings such as get_bill_votes or get_bill_vote_tallies.

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 and does so well: it discloses LIS stop-word dropping ('"the" finds nothing'), that an unknown category returns the full valid list, that a bare keyword search includes failed bills while category/member_id filtering excludes failed and incorporated bills, and that limit is capped at 200 requiring offset paging. That is unusually rich 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?

Purpose is front-loaded and the three paragraphs map cleanly to purpose, parameter semantics, and return shape, with no filler sentences. It runs long, but the length is largely justified by ten undocumented parameters and no schema descriptions.

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 complex tool with no annotations and no output schema, the description supplies the return row shape (status, chapter, chief patron, holding committee) and the effect of include_summaries. It leaves the chamber filter and the meaning/source of session_code unexplained (no pointer to list_sessions), which is the main remaining gap.

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 the description must compensate, and it documents keyword syntax, search_in, category values, member_id scoping, chapter format (350 → CHAP0350), include_summaries, and the limit/offset interaction. The chamber parameter is never mentioned, and session_code is only implied by 'a session's bills', leaving two parameters semantically thin.

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 a precise verb+resource+facets ('Search a session's bills by keyword, stage, patron, or chapter number') and explicitly demarcates itself from the sibling list_bills ('only matches the number and the short description'). An agent can route between the two without opening either schema.

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?

States the selection condition against list_bills, explains that at least one of keyword/category/member_id/chapter is required, and clarifies the differing semantics of each route (keyword vs category vs member_id vs chapter). It also warns about LIS stop-word behavior so the agent does not mis-select this tool for common-word lookups.

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