Server Quality Checklist

Tool Scores

• deck_previewA
  4.2/5.0
  Behavior4/5

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

  The description discloses the return format (contact sheet by default or individual slides) and suggests how to use the output for quality checks. Annotations already declare readOnlyHint=true, and the description adds value by explaining what the rendered images are for, going beyond the annotation's basic safety flag.

  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 three sentences, front-loaded with the primary action ('Render a generated deck to images'), followed by return format and practical usage guidance. Every sentence earns its place with no redundancy.

  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?

  The description explains the return format and intended use, and the schema covers all parameters and defaults. It could explicitly state that the deck must already be generated, but 'generated deck' and the sibling deck_generate make this clear enough. With no output schema, the return value explanation is adequate.

  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?

  All four parameters are fully documented in the schema (100% coverage), so the baseline is 3. The description adds no parameter-specific details beyond what the schema already provides; the mention of 'contact sheet by default' merely reflects the mode parameter's default, not new information.

  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 'Render' with a specific resource 'generated deck', clearly stating it produces images for visual inspection. It distinguishes itself from siblings by focusing on visual rendering rather than capabilities, fetching, validation, or generation.

  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 context for when to use the tool: to visually inspect a deck for issues like text spilling, empty slides, or badly wrapped titles, and implies a follow-up workflow of fixing Markdown and regenerating. However, it does not explicitly name alternatives or exclusion conditions, stopping short of full when/when-not guidance.

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

• deck_validateA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so the description's added value comes from clarifying that it does not render a file and specifies the type of warnings reported (overflow risk, too many cards, missing titles). This provides useful behavioral context beyond the annotation.

  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 action and output, and each clause earns its place. The usage hint ('Cheap — use it while drafting') is concise and memorable.

  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?

  Given the tool's simplicity (one parameter, output schema present, read-only annotation), the description covers the essential facets: what it parses, what it reports, when to use it, and that it avoids rendering. No critical context is missing.

  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 description coverage is 100%, and the parameter 'markdown' is already fully described as 'The deck source in the True deck Markdown format.' The description adds no new parameter-level semantics beyond what the schema provides, so the baseline of 3 is appropriate.

  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 action ('Parse deck Markdown'), the resource ('deck Markdown'), and the output ('slide outline plus layout warnings'). It explicitly distinguishes itself from sibling tools by focusing on validation, not generation, fetching, or previewing.

  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 usage context, recommending use 'while drafting' and emphasizing the tool is 'Cheap'. It does not explicitly name alternative tools or exclusions, but the context is sufficient for a single-purpose validation tool.

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

• deck_capabilitiesA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=false, so the read-only nature is covered. The description adds context about the content scope (what capabilities are exposed) and the recommended call time, going beyond the annotations without contradicting them.

  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?

  Two concise sentences deliver exactly the needed information: the categories of data returned and when to invoke the tool. Every word earns its place, with no padding or repetition.

  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 simple read-only, parameterless tool, the description adequately covers what it returns and when to call it. It could be more explicit about the return format, but with no output schema and the clear scope, this is a minor gap.

  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, so the schema fully covers all parameters (vacuously). The description adds no parameter-level details because none exist, matching the baseline for a parameterless tool.

  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 explicitly states what the tool returns: 'slide kinds, body block types, capacity limits and the brand palette.' This is a specific, actionable scope that clearly distinguishes it from siblings like deck_fetch, deck_validate, deck_generate, and deck_preview.

  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 usage guidance: 'Call this before writing deck Markdown for the first time.' This establishes a specific precondition and context, though it does not explicitly name alternatives or state when not to use the tool.

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

• deck_generateA
  4.4/5.0
  Behavior4/5

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

  Annotations already cover safety (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description adds valuable behavioral context by explaining the artifact_id return and the intended regeneration workflow, going beyond the annotations without contradicting them.

  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 purpose, and every sentence provides essential information: what it does, what it returns, and a key usage guideline. No wasted words.

  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?

  With an output schema present, the description need not explain return values in detail. It adequately covers the generation workflow and integration with preview/fetch. Minor gap: no explicit mention of when to use deck_validate or deck_capabilities, but overall complete for selection and invocation.

  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 description coverage is 100%, so the baseline is 3. The description does not add parameter-level meaning beyond the schema; all three parameters are already well described in the schema properties.

  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: 'Render deck Markdown into a True-branded .pptx.' This is a specific verb and resource, and it distinguishes from siblings by explaining that it returns an artifact_id for use with deck_preview and deck_fetch.

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

  Usage Guidelines5/5

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

  The description provides explicit guidance: 'Regenerate from edited Markdown rather than editing the .pptx' and directs the user to pass the artifact_id to deck_preview and deck_fetch for viewing and retrieval. This clarifies when to use this tool and how it fits with alternatives.

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

• deck_fetchA
  4.7/5.0
  Behavior5/5

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

  Beyond the readOnlyHint annotation, the description discloses that large files are refused and that the file is returned as an embedded resource. This provides meaningful behavioral context not available from annotations alone. No contradiction with annotations.

  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?

  Two concise sentences front-load the core purpose and immediately state the key limitation and alternatives. Every word earns its place.

  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 simple single-parameter read-only tool with rich annotations and schema, the description is complete. It covers purpose, usage context, and failure mode (large files), which is sufficient for an AI agent to decide when to use this tool.

  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 for the single parameter is 100%, with the artifact_id already described as 'returned by deck_generate'. The tool description adds no additional parameter semantics, so the baseline of 3 applies.

  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 explicitly states the tool returns the generated .pptx as an embedded resource, and clearly distinguishes from sibling tools by noting it's for hosts that cannot fetch a download URL. It also references alternatives like download_url or file_path.

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

  Usage Guidelines5/5

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

  The description gives explicit when-to-use guidance ('for hosts that cannot fetch a download URL') and when-not-to-use with a specific exclusion ('Large files are refused — use download_url or file_path instead'). It names exact alternatives.

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