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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful context about the return values ('committee summaries (name, house, active status, ID)') and the recommended next steps, but it does not disclose any non-obvious behaviors (e.g., client-side filtering, pagination details) that are not already in the schema. Given the annotations, the description adds moderate value beyond structured data.

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 efficient, with only two sentences. It front-loads the primary purpose in the first sentence and packs follow-up guidance into the second, avoiding any fluff or redundant repetition of schema details.

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 a robust input schema (100% coverage), output schema, and comprehensive annotations (readOnlyHint, idempotentHint, destructiveHint), the description only needs to clarify the tool's role and workflow. It does so effectively, including the critical downstream step of passing committee_id to other tools, making it complete for the given complexity.

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 100%, meaning every parameter (house, limit, query, active_only) has a description in the input schema. The tool description does not add any additional parameter-specific semantics beyond what the schema already provides, so it meets the baseline of 3 without elevating.

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 ('searching or listing') and resource ('UK parliamentary select committees'), with clear filtering dimensions ('by name, house, or active status'). It also distinguishes itself by referencing downstream tools (committees_get_committee, committees_search_evidence), clearly separating its role from 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 opening instruction 'USE THIS TOOL WHEN' explicitly marks the intended use case. It also provides clear context by describing the follow-up workflow ('AFTER calling, pass committee_id into...'), but it does not explicitly name alternatives when this tool should NOT be used, though sibling tool differentiation is implied.

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