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 a good job: it discloses that search_amendments is not full-text search, that the limit is capped at 250 for API compliance, that operations fail without required values due to the shared schema, and that text is unavailable before the 117th Congress. It does not cover authentication, rate limits, or offset/format behavior, but the most operation-critical behaviors are disclosed.

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 long but well-structured with labeled sections, bolded operation groups, and bullet lists, making the information scannable. Some content is repeated between the operations list and the required-parameters note, but the redundancy serves clarity rather than harming it.

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 11-parameter, multi-operation tool, the description covers operation selection, required parameter combinations, parameter semantics, and key API constraints. The only notable gaps are format and offset semantics and lack of default limit/pagination details; otherwise an agent has enough context to invoke 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?

The schema has zero descriptions for its 11 parameters, but the Args section explains 9 of them with concrete formats and allowed values, such as hamdt/samdt for amendment_type, YYYY-MM-DDTHH:MM:SSZ for dates, and updateDate+desc/asc for sort. This strongly compensates for the schema gap, though format and offset are omitted from the Args list.

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 (congressional amendments) and enumerates seven concrete operations grouped by function, such as get_amendment_details, get_amendment_actions, and get_amendment_text. This goes far beyond the title and lets an agent understand exactly what operations are available without inspecting schemas.

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 selection criteria within the tool, including which operations require congress, amendment_type, and amendment_number, and which do not. It also flags important limitations such as search_amendments being client-side and limited to 250 amendments, and get_amendment_text requiring congress >= 117. It does not explicitly contrast with sibling tools like bills or laws, so it stops short of a 5.

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 it delivers exhaustively: the recency_window_fallback mode and what a zero result means there, pagination quirks (pages can run short, bills can reappear across page boundaries, dedup advice), count semantics (total_version_matches vs results_count), date-bound semantics (version publication date, not update date), error cases (invalid_parameters, version_not_available), and AND-matching gotchas with a worked example. This is exemplary disclosure of non-obvious 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 structure is exemplary — clear section headers, a bullet-taxonomy of operations, a worked search example, and a trailing examples block — but the description is over-long and repeats the same bill_id-embeds-congress rule at least four times (FLEXIBLE BILL IDENTIFICATION, REQUIRED PARAMETERS, the Args section, and the Examples block). A critical rule merits emphasis, but the near-verbatim repetition inflates length without adding information; the description would be equally effective at roughly two-thirds of its 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?

