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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuine behavioral context beyond that: membership is 'bounded', results carry truncation state, and the tool is explicitly not a prerequisite for the broader List activity research flow.

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 tight sentences, front-loaded with the core verb+resource and followed by the scoping caveat. Dense but every clause carries information about scope or exclusions; 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 6 parameters at 33% description coverage, the definition leaves the agent guessing about pagination mechanics and the request_id/after_id contract. The revision-continuation semantics live only in the schema, and return shape is only gestured at via 'revision and truncation'.

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 only 33% (limit, after_id and request_id are undocumented), so the description carries extra burden. It partially compensates by invoking 'bounded' membership, 'truncation' and 'revision' — which map loosely to limit/revision/section — but adds nothing for after_id or request_id.

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 gives a specific verb and resource ('Read a selected saved List's bounded membership, pins and saved-query references') and explicitly scopes it as metadata inspection. It distinguishes itself functionally from saved-query execution and List editing, though it never names the neighboring list_lists tool that an agent would use to discover a list_id.

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 states clear exclusions — 'not saved-query execution, List editing or a prerequisite for List activity research' — which steers the agent away from plausible misuses. What's missing is the positive routing: no mention that list_lists should be called first to obtain the required list_id.

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