Unity AI Bridge enables AI coding assistants to remotely control and interact with the Unity Editor through file-based IPC (no ports, firewalls, or network dependencies), providing 62 tools across 13 categories:
Scene Management: Create, open, save, unload, and list scenes; retrieve scene data and set the active scene.
GameObject Operations: Find, create, destroy, duplicate, modify, and parent/unparent GameObjects.
Component Management: Add, remove, get, list, and modify components on GameObjects.
Asset Management: Search, get, modify, move, copy, delete assets; create folders, materials, list shaders, and refresh the AssetDatabase.
Prefab Workflows: Create prefabs from GameObjects; open, save, close, and instantiate prefabs.
Scripting & Code Execution: Read, create, update, and delete C# scripts; dynamically compile and execute C# code via Roslyn.
Editor Control: Get/set play mode and pause state, manage editor selection, and retrieve console logs.
C# Reflection: Find and call any C# method (including private) across all assemblies.
Performance Profiling: Capture snapshots (FPS, memory, draw calls), stream multi-frame data with P95/P99 percentiles, analyze frame hierarchies, identify hotpaths, and track GC allocations.
Package Management: List, search, add, and remove UPM packages from registry, Git, or local sources.
Light Probes: Analyze lights, generate probe grids, bake lighting, clear probe groups, and configure bake modes.
Testing: Run EditMode/PlayMode tests with filtering by assembly, namespace, class, or method; retrieve detailed pass/fail results with logs and stack traces.
Extensibility: Add custom tools via [BridgeTool] attribute with automatic discovery. Works with Claude Code, Cursor, GitHub Copilot, Windsurf, and Claude Desktop.
Allows remote control and automation of the Unity Editor, providing tools to manage scenes, game objects, assets, prefabs, and scripts, as well as access to the profiler and test runner.
Remote-control the Unity Editor from any AI IDE — no ports, no dependencies, just works.
https://github.com/user-attachments/assets/4e8b3f85-b209-406f-a96e-f8b8eddc9160
Most AI coding assistants can read and write files, but they are blind to the Unity Editor — they can't inspect your scene, tweak materials, run tests, or profile performance. Unity AI Bridge gives AI full editor access.
65 tools, 15 categories — Scene, GameObject, Assets, Prefab, Script, Profiler, LightProbe, Screenshot, Runtime, Tests, and more. Covers the full editor workflow, not just file I/O.
File-based IPC, not WebSocket — No open ports, no firewall issues, no connection drops. Survives recompilation, play-mode transitions, and editor restarts gracefully.
Zero external dependencies — Pure Python stdlib CLI/MCP server, self-contained C# Unity package. No pip install, no npm, no Node.js runtime.
Every major AI IDE — Claude Code (Skill mode), Cursor, GitHub Copilot, Windsurf, Claude Desktop (MCP mode). One Unity plugin, all IDEs.
5-line extensibility — Add custom tools with [BridgeTool] attribute. Auto-discovered, auto-serialized, auto-documented. No registration code needed.
Production-tested — Built for and battle-tested in a large-scale open-world Unity game (50+ developers, 2M+ lines of C#).
Unity 6.2 introduced an official AI Gateway with MCP support. Both projects share the same goal — giving AI agents editor access via MCP — but differ in important ways:
Unity AI Bridge | Unity 6 AI Gateway | |
Unity version | 2022.3 LTS+ | 6.2+ only |
Tool coverage | 65 tools across 15 categories | General-purpose (Scene, Assets, Script, Console) |
Deep tooling | Profiler (snapshot, hotpath, stream), LightProbe, Reflection, Package Manager | Not yet available |
IPC mechanism | File polling (~100ms) | Unix Socket / Named Pipe |
Extensibility |
| TBD |
In practice, the ~100ms file-polling latency is imperceptible because AI agent think-time dominates each round trip. File IPC also makes cross-process debugging trivial — just inspect the JSON files on disk.
Related MCP server: Union Unity MCP Server
AI-native project — Copy the prompt below and send it to your AI coding assistant. The setup guide is written for AI to follow — you don't need to run any commands yourself.
Help me install Unity AI Bridge by following this guide: https://github.com/butterlatte-zhang/unity-ai-bridge/blob/main/docs/SETUP.md
If you prefer manual setup:
Unity Package — In Unity: Window > Package Manager > + > Add package from git URL:
https://github.com/butterlatte-zhang/unity-ai-bridge.git?path=Packages/com.aibridge.unityOr manually copy Packages/com.aibridge.unity from this repo into your project's Packages/ directory.
IDE Integration — Copy .claude/ to your project root, then configure your IDE per docs/SETUP.md.
Supports: Claude Code (Skill mode), Cursor, GitHub Copilot, Windsurf, Claude Desktop (MCP mode).
65 tools organized into 15 categories:
Category | Count | Tools |
Scene | 7 |
|
GameObject | 11 |
|
Assets | 11 |
|
Prefab | 5 |
|
Script | 4 |
|
Object | 2 |
|
Editor | 4 |
|
Reflection | 2 |
|
Screenshot | 1 |
|
Runtime | 2 |
|
Console | 1 |
|
Profiler | 5 |
|
Package | 4 |
|
Light Probe | 5 |
|
Tests | 1 |
|
┌──────────────────────────────────────────────────┐
│ AI IDE │
│ (Claude Code / Cursor / Copilot / Windsurf) │
└──────────┬────────────────────┬──────────────────┘
│ │
Skill mode MCP mode
│ │
▼ ▼
┌─────────────┐ ┌──────────────┐
│ bridge.py │ │ mcp_server.py│
│ (Python) │ │ (Python) │
└──────┬──────┘ └──────┬───────┘
│ │
└────────┬─────────┘
│
File-based IPC
(request / response)
│
▼
┌───────────────────────────────┐
│ Unity Editor Plugin │
│ (com.aibridge.unity) │
│ │
│ BridgePlugin ← polls files │
│ BridgeToolRegistry │
│ BridgeToolRunner │
│ [BridgeTool] methods │
└───────────────────────────────┘Dual-channel design: The same Unity plugin serves both Skill mode (direct CLI) and MCP mode (protocol server). Both channels communicate through the same file-based IPC — a pair of request/response files on disk. No network sockets, no port conflicts, no firewall rules.
Why file IPC? Unity's main thread is single-threaded and blocks during domain reload. File polling is the most reliable way to survive recompilation, play-mode transitions, and Editor restarts without losing messages.
Most Unity AI tools stop at file editing. Unity AI Bridge goes further — it turns Claude Code (or any AI IDE) into a game testing harness.
Capability | Traditional AI | With Unity AI Bridge |
Write C# code | :white_check_mark: | :white_check_mark: |
Check compilation errors | :x: | :white_check_mark: |
Enter / exit Play Mode | :x: | :white_check_mark: |
Trigger game actions | :x: | :white_check_mark: |
Read runtime game state | :x: | :white_check_mark: |
Take screenshots | :x: | :white_check_mark: |
Full closed loop: Write → Test → Fix → Repeat | :x: | :white_check_mark: |
AI writes code → compiles → enters Play Mode → observes state → judges → fixes → repeats
↑ │
└─────────────────── fully automated loop ────────────────────────────────┘The pattern: Act → Wait → Observe → Judge → Repeat
Act: runtime-invoke calls static methods to trigger game actions
Wait: wait_playmode.py / wait_compile.py handle timing
Observe: runtime-query reads MonoBehaviour fields + screenshot-capture for visuals
Judge: AI analyzes state/screenshots to decide PASS/FAIL
Auto-Playtest Example | AI Closed-Loop Guide | Playtest Tool Reference
Expose any static method to AI with a single attribute:
using UnityAiBridge;
[BridgeToolType]
public static partial class CustomTools
{
[BridgeTool("custom-greet")]
[System.ComponentModel.Description("Say hello")]
public static string Greet(string name = "World")
{
return $"Hello, {name}!";
}
}The bridge discovers tools at Editor startup via reflection. No registration code, no config files. Parameters are automatically mapped to JSON Schema for the AI to call.
Unity AI Bridge runs entirely on your local machine. The file IPC channel is scoped to your user's temp directory, and no network listeners are opened.
See SECURITY.md for details.
Unity Version | Render Pipeline | Status |
2022.3 LTS+ | Built-in | Supported |
2022.3 LTS+ | URP | Supported |
2022.3 LTS+ | HDRP | Supported |
6000.x (Unity 6) | All | Supported |
Platforms: Windows, macOS
Contributions are welcome! Please see CONTRIBUTING.md for guidelines.
Report bugs and request features via GitHub Issues
Submit pull requests against the main branch
Add new tools by following the [BridgeTool] pattern above
Unity AI Bridge is derived from Unity-MCP by Ivan Murzak (Apache License 2.0). See THIRD_PARTY_NOTICES.md for details.
Copy the asset at path and stores it at newPath. Does AssetDatabase.Refresh() at the end. Use 'assets-find' tool to find assets before copying.
| Name | Required | Description | Default |
|---|---|---|---|
| sourcePaths | Yes | Array of asset paths to copy. Example: ["Assets/Materials/Mat.mat"] | |
| destinationPaths | Yes | Array of destination paths (same length as sourcePaths). Example: ["Assets/Materials/MatCopy.mat"] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that AssetDatabase.Refresh() is called, a useful side effect, but does not mention overwrite behavior, error handling, or whether the operation is atomic, which is needed since no annotations are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the main action, and includes a key usage tip without extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is present, and the description does not explain return values or error states. It covers the main action and a side effect, but lacks details on handling multiple paths or failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds an example and a hint about using assets-find, but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool copies an asset from one path to another, distinguishing it from siblings like assets-move or assets-delete. However, it uses singular 'path' while the schema accepts arrays, causing slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using 'assets-find' before copying, which is helpful context, but it does not specify when to avoid copying or when to use alternatives like assets-move, leaving room for improvement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new folder in the specified parent folder. The parent folder string must start with the 'Assets' folder, and all folders within the parent folder string must already exist. For example, when specifying 'Assets/ParentFolder1/ParentFolder2/', the new folder will be created in 'ParentFolder2' only if ParentFolder1 and ParentFolder2 already exist. Use it to organize scripts and assets in the project. Does AssetDatabase.Refresh() at the end. Returns the GUID of the newly created folder, if successful.
| Name | Required | Description | Default |
|---|---|---|---|
| inputs | Yes | Array of folder creation specs. SCHEMA: [{"parentFolderPath":"Assets/parent","newFolderName":"folderName"}] - properties must be camelCase. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effect (AssetDatabase.Refresh()), return value (GUID), and path validation behavior, compensating for lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, well-structured sentences with each sentence providing essential information, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a single-parameter tool with no output schema; covers behavior, return, and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds value by explaining array format, camelCase requirement, and path structure beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new folder, specifies parent folder requirements, and distinguishes from siblings by focusing on folder creation in a project context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States to use 'to organize scripts and assets', provides path requirements, but doesn't explicitly mention when not to use or name alternatives, though the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete the assets at paths from the project. Does AssetDatabase.Refresh() at the end. Use 'assets-find' tool to find assets before deleting.
| Name | Required | Description | Default |
|---|---|---|---|
| paths | Yes | Array of asset paths to delete. Example: ["Assets/Materials/Mat.mat"] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Mentions the side effect of calling AssetDatabase.Refresh() at the end, which is useful. Without annotations, it could disclose more about irreversibility or permissions, but does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. Front-loaded with action, then adds advice and side effect. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema and no annotations, the description is fairly complete: states action, side effect, and usage hint. Could mention permanence, but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description does not add additional meaning beyond the schema's parameter description of 'Array of asset paths to delete'. Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete assets at paths) and resource, and references a sibling tool (assets-find) for finding assets before deletion, which helps distinguish its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to use assets-find before deleting, but lacks explicit when-not-to-use or other alternatives. Still, it gives clear context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the asset database using the search filter string. Allows you to search for Assets. The string argument can provide names, labels or types (classnames).
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | The filter string can contain search data. Could be empty. Name: Filter assets by their filename (without extension). Words separated by whitespace are treated as separate name searches. Labels (l:): Assets can have labels attached to them. Use 'l:' before each label. Types (t:): Find assets based on explicitly identified types. Use 't:' keyword. Available types: AnimationClip, AudioClip, AudioMixer, ComputeShader, Font, GUISkin, Material, Mesh, Model, PhysicMaterial, Prefab, Scene, Script, Shader, Sprite, Texture, VideoClip, VisualEffectAsset, VisualEffectSubgraph. AssetBundles (b:): Find assets which are part of an Asset bundle. Area (a:): Find assets in a specific area. Valid values are 'all', 'assets', and 'packages'. Globbing (glob:): Use globbing to match specific rules. Note: Searching is case insensitive. | |
| searchInFolders | No | The folders where the search will start. If null, the search will be performed in all folders. | |
| maxResults | No | Maximum number of assets to return. If the number of found assets exceeds this limit, the result will be truncated. | 10 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. However, it only states the tool searches assets, implying a read-only operation, but lacks details on side effects, performance limits, or error conditions. For a search tool, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that front-load the main purpose. No superfluous information. Could be slightly more structured but is generally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should clarify what is returned (e.g., asset paths or IDs). It also does not mention behavior with maxResults or empty results. Given the complexity of the filter string and sibling tools, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter descriptions in the schema are comprehensive. The tool description only summarizes these, adding marginal value. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the asset database using a filter string. It distinguishes from similar tools like 'assets-find-built-in' by specifying it searches the general asset database, not built-in assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives such as 'assets-find-built-in' or other search tools. No explicit context for usage is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the built-in assets of the Unity Editor located in the built-in resources: Resources/unity_builtin_extra. Doesn't support GUIDs since built-in assets do not have them.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | The name of the asset to filter by. | |
| type | No | The type of the asset to filter by. Schema: "Material" or "Shader" or "Texture2D" etc. (Unity asset type name) | |
| maxResults | No | Maximum number of assets to return. If the number of found assets exceeds this limit, the result will be truncated. | 10 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully discloses behavior: it searches built-in assets, highlights the location, and explains the lack of GUID support. This is sufficient for a read-only search operation, though it could mention that it only returns built-in assets (which is implied).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of two sentences. The first sentence states the purpose and location, and the second provides a key limitation. Every word contributes value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description provides essential context: the asset type support, location, and a notable limitation (no GUIDs). It is complete enough for an agent to understand the tool's scope, though a brief note on return format would enhance it further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the descriptions already define the parameters. The tool description does not add extra meaning beyond the schema. For high schema coverage, a baseline of 3 is appropriate as the description adds no significant new semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches built-in assets of Unity Editor, specifies the exact location (Resources/unity_builtin_extra), and distinguishes from other asset-finding tools by noting it does not support GUIDs. This provides a specific verb-resource combination and sets it apart from siblings like 'assets-find'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching built-in assets but does not explicitly state when to use this tool versus alternatives like 'assets-find'. It mentions the unsupported GUIDs, which hints at a limitation but does not provide clear when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get asset data from the asset file in the Unity project. It includes all serializable fields and properties of the asset. Use 'assets-find' tool to find asset before using this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| assetRef | Yes | Asset reference. SCHEMA: {"assetPath":"Assets/path/to/asset"} or {"instanceID":12345} or {"assetGuid":"guid-string"} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It states 'includes all serializable fields and properties' which is behavioral, but does not explicitly confirm read-only nature or lack of side effects. Adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with primary action, no extraneous words. Every sentence adds value: first states purpose, second provides usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter (well-described in schema) and no output schema, description explains what the tool returns (all serializable fields and properties). Could mention return data format, but sufficient for a straightforward getter with clear purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers the single parameter with a detailed description of the three reference formats (basis). Description adds context about getting asset data but does not enhance parameter understanding beyond schema. Baseline 3 due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Get asset data from the asset file in the Unity project' with a specific verb and resource, and mentions it includes all serializable fields and properties. It also distinguishes from siblings by referencing 'assets-find' as a prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear when-to-use guidance: 'Use assets-find tool to find asset before using this tool.' This tells the agent the required preceding step and implies this tool is for fetching data after locating an asset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create new material asset with default parameters. Creates folders recursively if they do not exist. Provide proper 'shaderName' - use 'assets-shader-list-all' tool to find available shaders.
| Name | Required | Description | Default |
|---|---|---|---|
| assetPath | Yes | Full path for the new material including filename. Example: "Assets/Materials/NewMat.mat". Parent folder must exist. | |
| shaderName | Yes | Shader name. Example: "Universal Render Pipeline/Lit", "Standard" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavior. It describes folder creation recursively, but this contradicts the input schema's note that parent folder must exist. This inconsistency reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the purpose. Structure is clear, though slightly dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks details on default parameters, error handling, overwrite behavior, and output. The contradiction with the schema further reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions. The description adds examples for shaderName but also contradicts the schema regarding folder creation. This confusion lowers the added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new material asset, which aligns with the name. It mentions 'default parameters' and folder creation, but does not explicitly distinguish from other creation tools like 'assets-create-folder'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using 'assets-shader-list-all' to find available shaders, which provides some guidance. However, it lacks explicit when-to-use or when-not-to-use context, and does not mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Modify asset file in the project. Use 'assets-get-data' tool first to inspect the asset structure before modifying. Not allowed to modify asset file in 'Packages/' folder. Please modify it in 'Assets/' folder.
| Name | Required | Description | Default |
|---|---|---|---|
| assetRef | Yes | Asset reference. SCHEMA: {"assetPath":"Assets/path/to/asset"} or {"instanceID":12345} | |
| content | Yes | JSON string of SerializedMember diff to apply. SCHEMA: {"props":[{"name":"propertyName","value":any}],"fields":[{"name":"fieldName","value":any}]} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It declares modification behavior and adds a constraint (no Packages/). However, it lacks details on success/failure outcomes or permission requirements, which would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of nested object parameters and no output schema, the description covers essential usage preconditions (inspection step, folder restriction). However, it omits description of return value or error conditions, which could help in complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds practical usage context (using get-data for assetRef) but does not elaborate on parameter specifics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Modify asset file in the project' which clearly specifies the verb (modify) and resource (asset file). It distinguishes itself from sibling tools like 'assets-get-data' (read) and other asset modification tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use 'assets-get-data' first to inspect structure, and states prohibition on modifying files in 'Packages/' folder, suggesting 'Assets/' instead. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move the assets at paths in the project. Should be used for asset rename. Does AssetDatabase.Refresh() at the end. Use 'assets-find' tool to find assets before moving.
| Name | Required | Description | Default |
|---|---|---|---|
| sourcePaths | Yes | Array of source asset paths. Example: ["Assets/old.mat"] | |
| destinationPaths | Yes | Array of destination paths. Example: ["Assets/new.mat"] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses AssetDatabase.Refresh() side effect, but lacks details on overwrite behavior, error handling, or return value. No annotations provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides basic purpose and side effect but lacks details on return, error conditions, and path validation. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers both parameters with examples. Description adds no extra semantic value beyond usage hint for rename.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it moves assets, specifically for renaming. Distinguishes from siblings like assets-copy and assets-delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States it should be used for rename and suggests using assets-find first. No explicit exclusion of other uses, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close currently opened prefab. Use it when you are in prefab editing mode in Unity Editor. Use 'assets-prefab-open' tool to open a prefab first.
| Name | Required | Description | Default |
|---|---|---|---|
| save | No | True to save prefab. False to discard changes. | true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It mentions the 'save' parameter to indicate whether changes are saved or discarded, but does not elaborate on side effects or irreversible consequences of discarding changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences, front-loading the core action and avoiding any unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description provides sufficient context: it specifies the editing mode, the prerequisite action (opening a prefab), and the effect of the save parameter. No additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter. The description does not add extra meaning beyond that already in the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Close' and resource 'prefab', clearly stating the action and scope. It distinguishes from sibling tools like 'assets-prefab-open' by naming them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use the tool (when in prefab editing mode) and references the sibling 'assets-prefab-open' as a prerequisite. However, it does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a prefab from a GameObject in the current active scene. The prefab will be saved in the project assets at the specified path. Use 'gameobject-find' tool to find the target GameObject first.
| Name | Required | Description | Default |
|---|---|---|---|
| prefabAssetPath | Yes | Save path for the new prefab. Example: "Assets/Prefabs/MyPrefab.prefab" | |
| gameObjectRef | Yes | Source GameObject reference. SCHEMA: {"name":"ObjectName"} or {"instanceID":12345} or {"path":"hierarchy/path"} | |
| replaceGameObjectWithPrefab | No | If true, the prefab will replace the GameObject in the scene. | true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the creation and saving behavior, and mentions the replace option. However, it doesn't disclose whether it overwrites existing prefabs, requires permissions, or returns a reference. The description is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear sentences, front-loaded with the action. Every sentence adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 3 params and no output schema, the description covers the main purpose, prerequisite, and replace option. It lacks detail on overwrite behavior and error cases, but is reasonably complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage, so baseline 3. The description adds context by referencing gameobject-find for the gameObjectRef parameter, but does not add significant detail beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it creates a prefab from a GameObject in the active scene, distinguishing it from sibling tools like assets-prefab-instantiate. The verb 'create' and resource 'prefab from GameObject' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use 'gameobject-find' first, providing a clear prerequisite. It doesn't state when not to use, but the sibling context (e.g., assets-prefab-instantiate) implies the direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Instantiates prefab in the current active scene. Use 'assets-find' tool to find prefab assets in the project.
| Name | Required | Description | Default |
|---|---|---|---|
| prefabAssetPath | Yes | Path to the prefab asset. Example: "Assets/Prefabs/MyPrefab.prefab" | |
| gameObjectPath | Yes | GameObject path in the current active scene. | |
| position | No | Spawn position. SCHEMA: {"x":0,"y":0,"z":0} | |
| rotation | No | Spawn rotation (Euler angles). SCHEMA: {"x":0,"y":0,"z":0} | |
| scale | No | Scale. SCHEMA: {"x":1,"y":1,"z":1} | |
| isLocalSpace | No | World or Local space of transform. | false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but offers minimal behavioral context—it does not disclose side effects, permissions, or limitations beyond the basic instantiation action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no extraneous information, every word serves a purpose, making it highly concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 no annotations, the description is insufficiently complete—it lacks information about return values, error handling, or what happens when the gameObjectPath is not found.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with descriptions for each parameter, so the description does not need to add much; it provides no extra parameter context beyond the schema, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('instantiates') and the resource ('prefab in the current active scene'), distinguishing it from sibling tools by directing to 'assets-find' for finding prefabs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using 'assets-find' as a prerequisite step, providing clear guidance on when to use this tool in conjunction with others, though it lacks explicit when-not-to-use comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open prefab edit mode for a specific GameObject. In the Edit mode you can modify the prefab. The modification will be applied to all instances of the prefab across the project. Note: Please use 'assets-prefab-close' tool later to exit prefab editing mode.
| Name | Required | Description | Default |
|---|---|---|---|
| gameObjectRef | Yes | Prefab GameObject reference (use instanceID from prefab-instantiate result, or name of prefab instance in scene). SCHEMA: {"name":"PrefabName"} or {"instanceID":12345} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that modifications apply to all instances, which is key, but does not mention side effects like locking, unsaved changes, or performance impact. No annotations provided, so description carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a note, each adding value: action, effect on instances, and exit instruction. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains purpose and effect, but lacks details on return value (no output schema) and prerequisites (e.g., prefab must exist in scene). Could mention error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers the parameter well (100% coverage) with description of how to reference it. The tool description adds no extra parameter semantics beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Open' and resource 'prefab edit mode for a specific GameObject', differentiating it from sibling tools like 'assets-prefab-close'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (to modify prefabs) and provides a note to use 'assets-prefab-close' later, but does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a prefab. Use it when you are in prefab editing mode in Unity Editor. Use 'assets-prefab-open' tool to open a prefab first.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It only states the action and prerequisite but does not disclose side effects, saving behavior (overwrite vs. save-as), or whether the edit mode continues after save.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. First sentence states the primary action, second and third provide usage context and prerequisite. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters or output schema, the description provides essential context (prefab editing mode) and prerequisite. However, it lacks detail on what exactly is saved, save behavior, or post-save state, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0 parameters, and schema description coverage is 100%. According to guidelines, baseline is 4 with no parameters. Description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Save a prefab' and distinguishes from sibling by specifying 'Use ''assets-prefab-open'' tool to open a prefab first.' It identifies the resource (prefab) and the action, providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use it when you are in prefab editing mode' and directs to open prefab first via 'assets-prefab-open.' This provides context and a prerequisite, though it does not list when not to use or alternatives beyond the open tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refreshes the AssetDatabase. Use it if any file was added or updated in the project outside of Unity API. Use it if need to force scripts recompilation when '.cs' file changed.
| Name | Required | Description | Default |
|---|---|---|---|
| options | No | Import options. ENUM: "Default", "ForceUpdate", "ForceSynchronousImport", "ImportRecursive", "DontDownloadFromCacheServer", "ForceUncompressedImport". Default: "ForceSynchronousImport". Accepts string name or integer value. | 8 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full weight. It reveals the tool causes refresh and recompilation, but omits details on return value, error handling, or potential destruction of unsaved changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both essential, with no extraneous text. The description front-loads the core action and provides concrete usage conditions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple refresh tool, the description covers purpose and usage context adequately. It lacks details on return type or side effects, but given no output schema and low complexity, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter with enum options and default, achieving 100% coverage. The description adds no additional parameter meaning, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool refreshes the AssetDatabase, with specific use cases: when files are added/updated outside Unity API and to force script recompilation on .cs changes. This distinguishes it from sibling tools like assets-copy or assets-delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use: for externally modified files and forced recompilation. While it does not list alternatives or exclusion scenarios, this guidance is clear and context-rich.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available shaders in the project assets and packages. Returns their names. Use this to find a shader name for 'assets-material-create' tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes a read-only listing operation with no side effects. Since annotations are absent, the description adequately conveys the simple, safe nature of the tool. Could add details on scope (what 'available' means), but sufficient for this straightforward tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: one states the action and result, the second provides a practical use case. No fluff, front-loaded with essential info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is complete enough. It tells what it returns (names) and gives a usage context. Could mention if built-in shaders are included, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (schema coverage 100%), so description does not need to explain parameters. Baseline 4 applies, and the description adds value by specifying return value (names).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it lists all available shaders in project assets and packages, returns names, and mentions a specific use case (finding a shader name for 'assets-material-create'). This clearly distinguishes it 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear use case: use to find shader name for 'assets-material-create'. Does not mention when not to use, but the positive guidance is strong and directly addresses a common scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves Unity Editor logs. Useful for debugging and monitoring Unity Editor activity.
| Name | Required | Description | Default |
|---|---|---|---|
| maxEntries | No | Maximum number of log entries to return. Default: 100 | 100 |
| logTypeFilter | No | Filter by log type. ENUM: "Log", "Warning", "Error", "Assert", "Exception". Leave empty for all types. | |
| includeStackTrace | No | Include stack traces in the output. Default: false | false |
| lastMinutes | No | Return logs from the last N minutes. If 0, returns all available logs. Default: 0 | 0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral transparency. It only states 'retrieves' without disclosing any side effects, destructive actions, or performance implications. This is insufficient for a data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, with no superfluous information. Every word earns its place, and the structure is clear and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should provide more context about return format or potential limitations. It mentions 'logs' but does not describe the structure or volume. However, the schema covers parameters adequately, making it minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 four parameters. The description does not add any parameter-specific meaning beyond the schema. Per the guidelines, this warrants a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Unity Editor logs and indicates its utility for debugging and monitoring. It effectively communicates the core function, though it could be more specific about the source (e.g., 'from the Console window').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions usefulness for debugging and monitoring, implying when to use, but does not provide explicit guidance on when not to use or alternatives. Given no sibling log tools exist, the lack of exclusion is acceptable, but the description could be more directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns available information about 'UnityEditor.EditorApplication'. Use it to get information about the current state of the Unity Editor application. Such as: playmode, paused state, compilation state, etc.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states that it returns information and gives examples; it does not mention any side effects, performance implications, or safety traits. The read-only nature is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant information, and the key action is front-loaded. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description provides a reasonable overview with examples, but lacks specifics about the return format (e.g., JSON structure, possible values). 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description adds value by describing what the tool returns, fulfilling the need to explain the output in lieu of an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns information about the EditorApplication state, with examples like playmode and paused state. It implicitly differentiates from the sibling 'editor-application-set-state' by being a getter, but does not explicitly contrast with other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use it to get information about the current state,' which provides a clear when-to-use, but no guidance on when not to use or alternatives besides the obvious setter sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Control the Unity Editor application state. You can start, stop, or pause the 'playmode'. Use 'editor-application-get-state' tool to get the current state first.
| Name | Required | Description | Default |
|---|---|---|---|
| isPlaying | No | If true, the 'playmode' will be started. If false, the 'playmode' will be stopped. | false |
| isPaused | No | If true, the 'playmode' will be paused. If false, the 'playmode' will be resumed. | false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the behavioral effect: starting, stopping, or pausing playmode via isPlaying and isPaused. It does not mention side effects or permissions, but for a simple state control, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and immediately follow with a usage recommendation. Every sentence is essential and well-ordered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two boolean parameters and no output schema, the description fully covers what an agent needs: what the tool does, how to use it, and a reference to a related sibling tool for pre-conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 value beyond the schema. It restates the parameter meanings but does not provide additional context about default values or interactions between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool controls Unity Editor playmode state (start, stop, pause) and distinguishes it from the sibling tool 'editor-application-get-state'. The verb 'control' combined with specific actions makes 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using 'editor-application-get-state' first to get the current state, providing valuable usage guidance. While it lacks explicit when-not-to-use conditions, the recommendation is sufficient for this straightforward tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the current Selection in the Unity Editor. Use 'editor-selection-set' tool to set the selection.
| Name | Required | Description | Default |
|---|---|---|---|
| includeGameObjects | No | false | |
| includeTransforms | No | false | |
| includeInstanceIDs | No | false | |
| includeAssetGUIDs | No | false | |
| includeActiveObject | No | true | |
| includeActiveTransform | No | true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states 'Get information' implying a read operation, but does not explicitly confirm non-destructiveness, permissions, or what happens when no selection exists. The minimal description leaves significant uncertainty about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and succinctly referencing the sibling. Every word serves a purpose without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has six configurable boolean parameters and no output schema, the description is far too minimal. It does not mention what information is returned, how parameters affect the output, or any edge case handling (e.g., empty selection). This leaves the agent with insufficient context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about the six boolean parameters. Schema description coverage is 0%, and the description does not explain what fields like 'includeGameObjects' or 'includeActiveObject' control. The agent cannot understand how to use these parameters based on the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Get information about the current Selection' and distinguishes it from the sibling 'editor-selection-set' by directing agents to use that tool for setting. This provides a specific verb and resource, effectively differentiating the tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs agents to use 'editor-selection-set' for setting the selection, offering clear context on when to use this getter versus the alternative. However, it does not provide exclusions or broader usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the current Selection in the Unity Editor to the provided objects. Use 'editor-selection-get' tool to get the current selection first.
| Name | Required | Description | Default |
|---|---|---|---|
| select | Yes | Array of ObjectRef to select. SCHEMA: [{"instanceID":12345}]. Get instanceID from gameobject-find or editor-selection-get first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action without disclosing side effects, error handling (e.g., invalid objects), or whether it replaces or appends to the selection. Minimal behavioral context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, followed by a usage guideline. Every sentence earns its place with no redundancy or trivia.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description covers key aspects: what it does, how to get the parameter, and when to use. However, lacks clarity on whether selection is replaced or appended, and no mention of return or confirmation. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter with 100% coverage. The description adds value by specifying the format (Array of ObjectRef with instanceID) and instructing how to obtain instanceIDs from other tools, going beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Set the current Selection' and the resource 'Unity Editor', distinguishing it from the sibling 'editor-selection-get' by recommending its use first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to use 'editor-selection-get' first to obtain the current selection, setting clear context for when to invoke this tool. No exclusions or alternatives needed for a simple setter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add Component to GameObject in opened Prefab or in a Scene. Use 'gameobject-find' tool to find the target GameObject first. Use 'gameobject-component-list-all' tool to find the component type names to add.
| Name | Required | Description | Default |
|---|---|---|---|
| componentNames | Yes | Array of component type names to add. Example: ["BoxCollider","Rigidbody"] | |
| gameObjectRef | Yes | Target GameObject. SCHEMA: {"name":"ObjectName"} or {"instanceID":12345} or {"path":"hierarchy/path"} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action and context but does not disclose behavioral traits such as whether components can be added multiple times, error handling, or side effects. For a mutation tool, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two focused sentences, front-loading the core purpose and then providing actionable guidance. No redundancy or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two required parameters and no output schema, the description is largely complete. It explains how to obtain the inputs and the context (opened prefab or scene). It could mention that components are added fresh (not overwriting) or error scenarios, but overall it is sufficient for a straightforward add operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents both parameters with examples. The description adds value by referencing the prerequisite tools for finding parameter values, but it does not add new 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add Component to GameObject in opened Prefab or in a Scene.' It uses a specific verb ('Add') and specifies the resource ('Component' on 'GameObject'), and distinguishes from sibling tools like gameobject-component-destroy and gameobject-component-modify by focusing on addition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use gameobject-find tool to find the target GameObject first. Use gameobject-component-list-all tool to find the component type names to add.' This tells the agent when to use this tool and what prerequisites are needed, effectively differentiating from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Destroy one or many components from target GameObject. Can't destroy missed components. Use 'gameobject-find' tool to find the target GameObject and 'gameobject-component-get' to get component details first.
| Name | Required | Description | Default |
|---|---|---|---|
| gameObjectRef | Yes | Target GameObject. SCHEMA: {"name":"ObjectName"} or {"instanceID":12345} | |
| destroyComponentRefs | Yes | Array of component references to destroy. SCHEMA: [{"typeName":"BoxCollider"}] or [{"typeName":"BoxCollider","index":0}] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It mentions the destructive nature ('destroy') and a limitation ('Can't destroy missed components'), but lacks details on side effects (e.g., undo, permissions) or error handling. For a destructive tool, more transparency would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the sibling tools and the complexity of gameobject operations, the description provides enough context to use the tool correctly, including references to other tools. However, it could be more complete by mentioning that components must exist or what happens on failure, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 both parameters. The description adds no further parameter semantics, only mentions the workflow. Thus, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (destroy components) and the target (target GameObject). It distinguishes itself from sibling tools like gameobject-find and gameobject-component-get by specifying the prerequisite workflow. The phrase 'Can't destroy missed components' adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use gameobject-find and gameobject-component-get before this tool, providing clear workflow guidance. It does not explicitly state when not to use it, but the implied context is sufficient for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific Component on a GameObject. Returns component type, enabled state, and optionally serialized fields and properties. Use this to inspect component data before modifying it. Use 'gameobject-find' tool to get the list of all components on the GameObject.
| Name | Required | Description | Default |
|---|---|---|---|
| gameObjectRef | Yes | Target GameObject. SCHEMA: {"name":"ObjectName"} or {"instanceID":12345} | |
| componentRef | Yes | Component to get. SCHEMA: {"typeName":"Transform"} or {"typeName":"BoxCollider","index":0} | |
| includeFields | No | Include serialized fields of the component. | true |
| includeProperties | No | Include serialized properties of the component. | true |
| deepSerialization | No | Performs deep serialization including all nested objects. Otherwise, only serializes top-level members. | false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation via 'inspect' and mentions what data is returned, but does not explicitly state side effects, error handling, or access restrictions. This is sufficient for a simple getter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the purpose, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description mentions the returned data (component type, enabled state, optional fields/properties). It also advises using an alternative tool. It could elaborate on error cases but is sufficiently complete for a straightforward inspection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the input schema. The description adds no new parameter semantics beyond what the schema already provides, achieving the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Get detailed information about a specific Component on a GameObject.' It specifies the returned data (component type, enabled state, optional fields/properties) and distinguishes itself from the sibling tool 'gameobject-find' which lists all components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to inspect component data before modifying it' and 'Use 'gameobject-find' tool to get the list of all components on the GameObject,' providing clear when-to-use and alternative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
When gameObjectRef is provided: list all components attached to that GameObject (type name + instanceID). When gameObjectRef is omitted: list all available C# component type names in the project (for 'gameobject-component-add' tool). Results are paginated.
| Name | Required | Description | Default |
|---|---|---|---|
| gameObjectRef | No | Target GameObject. When provided, lists components ON this object. When omitted, lists all available component types. SCHEMA: {"name":"ObjectName"} or {"instanceID":12345} | |
| search | No | Substring for searching/filtering component names. Could be empty. | |
| page | No | Page number (0-based). Default is 0. | 0 |
| pageSize | No | Number of items per page. Default is 20. Max is 500. | 20 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the dual behavior and pagination but does not explicitly state that the tool is read-only or describe any side effects. A read-only hint would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but conveys all key aspects: two modes, what is listed, and pagination. It is reasonably concise but could be slightly more structured (e.g., separate sentences). Not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 4 parameters (all documented in schema) and no output schema, the description explains the return format ('type name + instanceID' for components, 'component type names' for types). It covers pagination. Still, it lacks details on ordering or sorting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 significant value by explaining the dual behavior change based on gameObjectRef presence and the expected JSON structure for that parameter, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states two distinct modes (with and without gameObjectRef) and specifies what is listed in each case (component instances vs. component type names). It also mentions pagination. This effectively distinguishes it from sibling tools like gameobject-component-add.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use each mode (with gameObjectRef vs. omitted) and even references the 'gameobject-component-add' tool for context. However, it does not explicitly state when not to use the tool or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Modify a specific Component on a GameObject in opened Prefab or in a Scene. Allows direct modification of component fields and properties without wrapping in GameObject structure. Use 'gameobject-component-get' first to inspect the component structure before modifying.
| Name | Required | Description | Default |
|---|---|---|---|
| gameObjectRef | Yes | Target GameObject. SCHEMA: {"name":"ObjectName"} or {"instanceID":12345} | |
| componentRef | Yes | Component to modify. SCHEMA: {"typeName":"Transform"} | |
| componentDiff | Yes | SerializedMember diff. SCHEMA: {"props":[{"name":"size","value":{"x":2,"y":2,"z":2}}],"fields":[...]} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions modifying component fields/properties but does not disclose side effects, error conditions, or whether modifications are immediately applied. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences that are front-loaded with the core action, then provide a benefit and a usage tip. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose and prerequisite, but lacks details on return values, error handling, and behavioral scope. With no output schema, more context on outcome would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes parameters. The description adds minimal extra meaning beyond noting direct modification, not clarifying the nested structure of gameObjectRef or componentRef beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it modifies a specific component on a GameObject, and distinguishes from sibling tools like gameobject-component-add (adds) and gameobject-component-destroy (destroys) by noting direct modification without wrapping in GameObject structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It advises to use 'gameobject-component-get' first for inspection, providing a prerequisite. However, it does not explicitly state when not to use this tool or list alternative tools for different tasks, such as gameobject-modify for the entire GameObject.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new GameObject in opened Prefab or in a Scene. If needed - provide proper 'position', 'rotation' and 'scale' to reduce amount of operations.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the new GameObject. | |
| parentGameObjectRef | No | Parent GameObject reference. If not provided, the GameObject will be created at the root of the scene or prefab. Schema: {"name":"string"} or {"instanceID":int} or {"path":"hierarchy/path"} | |
| position | No | Transform position of the GameObject. Schema: {"x":0,"y":0,"z":0} | |
| rotation | No | Transform rotation of the GameObject. Euler angles in degrees. Schema: {"x":0,"y":0,"z":0} | |
| scale | No | Transform scale of the GameObject. Schema: {"x":1,"y":1,"z":1} | |
| isLocalSpace | No | World or Local space of transform. | false |
| primitiveType | No | Values: [Cube, Sphere, Capsule, Cylinder, Plane, Quad] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavioral traits. It only states the action and a hint about reducing operations, but lacks disclosure of side effects, failure modes, or what happens after creation (e.g., selection state, naming conflicts).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence that is concise and front-loaded. However, it could be more structured without losing brevity, e.g., by separating the creation action from the optional performance hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and many sibling tools, the description omits crucial details: default behavior, return value, error conditions, and integration with the broader tool ecosystem. It feels incomplete for a creator tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds marginal value by suggesting to provide transform params to reduce operations, but no new semantic details beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Create), resource (new GameObject), and context (in opened Prefab or Scene). It distinguishes from siblings like gameobject-destroy and gameobject-duplicate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like gameobject-duplicate or gameobject-find. The only tip is about including transforms to reduce operations, but no exclusion criteria or comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Destroy GameObject and all nested GameObjects recursively in opened Prefab or in a Scene. Use 'gameobject-find' tool to find the target GameObject first.
| Name | Required | Description | Default |
|---|---|---|---|
| gameObjectRef | Yes | Schema: {"name":"string"} or {"instanceID":int} or {"path":"hierarchy/path"} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses recursive destruction and scope (Prefab/Scene), but omits details about irreversibility, side effects, or permission requirements. Minimal but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences: the first defines the action, the second provides a usage hint. No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers what the tool does, the scope, and a prerequisite. Lacks error behavior or return value description, but for a destroy operation with no output schema, the gap is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameter with a clear description. The tool description adds no extra semantics beyond the schema; it only hints at using gameobject-find. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Destroy), the resource (GameObject), the scope (all nested recursively), and the context (opened Prefab or Scene). It also differentiates from sibling tools like gameobject-create or gameobject-duplicate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using gameobject-find first, establishing a clear prerequisite. However, it lacks guidance on when not to use this tool or alternatives, though for a destructive action the intent is self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Duplicate GameObjects in opened Prefab or in a Scene. Use 'gameobject-find' tool to find the target GameObjects first.
| Name | Required | Description | Default |
|---|---|---|---|
| gameObjectRefs | Yes | Schema: [{"name":"string"}] - array of GameObjectRef |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only states 'duplicates' but fails to mention side effects (e.g., children duplication, prefab connections, or undo support). Lacks critical behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the action and context. Every word is informative with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks information on return value, success/failure indicators, or impact on hierarchy. Given no output schema and many sibling tools, the description could more completely contextualize the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description does not add significant meaning beyond the schema. The description notes the parameter but does not clarify how to construct a GameObjectRef (e.g., by path or unique ID), which is a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Duplicate' and resource 'GameObjects', specifies context (in opened Prefab or Scene), and references the prerequisite tool 'gameobject-find'. Differentiates from siblings like 'gameobject-create' and 'gameobject-destroy'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use 'gameobject-find' first, providing clear usage context. Does not list when not to use or alternative tools, but the given guidance is sufficient for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds specific GameObject by provided information in opened Prefab or in a Scene. First it looks for the opened Prefab, if any Prefab is opened it looks only there ignoring a scene. If no opened Prefab it looks into current active scene. Returns GameObject information and its children. Also, it returns Components preview just for the target GameObject.
| Name | Required | Description | Default |
|---|---|---|---|
| gameObjectRef | Yes | GameObject reference. SCHEMA: {"name":"Main Camera"} or {"instanceID":12345} or {"path":"Canvas/Panel/Button"} | |
| includeData | No | Include editable GameObject data (tag, layer, etc). | false |
| includeComponents | No | Include attached components references. | false |
| includeBounds | No | Include 3D bounds of the GameObject. | false |
| includeHierarchy | No | Include hierarchy metadata. | false |
| hierarchyDepth | No | Determines the depth of the hierarchy to include. 0 - means only the target GameObject. 1 - means to include one layer below. | 0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses search order, return content (GameObject info, children, components preview), but does not explicitly state read-only behavior or error handling. The behavioral details are adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) with no wasted words. Each sentence adds value: search context, precedence, return values. 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description explains search behavior but lacks details on missing objects, error responses, or output format. It is moderately complete but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (6 parameters, all described). The description adds minimal extra meaning beyond schema descriptions. For example, it says 'returns components preview' which relates to includeComponents, but does not clarify interactions like hierarchyDepth depending on includeHierarchy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Finds') and resource ('GameObject'), and clearly distinguishes the search context (opened Prefab vs Scene). It differentiates from sibling tools like gameobject-create or gameobject-destroy by focusing on finding and returning information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to find a GameObject in a prefab or scene) and states the search precedence (prefab first, then scene). It does not explicitly mention alternatives or when not to use it, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Modify GameObject fields and properties in opened Prefab or in a Scene. You can modify multiple GameObjects at once. Just provide the same number of GameObject references and SerializedMember objects.
| Name | Required | Description | Default |
|---|---|---|---|
| gameObjectRefs | Yes | Array of GameObjectRef to modify. SCHEMA: [{"name":"ObjectName"}] or [{"instanceID":12345}] | |
| gameObjectDiffs | Yes | Array of diffs (same length as gameObjectRefs). SCHEMA: [{"props":[{"name":"tag","value":"EditorOnly"}]}] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Modify' but does not disclose behavioral traits such as whether the operation is destructive, requires saving, or has side effects. No details on error handling or success indicators.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and quickly provide a usage hint. No unnecessary words, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is minimal. It explains the basic functionality and the length constraint but lacks behavioral context, error conditions, or return value information. Adequate for a simple tool but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters with examples, but the description adds value by clarifying that the arrays must have the same length and mentioning 'SerializedMember objects', which maps to the 'gameObjectDiffs' parameter. This goes beyond the schema's basic type info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Modify'), the target resource ('GameObject fields and properties'), and the context ('opened Prefab or in a Scene'). It also mentions the ability to modify multiple GameObjects at once. However, it does not differentiate from sibling tools like 'gameobject-component-modify' or 'object-modify', so it misses some specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It only mentions the context of opened Prefab or Scene, but does not state when not to use it or what other tools are better suited for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set parent GameObject to list of GameObjects in opened Prefab or in a Scene. Use 'gameobject-find' tool to find the target GameObjects first.
| Name | Required | Description | Default |
|---|---|---|---|
| gameObjectRefs | Yes | Array of GameObjectRef to reparent. SCHEMA: [{"name":"ChildObject"}] | |
| parentGameObjectRef | Yes | New parent. SCHEMA: {"name":"ParentObject"} or {"instanceID":12345}. Use null to unparent. | |
| worldPositionStays | No | A boolean flag indicating whether the GameObject's world position should remain unchanged when setting its parent. | true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries transparency burden. It mentions 'in opened Prefab or in a Scene' and discusses worldPositionStays, but does not elaborate on side effects or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key action and prerequisite. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given schema covers parameters and no output schema, the description adequately explains usage context and prerequisite. Lacks details about return values but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds minimal extra meaning beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set parent GameObject to list of GameObjects', specifying the action and resource. It distinguishes from siblings like gameobject-find by noting prerequisite use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description advises using 'gameobject-find' first, establishing when to use this tool. However, it does not explicitly state when not to use it or list alternatives, though the purpose is straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze the current scene's local lights (Point, Spot, Area) and return their influence bounds, spatial density, and recommended probe placement parameters. Directional lights are skipped as they have no localized influence. Use this before 'lightprobe-generate-grid' to determine optimal spacing.
| Name | Required | Description | Default |
|---|---|---|---|
| cellSize | No | Grid cell size for spatial density analysis (in world units). | 5 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that directional lights are skipped and describes the outputs (influence bounds, density, probe parameters). It does not mention side effects or limitations beyond that, but is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: purpose, a clarifying exclusion, and usage guidance. Every sentence adds value, and the key information is front-loaded. No redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists the returned data types (influence bounds, spatial density, probe placement parameters). It lacks detail on return format or structure, but is adequate for a single-parameter tool with clear sibling guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (cellSize) already described in the schema. The description adds a brief usage context (grid cell size for spatial density analysis) but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes local lights (Point, Spot, Area) and returns influence bounds, spatial density, and probe placement parameters. It explicitly excludes directional lights, distinguishing it from other light-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool before 'lightprobe-generate-grid' to determine optimal spacing, providing clear context. It lacks explicit when-not-to-use scenarios or alternatives, but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger light baking in the current scene. Bakes Light Probe data (and Lightmaps if static objects exist). Make sure lights are set to Baked or Mixed mode before baking (use 'lightprobe-configure-lights' to configure). Use 'lightprobe-analyze' and console-get-logs to verify results after baking completes.
| Name | Required | Description | Default |
|---|---|---|---|
| async | No | If true, bake asynchronously (non-blocking). If false, bake synchronously (blocks editor until done). | true |
| enableBakedGI | No | Enable Baked Global Illumination in Lighting Settings. | true |
| enableRealtimeGI | No | Enable Realtime Global Illumination in Lighting Settings (Enlighten). Usually not needed with Baked GI. | false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions baking of probes and lightmaps, and hints at async vs sync behavior via parameter, but does not disclose side effects like overwriting data, performance impact, or whether saving is needed. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action, no fluff. Every sentence adds value: purpose, prerequisite, and follow-up steps. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, the description covers the main purpose, necessary preconditions, and post-baking verification. Could elaborate on behavior (e.g., overwriting), but provides enough for a knowledgeable user in a Unity context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 3 parameters with 100% description coverage. The description adds no additional meaning beyond the schema, only referencing a prerequisite. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool triggers light baking, specifying it bakes Light Probe data and Lightmaps. It uses specific verbs ('Trigger', 'Bakes') and distinguishes from sibling tools like lightprobe-analyze and lightprobe-configure-lights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: after configuring lights to Baked or Mixed mode with 'lightprobe-configure-lights', and before verifying results with 'lightprobe-analyze' and console-get-logs. Provides clear context for pre- and post-steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove auto-generated LightProbeGroup GameObjects from the scene. By default only removes groups whose name starts with 'LightProbeGroup_Auto'. Set removeAll=true to remove ALL LightProbeGroups.
| Name | Required | Description | Default |
|---|---|---|---|
| removeAll | No | If true, remove ALL LightProbeGroups in the scene, not just auto-generated ones. | false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It explains the default filter and the removeAll option but does not mention that the operation is destructive, irreversible, or has no undo. Some behavioral context is added beyond the schema, but safety implications are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. It front-loads the purpose and immediately provides conditional usage. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the main behavior and parameter. It lacks mention of prerequisites like an open scene, error conditions, or that the removal is immediate, but it is reasonably complete for a basic action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter removeAll is fully described: its type, default value, and effect. The description reiterates and clarifies the default behavior, adding value over the schema alone. Schema coverage is 100%, and the description enhances understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove'), the resource ('LightProbeGroup GameObjects'), and the context ('auto-generated', from scene). It distinguishes from sibling tools that perform other light probe operations like baking or configuring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Guidance is provided on default behavior (only auto-generated) and the optional flag to remove all groups. While it doesn't explicitly state when not to use or suggest alternatives, the context is sufficient for a straightforward removal tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Batch-configure Light bake modes in the scene. Each entry specifies a name pattern (supports * wildcard) and a target mode (Realtime, Baked, Mixed). Use 'lightprobe-analyze' first to inspect all lights and their current modes, then decide which lights to change based on the analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| lights | Yes | Array of light configurations. SCHEMA: [{"namePattern":"Directional*","mode":"Mixed"}] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It describes the action as 'batch-configure' and explains the parameter structure, but does not disclose potential side effects, atomicity, or whether the operation is destructive. Lacks explicit behavioral details beyond the core function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences covering purpose, parameter explanation, and usage prerequisite. No redundant information; every sentence serves a clear function. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description adequately explains the tool's purpose and usage. References a sibling tool for context. However, it omits mention of return values or success/failure indicators, which could be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the schema by explaining that each entry specifies a name pattern with wildcard support and target mode, and lists allowed modes (Realtime, Baked, Mixed), while the schema only provides a brief example. Schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Batch-configure Light bake modes in the scene', specifying the verb (batch-configure), resource (light bake modes), and the action. It distinguishes from the sibling 'lightprobe-analyze' which is for inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to 'Use lightprobe-analyze first to inspect all lights and their current modes, then decide which lights to change based on the analysis', providing clear guidance on when to use this tool and the prerequisite step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate Light Probes in a 3D grid within local light influence ranges. Supports density gradient: denser probes near light centers, sparser at edges. Scans Point/Spot/Area lights, skips Directional lights. Uses raycasting to find ground level and Physics.CheckSphere to avoid placing probes inside geometry. Use 'lightprobe-analyze' first to get recommended spacing values.
| Name | Required | Description | Default |
|---|---|---|---|
| spacingXZ | No | Horizontal spacing between probes. Default: 3 | 3 |
| spacingY | No | Vertical spacing between probes. Default: 2 | 2 |
| heightLevels | No | Number of vertical layers of probes above ground. | 3 |
| groundOffset | No | Height offset from ground for the first probe layer. | 0.5 |
| groupName | No | Name of the LightProbeGroup GameObject to create. | LightProbeGroup_Auto |
| insideCheckRadius | No | Radius for CheckSphere to reject probes inside geometry. Set to 0 to disable. | 0.300000012 |
| useDensityGradient | No | Enable density gradient: denser probes near light centers (d<0.4 range → half spacing), standard spacing at mid-range (0.4-0.8), sparser at edges (>0.8 → double spacing). When false, uses uniform spacingXZ everywhere. | true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden and covers key behaviors: density gradient logic, light type scanning (skipping directional), raycasting for ground level, and Physics.CheckSphere to avoid geometry. It explains the effect of the 'useDensityGradient' parameter in detail, though it doesn't mention potential performance impact or undo behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each contributing unique information. It is front-loaded with the primary purpose and efficiently covers algorithm details, parameter behavior, and usage recommendation. No redundant or vague statements are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 params, no output schema), the description explains most aspects: the generation algorithm, density gradient, light scanning, and physics checks. However, it does not describe the output (e.g., what is returned or the created GameObject's properties) or error conditions. It references the analyze tool for spacing, which compensates slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters have schema descriptions (100% coverage), and the description adds extra context, especially for 'useDensityGradient' (explaining the gradient stages) and 'insideCheckRadius' (mentioning it uses CheckSphere). This helps in understanding how parameters interact, surpassing the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates light probes in a 3D grid within light influence ranges, with specific details on density gradient and light type scanning. It distinguishes itself from sibling tools like 'lightprobe-analyze' and 'lightprobe-bake' by focusing on grid generation and even references the analyze tool as a prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using 'lightprobe-analyze' first to get recommended spacing values, providing a clear usage sequence. While it doesn't list alternatives, the context of sibling tools (e.g., lightprobe-clear, lightprobe-configure-lights) makes the tool's role as the grid generator clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get data of the specified Unity Object. Returns serialized data of the object including its properties and fields. If need to modify the data use 'object-modify' tool.
| Name | Required | Description | Default |
|---|---|---|---|
| objectRef | Yes | Object reference. SCHEMA: {"instanceID":12345} - get instanceID from gameobject-find or editor-selection-get. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions return type but lacks information on error handling, side effects, or permissions. Expected behavior is inferred but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) with no wasted words. The first sentence defines the core purpose, the second provides an alternative. Information is front-loaded and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter. The description covers purpose, usage, and parameter guidance adequately. However, without an output schema, it would benefit from describing the return format or structure of serialized data for complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 value by explaining how to obtain the parameter value (from instanceID via gameobject-find or editor-selection-get), enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets data of a Unity Object and returns serialized data including properties and fields. It distinguishes itself from the sibling 'object-modify' by mentioning modification alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (to get data) and when to use an alternative ('object-modify' for modifications). Provides clear guidance on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Modify the specified Unity Object. Allows direct modification of object fields and properties. Use 'object-get-data' first to inspect the object structure before modifying.
| Name | Required | Description | Default |
|---|---|---|---|
| objectRef | Yes | Object reference. SCHEMA: {"instanceID":12345} | |
| objectDiff | Yes | SerializedMember diff. SCHEMA: {"props":[{"name":"propertyName","value":any}],"fields":[...]} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool 'Modifies' suggesting destructive action, but does not elaborate on persistence, side effects, permissions, or reversibility. The description is adequate but lacks depth 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no extraneous information. It front-loads the purpose and immediately provides usage guidance, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and the tool has nested object parameters, the description could benefit from explaining return behavior or providing examples of the diff structure. However, the guidance to use 'object-get-data' partially compensates. The description is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes the two parameters. The description does not add extra meaning beyond what is in the schema (e.g., how to construct the diff). Baseline of 3 is appropriate as description adds no value over schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool modifies a Unity Object's fields and properties, using a specific verb and resource. It distinguishes itself from siblings like 'object-get-data' and 'gameobject-modify' by focusing on direct modification of any Unity object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use 'object-get-data' first to inspect the object structure before modifying. This provides clear when-to-use guidance and names a specific sibling tool as prerequisite, effectively differentiating from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install a package from the Unity Package Manager registry, Git URL, or local path. This operation modifies the project's manifest.json and triggers package resolution. Note: Package installation may trigger a domain reload. The result will be sent after the reload completes. Use 'package-search' tool to search for packages and 'package-list' to list installed packages.
| Name | Required | Description | Default |
|---|---|---|---|
| packageId | Yes | The package ID to install. Formats: Package ID 'com.unity.textmeshpro' (installs latest compatible version), Package ID with version 'com.unity.textmeshpro@3.0.6', Git URL 'https://github.com/user/repo.git', Git URL with branch/tag 'https://github.com/user/repo.git#v1.0.0', Local path 'file:../MyPackage'. | |
| requestId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses that the operation modifies manifest.json, triggers package resolution, and may cause a domain reload with results sent after reload. This is good but lacks details on permissions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five concise sentences with no wasted words. The description front-loads the action, then explains side effects and related tools. Perfectly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity, the description covers installation sources, side effects, and sibling tool pointers. Missing details like error handling or duplicate package behavior, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides rich detail on packageId formats, significantly adding value beyond the schema. However, requestId is left completely undescribed, and schema coverage is 50%. The description compensates reasonably well for the main parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool installs a package from various sources (registry, Git, local) and modifies manifest.json. It distinguishes itself from sibling tools by mentioning 'package-search' and 'package-list' for searching and listing packages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly recommends using 'package-search' to find packages and 'package-list' to list installed packages, providing clear alternatives for when not to use this tool. However, it does not explicitly state when to avoid using this tool for other operations like removal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all packages installed in the Unity project (UPM packages). Returns information about each installed package including name, version, source, and description. Use this to check which packages are currently installed before adding or removing packages.
| Name | Required | Description | Default |
|---|---|---|---|
| sourceFilter | No | Filter packages by source. Values: [All, Registry, Embedded, Local, Git, BuiltIn, LocalTarball] | 0 |
| nameFilter | No | Filter packages by name, display name, or description (case-insensitive). Results are prioritized: exact name match, exact display name match, name substring, display name substring, description substring. | |
| directDependenciesOnly | No | Include only direct dependencies (packages in manifest.json). If false, includes all resolved packages. Default: false | false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It implies a read-only operation by stating 'returns information,' but does not explicitly confirm safety, absence of side effects, or any required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, no superfluous content. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description provides a useful summary of return fields (name, version, source, description). Adequate for a listing tool, though details on pagination or result limits would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 extra meaning 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and resource 'packages installed in the Unity project (UPM packages)', and distinguishes from siblings like package-add, package-remove, and package-search by focusing on listing current installations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to use this tool before adding or removing packages, giving clear context. However, it does not mention when not to use it or alternatives like package-search for more specific filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove (uninstall) a package from the Unity project. This removes the package from the project's manifest.json and triggers package resolution. Note: Built-in packages and packages that are dependencies of other installed packages cannot be removed. Note: Package removal may trigger a domain reload. The result will be sent after the reload completes. Use 'package-list' tool to list installed packages first.
| Name | Required | Description | Default |
|---|---|---|---|
| packageId | Yes | The ID of the package to remove. Example: 'com.unity.textmeshpro'. Do not include version number. | |
| requestId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses domain reload and package resolution triggers, which are significant behavioral traits. Lacks details on permissions or reversibility but is thorough given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with core action, followed by important notes in a clear and structured manner with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers constraints and recommended workflow adequately for a removal tool without output schema. Could mention return or effect on dependencies, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds value by clarifying packageId format (no version number) and example, but requestId remains undocumented. Schema coverage at 50% leaves room for improvement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Describes a specific action (remove/uninstall) on a specific resource (package from Unity project), and clearly distinguishes from siblings like package-add and package-list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when not to use (built-in or dependency packages) and recommends using package-list first, providing clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for packages in both Unity Package Manager registry and installed packages. Use this to find packages by name before installing them. Returns available versions and installation status. Searches both the Unity registry and locally installed packages (including Git, local, and embedded sources). Results are prioritized: exact name match, exact display name match, name substring, display name substring, description substring. Note: Online mode fetches exact matches from live registry, then supplements with cached substring matches.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query string. Example: "animation", "com.unity.textmeshpro" | |
| maxResults | No | Maximum number of results to return. Default: 10 | 10 |
| offlineMode | No | Whether to perform the search in offline mode (uses cached registry data only). Default: true. Set to false to fetch latest exact matches from Unity registry. | true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It discloses search sources (registry + installed), result prioritization order, and online mode behavior regarding caching. This provides good insight into the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 4 sentences, front-loaded with the main purpose followed by usage and details. Every sentence adds value without redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters with defaults, search behavior), the description covers key aspects: search scope, result prioritization, and online/offline behavior. However, it does not describe return format or error cases, but output schema absence means agent must infer. Still sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all 3 parameters documented), so baseline is 3. The description adds value by providing examples for 'query', explaining default values for 'maxResults' and 'offlineMode', and clarifying what offline mode does, enhancing agent understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for packages in Unity Package Manager registry and installed packages, using specific verbs and resources. It differentiates from siblings like package-add, package-list, and package-remove by specifying this is for finding packages before installing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to find packages by name before installing them,' which guides when to use. It explains search scope and prioritization but lacks explicit exclusions or alternatives, though the context with siblings implies usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves the full profiler call hierarchy tree for a specific frame. Returns function names, total time, self time, call counts, and GC allocations in a tree structure — equivalent to the Unity Profiler Hierarchy view. Use this to analyze detailed per-function performance.
| Name | Required | Description | Default |
|---|---|---|---|
| frameIndex | No | Frame index to analyze. Use -1 for the latest available frame. Default: -1 | -1 |
| threadIndex | No | Thread index. 0 = Main Thread, 1 = Render Thread, etc. Default: 0 | 0 |
| maxDepth | No | Maximum depth of the call tree to return. Use smaller values for overview, larger values for detailed analysis. Default: 5 | 5 |
| minTotalMs | No | Minimum total time (ms) to include a node. Filters out insignificant calls. Default: 0.1 | 0.100000001 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, performance impact, or caching. The description carries the full burden but remains silent on side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with the main action and output. The second sentence adds a practical use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the return fields (function names, times, call counts, GC allocations) and mentions the tree structure and equivalence to Unity Profiler view. Missing details like default parameter behaviors or performance hints, but still quite complete for a retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with adequate descriptions. The description adds no additional parameter-specific information beyond what the schema provides, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the full profiler call hierarchy tree for a frame, listing returned data and equating to Unity Profiler Hierarchy view. It implies but does not explicitly contrast with sibling profiler tools, thus not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It suggests analyzing detailed per-function performance, providing a usage context, but does not specify when not to use or mention alternatives like profiler-gc-alloc for GC-specific analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the top N functions with the highest GC (garbage collection) allocations in a profiler frame, including their call paths. GC allocations are a major source of frame hitches in Unity — use this to find and eliminate them.
| Name | Required | Description | Default |
|---|---|---|---|
| frameIndex | No | Frame index to analyze. Use -1 for the latest available frame. Default: -1 | -1 |
| threadIndex | No | Thread index. 0 = Main Thread. Default: 0 | 0 |
| topN | No | Number of top entries to return. Default: 20 | 20 |
| minBytes | No | Minimum GC allocation bytes to include. Filters out trivial allocations. Default: 0 | 0 |
| maxDepth | No | Maximum tree depth to scan. Default: 15 | 15 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full behavioral disclosure burden. It accurately indicates this is a read-only analytical operation (returns data, no mutations mentioned), but does not specify behavior when frame data is missing, limits on depth/topN, or any caching or freshness semantics. Adequate 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. The first sentence states the function clearly, the second adds detail (call paths), the third provides motivational context. Every sentence earns its place, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters but no output schema or annotations. The description explains the output (top functions with call paths) but doesn't specify the structure (e.g., list of objects, fields like function name, bytes, call path). For a list-returning tool, this is nearly complete; only the output format is missing but not critical given the name implies a list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all 5 parameters with defaults and brief descriptions (100% coverage). The description does not add new parameter meaning beyond what the schema provides—it only summarizes the tool's output. Baseline 3 is appropriate as the description does not detract but adds no extra parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns top N functions with highest GC allocations and their call paths, specifying the resource (profiler frame) and the specific metric (GC allocations). It distinguishes from sibling profiler tools (e.g., profiler-frame-hierarchy, profiler-hotpath) by focusing on garbage collection, a specific performance concern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool ('GC allocations are a major source of frame hitches in Unity — use this to find and eliminate them'), but does not explicitly state when not to use it or mention alternative tools for other performance issues. The context implies its niche, but lacks explicit guidance on exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the top N most expensive functions in a profiler frame, sorted by self time or total time. Useful for quickly identifying performance bottlenecks without reading the full hierarchy.
| Name | Required | Description | Default |
|---|---|---|---|
| frameIndex | No | Frame index to analyze. Use -1 for the latest available frame. Default: -1 | -1 |
| threadIndex | No | Thread index. 0 = Main Thread. Default: 0 | 0 |
| topN | No | Number of top entries to return. Default: 20 | 20 |
| sortBy | No | Sort by 'selfTime' or 'totalTime'. Default: selfTime Values: [TotalTime, SelfTime] | selfTime |
| maxDepth | No | Maximum tree depth to scan. Deeper = more complete but slower. Default: 15 | 15 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description does not disclose any behavioral traits such as whether it is read-only, requires authentication, or has side effects. It adequately describes the output but lacks transparency on limitations or costs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that are front-loaded with the core functionality and a usage hint. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of profiler tools and no output schema, the description is fairly complete. It could optionally mention the output format or prerequisites (e.g., active profiler session), but it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 minimal extra meaning beyond mentioning sorting by self/total time, which is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the top N most expensive functions in a profiler frame, sorted by self or total time. This differentiates from sibling tools like profiler-frame-hierarchy which returns the full hierarchy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says it is useful for quickly identifying performance bottlenecks without reading the full hierarchy, providing clear context. It implies when to use but does not explicitly state alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Captures a quick performance snapshot including FPS, memory usage, draw calls, triangles, and other key metrics. Useful for a quick overview of current performance status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. While it implies a read-only snapshot, it does not explicitly state safety (no side effects), permissions, or return format. This is insufficient for a safe selection by an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, front-loaded with the action and content. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and high-level metrics but omits details like return value structure (no output schema) or whether the tool is synchronous. For a simple snapshot tool, it is adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so no parameter documentation is needed. The description avoids irrelevant detail, earning a baseline score of 4 per the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: capturing a quick performance snapshot with specific metrics (FPS, memory, etc.). It distinguishes itself from sibling profiler tools (e.g., profiler-frame-hierarchy, profiler-gc-alloc) by emphasizing a 'quick overview' of current status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a usage context ('Useful for a quick overview of current performance status') but does not explicitly exclude scenarios or name alternative tools for deeper analysis. Implied usage is clear, but no when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multi-frame continuous Profiler sampling (snapshot + GC + hotpath + call counts). Writes JSONL summary file and outputs aggregated statistics (with P95/P99 percentiles) on completion. Supports fixed-frame and continuous modes. Auto-loads threshold fences; takes screenshot on violation.
| Name | Required | Description | Default |
|---|---|---|---|
| frames | No | Number of frames to sample. 0 or negative = continuous mode (returns immediately, samples in background until stop signal). Default: 0 | 0 |
| frameInterval | No | Frame interval (Unity frames to skip between samples). Default: 2 | 2 |
| gcTopN | No | Top N GC allocations per frame. Default: 20 | 20 |
| hotpathTopN | No | Top N hotpath functions per frame. Default: 20 | 20 |
| hierarchyMaxDepth | No | Maximum call hierarchy depth. Default: 8 | 8 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully describes key behaviors: writing a JSONL file, outputting aggregated stats with P95/P99, auto-loading threshold fences, and taking a screenshot on violation. It explains continuous mode returns immediately and samples in background. However, it does not mention how to stop continuous mode or if there are side effects on concurrent profiling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) and front-loaded with the main purpose. Each sentence provides essential detail without redundancy, making it easy for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the output (JSONL file and aggregated stats) and covers inputs via schema. However, it lacks information on how to stop continuous mode (no stop tool in siblings), and the immediate return value in continuous mode is unclear. This is a notable gap given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All five parameters are well-described in the input schema (100% coverage). The description adds minimal extra meaning beyond the schema, primarily reiterating defaults and the continuous mode behavior for 'frames'. Since schema coverage is high, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's purpose: multi-frame continuous profiler sampling that includes snapshot, GC, hotpath, and call counts. It distinguishes from sibling tools like profiler-snapshot, profiler-gc-alloc, and profiler-hotpath by highlighting the multi-frame/continuous aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions support for fixed-frame and continuous modes, providing clear context for when to use each. However, it does not explicitly state when not to use this tool or point to alternatives like single-frame profiler tools, leaving some ambiguity for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call C# method. Any method could be called, even private methods. It requires to receive proper method schema. Use 'reflection-method-find' to find available method before using it. Receives input parameters and returns result.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | Yes | Method filter. SCHEMA: {"namespace":"UnityEngine","typeName":"Application","methodName":"get_dataPath","inputParameters":[]} | |
| knownNamespace | No | Set to true if 'Namespace' is known and full namespace name is specified in the 'filter.Namespace' property. Otherwise, set to false. | false |
| typeNameMatchLevel | No | Minimal match level for 'typeName'. 0 - ignore 'filter.typeName', 1 - contains ignoring case (default value), 2 - contains case sensitive, 3 - starts with ignoring case, 4 - starts with case sensitive, 5 - equals ignoring case, 6 - equals case sensitive. | 1 |
| methodNameMatchLevel | No | Minimal match level for 'MethodName'. 0 - ignore 'filter.MethodName', 1 - contains ignoring case (default value), 2 - contains case sensitive, 3 - starts with ignoring case, 4 - starts with case sensitive, 5 - equals ignoring case, 6 - equals case sensitive. | 1 |
| parametersMatchLevel | No | Minimal match level for 'Parameters'. 0 - ignore 'filter.Parameters', 1 - parameters count is the same, 2 - equals (default value). | 2 |
| targetObject | No | Specify target object to call method on. Should be null if the method is static or if there is no specific target instance. New instance of the specified class will be created if the method is instance method and the targetObject is null. Required: type - full type name of the object to call method on, value - serialized object value (it will be deserialized to the specified type). Schema: null for static methods, or {"instanceID":int} | |
| inputParameters | No | Method input parameters. Per each parameter specify: type - full type name of the object to call method on, name - parameter name, value - serialized object value (it will be deserialized to the specified type). Schema: [{"typeName":"string","value":any}] | |
| executeInMainThread | No | Set to true if the method should be executed in the main thread. Otherwise, set to false. | true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that private methods can be called and mentions main thread execution via parameter, but lacks details on side effects, error handling, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with key purpose and prerequisite. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without output schema, description does not specify return shape. For a complex reflection tool with 8 parameters and nested objects, more detail on return format or error behaviors would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. The description adds no extra meaning beyond the schema; it merely says 'Receives input parameters and returns result.' The schema already documents each parameter thoroughly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Call C# method' and specifies that any method, even private, can be called. It differentiates from siblings like 'runtime-invoke' and references 'reflection-method-find' for finding methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to use 'reflection-method-find' first, providing a clear prerequisite. However, it does not explicitly contrast with alternatives like 'runtime-invoke' nor specify when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find method in the project using C# Reflection. It looks for all assemblies in the project and finds method by its name, class name and parameters. Even private methods are available. Use 'reflection-method-call' to call the method after finding it.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | Yes | Method filter. SCHEMA: {"namespace":"UnityEngine","typeName":"Application","methodName":"get_dataPath","inputParameters":[]} | |
| knownNamespace | No | Set to true if 'Namespace' is known and full namespace name is specified in the 'filter.Namespace' property. Otherwise, set to false. | false |
| typeNameMatchLevel | No | Minimal match level for 'typeName'. 0 - ignore 'filter.typeName', 1 - contains ignoring case (default value), 2 - contains case sensitive, 3 - starts with ignoring case, 4 - starts with case sensitive, 5 - equals ignoring case, 6 - equals case sensitive. | 1 |
| methodNameMatchLevel | No | Minimal match level for 'MethodName'. 0 - ignore 'filter.MethodName', 1 - contains ignoring case (default value), 2 - contains case sensitive, 3 - starts with ignoring case, 4 - starts with case sensitive, 5 - equals ignoring case, 6 - equals case sensitive. | 1 |
| parametersMatchLevel | No | Minimal match level for 'Parameters'. 0 - ignore 'filter.Parameters' (default value), 1 - parameters count is the same, 2 - equals. | 0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It accurately conveys the search behavior (looking across all assemblies, finding by name/class/parameters) and the availability of private methods. It does not mention side effects or permissions, but as a read-only find operation, this is acceptable and truthful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: three sentences that immediately state the purpose, then list capabilities, and finally direct to the related tool. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a simple find tool but lacks details about the return value (no output schema) and the structure of the nested 'filter' parameter. It assumes the user understands the schema. Given the complexity (nested object, 5 parameters), the description could provide more context on how to use the filter effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 5 parameters. The description does not add extra meaning beyond what the schema already provides. It only briefly mentions filter parameters in the main text, but the schema already explains the match levels and defaults. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: finding a method using C# Reflection. It specifies the resources (methods in assemblies) and the action (find by name, class, parameters). It distinguishes itself from the sibling 'reflection-method-call' by mentioning it as the follow-up step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: to find a method, and explicitly notes that private methods are accessible. It directs to use 'reflection-method-call' afterward. However, it does not elaborate on when not to use it or alternative approaches, though no other search tools are siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Invoke a public static method on any class in Play Mode. Useful for triggering game actions, changing state, calling test helpers, or executing debug commands. The method must be public and static. For instance methods on MonoBehaviours, use 'reflection-method-call' instead.
| Name | Required | Description | Default |
|---|---|---|---|
| typeName | Yes | Full type name (e.g. 'MyNamespace.GameManager') or simple name (e.g. 'GameManager'). Searches all loaded assemblies. | |
| methodName | Yes | Name of the public static method to invoke. | |
| arguments | No | Arguments as JSON array (e.g. '["hello", 42, true]'). Leave empty or '[]' for no-arg methods. Supported types: string, int, float, bool, null. | [] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description explains the operation (invoke public static method) but does not disclose potential side effects (e.g., state changes, exceptions) or security considerations. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no filler. Every sentence adds value with examples and alternatives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output schema and annotations. Does not describe the return value of the method invocation (e.g., if any). For a reflection tool, missing behavioral traits like permission requirements. Could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—all three parameters are described in the schema. The description adds context about argument formats but does not significantly extend beyond 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.
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies a specific verb ('invoke'), resource ('public static method on any class in Play Mode'), and lists concrete use cases. It clearly distinguishes from sibling tool 'reflection-method-call' for instance methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (public static methods, in Play Mode) and when not to (instance methods on MonoBehaviours, directing to 'reflection-method-call'). Provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query runtime game state in Play Mode. Find MonoBehaviours by type name and read their public fields and properties. Useful for verifying game logic, checking object states, reading scores, debugging component values, etc. Works with any MonoBehaviour in the scene — no project-specific setup required.
| Name | Required | Description | Default |
|---|---|---|---|
| typeName | Yes | Full or partial type name of the MonoBehaviour to find (e.g. 'PlayerController', 'GameManager', 'MyNamespace.EnemyAI'). | |
| fields | No | Specific field or property names to read (comma-separated). If empty, reads all public instance fields and properties. | |
| findAll | No | If true, find all instances. If false, find first instance only. | false |
| maxResults | No | Maximum number of instances to return when findAll=true (default: 10). | 10 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It implies read-only operation ('Query', 'read') and states no setup required, but does not explicitly guarantee no side effects or mention performance impacts. Adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no waste. First sentence states core purpose, second adds use cases and a feature. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema or annotations, the description covers what the tool does, how it works, and use cases. It could mention the return format or limitations (e.g., only public members), but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so baseline is 3. The description adds marginal value by explaining the overall purpose of reading fields, which helps understand parameters, but does not significantly enhance parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Query', 'Find', 'read') and resource ('runtime game state', 'MonoBehaviours') with specific verb+resource. It distinguishes from siblings like 'runtime-invoke' (which likely invokes methods) by focusing on reading state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides concrete use cases ('verifying game logic, checking object states, reading scores, debugging') but does not explicitly mention when to avoid using it or compare to alternative sibling tools for writing or calling methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create new scene in the project assets. Use 'scene-list-opened' tool to list all opened scenes after creation.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the scene file. Should end with ".unity" extension. | |
| newSceneSetup | No | Scene setup. ENUM: "DefaultGameObjects" (camera+light), "EmptyScene". Default: "DefaultGameObjects" | 1 |
| newSceneMode | No | Scene mode. ENUM: "Single" (close other scenes), "Additive" (keep other scenes). Default: "Single" | 0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Missing details on permissions, overwrite behavior, whether the scene is automatically opened, or handling of unsaved changes. Only mentions creation based on path.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no extraneous words. Purpose front-loaded, followed by relevant usage hint. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description does not explain return values or success indication. Missing behavioral context (e.g., does it return scene reference?). Incomplete for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with clear descriptions for all parameters. Description adds no further meaning beyond schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Create' and resource 'scene' in 'project assets', distinguishing it from sibling tools like 'scene-open' and 'scene-list-opened'. Specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a sequential hint to use 'scene-list-opened' after creation, but lacks guidance on when to use this tool versus alternatives like 'scene-open' or 'scene-save'. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This tool retrieves the list of root GameObjects in the specified scene. Use 'scene-list-opened' tool to get the list of all opened scenes.
| Name | Required | Description | Default |
|---|---|---|---|
| openedSceneName | No | Name of the opened scene. If empty or null, the active scene will be used. | |
| includeRootGameObjects | No | If true, includes root GameObjects in the scene data. | false |
| includeChildrenDepth | No | Determines the depth of the hierarchy to include. | 3 |
| includeBounds | No | If true, includes bounding box information for GameObjects. | false |
| includeData | No | If true, includes component data for GameObjects. | false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, required permissions, or side effects. The agent must infer safety from the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, no fluff, directly stating purpose and a usage hint. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite well-documented parameters, the description fails to explain the return format or how parameters affect output. For a tool with 5 optional parameters, the description is too minimal to provide complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 does not add extra meaning beyond the schema's parameter descriptions; it only states the main purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieves' and the resource 'list of root GameObjects in the specified scene', distinguishing it from siblings like 'scene-list-opened'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using 'scene-list-opened' to get a list of opened scenes, providing clear context for when to use this tool, though it does not state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the list of currently opened scenes in Unity Editor. Use 'scene-get-data' tool to get detailed information about a specific scene.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes a read-only operation without side effects, but no explicit mention of non-destructive behavior. Given no annotations, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two front-loaded sentences convey purpose and guidance with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with no parameters or output schema; description fully covers functionality and directs to related tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema, so description adds no parameter info. Baseline 4 for zero-parameter tools is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Uses specific verb 'returns' and resource 'list of currently opened scenes', clearly distinguishing from sibling tool 'scene-get-data'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States when to use (to get list of opened scenes) and suggests alternative for detailed info, but lacks explicit when-not-to-use or exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open scene from the project asset file. Use 'assets-find' tool to find the scene asset first.
| Name | Required | Description | Default |
|---|---|---|---|
| sceneRef | Yes | Scene asset reference. SCHEMA: {"assetPath":"Assets/Scenes/MyScene.unity"} | |
| loadSceneMode | No | Load mode. ENUM: "Single", "Additive". Default: "Single" | 0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. It fails to mention loading behavior (async/sync), effect on existing scenes, or any side effects, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundant information. Every word serves a 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While minimal, the description covers the basic open action. However, given the tool's potential impact (changing active scene), more context on state changes would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents parameters. The description adds no extra meaning beyond what's in the schema, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Open') and resource ('scene from the project asset file'), clearly distinguishing it from sibling tools like scene-create or scene-save.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using 'assets-find' first, providing a clear prerequisite. However, it does not specify when not to use this tool or mention any alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save Opened scene to the asset file. Use 'scene-list-opened' tool to get the list of all opened scenes.
| Name | Required | Description | Default |
|---|---|---|---|
| openedSceneName | No | Name of the opened scene that should be saved. Could be empty if need to save the current active scene. | |
| path | No | Path to the scene file. Should end with ".unity". If null or empty save to the existed scene asset file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose side effects such as overwriting existing files, potential failures (e.g., missing scene), authentication requirements, or whether the operation is reversible. The phrase 'save to the existed scene asset file' hints at overwriting but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, no unnecessary words. It is front-loaded with the core action, then provides a pointer to a related tool. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (save an opened scene), no output schema, and complete parameter descriptions, the description covers most essential aspects. However, it lacks information about error conditions or what happens if the save fails, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline is 3. The description adds value by explaining that empty 'openedSceneName' saves the current active scene and that null/empty 'path' saves to the existing asset file. This supplements the schema descriptions with practical usage details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Save Opened scene to the asset file.' It uses a specific verb-resource pair and distinguishes itself from other scene tools like scene-open or scene-create by focusing on saving. References a related tool (scene-list-opened) for context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by mentioning the prerequisite 'scene-list-opened' tool for obtaining scene names. It implies when to use the tool (after opening a scene), but does not explicitly state when not to use it or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the specified opened scene as the active scene. Use 'scene-list-opened' tool to get the list of all opened scenes.
| Name | Required | Description | Default |
|---|---|---|---|
| sceneRef | Yes | Scene asset reference. SCHEMA: {"assetPath":"Assets/Scenes/MyScene.unity"} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the core behavior (set active scene) but does not disclose potential side effects or error conditions (e.g., invalid sceneRef). The behavior is simple, so minimal disclosure is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. First sentence states purpose, second provides usage guidance. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool, the description covers purpose and prerequisite. No output schema is needed. Complete enough for an agent to decide when and how to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes the one parameter fully with an example. Description adds no extra meaning beyond the schema. With 100% schema coverage, baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action: 'Set the specified opened scene as the active scene.' Specific verb 'set' and resource 'active scene' differentiate it from sibling tools like scene-list-opened (list) and scene-open (open).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using scene-list-opened first to obtain opened scenes, providing clear context for when to invoke this tool. Does not explicitly state when not to use it, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unload scene from the Opened scenes in Unity Editor. Use 'scene-list-opened' tool to get the list of all opened scenes.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the opened scene to unload (not the path). Get from scene-list-opened. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description indicates an unload operation but does not mention potential side effects like loss of unsaved changes or required permissions. Adequate for a straightforward destructive action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant information. Direct and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the necessary information: action, resource, and parameter source. Fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes parameter; description adds value by specifying the source ('Get from scene-list-opened') and clarifying that it's the name, not path. Reduces ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (unload) and resource (scene from opened scenes). References sibling tool 'scene-list-opened', distinguishing it from other scene operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use 'scene-list-opened' to obtain the scene name, providing context for when to use this tool. Does not mention when not to use or alternatives, but sufficient for a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a screenshot of the Game view (Play Mode) or Scene view (Edit Mode) and save it as a PNG file. Returns the file path so Claude can use the Read tool to view the image. Useful for visually verifying game state, UI layout, or debugging rendering issues.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Optional tag prefix for the filename (e.g. 'before-fix', 'ui-check'). If omitted, the filename is 'screenshot_<timestamp>.png'. | |
| width | No | Output width in pixels (default: 960). | 960 |
| height | No | Output height in pixels (default: 540). | 540 |
| superSize | No | Super-sampling multiplier for higher quality (1-4, default: 1). Only applies to Play Mode captures. | 1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description reveals key behaviors: saves as PNG, returns file path, superSize only applies to Play Mode. It does not mention file overwrite behavior or required permissions, but overall provides sufficient transparency for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-loaded with the action and result. Every word serves a purpose, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return value (file path). All parameters are described with defaults and constraints. The tool is straightforward and the description covers all necessary aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the schema: explains tag as optional filename prefix, dimensions as output size, and superSize as supersampling multiplier limited to Play Mode. Schema coverage is 100% but description enriches with practical details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures a screenshot of Game or Scene view and saves it as PNG. It uses a specific verb 'Capture' and resource 'screenshot', and distinguishes between Play/Edit modes. No sibling tools overlap, so differentiation is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it's useful for visual verification, UI layout, and debugging rendering issues. It provides clear context for when to use but does not explicitly state alternatives or when not to use. However, given no competing sibling, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete the script file(s). Does AssetDatabase.Refresh() and waits for Unity compilation to complete before reporting results. Use 'script-read' tool to read existing script files first.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | Array of file paths to delete. Example: ["Assets/Scripts/Old.cs"] | |
| requestId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that AssetDatabase.Refresh() is called and Unity compilation waits before reporting results, which is important 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, starting with the core action, and every sentence provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers key behavioral aspects, it lacks details on error handling, success/failure reporting, and the purpose of 'requestId'. Given no output schema, it could provide more on return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%, and the description adds minimal value beyond the schema for the 'files' parameter. The 'requestId' parameter is not mentioned or explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete the script file(s)', specifying the exact action and resource. It also distinguishes from the sibling 'script-read' tool by advising to use it first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance to use 'script-read' first, indicating a precondition. However, it does not specify when not to use the tool or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compiles and executes C# code dynamically using Roslyn. The provided code must define a class with a static method to execute.
| Name | Required | Description | Default |
|---|---|---|---|
| csharpCode | Yes | C# code that compiles and executes immediately. It won't be stored as a script in the project. It is temporary one shot C# code execution using Roslyn. IMPORTANT: The code must define a class (e.g., 'public class Script') with a static method (e.g., 'public static object Main()'). Do NOT use top-level statements or code outside a class. Top-level statements are not supported and will cause compilation errors. | |
| className | No | The name of the class containing the method to execute. | Script |
| methodName | No | The name of the method to execute. It must be a static method in the class provided above. | Main |
| parameters | No | Serialized parameters to pass to the method. If the method does not require parameters, leave this empty. Schema: [{"name":"string","typeName":"string","value":any}] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: the code is temporary, not stored, and must define a class with a static method (no top-level statements). This goes beyond what annotations (none provided) indicate. It does not mention error handling, output format, or side effects, but for a code execution tool, the stated constraints are sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences that front-load the core purpose and key constraint. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 constraints, including the required class/method structure. However, it lacks information about return values or compilation error handling, which is notable given the absence of an output schema. The complexity of code execution warrants a bit more detail on output or errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing detailed parameter documentation. The description reinforces these details (e.g., 'temporary one shot') but does not add significant new semantic information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compiles and executes C# code dynamically using Roslyn, specifying the required structure (class with static method). It distinguishes itself from siblings like 'reflection-method-call' and 'runtime-invoke' by focusing on dynamic compilation rather than invoking existing methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for one-shot temporary code execution (not stored scripts), which differentiates from siblings like 'script-read' or 'script-update-or-create'. However, it does not explicitly compare with other code execution tools like 'runtime-invoke', leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads the content of a script file and returns it as a string. Use 'script-update-or-create' tool to update or create script files.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Path to the script file. Example: "Assets/Scripts/MyScript.cs" | |
| lineFrom | No | The line number to start reading from (1-based). | 1 |
| lineTo | No | The line number to stop reading at (1-based, -1 for all lines). | -1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description alone must convey behavior. It correctly indicates a read-only operation but lacks details on error handling or permissions. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no unnecessary words. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return type. Schema covers parameter details. Mentioning line range behavior would improve, but overall adequate for a read tool with well-documented schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with clear descriptions. The tool description adds minimal extra meaning beyond the schema, only mentioning the sibling tool. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Reads the content of a script file and returns it as a string,' which is a specific verb and resource. It also distinguishes from the sibling 'script-update-or-create,' making purpose very clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use 'script-update-or-create' for updating or creating script files, providing clear when-to-use guidance and a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates or creates script file with the provided C# code. Does AssetDatabase.Refresh() at the end. Provides compilation error details if the code has syntax errors. Use 'script-read' tool to read existing script files first.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Path to the script file. Example: "Assets/Scripts/MyScript.cs" | |
| content | Yes | Full C# source code content for the file. | |
| requestId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: AssetDatabase.Refresh() and compilation error details. However, no annotations exist, and it omits potential side effects like overwriting files 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding value: purpose, side effects, and usage advice. No extraneous words, front-loaded with primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main behaviors and provides a usage hint. Lacks return value specification (e.g., whether errors are returned). Acceptable given complexity and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides descriptions for 2 of 3 parameters (67% coverage). Description adds no new semantic information beyond repeating schema content. Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool updates or creates script files with C# code, and distinguishes itself from sibling 'script-read' by advising to read first. Verb+resource is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using 'script-read' before this tool, providing clear context. Does not specify when to choose update vs create, but the recommendation is helpful for workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute Unity tests and return detailed results. Supports filtering by test mode, assembly, namespace, class, and method. Recommended to use 'EditMode' for faster iteration during development.
| Name | Required | Description | Default |
|---|---|---|---|
| testMode | No | Test mode to run. Options: 'EditMode', 'PlayMode'. Default: 'EditMode' Values: [EditMode, PlayMode] | 1 |
| testAssembly | No | Specific test assembly name to run (optional). Example: 'Assembly-CSharp-Editor-testable' | |
| testNamespace | No | Specific test namespace to run (optional). Example: 'MyTestNamespace' | |
| testClass | No | Specific test class name to run (optional). Example: 'MyTestClass' | |
| testMethod | No | Specific fully qualified test method to run (optional). Example: 'MyTestNamespace.FixtureName.TestName' | |
| includePassingTests | No | Include details for all tests, both passing and failing (default: false). If you just need details for failing tests, set to false. | false |
| includeMessages | No | Include test result messages in the test results (default: true). If you just need pass/fail status, set to false. | true |
| includeStacktrace | No | Include stack traces in the test results (default: false). | false |
| includeLogs | No | Include console logs in the test results (default: false). | false |
| logType | No | Log type filter for console logs. Options: 'Log', 'Warning', 'Assert', 'Error', 'Exception'. (default: 'Warning') Values: [Error, Warning, Log] | 2 |
| includeLogsStacktrace | No | Include stack traces for console logs in the test results (default: false). This is huge amount of data, use only if really needed. | false |
| requestId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full behavioral burden. It only states 'execute tests' without disclosing side effects, permissions, or whether results are synchronous. Lacks detail on return value behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with purpose, then filtering capability, then usage recommendation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 12 parameters and no output schema, description omits return value details, synchronization behavior, and potential state changes. Incomplete for agent to fully understand tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 92% with detailed parameter descriptions. Description adds only a generic mention of filtering, adding minimal value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it executes tests and returns results, with specific filtering capabilities. Distinguishes from siblings since no other test tool exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Recommends EditMode for faster iteration, implying PlayMode for full simulation. Provides clear context for when to use each mode, but no explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tools are clearly separated by domain (assets, gameobjects, prefabs, light probes, profiler, reflection, scripting, scenes, etc.). Even overlapping areas like runtime-invoke vs reflection-method-call are distinguished by usage context. Each tool has a distinct purpose.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., assets-copy, gameobject-find, scene-open). Exceptions like lightprobe-analyze still follow the pattern. This makes the set predictable and easy to navigate.
With 65 tools, the count is high but appropriate for the breadth of Unity editor automation covered. The scope justifies the number, though some tools could potentially be merged (e.g., object-get-data and object-modify). Still, it remains well-scoped for a comprehensive bridge.
The tool set covers all major Unity editor workflows: assets, gameobjects, prefabs, scenes, scripts, packages, reflection, profiler, light probes, tests, and screenshots. It includes CRUD operations, analysis, and debugging utilities, with no obvious missing functionality.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to control Unreal E…
Universal AI API Orchestrator — 1,554 tools, 96 services. One install.
Shared control plane for AI coding agents — tasks, memory, decisions, file locks. 12 tools.
65+ AI tools as MCP: research, write, code, scrape, translate, RAG, agent memory, workflows
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/butterlatte-zhang/unity-ai-bridge'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
