Server Quality Checklist

Tool Scores

• babylonjs_scene_inspectA
  3.8/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. The verb 'Inspect' implies a read-only operation, and the category list clarifies what will be examined, but it does not explicitly promise no side effects, warn about the cost of 'full', or describe the output shape. This 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?

  Three sentences, each earning its place: an action statement, a category menu, and parameter usage. It is compact, front-loaded, and avoids repeating schema metadata unnecessarily.

  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 read-only inspection tool with no required parameters, the description covers the main invocation choices and provides enough context to select summary, full, or a drill-down category. It leaves minor gaps: no output format, no explicit combination rules for target/filter with categories, and no caveat about potentially expensive operations like the full scene graph.

  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 schema already documents category, target, and filter. The description restates the intended use of target and filter and adds conceptual framing, but it does not provide material new semantic information beyond the schema.

  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 opening sentence 'Inspect the BabylonJS scene' names a specific action and resource, and the category list makes the object of inspection concrete. It does not explicitly contrast with sibling tools like babylonjs_scene_evaluate or babylonjs_screenshot, but the verb and categories make the tool's role clear.

  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 provides explicit guidance for choosing a category: 'summary' for overview, 'full' for complete scene graph, and named categories for drilling into specific aspects. It also instructs when to use target and filter. It does not state when this tool should be preferred over sibling tools or when not to use it.

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

• babylonjs_scene_evaluateA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal that arbitrary JavaScript is executed against the scene and that return values are JSON-serialized, which is important. However, it does not mention potential side effects, mutation of the scene, error behavior, security implications, or asynchronous execution, all of which are significant for a code-evaluation tool.

  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 tight sentences with no wasted words. It front-loads the action, then covers arguments, return behavior, and intended use. Every sentence earns its place and the structure helps an agent quickly parse the tool's 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?

  The description covers the essentials for a basic call: the function body, input arguments, and JSON return. However, for a tool that executes arbitrary JavaScript, important context is missing—such as whether scene changes persist, what happens on exceptions, and any timeout or safety constraints. Given no output schema and no annotations, this is a noticeable gap.

  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 schema already documents the 'function' parameter with a detailed example. The tool description repeats the function signature (scene, engine, BABYLON) without adding new information about parameter format or constraints. This meets the baseline for full schema coverage but provides no extra semantic value.

  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: 'Execute a JavaScript function against the BabylonJS scene.' It clearly states what the tool does, names the arguments passed to the function, and explains the return serialization. It also distinguishes itself from sibling inspection/capture tools by positioning itself for 'custom queries or operations not covered by other 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?

  The description gives an explicit usage condition: 'Use this for custom queries or operations not covered by other tools.' This tells an agent when this escape-hatch tool is appropriate, though it does not name the sibling alternatives or explicitly say when not to use it. That slight lack of specificity keeps it from a 5.

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

• babylonjs_screenshotA
  4/5.0
  Behavior4/5

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

  With no annotations present, the description carries the burden of behavioral disclosure. It clearly states that screenshots are saved to tmp/, that file paths are returned, and that a rendering browser is required. It does not cover failure modes, file naming, cleanup, or error cases, so it stops short of 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 substantive sentences with no filler. The core action is front-loaded, followed by capabilities, output behavior, and a precondition. Every sentence earns its place.

  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 screenshot tool with no required parameters and a nested optional customCamera object, the description covers purpose, output location, returned values, and a critical prerequisite. It is slightly light on the exact shape of returned paths and how multiple views map to outputs, but an agent still has enough to select and invoke it 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 description coverage is only 20%, with only customCamera described. The description partially compensates by explaining that multiple views, preset angles, depth maps, and custom camera positions are supported, but it does not add meaningful semantics for width, height, format, or the individual view enum values beyond what the schema already exposes.

  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 states a clear action and resource: 'Capture one or more screenshots of the BabylonJS scene.' It also names concrete capabilities (preset angles, depth maps, custom camera positions) that distinguish it from scene inspection or connection tools, though it does not explicitly contrast it with a sibling.

  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 provides an explicit precondition and negative condition: 'Only available when a browser with rendering is connected.' This helps the agent avoid calling it at the wrong time. It implies use whenever a visual snapshot is needed, but it does not name alternative tools or when to prefer them.

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

• babylonjs_spector_captureA
  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 behavioral disclosure burden. It does disclose what the tool returns and its availability precondition, which is useful. However, it does not mention potential side effects, performance impact, whether capture pauses rendering, or how the data is returned. Partial transparency only.

  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 compact sentences that front-load the main action and rationale, then list outputs and a key precondition. Every sentence earns its place with no filler or 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?

  This tool has no output schema, so the description correctly enumerates the returned data categories (draw call count, shader source, WebGL state, texture bindings, performance data) and the runtime requirement. It could additionally explain how the capture affects the scene or how to choose between this and scene_inspect/screenshot, but the essential invocation context is present.

  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%: both detailLevel and quickCapture have descriptive text and detailLevel has an enum with meanings. The description itself adds no parameter-level information, so a 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 names a specific verb ('Capture'), resource ('a WebGL frame'), and technique ('using Spector.js'), and clarifies the purpose as 'low-level rendering inspection'. This distinguishes it from sibling tools like babylonjs_screenshot or babylonjs_scene_inspect, especially by enumerating rendering-specific outputs.

  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 context by stating the tool is for low-level rendering inspection and only available when a browser with WebGL is connected. It does not explicitly enumerate sibling alternatives or when-not-to-use conditions, so it falls short of a 5, but the intended usage is clearly communicated.

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

• babylonjs_connection_statusA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the behavioral disclosure burden. It transparently describes a read-only status operation and lists what will be returned: browser connection state, engine type, rendering capabilities, and available tool categories. It could explicitly state that it has no side effects, but for a status probe this is reasonably clear.

  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 with no filler. It opens with the action, names the target, and compactly lists the return areas, making every phrase useful.

  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 zero-parameter status probe with no output schema, the description is nearly complete: it states the action and the high-level return contents. It could name the specific tool categories available, but that is an enhancement rather than a necessary fix.

  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 input schema is empty, so the schema already covers everything needed. With no parameters to document, the description does not need to compensate for any parameter 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 states a specific verb, 'Check', and a specific resource, 'current connection state of the BabylonJS inspector'. It also enumerates the returned contents, which clearly distinguishes it from the sibling action-oriented tools like babylonjs_scene_inspect and babylonjs_screenshot.

  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: check connection state before using inspector tools. However, the description does not explicitly say when to use it versus alternatives or name any exclusions, so the agent must infer the usage context from the tool name and sibling list.

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