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

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint false, openWorldHint), so the description focuses on useful extras: results are ordered newest first, every witness is expanded with role and organisation, and each item carries transcript links rather than content. It also discloses provenance (UK Parliament Committees API) and cost (1 credit), which the annotations do not. Return-shape is described at a summary level but paging behaviour beyond 'take' is left to the schema.

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, return contents, and example questions are front-loaded in the first two sentences, with exclusions, provenance, and cost trailing as compact parentheticals. Every clause carries information; nothing is repeated from the schema or annotations.

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-only list tool with no output schema, the description adequately conveys what is returned and what is not, plus cost and source. The one residual gap is paging/volume behaviour when a committee has many sessions, which the description never touches and is only inferable from the 'take' schema field.

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 100% and both parameters are already documented, including the example '15x = Treasury Committee' and the take range/default. The description adds no syntax, format, or edge-case meaning for these parameters beyond restating that a committee id is needed, so the baseline of 3 applies.

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 ('List a committee's oral evidence sessions') and then enumerates exactly what comes back: meeting date, inquiry, every witness with role and organisation, and transcript links. It also marks its boundaries against adjacent resources ('Gives transcript links, not the transcript text or video'), so an agent can tell it apart from a transcript-fetching or bill-tracking sibling 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?

Supplies two concrete question shapes it answers ('when did the CEO give evidence', 'who has the committee questioned on X') and points to committee_search as the source of the required committee id, which effectively names a prerequisite tool. It does not give an explicit when-not rule or name a sibling to use for the transcript body beyond the negative 'not the transcript text or video'.

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