For a 14-parameter dispatcher tool with zero annotations and a schema that provides only titles, the description covers everything needed for correct invocation: per-operation parameter requirements, exhaustive search semantics, pagination behavior, fallback semantics, date handling, and complete worked examples. An output schema exists for return values, so the terse 'Formatted results specific to requested operation' line is acceptable. Nothing an agent needs to call this tool correctly is missing.

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 every parameter, and it does: bill_id parsing rules with examples, congress examples (118/119), the full bill_type enumeration, limit's 250 max, page_token as an opaque verbatim cursor, sort's two allowed values, and fromDateTime/toDateTime format and meaning. It even warns that search_bills does NOT accept offset/sort/format despite those fields appearing in the schema — precisely the kind of disambiguation an agent needs when the schema is misleading.

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 this as the comprehensive bills interface and enumerates all operations in a structured taxonomy (Search & Discovery, Details & Metadata, Text & Content, Summaries, Relationships, Legislative Process, Date-Based). It explicitly names the sibling tools that own adjacent concerns — search_bill_text, get_bill_section, get_bill_toc — so an agent can immediately tell this tool apart from its siblings without opening their schemas.

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 routing guidance: 'for FULL bill text search/retrieval use the dedicated search_bill_text, get_bill_section and get_bill_toc tools' names the alternatives directly, and the SEARCH_BILLS section contrasts this tool's AND-matching semantics against search_bill_text's OR-matching semantics to steer the choice. The REQUIRED PARAMETERS section further specifies exactly which operation needs which parameters and what fails without them, leaving no when-to-use ambiguity.

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. It usefully discloses the shared-schema optionality trap and that operations will fail without required values, and it notes structured returns with metadata and chunking. It does not mention side effects, permissions, rate limits, or explicitly state that the operations are read-only.

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 long but well-organized with clear category headings, bullet lists, and a separated REQUIRED PARAMETERS section. Each section earns its place, and critical operational guidance is front-loaded. Some repetition of operation names exists, but it remains scannable.

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 unusual design of one shared schema over 19 operations, the description provides essential context: operation-to-parameter combinations, the fact that schema optionality is misleading, and that search/latest operations have different requirements. It does not cover value formats or deeper filtering semantics, but the output schema covers return structure and the operation guidance is strong.

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. The mapping of congress, chamber, report_type, jacket_number, committee_code, and event_id to specific operations adds substantial meaning beyond the schema. It still does not define allowed values or formats for parameters like chamber, report_type, or date range fields, but the operation-dispatch guidance is highly valuable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as providing congressional committee documents and activities, and enumerates the operations by category (reports, prints, meetings). It does not explicitly distinguish itself from sibling tools such as get_committee_reports, which also deals with committee documents, so it falls short of full differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The REQUIRED PARAMETERS section gives concrete operation-to-parameter mappings and warns that operations fail without the required values, which is strong usage guidance. It also clarifies that search and latest operations need none of those parameters. However, it does not address when to choose this tool over sibling tools like get_committee_reports.

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 fully carries the burden of behavioral transparency. It discloses critical behaviors: the max_bytes cap with clamping range, handling of structural containers (heading plus child descriptors when subtree exceeds max_bytes), the semantics of is_amendatory and amends, including the union behavior for multiple units and the limitations of amends (e.g., not resolving named Acts). It also explains how to interpret quoted language as amendatory. This is exceptionally transparent.

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 long but dense, with every sentence contributing technical detail essential for correct usage. It is front-loaded with the primary purpose and then systematically covers id resolution, output behavior, and amendatory interpretation. The structure is logical, though the length is substantial. Slight deduction for not using shorter paragraphs or bullet-like separation, but it's not 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?

Given the tool's complexity (multiple id types, max_bytes semantics, amendatory flags, container handling), the description is remarkably complete. It explains the return behavior, field semantics, and edge cases (e.g., non-unique bare section numbers, incomplete amends lists). Since an output schema exists, the description doesn't need to outline the full return structure, but it covers all operational nuances. This is a comprehensive description for a complex 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?

The input schema has 0% description coverage, so the description must compensate. It provides detailed semantics for section_id (how IDs resolve, examples) and max_bytes (UTF-8 bytes, clamping range, effect on output). It indirectly covers congress, bill_type, and number by framing them as part of bill identification, and version is not discussed but likely self-explanatory. While not all parameters are explicitly detailed, the most complex ones are thoroughly explained, providing solid added value 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 opens with a specific verb and resource: 'Retrieve the full statutory text of a single bill section -- or an addressable sub-section chunk.' It clearly differentiates from sibling tools by mentioning that it should be called after search_bill_text or get_bill_toc, and describes its role in the workflow. The purpose is unambiguous and distinct.

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 states when to call this tool: 'Call this after search_bill_text or get_bill_toc to read a specific section by its section_id.' It also explains ID resolution rules (fully-qualified, chunk IDs, bare section numbers) and describes behavior for containers. While it doesn't explicitly state when NOT to use it, the usage context is clear and directs the agent appropriately. Slight deduction for lacking explicit exclusions or alternative selection guidance.

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

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

