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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value by disclosing the shape of the returned content (framework, model answer, follow-up, common mistake, 1-5 rubric), which is important since there is no output schema. It doesn't say what happens for an unknown id, which keeps it from a 5.

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?

A single sentence with zero filler, front-loaded with the operation and followed by the enumerated return contents. Every clause earns its place.

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 correctly compensates by listing what comes back, which is the main thing an agent needs. The only gap is behavior on an invalid or missing id, minor for a read-only single-parameter lookup.

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% and the schema already gives the same example ids (aie-026, ib-071). The description's 'one question id' reinforces the single-id constraint but adds no format, validity, or lookup semantics beyond the schema, so the baseline 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 (return a step-by-step answer framework for one question id) and enumerates exactly what the payload contains: framework, model answer, follow-up, common mistake, and rubric. This is clearly differentiated from siblings like get_questions, search_questions, and random_drill, which operate over sets of questions rather than a single 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?

The phrase 'for one question id' implies the usage condition (call it once you already know the id), but no sibling is named and there are no explicit exclusions or prerequisites. An agent must infer that search_questions/get_questions are the way to obtain an id first.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds little beyond that — the include_answers and offset behavior it mentions is already in the schema — and it doesn't state the result count cap, ordering, or what a question object contains.

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, zero filler, front-loaded with the primary outcome and followed by the optional modifiers. Every clause maps to a real capability of the tool.

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 6-parameter read tool with 100% schema coverage and clear read-only annotations, the description covers purpose, filters, and paging adequately. The remaining gap is the return shape (no output schema exists), which the agent must discover at call time.

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%, with enums, defaults, and min/max bounds all documented per parameter. The description only restates role/topic/level/offset/include_answers without adding format or selection semantics, so the schema is doing all the work.

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 ("Return interview questions for a role") and enumerates the available filters and the paging mechanism. It's clear what the tool does, but it never distinguishes itself from siblings like search_questions or random_drill, so an agent must infer which retrieval tool fits.

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?

Implies usage through the filter list (role required, topic/level optional) but gives no explicit when-to-use guidance and no exclusions versus search_questions or random_drill. The agent has to guess whether this is the canonical browse/enumerate path.

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

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

Annotations already declare readOnlyHint and closed-world (openWorldHint=false); the description adds that the content is a bounded catalog of two fixed roles with per-level counts, confirming a static lookup rather than a search. It does not describe ordering or pagination, but none is implied for a two-role catalog.

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 short sentences, front-loaded with what is returned, then the action-driving guidance. Nothing redundant.

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?

No output schema exists, but the description covers the returned entities and their aggregation (counts by level), which is enough to call and interpret it. Only the exact response keying is unstated, a minor gap.

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% and the single enum parameter is fully documented with 'Omit for all roles.' The description restates the enum values but adds no filtering semantics beyond the schema, so baseline 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?

Specific verb (List) plus the exact resources (roles and topics in the question bank) with concrete example values and the return payload (question counts per Entry/Mid/Senior level). The 'call this first' note also distinguishes it from retrieval siblings like get_questions and search_questions.

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?

Explicit sequencing guidance: call this first to obtain valid topic ids, which effectively tells the agent this precedes get_questions/search_questions. It lacks an explicit 'don't use this to fetch questions' exclusion, so a 4 rather than 5.

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

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

With readOnlyHint/openWorldHint already covering the safety profile, the description still adds real value: results exclude answers, and passing the same seed replays an identical drill. It doesn't say whether questions can repeat within a drill or in what order they come back.

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, zero filler, and the core purpose plus the "no answers" constraint are front-loaded before the optional modifiers.

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 5-parameter, read-only tool with full schema coverage and no output schema, this covers what the agent needs to select and call it. The remaining gap is the shape of a returned question object, which isn't hinted at.

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 the enums are documented inline, so the parameters are already fully specified. The description restates topic/level/seed filtering without adding format or syntax detail beyond the schema, matching the baseline.

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?

Specific verb+resource ("pick n random questions") with an explicit scope qualifier: random sampling, no answers, for a timed mock round. Randomness cleanly separates it from search_questions/get_questions, and it names get_answer_framework as the complement.

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 a clear triggering scenario ("for a timed mock round"), notes optional filtering, and points to get_answer_framework for the answer side. It stops short of stating when NOT to use it (e.g., targeted practice should use search_questions).

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the description isn't required to cover safety. It usefully adds that this is keyword matching (not semantic search), but it says 'across questions and model answers' without noting that answers are only included when include_answers=true (default false), which could mislead about return content.

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?

A single front-loaded sentence with zero filler; the examples earn their place by illustrating query shape.

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?

Adequate for a simple search tool with fully documented params and no output schema, but it omits result-size behavior (n defaults to 5, max 20) and, more importantly, the conditional nature of answer inclusion, which matters for interpreting results.

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%, so the schema already explains query, n, role and include_answers; 3 is the baseline. The example keywords add a little intuition about query content but no syntax, matching behavior, or result-sizing details beyond the schema.

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+resource ('Keyword search across questions and model answers'), which cleanly separates it from listing tools like get_questions and list_topics. The examples reinforce the keyword-search intent, though it doesn't explicitly name a sibling as an alternative.

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 is implied by 'keyword search' versus the sibling listing/retrieval tools, but there is no explicit 'use this when...' guidance, no mention of when not to use it, and no named alternative (e.g. get_questions for browsing).

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