Server Quality Checklist

Tool Scores

• define_scopeB
  3/5.0
  Behavior3/5

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

  With no annotations, the description carries full weight. It discloses a notable behavioral trait: 'Enforces acyclic prerequisites and exclusion reasons in code', which adds value. However, it does not cover mutation/persistence effects, error behavior, or permission requirements, leaving gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, dense sentence that front-loads the core purpose. It avoids redundancy, though the long list of output components makes it slightly packed. Every clause earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 4-parameter tool with no output schema and no annotations, the description is too sparse. It mentions outputs but omits return structure, edge cases, and how inputs map to outputs. The enforcement note helps but does not compensate for the overall missing context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description does not explain any parameter meanings. It lists output components but not how inputs like materialsId, audienceLevel, explicitExclusions, or learningObjectives are used, forcing the agent to infer from names alone.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's verb ('Produce') and specific deliverable ('pedagogical Scope Contract'), enumerating its components. This distinguishes it from sibling tools like render_deck or plan_presentation by focusing on the scoping phase.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, typical workflow position, or exclusions for other planning tools, leaving the agent without context for selection.

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

• plan_presentationB
  3.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses that the tool returns a planId and what the plan contains (outline, time budgets, slide stubs, enrichment queries). However, it does not mention side effects like whether it creates or overwrites a plan, whether it requires existing materials/scope, or any rate limits. This partial disclosure is adequate but not comprehensive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no filler or redundancy. It front-loads the core action and output, making it easy to parse quickly. Every phrase adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 5 parameters, no output schema, and no annotations, so a robust description is critical. This description gives only a high-level overview and omits parameter semantics, prerequisites, and relations to sibling tools. It is inadequate for an agent to confidently invoke the tool without additional guessing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description does not mention any of the 5 parameters (style, scopeId, maxSlides, materialsId, targetDurationMin) and schema description coverage is 0%. It vaguely hints at time budgets and slide stubs but does not map these to parameters. The agent must infer meaning solely from parameter names, which for scopeId and materialsId is insufficient.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Build the section outline with per-section time budgets and slide stubs, plus enrichment queries (research gaps).' It also mentions the return value (planId). This distinguishes it from siblings like generate_deck or define_scope, as it focuses on planning the structure rather than final rendering or scoping.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing define_scope first) or postconditions (e.g., feeding into enrich_plan or render_deck). There is no explicit 'when to use' or 'when not to use' context.

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

• delete_deckB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden for behavioral disclosure. It does disclose the confirm:true requirement, which is a key safety guard, but it omits important details like irreversibility, required permissions, or success/failure behavior. This is a partial disclosure, not a complete one.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exactly two sentences with zero wasted words. It front-loads the purpose and immediately follows with the critical confirm constraint. Perfectly concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has simple parameters and no output schema, but the description still leaves gaps. It doesn't explain what happens on successful deletion, whether the action is permanent, or any error conditions beyond 'refuses.' For a delete tool, this is minimally adequate but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It adds meaning for the 'confirm' parameter by explicitly tying it to the refusal behavior, but it provides no detail on 'deckId' beyond what the name implies. This is insufficient given the lack of schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Delete') and resource ('a deck bundle'), clearly distinguishing it from sibling tools like get_deck and list_decks. It also adds a behavioral qualifier ('Refuses unless confirm:true') that further clarifies the action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives, such as get_deck for viewing or render_deck for presentation. The only hint is the confirm requirement, but that is a precondition, not usage context.

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

• pingB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description must fully disclose behavior. It mentions returning 'pong' but does not explain how the 'echo' parameter affects the response, leaving ambiguity about tool behavior when parameters are supplied.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that front-loads the core purpose and return value. Every word earns its place, making it appropriately sized for a trivial tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple health check, the core behavior is documented, and default invocation without parameters is clear. However, the omission of the echo parameter means an agent cannot fully understand optional usage, a notable gap given the absence of schema descriptions and output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema includes a single 'echo' parameter with no description and 0% schema coverage. The description does not mention the parameter at all, providing no guidance on its meaning, usage, or accepted values.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly defines the tool as a liveness/health check and specifies the return value 'pong'. This specific verb+resource phrasing naturally distinguishes it from sibling tools, which all deal with presentation tasks.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  States that it is a liveness/health check, implying its intended use for verifying server availability. No explicit alternatives are mentioned, but none exist among siblings, so the context is clear.

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