With no annotations, the description carries the full burden. It fully discloses that the tool returns only structure, not text; explains depth clamping (1-5, default 2), the 500-node cap, and the two distinct incompleteness signals (depth_reduced and toc_truncated) along with the toc_note for depth needed. This is exceptionally transparent and goes beyond typical tool descriptions.

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 well-structured paragraph with no fluff. Every sentence contributes essential information: purpose, alternatives, behavior on depth/node cap, and the distinction between two incompleteness flags. It is front-loaded with the main purpose and then adds nuanced detail.

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 moderately complex with 5 parameters and an output schema. The description fully explains the tool's behavior and edge cases (depth clamping, node cap, truncation flags). The existence of an output schema reduces the need to describe return structure, but the description covers the key aspects of how to interpret the returned flags, making it complete for its role.

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 all five parameters. It only meaningfully describes 'depth' (default, clamp range, and its relation to depth_reduced). It does not explain 'congress', 'bill_type', 'number', or 'version', relying on standard bill-identification context. This is insufficient given the low coverage.

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 a shallow table of contents (divisions, titles, subtitles, sections) for a bill's statutory text, and explicitly distinguishes it as a navigation aid for discovering section_id values to use with get_bill_section or search_bill_text. It also contrasts with other bill-related tools by specifying it returns only structure, never the 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 explicitly says when to use this tool (as a navigation aid) and when not to use it (not the answer path). It names the alternative tools for retrieving sections or searching text, and explains the depth and node cap behavior with flags like depth_reduced and toc_truncated, giving clear guidance on interpreting results.

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 burden of behavioral disclosure, and it does a good job: it explains that the endpoint is oldest-first and that most_recent works by fetching the final page. It also clearly describes pagination parameters. It does not mention permissions, rate limits, or error behavior, but the core call mechanics are transparent.

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 line is a single, precise sentence, and the Args section is a clean bullet-style list with no filler. Every sentence contributes actionable information, and the behavioral note about most_recent is economical.

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 has an output schema, so the return format does not need explanation, and the description covers all parameters plus a non-obvious endpoint ordering quirk. The only gap is lack of guidance on how this relates to the many similar bill/committee tools, but that is more of a usage-optimization concern than a correctness blocker.

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%, yet the description provides meaningful semantics for every parameter: committee_code gets an example, chamber gets allowed values and inference behavior, limit/offset get paging meaning, and most_recent gets a behavioral explanation. This fully compensates for the schema's lack of parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb-resource pairing: 'Get bills referred to or reported by a specific committee.' This clearly distinguishes the tool from siblings like get_committee_reports or search_bill_text while still being immediately 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?

The description gives useful invocation details such as committee_code format, chamber auto-inference, and pagination semantics, but it does not state when to prefer this tool over alternatives or when not to use it. It is clear enough for a straightforward database lookup, but lacks explicit routing guidance among the large sibling set.

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 burden of disclosing behavior. It does disclose pagination semantics (offset is 0-based), the default ordering behavior (most_recent=True returns newest first), and automatic chamber inference. However, it does not mention potential errors, data availability limitations, or whether the operation is strictly read-only, though 'Get' implies this.

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 well-structured with a one-sentence purpose statement followed by a compact Args list and Returns line. Each line adds useful information, and there is no padding or repetition of the schema.

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, the description does not need to detail return fields. It covers all five parameters, provides defaults and inference behavior, and includes a clear return description. It is sufficiently complete for an agent to invoke the tool correctly, though it could add a small note about when the committee_code format may be invalid.

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 by explaining committee_code with concrete examples, describing chamber inference behavior, and clarifying limit, offset, and most_recent semantics beyond the bare schema definitions. This adds real meaning to every 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 states a specific verb ('Get'), a clear resource ('communications (letters, statements)'), and a specific scope ('from a specific committee'). This distinguishes it from sibling committee tools like get_committee_bills and get_committee_reports, which target different resource types.

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 intended use is implied by the title and description: call this when you need communications from a specific committee. However, the description does not explicitly mention alternatives or provide when-to-use versus when-not-to-use guidance against the many sibling committee 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 burden of explaining behavior. It does disclose that the tool returns a list, orders by most_recent by default, and supports offset-based paging, which is useful. However, it does not explicitly state read-only/no-side-effect behavior, authentication requirements, or failure modes, though 'Get' strongly implies a 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 well-structured with Args and Returns sections. It front-loads the core purpose and every line adds useful information, with only minor boilerplate like 'ctx' being unnecessary for an agent.

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 low complexity, existence of an output schema, and full parameter coverage, the description provides enough context for an agent to invoke the tool correctly. It could mention how to find valid committee codes or note API limits, but those are not essential gaps.

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 explains committee_code with concrete examples, limit as a maximum count, offset as 0-based paging, and most_recent default sorting behavior, fully compensating for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get') and the resource ('nominations referred to a specific committee'), and the title reinforces the committee scope. However, it does not explicitly differentiate itself from sibling tools like get_committee_bills or voting_and_nominations, though the resource is distinct enough.

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 no guidance on when to use this tool vs alternatives, no exclusions, and no mention of related tools like search_committees for finding valid committee codes. Usage context is only implied by the tool's name and description.

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 burden of behavioral disclosure and does so well: it explains that chamber is inferred from the committee_code prefix when omitted, that most_recent defaults to True and returns newest reports first, and that offset is zero-based for paging. These details go beyond simply saying 'get reports'.

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 well structured into Args and Returns, with each parameter on its own line and no unnecessary prose. The inclusion of 'ctx' is slightly extraneous, but overall the description is economical and easy to scan.

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 annotations and zero schema description coverage, the description covers all parameters, defaults, and paging behavior, while the output schema handles return expectations. The main gap is the lack of explicit guidance on when to choose this tool over the committee-related siblings, and how to discover an official committee_code if unknown.

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 strongly by explaining every input-schema parameter: committee_code with examples, chamber values and inference, limit, offset, and most_recent's default sorting behavior. However, the description also includes a 'ctx' argument that is not present in the input schema, which is a minor inconsistency.

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 'Get reports issued by a specific committee,' a specific verb and resource, and the title reinforces that these are reports published by a committee. This clearly differentiates it from sibling tools like get_committee_bills, get_committee_communications, and get_committee_nominations by naming the distinct resource type.

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 a clear use case but does not explicitly mention when to prefer this tool over alternatives or when not to use it. With siblings like get_committee_bills and get_committee_communications nearby, the absence of any exclusion or alternative routing leaves the usage guidance implied rather than 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?

