Server Quality Checklist

Tool Scores

• manage_accountA
  3.9/5.0
  Behavior5/5

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

  Annotations already indicate destructiveHint=true, but the description adds crucial behavioral details: actions like delete_job and delete_asset are explicitly marked as irreversible, webhooks are described as push endpoints to avoid polling, and special notes like 'Logos are content-addressed/shared and are not deleted by this action' enhance transparency.

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

  Conciseness3/5

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

  The description is dense and front-loaded with a brief overview, but the long paragraph listing actions in a run-on manner reduces readability. A structured list would be more effective.

  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 all actions, including edge cases and irreversible operations. However, it lacks details on rate limits, authentication prerequisites, or error handling. Given the complexity (15 params, no output schema), it is mostly complete.

  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?

  With 100% schema description coverage, baseline is 3. The description adds value by grouping actions, explaining nuances (e.g., 'delete_asset irreversibly deletes a user-owned uploaded/generated image asset'), and clarifying webhook event subscriptions, thus exceeding basic schema explanations.

  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 'Account info, billing, job history, feedback, and data controls' and lists specific actions, distinguishing it from sibling tools focused on slide/deck creation and catalog browsing. However, the broad scope might reduce precision.

  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 for account management tasks but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.

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

• translate_deckA
  3.9/5.0
  Behavior3/5

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

  Annotations provide no safety hints, so the description must carry the burden. It mentions 'preserving formatting' but does not disclose whether the operation is destructive to the original source, rate limits, or what the output format looks like. The preferred input method (job_id) is noted, but overall behavioral details are sparse.

  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 sentences deliver the core action, features, and input options with no filler. Information is front-loaded and each sentence serves a distinct purpose.

  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?

  Given 10 parameters, no output schema, and complex inputs, the description is adequate but lacks details on return values, async behavior, or the translation process. The schema descriptions help but the tool overview could be more comprehensive.

  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 100%, so the parameter descriptions already define the inputs. The description repeats the key sources (job_id, url, base64) but adds no new semantic meaning beyond that. The pricing and language scope are not parameter-specific, so baseline 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 ('Translate a PPTX deck'), the specific resource (PPTX files), and distinguishes it from siblings like create_slide/create_deck by noting it works on existing decks and preserving formatting. The mention of pricing and language support adds specificity.

  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 explicitly tells when to use the tool: after creating a slide/deck (via job_id), or by providing a URL or base64. While it doesn't explicitly state alternatives or when not to use it, the context with sibling tools makes the usage clear.

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

• browse_catalogA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by detailing the behavior of each mode (e.g., returns contracts, thumbnails, layouts) and even suggests downstream actions ('render via create_slide'). 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.

  Conciseness3/5

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

  The description is dense and information-rich but lacks structural elements like bullet points or clear section breaks. It front-loads the main purpose but becomes a wall of text, making parsing harder despite being concise in word count.

  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 complexity (11 parameters, no output schema), the description covers all major use cases and explains what each mode returns (e.g., form overview with variant counts, exact payload contracts). It even mentions the code path and rendering instructions for themes. Missing a formal output schema is partially mitigated.

  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?

  With 73% schema description coverage, the description goes beyond the schema by explaining how parameters interact (e.g., 'type=schema + family -> variant chooser', 'variant=/prior_id= -> example payload'). For parameters like family and variant that lack schema descriptions, the description provides essential context, compensating for gaps.

  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 is for browsing the SSG catalog progressively, with a specific verb 'browse' and resource 'catalog'. It differentiates from siblings like create_slide or plan_slide by focusing on discovery rather than creation. The multiple modes are explicitly outlined, making the purpose unmistakable.

  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 explicit guidance on when to use each parameter combination (e.g., 'No args -> form overview', 'q=<text> -> ranked search'), and contrasts with siblings implicitly by describing a discovery workflow that precedes creation. However, it lacks explicit 'when not to use' statements or direct references to alternatives.

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

• plan_slideA
  4.2/5.0
  Behavior5/5

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

  Annotations already mark readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds detailed behavioral context: explains output fields (route, confidence, retrieval_score, etc.), the effect of escalate on LLM rescue, and cost implications ('Free (one embedding)'). No contradictions.

  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 front-loaded with the core action and provides detailed technical information about output fields. While dense, each sentence adds value. Slightly verbose but still efficient for the complexity.

  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 explains output structure and key parameters but misses the 'top' parameter and does not fully describe the return format of candidates (no output schema). Error handling or edge cases are not addressed. Could be more 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?

  Schema description coverage is 50%. The description adds meaning for escalate and variant_policy but does not explain the 'top' parameter. The brief parameter is implied but lacks explicit validation guidance. More detail on all parameters would improve semantics.

  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 purpose: 'Plan before rendering: send a short brief, get ranked candidates + a separated verdict'. It distinguishes from siblings by explicitly directing to call create_slide afterwards, showing it is a planning step.

  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 implies usage before rendering and provides context like 'Free (one embedding)' and the escalate parameter's effect. However, it does not explicitly state when not to use this tool versus alternatives, such as browse_catalog.

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

