Server Quality Checklist

Tool Scores

• discoverB
  3.2/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 the two modes (list summaries vs. fetch arguments) and implies a read-only nature, but it does not mention any edge cases, error behavior, or whether the operation parameter accepts identifiers, names, or other forms. This is moderate transparency but lacks depth.

  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 a single, compact sentence that front-loads the main action ('List operation summaries') before introducing the alternative. It avoids redundancy and unnecessary details, making it efficient and easy to parse.

  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 tool is simple with one optional parameter and an output schema provided (not shown here). The description explains the two invocation patterns but does not detail the return format or clarify how to specify an operation (e.g., by ID or name). While the output schema may cover return structure, the ambiguity around the parameter and lack of sibling differentiation make it incomplete for an agent to reliably choose and 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?

  With 0% schema description coverage, the description must explain the parameter's meaning. It does convey that the 'operation' parameter selects which operation to fetch arguments for, and that omitting it yields a list of summaries. However, it doesn't specify the format or allowed values of the parameter (e.g., integer ID, string name), so the agent must infer this from context or trial.

  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 the tool's dual behavior: listing operation summaries or fetching one operation's arguments. It uses specific verbs ('List' and 'fetch') and specifies the resource ('operation summaries', 'operation's arguments'), which distinguishes it from the sibling tools (inspect, capture, execute). However, it doesn't explicitly contrast itself with these siblings, so it's a step below fully differentiated.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus the alternatives (inspect, capture, execute). The description only states what it does, not the conditions under which an agent should select it. No exclusions or alternative suggestions are provided, leaving the agent to infer from the name alone.

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

• inspectB
  3.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 full burden. 'Read' implies a non-mutating operation, and 'bounded' hints at pagination/limit behavior, which is transparent. However, it does not disclose details about what a scene summary includes, how names behave when null, or any edge cases. The transparency is reasonable but not comprehensive.

  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, well-structured sentence with a subject-verb-object followed by a cond intuitive complement. It wastes no words, front-loading the core behavior ('Read a bounded scene summary') before explaining the secondary option (detailed properties via names).

  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?

  Though the description is short, the tool has zero required params, an output schema present, and no nested objects. It explains the primary call (bounded scene summary) and the optional enhancement (names). Given the schema already details return shape, the description covers the agent's immediate needs, though 'scene summary' itself remains fuzzy without more context.

  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 0%, so the description must compensate. It does add meaning: 'bounded' points to limit/offset, and 'pass names for detailed object properties' directly explains the names parameter. Yet it leaves limit and offset to inference, so the compensation is only partial, deserving a mid-range score.

  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 uses a specific verb ('Read') and explicit resource ('bounded scene summary'), and it explains the behavior of passing names to retrieve detailed object properties. It is clear about the operation's nature, though it does not name any sibling tool to distinguish itself from discover/capture/execute.

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

  Usage Guidelines2/5

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

  No guidance is given about when to use this tool versus its siblings (discover, capture, execute). There are no conditions, exclusions, or alternatives mentioned, leaving the agent to guess when this read operation is appropriate over the other tools.

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

• executeA
  3.8/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden. It discloses the 100-step ceiling, the non-transactional partial-failure behavior, and the fact that dry_run only checks syntax/permissions. This is strong behavior context, though it does not address auth or side-effect details of individual operations.

  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?

  Four short sentences, front-loaded with the core purpose and step format. Every sentence adds essential information: scope, return type, dry_run behavior, and failure semantics. 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?

  For a three-parameter batch tool with an output schema, the definition covers the main contract: step shape, limit, dry_run, and partial failures. Missing timeout semantics and explicit sibling routing are the only material omissions, so it falls just short of fully 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 0%, so the description must compensate. It does explain the steps object format and dry_run's effect, but it leaves timeout undocumented beyond its name/default. That is a notable gap for a tool with only three parameters.

  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 a specific action ('Execute up to 100 ... steps') and gives the step shape as {'op': name, ...arguments}. It also distinguishes its return style from inspect/capture-style tools by saying it returns 'counts/errors, not full scene data', though it never names the sibling tools explicitly.

  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 dry_run note gives clear guidance for validating a batch before running it, and the partial-failure warning implies the tool should not be used where atomicity is required. However, there is no explicit when-to-use/when-not-to-use comparison with the sibling tools inspect, discover, or capture.

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

• captureA
  4.2/5.0
  Behavior3/5

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

  With no annotations provided, the description must carry the burden. It discloses the output format (PNG), size range, and the prerequisite of an interactive 3D View. It does not mention potential side effects, failure conditions, or whether it is read-only, leaving some behavioral ambiguity.

  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, compact sentence that front-loads the output type and size range, followed by the mode and prerequisite. It contains no wasted words 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?

  For a simple tool with two optional parameters and no output schema, the description adequately covers the output (PNG), size range, and the critical prerequisite. It does not explain error handling or what happens if the view is not interactive, but that is a minor gap given the tool's simplicity.

  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 only defaults with 0% coverage, so the description must compensate. It does so by explaining the size range (64..1024) and clarifying that 'view' refers to camera render or viewport, directly enriching both parameters beyond their bare schema definitions.

  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 captures a PNG preview at sizes 64..1024, either from a camera or viewport, and requires an interactive 3D View. This is a specific verb-resource-output combination that clearly distinguishes it from siblings like inspect or execute.

  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 clearly communicates a key usage requirement (interactive 3D View) and specifies the two output modes (camera or viewport). However, it does not explicitly contrast with sibling tools or state when not to use it, though the distinct purpose makes the context evident.

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