No annotations are present, so the description carries more weight. It discloses the read-only nature through the verb 'Get' and the 'Returns' section, and it exposes pagination behavior via offset and limit. However, it does not explicitly confirm no side effects, mention permissions, or describe any error/rate-limit 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 description is compact, well-organized into Args and Returns sections, and the core purpose is front-loaded in the first sentence. Every section earns its place with 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 simple read-only lookup, the description is nearly complete: all user-supplied parameters are described and the output schema covers return shape. The main gap is that it doesn't explicitly route the agent to get_member_sponsored_legislation when sponsored bills are needed, and the mention of 'ctx' might be slightly confusing since it is not in the input 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?

The input schema has 0% property descriptions, but the description fully compensates by explaining all three parameters: bioguide_id is the unique member identifier, limit is the maximum number of bills, and offset is zero-based pagination. This adds meaningful semantics beyond the raw JSON 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 opens with 'Get legislation cosponsored by a specific member of Congress,' which names a specific verb, resource, and scope. The use of 'cosponsored' clearly distinguishes this from sibling tool get_member_sponsored_legislation.

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 the tool should be used when the agent needs bills/resolutions cosponsored by a particular member, but it does not explicitly state when to use this tool versus alternatives like get_member_sponsored_legislation. There are no exclusions or when-not-to-use conditions.

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 does disclose the return behavior ('detailed member information including biographical data, terms served, etc.') and the 'Get' verb implies a read operation. However, it does not mention error behavior, data limitations, or any other non-obvious 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?

The description is short and organized into Args and Returns sections, making the purpose easy to scan. The inclusion of 'ctx' as an argument is unnecessary and potentially confusing, and the Returns section repeats some of the opening phrasing, but overall 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 a one-parameter read-only tool, the description is minimally adequate and an output schema is present. However, given the large sibling list, the description would benefit from explicit guidance on when this tool is the right choice versus get_members_by_congress, search_members, or other member-related 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?