• upload_assetA
  4.4/5.0
  Behavior4/5

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

  Annotations are all false, so the description carries the behavioral disclosure burden. It reveals additional traits: AI generation costs ($0.05, $0.02/slide), large-file drop-zone behavior, and that bytes never pass through agent for large files. No contradictions. Could mention if file size limits are enforced strictly.

  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 structured with a brief overall statement followed by bullet points for each purpose. It is front-loaded with the main action. While slightly lengthy, it earns its length by covering multiple use cases and edge cases without redundancy.

  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 no output schema, the description covers return values (IDs) for each purpose. It addresses all 10 parameters, required fields, large-file handling, cost details, and optional chaining (pdf+translate). It is comprehensive for a complex 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 coverage is 100%, baseline is 3. The description adds value by explaining which parameters are required per purpose and what IDs are returned (e.g., logo_id, theme_id). It also clarifies the drop-zone behavior for large files, going beyond 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 clearly states the tool's purpose: upload or generate assets (logo, theme PPTX, image, document, or AI-generated image). It lists specific purposes and their outcomes (e.g., logo_id, asset_id), distinguishing it from sibling tools like browse_catalog or plan_slide.

  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 explicit guidance on when to use each purpose and for large files (>3MB) on pdf/translate/theme, it advises omitting data. It does not explicitly mention when not to use the tool vs siblings, but given no direct overlap, this is adequate.

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

• create_slideA
  4.7/5.0
  Behavior5/5

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

  Beyond annotations (readOnlyHint=false, destructiveHint=false), the description adds significant behavioral context: cost implications, blocking vs. async modes, dry_run free checks, error handling (e.g., min_font_not_met), and mode-specific behaviors (e.g., code sandbox, status polling). No contradictions 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.

  Conciseness4/5

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

  The description is long but well-structured with clear sections (FORM MENU, escape modes, parameter hints). It front-loads the core action and uses headings to organize dense information. Could be slightly more concise, but the verbosity is justified given the tool's complexity.

  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 complexity (41 parameters, many forms, multiple modes) and no output schema, the description is remarkably complete. It covers all important aspects: form selection, parameter usage, behavioral details, cost, error handling, and references to sibling tools for additional info.

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

  Parameters5/5

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

  Although schema description coverage is high (93%), the description adds crucial meaning beyond schema by detailing the entire form menu (30+ forms with their intents and data shapes) and explaining complex parameters like mode, verify, and allow_fabrication. This is essential for correct invocation.

  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 purpose: 'Create ONE slide from a structured intent in ONE call.' It specifies the two main input methods (form+brief) and escape modes (code, status). It also distinguishes itself from sibling tools like browse_catalog (browsing) and create_deck (multiple slides).

  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 guidance on when to use different modes (e.g., mode=code for custom diagrams, dry_run for free validation, wait for async polling). It does not explicitly state when not to use this tool versus alternatives, but given the context, the usage is clear.

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

• create_deckA
  4.9/5.0
  Behavior5/5

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

  A annotations do not contradict the description. The description discloses key behaviors such as slides filling in parallel, polling via deck_id=job_id, cost implications (dry_run free, allow_partial billing), and policy gates. This goes beyond annotations to aid correct invocation.

  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 relatively concise given the number of parameters and complexity. It is front-loaded with the main purpose and then logically covers modes, polling, and edge-case parameters. Minor redundancy could be trimmed but overall well-structured.

  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 complexity (14 parameters, nested objects, multiple modes, no output schema), the description provides comprehensive guidance on inputs, behavior, and error handling. It covers validation, cost, polling, and policy gates, making it complete for an AI agent.

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

  Parameters5/5

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

  With schema coverage at 86%, the description adds significant value by explaining the relationship between slides and create_slide, the meaning of modes, dry_run's return value, and the effect of force_render, allow_partial, and strict_policy. This helps the agent understand parameter usage beyond 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 clearly states 'Create a WHOLE deck in one call' and details the slides parameter and modes. It distinguishes itself from siblings like create_slide by explaining that slides are a list of create_slide intents. The purpose is specific and unambiguous.

  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 on when to use each mode (render, assemble, fork) and when to use dry_run. It also references create_slide for individual slides and explains that assemble and fork are free. This helps the agent choose between tools.

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