Unity MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation2/5
With 84 tools, many have overlapping purposes, such as multiple tools for adding objects (add_asset_to_scene, create_prefab, instantiate) and multiple ways to execute code (execute_code, call_static_method). Descriptions are detailed but the high number of tools with similar functions causes confusion.
Naming Consistency2/5
Tool names follow inconsistent patterns: some use verb_noun (add_asset_to_scene), others are simple nouns (animation, debugger), and some are verb-only (execute_code). Mixing of patterns and lack of a predictable scheme reduces coherence.
Tool Count2/5
84 tools is excessively high for a single MCP server. While the server covers a broad Unity domain, the count makes navigation difficult and suggests many tools could be combined or eliminated. A more focused scope would improve usability.
Completeness3/5
The server covers many Unity areas (XR, animation, physics, terrain, etc.), but has notable gaps like missing standard UI tools (non-XR canvas, buttons) and lack of direct GameObject hierarchy management. It is comprehensive in XR but incomplete for general Unity workflows.
Average 3.6/5 across 84 of 84 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 21 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, so mutation is expected. However, the description does not disclose side effects, required permissions, or undo behavior for actions like assign_material or set_shader. No detail on what gets modified or how changes are applied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the general purpose, but the bullet list of 13 actions is lengthy and duplicates the action enum from the schema. Could be more concise by grouping or omitting the full list and focusing on behavior.
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?
No output schema exists, yet the description does not explain what each action returns (e.g., 'get_material returns material properties'). With 18 parameters and varied actions, the agent lacks information on expected outcomes, making the description incomplete.
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 each parameter has a description. The tool description does not add semantic meaning beyond the schema. Baseline of 3 is appropriate, as the description neither enhances nor degrades parameter understanding.
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 'Manages Unity materials and shaders' and lists 13 specific actions, clearly indicating the scope. It is distinguishable from sibling tools that cover different domains. However, it lacks a concise overall statement of what the tool does (e.g., 'Provides operations to create, modify, and query materials and shaders').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. No when-to-use, when-not-to-use, or prerequisite information is given. The lengthy list of actions assumes the agent knows which action to choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, so the tool is expected to mutate state. The description 'runs tests' implies execution but provides no additional behavioral context such as side effects (modification of project files), resource consumption, or output format. Beyond the annotations, the description adds minimal transparency.
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 sentence, making it very concise and front-loaded. It contains no unnecessary words. However, it could be slightly longer to include key context (e.g., test modes) without losing conciseness. The sentence earns its place but could be more informative.
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?
Given the complexity (4 optional parameters, output schema exists), the description is too sparse. It does not mention that it runs in the Unity Editor, requires a test setup, or that logs and failure details are configurable via parameters. The output schema exists but the description doesn't complement it. A more complete description would help agents understand the tool's scope and usage.
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 each of the 4 parameters (testMode, testFilter, returnWithLogs, returnOnlyFailures) having a functional description. The tool description repeats no parameter details and adds no extra meaning. According to rubric, baseline 3 is appropriate when schema does the heavy lifting.
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 'Runs Unity's Test Runner tests' clearly states the verb ('runs') and the resource ('Unity's Test Runner tests'), making the basic function understandable. However, it does not distinguish this tool from sibling tools like 'playtest' or 'execute_code', which could also involve running tests. The description lacks specificity about test modes or filters, which are covered only in the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. There is no mention of when to use it (e.g., for unit tests vs. integration tests), when not to use it, or any prerequisites. Siblings like 'playtest' exist, but the description offers no comparison or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes that 'clear' removes all NavMesh data and 'bake' generates the NavMesh, implying destructive potential. However, it does not explicitly warn about irreversible actions or required permissions. With only a readOnlyHint=false annotation, the description should provide more safety cues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise but uses a bullet list that is easy to scan. However, it could be better structured by grouping read vs write actions or adding a brief usage note. It is not excessively long but lacks optimal organization.
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?
Given the tool's complexity (21 parameters, 13 actions, no output schema), the description is insufficient. It does not explain how parameters are action-specific, nor what return values or side effects to expect. The agent would need to infer parameter-action mapping from parameter descriptions alone.
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?
All 21 parameters have descriptions in the input schema (100% coverage), so the schema carries the semantic load. The description adds no extra meaning about how parameters relate to actions, e.g., x,y,z are only for sample_position. Baseline 3 applies as the description does not detract.
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 'Manage Unity NavMesh navigation system' which clearly indicates the tool's domain. It lists 13 specific sub-actions, giving a good overview. However, the overall purpose is somewhat generic and could be more precise about what managing NavMesh entails beyond the listed actions.
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 other siblings like physics or terrain, nor when to choose one action over another. The description simply enumerates actions without context for selection or prerequisites, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and openWorldHint=true, but the description does not disclose potential long-running operations, file size implications, or permissions needed. It merely lists actions without behavioral warnings.
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 concise, with a front-loaded purpose and a bulleted list of actions. It could be more structured (e.g., grouping actions), but it is efficient and easy to scan.
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?
Given the tool's complexity (many actions, nested objects, no output schema), the description is incomplete. It does not explain return values or side effects for actions like 'build', 'get_report', or 'validate', leaving the agent with gaps.
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 covers all parameters with descriptions (100% coverage). The description does not add value beyond the schema, lacking context on defaults or inter-parameter relationships, but the schema is sufficient.
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 explicitly states 'Comprehensive Unity build pipeline control' and lists multiple actions, making the tool's purpose clear. However, the tool name is a noun rather than a verb, and it doesn't differentiate from sibling build tools like build_xreal_apk.
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, nor when to use specific actions. For a multi-action tool, such guidance is critical but absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The tool has readOnlyHint=false (mutation) and the description says 'configures', which implies changes. However, it does not disclose side effects like whether changes reset existing tracking, require the system to be running, or are persistent. The description adds minimal behavioral context beyond the annotation.
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 concise sentence that front-loads the verb. It avoids unnecessary details and is easy to parse, though it could be slightly more specific about the tool's domain.
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 6-parameter configuration tool with no output schema, the description is sparse. It does not explain return behavior, error states, or whether settings are applied immediately. More context about the AR image tracking domain and configuration lifecycle would improve 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%, so the schema already explains each parameter. The description only provides a high-level summary without adding new meaning, thus baseline score of 3 is appropriate.
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 configures image tracking settings and lists example parameters (how many images, quality, update frequency). This distinguishes it from sibling tools like 'add_tracking_image' or 'get_tracked_images', but does not explicitly contrast with other 'configure_*' tools.
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 on when to use this tool versus alternatives, such as when to adjust tracking parameters instead of adding images. The description lacks context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, and the description confirms it configures settings, but it does not disclose behavioral details such as whether changes take effect immediately, require a scene reload, or permissions needed.
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 sentences long, front-loaded with the core action, and no unnecessary words. Slightly more detail could be included without breaking conciseness.
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 with 8 parameters, no output schema, and minimal annotations, the description is too brief. It does not explain how settings interact, return values, or side effects, leaving the agent underinformed.
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% parameter description coverage, so the tool description does not add further meaning. Baseline of 3 applies.
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 it configures depth-based occlusion settings and explains the purpose of occlusion in mixed reality. However, it does not differentiate from sibling tools like configure_passthrough, which might have overlapping functionality.
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 provided on when to use this tool versus alternatives, or any prerequisites. It simply states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint=false, implying mutation. The description does not disclose whether actions are synchronous, have side effects, require specific permissions, or any other behavioral traits beyond the action names. For a complex tool with many actions, this is insufficient.
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 concise, starting with a one-sentence summary followed by a clear list of actions. It avoids unnecessary text and is well-structured for quick scanning.
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?
The description lacks information about parameter-action mappings, return values for getters, or process details for long-running actions like bake_lighting. Given the tool's complexity (7 parameters, nested objects, no output schema), the description is incomplete.
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 each parameter has a description in the schema. The tool description adds the action list but adds no additional meaning beyond what the enum already provides. Thus, the description adds marginal value over 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 description states 'Controls Unity lighting and rendering environment' and lists specific actions like get_settings, set_settings, bake_lighting, etc. It clearly identifies the tool's domain and primary actions, distinguishing it from sibling tools that are unrelated topics.
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. It simply enumerates actions without explaining under what circumstances each action should be chosen or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes mutating actions (start, stop, clear) yet the annotation declares readOnlyHint: true, which is a contradiction. The description does not disclose side effects or behavioral traits beyond the annotation's implication.
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 concise and front-loaded with the purpose and a list of actions. It avoids unnecessary words but could benefit from grouping related actions.
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?
With 10 parameters and no output schema, the description is insufficient. It does not explain return values, default behaviors, or how parameters interact with different actions.
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 description adds minimal additional meaning. It does not elaborate on parameter usage or relationships 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?
The description clearly states the tool controls Unity's Profiler for performance analysis, and lists specific actions (start, stop, get_frame_data, etc.), making the tool's purpose distinct from siblings like profile_xr_scene.
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 provided on when to use this tool versus alternatives (e.g., profile_xr_scene for XR-specific profiling). There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint=false, requiring the description to disclose behavioral traits. The list of actions is provided but without details on side effects, prerequisites, or return values. The description does not explain what each action does beyond its name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a bullet list, but it is dense and not well-structured for quick agent parsing. It could be more efficient by grouping related information.
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?
Given the complexity (17 parameters, multiple actions, no output schema), the description is incomplete. It does not explain which parameters are required for each action or provide usage examples, leaving the agent with insufficient 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 100%, so the base rating is 3. The description adds the list of actions but does not map parameters to specific actions or provide additional meaning beyond the schema descriptions.
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 it controls Unity Animation and Timeline systems and lists the actions, which differentiates it from sibling tools focused on other domains like lighting or physics. However, it could be more specific about the scope.
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 animation/timeline tasks but lacks explicit guidance on when to use this tool versus alternatives or when not to use it. There are no exclusion criteria or context for action selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint: false (mutation allowed). The description lists actions like open/close and lock, implying mutations, but lacks details on side effects, permissions, error handling, or return values. For a tool with many actions, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long with a bullet list of 13 actions, which is necessary but could be more concise. The structure is clear but not front-loaded; the key purpose is stated first, but the list could be trimmed by removing redundant phrasing like 'List all open editor windows' for get_windows.
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?
With 8 parameters, nested objects, and no output schema, the description should explain what each action returns and how to use parameters. It only gives one-line descriptions of actions, omitting return values and parameter details. This is insufficient for an agent to use the tool correctly without additional 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?
Input schema coverage is 100%, with descriptions for all parameters. The tool description adds little beyond listing action names; it does not elaborate on parameter usage or the complex sceneViewSettings object. Baseline score of 3 is appropriate given 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 it controls Unity Editor windows and UI elements, and enumerates 13 specific actions. This distinguishes it from sibling tools like editor_selection or play_mode, which have different purposes.
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 vs alternatives. It lists actions but does not explain when to choose this over other editor control tools or provide context for selecting specific actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a mutation (readOnlyHint=false, idempotentHint=false). The description adds that it saves to a path, but omits error conditions (e.g., if scene already exists), side effects, or permission requirements.
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?
One sentence with no wasted words, but slightly too terse for a mutation tool. Could include more context without harming conciseness.
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?
Lacks information about output (return values), error handling, and behaviors around parameter interactions. With no output schema and minimal annotations, the description should cover more for 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 coverage is 100% with clear parameter descriptions. The description adds no extra meaning beyond what the schema already 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 uses a specific verb ('creates') and resource ('new scene'), and adds the detail 'saves it to the specified path', clearly distinguishing from sibling tools like 'load_scene' or 'delete_scene'.
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 on when to use this tool versus alternatives (e.g., 'duplicate_gameobject' or 'load_scene'), nor prerequisites or consequences like overwriting existing scenes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false) indicate possible mutations. The description includes notes like 'when paused or from last exception' for get_stack_trace and 'requires external debugger' for list_breakpoints, adding some context beyond annotations. However, it doesn't detail side effects or auth requirements for other actions.
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 concise and front-loaded with the purpose. It uses a list format which is efficient for a composite tool. However, the list is somewhat lengthy but structured well.
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?
Given the tool's complexity (13 parameters, 10 sub-actions, no output schema), the description is incomplete. It lacks details on output formats, how parameters combine with actions, and typical usage patterns.
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 parameters. The description adds no additional parameter-specific meaning beyond listing actions. Baseline 3 is appropriate.
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 'Unity debugging utilities for inspection and troubleshooting' and lists specific actions, clearly indicating the tool's purpose as a composite debugging meta-tool. However, it doesn't differentiate from sibling tools like get_console_logs or watch_console.
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 vs. alternatives. It lists actions but does not explain context or exclusions. For example, it doesn't advise when to use debugger over get_console_logs for logging.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and readOnlyHint=false; the description adds that it gets or sets the selection but does not disclose the clear/add capabilities or any side effects beyond what is inferred.
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 sentence, but it is concise; however, it could be more precise by listing all supported actions.
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?
Given the complexity (5 parameters, multiple actions, no output schema), the description is too brief, lacking details on return values, usage examples, or action-specific guidance.
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 the description adds no extra meaning to parameters beyond 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 clearly states the tool operates on the Unity Editor selection with verbs 'gets or sets', but it does not mention the 'clear' and 'add' actions from the schema, and it fails to differentiate from the sibling 'select_gameobject' tool.
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 provided on when to use this tool versus alternatives like 'select_gameobject', nor does it specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies state changes (installation, configuration) matching the readOnlyHint=false annotation. However, it does not detail potential side effects like overwriting existing configurations or dependency requirements.
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?
Two sentences, clear and free of fluff. Could benefit from bullet points but remains efficient.
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?
Does not explain return values, success indicators, or expected outcomes. Missing context about how this tool relates to sibling tools like setup_xreal_project or enable_hand_tracking.
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 each parameter described. The tool's description adds no further insight into parameter usage or relationships 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 description clearly states the tool sets up the XR Interaction Toolkit and configures interaction systems, input actions, and interactors. It is specific about the resource and actions, though it does not explicitly differentiate from sibling tools like configure_hand_gestures.
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 on when to use this tool versus alternatives, such as configure_hand_gestures or enable_hand_tracking. No prerequisites or context about the setup order are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only show readOnlyHint=false, so description must disclose behavior. It lists actions but does not explain side effects, persistence, or error handling. Minimal behavioral context.
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?
Very concise: one-line purpose followed by bullet list of actions. No wasted words.
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?
Despite actions listing, the description lacks context on prerequisites, output expectations, or how actions chain. Complexity is moderate (7 params, 8 actions) and description is too sparse.
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 parameter descriptions. The description adds a list of actions but doesn't clarify which parameters correspond to each action. Baseline 3, no extra value.
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 it manages AudioMixers and AudioSources and lists 8 specific actions. It distinguishes from sibling tools which are unrelated to audio.
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?
No explicit guidance on when to use vs alternatives. The action list implies use for audio mixer operations, but no exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation (readOnlyHint=false) and open-world effects (openWorldHint=true). The description adds no additional behavioral context, such as side effects, required device state, or result feedback.
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?
A single, concise sentence that efficiently communicates the tool's function. No superfluous content.
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?
Despite rich schema and annotations, the description lacks completeness. It does not explain return behavior (no output schema), failure modes, or expected outcomes, which is important for a mutation tool affecting device settings.
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 fully documents parameters. The description lists three calibration types but does not add new insights beyond what the schema provides (e.g., parameter interactions or default behaviors). Baseline of 3 applies.
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 triggers calibration procedures for XREAL glasses, specifying three types (IPD, brightness, tracking). It uses a specific verb-resource combination and is distinct from sibling tools like 'set_tracking_mode' which are not calibration-focused.
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 on when to use this tool vs. alternatives. It does not mention prerequisites, when not to use, or differentiate from related tools like 'set_tracking_mode' or 'configure_hand_gestures'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Executes' but does not disclose side effects, required context, or consequences of execution. Annotations indicate readOnlyHint=false and openWorldHint=true, but the description adds no behavioral context beyond the bare action.
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?
A single sentence that is front-loaded and contains no extraneous words. Every word contributes to the core purpose.
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 simple tool with one parameter and no output schema, the description is minimal. It omits details about execution results, error conditions, or safety considerations, which are important given the readOnlyHint=false annotation.
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 a clear description and example for the single parameter. The description adds no additional semantic value beyond what the schema already 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?
The description uses a specific verb 'Executes' and identifies the resource as 'Unity menu item by path', clearly distinguishing it from sibling tools which cover different Unity actions like creating objects or building projects.
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 on when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or alternative tools, leaving the agent to infer usage 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true (no side effects) and openWorldHint=true (data may vary). The description adds that it returns joint positions, gestures, pinch strength, and confidence, which supplements the parameters. However, it doesn't mention that results depend on tracking state or that openWorldHint implies variability.
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?
Two sentences, front-loaded with the primary action, no filler words. Efficient and clear, though a slightly more structured format (e.g., bullet list of returned fields) could improve scannability.
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?
No output schema, but parameters are well-documented. The description covers core return data but omits error conditions, required setup (e.g., hand tracking enabled), and doesn't address the implications of openWorldHint. Adequate for a simple getter, but could be more 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 coverage is 100% (all 6 parameters described). The description includes some data fields (e.g., pinch strength) not directly in param descriptions, but doesn't elaborate on parameter behavior or defaults beyond the schema. Baseline 3 applies as schema already does the heavy lifting.
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 gets the current state of tracked hands and lists included data (joint positions, gestures, pinch strength, tracking confidence). It distinguishes from sibling hand-configuration tools like 'configure_hand_gestures' or 'enable_hand_tracking', but does not explicitly differentiate from other getters.
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 on when to use this tool versus alternatives, prerequisites (e.g., hand tracking must be enabled), or conditions that affect results. The description merely states functionality without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint: true, and the description adds the list of actions, most of which are mutating. However, it does not disclose that get_path is read-only, nor does it explain authorization needs or side effects beyond what annotations provide.
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?
Extremely concise: a single sentence listing actions. Front-loaded with purpose. No wasted words, making it efficient for an AI agent to parse.
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?
Given the complexity (9 parameters, no output schema), the description is too minimal. It does not explain how actions are selected, parameter dependencies, or what happens on success/failure. Leaves significant gaps for an AI agent.
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 description's role is reduced. It groups actions but does not map parameters to actions (e.g., which parameters are required for each action). The schema handles detail, but the description could add relational clarity.
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 it manages assets and lists specific actions (move, delete, rename, copy, create_folder, get_path), providing a specific verb and resource. It distinguishes from sibling tools by enumerating these actions, but does not explicitly contrast with other asset-related tools.
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 provided on when to use this tool vs alternatives like add_asset_to_scene or asset_import. The description lists actions but does not advise on which action to choose based on task context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, consistent with mutation. The description adds no extra behavioral context (e.g., side effects, error conditions); it merely lists actions already detailed in the schema.
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?
Single sentence efficiently captures the tool's purpose and capabilities, though it could be slightly more structured or bulleted.
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?
No output schema, so description could explain return values or state after actions. It adequately describes the tool's scope but lacks completeness for a complex 23-parameter 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?
Schema coverage is 100%, so baseline is 3. The tool description adds no further parameter details beyond the schema's per-action descriptions.
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 is for autonomous playtesting in Unity play mode, listing core actions. It distinguishes from sibling tools like play_mode or scene management by focusing on in-play interactions.
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 explicit guidance on when to use this tool versus alternatives like find_gameobjects or execute_code. The description omits context for when playtesting is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, signaling a write operation. The description confirms it triggers recompilation, but does not elaborate on potential side effects like blocking, error messages, or changes to the project state. It adds minimal value beyond the annotation.
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, clear sentence that is concise and front-loaded. However, it could be slightly more informative without sacrificing brevity, e.g., by mentioning that recompilation may take time.
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 simplicity of the tool (2 optional parameters, no output schema), the description covers the basic action. However, it lacks important context such as the duration of recompilation, that it forces a full rebuild, or how logs are structured when returned.
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 parameters 'logsLimit' and 'returnWithLogs' are already documented. The description adds no additional meaning or context for these parameters, meeting the baseline but not exceeding it.
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 verb 'Recompiles' and the resource 'all scripts in the Unity project', clearly identifying the tool's action and scope. It distinguishes from sibling tools like 'execute_code' or 'execute_menu_item' by directly addressing script recompilation.
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 provided on when to use this tool versus alternatives. There is no mention of prerequisites, expected outcomes, or scenarios where other tools (e.g., 'execute_menu_item') might be more appropriate for triggering compilation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive mutation (readOnlyHint=false). The description adds context by explaining each rendering mode's visual behavior, but does not disclose side effects on occlusion, background, or other settings when changing modes.
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 short and front-loaded with the core purpose. It is efficient with no filler, though it could be slightly more structured (e.g., bullet points) for readability.
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?
With 6 parameters (1 required), the description covers only the mode parameter. The interplay of occlusionMode, backgroundType, etc., is not explained. Schema covers definitions, but behavioral interactions are missing, leaving gaps for an agent.
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 good enum descriptions. The description adds no new parameter details beyond the main 'mode' enumeration; it merely restates what the schema already provides. Baseline 3 is appropriate.
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 sets rendering mode for XREAL and briefly explains VR, AR, MR. It distinguishes the main function from sibling tools like configure_passthrough or set_tracking_mode, but does not explicitly differentiate itself beyond the mode focus.
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 vs alternatives, nor any prerequisites or exclusions. It only states the modes, leaving the agent to infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and readOnlyHint=false. The description adds that additive loading is supported with a default false, which is useful. However, it does not disclose side effects like unloading the previous scene when additive=false, nor does it explain error conditions or folderPath resolution 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?
Two sentences convey the essential purpose and a key behavioral option with no unnecessary words. The description is front-loaded and efficient.
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 four optional parameters and no output schema, the description covers the basic mechanism but omits important details: precedence when both scenePath and sceneName are provided, behavior when additive=false (unloads current scene), folderPath usage, and potential errors. Not fully complete for complex contexts.
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 descriptions for all parameters. The description mentions loading by path or name and additive loading, but these concepts are already covered in parameter descriptions. No additional meaning is added 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 description clearly states 'Loads a scene by path or name', which identifies the verb (loads), resource (scene), and two resolution methods. However, it does not explicitly differentiate from sibling tools like create_scene or delete_scene, so it misses some sibling distinction.
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 on when to use this tool versus alternatives such as add_asset_to_scene or create_scene. The description lacks context for selecting this tool over siblings, leaving the agent to guess usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only readOnlyHint=false in annotations, the description fails to disclose behavioral traits such as destructive side effects, permission requirements, or whether actions trigger recompilation, leaving significant gaps for safe agent decision-making.
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 well-structured with a clear verb phrase, bulleted categories, and action list, but it could be more concise by avoiding redundant listing of actions already in the schema.
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 complex tool with 8 parameters, no output schema, and diverse actions, the description lacks critical context such as return format for get actions, required parameter combinations per action, and behavioral nuances like platform defaults.
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 detailed parameter descriptions, so the description adds no additional meaning beyond the schema. Baseline of 3 is appropriate as it neither harms nor helps.
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 it manages Unity scripting configuration and lists specific categories (define symbols, assembly definitions, execution order, compilation state) and actions, clearly distinguishing from sibling tools like execute_code and recompile_scripts.
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 through listing actions but does not provide explicit when-to-use or when-not-to-use guidance, nor does it differentiate from similar tools like recompile_scripts or scriptable_object.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, confirming mutation. The description adds that the system will 'detect and track this image' and 'return its pose in 3D space,' but does not disclose potential side effects (e.g., image already exists, database modifications) or permissions needed. Minimal additional behavioral context.
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 sentences, front-loaded with the primary action, and contains no unnecessary words. Every sentence adds value.
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?
The tool has 8 parameters and no output schema, yet the description ambiguously mentions 'returning its pose in 3D space'—likely referring to tracking later, not the add operation. Missing details on return value, prerequisites (image in Assets folder), and error conditions. Incomplete for a complex 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?
Schema coverage is 100% with descriptive parameter descriptions. The tool description provides overall context but does not add specific meaning beyond the schema. 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 specifies the action 'adds an image to the image tracking database' and explains the resulting behavior (detection and tracking). This clearly distinguishes it from sibling tools like 'configure_image_tracking' (settings) and 'get_tracked_images' (query).
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 the tool is used to add new tracking images but provides no explicit guidance on when to use it versus alternatives, nor any exclusions or prerequisites. Usage is inferred rather than directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutability (readOnlyHint=false), so the description adds value by mentioning optional components and fields. However, it does not disclose side effects, permissions, or return behavior, leaving gaps for a creation 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?
Single sentence, 12 words, front-loaded with the action and resource. No superfluous content. Efficient and clear.
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?
Given no output schema and 3 parameters (one required with nested objects), the description is too brief. It lacks context on what a prefab is, how field values are applied, or what happens after creation. Incomplete for an agent to use without additional knowledge.
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 descriptions for all parameters. The description aligns with the parameters but does not add extra meaning or clarify the format for 'fieldValues' or how 'componentName' is used 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 action (creates), the resource (prefab), and the optional features (MonoBehaviour script and serialized field values). It is specific and distinguishes from sibling tools like 'prefab' or 'create_scene'.
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 on when to use this tool versus alternatives like 'create_scene', 'scriptable_object', or other asset creation tools. The description does not provide context for selection or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, so mutation is expected. The description adds 'Duplicates' and 'optionally with a new name', but does not disclose side effects like position, hierarchy, or component copying. Behavior is minimally transparent beyond 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 a single, 11-word sentence that is front-loaded and concise. Every word adds value, with no redundancy or fluff.
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?
Despite simple duplication, the description omits details on parameter interaction (e.g., instanceId vs objectName conflict), hierarchy behavior, return values, and selection outcome. Given 4 parameters and no output schema, the description is incomplete.
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 fully documents all 4 parameters. The description only adds 'optionally with a new name', which aligns with the newName parameter but does not add significant meaning beyond the schema. 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 action 'Duplicates' and the resource 'GameObject', and distinguishes from siblings by mentioning 'optionally with a new name', which sets it apart from tools like delete_gameobject or update_gameobject.
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 duplicating a GameObject, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives or restrictions. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description names both read (raycast) and write (add_force) actions but does not expand on behavioral traits like side effects, permissions needed, or state persistence. Given readOnlyHint=false, the description could have added context about what modifications entail (e.g., gravity changes affect all objects). The lack of such detail limits transparency.
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 concise: one header sentence followed by a compact list of actions with one-line descriptions. It front-loads the purpose. However, the list format could be better structured (e.g., grouping reads vs writes). Still, no wasted words.
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 high complexity (21 parameters, 15 actions, no output schema), the description lacks information on return structures, error handling, or behavior of unmentioned combinations. The schema covers parameters well, but the description doesn't fully compensate for missing output schema or complex interactions.
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?
Input schema has 100% description coverage for all parameters. The tool description adds no additional parameter meaning beyond listing actions in the description, which maps to the action enum. Baseline of 3 applies because schema does the heavy lifting.
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 controls Unity Physics system and lists 15 specific actions (raycast, simulate, add_force, etc.), distinguishing it from siblings like physics2d. The verb-resource pair is specific: 'Unity Physics system control and queries'.
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?
No explicit when-to-use or when-not-to-use guidance. The description lists actions but doesn't indicate which action to choose for a given scenario or when to use this tool over other physics-related tools (e.g., physics2d). The agent must infer usage from action names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description names actions like 'apply_overrides' and 'revert_overrides', which imply mutability, but does not elaborate on side effects, permissions, or destructive potential beyond the annotation 'readOnlyHint: false'.
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 a clear list of actions. Every sentence serves a purpose with no unnecessary text.
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?
Given the tool's complexity with 9 actions and 8 parameters, the description lacks essential mapping of required parameters per action, leaving the agent without enough context to correctly invoke sub-actions.
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% coverage with descriptions for each parameter, so the tool description adds no additional meaning. The description merely lists actions without linking parameters to specific actions.
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 'Advanced Unity prefab operations' and lists 9 specific actions, effectively communicating the tool's purpose and distinguishing it from sibling tools like 'create_prefab' which focuses on creation.
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 explicit guidance on when to use this tool versus alternatives is provided. The description lists actions but does not compare with siblings such as 'create_prefab' or 'update_gameobject', leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the tool is clearly read-only and safe. The description adds specific analysis areas but no additional behavioral traits (e.g., permissions, side effects, or limitations).
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?
Description is a single sentence that efficiently conveys purpose and scope. It is front-loaded with the core action, but the list of checks could be more structured. No extraneous words.
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 8 optional parameters and no output schema, the description lacks details on default behavior (all analyses run by default) and output format (just 'recommendations'). It is adequate but leaves important context unaddressed.
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 covers all 8 parameters with descriptions, achieving 100% coverage. The tool description does not add new information about parameters beyond the schema, so it meets the baseline but does not enhance understanding.
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?
Description clearly states the tool analyzes the current scene for XR performance issues and lists specific checks. It distinguishes itself from sibling tools like 'get_xr_performance_metrics' by offering recommendations beyond raw metrics.
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 explicit guidance on when to use this tool versus alternatives (e.g., 'profiler', 'get_xr_performance_metrics'). The description implies usage for performance profiling but does not state when not to use it or provide comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, and the description lists mutating actions (create, duplicate, set_property), but lacks additional behavioral details like permission requirements, side effects, or failure modes.
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?
Description is concise with a clear introductory sentence followed by a list of actions; it is efficient but could be slightly more structured (e.g., grouping actions).
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?
Covers main actions but lacks comprehensive context for each action's behavior, return values, or edge cases; no output schema, so more detail 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 parameters are already documented. The description adds no extra semantics or examples beyond the 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 clearly states it manages Unity ScriptableObjects and lists specific actions (create, get_properties, etc.), distinguishing it from generic asset or script management tools like 'manage_asset' or 'script_management'.
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 on when to use this tool versus alternatives; it does not mention when not to use it or provide context for selecting among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, matching the description's 'Sends' action. The description adds no further behavioral details (e.g., side effects, rate limits, or confirmation). With annotations already covering the write nature, a score of 3 is appropriate.
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?
A single, clear sentence with no unnecessary words. Every word adds value, and it front-loads the core action.
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 simplicity of the tool (no output schema, 2 params), the description is mostly complete. It captures the purpose and the schema handles parameter details. The only minor gap is the lack of explicit mention of Unity console, but it's implied by the name.
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 both parameters adequately described in the schema. The tool description adds no additional meaning beyond the schema, so baseline 3 is correct.
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 'Sends' and resource 'console log messages', making the tool's purpose clear. However, it does not explicitly differentiate from sibling tools like get_console_logs, though the name and context imply it's for sending.
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 provided on when to use this tool versus alternatives like get_console_logs or watch_console. The description does not mention prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation, and the description 'Adds' aligns. However, it omits details like side effects, failure conditions, or behavioral constraints beyond the bare action.
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?
Single sentence with 10 words, front-loaded and efficient, no fluff.
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?
With 5 parameters and no output schema, the description covers the core function but misses context on parameter relationships (e.g., guid vs assetPath) and return behavior.
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 baseline is 3. The description adds no additional meaning 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 'Adds an asset from the AssetDatabase to the Unity scene' provides a specific verb, resource, and destination, clearly differentiating it from sibling tools like load_scene or manage_asset.
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 on when to use this tool versus alternatives (e.g., create_prefab, prefab) or prerequisites (e.g., asset must exist in AssetDatabase).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnlyHint=false (write operation) and openWorldHint=true (potential side effects). The description adds no further behavioral context, such as error conditions or side effects, but does not contradict 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 a single concise sentence that efficiently conveys the tool's purpose without unnecessary words. It is front-loaded and to the point.
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?
While the schema fully describes parameters, the description lacks an overview of behavior (e.g., different source types, requirements). Minimal but functional given sibling 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 100% with all parameters documented. The description does not elaborate on parameters, but baseline is 3 given 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 uses a specific verb ('Adds') and resource ('packages into the Unity Package Manager'), clearly distinguishing it from sibling tools like 'add_asset_to_scene' or 'add_external_dll'.
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 provided on when to use this tool versus alternatives, nor are any conditions or prerequisites mentioned. The description simply states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false), and the description's verb 'Adds' aligns with that. The description adds behavioral context about the interactors' capabilities (ray casting/direct touch) but does not disclose side effects like potential game object modifications or dependencies on XR setup.
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 extremely concise at two sentences, with the action front-loaded in the first sentence and purpose added in the second. No filler or redundant information.
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 complexity (11 params, 4 enum types) and the lack of an output schema, the description provides basic high-level context but lacks details on expected behavior, constraints, or how it fits with sibling tools. It is adequate but not 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?
All 11 parameters have descriptions in the schema (100% coverage), so the description adds no extra parameter-level context. The baseline is 3, and the description does not enhance understanding of parameter usage beyond what the schema already 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?
The description clearly states the action ('Adds XR interaction components to a GameObject') and differentiates from sibling tools like 'setup_xr_interaction' by specifying component-level addition rather than system setup. It also provides context on what interactors enable (selection/manipulation), making the purpose unambiguous.
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 does not provide any guidance on when to use this tool versus alternatives, nor does it specify prerequisites or exclusions. The mention of 'via ray casting or direct touch' gives limited context but no comparative decision framework.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false), consistent with 'configures'. The description adds no further behavioral traits beyond what annotations provide, such as side effects or persistence.
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 concise sentence, but could be slightly more structured to include key capabilities. It is front-loaded and to the point.
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?
No output schema, so the description should hint at return behavior or side effects. It lacks mention of prerequisites like hand tracking being enabled. Incomplete for a configuration tool with 6 parameters.
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 parameters are well-documented in the schema. The description provides a high-level summary but adds minimal meaning beyond the existing parameter descriptions.
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 configures recognized hand gestures and sensitivity, listing examples like pinch, grab, point. It distinguishes from sibling tools like enable_hand_tracking and get_hand_state.
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?
No explicit guidance on when to use this tool versus alternatives or prerequisites (e.g., hand tracking must be enabled). The description implies configuration use but lacks context for proper selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds persistence and real-world positioning beyond the readOnlyHint annotation. However, it does not disclose error behavior on duplicate names, side effects, or required settings.
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?
Two succinct sentences with no wasted words. Could be more structured but is efficient.
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?
No output schema, no mention of return value. Lacks behavioral context for 8 parameters, such as what happens if anchorName already exists or if attachToPlane fails.
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 parameters are documented. Description provides a high-level summary but adds minimal detail beyond what's in 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 action (creates), resource (spatial anchor), and options (specified position or detected plane). It distinguishes from sibling tools like 'manage_spatial_anchors' which handle existing anchors.
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?
Implied usage for creation, but no explicit guidance on when to use this vs alternatives (e.g., manage_spatial_anchors). Missing prerequisites like plane detection being enabled for attachToPlane.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies mutation (controls) consistent with annotations (readOnlyHint: false). However, it does not disclose behavioral traits beyond what annotations provide, such as whether entering play mode recompiles scripts or affects unsaved scenes.
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 one sentence that lists all actions efficiently. It is front-loaded with the verb 'controls' and provides a clear list. No redundant 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?
For a simple tool with one parameter and no output schema, the description adequately covers the actions. It does not explain return values for 'get_state', but given the lack of output schema, this is a minor gap. Overall, it is complete enough for the tool's complexity.
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 already describes the single parameter 'action' with an enum and description. The tool description repeats the enum values but adds no additional meaning beyond what the schema provides. Schema coverage is 100%, so 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 explicitly lists the specific actions ('enter', 'exit', 'pause', 'unpause', 'step', 'get_state') and states it controls Unity Editor play mode. It clearly distinguishes from sibling tools like 'editor_control' which likely has a broader scope.
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 such as 'debugger', 'playtest', or 'execute_menu_item'. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lists both read actions (get_info, list) and write actions (set_import_settings, create_atlas, etc.), which aligns with the annotation readOnlyHint=false. However, it does not disclose potential side effects (e.g., destructive slicing, permanent atlas packing) or prerequisites (e.g., asset existence). The behavioral traits are implied but not explicitly stated.
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 well-structured with a clear opening sentence followed by a bulleted list of actions. It is front-loaded with the purpose. While the list is long, it efficiently conveys all capabilities without unnecessary words. A minor improvement would be to group read and write actions, but overall it is appropriately sized.
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?
Given the tool's complexity (28 parameters, no output schema, 10 actions), the description is incomplete. It does not explain return values for any action, nor does it provide workflow examples or context on when each action is appropriate. The list of actions alone is insufficient for an agent to understand usage patterns.
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% coverage (all 28 parameters have descriptions), so the schema alone provides parameter meaning. The tool description adds no extra parameter details—it only lists actions, which correspond to the action enum already in the schema. Thus it meets the baseline expectation but adds no additional 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 clearly states the tool's purpose: 'Manage Unity Sprites and SpriteAtlases.' It then lists ten specific actions covering read and write operations, which leaves no ambiguity about what the tool does. It distinguishes itself from sibling tools by being the only sprite-focused tool among many.
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 implicitly defines usage by listing all sprite-related actions, suggesting the tool is for any sprite or atlas operation. However, it provides no explicit guidance on when to use this tool versus alternatives like 'asset_import' for texture imports, nor does it specify when not to use it (e.g., for non-sprite textures).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the creation behavior (if GameObject missing), which is good. However, it does not disclose side effects, error handling, or behavior when both instanceId and objectPath are provided. Annotations indicate non-read-only, but the description carries most of the burden.
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 no filler. The key information (verb, resource, alternative identifiers, creation behavior) is front-loaded.
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 and no output schema, the description covers basic purpose and creation nuance but omits return value, error conditions, and behavior for missing instanceId. It is adequate but not comprehensive.
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 each parameter already has a description. The description adds context about creation tied to objectPath, but does not further clarify the relationship between instanceId and objectPath or the structure of gameObjectData.
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 updates GameObject properties via instance ID or path, and includes the notable creation behavior. This distinguishes it from sibling tools like get_gameobject, delete_gameobject, etc.
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 explicit guidance on when to use this tool vs alternatives like get_gameobject or delete_gameobject. It does not mention prerequisites, when-not to use, or alternative approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate write operation (readOnlyHint=false). Description adds context about passthrough concept but doesn't disclose behavioral details like immediate effect, side effects, or limitations.
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 sentences, front-loaded with core purpose, no wasted words. Efficiently communicates the tool's function.
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?
With 8 parameters, schema covers them all, and annotations provide readOnlyHint. Description explains the concept sufficiently. No output schema but not critical. Slightly lacking in operational context (e.g., persistence of settings).
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 provides 100% coverage with descriptions for all 8 parameters. Description adds no parameter-specific meaning, 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?
Description clearly states the tool configures camera passthrough for mixed reality, and explains what passthrough does (shows real world with virtual overlays). This distinguishes it from siblings like 'configure_occlusion' which handles a different aspect.
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 on when to use this tool vs alternatives like 'configure_occlusion' or other configuration tools. Doesn't mention prerequisites or scenarios where passthrough should not be altered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, so the tool is a mutation. The description adds context by stating it 'adds components' and 'sets up colliders and scripts', which reveals non-obvious side effects. However, it does not mention potential irreversible changes, performance impact, or required permissions. Given annotations already signal mutation, this is adequate but not exceptional.
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 sentences, each adding value: first states the primary action, second clarifies what it sets up. No redundant words. Optimal length for conveying the core purpose.
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 has 11 parameters and no output schema, the description provides adequate context for the overall behavior. The schema handles parameter details. It could mention interaction types briefly, but the description remains sufficient for basic understanding. Missing usage guidelines are the main 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?
Input schema covers 100% of parameters with descriptions and defaults. The tool description does not add further detail about parameters beyond the schema. This meets the baseline expectation but does not enhance understanding.
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 adds hand interaction components to a GameObject, enabling hand gesture responses like pinch-to-grab, poke, or hover. It specifies it sets up colliders and interaction scripts, making the tool's purpose unmistakable. Among sibling tools, none directly duplicate this functionality, so it distinguishes well.
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 (e.g., add_xr_interactor) or any prerequisites (e.g., GameObject must exist). It does not mention when not to use it or what happens if parameters are omitted. The agent lacks context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the toggle behavior (enable/disable) and use cases, which aligns with the readOnlyHint=false annotation. However, it lacks deeper behavioral context such as whether disabling removes existing meshes, performance impact, or permission requirements.
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 sentences: the first states the action and resource, the second lists use cases. It is concise, front-loaded, and contains no unnecessary 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?
Given the tool has 9 parameters including a nested object, the description is succinct but covers the core functionality. The full schema documentation compensates for lack of detail about optional parameters. Slightly more context about when to adjust parameters would improve 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?
With 100% schema description coverage, the schema already fully documents all parameters. The description adds no additional insight beyond the schema, 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 clearly states the verb (Enables or disables) and resource (spatial meshing), and explicitly lists use cases (occlusion, physics collisions, spatial understanding). It distinguishes from sibling tools like 'enable_hand_tracking' or 'configure_occlusion' by focusing on mesh generation.
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, no prerequisites, and no exclusions. It simply states the function, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to cover those. The description adds that it searches by multiple criteria, which is useful but does not disclose behavioral details like wildcard support, pagination (maxResults), or whether inactive objects are included by default (these are in schema but not description). With annotations, the bar is lower, and the description 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?
The description is a single concise sentence that front-loads the key action and resources. Every part is essential, no fluff 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?
Given the existence of an output schema and full parameter documentation, the description is mostly complete. It clearly conveys the core functionality. However, it does not explicitly mention that results are returned as a list or how maxResults affects pagination, though these could be inferred from the schema. Slight room for improvement, but overall adequate.
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 all parameters are already documented in the schema. The description only lists the parameter categories (name pattern, tag, layer, component type) without adding new meaning or format details beyond what the schema provides. 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 verb 'finds', the resource 'GameObjects', and the filtering criteria (name pattern, tag, layer, or component type). It effectively distinguishes itself from sibling tools like 'get_gameobject' or 'select_gameobject' by focusing on search/filtering.
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 does not provide any guidance on when to use this tool versus alternatives (e.g., when to use 'get_gameobject' instead), nor does it mention any prerequisites or exclusions. It simply states what the tool does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds context about pagination preventing token limits, which is useful but does not contradict annotations. Lacks disclosure of any additional behavior such as rate limits or return format, but output schema covers return structure.
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 unnecessary words. Every element serves a purpose: states the action, resource, and key feature (pagination for token limits).
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 presence of a comprehensive input schema (100% coverage) and an output schema, the description adequately summarizes the tool's core purpose. It does not need to explain return values due to the output schema. Slightly missing mention of optional filtering by log type, but this is evident from the schema.
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 baseline is 3. The description only reiterates the token-saving aspect already detailed in parameter descriptions (e.g., limit, includeStackTrace). It adds no new semantic meaning beyond what the schema 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 clearly states the tool retrieves logs from the Unity console with pagination support. It effectively distinguishes from siblings like 'send_console_log' (sending) and 'watch_console' (real-time monitoring) by focusing on retrieval and pagination, though it doesn't explicitly contrast with alternatives.
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 when logs are needed and token limits are a concern, but provides no explicit guidance on when not to use this tool or alternatives. No prerequisites or context for selection among siblings like 'watch_console' for real-time logs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds that metrics are 'real-time' but does not disclose other behavioral traits (e.g., whether a running XR session is required, if data comes from device or simulation). Not contradictory, but minimal added value beyond annotations.
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?
Two sentences, front-loaded with the core purpose. The second sentence is somewhat generic but not wasteful. Could be slightly more efficient, but overall concise.
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?
No output schema, but description lists the types of metrics. It does not mention the return format or clarify that all parameters are optional (though defaults are in schema). Adequate but could provide more 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?
All 7 parameters have 100% schema coverage with descriptions and defaults. The tool description does not add any extra meaning beyond the schema, so 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?
Clearly states the tool 'gets real-time XR performance metrics' and lists specific metrics (frame rate, GPU/CPU usage, etc.), making the purpose unambiguous and distinct 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions it is 'essential for optimizing mobile XR experiences,' implying when to use, but does not specify when not to use or provide alternatives like profile_xr_scene. Lacks explicit guidance on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, consistent with the write operations described. The description lists actions but does not elaborate on side effects, authentication needs, or error conditions. It adds moderate context beyond 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?
Two concise sentences that are front-loaded with the core purpose. Every sentence adds value without redundancy.
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?
Despite no output schema, the description does not explain return values or behavior for each action. For a tool with 6 parameters and nested objects, more context (e.g., what happens on save/delete) 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 baseline is 3. The description does not add additional meaning beyond what the schema already provides for parameters like 'action', 'filter', etc.
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 verb 'manages' and the resource 'spatial anchors', listing specific actions (load, save, delete, query). This distinguishes it from sibling tools like 'create_spatial_anchor' which focuses on creation.
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 phrase 'Essential for persistent MR experiences' implies usage context but does not explicitly state when to use this tool versus alternatives like 'create_spatial_anchor'. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lists actions but does not disclose behavioral traits beyond what the annotations already provide. Annotations indicate readOnlyHint=false, consistent with write actions. However, the description lacks details on side effects (e.g., permanent changes to physics settings), authorization needs, or limitations (e.g., physics engine must be enabled). With only a list of action names and one-line summaries, transparency is low.
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 well-structured with a brief intro followed by a bullet list of actions. It front-loads the core purpose. While the list is long, it is necessary given the tool's complexity. Every sentence adds value; no redundancy. Slightly verbose but efficient for the scope.
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 all actions but lacks context on how to sequence them, prerequisites (e.g., existing GameObjects for adding components), or return values. Without an output schema, the description does not explain what each action returns. For a complex tool with 35 parameters, more guidance on typical usage patterns would improve 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%, so every parameter has a basic description. The tool description adds no additional parameter-level detail beyond listing action options. Baseline of 3 is appropriate because the schema already provides the necessary semantics, and the description does not enhance understanding of parameters.
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 starts with 'Manage Unity 2D Physics: rigidbodies, colliders, raycasts, joints, effectors.' clearly stating the tool's purpose and domain. It distinguishes from the sibling tool 'physics' by explicitly mentioning 2D, which is the key differentiator. The list of actions further specifies what can be done, leaving no ambiguity about the tool's scope.
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 implicitly guides usage by labeling the tool as '2D Physics,' which tells an agent to use this for 2D physics tasks and likely the sibling 'physics' for 3D. However, it does not explicitly state when not to use this tool or provide direct comparisons with alternatives. The list of actions itself gives context for which action to pick based on the task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint: false indicates potential write operations, and the description confirms 'set (modify settings)'. However, it does not disclose possible destructive consequences of modifying settings, whether changes are reversible, or if specific permissions are required. With no further annotations, the description should provide more behavioral context for a mutation 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 concise: two short sentences. The first sentence states the purpose, the second lists actions and categories. No redundant information. Front-loaded with essential info.
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?
Despite having a clear purpose and schema, the description lacks details about the output format for 'get' and 'list_categories' actions. Given no output schema, the agent does not know what shape of data to expect. Additionally, there is no mention of how to use the 'settings' parameter (key-value pairs) in the description, although the schema covers it. The description should provide more complete guidance for a tool with multiple actions.
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 descriptions for all parameters, so the baseline is 3. The description adds value by listing the actions and categories, which correspond to the 'action' and 'category' parameters, but it does not add meaning beyond what the schema already provides. The mapping is clear but not enhanced.
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 manages Unity Project Settings, lists the exact actions (get, set, list_categories), and enumerates the supported categories (player, quality, etc.). It distinguishes itself from sibling tools which are more specific to individual features (e.g., physics, animation) by covering a broad umbrella of settings.
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 lists the actions and categories, so an agent knows what operations are possible. However, it does not explicitly state when to use this tool versus more specific tools (e.g., for physics settings, should one use project_settings or the physics tool?). It provides clear context but lacks explicit exclusion criteria or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and readOnlyHint=false, so the description adds no additional behavioral context beyond confirming the mutation. The description does not contradict the 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?
A single, complete sentence that efficiently conveys the tool's action without unnecessary words. Perfectly front-loaded.
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 simplicity, the description is sufficient. It lacks any mention of return value, but that is acceptable since no output schema exists and the action is inherently a set operation.
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 the parameters are fully described in the schema. The description merely echoes that selection is by path, name, or instance ID, adding no extra syntax or constraints.
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 sets the selected GameObject in the Unity editor using path, name, or instance ID. It is a specific verb-resource pair that distinguishes it from sibling tools like get_gameobject or delete_gameobject.
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 provided on when to use this tool versus alternatives such as get_gameobject or update_gameobject. The agent receives no context about prerequisites or situations where this tool should be chosen over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=false, indicating a write operation. The description adds behavioral context (sets up scaling, raycasting, visual settings) but does not disclose side effects, permissions, or error conditions. Sufficient but not thorough.
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 no redundancy. The first sentence states the primary action, the second adds key behavioral details. Efficient 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 13 parameters and no output schema, the description provides a reasonable overview but omits details about return values, failure modes, or confirmation of creation. Adequate but not exhaustive.
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 each parameter has its own description. The tool description adds high-level context but no additional parameter-level details beyond the schema. 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 it creates a world-space UI canvas for XR interaction, with specific details about scaling and raycasting. This differentiates it from sibling tools like create_hand_interactable or create_xr_rig.
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 creating XR UI canvases but offers no explicit guidance on when to use this tool versus alternatives, nor does it state prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnlyHint annotation (false): it explains what happens when enabled (tracks hand poses, joint positions, recognizes gestures). It does not mention destructive actions, authorization needs, or rate limits, but the mutation nature is clear. The description adds moderate value beyond 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 two sentences, front-loaded with the primary purpose and quickly adding context. Every word is informative, and no extraneous details are present. Excellent conciseness.
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 has 6 parameters, all well-documented in the schema, and no output schema. The description provides a general overview but does not explain key parameters like 'trackedHands', 'trackingMode', or visualization options. For a complex tool, additional context about parameter defaults or use cases would improve 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%, so the schema already documents all 6 parameters. The tool description does not add new meaning to parameters; it only summarizes the overall behavior. Since the schema is thorough, the description adds minimal additional semantic value, matching the baseline of 3.
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 purpose: enabling or disabling hand tracking on XREAL glasses. It specifies the resource ('hand tracking') and the action ('enables or disables'), and distinguishes from sibling tools like 'configure_hand_gestures' and 'get_hand_state' by focusing on the master toggle.
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 mentions it is 'Required for hand-based interactions,' implying when to use it. However, it does not explicitly state when not to use it or provide alternatives among siblings (e.g., 'configure_hand_gestures' for gesture-specific settings). Usage guidance is implied but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, consistent with the mutation described. However, the description does not disclose behavioral traits such as side effects on the spatial mapping system, whether prior state matters, or if enabling plane detection impacts performance. With only one annotation, the description should provide more context but remains minimally adequate.
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 sentences with no redundant information. It is front-loaded with the primary action and then details the surfaces detected. This is efficiently concise.
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 has 9 parameters, no output schema, and the description does not explain return values or state changes (e.g., whether previously detected planes are cleared), the description is somewhat sparse. It covers the basic toggle action but lacks completeness for an AI agent to fully understand the tool's impact without additional 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?
Since schema description coverage is 100%, the parameters are fully documented in the schema. The description adds no additional parameter-level details beyond the overview of detection types. Baseline 3 is appropriate as the description does not reduce cognitive load but also does not mislead.
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 enables or disables plane detection for spatial mapping, specifying detection of horizontal (floors, tables) and vertical (walls) surfaces. This is a specific verb+resource with clear scope, and it distinguishes from sibling tools like enable_meshing or get_detected_planes.
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 when plane detection is needed, but it provides no explicit guidance on when to use this tool vs alternatives (e.g., when to use enable_meshing instead), no prerequisites, and no conditions where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description enumerates actions that modify state (undo, redo, clear, record_object, flush) and a read-only action (get_history), going beyond the annotation readOnlyHint=false. It does not contradict annotations.
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 moderately sized with a clear bulleted list of actions. It could be more concise by grouping similar actions, but it is not overly verbose.
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 has multiple actions and no output schema, the description covers each action's purpose adequately. It provides enough context for an agent to understand the tool's capabilities.
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 the schema adequately describes parameters. The description adds no additional meaning beyond the action list. 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 controls Unity's Undo/Redo system, listing all supported actions. This verb+resource description distinguishes it from sibling tools like animation or play_mode.
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 provided on when to use this tool versus alternatives. There is no mention of when to prefer undo_redo over other tools that might affect scene state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the description's mention of deletion aligns. It adds the context of removing the scene from Build Settings. However, it does not clarify whether deletion is permanent or if the scene file is removed from the project entirely, leaving some 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 concise sentence of 12 words, front-loading the action and object. Every word is necessary and there is no 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 deletion tool with annotations indicating destructiveness, the description covers the primary action and a secondary effect (Build Settings removal). It could be enhanced by explicitly stating irreversibility, but overall it is sufficient for understanding the tool's purpose and effect.
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% coverage with clear parameter descriptions. The description reiterates that deletion can be 'by path or name' but does not add new semantic meaning beyond what the schema already provides, so it meets the baseline.
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 action 'Deletes a scene' and the specific method 'by path or name', differentiating it from sibling tools like `load_scene` or `create_scene` which have different purposes. It also notes the additional effect of removing from Build Settings.
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 does not explicitly state when to use this tool versus alternatives or provide context for exclusion. It is implicit that you use it to delete scenes, but no guidance is given on prerequisites or scenarios where other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds that it returns image data or saves to a file, which is useful but does not elaborate on side effects like file creation or performance impact. Behavioral disclosure is adequate but not detailed.
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 sentences cover the main action and use cases with no wasted words. The description is front-loaded with the core purpose, making it efficient for an AI agent to parse.
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 has 6 parameters, no output schema, and many siblings, the description covers the key aspects: core function, use cases, and behavior. It lacks details on return format when not saving, but annotations and schema compensate partially.
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 fully documents all 6 parameters. The description adds minimal value beyond restating the save-to-file behavior. 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 captures a frame from the XREAL RGB camera, with specific verb and resource. It distinguishes itself from siblings like capture_xr_screenshot and get_tracked_images by focusing on raw camera frames for computer vision and AR development.
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 context (for computer vision, debugging image tracking) but does not explicitly state when to use this tool instead of alternatives like capture_xr_screenshot or get_tracked_images. Usage is implied rather than clearly delineated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's claim of 'Gets' is consistent. The description adds detail on returned data (detected, poses, quality) but no additional behavioral context like auth requirements or rate limits, which is acceptable given annotation coverage.
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?
Single sentence that is front-loaded with the core action and resource, containing no filler. Every word contributes to understanding.
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 query tool with 5 parameters and no output schema, the description covers the main purpose and outputs. It could mention the return format or filtering options, but the parameters handle filtering implicitly. Overall, adequate.
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 description adds minimal extra meaning beyond what the schema already provides. It mentions 'poses' and 'tracking quality', which maps to parameters like includePose and trackingState, but does not elaborate on syntax or usage.
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 verb 'Gets' and the resource 'current state of tracked images', listing specific aspects: which images are detected, poses, and tracking quality. It distinguishes from sibling tools like 'add_tracking_image' (adds) and 'configure_image_tracking' (configures).
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 querying tracking state but lacks explicit guidance on when to use versus alternatives like 'get_detected_planes' or 'get_hand_state'. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, and the description lists both read and write actions, disclosing mutability. No contradictions with annotations. However, it does not explicitly state which actions are destructive or their side effects beyond the brief action descriptions.
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 opens with a clear one-line purpose, followed by a structured list of actions. While the list is somewhat lengthy, it is well-organized and front-loaded. Each action description is concise.
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 complexity (20 parameters, 13 actions) and lack of output schema, the description provides only high-level action summaries. It does not specify parameter requirements per action or return values, leaving gaps for correct invocation.
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, so the baseline is 3. The description adds context by grouping parameters under actions, but does not explain parameter relationships or provide additional meaning beyond the 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 clearly states 'Manage Unity Tilemaps for 2D level design' and enumerates 13 specific actions, making the tool's purpose unambiguous. It distinguishes itself from sibling tools, none of which target tilemaps.
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 use for tilemap operations but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusion criteria. The sibling list is diverse, so the tool is clearly specialized, but no usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, implying modification. The description adds a caution for 'reimport_all' but does not disclose other behavioral traits like side effects, authorization needs, or error handling. It provides minimal additional value beyond 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 and front-loaded with the main purpose. It uses bullet points effectively to enumerate actions and types, with no redundant or verbose content. Every sentence serves a 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?
Given the tool's complexity (8 parameters, nested objects, no output schema), the description covers the scope well but lacks return value descriptions and error conditions. The detailed parameter schemas compensate partially, but completeness is average.
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%, so the schema documents all parameters. The description adds value by grouping actions and asset types, providing context for the 'action' enum and 'assetType' parameter. This aids understanding beyond raw parameter 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 clearly states it manages Unity asset import settings and reimport operations, listing specific actions and asset types. It distinguishes itself from sibling tools by focusing solely on import-related tasks.
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 lists actions but does not provide explicit guidance on when to use this tool versus alternatives or how to choose among actions. Usage is implied from the action names, but no exclusion criteria or context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description accurately indicates the tool creates a new GameObject (write operation) without contradicting the readOnlyHint=false annotation. It specifies the components set up, but could add more detail about scene impact (e.g., 'adds to current scene'). No contradiction found.
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 concise with two sentences covering the core action and key setup details. It front-loads the purpose but could improve by listing configurable aspects more explicitly.
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 (11 parameters, nested objects) and absence of an output schema, the description adequately summarizes the creation scope. However, it omits what the tool returns (e.g., the GameObject) and scene-level implications.
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 baseline is 3. The description does not add extra semantic meaning beyond the schema; it only provides a high-level overview without parameter-specific detail.
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 creates an XR Origin configured for XREAL One Pro, naming specific components (HMD camera, hand tracking origins, interaction components). This clearly distinguishes it from sibling tools like create_scene or create_prefab.
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 lacks explicit guidance on when to use this tool versus alternatives like setup_xreal_project or create_xr_ui. While the purpose is clear, no usage context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true, so the description adds value by detailing the returned data (positions, orientations, boundaries, classifications). It does not contradict the annotations and provides context beyond what annotations alone offer.
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 extremely concise: two sentences with no redundancy. It is front-loaded with the purpose and follows with specifics. Every sentence contributes meaningfully.
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?
Despite no output schema, the description lists the returned data types. However, it does not mention preconditions (e.g., that plane detection must be enabled) or potential performance considerations. Given the tool's simplicity and good annotations, it is adequate but not 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 100% coverage with descriptions for all six parameters, so the description adds little new information about parameters. It indirectly relates to some parameters (e.g., classification) but does not directly explain them. 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's purpose: 'Gets information about all currently detected planes in the environment.' It specifies what is returned (positions, orientations, boundaries, classifications), making it easy for an AI agent to understand the action and resource. The sibling tools are unrelated, so no confusion.
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 does not provide explicit guidance on when to use this tool versus alternatives. It is implied that it should be used when plane detection data is needed, but no exclusions or conditions are mentioned. With many siblings not related to plane detection, this is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Each action has a one-line description that indicates its effect (e.g., 'flatten' says it flattens to uniform height). The readOnlyHint annotation is false, consistent with the mutating actions. However, deeper behavioral details (e.g., performance, undo support) are absent.
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: a single introductory line followed by a bullet list of actions. Every sentence provides useful information with no redundancy.
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 complexity (26 parameters, 12 actions), the description lacks explicit mapping of parameters to actions. The schema partially compensates by noting which action a parameter applies to (e.g., 'width (create)'), but the description could be more 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 coverage is 100%, so the schema describes each parameter. The description adds no additional parameter semantics; it only lists actions. 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 'Manage Unity Terrains' and lists 12 specific actions, each with a brief explanation. It distinguishes this tool from siblings as the only terrain-related tool among many.
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 does not explicitly state when to use this tool versus alternatives, but since no sibling tool handles terrain, usage is implied. There is no guidance on which action to choose or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation (readOnlyHint=false). Description adds value by explaining the add-if-missing behavior, which is a key behavioral trait not inferred from annotations. Discloses that the tool may create a component, which is important for agent understanding.
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?
Single sentence that is concise, informative, and front-loaded. No unnecessary words. Every part contributes to understanding the tool's function.
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?
No output schema exists, and description does not hint at return value (e.g., success/error, updated component). With a nested object parameter (componentData), more guidance on expected structure would improve completeness. Overall adequate for basic use but leaves some gaps.
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 descriptions for all 4 parameters. Description does not add detailed semantics beyond schema, but effectively summarizes the overall purpose. For componentData, schema defines it as an object, but description offers no additional guidance on structure or constraints. 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?
Description clearly states it updates component fields or adds the component if missing. Specific verb 'updates' and resource 'component on a GameObject' with clear dual behavior. Distinguishes from sibling tools like update_gameobject that handle other properties.
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?
No explicit guidance on when to use this tool versus alternatives like update_gameobject or delete_gameobject. Does not indicate scenarios where adding is preferred over updating, nor how to choose between instanceId and objectPath. Usage is implied but not clearly delineated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that most actions are mutating (readOnlyHint=false) and mentions requirements and constraints. It aligns with annotations (readOnlyHint=false, openWorldHint=true) and adds context about caching and server interactions, though specific side effects per action are not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear summary, but the full list of all 12 actions repeats information from the schema enum. This makes it longer than necessary while still being organized. A more concise listing or referencing the schema would improve structure.
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, multiple sub-actions, no output schema), the description covers overall purpose, prerequisite conditions, and which actions work without authentication. It lacks details on return values per action but provides sufficient context for an AI agent to understand the tool's capabilities.
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 minimal insight beyond parameter names; the note about Unity version and authentication is valuable but not linked directly to parameters. The nested importOptions object is only briefly described.
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 manages Unity Asset Store assets and Package Manager integration, with a specific verb and resource. It distinguishes from siblings like 'manage_asset' by focusing on the Asset Store, and the listed actions reinforce the scope.
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 explicit prerequisites (Unity 2020.1+, logged into Hub/Editor) and notes which actions need authentication and that assets must be purchased before downloading. It doesn't explicitly mention when not to use or alternatives, but the guidance is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, and the description clearly states it configures settings, implying mutation. The description adds context about optimization for specific hardware but doesn't detail side effects or permissions. Still, it is fairly transparent.
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 sentences, no fluff. First sentence states purpose and target device, second lists key settings. Front-loaded and efficient.
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 13 parameters with full schema coverage and no output schema, the description adequately covers the tool's purpose and key behaviors. It could mention that the tool sets recommended defaults customizable by parameters, but it is sufficiently 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 coverage is 100%, so baseline 3. The description highlights key parameters (ARM64 architecture, IL2CPP, minimum API level) but does not add significant meaning beyond what the schema already provides for all 13 parameters.
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 configures Android build settings optimized for a specific device (XREAL One Pro on Samsung S24) and lists key settings (ARM64, IL2CPP, minimum API), clearly distinguishing it from sibling tools like 'build_pipeline' or 'build_xreal_apk'.
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 XREAL One Pro on Samsung S24 but does not explicitly state when not to use this tool or provide alternatives among siblings like 'setup_xreal_project' or 'build_pipeline'. Guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and the description adds value by specifying identification methods (path, name, instance ID). It does not contradict annotations and provides behavioral context beyond the annotation flags.
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 wasted words. It conveys the core purpose and identification methods efficiently.
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 adequately covers the tool's purpose and input methods. For a simple destructive tool with no output schema, it is reasonably complete, though it could mention implications like irreversibility or prerequisites.
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 clear descriptions for all three parameters. The tool description summarizes the methods but adds no new semantic details beyond the schema, meeting the baseline of 3.
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 action (delete), resource (GameObject from the scene), and identification methods (path, name, or instance ID), distinguishing it from siblings like duplicate_gameobject or select_gameobject.
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 when to use (to delete a GameObject) but provides no explicit guidance on when not to use or alternatives. It lacks prerequisites or context for choosing this over other deletion tools like delete_scene.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds that it lists via ADB and shows specific fields, but does not disclose other behaviors like caching or performance characteristics. Given annotation coverage, a score of 3 is appropriate.
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 sentences, no wasted words. It is front-loaded with the verb and resource, making it easy to understand quickly.
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 no output schema, the description sufficiently explains what is returned (device IDs, models, versions, connection status). It is complete for a list tool, though it could mention pagination or ordering.
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 baseline is 3. The description does not add information about parameters beyond what the schema already provides in its descriptions.
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 lists Android devices connected via ADB, specifying the verb 'Lists' and resource. It differentiates from siblings like get_xreal_device_info by focusing on general Android devices, not specifically XREAL.
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: 'useful for verifying device setup before deployment'. However, it does not explicitly mention when not to use or alternatives, leaving partial guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint=false, so description carries burden. It enumerates actions (create, set, play, etc.) that imply modification, but does not disclose side effects, authorization needs, or other behavioral traits beyond the action names.
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?
Bullet-pointed list of actions is well-structured and front-loaded with purpose. Some redundancy (e.g., 'Configure' repeated), but overall efficient and easy to scan.
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 37 parameters and no output schema, description covers all actions and modules. Agent can infer which parameters apply to which action from context, making it complete for invocation.
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%, baseline 3. Description adds value by grouping actions and including example JSON for color parameters, which helps interpret the input 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 manages Unity ParticleSystems in detail, listing specific actions. It distinguishes from siblings which cover other aspects of Unity (animation, lighting, etc.).
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 lists all possible actions but does not provide explicit when-to-use or when-not-to-use guidance. It implies usage for particle system management, but lacks comparisons to alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds that the tool returns a formatted string with source info, providing behavioral context beyond the annotations. No contradictions.
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, with a clear purpose sentence followed by structured Args and Returns sections. No unnecessary words 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?
The description covers the function, parameters, and return format. Given the presence of annotations and the absence of an output schema, it provides sufficient context. Minor improvement could be noting result ordering or pagination, but not critical.
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 descriptions identical to the tool description. The description adds no new meaning beyond what the schema provides, so 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 clearly states the tool searches the Unity knowledge base for documentation and assets, with a specific verb and resource. It is distinct from sibling tools, which are mostly action-oriented like creating or modifying scene objects.
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 through parameter documentation (e.g., optional filter) but does not explicitly state when to use this tool versus alternatives or when not to use it. No specific exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate write operation (readOnlyHint=false) and dynamic environment (openWorldHint=true). Description confirms mutation but adds no additional behavioral context beyond annotations. No contradictions.
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 sentences with no wasted words. First sentence states purpose, second explains modes. Efficient and front-loaded.
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 the primary purpose and mode meanings. No output schema exists, but for a setter this is acceptable. Could mention return values or side effects, but not critical.
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 100%. Description adds meaning by explaining the implications of each tracking mode (e.g., 'rotation only'), which goes beyond the schema's enum descriptions. However, 'trackingOrigin' and 'recenterOnSwitch' are not explained in the description.
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 verb 'Sets' and the resource 'tracking mode for the XREAL glasses', and explains each mode value. It distinguishes from sibling tools like 'set_render_mode' by focusing on tracking modes.
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?
It explains what each mode does (0DoF, 3DoF, 6DoF) but does not explicitly state when to use this tool versus alternatives or mention prerequisites like device connection. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and openWorldHint=true. The description adds behavioral context: it states that editor installs use the Hub CLI while project creation uses the installed Editor directly. No contradictions with annotations.
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 well-organized with a clear overview, bullet-list of actions, and default paths note. It is concise without unnecessary repetition, though slightly verbose in listing actions that are already in the schema enum.
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 complexity (8 parameters, multiple actions) and lack of output schema, the description covers the high-level functionality and action types. However, it does not describe return values or error conditions, which would enhance completeness for an AI agent.
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 all 8 parameters described. The description adds marginal value beyond the schema, such as noting that projectPath is used with projectName for project creation, but does not provide additional semantic depth for most parameters.
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 controls Unity Hub for project creation, installation management, and project opening. It lists all 8 actions explicitly, distinguishing it from sibling tools like editor_control which deal with the Unity Editor itself.
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 explains that the tool works independently of the Unity Editor connection and notes default installation paths. However, it does not explicitly state when to use this tool versus alternatives like editor_control or file_operations, though the context makes it reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds context about returning all component properties including Transform, which is useful beyond the annotations. No contradictions.
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 concise sentence that front-loads the action and includes an example. Every word adds value, no redundancy.
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?
For a simple read tool with output schema and annotations, the description covers input format and output scope sufficiently. No missing critical information.
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 the description repeats the same information about the parameter (instance ID, name, path). No additional semantic detail 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 retrieves detailed information about a specific GameObject, specifying the identifiers (instance ID, name, hierarchical path). It distinguishes from sibling tools like delete_gameobject or update_gameobject.
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 indirectly implies usage for retrieving details of a single known object, but does not explicitly contrast with siblings like find_gameobjects (for searching) or explain when not to use. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds context about specific data fields (battery, tracking) but does not disclose additional behavioral traits beyond what annotations provide.
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 sentences that are clear, front-loaded, and contain no extraneous words. Every sentence provides value.
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?
For a simple read-only information tool with no output schema, the description fully covers its purpose, scope, and environment. Parameters are adequately documented in schema.
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 each parameter already described. The description adds no extra meaning beyond the schema, 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 tool name 'get_xreal_device_info' and description clearly state it retrieves information about a connected XREAL device, specifying exact data like model, battery, tracking. It is distinct from sibling 'get_connected_devices' which lists devices.
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 mentions it works in both Editor simulation and on-device, indicating appropriate context. However, it does not explicitly state when not to use or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes async dispatch via EditorApplication.delayCall to avoid timeout. Annotations indicate non-readOnly and open world (side effects), which align with starting a build. No contradictions, and description adds useful context beyond 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?
Three sentences efficiently convey purpose, rationale for async, and next steps. No redundant information. Excellent structure for agent consumption.
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?
Covers main workflow: request returns jobId, then poll. With 12 parameters and no output schema, additional details like error handling or prerequisites would improve completeness, but core behavior is well explained.
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 covers 100% of parameters with descriptions, so baseline is 3. Description does not add parameter-specific meaning beyond what schema provides, but that is acceptable given high 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?
Clearly states the tool queues an asynchronous Android APK build for XREAL One Pro and returns a jobId immediately. Distinguishes from sibling 'get_build_status' by mentioning polling. The verb 'build' and resource 'APK for XREAL One Pro' are specific.
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?
Explains why async is needed (Unity blocks) and instructs to poll 'get_build_status' with jobId. Does not explicitly mention when not to use or alternatives like 'build_pipeline', but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description aligns by describing a capture operation without implying state modification. The description adds context about the type of captures (mono, stereo, etc.) beyond the annotation.
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 sentences with key information front-loaded. No unnecessary words or redundancies.
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 11 parameters and no output schema, the description covers the core purpose and modes. It could briefly mention file saving behavior (outputPath), but schema descriptions handle details sufficiently.
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. Description mentions capture modes (mono, stereo, etc.) which are already enumerated in the schema's captureMode parameter, adding no new meaning.
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?
Description clearly states the tool captures a screenshot from XR camera perspective, specifying mono, stereo, or individual eye views. This distinguishes it from sibling tools like get_camera_frame, which likely returns raw frame data.
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 mentions usefulness for documentation and debugging, implying appropriate use cases. However, it does not explicitly state when to use this tool versus alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive and non-readOnly behavior. The description adds that write actions auto-import to AssetDatabase and enforces security constraints (all paths must be within project directory). No contradictions.
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?
Description is well-organized with a clear action list, path examples, and security note. It is concise yet informative, with 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?
Given the tool's complexity (7 parameters, no output schema), the description covers all actions and provides examples. It lacks return value details, but that is acceptable without an output schema.
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 path examples but does not significantly enhance understanding beyond the schema's parameter descriptions.
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 performs file operations (read, write, list, etc.) and distinguishes it from sibling tools by enumerating specific file-related actions. The verb+resource pairing is explicit.
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 path examples and a security note, giving users guidance on how to use the tool. While it does not explicitly state when to avoid it, the clarity of actions and context signals are sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, so the description's job is to add behavioral context. It does so by listing the configuration steps (Android build target, XR Plugin Management, NRSDK import). However, it does not mention whether the tool overwrites existing settings or is idempotent, but this is acceptable for a setup 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 sentences with no wasted words. The key action and usage are front-loaded. Every sentence adds necessary context.
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 has 8 optional parameters and no output schema, the description explains the overall purpose and steps. It could benefit from mentioning the result (e.g., modifies the current project), but it is still reasonably complete for a setup 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?
Schema coverage is 100% with each parameter having a description, so baseline is 3. The description does not add parameter-specific semantics beyond the schema; it names the high-level steps but does not map them to the individual parameters. No extra value beyond the schema is provided.
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 ('Sets up'), identifies the resource ('Unity project for XREAL One Pro development'), and lists key actions (configure Android build, XR Plugin Management, import NRSDK). It distinguishes itself from siblings like import_nrsdk by being a broader setup tool and explicitly stating it's the first step.
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 states 'This is the first step for any new XREAL mixed reality project,' which tells the agent when to use it. It does not list when not to use or name alternatives, but the context is clear enough given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses that server will exit and be auto-restarted by the host. This is key behavioral information. Could mention potential brief downtime, but adequate.
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 sentences, no filler. Every sentence adds value: purpose, usage context, side effect. Front-loaded with most critical info.
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?
For a simple restart tool with one optional parameter and no output schema, description covers purpose, when to use, and behavioral effect. No gaps.
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% (one boolean parameter). Description adds no extra meaning beyond 'Run npm build before restarting (default: true)', which matches schema description. 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?
Description clearly states verb (rebuild and restart), resource (MCP server), and purpose (pick up code changes). Distinct from sibling Unity tools, which are all scene/asset/editor operations.
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?
Explicitly says 'Use after modifying TS tools, C# handlers, or prompts.' This provides clear context. Doesn't mention when not to use or alternatives, but siblings are unrelated so it's sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations: it explains the download-then-copy process ('The Node MCP server downloads the URL to a temp file and asks the Unity Editor to copy it into the Assets tree and refresh the AssetDatabase'). Annotations already mark it as non-readOnly and non-destructive, so the description provides useful procedural detail.
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?
Description is concise (4 sentences) and front-loaded: first sentence states purpose, second gives use cases, third explains process, fourth contrasts with sibling. 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?
Given no output schema, description still covers essential behavior: where file goes, how it's handled, and the overwrite flag. It mentions AssetDatabase refresh. Could briefly address error handling (e.g., URL failure) but overall sufficient for a simple file operation.
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?
Input schema has 100% coverage with descriptions for all 4 parameters. The description adds value for 'fileName' by explaining it defaults to the last URL segment, but for other parameters it largely repeats schema info (e.g., 'overwrite' description is same). Baseline 3 is appropriate since schema already does heavy lifting.
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 downloads a raw DLL or binary asset from a URL and installs it under Assets/<destinationFolder>/<fileName>. It specifies the verb (downloads/installs) and resource (DLL/binary asset), and distinguishes it from sibling tools like add_package by mentioning it is for assets not published as Unity packages.
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 provides when to use this tool: for native plugins, NuGet DLLs, CDN-hosted libraries. It also gives examples (zxing.unity.dll, Newtonsoft.Json.dll) and tells when NOT to use it by suggesting add_package for git-hosted UPM packages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-read-only, potentially side-effect operation. The description adds that the tool 'configures initial SDK settings after import', which provides behavioral context beyond the annotations. It does not detail what settings or potential destructive actions, but the added context is valuable.
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 clear sentences, no wasted words. The first sentence states the core purpose, and the following sentences add significant detail efficiently. Perfectly front-loaded.
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 complexity and rich input schema, the description covers the essential aspects (import, source options, configuration). It does not mention return values or error behavior, but for an import tool, the purpose and parameters are sufficiently clear. The annotation 'openWorldHint' hints at side effects, which the description acknowledges.
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?
With 100% schema coverage, the baseline is 3. The description adds meaning by explaining the two import modes ('local' vs 'url'), which maps to the 'path' and 'url' parameters, and the optional import of examples and streaming assets. This goes beyond the schema's descriptions.
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 verb 'Imports' and the resource 'NRSDK (XREAL SDK)', and distinguishes two import modes (local file or download). It sets the tool apart from siblings like 'setup_xreal_project' or 'add_package' by focusing specifically on importing and configuring the NRSDK.
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 mentions two import sources (local file or download a specific version), giving clear context on when to use each. However, it does not exclude alternatives or provide when-not-to-use guidance relative to sibling tools, which would improve the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description confirms read-only behavior by stating 'validates' and 'reports issues'. No contradictions. Description adds context about what is checked beyond 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?
Two sentences: first states overall purpose, second enumerates checks. No redundant information. Each 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?
The description covers the tool's function but does not specify the output format or what 'reports issues' means (e.g., list of strings, success/failure). Given no output schema, the description could be more explicit about return value structure.
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 all parameters described. The description lists checks but does not add new information beyond the schema's parameter descriptions. Baseline 3 is appropriate since schema already provides full 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 tool validates Unity project configuration for XREAL development and lists specific checks (NRSDK, Android settings, XR Plugin Management, permissions). It distinguishes from sibling tools like setup_xreal_project or build_xreal_apk.
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 usage for checking configuration before development or deployment, but does not explicitly mention when not to use or alternative tools. However, the purpose is clear enough for an agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds important behavioral details such as 'Block until' for wait actions, timeouts, and internal cursor management. This fully informs the agent about blocking behavior and statefulness.
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, starts with the main purpose, and uses a bullet list for actions. Every sentence adds value without 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?
Given the tool's complexity (8 parameters, multiple actions), the description provides a good overview of capabilities and behaviors. However, it lacks details about return value format (e.g., structure of log entries) and error handling, leaving some gaps despite no output schema.
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 parameters thoroughly. The description briefly restates actions but does not add significant semantic 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 monitors the Unity console for new logs with filtering and waiting capabilities, listing specific actions. It distinguishes itself from sibling tools like get_console_logs by focusing on waiting and iterative log checking.
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 mentions 'Perfect for recursive iteration' and lists use cases like waiting for messages, errors, or compilation results. However, it does not provide explicit when-not-to-use guidance or compare to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true. Description reinforces this by stating it can do anything the Unity Editor API allows, and provides details on namespaces, execution modes, and capture of Debug.Log output. No contradiction with annotations.
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 well-structured with key information first (powerful, access) followed by details and examples. It is slightly verbose but every sentence adds value; could be more concise but remains efficient.
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 power and lack of output schema, the description covers all necessary aspects: how to write code, namespaces, examples, and what outputs to expect. It is fully complete for effective usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'code' with 100% schema coverage. The description adds significant meaning by explaining how the code is evaluated (expression vs statements), the role of return statements, and pre-imported namespaces, going far beyond the schema's basic description.
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 executes arbitrary C# code in the Unity Editor context. It distinguishes itself from sibling tools which are specific, targeted operations, making it clear this is the general-purpose code execution tool.
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 guidance on how to use it (expression vs multi-statement, examples) and implies it's for tasks not covered by sibling tools. However, it does not explicitly state when NOT to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes state transitions (Queued -> Building -> Succeeded | Failed), response fields per state, and the effect of omitting jobId. Annotations confirm read-only behavior; no contradiction.
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?
Very concise (3 sentences), front-loaded with main purpose. Every sentence adds value: purpose, how to use, and behavior variations.
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?
With only 1 parameter and no output schema, the description fully covers behavior, state machine, response fields, and edge cases. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage (jobId described). Description adds that jobId comes from build_xreal_apk and that omitting it lists all jobs, plus response details per state.
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 returns the status of an asynchronous build, linking it to build_xreal_apk via jobId. It distinguishes from siblings like build_xreal_apk by being the status checker.
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 tells when to use (after build_xreal_apk with jobId) and when not (omit jobId to list all jobs). Provides clear context for alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![unity-mcp MCP server](https://glama.ai/mcp/servers/joel-wehr/unity-mcp/badges/card.svg)](https://glama.ai/mcp/servers/joel-wehr/unity-mcp)

Score Badge

Copy to your README.md:

[![unity-mcp MCP server](https://glama.ai/mcp/servers/joel-wehr/unity-mcp/badges/score.svg)](https://glama.ai/mcp/servers/joel-wehr/unity-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/joel-wehr/unity-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server