The description adds useful meaning for bioguide_id by calling it 'Unique bioguide identifier' and providing an example, which goes beyond the bare schema. However, it also lists 'ctx' as an argument even though ctx is not in the input schema, which could mislead an agent into passing an invalid 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 clearly states a specific verb and resource: 'Get detailed information about a specific member of Congress.' The phrase 'specific member' helps distinguish it from list-oriented siblings like get_members_by_state or search_members, though it does not explicitly name or contrast them.

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 guidance is given about when to use this tool vs. alternatives. There is no mention of using search_members if the bioguide_id is unknown, or using get_member_sponsored_legislation for sponsored bills. The intended use is only implied by the tool name and the required parameter.

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 were provided, so the description carries the full burden of behavioral disclosure. It only says it returns a list and gives basic argument explanations; it does not clarify semantics like current_member=null vs false, pagination behavior, limit bounds, or the read-only nature of the 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-loads the core purpose before listing arguments and return type. The Args block partially duplicates the schema, but it adds useful explanatory text rather than just restating names, so the structure is appropriate and not bloated.

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, the return value does not need more explanation. However, with no annotations and minimal behavioral guidance, the description is only minimally complete for a three-parameter tool; missing edge-case semantics and alternative routing keep it from being fully contextual.

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 parameter explanations in the description are valuable: congress gets an example (118), current_member is clarified as filtering to only current members, and limit is defined as a maximum. This compensates well for the schema's lack of descriptions, though it adds little about defaults, bounds, or null behavior.

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 ('Get'), a clear resource ('members'), and a precise scope ('served in a specific Congress'). This cleanly differentiates it from sibling tools that get members by state, district, or combined congress/state/district.

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 usage context is implied by the name and description: use this when you need members for a particular Congress number. However, there is no explicit guidance about when to prefer this tool over nearby siblings, nor any conditions or exclusions, so it stays at the implied level.

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 explains the current_member filter default and states that a single member is returned, which is useful. However, it does not describe behavior when current_member is false, potential error cases, or whether historical members are included by default.

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 well-structured with a clear one-sentence purpose, an Args block, and a Returns line. It is efficient, though the 'ctx' entry is an implementation detail not present in the schema and adds little for the agent.

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 straightforward lookup tool with an output schema available, the description covers purpose, parameters, defaults, and the return concept. It could be more complete with explicit guidance on choosing this over sibling get_members_by_* tools, but nothing essential to making the call is missing.

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 fully compensates by explaining each parameter: congress with an example, state_code with example values, district as the district number within the state, and current_member with its default meaning. This is exactly the added semantic value the schema lacks.

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 ('Get'), a clear resource ('the member representing a specific congressional district in a specific Congress'), and the exact combination of filters. This clearly distinguishes it from siblings like get_members_by_congress, get_members_by_state, and get_members_by_district, which each cover only a subset of these filters.

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 first sentence communicates exactly when to use this tool: when a single representative for a specific district in a specific Congress is needed. It does not explicitly contrast with sibling tools, but the precise scope and the sibling names make the intended 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 is the only source of behavioral disclosure. It does disclose the default current-member behavior and that the result may be 'Member(s)', implying multiple historical results are possible. It does not cover edge cases, ordering, or the semantic difference between current and historical results beyond that parameter.

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 a clear one-line purpose. The Returns line is largely redundant with the first sentence and output schema, but the overall structure is efficient.

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 and has an output schema, so basic invocation is covered. The missing differentiation from get_members_by_congress_state_district and the ambiguity over historical 'served' members mean an agent may not know which tool to select for a specific Congress query.

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%, but the Args section supplies the missing meaning: state_code format with examples, district scope, and current_member semantics. Every non-context parameter is explained well enough to construct a correct call.

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 and resource: getting the member for a state_code/district pair. It is not a tautology and the scope is concrete. However, it never differentiates itself from sibling get_members_by_congress_state_district or explains whether historical members are included, so it stops short of full distinction.

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 'when to use' vs alternatives, and no mention of the sibling tool get_members_by_congress_state_district for congress-specific queries. The only contextual signal is the current_member default, which says little about choosing this tool over get_members_by_state or get_members_by_congress. This is effectively no 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?

With no annotations, the description carries the behavioral burden. It explains the current_member flag's effect (only show current members, defaulting to true) and that the call returns a list, giving the agent a clear read-only mental model. It does not discuss ordering, pagination, or invalid-state handling, but for a simple list endpoint this is 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?

The description is tight: a one-sentence summary, a labeled Args block with one line per parameter, and a one-line Returns note. No filler or duplicated schema noise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple three-parameter tool with an output schema, all parameters and the current/historical toggle are documented. The only notable omission is guidance on when to pick this over get_members_by_district or get_members_by_congress, but the state_code resource and sibling names make the distinction mostly recoverable.

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. It does: state_code is documented as a two-letter code with examples, current_member is given meaning and its default, and limit is clarified as the maximum number of returned members. The nullable current_member behavior is not elaborated, but the core 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?

