Server Quality Checklist

Tool Scores

• inspect_sceneA
  4/5.0
  Behavior3/5

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

  No annotations provided, so description must carry the burden. It discloses the type of data returned and mentions parameters like settle_frames hinting at async behavior, but does not explicitly state that the tool is read-only or describe performance implications.

  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 with zero waste. The first states the action and output, the second gives usage context and a concrete example. Front-loads the key information.

  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 8 parameters (1 required), no output schema, and no annotations, the description adequately explains the tool's purpose and hints at the output structure. Could mention the return format (e.g., JSON), but overall sufficient.

  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% with thorough parameter descriptions. The tool description does not add new semantics beyond what the schema already provides, so a baseline score 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?

  Title and description clearly state the tool returns a Three.js scene graph with specific world-space data. The example 'which Y puts the hat on the head' and mention of validate_scene distinguish its purpose from sibling tools.

  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?

  Description explicitly guides the agent to use this tool to reason about exact placement/sizes when fixing issues from validate_scene. It does not explicitly state when not to use, but the context with sibling tools is clear enough.

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

• render_sceneA
  4/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 rendering happens in a headless browser and returns screenshots. It mentions the need for specific global objects for multi-angle views. However, it does not fully disclose side effects (e.g., whether the file is modified), error handling, rate limits, or authentication needs, which would be expected with no 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 concise at 6 sentences, front-loaded with the main action and purpose. It uses emphasis ('ALWAYS') to highlight critical guidance. Every sentence adds value with no redundant or irrelevant content.

  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 (10 parameters, no output schema, no annotations), the description is mostly complete. It covers workflow, prerequisites, and specific usage tips. However, it lacks details about the return format of screenshots (e.g., base64, file paths) and does not address error conditions, which reduces 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?

  Schema description coverage is high (90%), so baseline is 3. The description adds value by explaining the multi-angle mechanism and hinting at distance_factor usage for close-ups. However, it does not compensate for the undocumented format parameter (no description in schema). Overall, it adds moderate context 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 the tool renders an HTML file with a 3D canvas and returns screenshots from multiple angles. It uses specific verbs ('renders', 'returns') and the resource (3D scene HTML). It distinguishes from siblings like get_guidelines (guidance), inspect_scene (inspect), interact_scene (interact), and validate_scene (validate) by focusing on rendering and image capture.

  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 advises when to use: 'ALWAYS call this after writing or editing scene HTML'. It mentions prerequisites for multi-angle views (window.__scene or window.__setView) and suggests calling get_guidelines topic 'workflow' for further guidance. It does not provide explicit when-not-to-use scenarios but gives clear context for when it's applicable.

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

• get_guidelinesA
  4.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 states that the tool returns guides and details what the 'workflow' topic includes, but does not mention any side effects, idempotency, or rate limits. For a read-only retrieval tool, this is adequate.

  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 main purpose and structured with key guidance upfront. It is not overly verbose but could be slightly more concise.

  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 a single parameter and no output schema, the description provides a thorough overview of each topic's content. It is sufficient for understanding the tool's functionality without gaps.

  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 schema provides full coverage with descriptions for each enum value. The tool description adds context by highlighting that 'workflow' is the starting point and explaining what it covers, adding value 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 states that the tool 'Returns curated guides for building good 3D canvas scenes.' It also specifies the 'workflow' topic as a starting point, clearly distinguishing it from sibling tools like interact_scene or render_scene.

  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 advises to 'Call topic 'workflow' BEFORE writing your first scene' and explains why (it covers the write→render→validate loop). Other topics are implied for different aspects, but no explicit exclusions or alternatives are provided.

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

• interact_sceneA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It explains the load-and-execute behavior, interleaved screenshots/state reads, and the requirement for window.__state. It lacks details on failure modes or error handling but covers core behavior well.

  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 two paragraphs, front-loaded with the main action. It is informative without being verbose, though some sentences could be tightened.

  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 (8 parameters, nested script array), the description covers the essential aspects. No output schema is provided, but the return of screenshots/state is implied. Missing details on error handling, but overall complete enough.

  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 88%, so most parameters are described. The description adds context: e.g., script should interleave actions with screenshots/state reads, and key names follow Playwright conventions. This adds value 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 it loads a game HTML and executes an input script with screenshots/state reads for verification. It distinguishes from sibling tools like render_scene by emphasizing dynamic interaction testing over static rendering.

  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 advises using it after building or changing game mechanics, implying it's for playtesting. It doesn't explicitly state when not to use, but context from sibling names and the description itself gives good guidance.

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

• validate_sceneA
  4.6/5.0
  Behavior5/5

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

  With no annotations, the description fully details the tool's behavior: loads scene HTML, reports page/console errors, performs deep scene-graph checks (floating objects, missing lights, etc.), each with severity and fix suggestion. No hidden side effects.

  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?

  A single, well-structured paragraph front-loading the main purpose and then detailing checks and usage. Efficiently conveys a lot of information without extraneous text.

  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 and 7 parameters, the description is comprehensive: covers what the tool does, the types of checks, and usage context. It provides enough information for an agent to use it effectively.

  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 baseline is 3. The description adds context for the overall tool but does not significantly elaborate on individual parameters beyond what the schema provides.

  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's purpose: running structured diagnostics on a 3D canvas scene and returning a JSON report. Distinguishes from siblings like 'interact_scene' or 'render_scene' by focusing on validation.

  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?

  Explicitly states when to use: 'Call this after render_scene whenever something looks wrong, and at least once before declaring the scene done.' Also provides ordering advice: 'Fix errors first, then warnings.'

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