• generate_deckA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden. It discloses 'Long-running; emits progress,' which is a key behavioral trait, and it lists the produced artifacts. However, it does not disclose potential side effects (e.g., whether it creates or overwrites resources), idempotency, failure modes, or permission/cost implications. It adds some transparency beyond a bare statement but leaves many behavioral aspects undisclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core purpose ('The full generation...') and then enumerating outputs. Every word adds value, with no redundant phrases. It is compact and well-structured for quick parsing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex tool with 5 parameters, no output schema, and no annotations, the description is insufficient. While it lists the output artifacts and mentions long-running behavior, it lacks explanation of the input semantics, when to use it relative to sibling tools, and what the 'Scope-Guard' and 'Script-Sync' steps entail. The agent would struggle to invoke this tool correctly in many scenarios.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning the description explains none of the five parameters (planId, themeId, enrichmentId, includeQuizzes, quizEveryNConcepts). The description mentions outputs like 'scope ledger' but gives no hint of how these parameters influence generation. Since the schema itself lacks descriptions, the agent is left guessing about the meaning and effects of each parameter, which is a significant gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states this is 'The full generation: Draft → Scope-Guard → Render → Script-Sync,' which is a specific, multi-step process with a distinct resource (a Reveal.js bundle and associated artifacts). It names concrete outputs (presenter script, scope ledger, cost-report manifest), and the pipeline reference distinguishes it from the sibling 'render_deck' which likely only performs the render step.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this is the full-pipeline tool, especially with 'full generation' contrasted against 'render_deck', but it does not explicitly state when to use this tool over alternatives. It does not mention prerequisites such as first using 'plan_presentation' or whether a 'planId' must exist, nor does it provide any exclusions (e.g., 'use render_deck if you only need to render').

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

• enrich_planA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses that the tool performs server-side web search/fetch, respects a scope boundary and search budget, and that 'skip:true yields an empty report.' This is useful context. However, it does not mention side effects on the plan, return format, or permissions. The behavioral disclosure is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core function, and provides a key detail about the skip parameter without wasted words. Every phrase earns its place, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (3 params, no output schema, no annotations), the description covers the core function, constraints, and special skip behavior. It lacks details about the report's contents or whether the plan is modified, but these are not critical for basic usage. The description is sufficiently complete for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate. It explains the skip parameter ('skip:true yields an empty report'), which adds meaning beyond the schema. However, planId and maxSearches are not described; while their names are self-explanatory, the description does not clarify their exact semantics or constraints. The description only partially compensates for the lack of schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Research the plan's knowledge gaps with server-side web search/fetch.' This specifies the verb (research) and resource (plan's knowledge gaps), distinguishing it from sibling tools like define_scope or generate_deck. However, it does not explicitly name alternatives or contrast with siblings, so it falls short of a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context by mentioning 'within the scope boundary and a search budget,' suggesting it should be used after scope definition and with limited searches. However, it does not explicitly state when to use this tool versus alternatives or provide any exclusions. The guidance is implied rather than explicit.

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

• get_deckA
  3.7/5.0
  Behavior2/5

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

  No annotations exist, and the description doesn't disclose whether this is read-only, error behavior for missing IDs, or required permissions. It only lists 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One concise sentence, no fluff, front-loaded with the action and key result.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple getter with no output schema, it lists return components but omits error handling and read-only guarantees; sufficient but not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has zero coverage for deckId; the description adds that it identifies one deck but doesn't clarify ID format or origin, leaving the parameter's semantics partially inferred.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description specifies a clear retrieval action for one deck and lists the exact returned components (manifest, scope-ledger summary, bundle file paths), distinguishing it from list_decks and render_deck.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It implies usage when full details for a single deck are needed, but it doesn't explicitly state common alternatives or when not to use it. The context is clear enough for a basic getter.

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

• render_deckA
  3.7/5.0
  Behavior3/5

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

  Without annotations, the description carries the burden of behavioral disclosure. It reveals that 'pdf' returns a structured not-available error, which is helpful. However, it does not clarify whether the operation is read-only or modifies state, or any permissions required, so significant transparency is lacking.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is dense with information: it states the action, the resource, the optional theme, and the format limitation. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the main functionality and the pdf edge case, but it lacks explanation of what 'IR' stands for, what the output looks like, or any potential side effects. This is a moderately complex tool with 3 parameters and no output schema, so more detail would be useful.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate. It adds meaning for 'format' by noting pdf is Phase 3, and 'themeId' via 'optionally with a new theme'. However, 'deckId' is not explicitly explained beyond the word 'deck', leaving some ambiguity.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Re-render' and the resource 'stored deck from its IR', with an optional theme. It distinguishes from sibling tools like generate_deck by implying a re-rendering operation on an existing deck.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context that this is for re-rendering an existing deck and notes the pdf format is a Phase 3 limitation. However, it does not explicitly state when to use this vs. alternatives like generate_deck, or provide when-not-to-use guidance beyond the pdf caveat.

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