States a specific verb and resource: 'Get members of Congress from a specific state.' Title adds 'Current or historical representatives,' clarifying the main filtering dimension and distinguishing it from district- or congress-scoped siblings.

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 it should be used when members need to be retrieved by state_code, and the current_member parameter indicates a current-vs-historical choice. However, it never names or contrasts the many sibling member-lookup tools (by district, by congress, by congress+district), leaving the agent to infer when this tool is preferred.

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

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

There are no annotations, so the description carries the behavioral disclosure burden. It communicates that this is a read-only 'Get' operation and reveals pagination behavior through the limit and offset arguments, but it does not explain ordering, scope (e.g., all congresses or current congress), or any error/limit 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 description is tightly written: a one-sentence purpose, a brief argument list, and a short return note. No filler or redundant material appears, and the key distinction is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple paginated list tool with an output schema, the description covers the essentials: the member identifier, pagination parameters, and the return type. It could be slightly more complete by explicitly routing users away from the cosponsored sibling or noting historical scope, but nothing critical is missing.

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 explains all three schema parameters: bioguide_id as a unique identifier, limit as maximum number of bills, and offset as zero-based pagination. This adds meaning beyond the bare input schema, though it lacks deeper format or boundary details.

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 uses a specific verb and resource: 'Get legislation sponsored by a specific member of Congress.' This clearly distinguishes it from the sibling tool get_member_cosponsored_legislation by emphasizing 'sponsored' rather than 'cosponsored.'

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: use this when you need bills and resolutions sponsored by a specific member. It does not explicitly name alternatives or state when not to use it, but the purpose is unambiguous and the sibling tool name reinforces the sponsored-vs-cosponsored distinction.

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, and the description does not mention whether the tool is read-only, has side effects, rate limits, or error handling. While it implies retrieval, it does not explicitly state behavioral constraints.

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, using a title, short summary, and then structured lists for operations, arguments, and examples. No redundant information is present, and all parts are relevant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the available operations, all parameters with their roles, and provides examples for both operations. It does not explain output structure, but given the presence of an output schema, this is not critical. However, it lacks explicit notes on edge cases or error scenarios, so it is 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?

The description adds meaningful context to the parameters: it specifies which parameters are required for each operation (e.g., law_number required for get_law_details), explains the default for limit, and clarifies the purpose of offset. This goes beyond the schema's bare types and defaults.

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 deals with enacted public and private laws, distinguishing it from sibling tools that handle bills, amendments, etc. The operations 'get_laws' and 'get_law_details' are clearly listed, 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 does not provide guidance on when to use this tool over alternatives, such as when to retrieve laws versus bills or amendments. It gives examples but no contextual usage scenarios or decision criteria.

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 explains the shared-schema quirk, states that operations fail without certain values, and mentions that it returns structured record/hearing data with full text content. It does not discuss pagination, authentication, or rate limits, but the read-only nature of the operations is strongly implied by the search/get operation names.

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 well-structured with clear section headers and bullet lists, and the required-parameters section earns its length because it resolves a critical schema inconsistency. It is longer than ideal and contains some redundancy and ambiguous shorthand, but the complexity of a multi-operation dispatcher tool justifies most of the detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers operation families, required parameter combinations, and return data, which is substantial for a tool with 17 params and 16 operations. However, exact operation-name derivation is not fully unambiguous from the slash notation, and several parameters remain undocumented. An agent could still struggle to construct a valid operation string with confidence.

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 map required parameter combinations to specific operations and highlights key params, which is valuable. However, several schema params (sort, limit, from_date_time, to_date_time, issue_number, volume_number) are not explained, and the slash notation leaves exact operation string values ambiguous in places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as an access point for congressional records, communications, and hearings, and enumerates the operation families. It distinguishes this tool from bill/member/committee tools by its domain focus, though the slash-separated operation shorthand (e.g., search_congressional_record/daily/bound) creates some ambiguity about exact operation names.

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 guidance on which parameters are required for which operations, and warns that operations fail without them despite the schema marking all parameters optional. It does not explicitly route users to sibling tools, but the operation-family breakdown and required-parameter table provide strong within-tool usage direction.

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. It discloses two important non-obvious behaviors: the schema falsely marks everything optional but operations actually require specific values, and search_crs_reports only searches 'the 250 most recently updated reports (not full-text)' unless an exact report_number is provided. This is genuinely useful context beyond the schema, although it does not cover every behavioral detail.

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 well-organized with headers and bullet lists, but it contains redundant filler: the first line repeats the tool title, and 'Returns professional-grade research data with enhanced analytics and historical insights' adds no operational value. It is readable but not 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?

