Server Quality Checklist

Tool Scores

• pptx_auditA
  3.9/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful context about the report's scope, including portability risk behavior ('strict readers reject bugs that lenient ones silently self-heal'), which goes beyond the annotations. No contradiction with annotations is present.

  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, information-rich sentence that front-loads the purpose ('Full report') and then lists concrete report components in a dash-separated series. Every phrase adds value and no filler exists. The structure makes it easy to scan even though the sentence is long.

  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 covers the tool's substantive functionality thoroughly, and an output schema exists so return values need not be described in prose. It is complete enough for an agent to understand the audit scope and expected metrics. The only notable gap is the lack of explicit routing away from pptx_validate, but the 'plus advisory metrics' phrasing largely covers that.

  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% according to context signals, so the description must compensate by explaining the `source` parameter and the path/base64 tradeoff. It does not: the entire description focuses on the output report and never mentions how to specify the input file. The schema provides some names and types, but the description adds no parameter guidance, leaving a gap for low coverage.

  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 verb and resource: it produces a full audit report of an existing .pptx. It enumerates concrete content ('all structural validation violations, plus advisory metrics') and explicitly includes validation plus quality metrics, which distinguishes it from the sibling pptx_validate. The title reinforces the same distinction.

  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 when to use the tool: whenever a comprehensive report with validation and metrics is needed. However, it never explicitly states when not to use it, e.g., 'if you only need validation, use pptx_validate', or mentions any alternatives. The usage context is clear but left to inference.

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

• pptx_validateA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and idempotentHint, and the description adds meaningful behavioral details beyond those: it returns valid:true only with zero error-severity violations, targets specific bug classes, and promises cross-tool compatibility. No contradiction with annotations exists.

  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-loads the core purpose, and each sentence earns its place: purpose, scope, and return semantics. It is detailed without being bloated or redundant.

  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 output schema exists, the description does not need to enumerate the full return shape. It covers what is validated, the strictness standard, the files it applies to, and the validity condition. Combined with the read-only/idempotent annotations and schema-documented parameters, nothing essential 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?

  The description does not discuss the source parameter or the path/base64 distinction, but the input schema itself provides clear descriptions for both fields. The schema carries the parameter-semantics burden, so the description adds little beyond what an agent already sees in the schema.

  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 ('Check an existing .pptx file's structural conformance') and identifies the exact standard (OOXML/ECMA-376 PresentationML). It lists concrete violation classes, distinguishes validation from creation/repair/audit siblings, and clarifies the success condition, so an agent can tell what this tool does without opening the schema.

  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 when to use the tool: whenever an existing .pptx needs conformance checking, and it explicitly says it works on any .pptx regardless of origin. However, it never names sibling tools like pptx_audit or pptx_repair, nor states when to choose validation over auditing or repair, leaving some routing to inference.

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

• pptx_repairA
  4.3/5.0
  Behavior5/5

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

  The description discloses specific mutations: backfilling ID-list entries, correcting content types, removing dangling relationships, stripping printer-settings parts, and clamping geometry. It also states it returns a change log and reports unfixable violations instead of guessing, which adds meaningful behavioral context beyond the readOnlyHint=false and idempotentHint=true 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?

  The description is dense but purposeful: it front-loads the core action, then uses a colon to introduce a specific list of fixes, and closes with the output/log behavior. Every clause adds useful information, with no filler or tautological repetition of the title.

  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 single-parameter repair tool with a true output schema and annotations covering read-only/idempotence, the description supplies all essential context: what will be fixed, what will be removed, and how unsafe violations are handled. Nothing critical appears missing for an agent to decide whether and how to invoke it.

  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 description adds only that the tool operates on an existing .pptx and returns a repaired file; it does not explain how to provide the source via path versus base64. However, the input schema itself documents the nested path and base64 properties well, so the parameter semantics are still usable without requiring the description to compensate.

  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 and resource: "Auto-fix an existing .pptx's structural problems," then enumerates concrete repair actions. This clearly distinguishes it from sibling tools like pptx_validate and pptx_audit, which are inspection-oriented rather than repair-oriented.

  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 intended use is implied by "auto-fix" and the enumerated structural defects, so an agent can infer this is for repairing broken OOXML packages rather than creating or auditing them. However, the description never explicitly names alternatives such as pptx_validate or pptx_audit, nor does it state when not to use this tool.

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

• pptx_list_layoutsA
  4.5/5.0
  Behavior4/5

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

  Annotations already establish readOnlyHint and idempotentHint, and the description adds meaningful behavioral context beyond them: it behaves differently with and without the optional template, returning either the archetype catalog or also template slide details. OpenWorldHint=false is not contradicted by the description.

  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 with no filler, front-loading the primary return value and then explaining the conditional template behavior. The title adds a concise summary, and every word contributes to operational understanding.

  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 one optional parameter, a rich output schema, and clear annotations, the description fully covers both invocation modes and the practical purpose of the template parameter. There are no significant gaps for an agent to call this tool correctly.

  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 input schema already documents template, path, and base64 with 100% coverage, so the baseline is 3. The description adds functional value by explaining that passing a template lets the agent inspect existing slides and pick stencilSlideIndex values, which the schema alone does not convey.

  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: it returns the catalog of slide layout archetypes supported by pptx_create_deck, and optionally inspects an existing template's slides for layout names and placeholder types. It uses specific, distinct language that separates it from the sibling tools like create, validate, audit, and repair.

  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 explains when to use the tool: before creating a deck or when working in template mode, specifically to choose a stencilSlideIndex. It does not explicitly name alternatives or state when not to use it, but the context is strong enough for an agent to infer correct usage.

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

• pptx_create_deckA
  4.6/5.0
  Behavior5/5

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

  Annotations are minimal (all false), so the description carries the burden and does it well: it discloses that new slides are APPENDED after template slides, that the template must contain at least one slide, that output is self-certified against the same OOXML checklist as pptx_validate, and that the result is returned as a base64 resource plus a summary. This is far beyond what the annotations or schema convey.

  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 dense but every sentence earns its place: purpose, template mode, append behavior, template requirement, default-theme fallback, self-certification, and return format are all covered without filler. It is front-loaded with the core purpose before diving into mode details.

  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 complexity, the description covers the most important operational context: template cloning, append semantics, validation, and output shape. It also points to pptx_list_layouts for the archetype catalog, which compensates for not enumerating archetypes. Minor gaps remain around failure modes and explicit call-to-action sequencing, but the output schema and rich parameter schema cover much of the remaining detail.

  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 coverage is 100%, so the baseline is 3, but the description adds substantial semantic value: it explains that template mode clones stencil slides and inherits masters, layout, theme and branding; it clarifies stencilSlideIndex's role; and it explains what happens when template is omitted. This goes beyond the schema's field-level 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 opens with a specific verb and resource: 'Build a .pptx from a declarative list of slides.' It clearly distinguishes the tool from its siblings by referencing pptx_list_layouts for the archetype catalog and by describing the create/append behavior rather than validation or repair.

  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 each mode: bring-your-own-template vs. omitting template for a fresh default deck. It also routes the agent to pptx_list_layouts for the archetype catalog and ties validation back to pptx_validate's checklist. It does not explicitly state when not to use this tool versus audit/repair, but those are clearly distinct operations.

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