Server Quality Checklist

Tool Scores

• godot_exportC
  2.9/5.0
  Behavior2/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 mentions the export action but fails to describe critical behaviors: whether this is a destructive operation (overwrites output files), requires specific permissions, has side effects on the project, or includes error handling. This leaves significant gaps for a tool that performs file system 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?

  The description is a single, clear sentence that efficiently conveys the core purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to understand at a glance.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool that performs export operations (potentially involving file system changes and platform-specific builds) with no annotations and no output schema, the description is insufficient. It lacks details on return values, error conditions, platform support, or dependencies like export preset configuration, leaving the agent with incomplete operational 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?

  The schema description coverage is 100%, with all three parameters well-documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema (e.g., format examples, constraints, or relationships between parameters), so it meets the baseline for high schema coverage.

  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 verb ('Export') and resource ('a Godot project') with the specific target ('to a specific platform'), making the purpose immediately understandable. It distinguishes from siblings like 'godot_import' (import vs export) and 'godot_run_scene' (run vs export), though it doesn't explicitly mention these distinctions.

  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?

  The description provides no guidance on when to use this tool versus alternatives like 'godot_check_errors' or 'godot_run_tests', nor does it mention prerequisites such as having a configured export preset. It simply states what the tool does without contextual usage information.

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

• godot_importA
  3.5/5.0
  Behavior2/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 of behavioral disclosure. It mentions the tool is 'useful after adding new files,' which adds some context about timing, but lacks details on permissions needed, whether it's destructive (e.g., overwrites existing assets), rate limits, or what the import process entails (e.g., formats supported, error handling). For a mutation tool with zero annotation coverage, this is a significant gap.

  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 appropriately sized and front-loaded, consisting of two concise sentences that directly state the purpose and usage context without unnecessary elaboration. Every sentence adds value, making it efficient and easy to understand.

  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 the tool's moderate complexity (importing assets, likely a mutation), lack of annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and usage timing but misses behavioral details like side effects or return values. For a tool with no structured safety or output information, it should provide more context to be 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?

  The input schema has 1 parameter with 100% description coverage, providing a clear definition for 'project_path.' The description doesn't add any parameter-specific details beyond what the schema already covers, such as explaining how the path is used or format requirements. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.

  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 purpose as 'Import/reimport assets in a Godot project,' specifying both the action (import/reimport) and resource (assets in Godot project). It distinguishes from siblings like godot_check_errors or godot_run_scene by focusing on asset management rather than error checking or execution. However, it doesn't explicitly differentiate from godot_export, which might also involve asset handling.

  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 usage with 'Useful after adding new files,' indicating when to use this tool. It implies an alternative workflow (not using it if no new files are added), but doesn't explicitly state when not to use it or name specific alternatives among siblings like godot_check_errors for validation.

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

• godot_run_sceneA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden. It discloses the key behavioral trait that execution is 'non-headless, will open a window' - important runtime behavior. However, it doesn't mention what happens on timeout, whether the tool blocks until scene completion, error handling, or resource cleanup. For a tool that launches graphical applications, more behavioral context would be helpful.

  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, efficient sentence that front-loads the core purpose and includes the critical behavioral detail about window opening. Every word earns its place with no redundancy or unnecessary elaboration.

  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?

  For a tool with 3 parameters, 100% schema coverage, but no annotations and no output schema, the description provides adequate but minimal context. It covers the core purpose and key runtime behavior but doesn't address error conditions, return values, or integration considerations. Given the complexity of launching graphical applications, more completeness would be beneficial.

  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 all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting for parameter documentation.

  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 specific action ('Run a specific scene') and resource ('Godot project'), and distinguishes it from siblings by specifying it's 'non-headless, will open a window' - which differentiates it from test-running or headless execution tools. The verb+resource combination is precise 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 Guidelines3/5

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

  The description implies usage context through 'non-headless, will open a window' which suggests this is for visual testing/demo purposes rather than automated testing. However, it doesn't explicitly state when to use this vs. alternatives like godot_run_tests or godot_export, nor does it provide any exclusion criteria or prerequisites for usage.

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

• godot_run_testsA
  3.7/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 mentions the tool returns test results including pass/fail counts and failures, which adds some context beyond the input schema. However, it lacks details on execution behavior (e.g., whether it runs tests synchronously, potential side effects, or error handling), leaving gaps in transparency.

  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 front-loaded with the core purpose in the first sentence and efficiently adds return value information in the second. Both sentences earn their place by providing essential context without redundancy, making it appropriately sized and well-structured.

  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 the tool's moderate complexity (4 parameters, no annotations, no output schema), the description is partially complete. It covers the purpose and return values but lacks details on behavioral aspects like execution flow or error conditions. Without an output schema, it should ideally explain return formats more thoroughly, but it provides a basic overview.

  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 input schema has 100% description coverage, providing full documentation for all 4 parameters. The description does not add any additional meaning or semantics beyond what the schema already specifies, such as explaining parameter interactions or usage nuances. This meets the baseline for high schema 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 clearly states the specific action ('Run GUT (Godot Unit Test) tests') and resource ('for a Godot project'), distinguishing it from sibling tools like godot_export or godot_run_scene. It precisely defines the tool's function without being vague or tautological.

  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 testing Godot projects but does not explicitly state when to use this tool versus alternatives like godot_check_errors or godot_run_scene. There is no guidance on prerequisites, exclusions, or specific contexts, leaving usage inferred rather than clearly defined.

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

• godot_check_errorsA
  4/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 effectively communicates that this is a read-only, non-destructive operation ('Check... without running the game'), which is appropriate for a static analysis tool. However, it doesn't mention potential side effects like file system access, performance characteristics, or error handling behavior.

  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 that efficiently communicates the tool's purpose, scope, and limitation. Every word earns its place, with no redundant information or unnecessary elaboration.

  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 single-parameter tool with no output schema and no annotations, the description provides good context about what the tool does and its non-execution nature. However, it doesn't describe what the output looks like (e.g., error list, success/failure status) or potential limitations, leaving some gaps in 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 100%, with the single parameter 'project_path' well-documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema, so it meets the baseline score of 3 for high schema coverage without providing additional parameter 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 specific action ('Check') and resource ('Godot project'), specifying what it checks for ('parse errors and syntax issues') and what it doesn't do ('without running the game'). It distinguishes itself from siblings like godot_run_scene and godot_run_tests by emphasizing it's a static analysis tool rather than execution.

  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 about when to use this tool ('Check a Godot project for parse errors and syntax issues') and implicitly distinguishes it from execution tools by stating 'without running the game.' However, it doesn't explicitly mention when NOT to use it or name specific alternatives among siblings for different scenarios.

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