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

Beyond the readOnly/non-destructive annotations it discloses two useful traits: the call does not trigger generation, and changed evidence is flagged stale in the result. The auth requirement ('OAuth or a scoped token') is also stated, which annotations do not cover.

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?

Four short sentences, each carrying distinct information (no regeneration, planId default, id source, stale marking, auth). The default behavior is front-loaded; nothing is padding.

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 should say more about what the returned set contains, and it never explains candidateId, a required parameter. It is sufficient to call the tool correctly in the common case but leaves meaningful gaps for a three-parameter read.

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%, and the description compensates only for planId (omit for latest, source it from list_interview_question_sets). candidateId is required but never explained in the description or schema, leaving a real gap that the low coverage demands be filled.

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 ('Read') and resource ('a prepared set' of interview questions) and immediately distinguishes it from the generating sibling ('without generating again'). It also points at list_interview_question_sets as the id source, making it separable from sibling 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?

Gives concrete invocation guidance: omit planId to fetch the latest set, or pass an id obtained from list_interview_question_sets. It stops short of explicitly naming prepare_interview_questions as the alternative for generating, leaving that inference to the reader.

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