• ingest_materialsA
  3.9/5.0
  Behavior3/5

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

  Since no annotations are provided, the description carries the burden. It discloses a specific behavior (image-only PDFs are transcribed via vision) and a constraint (allowed roots), but it omits details about side effects, permissions, error handling, or whether it modifies files. The return of a materialsId implies some stored artifact, but that is not made explicit.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is only two sentences, immediately states the core action, lists formats, highlights a special case, and specifies the output usage. Every sentence contributes value without redundancy, making it efficiently scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the primary function, output, and even a special case, but it does not explain 'courseContext', error scenarios, or the exact nature of the materialId. Given the tool's moderate complexity and lack of output schema, more detail about return behavior and constraints would be needed for full completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers only 'paths' with a description; 'courseContext' is undescribed. The description adds useful context for 'paths' by enumerating supported file types and emphasizing 'allowed roots', but it completely fails to explain the purpose or format of 'courseContext', leaving a gap in parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Extract' with a clear resource 'text + topic inventory from source files' and lists supported formats. It distinguishes itself from sibling tools by focusing on ingestion and returning a materialsId for downstream use by define_scope/plan_presentation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies usage context: it processes source files within allowed roots and the returned materialsId is used by other tools, suggesting it is an initial ingestion step. However, it does not explicitly state when not to use it or name alternative tools, but the sibling list makes the distinction fairly obvious.

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

• rehearse_scriptA
  4.3/5.0
  Behavior5/5

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

  No annotations are provided, so the description must disclose all behavioral traits. It does so thoroughly: online dependency, error behavior (TTS_UNAVAILABLE, deck untouched), output files, rebalancing logic, and persistence of the effective WPM. This exceeds the transparency expected of a non-annotated tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but not bloated; each sentence adds a distinct operational detail (phase, process, output, error handling). It is longer than average but appropriate for a tool with multiple side effects, maintaining clear logical flow.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the absence of annotations and output schema, the description compensates well by specifying outputs, side effects, and error behavior. It falls short of a 5 only because it does not explicitly describe the shape of the immediate success response (the drift report), leaving that detail to inference.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 67% schema description coverage, the schema already documents voice and wpmOverride. The description adds context about their purpose (WPM drift model, Microsoft voice) but does not explicitly explain the required deckId parameter, which is only inferable from the phrase 'the deck's rehearsal/ dir'. Overall, the description offers moderate additional parameter meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool's function: synthesizing speaker scripts to audio via TTS, measuring durations, and producing a drift report. It uses specific verbs ('synthesize', 'measure', 'produce') and distinguishes itself from sibling tools by describing a unique Phase 3 rehearsal workflow with explicit artifacts.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear contextual usage: it's for Phase 3, rehearsal time only, and requires network access. It implicitly signals when not to use (offline) but does not explicitly name alternative tools or exclusion scenarios, so it falls short of a 5.

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

• generate_quizzesA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full responsibility for behavioral disclosure. It clearly states that the tool regenerates quiz slides and re-renders the deck, implying mutation of existing content. It also describes the distractor structure (misconception and groundedIn provenance), adding valuable context. However, it doesn't explicitly warn about overwriting existing quizzes or mention required permissions, so it's not 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences, each adding unique value: action, distractor details, and placement. No filler or repetition. The most important information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with two parameters and no output schema, the description covers the essential aspects: what it does, how it behaves, and where the results appear. It could mention the return value or more explicit parameter names, but overall it is quite complete for selecting and invoking this tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, but the description compensates well. It references 'every N core concepts' which maps directly to the everyNConcepts parameter and implies its purpose. 'EXISTING deck' implies the deckId parameter. It doesn't specify types or formats, but with only two simple parameters, this is sufficient.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Regenerate misconception-grounded quiz slides') on a specific resource ('an EXISTING deck') and also mentions re-rendering. This clearly distinguishes it from siblings like generate_deck (creates new decks) and render_deck (renders without generating quizzes).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear usage context: it operates on an existing deck and specifies placement ('after every N core concepts, before the section summary'). It implies the tool is for updating/refreshing quizzes rather than creating new decks, though it doesn't explicitly name alternatives or state when not to use.

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

• list_decksA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description must disclose behavior on its own. It does so by listing the returned fields (id, title, created, duration, slide count), making the response predictable. The verb 'list' implies read-only semantics, and no side effects are suggested, which is sufficient transparency for a simple read operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that conveys the tool's purpose and output fields without any wasted words. Every piece of information is essential.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless list tool with no output schema, the description fully covers the essentials: what it lists, the scope (all decks), and the return fields. No additional context (e.g., pagination, format) is needed given the simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the schema is trivially 100% covered. The description does not need to add parameter details. Per rubric, 0 params earns a baseline of 4, and no further information is necessary.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('all generated decks'), clearly distinguishing it from sibling tools like get_deck, which retrieves a single deck. It also specifies the exact output fields, leaving no ambiguity about the tool's function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'List all generated decks' provides clear context for when to use the tool: when a summary of all decks is needed. It does not explicitly exclude use cases or reference alternatives, but the scope ('all') inherently distinguishes it from single-item tools like get_deck.

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