For a 10-parameter dispatcher tool with no parameter descriptions in the schema and no annotations, the description is incomplete. It gives strong operation-level routing and flags the required-parameter trap, but the semantics of most parameters remain unexplained, making correct invocation uncertain for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description needed to compensate, but it only explains keywords and report_number for operation selection. The 'Key params' line names congress, start_year, and end_year without saying what they mean or how they affect results, and limit, current, detailed, and format_type are never explained at all.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool's domain: 'Access CRS reports and enhanced Congress analytics,' then enumerates the four supported operations with one-line behavioral summaries. It effectively distinguishes the sub-operations within the tool, though it does not explicitly contrast against the many sibling congressional tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The REQUIRED PARAMETERS section gives concrete invocation guidance, mapping operations to the parameters they need and warning that operations 'fail without the values below.' It provides clear context for choosing between the four operations, but it never explicitly states when a sibling tool should be used instead, stopping short of a 5.

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 burden and excels: it discloses literal-phrase-with-stemming matching, zero-hit diagnostics (verdicts 'phrasing' vs 'absent_term'), the meaning of 'quoted' in match_contexts, and the incompleteness of the amends list. It even explains stemmed tokens in 'terms'.

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 long but each paragraph addresses a distinct nuance: matching semantics, diagnostics, bill-location trap, quoted/amends caveats, and max_hits clamping. It is well-structured, front-loaded with the core purpose, and 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?

Despite having an output schema, the description thoroughly covers tool behavior, query semantics, output interpretation (match_contexts, query_diagnostics, amends), and parameter constraints. It preemptively addresses edge cases and likely agent mistakes, making it complete for a complex search 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?

With 0% schema description coverage, the description adds critical semantics for 'queries' (literal phrases, stemming, synonyms) and 'max_hits' (clamped 1-50). However, 'congress', 'bill_type', 'number', and 'version' are not explicitly explained, though their names and context make them reasonably clear. It partially compensates but not fully.

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-text search of a bill's statutory text', a specific verb and resource, and further explains it returns matching sections with U.S. Code and Public Law citations. This clearly distinguishes it from sibling tools like get_bill_section and get_bill_toc by its retrieval modality.

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 states 'Use this to answer "what does bill X say about Y" without reading the whole bill', providing a clear when-to-use. It also warns 'Call the tool instead' for bill-location questions, and gives detailed query-construction advice (literal phrases, synonyms), effectively communicating when not to rely on prior knowledge.

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 takes on the full behavioral burden. It clearly states the search-or-list behavior, optional filtering, limit semantics, and that it returns 'a list of matching committees with basic information.' It could disclose more about pagination or sorting, but the core behavior is transparent.

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 well structured with a front-loaded purpose sentence and a compact Args/Returns format. The only minor waste is the 'ctx: Context for API requests' line, which is not an actual schema parameter and adds little value for an MCP agent.

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 5-parameter search tool with an output schema present, the description covers the main usage modes and return shape. It lacks detail on sort order or pagination behavior, but the existing coverage is enough for an agent to select and call the tool correctly in most cases.

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. Every parameter is meaningfully explained: keywords behavior, chamber examples, committee_type examples, congress example with 119, and limit as a maximum count. This substantially exceeds what the bare schema provides.

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 action and resource: 'Search for / browse congressional committees.' The title and parameter list further clarify that it finds committees by chamber and type, which cleanly separates it from sibling tools like search_bill_text and search_members.

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 useful behavior guidance such as 'When omitted, lists committees (optionally filtered by chamber/type),' which clarifies search vs browse usage. However, it does not explicitly mention when not to use this tool or name any alternative tools for different committee-related tasks.

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 burden of behavioral disclosure. It does disclose partial name matching, a current_member filter, and a limit, which is useful. However, it omits important behavior such as how criteria combine, what happens when no criteria are supplied, pagination behavior, and what 'structured response' means in practice.

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 Args list is mostly earn-worthy and the overall structure is readable. However, it includes 'ctx: Context for API requests', which is not an actual input parameter and adds noise. The Returns section is generic but harmless. Slightly tighter editing would improve it.

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 8 optional parameters and a large sibling family, the description is incomplete. It does not explain when to prefer this search tool over the more specialized get_members_by_* siblings, nor does it explain behavioral nuances like empty searches or result ordering. The output schema covers return shape, but routing and invocation context remain underexplained.

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 schema description coverage at 0%, the description must compensate, and it does: each parameter is listed with a meaningful explanation, including examples for state codes, accepted party values, chamber names, and partial name matching. This adds real value beyond the bare schema. It could be improved by clarifying whether multiple criteria are ANDed or ORed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as searching for members of Congress using a verb and resource, and the title reinforces that it finds representatives and senators by criteria. It is reasonably distinct from the sibling get_members_by_* tools, though it does not explicitly name or contrast them.

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 no guidance on when to use search_members versus the many sibling tools like get_members_by_congress, get_members_by_state, or get_member_details. The phrase 'by various criteria' hints at flexibility, but the agent is left to infer the intended selection logic.

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 usefully disclose that the schema marks every parameter optional while certain operations fail without congress and treaty_number. It also surfaces the max limit of 250 for API compliance and sort/date format expectations. It does not address read-only status, auth, or error behavior, but it adds substantive operational 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?

