Server Quality Checklist

Tool Scores

• parse_unity_prefabA
  3.9/5.0
  Behavior3/5

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

  The description discloses the deprecated status and the automatic cache-loading behavior. With no annotations, it adds some transparency, but it does not mention return structure, side effects, or error behaviors, leaving gaps in the tool's safety and outcome profile.

  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 and effectively front-loaded with the deprecation notice. The WORKFLOW section adds relevant context without redundancy, making every sentence purposeful 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?

  As a deprecated alias, the description appropriately points to parse_unity_file for core behavior, but it doesn't explain return values or deeper operational details, especially without an output schema. The workflow note adds some completeness, but the description remains dependent on the sibling tool for full 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 input schema fully describes both filePath and config parameters, and the description adds no additional parameter-level details. This meets the baseline but does not exceed what the schema already provides.

  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 identifies the tool as a deprecated alias for parse_unity_file, which clarifies its purpose by referencing the canonical tool. However, it does not independently describe what parsing entails, relying on the sibling tool's definition for full clarity.

  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 explicitly instructs users to adopt parse_unity_file for new clients, and provides a workflow step to call init_unity_project first. This directly distinguishes when to use this tool vs alternatives and offers clear contextual guidance.

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

• list_unity_assetsA
  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 states the tool scans and returns a list, implying a read-only operation, but does not explicitly confirm non-destructiveness, error handling, or the nature of 'grouping'. This is adequate but leaves gaps.

  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 sentence that efficiently conveys the action, target, and output. No filler or redundancy, and it even includes a workflow hint about parse_unity_file.

  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 tool with six parameters, no output schema, and no annotations, the description covers the core purpose and output type. It could clarify what 'grouped' means and mention default/error behavior, but combined with the rich schema it is nearly sufficient for typical use.

  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% and all six parameters have rich descriptions (e.g., exact matching, default values). The tool description adds nothing about parameters 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?

  The description uses a specific verb ('Scan'), names the exact resource (directory for Unity asset files with .prefab, .unity, .asset), and clarifies the output (grouped list with absolute paths). This clearly distinguishes it from sibling tools like parse_unity_file and browse_unity_project.

  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 the tool is used to discover files for subsequent parsing ('ready to use with parse_unity_file'), offering clear context. However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of the highest bar.

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

• browse_unity_projectA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses that browsing shows asset counts, that it requires initialization but can auto-init, and it positions the tool within a workflow. However, it does not detail the exact return structure or whether the operation is purely read-only, though browsing implies this.

  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 and front-loaded with the main purpose, followed by a clear numbered workflow. Every sentence adds value, with no filler or repetition.

  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 3 parameters and no output schema, the description provides sufficient context through the workflow and usage guidance. It could mention the tree-like nature of the output explicitly, but the information provided is enough for an agent to invoke the tool correctly in sequence.

  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 already has 100% description coverage and clear parameter descriptions (projectPath, depth, subPath). The description adds workflow context but does not elaborate further on parameter semantics beyond what the schema provides, so the 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?

  The description clearly states the tool's function: 'Browse the Unity project folder tree with asset counts.' This uses a specific verb ('browse') and resource ('Unity project folder tree'), and the workflow list differentiates it from sibling tools like listing assets or parsing files.

  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 explicitly provides a workflow ('init_unity_project → browse_unity_project → list_unity_assets → parse_unity_file') and states when to use this tool: 'Use this to navigate large projects and find the subfolder containing the assets you want to work with.' This gives clear context and distinguishes it from alternatives.

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

• init_unity_projectA
  4.4/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 reveals the cache file location (.unity-mcp-cache.json), automatic reuse, and performance characteristics for large projects. However, it doesn't detail potential side effects on existing project files beyond creating the cache.

  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 short paragraphs with clear front-loading: purpose first, workflow second, performance last. Every sentence earns its place, making it concise and well-structured.

  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 purpose, workflow, prerequisites, and performance. It lacks explicit return value details, but there is no output schema and the tool is an initialization routine, so the provided information is mostly 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 coverage is 100%, with both parameters already described. The description adds no additional parameter-level semantics beyond what the schema provides, 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 initializes a Unity project for MCP use by building a GUID→asset name cache from .meta files. It distinguishes itself from siblings by being the required setup step for parse_unity_file and browse_unity_project.

  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?

  It explicitly instructs to call ONCE per project before using parse_unity_file or browse_unity_project, and explains reuse and when to force rescan. This gives clear when-to-use and workflow context, directly guiding the agent.

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

• parse_unity_fileA
  4.4/5.0
  Behavior5/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 exhaustively documents output behavior: omitted fields (default values, null references, enabled:true), unity internal field filtering, field renaming to Inspector names, prefab variant handling, and compact mode optimizations. It also details specific examples like 'lPos (0,0,0)' and 'short reference syntax (@Player)'. This is exceptionally transparent.

  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 (WORKFLOW, IMPORTANT, Features, Prefab Variant Support, Compact mode optimizations). It is front-loaded with the core purpose and workflow, and each section adds relevant details. While some information could be trimmed (e.g., extensive compact mode enumeration), it is appropriate for 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 (2 params with nested config, no output schema), the description is remarkably complete. It explains the output structure ('hierarchical structure showing the GameObject tree and all component data'), default value handling, reference resolution, and edge cases like prefab variants. It fully compensates for the lack of an output schema and provides context for all config options.

  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 description coverage is 100% for filePath and config properties, so the baseline is 3. The description adds substantial meaning beyond the schema, particularly for the 'preset' parameter by explaining presets (minimal, standard, compact) and detailing compact mode optimizations with token reduction percentages, syntax examples, and abbreviation conventions. This elevates the parameter understanding significantly.

  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 function: 'Parse a Unity text-serialized prefab, scene, or asset file and extract Inspector-visible component data in YAML format.' The verb 'Parse' and resource 'Unity text-serialized prefab, scene, or asset file' are specific. It distinguishes from siblings like parse_unity_prefab by explicitly covering prefabs, scenes, and assets, implying a broader file parser.

  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 provides a clear workflow: 'For best results with asset name resolution, call init_unity_project first. If already initialized, the cache is loaded automatically.' However, it does not explicitly state when to choose this over parse_unity_prefab or other sibling tools, nor does it mention exclusions or alternatives beyond the init prerequisite. This is a gap in usage differentiation.

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