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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine behavioral context—what the payload contains (alt text on figures, response kinds, whether a calculator is allowed, a deep link) — which tells the agent what to expect without a separate output 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?

Two sentences: the first front-loads the resource and its payload, the second resolves the only ambiguous parameter choice. The long field list is dense but every item is returned content the agent would otherwise have to discover by calling.

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 appropriately enumerates return fields, and the four parameters are covered by schema plus the question/part note. It stops short of describing failure behavior for an invalid paper_id or a part that doesn't exist, which would matter for a lookup 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 coverage is 100%, giving a baseline of 3, and the description adds real meaning by clarifying the question-vs-part relationship: 'question' returns the whole item while 'part' narrows to one sub-part such as 3(a)(i). That relationship is not spelled out in the schema itself.

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 names a specific verb and resource ('The text of one question or part from an exam.now past paper') and enumerates the returned content: prompt, marks, figures, answer surface, topic codes, link. This makes it distinguishable from get_paper (whole paper) without naming 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 guidance is limited to the parameter distinction 'Pass question for the whole question or part for one part', which is more about invocation than when-to-use. It never states when to choose get_paper or find_questions_by_topic instead, so the agent must infer the selection rule from the sibling names.

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