The description is well-structured and front-loaded with purpose, but the operation list is repeated almost verbatim in the 'TREATIES OPERATIONS' and 'TREATIES/SUMMARIES' sections. This redundancy adds length without new information, though the rest of the structure is organized and scannable.

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 13-parameter, multi-operation router with an output schema, the description covers the operation dispatch model, required parameter combinations, API limits, and date formats. The main gaps are unmentioned format/offset parameters and lack of sibling routing guidance, but the core calling contract is well explained.

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 the Args section defines 11 of 13 parameters with concrete meaning, including congress numbering, keyword/topic/bill_type filters, limit, and date format. It omits format and offset and is vague on treaty_suffix, but overall it provides far more parameter context than the bare 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 tool as focused access to treaties and bill summaries and enumerates five specific sub-operations with one-line purposes. It is distinguishable from sibling bill, law, and member tools by its domain, though the verb 'access' is somewhat generic for a multi-operation router.

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 operation-specific parameter requirements but gives no explicit guidance about when to prefer this tool over siblings such as search_bill_text, bills, or laws. There are no when-to-use or when-not-to-use statements relative to alternatives, leaving routing decisions to inference.

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 warns that the schema marks all parameters optional but operations actually fail without required values, and it explains that operations return structured vote/nomination data. This is valuable beyond the schema, though it does not cover error conditions or pagination.

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 long but well-structured with sections, bullet lists, and bolded categories. Every section earns its place, and the critical warning about optional-looking required parameters is prominent. The format makes the 13 operations and their parameter requirements easy to scan.

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 11 parameters and no annotations, the description provides enough operational context to select an operation and know which parameters are required. The output schema exists, so return-value details do not need to be described. Minor gaps remain around exact parameter formats and operation string values, but overall this is a complete enough 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 description coverage is 0%, so the description must compensate. It lists key parameters and maps required parameter combinations to operations, which is genuinely helpful. However, it leaves several parameters (sort, limit, from_date, to_date, keywords) without any semantic detail beyond their names.

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 explicitly states the tool provides access to House votes and presidential nominations, then enumerates all 13 operations by category. This clearly distinguishes it from sibling tools focused on bills, members, committees, and treaties.

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 ('Access House votes and presidential nominations') and provides operation-specific required parameter mappings. It does not explicitly name when to prefer a sibling tool over this one, but the scope is well-defined and the operation breakdown is practical.

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