PlayCanvas Editor MCP Server

Official

by playcanvas

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Nearly every tool has a clearly distinct purpose, reinforced by explicit 'When NOT to use' cross-references that route agents to the correct alternative. A few overlapping clusters remain — query_settings/query_project_settings/modify_settings and the three script-attachment tools (attach_script, add_script_component_script, add_entity_scripts) — but the descriptions largely resolve the ambiguity.
Naming Consistency4/5
The dominant snake_case verb_noun pattern (create_branch, delete_entities, load_scene, capture_viewport) is highly consistent across the vast majority of tools. Minor deviations exist for external-service tools (store_search, sketchfab_get, my_assets_search, script_parse, vcs_status) which follow a noun-first convention, creating a recognizable but inconsistent sub-pattern.
Tool Count2/5
At 124 tools, this far exceeds the 25+ 'too many' threshold, making agent tool selection, context management, and effective routing impractical. While the broad game-editor domain justifies more tools than a typical server, the count is excessive and several clusters (texture processing, settings scopes, asset text operations) could be consolidated into parameterized operations.
Completeness5/5
The tool surface provides full lifecycle coverage for every editor subsystem: VCS (branches/checkpoints/merges), entities/components/scripts, assets/materials/textures/animation, scenes, settings, builds, store/Sketchfab imports, template overrides, and runtime testing. There are no obvious dead ends — every major workflow has create/read/update/delete or equivalent operations.
Average 4.2/5 across 124 of 124 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 6 of 6 community issues answered or closed in the last 6 months
- 21 commits in the last 12 weeks
- Last stable release on August 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are effectively all false, providing no safety profile, so the description carries the full burden. It states the action ('apply') but does not disclose side effects, whether existing overrides are overwritten, whether the operation is reversible, or what the response indicates. The two-mode behavior is present, but the consequences are opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one efficient sentence that front-loads the core behavior and the two invocation modes. It contains no filler, though its brevity sacrifices useful detail for the sake of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema and mostly absent annotations, this description is too thin. It does not explain what 'applying' does to the target, what valid override_type values exist, how conflicts are handled, or what a successful invocation returns. An agent would likely need additional context to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the existing parameter description ('Entity ID') is tautological. The description clarifies that entityId refers to a template instance and that overrides can be a specific subset, but it does not explain the meaning of resource_id, override_type, or path, leaving substantial semantic gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Apply') and resource (template instance overrides), and clarifies that it either applies all overrides or only the supplied override records. It is clear and informative, though it does not explicitly name sibling tools like get_template_overrides or revert_template_overrides to distinguish itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as get_template_overrides, revert_template_overrides, or unlink_template_instances. It implies two invocation modes but lacks contextual conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint, and the description is consistent with them. It adds the useful 'current user' scoping but does not disclose pagination behavior, matching semantics, or result ordering; with annotation coverage, this is minimal but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, and it front-loads the core operation and scope. It is efficient, though very sparse and lacking in supporting detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three optional pagination and filtering parameters, no output schema, and many sibling asset/search tools, this description is too thin. It omits how search matches assets, what skip/limit control, and what differentiates this from list_assets, making it incomplete for confident tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain skip, limit, or the search parameter beyond the general word 'search'. The description fails to compensate for the missing schema documentation, leaving parameter meanings mostly underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('search') and resource ('assets') with a clear ownership scope ('owned by the current user'), which helps distinguish it from store or sketchfab search tools. It does not explicitly contrast with sibling tools like list_assets, so it is clear but not maximally differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as list_assets, search_entities, or store_search. The ownership scope implies a use case, but there are no explicit conditions, exclusions, or alternative selection rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds some behavioral context by noting that the result includes durable job status and artifacts, but it does not explain pagination, filtering semantics, or what 'durable' means in practice. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with the main action front-loaded and no filler. It loses a point only because some terms like 'durable job status' are vaguely worded and could be more precise without lengthening the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameter descriptions, the description leaves an agent uncertain about how to filter or paginate results. It mentions status and artifacts as included output, but does not describe the behavior of the cursor, limit, format, actor, or branch parameters. The readOnly annotation helps, but the description is still incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description bears the burden of explaining parameters. It only hints at the type enum via 'publish and download builds' and at status via 'durable job status,' but leaves actor, limit, branch, cursor, format, and status filter semantics unexplained. This is insufficient for seven parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('List') on a specific resource ('publish and download builds') for a designated project, and adds that results include job status and artifacts. It distinguishes the tool as a listing operation from siblings like get_build or download_build, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus get_build, create_build, or download_build. There is no mention of alternatives, exclusions, or conditions that would lead an agent to choose this tool over a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, so the safety profile is known. The description adds no behavioral context such as what data gets overwritten or whether the operation modifies the asset in place. Since annotations cover the main traits, the lack of additional context is acceptable but not additive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler or repetition. It is front-loaded with the core purpose. However, it is almost too sparse, sacrificing useful context for brevity, so it is not a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a required integer id, a destructive hint, and no output schema, the description is under-specified. It does not clarify what the id refers to, what happens to existing prefilter data, or what a successful invocation returns. Given the rich sibling list, this description leaves important operational gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50% because the required 'id' parameter lacks a schema description. The tool description says 'a cubemap' but never explicitly states that 'id' identifies the cubemap asset. The 'legacy' parameter is documented in the schema, but the description does not compensate for the undocumented required argument.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Generate runtime lighting data for a cubemap.' It distinguishes the operation from related siblings such as create_cubemap_from_texture and clear_cubemap_prefilter by focusing on the prefiltering step. However, it does not explicitly contrast against those siblings, so it stops short of a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. Siblings like clear_cubemap_prefilter, create_cubemap_from_texture, and convert_texture_asset imply related workflows, but the description neither mentions them nor states conditions for choosing prefilter_cubemap. The agent is left to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description merely restates the operation and adds no behavioral context beyond what the annotations already provide. The annotations mark the tool as destructive and idempotent, but the description does not explain side effects, permanence, or behavior when the script is not attached.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short, front-loaded sentence with no filler or redundant wording. It communicates the core action efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with destructive and idempotent annotations, the core action and required parameters are adequately conveyed. However, lack of usage guidance and behavioral detail leaves the description only minimally complete for an agent making a nuanced decision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the description does not clarify that 'script' means a registered script name or that 'entityIds' identifies the target entities. The phrase 'one or more entities' adds little beyond the schema's existing property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete action ('Remove') and a specific resource ('a script from one or more entities'), so an agent can understand the operation. It does not explicitly differentiate from sibling tools like add_entity_scripts or move_entity_script, but the verb 'remove' contrasts clearly enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool instead of alternatives such as remove_components, add_entity_scripts, or move_entity_script. There are no conditions, prerequisites, or exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Overwrite the full contents,' which implies destructive replacement of existing text, yet annotations declare destructiveHint=false. This directly contradicts the annotation and obscures the irreversible impact on prior content. No additional behavioral nuance about side effects or reversibility is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. The verb, scope, and target asset types appear immediately, and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema and idempotentHint cover the basic invocation surface, and the operation is simple. However, the destructiveHint contradiction leads the description incomplete on behavioral safety, and the lack of alternative routing leaves selection ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: assetId and text are already clearly documented with 'Text-based asset id' and 'Full replacement contents.' The description adds no further parameter meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific action ('Overwrite'), the full-content scope, and enumerates supported asset types, making the tool's purpose clear. It does not explicitly differentiate from the sibling set_script_text, which overlaps in the 'script' case, but the resource listing is otherwise distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to prefer this tool over alternatives such as set_script_text, get_asset_text, or modify_assets. The asset-type list implies a use case, but there are no explicit conditions, exclusions, or sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds the context that only 'missing' metadata is generated, which implies existing metadata is not overwritten. This is useful but minimal; no mention is made of what changes occur or what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the core meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameter documentation, the description leaves critical gaps: what exactly is pipeline metadata, what the return value is, and whether the tool modifies the asset or returns data. For an agent to invoke it confidently, more context is needed even though the tool is simple.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the only parameter 'id' has no schema description. The description implies 'id' refers to a texture asset, but it does not explicitly explain what the id identifies, how to obtain it, or what valid values mean beyond being a positive integer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Generate') and a specific resource ('metadata for a texture asset'). It is reasonably distinct from texture-related siblings like convert_texture_asset or process_texture_variants, though 'pipeline metadata' is somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus texture conversion or processing siblings. The phrase 'missing pipeline metadata' implies a use case, but the description never states conditions, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate readOnlyHint=true and openWorldHint=true, so the safety and external-world scope are covered. The description adds the 'downloadable' qualifier, which hints at the result focus, but it does not disclose pagination behavior, network reliance, or how results are structured.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the verb, containing no filler. However, it is so terse that it leaves meaningful details unstated, which prevents it from being excellent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with four undocumented parameters and no output schema, the description is too thin. An agent would not know what the response looks like, how to set 'order', how cursor usage works, or how 'downloadable' affects results. The sibling context suggests a search-then-get/import pipeline, but the description does not make that connection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning, but it names no parameters at all. While 'search', 'limit', and 'cursor' are somewhat self-explanatory, 'order' is undefined, and there is no guidance on how cursor pagination works or what values are valid.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Search downloadable Sketchfab models.' This distinguishes it from nearby siblings like sketchfab_get and sketchfab_import. However, it does not clarify what 'downloadable' means in terms of result filtering or what is returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: this is the tool to call when searching for Sketchfab models. However, there is no explicit guidance on when to prefer it over store_search, my_assets_search, or when to follow up with sketchfab_get or sketchfab_import. The agent must infer the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the mutation profile is partially available. The description adds useful behavioral context by saying the result is a 'published' and 'durable build job', which signals that the action has a persistent, non-transient effect. However, it does not disclose whether the build process is asynchronous, whether it can overwrite existing builds, or what side effects publishing may have.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler or repetition. It front-loads the core action and then states the return value, which is an efficient structure for an AI agent scanning tool definitions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no output schema, and minimal annotation detail, this description is insufficient. It tells the agent what the tool does and that it returns a durable job, but it does not clarify how to configure a successful build, what the required name represents, how primarySceneId is used, or how the returned job can be tracked. The description leaves too much to inference for a complex build-creation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% with 12 parameters, so the description must compensate. It does not explain the required name parameter, primarySceneId, minify, version, or any other build configuration field. The only parameter hint, 'for scenes', merely mirrors the existing sceneIds schema description and adds no new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create'), a clear resource ('published PlayCanvas build'), and the target scope ('for scenes in the designated project'). It is easily distinguishable from siblings like list_builds, get_build, and delete_build because it names the creation action and the build artifact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used to create builds, but it provides no explicit guidance on when to use it versus alternatives like set_primary_build, download_build, or delete_build. It does not mention any prerequisite, such as having scenes ready or needing a specific project context, nor does it state when a build should not be created.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavior beyond annotations: it mentions both destructive removal and waiting for processing to settle. This complements the existing destructiveHint=true and idempotentHint=true annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary action and then adds the wait behavior. Every clause adds information, though 'wait for processing to settle' is slightly vague.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no parameter descriptions, and 4 parameters to handle, the description is not complete enough for an agent to invoke this tool confidently. It fails to clarify how formats, remove, and force interact, and what 'settle' means operationally.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not explain the force, remove, or formats parameters. The word 'remove' hints at the remove boolean, but the id, formats, and force semantics remain unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Compress or remove explicit texture variants', which clearly states what the tool does. It distinguishes itself from texture conversion/atlas/metadata siblings by focusing on variant processing, though 'explicit texture variants' is somewhat domain-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as convert_texture_asset or generate_texture_metadata. It only states the action, not the conditions or exclusions that would help an agent choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the readOnly/idempotent/destructive profile. The description adds that the source must be 'downloadable' and that the operation affects the 'current project'. It does not state what project state changes occur, e.g. whether a new asset is created or how license data is handled, so the behavioral value beyond annotations is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with no filler, starts with the action, and conveys the core operation immediately. It is appropriately concise for the amount of information it attempts to deliver.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
At 25% schema description coverage and no output schema, the description must carry much more weight. It covers only the source and target of the operation, leaving parameter semantics, side effects, and relationship to sibling import/asset tools unspecified. This is a meaningful gap for a tool with four parameters and no structured return description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema description coverage is only 25%, and the description does not compensate. uid, name, license, and license's nested fields have no semantic explanation in either schema or description. An agent cannot tell what uid refers to, what name should be, or why the license object is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Import'), a resource ('downloadable Sketchfab model') and a target ('current project'), making the primary purpose clear. It does not explicitly call out sibling differentiators, but the verb/resource combination distinguishes it from search/get-style siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'downloadable Sketchfab model' and 'into the current project' imply when the tool applies, but there is no explicit comparison to alternatives like my_assets_import, store_download, or download_asset. An agent must infer the intended use case rather than being told when to prefer it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true, readOnlyHint=false, and destructiveHint=false. The description adds useful behavioral context by noting that script components are created when needed and that the script must be parsed. However, it stops short of explaining what happens to existing scripts, how attributes are applied, or whether repeated calls simply overwrite.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that wastes no words and front-loads the core action. It is appropriately sized for the tool's complexity and does not repeat schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, a nested attributes object, and no output schema, the description is too thin. It does not explain the purpose of attributes, the meaning of the execution-order index, or how this tool relates to the many similar script/component tools in the sibling list. An agent could call it with required parameters but would lack enough context to use optional parameters confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the description partially compensates: 'one or more entities' clarifies entityIds, and 'parsed script' adds meaning beyond the schema's 'Registered script name'. However, the optional 'index' and especially 'attributes' parameters receive no semantic help from the description, leaving their roles partially underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('attach a parsed script to one or more entities') and includes the key side effect of creating script components when needed. It is clear about the resource and target, but it does not explicitly differentiate itself from similar sibling tools such as attach_script or add_script_component_script.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives like attach_script, add_script_component_script, or add_components. The description implies a use case but provides no exclusions, prerequisites, or decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds a useful state-dependent trait — the tool only works after another scene is loaded — but the self-contradictory phrasing muddles which scene is actually renamed, so the behavioral truth is not clearly disclosed. No contradiction with annotations: renaming is a non-destructive, idempotent mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action and no filler. It loses a point because a slightly longer, more explicit phrasing could have resolved the contradiction between 'currently loaded scene' and 'load another scene first'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter mutation with no output schema and adequate annotations, the description covers the action and a precondition — close to sufficient. But the internal inconsistency plus total silence on naming constraints means an agent may need to attempt the call to discover the actual contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, yet it never addresses the 'name' parameter directly. An agent can infer that name is the new scene name from the tool name alone, but there is no guidance on format, uniqueness, disallowed characters, or whether an extension is appended — leaving a single required parameter underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb (rename) and resource (a scene), and the phrase 'currently loaded scene' differentiates it from siblings like create_scene, duplicate_scene, delete_scene, and load_scene. However, the second sentence ('Load another scene first to rename it') introduces ambiguity about which scene is actually being renamed, suggesting the current one must first be unloaded — the two sentences sit in tension.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an actionable precondition ('Load another scene first to rename it'), which tells an agent when the call is valid. But it never names alternatives or explains when to prefer this tool over scene-related siblings, and the precondition's relationship to the 'currently loaded scene' claim is left unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false (readOnlyHint=false, destructiveHint=false), giving no safety profile. The description says 'convert' but does not clarify whether the source texture is modified, whether new assets are created, or any side effects. It also doesn't mention input format requirements beyond 'equirectangular'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-constructed sentence with the verb and resource front-loaded, no filler, and all essential information present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description omits behavioral clarity (e.g., whether the original texture is preserved) and usage context relative to siblings. It adequately states the conversion but lacks end-to-end completeness for an agent to call it with full confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage: the single parameter 'id' is described as 'Source equirectangular texture asset id', which is clear. The description adds no extra parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Convert'), the input source ('an equirectangular texture'), and the exact outputs ('six face textures and a cubemap asset'). This specific purpose distinguishes it from siblings like prefilter_cubemap and convert_texture_asset without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you have an equirectangular texture needing a cubemap) but provides no explicit guidance on when to choose this tool over related siblings like prefilter_cubemap or convert_texture_asset. There are no when-not or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal a mutating (readOnlyHint=false) but non-destructive (destructiveHint=false) operation. The description adds minimal context beyond the word 'new,' implying the source is preserved and a separate asset is produced. It does not address conversion constraints (e.g., alpha-channel handling when targeting JPEG), accepted source formats, or what the tool returns on success.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 14-word sentence that front-loads the verb and conveys resource, outcome, and formats. No filler, no redundancy with schema fields, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with annotations and a self-documenting enum, the description covers input and outcome. Gaps remain: no return-value information (and no output schema to compensate), no mention of edge cases like JPEG alpha flattening, and no statement of source-format restrictions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (id described, format not), but the format enum self-documents its values. The description reinforces meaning by mapping 'texture source' to the id parameter and listing AVIF/JPEG/PNG/WebP, which mirrors the format enum—yet it adds no constraints beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Convert'), resource ('texture source'), and precise outcome ('new AVIF, JPEG, PNG, or WebP texture asset'). The explicit output formats and the 'new asset' framing differentiate it from texture-adjacent siblings such as create_texture_atlas, process_texture_variants, and modify_assets without needing to name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus the many texture-related siblings (process_texture_variants, reimport_assets, create_texture_atlas, modify_assets). The intended use case—changing a texture's storage format—must be inferred from the verb and format list; no alternatives, exclusions, or preconditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only behavior is covered. The description adds minor scoping with 'valid' and 'for project imports,' but it does not explain what makes a license valid, whether external state is consulted, or what the returned list contains. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the action and scope. It contains no filler, repetition, or extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only listing tool, the description is nearly complete. It could add a bit more context about what qualifies as a 'valid' license or what the returned list looks like, but the current wording is adequate for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so there is nothing for the description to clarify. The baseline of 4 applies because parameter documentation is not needed here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies a clear resource ('valid Store licenses for project imports'), which is enough to distinguish it from asset searching and downloading siblings. It is concise and meaningful, though it does not explicitly name a differentiating sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit when-to-use guidance or alternative routing. The phrase 'for project imports' hints at the intended context, but it does not tell an agent when to choose this tool over store_search, store_get, store_download, or my_assets_import.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the operation is not read-only, not idempotent, and not destructive, so the safety profile is covered. The description adds useful context about ownership and target project, but does not disclose what actually happens during import, such as whether a duplicate is created, whether the original remains in the user library, or what errors may occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundant wording. It front-loads the key facts: the operation is an import, the asset is owned by the current user, and the destination is the current project.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating import tool with no output schema and only basic annotations, the description is too sparse. It does not explain the meaning of required parameters, what the tool returns, prerequisites such as discovering asset IDs, or how this relates to sibling tools like my_assets_search, leaving important gaps for an agent deciding how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents 'id' and 'folder' as Asset IDs, but the required 'name' parameter has no description, and the tool description adds no parameter-level meaning. With only 67% schema description coverage, the description should compensate for this ambiguity but does not clarify whether 'name' is the source name, the new project-local name, or something else.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Import'), a resource ('an asset owned by the current user'), and a destination ('the current project'), making the tool's function clear. This distinguishes it from related siblings like my_assets_search, sketchfab_import, upload_assets, and create_assets, since only this tool imports an already user-owned asset into the current project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the appropriate use case: an agent should call this when it needs to bring an asset from the current user's own collection into the current project. However, it provides no explicit guidance about when not to use it or which sibling tools are alternatives, such as my_assets_search for finding assets first or create_assets for creating new ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true, and the description's 'Rebuild' wording is consistent with those. It adds that the operation is scoped to a supplied character set and inversion setting, but it does not disclose side effects such as overwriting existing font data, breaking references, or long-running processing behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the core operation and its key options, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimally viable for a simple three-parameter operation, and annotations cover the destructive and idempotent aspects. Still, for a destructive tool with no output schema and no usage guidance, it leaves gaps around when to use it, what exactly gets replaced, and what the caller should expect after invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by relating 'characters' to the explicit character set and 'invert' to the optional inversion setting. However, it does not explain the role of 'id' or clarify the expected format of the characters string or the precise meaning of inversion, so the compensation is only partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Rebuild' with a clear resource 'font asset' and specifies the exact scope: an explicit character set and optional inversion setting. This distinguishes it from related asset-processing siblings like process_texture_variants and from generic modify_assets operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not name sibling tools, state prerequisites, or provide exclusion conditions, leaving the agent to infer the appropriate context among many asset-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile. The description adds useful context about recency, edit-time scope, and support for filters/pagination, but it does not disclose default recency windows, ordering behavior, or how pagination behaves when no parameters are supplied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence with no filler. It front-loads the core behavior and then names the key capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify what the tool returns, but it only says 'logs' without specifying response shape or fields. It also omits default behavior when no parameters are provided and does not explain the search filter's semantics. Given five optional parameters, this leaves meaningful gaps for an agent trying to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only 'since' is documented). The description mentions 'filters and pagination' but does not clarify which parameters map to those concepts, what 'search' targets, or default limits. The parameter names are somewhat self-explanatory, but the description does not sufficiently compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Read'), the resource ('edit-time Editor console logs'), and the scope ('recent'). It also distinguishes itself from the sibling read_runtime_logs by explicitly calling out 'edit-time Editor' logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'edit-time Editor console logs' implies when this tool is appropriate, and the presence of read_runtime_logs suggests the alternative. However, the description does not explicitly state when to use this tool versus the runtime-log sibling, so the guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true, so the description does not need to restate those. It adds useful context by specifying that only 'generated runtime lighting data' is removed, but it does not disclose whether the operation is irreversible beyond what destructiveHint already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler or redundant information. The action and target are front-loaded, making it easy for an agent to quickly understand the tool's behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one simple parameter and annotations already communicate destructiveness and idempotency, the description is largely complete for invocation purposes. It could optionally mention expected return behavior or an explicit note about regeneration, but these are minor gaps for a low-complexity operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description carries the burden of explaining the parameter. The phrase 'from a cubemap' indicates that the required id refers to a cubemap, which is meaningful, but it does not add detail about the id format, ownership, or failure behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Remove', and names the resource, 'generated runtime lighting data from a cubemap'. It clearly conveys the tool's action, though it does not explicitly reference the sibling 'prefilter_cubemap' to make the inverse relationship unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies when it should be used: when generated runtime lighting data on a cubemap needs to be removed. However, it does not explicitly state when to choose this over alternatives, mention prerequisites, or describe a typical workflow such as clearing before regenerating with prefilter_cubemap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds that the result is the complete JSON, which is mildly useful, but it does not disclose error behavior, access permissions, or response shape beyond 'complete JSON'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single clear sentence with no waste. The key scoping ('one', 'by id') and output type ('complete JSON') are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only getter, the description is largely complete: it says what it returns, identifies the lookup key, and annotations confirm safety. It lacks explicit routing to sibling asset tools, but that is not essential for invoking this simple tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the id parameter already has a description ('Asset ID'). The tool description only restates that lookup is by id, adding no new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), resource ('one project asset'), and selection key ('by id'), and specifies the result is the complete JSON. This distinguishes it from sibling tools like get_asset_references, get_asset_text, and download_asset without requiring the agent to open their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to choose this tool over alternatives or when not to use it. There is no mention of alternatives such as list_assets for querying multiple assets or get_asset_references for reference data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal mutation, destructiveness, and idempotency. The description adds useful behavioral detail beyond annotations: it returns accepted and rejected IDs and rejects invalid asset types and duplicates. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with the primary action front-loaded. There is no filler, and each sentence contributes either operational meaning or behavioral expectations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the operation and return behavior, and annotations provide the safety profile. However, with no output schema and low parameter schema coverage, the description leaves ambiguity about what each parameter represents, especially id and the contents of add/remove.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the tool description does not compensate for the gap. It does not explain what id refers to or that the add/remove arrays should contain asset IDs; it only hints at 'project assets' generically.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific operation, 'Add or remove project assets from a bundle', which distinguishes it from generic siblings like modify_assets or delete_assets. It also adds expected behavior by mentioning accepted/rejected IDs and validation rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool versus alternatives such as modify_assets or delete_assets, and no explicit exclusions or prerequisites. The agent must infer usage solely from the operation itself, which is not enough for confident tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not contradict them. It adds no extra behavioral context beyond 'by uid,' such as response shape, error behavior, or side effects, but for a simple read-only getter this is acceptable and not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no filler. Every word contributes to identifying the operation, and the key detail ('by uid') is included upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity—one required parameter, read-only annotations, and no nested schema—the description covers the essential information needed to call the tool. It does not describe the return value or not-found behavior, but for a simple get-by-id operation this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'uid' as a required string with no description. The description's 'by uid' clarifies that this parameter is the lookup key for the model, adding operational meaning. However, it does not elaborate on the expected format or provenance of the uid, though the single simple parameter is largely self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Get a Sketchfab model by uid.' It identifies the access method (by uid), which distinguishes it from sibling operations like sketchfab_search or sketchfab_import, though it does not explicitly name or contrast those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: this tool is for retrieving a model when you already have its uid. However, the description gives no explicit guidance about when to use this instead of sketchfab_search, sketchfab_import, or store_get, and no alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the operation duplicates a source texture asset and returns a new asset, making the side effect (creation of a new asset) explicit. Annotations are minimal (all hints false), leaving the description to carry the behavioral burden; it does so reasonably, though it omits details like whether the original is modified or what 'editable' implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that leads with the action and resource, then states the result. Every word earns its place; there is no repetition of the tool name or schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and minimal annotations, the description covers the core action and return value. However, it does not explain when this is preferable to duplicate_assets or convert_texture_asset, nor does it describe any side effects or copy behavior beyond the simple 'duplicate' wording. The tool is simple, but the surrounding sibling set creates ambiguity that is left unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the only parameter 'id' is documented as 'Source texture asset id'. The description adds no extra parameter-level meaning beyond what the schema already provides, which meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Duplicate'), a clear resource ('a texture asset'), and the intended outcome ('as an editable texture atlas and return the new asset'). This clearly distinguishes it from generic duplicate_assets and other texture-related tools even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like convert_texture_asset, duplicate_assets, or process_texture_variants. There is no explicit context, prerequisite, or condition that would help an agent choose it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: the 512 MiB size limit and the overwrite policy ('never overwrite unless overwrite=true'). These are critical for safe invocation and complement the destructiveHint and idempotentHint annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the main purpose and then adds two key constraints. Every clause earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter tool with no output schema, the description covers the essential behaviors: destination type, size limit, and overwrite semantics. It does not describe success/error return values, but the direct wording and schema coverage make it reasonably complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, with assetId and path already documented. The description adds semantics for the overwrite parameter by explaining its effect, which partially compensates for the missing schema documentation on that parameter. However, it adds no further detail on assetId or path.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Download an asset to a local file'), making the tool's core function clear. It does not explicitly differentiate itself from sibling tools like download_build or store_download, but the 'asset' and 'local file' phrasing provides enough distinction for a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives such as get_asset, download_build, or store_download. The usage context is only implied by the phrase 'Download an asset to a local file,' with no exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits beyond the annotations: it waits for the artifact, writes to a local path, and does not overwrite existing files unless overwrite=true. This complements the destructiveHint and readOnlyHint=false annotations without contradicting them, though it does not mention potential long-run wait times 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the main action is front-loaded, and the overwrite caveat follows. Every word earns its place, and the description is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters and no output schema, the description covers the core required behavior but omits return value structure, prerequisites for required inputs like sceneIds and name, and the semantics of optional flags. It is adequate for basic invocation but not fully complete given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for key parameters: format (static or npm), outputPath (explicit local path), and overwrite behavior. However, schema description coverage is only 27%, and the description does not explain many other parameters (name, minify, sourceMaps, concatenate, optimizeSceneFormat, primarySceneId), so it only partially compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create'), a resource ('static or NPM download build'), and unique behaviors (waiting for the artifact, saving to a local path). It clearly conveys what the tool does, though it does not explicitly name sibling tools like create_build to differentiate them; the 'download' and local-save aspects make the purpose distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a downloadable build artifact is needed locally, but it provides no explicit when-to-use or when-not-to-use guidance. It does not reference alternatives such as create_build or download_asset, leaving usage largely implied rather than explicitly scoped.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a mutating operation (readOnlyHint=false) but not destructive. The description adds useful behavioral context by stating duplicates stay in their current folders and that summaries are returned, but it does not disclose details like naming conventions, reference updates, or potential 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the primary action and includes the key scoping detail and return behavior. Every word contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter and no output schema, the description sufficiently covers the operation and its return value. It could be more complete by explicitly explaining that 'ids' selects the assets to duplicate, but the schema and tool name make this reasonably inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'ids' parameter beyond implying they are asset identifiers. The schema only provides 'Asset ID' on array items, so the description adds little semantic value for parameter interpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Duplicate'), the resource ('assets'), and the scope ('in their current folders'). It also specifies the expected return ('created asset summaries'), which distinguishes it from related asset operations like create_assets, move_assets, or delete_assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you want to duplicate assets while keeping them in their original folders. However, it does not explicitly state when not to use it, nor does it mention alternative tools such as move_assets or create_assets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is established. The description adds the useful scoping detail that this applies to publish or download build jobs, but it does not disclose additional behaviors such as return shape, not-found handling, or project designation mechanics. With annotations covering the read-only nature, a middle score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every phrase contributes meaning: the operation, the resource subtype, the lookup key, and the project scope. It is appropriately sized for a simple single-parameter getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only getter, the description is mostly complete: it names what is returned and how it is identified. The main gap is that it does not describe what the returned build job object will contain, and 'designated project' is not explained since the schema only accepts buildId. Still, the tool is simple enough that this is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden for parameter semantics. It only repeats the idea of 'by id' without adding anything beyond the schema property name 'buildId'. The schema itself already provides type and exclusiveMinimum, but the description does not clarify the meaning or origin of the buildId beyond what the property name already implies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('Get'), the resource ('a publish or download build job'), the selector ('by id'), and the scope ('from the designated project'). This differentiates it from siblings like list_builds (listing), create_build (creating), and delete_build (deleting), so an agent can identify the intended tool without inspecting the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by id' implies this tool should be used when a specific buildId is already known, and the mention of 'from the designated project' gives some context. However, there is no explicit guidance about when not to use it or which sibling alternative to choose when the buildId is unknown, such as list_builds.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry destructiveHint=true and readOnlyHint=false, so the mutation safety profile is covered and the bar is lower. The description adds that mutation is limited to scalar fields and data.* array paths, which clarifies scope, but it discloses nothing about partial-failure behavior, whether edits apply atomically, or side effects on references to the asset.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: purpose, array-op capability, and exclusions. The primary scope is front-loaded and there is zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is high-complexity (five operation variants, nested edits array, no output schema), and no schema documentation compensates. The description leaves an agent guessing about op semantics, path conventions, required fields per op, and what the tool returns, so it is not complete enough to invoke correctly on the first attempt.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the schema's single parameter is a polymorphic array with five op variants (set, unset, insert, remove, move) whose path/value/index/to semantics are entirely undocumented in the schema. The description only lists some valid fields (name, tags, preload) and notes data.* for arrays; it never explains what the ops do or what path means, so it only partially compensates for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Edit asset') and enumerates the editable fields: name, tags, preload, and data paths. It also carves out what it does not cover (anim state graph structure, animation events), distinguishing it from modify_anim_state_graph and modify_animation_events. This is specific enough to differentiate it from the many asset-related siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The final sentence gives an explicit when-not: anim state graph structure and animation events are out of scope and require their dedicated mutation tools. However, it never states a positive usage rule or contrasts with other asset-mutation siblings like move_assets or set_asset_text; the when-to-use is only implied by the listed editable fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the description doesn't need to restate that this is a mutating operation. The description adds that the tool returns succeeded/failed entries, but doesn't disclose more about what the pipeline overwrites or changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that immediately conveys action, scope, and return behavior. Every word earns its place, and the description is easy to parse with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite destructive annotations and a complex settings object, the description gives no guidance on expected side effects, settings semantics, or result format. With no output schema, the promised 'succeeded and failed entries' needs more detail to be actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description bears the burden of explaining parameters. It only hints that 'existing source assets' maps to the ids parameter; the large settings object with ~20 fields is entirely unexplained, leaving agents without meaningful guidance for those options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('re-run the import pipeline') and clearly scopes it to 'existing source assets', which distinguishes it from create/upload/import tools. It also states the outcome ('return succeeded and failed entries'), making the tool's purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Existing source assets' provides clear context that this tool is for re-processing already-imported assets, not for creating or uploading new ones. It doesn't explicitly name alternatives or exclusions, but the scope is clear enough for an agent to infer when it applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish idempotentHint=true, destructiveHint=false, and readOnlyHint=false, so the bar is lower. The description adds the key disclosure that the mutation targets transient editor view state rather than persisted entity data, effectively delimiting the write footprint and assuring non-persistence of effects. This complements the annotations and does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, roughly 30 words, front-loaded with the action and resource enumeration followed by the scoping caveat. Every sentence earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Reasonable for a state-setter whose safety profile is carried by annotations. The main gaps are uncovered parameter interactions (orthoHeight only meaningful with orthographic projection), what an all-optional empty call does, and no acknowledgment of the read counterpart query_viewport_state for verification — though since no output schema exists, silence on return values is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 11% schema description coverage (only cameraId is documented in-schema), the description must compensate. It maps parameter groups to aspects — 'camera transform' covers position/rotation/cameraId/orthoHeight, 'grid' covers the nested grid object, 'expanded state' covers expanded — which adds some meaning. However, per-parameter semantics remain undefined: rotation units, orthoHeight's relevance only to orthographic projection, the meaning of grid size vs divisions, and the behavior of an empty call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Set') and resource with an explicit enumeration of covered aspects: camera transform, projection, grid, bones, icon size, and expanded state. The second sentence adds a useful boundary by ruling out entity persisted enabled state, preventing a plausible category confusion. It does not explicitly name sibling tools, but the set/query verb split makes the contrast with query_viewport_state reasonably evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers one meaningful exclusion — 'not an entity's persisted enabled state' — which steers agents away from a real misuse scenario. However, it gives no explicit when-to-use guidance and does not route among the tightly related viewport siblings (query_viewport_state, set_viewport_visibility, focus_camera, focus_viewport), leaving usage largely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey idempotentHint=true, destructiveHint=false, and readOnlyHint=false, and the description adds meaningful behavioral context by disclosing that the operation updates the asset's source file. This goes beyond the annotations, which only say the tool is not read-only without specifying what mutation occurs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the main action ('Generate UV1 data') and then adds the relevant mechanism and side effect. There is no redundant wording or restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core operation but omits useful context about the 'unwrap worker' workflow, such as whether the call is asynchronous, how completion is signaled, or that cancel_model_unwrap exists as a cancellation sibling. With no output schema, agents are left to guess about return behavior and post-call status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both 'id' and 'padding' clearly. The description does not add additional parameter-level meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Generate UV1 data'), a clear resource ('model asset'), and a concrete side effect ('update its source file'). This distinguishes it from adjacent siblings like cancel_model_unwrap and bake_lightmaps, so an agent can tell what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention cancel_model_unwrap, nor does it state prerequisites or situations where another unwrap-related tool would be preferable. Usage context is only implied by the tool name and action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the description does not need to restate that basic safety posture. It adds a concrete 512 MiB per-file limit and discloses that the result separates succeeded and failed entries, giving useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences carry the full core message with no filler. The primary action is front-loaded, and each added clause earns its place by covering replacement, limits, and result behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive annotation and the complex nested assets schema, the description covers the main behaviors but leaves operational gaps: how replacement items should be structured relative to the required path/type fields, and what 'designated project' means in practice. With no output schema, the partial-success mention helps but is not a full contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The top-level assets parameter has no schema description, but the description does add meaning by explaining new-upload versus replace-by-id behavior and by mentioning file-size limits and result partitioning. It does not explain how the required path and type fields interact with replacement items, though the nested schema descriptions partially compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: uploading local files into the project, plus a second replacement mode keyed by asset id. This makes the core purpose clear, but it does not explicitly distinguish the replacement mode from sibling tools like replace_asset or create_assets, so some differentiation effort remains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The two modes imply when to use the tool: upload new local files or replace an existing asset source by id. However, it never names alternatives such as create_assets or replace_asset, nor does it say when not to use those tools, so usage guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false, so the description does not need to repeat those. It adds the important precondition that the unwrap must be 'in-progress', but it does not explain side effects such as whether partial UV data is discarded or whether cancellation is a no-op when no job exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence packs the verb, resource, state, and scope with no filler. Every word contributes to the agent's understanding, and the key precondition 'in-progress' is placed before the resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter cancellation tool, the description plus annotations cover the core information: what is canceled, in what state, and the safety profile (idempotent, non-destructive). It leaves minor questions about job-state behavior implicit, but the idempotentHint largely resolves those.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'id' is fully described in the schema as 'Model asset id' with exclusiveMinimum 0, so schema coverage is 100%. The description's 'model asset' echo adds no new parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a precise verb ('Cancel'), a specific target ('UV1 unwrap'), and the resource scope ('model asset'), making the intent unmistakable. It is clearly distinct from related siblings like unwrap_model_asset and cancel_merge because it is the cancellation counterpart for UV1 unwrapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in-progress' implies the tool is only appropriate when an unwrap is already running, but the description does not explicitly state when to prefer this over other tools or what to do if no unwrap is active. There is no exclusionary guidance, so the usage is inferred rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the description is not burdened with stating that the operation is read-only. It adds the semantic detail that the event map is stable-id based and includes time and payloads, but it does not describe other behavioral traits such as error handling, ordering, or determinism beyond what the annotation covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that specifies the action, resource, and key output content without any filler words. Every phrase contributes meaning, from 'stable-id event map' to 'time and optional number/string payloads'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with a readOnlyHint annotation, the description conveys the essential purpose and the shape of the returned data (event map with time and optional payloads). Since there is no output schema, the description partially fills the return-format gap, though 'stable-id event map' could be defined more precisely for agents unfamiliar with the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter assetId with 100% coverage, including a clear description ('GLB animation asset id') and bounds. The description does not need to add parameter-level detail, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation: getting a stable-id event map for a GLB animation asset, with specific content details (time, optional number/string payloads). The verb 'Get' and the resource 'event map' are explicit, and the tool is clearly distinct from its sibling 'modify_animation_events' which writes rather than reads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read-only use case by using 'Get', but it does not explicitly state when to choose this tool over alternatives or mention any exclusions. There is no direct reference to the sibling 'modify_animation_events' for write operations, so usage guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this is a safe read operation, so the description's main added value is clarifying that the result spans assets, entities, and settings. It does not describe output shape or potential breadth/performance behavior, but for a simple read-only lookup the baseline bar is met.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the action and scope. There is no redundant wording or filler, and the key behavior is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only lookup tool, the description covers the essential purpose and result categories. The absence of an output schema is not a major gap since the description tells the agent what kinds of items will be listed. A short note about response format would make it fully complete, but it is already sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full coverage of the single `id` parameter with 'Asset ID'. The description adds only the context that this ID identifies an asset, which is already implied. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and a precise resource ('project assets, entities, or settings that reference an asset'). It clearly distinguishes this tool from generic asset getters like get_asset by focusing on inbound references rather than the asset itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need to discover which project items depend on or reference a given asset, but it does not explicitly state when not to use it or name alternatives. Context is clear but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false, covering the core safety profile. The description adds the notion of execution-order index, but does not disclose whether moving affects the indices of other scripts, what the response looks like, or any side effects. With annotations present, some credit is given, but the description adds limited new behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence with no filler or repetition. It front-loads the core action and target, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter operation, the description plus annotations and schema are sufficient for an agent to invoke the tool correctly. The operation's purpose and inputs are clear. A small gap is the lack of detail on how the move interacts with other scripts' ordering, but this is not essential for making the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (entityId, script, index) already having a clear description. The tool description adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Move') and a specific resource ('script') with a clear target context ('to a new execution-order index on an entity'). This clearly differentiates the tool from sibling tools like attach_script, add_entity_scripts, and remove_entity_scripts, which perform different operations on entity scripts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the use case of reordering a script's execution position on an entity, but it does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. The sibling tool names provide context, but the description itself offers no direct guidance on selecting this over add/remove script tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds a small behavioral nuance by emphasizing that it updates references rather than modifying or deleting the asset itself, but it does not explain the scope of the replacement, reversibility, or side effects beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately conveys the operation. There is no redundant wording or unnecessary detail, and the key distinction ('references') is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with annotations covering idempotency and destructiveness, the description plus schema is largely sufficient. While it does not mention return values or edge cases like whether assetId and replacementId must differ, these are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only describes both parameters generically as 'Asset ID', while the description clarifies their roles: assetId is the source asset whose references are replaced, and replacementId is the target asset. This added semantic meaning helps an agent correctly map values to the two required parameters despite weak schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Replace') and a precise resource ('references to one asset with another asset'), which clearly distinguishes it from sibling tools like delete_assets, move_assets, or modify_assets. It tells the agent exactly what operation is performed without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_asset_references, delete_assets, or duplicate_assets. There are no stated prerequisites, exclusions, or routing hints, leaving the agent to infer the appropriate context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate that this is a mutating (readOnlyHint=false), idempotent, and non-destructive operation. The description adds the prerequisite that the build must be a completed publish build, but it does not disclose what happens to the previous primary build or whether an incomplete build causes an error.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant wording. It conveys the action, the object, and the key prerequisite efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter with annotations covering safety and idempotency, the description is largely sufficient. It identifies the essential precondition (completed publish build) and the tool's purpose, though it could mention how the buildId is obtained or whether the primary build is replaced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides buildId as an integer with exclusiveMinimum 0, and schema description coverage is 0%. The description helps by indicating that the buildId must refer to a completed publish build, but it does not explicitly name the parameter or explain how to obtain a valid buildId.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation: setting a completed publish build as the project primary build. It clearly distinguishes this from sibling build tools like create_build, get_build, list_builds, download_build, and delete_build.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'completed publish build' implies that only builds that have finished publishing are valid targets, providing a usage condition. However, it does not explicitly name alternatives or state when not to use this tool, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds meaningful behavioral context by stating this is 'one undoable edit,' which tells the agent the operation can be reverted atomically. It also discloses that the tool supports two modes (data modification vs. frame map replacement), going slightly beyond what the schema or annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, dense sentence front-loads the primary action and lists relevant targets without repetition or filler. The alternative mode and undoability are included in a compact way. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with a nested props object and no output schema, the description gives the purpose and the list of change targets but omits details on how to structure the frame map replacement or whether certain fields are mutually exclusive. An agent can make a basic call using `id` and `props` but may struggle with the more complex frame-map replacement path without additional examples or clearer field semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%: only `id` is described in the schema, while the entire `props` object is undocumented. The tool description partially compensates by mapping high-level concepts (atlas, frame order, pixels per unit, render mode) to the likely props fields. However, it does not explain the meaning of `textureAtlasAsset`, the structure of `frames`, or relationships between fields, so the agent still has to guess from property names and nested schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Modify') and resource ('sprite data') and enumerates the exact modification targets: atlas, frame order, pixels per unit, render mode. It also names the second operation mode, replacing a texture atlas frame map. This clearly distinguishes it from generic sibling tools like modify_assets or replace_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when sprite data or a frame map needs changing), but it does not explicitly contrast it with alternatives such as modify_assets, replace_asset, or convert_texture_asset. No exclusions or 'use X instead' guidance is provided, so an agent must infer the boundary from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description aligns with that by saying 'Get'. It adds useful behavioral context beyond the annotations by enumerating the returned structural content (layers, states, transitions, conditions, parameters), which is valuable given there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence that leads with the action and resource, then enriches with a concise list of included data. No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one well-documented parameter and readOnly annotations, the description is largely sufficient. Since there is no output schema, the explicit 'including' list partially fills the gap, though it does not describe edge cases like missing assets or the exact nesting of returned structures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the assetId parameter is already described as 'Anim state graph asset id'. The tool description does not add extra parameter-level meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a specific resource ('anim state graph asset'), and the nature of the payload ('complete structural data... including layers, states, transitions, conditions, and parameters'). This clearly distinguishes it from sibling tools like modify_anim_state_graph or get_animation_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for reading an anim state graph's structure, but it does not explicitly compare it with alternatives such as modify_anim_state_graph or get_animation_events, and it gives no when-not-to-use guidance. Usage is inferable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the description does not need to restate safety. It adds the meaningful detail that the return payload is the 'complete edit-time JSON' and that lookup is by resource_id, but it does not disclose behavior such as error handling, whether deleted entities return empty, or the exact structure of the JSON.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no filler. The core purpose and the key qualifier ('complete edit-time JSON') are front-loaded, making it immediately scannable and actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter with one well-documented parameter and no output schema, the description is mostly sufficient. It communicates what will be returned (complete edit-time JSON) and how to identify the entity. Missing details like error behavior or a return structure example are minor for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents the single parameter id as 'Entity ID' with 100% coverage. The description adds the useful clarification that id is the resource_id, linking the parameter to the concept of an entity resource. This is extra meaning beyond the schema, though the mapping is not perfectly explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('entity'), and specifies it returns the complete edit-time JSON for one entity by resource_id. This clearly distinguishes it from list_entities (which lists entities) and get_selection (which gets selected entities), even without explicitly naming siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: an agent should use this when it needs the full edit-time JSON for a specific entity identified by its ID. However, there is no explicit guidance about when to prefer alternatives like list_entities, resolve_entities, or get_selection, and no mention of prerequisites such as the entity already existing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description's 'Read' aligns with that. The description adds the context that these are 'current apply/revert override records,' which is useful, but it does not disclose any additional behavioral traits such as empty results, error conditions, or effects on template instance state. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler or redundant restating of the tool name. The key operation and resource are front-loaded, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only getter, the description is mostly complete: it names the resource, identifies the parameter semantics, and aligns with the readOnlyHint annotation. However, there is no explicit mention of what the returned override records look like, and no output schema exists to fill that gap, leaving a small amount of ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes entityId only as 'Entity ID' with a UUID format, which is vague. The description adds important meaning by clarifying that the entity ID refers to a template instance whose override records are being read, going beyond the structured schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' and names a clear resource: 'the current apply/revert override records for a template instance.' This distinguishes it from sibling mutation tools like apply_template_overrides and revert_template_overrides, even without 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to inspect override state for a template instance, but it does not explicitly state when to choose this tool over applying, reverting, or unlinking overrides, nor does it mention any preconditions. The read-only intent is obvious from the verb, but concrete usage guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a meaningful behavioral detail beyond the annotations: the tool waits until asset paths update. This signals that the operation is synchronous and that moving may affect asset paths. Nothing contradicts the readOnlyHint=false or idempotentHint=true annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no wasted words. The core operation is front-loaded, and the optional parameter behavior is given in a clean follow-up.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool, the description covers the essential context: what is moved, destination behavior, and the wait-for-path-update detail. It doesn't explain how the 'designated project' is determined or what the return value is, but the schema and annotations fill in enough for a straightforward call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description partially compensates for the weak schema documentation by clarifying that omitting folderId moves assets to the root. However, it doesn't explicitly define folderId as the destination folder's ID, and the schema's 'Nullable asset reference' provides poor guidance. The ids parameter semantics rely mostly on the schema's item-level 'Asset ID' note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Move assets to a folder'), the resource ('assets in the designated project'), and the key optional behavior ('omit folderId to move them to the root'). This clearly differentiates it from the many asset-related siblings like modify_assets, delete_assets, or duplicate_assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the operation itself, but there is no explicit guidance about when to choose move_assets over related tools, nor any exclusions or prerequisites. The only usage hint is about omitting folderId, which is parameter guidance rather than tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The destructiveHint annotation is true, and the description adds valuable scoping context by explicitly differentiating 'all overrides' from 'only the supplied override records', clarifying what will be affected. It does not state whether the operation is reversible, but given the annotation already signals destructiveness, this description provides sufficient behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence communicates the core action and the two modes without fluff. Every word earns its place, and the sentence structure makes the optional scope immediately obvious.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive tool with one required parameter and an optional array, the description covers both invocation modes and clearly identifies the target. It could additionally reference get_template_overrides as the source for override records, but the schema and sibling tool names make that connection discoverable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: only entityId has a description, and it is merely 'Entity ID'. The description helps by implying entityId refers to a template instance and that overrides specifies a subset of override records. However, it does not explain the fields within each override record (resource_id, override_type, path), so parameter semantics remain partially under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Revert'), a clear resource ('overrides on a template instance'), and distinguishes two modes: all overrides vs only supplied override records. It fits its sibling set, particularly alongside get_template_overrides and apply_template_overrides, and tells an agent exactly what operation is offered.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when a template instance's overrides need to be undone, either wholesale or selectively. It does not explicitly name alternatives or conditions for choosing this over apply_template_overrides, get_template_overrides, or unlink_template_instances, but the two-mode phrasing gives functional context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate that this is not read-only, is idempotent, and is not destructive. The description provides no additional behavioral detail beyond naming the action. Since the operation is simple and self-evident, this is adequate, but it does not go beyond what annotations already convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, complete sentence with no wasted words. It is front-loaded with the action and the target resource, making it immediately scannable and understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, trivial state-changing tool, the description plus annotations are sufficient. There is no output schema, but for such a simple operation the behavior is fully conveyed. No hidden inputs, side effects, or prerequisites need explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty with 100% coverage, so there are no parameter semantics to document. The baseline for zero-parameter tools is 4, and the description appropriately focuses on the action rather than inventing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Clear the editor's current selection.' This unambiguously identifies the operation and distinguishes it from sibling tools like set_selection and get_selection. Even though the title is similar, the description clarifies the exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for clearing the current selection, and the sibling list includes selection-related tools such as set_selection and get_selection. However, it does not explicitly state when to prefer clear_selection over alternatives like set_selection with an empty value, nor does it mention any exclusions. Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Overwrite the source code,' which is a destructive/overwriting operation, but the annotation destructiveHint is false. This is a direct annotation contradiction, so behavioral transparency must score 1 despite the description otherwise being transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no filler. The core action is front-loaded, the necessary post-step is included, and the when-not-to-use guidance is concise. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema, the description covers the action, the required next step, and when to choose sibling tools. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are already documented at 100% schema coverage. The description adds the important nuance that text must contain the full file contents, reinforcing overwrite semantics rather than a partial edit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Overwrite the source code of an existing script asset.' It also explicitly contrasts itself with attach_script and create_assets, so an agent can distinguish it from the most relevant siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When NOT to use' section names exact alternatives: attach_script for attaching a script to an entity, and create_assets type="script" for creating the asset. It also gives a concrete follow-up instruction to call script_parse after editing, which is strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses two important behaviors beyond the annotations: it blocks until baking finishes and it reports model assets missing UV1. Annotations only cover readOnly, idempotence, and destructiveness, so this additional operational detail is valuable, though it does not detail all 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences with no filler. The main action is front-loaded, the optional scope is stated immediately, and the behavioral/result note is concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool, the description covers the essential context: what is baked, how to constrain the bake, that it is synchronous, and what diagnostic information is reported. It does not describe the exact return shape, but no output schema exists and the report behavior is at least mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already documents entityIds as optional lightmapped entity resource_ids with omit-to-bake-all semantics. The description restates this idea without adding material new parameter meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Bake scene lightmaps', with a clear optional scope ('limited to the given entities'). This distinguishes it from the many sibling tools that deal with modeling, textures, and scene management rather than lightmap baking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear that this tool is for baking lightmaps and that entityIds can be supplied to limit the bake, with omission meaning all lightmapped entities are baked. It does not explicitly name alternatives or when-not-to-use conditions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safe-read behavior is covered. The description adds relevant behavioral context: fuzzy matching, ranking by relevance, and compact summaries. It does not detail pagination behavior for the default all-matches case, but the schema covers a limit parameter, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. The core behavior is front-loaded, and the exclusion guidance is succinctly placed at the end. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only fuzzy search tool with full parameter coverage and no output schema, the description covers the main agent decision points: what it returns, when to use it, and which siblings to prefer for other cases. A small gap is not spelling out what 'compact summary' contains, but the read-only annotation and simple output expectation make this minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters meaningfully. The description reinforces the query semantics by saying the name may be partial and that limit caps the results, but it adds only marginal behavioral nuance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Fuzzy-search entities by name and return the best matches ranked by relevance (each as a compact summary).' It distinguishes this tool from related entity-lookup tools by describing the fuzzy by-name match behavior and the compact-summary return form.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it — 'when you only know part of its name' — and when NOT to use it, naming two sibling alternatives: filter by component or tag (list_entities) and find entities using a script (find_entities_by_script).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, openWorldHint=true, and idempotentHint=false. The description adds useful behavioral context beyond these: it 'reaches an external service over the network' and 'adds new assets to the project,' which clarifies the side-effect profile. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, all substantive and front-loaded. The main action and scope come first, followed by prerequisites and side effects, with the exclusion last. No filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a network-reaching mutation tool with no output schema, the description covers the core call requirements: purpose, prerequisite, external side effect, and when not to use it. It does not describe return values, but with no output schema and a clear effect statement, the definition is still reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter meaning beyond the schema: it refers to the license fields returned by store_get, but the schema already says 'License info from store_get.' No additional semantic value is provided for id, name, or folder.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Clone/import a public store asset into the current project.' It clearly distinguishes store_download from generic download_asset and sketchfab_import by specifying 'store asset' and 'public'. This is enough for an agent to know what the tool does and how it differs from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear prerequisite: 'Requires the license fields returned by store_get.' It also provides an explicit exclusion: 'When NOT to use: for assets already in the project.' However, it does not name an alternative tool to use in that exclusion case, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive and idempotent, so the description only needs to add context. It does so by clarifying that entity data is preserved even though the template link is severed, which is a meaningful behavioral disclosure beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no filler. The core action is front-loaded, and the behavioral qualifier ('keeping their current entity data') is included without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward mutation with clear annotations and a single parameter, the description is nearly sufficient. It could add a note about the irreversible nature of unlinking or what happens to overrides, but the combination of description and annotations covers the essential operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes entityIds only as UUIDs, so the description adds the important semantic that these identify template instances to be unlinked. For a single-parameter tool, this is enough compensation for the sparse schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Unlink') and resource ('template instances') and adds the key outcome ('while keeping their current entity data'): this clearly distinguishes the tool from sibling template-override tools and from deleting instances. It does not restate the name, and the behavior is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage scenario: detach template instances while preserving their data. However, it does not explicitly state when to choose this over sibling tools such as revert_template_overrides or apply_template_overrides, and it provides no exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly=false and destructive=false, so the description doesn't need to restate them. It adds useful transparency about batch behavior: successful batches return the existing asset-summary array, failed batches retain error status and expose succeeded/failed entries in metadata. This is helpful, though it doesn't go into, for example, what happens to partial successes on the server or whether any part is rolled back.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by the batch/response behavior, then the when-not-to-use guidance. No filler. It loses one point only because the sentence about successful/failed batches is slightly dense for a first read.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no output schema and huge input schema, the description covers the most important orientation: what the tool creates, what binary assets route elsewhere, the per-item type/options pattern, and the batch response behavior. It doesn't explicitly mention the response format for partial failures or give examples of full option objects, but the schema provides the option structures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden. It describes the shape of each asset as { type, options } and gives examples of how options vary by type (material takes data, script takes filename/text, template takes an entity id). It doesn't enumerate every options field, but the schema itself is extremely large and mostly self-describing. The description adds the key semantic distinction between native/text assets and binary assets, which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create') and resource ('one or more native data/text assets'), and distinguishes itself from the sibling upload_assets for binary assets. It also explains the per-item structure. This is a clear, differentiated purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when NOT to use the tool, naming alternatives: add_components/modify_entities for adding assets to an entity, and set_material_properties for changing a material's look after creation. This gives an agent clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so no safety contradiction. The description adds genuine behavioral context beyond the schema: it reveals that results are returned inline (avoiding a follow-up call), that coordinates are local and rotation is in euler degrees, and that rigidbody/collision components will remain frozen unless the Ammo physics module is enabled. It does not describe pagination or error behavior, but that is minor for this create-style tool. No contradiction with annotations, so a 4 is fair.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded, opening with the core purpose before adding coordinate conventions, return behavior, physics caveat, and exclusions. Every sentence contributes. It is longer than ideal, but for a tool with such a rich domain (physics warning, hierarchical creation, return semantics) the length is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with a single required parameter and a rich schema, the description covers the essential context: what it creates, the coordinate system, the return behavior, the physics prerequisite, and the correct sibling alternatives. It doesn't document error cases or branch-context requirements, but those are not critical for initial selection and invocation. Overall, the description is complete enough for an agent to call this tool correctly without a follow-up.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains the entities array, parent uuid, and component fields. The description does add useful semantic clarifications (local coordinates, euler degrees, scale multiplier), but it mostly complements rather than deeply expands the structure. A baseline 3 is appropriate because the schema carries the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Create one or more entities ... in the current scene.' It enumerates concrete object types (cameras, lights, models, UI, empty groups) and explicitly distinguishes itself from modify_entities, add_components, and instantiate_template_assets. This makes the tool's scope and identity unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit 'When NOT to use' section naming the three main sibling alternatives (modify_entities for changes, add_components for components, instantiate_template_assets for templates). It also gives actionable operational guidance, such as not pausing to ask about Ammo physics and relying on the inline return rather than a follow-up list_entities call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint and readOnlyHint=false. The description adds that deletion is permanent and that the linked artifact is also removed, which is valuable beyond the annotations. It does not discuss behavior for already-deleted builds, but idempotentHint covers that aspect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence front-loads the action and object with no filler. Every phrase contributes: permanent, delete, build job, linked artifact, and project context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive tool whose annotations already convey safety and idempotency, this description is complete. It clearly states what is removed and that the removal is permanent; a return-value specification is not necessary for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate for the parameter. 'buildId' is implicitly the identifier of the build job to delete, and the integer schema makes it understandable, but no additional format, source, or lookup guidance is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('delete') and resource ('build job and its linked artifact'), clearly distinguishing it from sibling operations like create_build, list_builds, get_build, and download_build. The word 'permanently' adds important scope about the operation's effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: use this when a build job and its linked artifact should be permanently removed. It does not explicitly list alternatives or when-not-to-use conditions, but the unique delete action is recognizable among the build-related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces this with 'Read-only; does not resolve anything,' explicitly naming the side effect it does not perform. It does not describe return shape or edge cases, but for a read-only tool this is a minor gap rather than a serious omission. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences deliver the core action, the read-only safety property, and the explicit exclusion of resolve_conflicts. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only conflict-file reading tool, the description plus the fully documented schema covers what an agent needs to call it correctly. The absence of an output schema is acceptable because the description already states that the tool reads file content, and no nested objects or complex return constraints exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has a meaningful description explaining its origin, such as 'from start_merge' and 'from the conflict record'. The tool description adds no parameter-specific detail beyond the schema, so the schema carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Read the content of one side of a conflicting file' for the purpose of deciding how to resolve it. It also explicitly distinguishes the tool from resolve_conflicts by stating it is read-only and does not resolve anything.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use the tool — to read conflict content while deciding a resolution — and when not to use it: 'to choose a resolution (use resolve_conflicts)'. This explicit exclusion and sibling routing leaves little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only state readOnlyHint=true and openWorldHint=false. The description adds substantial behavioral detail beyond that: pagination behavior with total/count/hasMore/nextCursor, default limit of 50, empty results being successful rather than errors, and edit-time-only data. This fully informs the agent of expected runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but information-dense, with each sentence earning its place. It front-loads the core purpose and return format, then covers filters, pagination, full mode, empty results, and exclusions in a logical order without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for this tool's complexity. It covers the return format, pagination meta, filter options, full-mode tradeoff, empty-result semantics, edit-time limitation, and relevant non-use cases. Even without an output schema, an agent has enough information to call this tool correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents every parameter. The description does restate some parameter semantics like default limit and full entity size, but adds little new meaning beyond what the schema already provides. This matches the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists entities in the current scene and describes the compact summary format. It is specific about verb, resource, and scope, but it does not explicitly name sibling tools like search_entities or get_entity to draw a sharp contrast, so it falls slightly short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: when to use pagination, when full=true is appropriate, and when not to use the tool (known entity id, runtime/play-mode state). However, it stops short of explicitly naming the alternative tools to use in those cases, which would make the guidance fully actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals no writes, but the description adds context beyond that by clarifying it does not even read persisted entity enabled values. This explains that the operation is scoped to transient viewport state, which is useful behavior not present in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The primary action is front-loaded, and the clarifying scope constraint is provided immediately after. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only query tool, the description is complete: it states the exact result ('list entities hidden only in the editor viewport') and the safety profile is already covered by annotations. No output schema exists, but 'list entities' sufficiently conveys what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so there is no parameter semantics burden on the description. The baseline of 4 applies because with zero parameters, nothing is missing or ambiguous about invocation inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('entities hidden only in the editor viewport'). The clarifying clause about not reading or changing persisted enabled values distinguishes it from operations dealing with persisted entity state, so an agent can tell this apart from sibling set/query tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage for transient editor-viewport-only hidden entities and explicitly notes it does not read or change persisted enabled values, but it never names an alternative tool or states when to prefer this over siblings like query_viewport_state or set_viewport_visibility. The guidance is inferable rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, and the description reinforces this with 'Read-only; does not reload the editor.' It adds useful behavioral context beyond the annotations, such as the current-branch default and the fact that the editor is not reloaded.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. The core action is front-loaded, followed by key defaults, use guidance, and a clear exclusion. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex, with schema and annotations covering most structured details. The description adds use cases and exclusions, but because there is no output schema and the return is only described as 'change data,' the exact shape of the diff result is left unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 4 parameters with descriptions at 100% coverage, so the baseline is 3. The description adds the current-branch default, which is also present in the schema, and does not need to compensate for missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Compute the diff between two checkpoints and return the change data.' It distinguishes itself from related siblings like list_checkpoints and restore_checkpoint, making it clear this tool is for inspecting differences rather than listing or rolling back.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Use to inspect what changed before merging or restoring.' It also has a clear exclusion: 'When NOT to use: to roll back to a checkpoint (use restore_checkpoint).' This directly routes the agent to the correct alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/destructive/idempotent flags. The description adds that the operation returns the created scene record and implies the original scene is unchanged by describing the result as a copy. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each with a purpose: action, return value, and usage exclusion. No filler, and the main action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two simple parameters and no output schema, the description adequately explains the return value and the main alternative. It could additionally clarify name-uniqueness behavior, but for a straightforward create-copy tool it is close to complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents id and name. The description mostly restates the schema's meaning ('by its id', 'new name') without adding non-obvious parameter behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific action 'Duplicate an existing scene by its id' and the result 'giving the copy a new name'. Clearly a scene-copying operation, and the 'When NOT to use' note differentiates it from create_scene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the alternative create_scene for the empty-scene case, preventing misuse. The operation's own trigger (duplicating an existing scene) is clear from the verb and resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that the tool is non-read-only, idempotent, and non-destructive. The description adds useful behavioral context by clarifying that it affects the editor viewport camera rather than scene entities and by revealing the return shape '{ focused: <count> }'. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four short sentences, each contributing a distinct piece of information: the action, the use case, the return value, and the exclusion. It is front-loaded and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though there is no output schema, the description explicitly states the return value. It also provides a positive workflow hint and an explicit mis-use exclusion, which is enough for a simple viewport framing tool. The only minor gap is not directly differentiating from the sibling focus_camera, but the 'editor camera' phrasing resolves most ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter coverage with descriptions, so the baseline is 3. The description paraphrases the schema's 'view' and 'yaw/pitch' concepts without adding new constraints or behavioral details. It does not need to compensate for missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Frame'), a clear resource ('editor camera'), and the target ('given entities'), while also covering optional preset views and custom yaw/pitch. It distinguishes itself from capture_viewport and in-scene camera movement by naming the editor camera as the object being affected.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete workflow context with 'Useful before capture_viewport' and explicitly names an alternative for a common mis-use case: moving an in-scene camera entity via modify_entities. This is strong routing guidance that helps an agent select the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide openWorldHint=true and destructiveHint=false, but the description adds significant behavioral context beyond that: it opens a new browser window, enables debug logging, explains the adopted flag semantics (attaches to existing runtime only when no options passed), describes the ready flag meaning, and notes popup-blocking as a failure mode. The only mild gap is not detailing side effects on a previously running runtime instance, but the adopted explanation covers the main behavioral nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized: it front-loads the core action and effect, then the return contract, then the prerequisite/retry guidance, and finally the exclusion list. Every sentence earns its place. It is longer than average, but the tool has nontrivial semantics (ready/adopted flags, popup blocking, fresh-launch behavior) that justify the length. Slightly trimmed phrasing on the adopted clause would make it a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity — return flags needing interpretation, a browser-window side effect, failure modes, and prerequisite relationships to many sibling tools — the description covers everything an agent needs to invoke it correctly and interpret its result. The output contract ({ url, sceneId, ready, adopted }) is fully explained, which matters because there is no output schema. The failure handling for ready=false is explicitly specified. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description compensates somewhat by explaining that passing any option forces a fresh launch rather than adoption — this adds meaning to the parameter set as a whole. However, the description does not explain individual parameters like debug, bundles, profiler, miniStats, concatenate, or engineVersion, which remain undocumented in both the schema and description. The device enum has a schema description, and waitMs has one, but the remaining booleans are opaque. The baseline is 3 and the description adds aggregate-level semantics, but per-parameter meaning is still missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Start a real Launch runtime instance of the current scene...' It is immediately distinguishable from siblings like capture_viewport (editor screenshot), capture_runtime (uses the launched runtime), and launch_stop (the inverse operation). The phrase 'the editor's Launch button' grounds it in a familiar concept, and the explicit 'When NOT to use' list further differentiates it from capture_viewport and edit-time tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use ('This is the prerequisite for all runtime tools'), what to do if ready=false ('poll read_runtime_logs or retry'), and when NOT to use, naming the alternative tools (capture_viewport for screenshots, edit-time tools for scene changes). It also explains the adoption edge case and how to force a fresh launch by passing an option. This is comprehensive routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation behavior is covered. The description adds valuable context: permission requirements for specific scopes, the editor.pipeline.* convention for asset import defaults, and the advice to query before modifying. Nothing contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with a distinct job: core operation + scope list, a concrete path convention example, and a critical prerequisite/guideline. No filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, arbitrary-path mutation tool with no output schema, the description covers the essential what, where, and access requirements, and warns about the discovery workflow. It could be slightly more complete by naming query_settings as the companion read tool, but the current wording is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% at the top level, so the description must compensate. It explains that paths are dot-notation (matching the schema's 'Dot-notation settings path'), lists the scope enum values in prose, and adds opaque-path pragmatics: query first to discover valid paths/value. This is meaningful beyond the schema's bare enum and item descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Set or unset arbitrary Editor settings') and enumerates the exact scopes (project, scene, projectUser, user, session, projectPrivate). This clearly distinguishes it from related siblings like modify_project_settings, which only target a subset, and from query_settings, which is read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical guidance: query the scope first to discover current paths and values, and notes that project/scene/private scopes require project write access. It does not explicitly name alternative tools or state when not to use this tool, but the guidance is sufficient for an agent to proceed safely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description consistently says 'Read', so there is no contradiction. The description adds behavioral context beyond the annotation by explaining the complete-scope versus dot-path behavior and by giving examples of the settings families covered (including editor.pipeline asset import defaults under per-project user preferences).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences convey the full purpose, the complete list of scopes, and the path behavior with no filler. The most important information is front-loaded in the first clause, making it easy for an agent to quickly classify this as a read-only settings query tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only tool with no output schema, the description is nearly sufficient. It covers scope semantics and path behavior, and the readOnlyHint covers safety. It does not detail the return shape or error behavior, but that is a minor gap for a settings query tool whose name and description already convey what it returns conceptually.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining the parameters. It does this well: it maps the scope enum values to meaningful setting categories and explains how the optional path parameter behaves ('Omit path for the complete scope or provide a dot path for one value'). Some additional detail about path dot-format edge cases would be useful, but the essentials are present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the verb 'Read' and a specific resource ('any Editor settings scope'), then enumerates each supported scope explicitly (project, scene, per-project user preferences, global user preferences, session, private project settings). This clearly differentiates it from sibling tools like query_project_settings or query_scene_settings by signaling it is the general-purpose settings reader.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete operational guidance: omit path for the complete scope or provide a dot path for a single value, and it clarifies which scopes are covered. It does not explicitly name sibling alternatives or state when not to use this tool, but the 'any ... scope' phrasing makes the intended usage clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, and the description aligns by saying 'Read'. It adds meaningful behavioral context beyond the annotation: the tool captures exact state for later restoration, implying a pairing with a set/restore operation. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the core action and resource, and every clause earns its place. The restoral purpose adds useful context without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, a read-only annotation, and no output schema, the description gives enough context for an agent to call the tool: it explains what is read and why. It could more precisely enumerate the returned state fields, but this is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the description carries no parameter burden. The baseline of 4 applies because there is nothing to document and the description correctly focuses on semantics of the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool 'Reads' a specific resource (viewport camera and overlay state) with 'exact' precision. It is easily distinguished from sibling tools like set_viewport_state (write) and query_viewport_visibility (only visibility).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'so it can be restored after visual inspection' communicates the intended workflow and context for using this tool. It implicitly contrasts with set_viewport_state and query_viewport_visibility, though it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as non-readonly, non-destructive, and idempotent. The description adds useful context beyond that: it returns the moved entity summary including the new hierarchy path, and clarifies that preserveTransform keeps the world position. It does not disclose potential edge cases like cycle prevention or default index behavior, but the provided behavioral context is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler: the action comes first, optional behavior second, return value third, and the exclusion with alternative last. Every sentence earns its place and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter tool with no output schema, the description covers the return value, key behavioral option, and routing to an alternative. It does not specify what happens when index is omitted or how hierarchy constraints are handled, but the essential information for correct invocation is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all four parameters. The description adds only modest reinforcement, such as rephrasing preserveTransform as 'keep the entity at the same world position' and mentioning the child index. This is sufficient but not a major value-add over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Move an entity to a new parent in the hierarchy'. It also identifies what this tool is not for by naming modify_entities as the alternative for changing position/rotation directly, clearly distinguishing it from related siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use the tool (reparenting an entity) and when not to use it ('to change position/rotation values directly'), naming the alternative tool modify_entities. It also explains the optional preserveTransform behavior, which helps agents decide whether to set it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral trait: the effect is limited to the editor viewport and persisted enabled values are untouched. Annotations already communicate idempotentHint=true and destructiveHint=false, so the description adds meaningful context about what state is and is not affected. It 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the action ('Hide or show entities'), then states the scoping constraint ('only in the editor viewport') and the critical non-effect ('without changing their persisted enabled values'). Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, no-output-schema tool, the description covers what the tool does, where it applies, and what it does not persist. It could briefly mention that visibility changes are editor-session only, but the phrase 'only in the editor viewport' already implies this. The tool is simple enough that nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given the schema has 0% description coverage, the description helps by mapping 'entities' to the ids parameter and 'Hide or show' to the hidden boolean parameter. It does not explicitly state that hidden=true means hide and hidden=false means show, but the connection is straightforward. This adds meaning beyond the bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair, 'Hide or show entities', and clearly scopes the effect to the editor viewport. It also differentiates itself from persisted entity changes by stating that enabled values are not changed, distinguishing it from sibling tools like modify_entities or set_viewport_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this tool is for viewport-only visibility changes and excludes persisted enabled-value changes. It does not explicitly name an alternative tool such as query_viewport_visibility for reading visibility or modify_entities for persisted changes, but the context and scoping are sufficient for an agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description surfaces important runtime behavior beyond the annotations: the editor reloads, the tool waits for reconnection, and it returns the resulting vcs_status. This is useful context that annotations do not provide. It does not mention edge cases like unsaved changes, but the disclosed behavior is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentence sentences earn their place: the first states the action and behavior, the second provides an explicit exclusion. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a one-parameter tool with clear annotations and rich behavioral detail. It covers what happens, what is returned, and the main alternative. It could go slightly further in contrasting with open_branch/close_branch siblings, but that is not necessary for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already explains that branchId is the id of the branch to switch to. The description reinforces the schema's own reference to list_branches but does not add substantially new parameter meaning. With full schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Switch (checkout) the editor') and the resource ('an existing branch by its id'), with a specific source for IDs ('from list_branches'). It also distinguishes itself from create_branch by explicitly stating it only switches to existing branches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use the tool ('Switch the editor to an existing branch by its id') and explicitly names a non-use case ('When NOT to use: to create a new branch') with the alternative tool ('use create_branch'). This gives the agent concrete decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, indicating a mutating but non-destructive operation. The description adds meaningful behavior beyond that: it returns whether anything was undone and the resulting { canUndo, canRedo } state. This helps the agent understand no-op situations and stack state without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, all carrying distinct value: action, return behavior, usage, and an exclusion with alternative. Front-loaded with the core purpose and no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description covers all necessary aspects: what it does, what it returns, when to use it, and when not to use it. An agent can invoke it correctly without needing any additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is trivially 100%. Baseline for 0-param tools is 4, and the description appropriately focuses on return behavior rather than parameter details. Nothing further is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Undo the last edit in the editor.' It also includes a clear when-not-to-use with a named alternative (load_scene), which differentiates it from at least one sibling. It does not explicitly contrast with redo, but the core operation is unambiguous from the name and phrasing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use is given: 'Use this to roll back a change you just made.' An explicit when-not-to-use is also provided: 'to switch scenes (use load_scene).' This fully satisfies the highest bar for usage guidance, including an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal idempotentHint=true and destructiveHint=false, so the description does not need to restate safety. It adds meaningful behavioral context beyond annotations: the return value is the updated entity summary, and rigidbody/collision components only simulate when the Ammo physics module is enabled. This is useful operational information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average, but every sentence carries practical weight: action, parameter mapping, return value, physics prerequisite, and exclusions. It is front-loaded with the core operation and the physics note is dense but directly actionable, not filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large nested schema and no output schema, the description covers the essential missing pieces: what to pass, what comes back, and a critical environmental prerequisite. It also handles sibling-tool routing. Component-specific field details are already in the schema, so the description does not need to enumerate them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents both parameters well. The description still adds value by clarifying the components object structure: pass each component's initial data under its component name. This helps an agent understand that property names in the components object correspond to component types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Add'), a specific resource ('components to an existing entity'), and enumerates concrete component types. It also explicitly distinguishes itself from create_entities, modify_entities, and attach_script, so an agent can select it without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When NOT to use' section explicitly names the alternative tools and the conditions that route to them. The physics note also gives actionable guidance: if Ammo is not enabled, add the components then enable it rather than stalling. This is complete decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false, so no contradiction. The description adds meaningful behavioral context beyond annotations: it states the requirement that a script component must already exist, and it discloses the return behavior ('Returns the updated entity summary'), which is otherwise absent since there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it states the core purpose first, then the return value, then the critical usage exclusion. Every sentence contributes information without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple two-parameter mutation with clear annotations. The description covers the action, the precondition, the return value, and the alternative pathway. Nothing essential for correct invocation is missing for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description's phrase 'named script' aligns with the scriptName parameter, but it does not add deeper parameter-level meaning beyond what the schema provides. Baseline 3 is appropriate because the schema carries the weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Add a named script to an entity that ALREADY has a script component.' It clearly states the precondition and differentiates itself from the sibling tool attach_script by framing the distinction explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when not to use this tool: 'if the entity has no script component yet, prefer attach_script.' This directly names the alternative and the condition that selects it, leaving no ambiguity about routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations establish this is a non-read-only, non-idempotent mutation. The description adds valuable behavioral context: it creates an empty scene, returns the scene record, and does not change the current scene. This goes beyond the annotation flags, though it could mention failure modes or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences with no filler. The main action is front-loaded, then the return value and non-switching behavior are stated, and finally the alternative is given. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with one optional parameter and annotations covering side-effect flags, the description fully covers what happens, what is returned, and how to open the new scene. No critical operational details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the single optional 'name' parameter with 100% coverage, so the description does not need to add parameter details. The description adds no extra semantics beyond what the schema provides, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('create'), resource ('new empty scene'), and scope ('current project/branch'). Explicitly differentiates from load_scene and duplicate_scene with concrete conditions, so an agent can tell them apart without opening other schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use guidance: creates a scene but does not switch to it, directing the agent to load_scene for opening. Also provides a clear 'When NOT to use' case and names the alternative duplicate_scene for copying an existing scene.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, and the description reinforces this with 'destructive and cannot be undone,' adding permanence beyond the bare annotation. It does not contradict any annotation and provides useful consequence-level context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The action and consequence are front-loaded, and the when-not-to-use guidance is delivered in a compact, directly actionable sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive tool with annotations covering the safety profile, the description covers purpose, usage boundaries, and consequence. No output schema is needed for a delete operation, and nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema description for 'id' already explains that it is the scene id from list_scenes. The description's 'by its id' adds no new meaning. The baseline of 3 applies because the schema does the documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Permanently delete a scene by its id.' It clearly distinguishes the tool from siblings by naming load_scene as the alternative when the intent is to switch away without deleting. The destructive nature is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a 'When NOT to use' condition and names the correct alternative tool (load_scene). This gives an agent a direct decision rule for choosing between delete_scene and its closest sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds useful behavior: it returns 'compact entity summaries' and constrains the input to registered script names. This is sufficient for a simple read-only lookup, though it doesn't specify behavior when the script name is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, return type, and exclusions with alternatives. Every sentence adds value and the key purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with no output schema, the description communicates the input, the return nature, and the alternatives to avoid misuse. Nothing critical is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter is already documented as 'Registered script name to look up'. The description echoes this concept but does not add substantive new meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a precise resource ('entities whose script component uses a given registered script name'). It also draws an explicit contrast with siblings like search_entities and get_asset_text, making the tool's unique purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says exactly when not to use this tool and names the alternatives: search entities by name via search_entities, and read script source via get_asset_text. This gives an agent clear routing guidance with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clarifies that the operation affects the current editor camera rather than scene entities or saved transforms, which adds meaning beyond the annotations. It also implicitly signals that this changes viewport framing in preparation for capture_viewport, while idempotentHint and destructiveHint are consistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and every sentence earns its place: it states the primary behavior, the intended context, and the key exclusions with alternatives. The main use is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter camera-framing tool, the combination of a clear behavioral statement, explicit usage guidance, and alternative routing is complete. The absence of an output schema is not a problem because this operation primarily changes editor state rather than returning structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters and their meaning. The description adds no parameter-specific detail beyond the schema, which is acceptable but not value-adding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Aim the current editor camera to look at a world-space point from a given distance.' It clearly distinguishes itself from related tools by naming focus_viewport and modify_entities as the alternatives for different use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives both a positive use case ('framing an exact location before capture_viewport') and explicit not-to-use cases with direct alternatives ('use focus_viewport' for entities, 'use modify_entities' for in-scene camera entities). This makes selection unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds meaningful context by specifying that the full text contents are returned as text and that the tool does not serve binary assets. This is sufficient for a simple read operation, though it doesn't mention potential size limits or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler: the first sentence front-loads the operation and return type, and the second sentence gives precise negative usage guidance. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool, the description fully covers what the tool does, what it returns, what asset types it applies to, and when to use sibling tools instead. No output schema is needed because the return type is stated explicitly as text.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the only parameter, assetId, with the same valid text-based asset types listed in the description. Schema description coverage is 100%, so the description adds little beyond re-emphasizing what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read') and resource ('full text contents of a text-based asset'), and explicitly enumerates valid asset types (script, text, json, css, html, shader). It also distinguishes itself from siblings by naming what it is not for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit 'When NOT to use' section with concrete alternatives: script_parse for declared name/attribute definitions and list_assets for listing assets. It also rules out binary assets like textures or models, giving clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds behavioral value by specifying the exact return record shape ({ id, createdAt, description, user }), which is especially useful since no output schema is provided. It does not describe not-found behavior, but this is minor for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The primary purpose is front-loaded, the return shape is usefully specified, and the exclusion/alternative is stated efficiently. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool with no output schema, the description covers the core call semantics, the return shape, and the main alternative. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter description already explains 'Id of the checkpoint to get (from list_checkpoints).' The tool description adds little beyond restating 'by its id,' so the schema carries the semantic weight. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get a single checkpoint by its id.' It also explicitly differentiates from list_checkpoints by saying not to use it for listing a branch's checkpoints, so an agent can distinguish the tool from its closest sibling without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use context ('Get a single checkpoint by its id') and an explicit when-not-to-use condition with the correct alternative: 'to list a branch's checkpoints (use list_checkpoints).' This is clear routing guidance beyond simple domain inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals safety, and the description adds useful behavioral specificity beyond annotations: it discloses the exact return shape and clarifies that the tool is for inspecting, not initiating, merge progress. It doesn't fully detail possible statuses or conflict structures, but this is minor given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler: it opens with the core action and return payload, then provides usage context and an exclusion. Every sentence earns its place and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter with one parameter and no output schema, this description is fully sufficient. It covers return values, when to use, and when not to use, which is everything an agent needs to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the only parameter, mergeId, is already documented as 'Id of the merge (from start_merge).' The description implicitly reinforces this by referencing apply_merge and start_merge, but it adds no significant new semantic detail beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a specific resource ('current state of a merge'), and enumerates the returned fields, making the tool's function unambiguous. It also explicitly names the sibling it is not (start_merge), so an agent can quickly distinguish it from other merge-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit usage context: 're-check which conflicts are still unresolved before apply_merge,' and an explicit negative case with an alternative: 'When NOT to use: to start a merge (use start_merge).' This is ideal routing guidance for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations by specifying the id ('not uniqueId') and that the full scene record is returned, helping set expectations for the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, all earning their place: the first states the core action, the second the return value, and the third routes away from misuses. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter getter with readOnlyHint=true, the description covers the id source, return shape, and alternative tools. The lack of an output schema is fine because the description explicitly notes the full scene record is returned. Nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema description already explains the id parameter and its relationship to list_scenes. The description repeats similar id semantics without adding new parameter-specific syntax, format, or edge-case details, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Get a single scene by its id'), clarifies it returns the full scene record, and explicitly differentiates from sibling tools load_scene and list_scenes. An agent can immediately understand this is a read-by-id operation for full scene data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides 'When NOT to use' guidance, naming the alternatives load_scene for loading/switching scenes and list_scenes for listing scenes. This gives clear routing context for the agent with no inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only mark non-read-only, non-idempotent, non-destructive. The description adds useful behavior beyond that: events run in order, coordinates are CSS pixels from canvas top-left, and returns { dispatched }. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: purpose, prerequisite, coordinate framing, return shape, common patterns, follow-up observation, and exclusions. Front-loaded and well structured with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description specifies the return. It also covers prerequisites, ordering semantics, coordinate space, event patterns, how to verify effects, and when to use an alternative. This is complete for an input-injection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter and enum is already documented in the schema. The description adds practical usage patterns but no new parameter semantics, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: dispatches keyboard/mouse/touch input to the RUNNING Launch instance. Clearly differentiates from siblings like launch_start, capture_runtime, and modify_entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly requires launch_start first, gives post-injection observation tools (capture_runtime / read_runtime_logs / query scene), and lists when NOT to use: for direct entity data changes use modify_entities, or before launch_start.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the core behavior beyond the annotations: it creates entity hierarchies in the scene and returns the created entity summaries. It also states the template-only restriction. Annotations already mark the operation as non-read-only and non-idempotent, so the description adds meaningful behavioral context without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences: the first states the operation, effect, and return value; the second gives explicit exclusions and the alternative. No filler, and the key constraint is presented clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three params, one required, and schema fully documenting them, the description is complete. It states the output, the input restriction, and the alternative for a different use case. An agent has enough context to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters already documented in the input schema. The tool description doesn't add parameter-specific detail, but it doesn't need to because the schema carries that weight. Repeating parameter meaning would be redundant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Instantiate') and resource ('template assets') plus the outcome ('creating entity hierarchies from them') and return value. It also explicitly contrasts itself with create_entities, making its purpose unmistakable even among many sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when NOT to use the tool: for non-template assets, since only type="template" assets can be instantiated, and for building an entity from scratch, where create_entities is the alternative. This gives clear decision criteria for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds the meaningful behavioral detail 'Does not reload the editor,' which is not captured in the annotations and helps an agent predict side effects. It does not exhaustively describe what happens if the branch is already open, but that is a minor gap given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: the core action, the discovery method, and the key exclusion. The most important content is front-loaded. There is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with rich annotations, the description is fully sufficient. It tells the agent what the tool does, how to obtain the required identifier, which related tool is not appropriate, and the key side-effect characteristic. No output schema exists, but the description need not explain return values for this simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the branchId parameter already includes 'from list_branches with closed:true.' The main description repeats this same guidance rather than adding genuinely new parameter semantics. This meets the baseline for parameter clarity but does not go beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Re-open a previously closed branch.' It distinguishes itself from the related switch_branch tool by explicitly saying that switching the editor onto the branch is a different operation. The mention of list_branches({ closed: true }) further reinforces its exact role in the branch lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent how to find the closed branches to operate on via list_branches({ closed: true }). It also provides a clear 'When NOT to use' condition with the correct alternative tool, switch_branch. This is strong, unambiguous routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a non-read-only, idempotent, non-destructive operation. The description adds useful behavioral context beyond that: the meaning of each resolution value, the fact that it returns updated conflict records, and that 'revert' un-resolves rather than destroys. It could go further on failure behavior, but the core mutation semantics are clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences carry the full useful payload: what the tool does, how the resolution values behave, what is returned, the sequencing with sibling tools, and the primary when-not-to-use case. No filler or redundant restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description covers the essential context: it explains the input semantics, the return value, the correct place in the merge workflow, and the situation where a different tool should be used. An agent has enough information to invoke it correctly and integrate it with the surrounding merge lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already fully describes mergeId, resolution, and conflictIds. The description restates the enum semantics and workflow but adds little beyond the schema's parameter descriptions; for example, both already specify that conflictIds come from the merge's conflicts list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair: 'Resolve one or more merge conflicts by picking a side, or revert them to unresolved.' It clearly distinguishes this tool from siblings by naming get_merge, apply_merge, and get_conflict_file and explaining how they fit into the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit workflow guidance: repeat resolution until get_merge shows no unresolved conflicts, then call apply_merge. It also provides a direct exclusion: use get_conflict_file when you need to inspect a conflict's content first, not resolve_conflicts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description is not required to restate safety. It adds useful context beyond annotations: the required sequencing after set_script_text and the fact that it returns parsed metadata. No behavioral contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each earning its place: the first states purpose, the second gives sequencing, and the third provides an exclusion with alternatives. The description is front-loaded and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool with no output schema, the description is complete: it covers what the tool does, what it returns, when to run it, and when not to use it. An agent has enough context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, assetId, is already fully described in the schema with 100% coverage. The description does not add extra parameter-level detail, but it does not need to because the schema carries the full semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Parse') and resource ('script asset') and names the concrete outputs: declared script names and attribute definitions. It also distinguishes itself from entity-level script access tools, so an agent can tell it apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to run this tool after set_script_text and gives a direct 'When NOT to use' instruction with the alternative tools list_entities/modify_entities. This leaves no ambiguity about when the tool should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false, so the description carries a lighter burden. It adds meaningful behavioral context by guaranteeing the operation touches 'only' the diffuse color and will not modify other material properties — a scope guarantee beyond what annotations express. No contradiction exists between the write semantics ('Set') and readOnlyHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler. The action is front-loaded in the first sentence, followed by the color format, then the when-not-to-use guidance. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter write tool with no output schema and no nested objects, the description is complete: it covers the action, the value format, the scope limitation, and the routing to the alternative tool. Annotations cover the idempotence and safety profile. Nothing an agent needs to invoke this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description states 'Color is [r,g,b] in 0-1,' which largely duplicates the schema's 'RGB color [r,g,b] 0-1' for the color parameter, and adds nothing about assetId beyond the schema's 'Asset ID.' The description does not meaningfully exceed what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Set only the diffuse (base) color of a material.' The word 'only' precisely scopes the operation and differentiates it from set_material_properties, which is the key sibling for broader material changes. An agent can immediately know what this tool does and what it deliberately does not do.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a 'When NOT to use' clause: to change any other material property, or to set several properties at once, and names the alternative tool (set_material_properties). This is exactly the explicit when/when-not/alternative guidance the dimension rewards, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey idempotency and non-destructiveness. The description adds meaningful behavioral context: replacing the selection, showing items in the inspector, highlighting in the viewport/tree, and clearing the selection with an empty ids array. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the core action appears first, followed by the visible effects, parameter conventions, and exclusions. Every sentence earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with strong annotations and no output schema, the description is complete. It covers the action, effect, parameter semantics, clearing behavior, and the key sibling alternatives, giving an agent everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters well. The description reinforces the type-to-id mapping and empty-array clearing behavior, but it largely restates what the schema already provides rather than adding new semantic depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Replace the editor's selection with the given entities or assets.' It also clarifies the observable effect (showing in inspector, highlighting in viewport/tree) and distinguishes itself from related selection operations by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit and actionable: it states when not to use the tool, naming modify_entities for modifying selected items and focus_viewport for framing them. It also explains the type-specific id formats and the empty-array behavior for clearing selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no meaningful behavioral hints beyond non-read-only status, so the description carries the burden. It discloses important traits: the call waits for auto-merge to finish, returns a specific merge object, does not reload the editor, and reports conflicts for follow-up. It could go further by noting side effects on the current branch, but the disclosed behavior is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then efficiently packs in blocking behavior, return shape, conflict handling, an editor side-effect note, and an exclusion. Every sentence adds actionable value with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description specifies the returned merge fields and the conflict-resolution path. It covers when to start a merge, what happens while waiting, how to handle conflicts, and when to use get_merge instead. For a tool with only two documented parameters, this is fully sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents sourceBranchId and closeSource. The description adds no new parameter-level detail beyond what is already in the schema, matching the baseline for high coverage. It does reinforce that sourceBranchId is the branch to merge into the current branch.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's specific action: 'Start merging a source branch into the CURRENT branch' and clarifies that the destination is always the editor's current branch. It also distinguishes itself from related merge tools by mentioning the blocking wait and returned merge object, making its role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit workflow guidance: when conflicts exist, use resolve_conflicts then apply_merge. It also explicitly states when NOT to use the tool: 'to inspect an in-progress merge (use get_merge).' This provides clear routing among the sibling merge tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only and open-world behavior. The description adds useful context by stating that the tool reaches an external service over the network and that the returned details include license info needed for download, which helps set latency and failure expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded sentences: purpose first, then the network behavior, then the exclusion and alternative. Every sentence earns its place and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only getter, the description covers what the tool returns, the external nature of the service, and when not to use it. The lack of an output schema is mitigated by specifying that it returns full details including license info needed to download.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter, id, is already fully described in the schema as 'Store asset id (from store_search)'. The description merely says 'by id' and does not add meaningful parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific operation: retrieving full details for a single public store asset by ID, including license info needed for download. This distinguishes it from the related sibling tools like store_search and store_download, and from project-local get_asset/list_assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a when-not-to-use case: fetching a project-local asset, and names the alternative tool (list_assets). The external-service/network note also sets expectations about when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint, and the description adds meaningful behavioral context: it explicitly reaches an external service over the network and mentions pagination behavior via skip + limit. It does not discuss rate limits or result shape, but the annotation coverage reduces the burden and the added detail is useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences carry the purpose, workflow, pagination, external-service context, and an exclusion rule. There is no filler, and the most important purpose statement is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool, the description covers the resource, query mechanism, pagination, network/access expectations, and next steps for acting on results. Although there is no output schema, the mention of store_get for full details effectively indicates that search returns summary results. No critical information for selecting or invoking the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description confirms that 'search' is a keyword, and that skip and limit control pagination, adding slight value beyond the schema. However, it does not add meaningful detail about the 'order' parameter, and most parameter semantics already live in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search the public PlayCanvas asset store by keyword.' It also differentiates itself from siblings by mentioning the intended workflow with store_get and store_download and explicitly excluding project-asset searches via list_assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit and actionable: it tells the agent to use store_get for full details, then store_download to import, and includes a direct 'When NOT to use' clause pointing to list_assets for project-local assets. This leaves little ambiguity about when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations are minimal (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description adds useful behavioral context: duplication includes children, placement is under the same parent, and it returns new entity summaries. The rename=true auto-suffix detail also clarifies name collision handling, though it stops short of describing side effects, transaction behavior, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four short sentences with no filler. It front-loads the core action and placement, then mentions return value, the optional rename flag, and exclusions in a logical order. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description adequately covers what the tool does, what it returns, when to use it, and when not to use it. It could go deeper on edge cases like invalid entity IDs, partial duplication, or reference handling, but the combination of description, schema, and sibling context is sufficient for an agent to select and call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds extra meaning by explaining that rename=true causes auto-suffixing to avoid name conflicts and framing ids as 'existing entities,' which reinforces the schema's 'Entity resource_ids to duplicate'. This adds value beyond the raw schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Duplicate existing entities') and clarifies scope with 'including their children' and 'in place under the same parent'. It also explicitly distinguishes itself from create_entities and template asset creation, making its purpose unambiguous next to siblings like create_entities and duplicate_scene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit 'When NOT to use' section naming two distinct alternatives: creating a reusable prefab across scenes (template asset) and building a brand-new entity (create_entities). This gives clear decision criteria for selecting this tool over the nearby create_entities and instantiate_template_assets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true), the description discloses that modifications are undoable, times are normalized to 0–1, event ids remain stable, and generated ids are returned. These are non-obvious behavioral details that significantly help an agent anticipate side effects and return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences each add a distinct, non-redundant fact: the operation set, transactionality, and the normalization/id behavior. No wasted words and no restating of the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behavioral contract for a destructive tool: operations, undoability, normalization, and generated IDs. The schema documents the operation structures and constraints. Minor gaps remain around failure modes and the consequences of event.remove, but they are not critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only assetId is documented in the input schema; the operations array has no top-level description. The description compensates by explaining that operations are add/update/remove commands and by clarifying the time normalization. It does not elaborate on the properties sub-object, but the schema's anyOf structure already defines that thoroughly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb phrase, 'Add, update, or remove GLB animation events', naming the exact resource and the three operations supported. This clearly distinguishes it from the read-only sibling get_animation_events and from modify_anim_state_graph, which targets a different resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly frames this as the mutation tool for GLB animation events and adds useful context about batching via 'one undoable transaction'. It does not explicitly name alternatives or exclusion conditions, but the scope is evident enough that an agent can decide when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses important behaviors: the operation runs as one undoable transaction, add operations can omit ids, state deletion cascades to attached transitions, and parameter deletion is rejected while conditions reference it. These are meaningful edge-case behaviors that an agent could not infer from the schema alone and that materially affect invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is packed with useful information and no filler. Each sentence earns its place: transactionality, id allocation and return behavior, cascading deletion, and a specific layer default workflow. The core purpose is front-loaded before edge cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the absence of an output schema, the description covers the key return value (generated ids plus resulting graph) and several critical constraints. It does not enumerate all operation kinds or describe validation failure behavior, but those are largely captured in the detailed input schema and the high-level contract is sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents the operation kinds and their fields in detail, while the description adds semantic value by explaining that add operations may omit id to have one allocated and that generated ids plus the resulting graph are returned. It also clarifies the defaultStateId workflow. With only 50% schema description coverage, the description partially compensates for the gaps, though it does not fully explain every operation contract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: apply a validated batch of structural operations to an anim state graph as one undoable transaction. It specifies a concrete verb, resource, and scope, and goes beyond a simple restatement by mentioning returned generated ids and the resulting graph. This is easily distinguishable from read-only siblings like get_anim_state_graph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete guidance on when to use this tool: for validated batch mutations that should be undoable. It also provides a specific procedural tip about using layer.update defaultStateId before removing an old default state. It does not explicitly say when not to use it or name alternatives, but the usage context is still sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry destructiveHint=true, readOnlyHint=false, and idempotentHint=true, so the destructive safety profile is covered. The description adds value beyond that by disclosing the return behavior ('Returns the updated entity summary') and implicitly clarifying that removal physically deletes the component rather than merely toggling it, which is a meaningful behavioral distinction. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, zero filler: action first, then return value, then exclusionary routing. Every sentence earns its place, and the most decision-relevant information (what it removes and when not to use it) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-param, no-output-schema, idempotent-destructive tool, the description covers the action, parameter semantics, return value, and sibling routing. The only real gap is unstated behavior when a named component doesn't exist on the entity (error vs no-op), which an agent might want to know, but this is minor given idempotentHint=true and the overall simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: 'id' has a description but the 'components' property itself does not (only its items get 'Editor component type'). The description's 'by component name' fills this gap by clarifying that the array entries are component names, resolving the ambiguity of 'type' vs 'name' in the schema. It doesn't cover edge cases like nonexistent component names, but for a 2-param tool it compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Remove'), resource ('components from an entity'), and method ('by component name'), immediately distinguishing it from delete_entities and modify_entities. The return value is also disclosed ('Returns the updated entity summary'). This is exactly what an agent needs to tell this tool apart from its many siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit 'When NOT to use' section naming two alternatives (delete_entities for whole-entity deletion, modify_entities with components.<name>.enabled=false for disabling) with the precise conditions that select them. This is textbook routing guidance that leaves nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly=false, destructive=false, idempotent=true), the description explains the side-effect behavior: creates the script component when missing, adds the script, and returns an updated entity summary. It also usefully clarifies what this tool does not do, reducing ambiguity about its operational scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. The core behavior is front-loaded first, prerequisites second, and exclusions third. Every sentence adds distinct value, and the structure makes the tool easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description covers the return value (updated entity summary), prerequisite conditions, and explicit alternatives/exclusions. Combined with the provided annotations and schema, an agent has enough information to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds semantic context for scriptName by explaining the prerequisite that it must be a registered parsed script asset, not just any name. It also clarifies that attributes are initial values and execution order is controlled by index, though implicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Attach a script to an entity in one step') and precisely explains the behavior: it creates the script component if missing, then adds the named script. It also distinguishes this tool from set_script_text and modify_entities immediately, making its purpose clear relative to siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'When NOT to use' guidance, naming set_script_text for source code editing and modify_entities for setting attribute values. It also states the prerequisite that the script must already exist as a parsed asset, giving the agent concrete conditions for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by disclosing what is destroyed (the merge and its conflicts), what is preserved ('Project data is untouched'), and a notable side effect ('Does not reload the editor'). These details add real behavioral context beyond the readOnly/idempotent/destructive hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler. The core action and consequences come first, followed by the critical exclusion and alternative. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter schema and no output schema, the description covers everything needed: purpose, effect, side effects, and when to avoid the tool. It fully contextualizes cancellation among the merge-related siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is already well described as 'Id of the merge to cancel (from start_merge)'. The tool description adds no additional parameter-level meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('force-stop') and resource ('in-progress merge'), and clarifies the outcome: discarding the merge and its conflicts. It clearly distinguishes this from apply_merge by naming the sibling tool in the when-not-to-use note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The main sentence states the intended use: cancel an in-progress merge. It also explicitly tells the agent when NOT to use it ('to commit a merge') and names the correct alternative ('use apply_merge'). This is strong routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds useful behavioral context: it captures the live frame buffer, reflects actually running scripts/physics/animation, and produces a downscaled WebP image. It is transparent about the capture semantics without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: the core distinction is front-loaded, the prerequisite is clear, the behavioral detail is valuable, and the alternative routing is explicit. No filler or redundant repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool, the description covers what it captures, what format it returns, when it can be used, and which sibling to use instead. Nothing essential is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to explain. The description fully clarifies what the operation does, and the schema coverage is effectively complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the exact operation: screenshotting the running Launch instance, not the editor preview. It explicitly contrasts with capture_viewport, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the prerequisite (requires launch_start first) and gives a concrete when-not-to-use condition with a named alternative (use capture_viewport for edit-time visuals). This gives an agent clear decision rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits beyond the annotations: the operation is reversible, reopening is possible via open_branch, the current branch and permanent branches cannot be closed, and the editor is not reloaded. This adds meaningful context on side effects and constraints that annotations alone do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: what the tool does, its reversible nature, key restrictions, a side-effect note, and when not to use it. The description is compact and front-loaded with the most decision-relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers the operation's semantics, constraints, side effects, and alternatives. An agent has everything needed to decide when and how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents branchId as 'Id of the branch to close (from list_branches)'. The description does not need to add much, but it also does not go beyond the schema's parameter explanation. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Close a branch'), clearly defines it as a soft reversible archive, and differentiates it from delete_branch by stating what it is not for. It also gives constraints (cannot close current/permanent branch), making the tool's role unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly includes a 'When NOT to use' clause and names the alternative tool (delete_branch) for permanent removal. It also explains the intended recovery path via open_branch, giving an agent clear decision criteria for selecting this tool over branch-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses important behaviors: the snapshot is immutable, the tool does not reload the editor, snapshotting is asynchronous, and requests may time out while the checkpoint may still complete. It also describes the response shape and the safe verification strategy. No contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: purpose, return value, side-effect context, async/timeout behavior, and the key exclusion. It is front-loaded with the core purpose and remains tight despite covering several important operational caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool of this complexity, the description covers the essential operational facts: what is captured, the return shape in the absence of an output schema, the non-reloading behavior, the asynchronous/timeout risk, how to confirm completion, and the main alternative. The schema covers the parameter details, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents description and branchId. The description reinforces that the snapshot covers the current branch and includes scenes/assets/settings, but it does not add substantial new parameter-level meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action (create) and resource (checkpoint, an immutable snapshot of the current branch's scenes/assets/settings), and distinguishes it from the rollback sibling by explicitly pointing to restore_checkpoint. An agent can tell exactly what this tool does and how it differs from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context: create checkpoints to capture a recoverable state, and explicitly says when NOT to use it ('to roll back to a checkpoint, use restore_checkpoint'). It also provides guidance for the asynchronous case with a confirmation path: 'confirm with list_checkpoints'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond the destructiveHint=true annotation by explaining the concrete consequence: entities referencing deleted assets will lose those references. Also discloses the return shape ({ deleted: <count> }). No contradiction with annotations; idempotentHint=true is compatible with a delete operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, each contributing a distinct piece of information: action, consequence, return value, and when not to use. Front-loaded with the core purpose and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter destructive tool with no output schema, the description covers the essential call semantics: what it does, what side effects occur, what it returns, and the primary alternative. Combined with annotations and schema descriptions, nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, so the description does carry some responsibility for parameter meaning. It references ids generically ('by id') but does not explain rejectReferenced. However, the schema itself provides clear descriptions for both parameters ('Asset ID' and 'Fail before deletion if any asset is referenced'), so the gap is modest. A 3 reflects that the description adds little beyond the schema but does not mislead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Permanently delete assets by id'), and the destructive nature is explicit. Clearly distinguishes from sibling asset operations like modify_assets, move_assets, and duplicate_assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides a when-not-to-use scenario and names the alternative tool (modify_entities for removing references without deleting the asset). This leaves no ambiguity about tool selection in a key edge case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true, but the description adds meaningful detail beyond that: the operation is permanent and cannot be undone, it affects both the branch and its checkpoints, it refuses current/permanent branches, and it does not reload the editor. This fully informs the agent of behavior the annotations alone do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the critical DESTRUCTIVE label. Every sentence adds value: permanence, irreversible nature, constraints, editor behavior, and the explicit alternative for reversible use. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive tool, the description covers all essential context: what gets deleted, reversibility, constraints on what cannot be deleted, side effects on the editor, and when to use a sibling instead. The absence of an output schema is not a gap because the operation is a deletion with no meaningful return contract to document.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the only parameter with a clear description, 'Id of the branch to delete (from list_branches)', so schema coverage is 100%. The tool description does not need to add much, and it does not meaningfully elaborate on the parameter beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: permanently delete a branch and its checkpoints. It also differentiates from the sibling close_branch by explicitly naming the alternative for reversible archiving, so an agent can distinguish the tool immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly provides when-to-use context and, more importantly, a when-NOT-to-use directive: archive a branch reversibly with close_branch. It also lists exclusions such as current and permanent branches, which gives clear operational guardrails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds valuable behavioral detail by specifying the return shape, the possible type values, and the ID type distinction between entity and asset IDs. This goes beyond what annotations alone communicate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler: the action is first, return shape follows, and the exclusion with alternatives is stated crisply. Every sentence adds information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description is fully adequate. It explains the return shape, distinguishes entity vs asset IDs, and routes the agent away from listing tools. No critical information is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the parameter-semantics burden is minimal. The description adds relevant output semantics (return type and ID types) that help an agent understand what the tool will provide even without parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and resource ('the editor's current selection'), and clearly distinguishes itself from list_entities/list_assets by stating what it is not for. This makes it easy to differentiate from sibling tools like set_selection and clear_selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a 'When NOT to use' section with named alternatives (list_entities/list_assets). This gives clear routing guidance for an agent deciding between selection-reading and entity/asset listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond the destructiveHint annotation: irreversible erasure, editor reload, waiting for reconnect, and returning vcs_status. It does not contradict annotations; the idempotentHint and destructiveHint are consistent with a reset that can be repeated and has destructive 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: the destructive warning is front-loaded, key side effects are stated compactly, the return value is noted, and the alternative is given without extra prose. The description is dense but highly readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, editor-reloading operation with no output schema, the description covers the action, the irreversibility, the side effect on the editor, the return value, and the alternative tool. An agent has enough information to decide when to call this tool and what to expect afterward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both branchId and checkpointId. The description reinforces the meaning of checkpointId indirectly by explaining that later checkpoints are erased, but it does not add new parameter-level detail beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: reset the branch head back to a checkpoint, and clearly specifies the destructive consequence: permanently erasing every later checkpoint. It also distinguishes itself from restore_checkpoint, which is a sibling with a similar purpose but a different use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides a 'When NOT to use' condition and names the alternative restore_checkpoint for rolling back working state while keeping history. This gives an agent clear routing guidance beyond mere capability description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true), the description adds that the call closes the launch window and returns { stopped }. It does not contradict the annotations and provides useful lifecycle context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences carry all the needed information: purpose, effect, return value, and when not to use it. Every phrase earns its place, and the 'When NOT to use' guidance is clearly separated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with no output schema, the description fully covers the operation, its lifecycle role, return value, and the common misuse case. An agent selecting among the runtime siblings has enough to invoke and reason about launch_stop correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description cannot add much beyond the empty schema. Per the 0-parameter baseline, a 4 is appropriate; nothing is undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Stop'), a specific resource ('the running Launch instance started by launch_start'), and the concrete effect ('closes the launch window'). This clearly distinguishes the tool from launch_start and the rest of the runtime workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-not guidance is provided: 'there is no need to call this between captures — keep the instance running and re-capture.' This routes the agent away from stopping and toward re-capturing, which is an explicit alternative behavior. The paired use with launch_start is also clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral context: pagination via limit + cursor, the meta.nextCursor response mechanism, and the effect of the closed and favorite flags. It does not contradict the annotations and provides useful operational detail beyond what the annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. It front-loads the core purpose and return shape, then covers pagination, filtering, and the key exclusion, all in a compact and scannable form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list operation with no required parameters and 100% schema coverage, the description fully covers return values, pagination, filtering behavior, and the main alternative tool. No critical information is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented at a basic level. The description adds extra meaning by explaining the pagination relationship between limit and cursor, that cursor comes from a previous meta.nextCursor, and that favorite:true filters to the user's favourites, which goes beyond the schema's one-line descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('List the project's branches') and goes beyond the tool name by detailing the exact return record shape. It also distinguishes itself from sibling vcs_status by explicitly stating when not to use it, which makes the tool's purpose unambiguous among many similar branch/checkout tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when NOT to use the tool ('to read the current branch (use vcs_status)') and names the alternative. It also clarifies how to use filtering parameters for closed branches and favorites, giving an agent clear decision criteria without needing to inspect the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already provide readOnlyHint, so the description adds useful behavioral context by scoping results to the current project/branch and describing the returned record shape. It does not contradict the annotations and provides meaningful information beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three dense sentences with no filler. It front-loads the core purpose, then provides ID routing and an explicit exclusion, every sentence earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only list tool with no output schema, the description is complete: it specifies scope, return fields, relationships to sibling tools, and the primary alternative. An agent has everything needed to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so there is no parameter documentation burden. The description adds value by explaining the meaning of the returned fields and how they relate to other tools, compensating for the lack of an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List the scenes in the current project/branch.' It also names the returned fields (id, uniqueId, name) and explicitly distinguishes itself from list_assets, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives direct usage guidance: use uniqueId with load_scene and id with get_scene/duplicate_scene/delete_scene. It also explicitly says when NOT to use this tool—when listing assets—and names the correct alternative, list_assets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral semantics: only provided fields change, settings can be nested objects or dot-paths, and the tool returns the full resulting project settings snapshot. Even without meaningful annotation metadata, this gives an agent a clear model of the mutation's scope and return value, though it does not discuss failure cases or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then moves efficiently through the input format, return behavior, and explicit exclusions. Every sentence adds useful information and none of it repeats the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter mutation tool with no output schema, the description is complete: it covers scope, input format, partial-update behavior, return value, and routing to sibling tools. An agent has enough information to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the settings parameter as 'Partial project settings to change (path/value pairs); only provided fields are modified', so coverage is high. The description adds valuable detail beyond the schema by giving concrete examples of nested objects and dot-paths, such as { enableWebGpu: true, "layers.0.name": "World" }, which clarifies the expected format more precisely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Modify project-wide settings') and lists concrete setting domains (physics engine, rendering device, layers, input, resolution). It clearly differentiates this tool from modify_scene_settings and modify_entities by scope, so an agent can identify it without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool (project-wide settings changes) and when not to use it, naming concrete alternatives: modify_scene_settings for per-scene settings like fog or gravity, and modify_entities for a single entity. It also explains how to supply partial settings, which is the key invocation pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the mutation/safety profile is covered. The description adds valuable behavior beyond those annotations: 'Only the provided fields are changed' clarifies partial-update semantics, and 'Returns the full resulting scene settings snapshot' discloses the return behavior even though no output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words: purpose, partial-update behavior, return value, and exclusions with alternatives. The most important usage guidance is front-loaded, and each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with a deeply nested settings schema and no output schema, the description sufficiently covers what the agent needs: what it modifies, partial-update semantics, return value, and when to use sibling tools instead. The extensive input schema covers parameter detail, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter detail is well covered by the input schema. The description adds meaning beyond the schema by stating that only provided fields are changed, which clarifies that the settings object is a partial update rather than a full replacement. This is a meaningful semantic distinction for a nested settings object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Modify scene-wide settings' with concrete examples like physics gravity and rendering (fog, ambient light, skybox). It also explicitly distinguishes itself from modify_entities and query_scene_settings, so an agent can separate this from siblings without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use context ('Modify scene-wide settings') and explicit when-not-to-use guidance with named alternatives: use modify_entities for a single entity and query_scene_settings for reading without changes. This is strong routing signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces this with 'Read'. It adds useful behavioral context by stating that it 'Returns the full settings object' and listing the covered settings domains, which clarifies what an agent can expect beyond the annotation. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. It front-loads the core action and scope, briefly states the return content, and ends with a clearly marked negative usage instruction with alternatives. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description fully covers what the tool does, what it returns, and how it differs from related tools. The annotations cover the safety profile, and no output schema is needed because the return type is described as 'the full settings object'. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so parameter documentation is not needed. The schema description coverage is effectively 100%, and the description clarifies the return value rather than parameters, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Read') and a specific resource ('current project-wide settings'), then enumerates the settings categories included. It also distinguishes itself from the obvious sibling 'modify_project_settings' and 'query_scene_settings' by naming them in the usage note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when not to use the tool and names the exact alternatives: use modify_project_settings for changes and query_scene_settings for per-scene settings. This is direct, actionable routing guidance that leaves little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the read-only safety profile is covered. The description adds useful behavior: it returns the full settings object and specifies that the scope is scene-wide physics and rendering. No side effects are described, but for a zero-parameter read operation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: what the tool does, what it returns, and when not to use it. The key scoping information is front-loaded and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read-only tool with a clear sibling for mutations, the description fully covers what is read, what is returned, and when to avoid it. Nothing needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to add beyond what the input schema already shows. The description's scene-scope clarification adds context, but no parameter-specific semantics are needed. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads current scene-wide settings, specifically physics and rendering, and returns the full settings object. This distinguishes it from query_settings and query_project_settings by its scene scope, and from modify_scene_settings by the read vs. change intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when NOT to use the tool (to change settings) and names the alternative tool (modify_scene_settings). It also implies the correct use case: reading current scene settings. This is direct and leaves no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the return behavior (whether something was redone plus the canUndo/canRedo state) and clarifies the non-idempotent nature by saying it re-applies a previously undone edit. Annotations provide no detailed behavioral hints beyond booleans, so the description adds meaningful context without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences with no filler. The primary action is front-loaded, followed by return value information and a clear exclusion. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description fully covers what it does, what it returns, and when not to use it. No output schema exists, so the explicit return-state description is especially valuable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter semantics are trivially complete. The description correctly focuses on behavior rather than inputs, and schema coverage is effectively 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (redo) on a specific resource (the last undone edit in the editor). It clearly distinguishes itself from the sibling 'undo' tool and clarifies its narrow scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-not-to-use guidance: it should not be used to repeat an arbitrary action, only to re-apply an edit that was just undone. This gives an agent clear selection criteria relative to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the description discloses key behavioral traits: history is preserved, the editor reloads, the tool waits for reconnection, and it returns vcs_status. These details meaningfully inform the agent about side effects and execution behavior beyond what annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, with no filler. It front-loads the core purpose, then adds crucial behavioral side-effects and an explicit exclusion, each sentence earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool without an output schema, the description covers the return value (vcs_status), the reload side-effect, the history-preservation semantics, and the routing to the hard reset sibling. This is sufficiently complete for an agent to invoke and understand the tool's behavior correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters with 100% coverage, including the source of checkpointId and the default behavior of branchId. The description does not add additional parameter-specific detail, so the baseline of 3 for high schema coverage is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Restore (soft revert) the current branch's working state to a checkpoint') and immediately distinguishes itself from the hard-reset sibling, so the agent knows exactly what this tool does and how it differs from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when NOT to use the tool and names the correct alternative: 'to permanently erase later checkpoints (use hard_reset_checkpoint).' This gives the agent a clear decision rule for choosing between restore_checkpoint and hard_reset_checkpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds genuinely useful behavioral context beyond those flags: partial-update semantics ('Only the provided fields are changed; all fields are optional') and the return behavior ('Returns the updated asset summary'). This is consistent with idempotentHint and clarifies the non-destructive update model. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five short sentences, each earning its place: purpose, patch semantics, value formats, return value, and exclusion routing. Front-loaded with the operation, zero fluff, and no repetition of what the schema already states.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a ~200-property nested schema and no output schema, the description covers everything an agent needs to invoke it correctly: what it does, partial-update semantics, value/format conventions, the return value, and when to use alternatives. The massive schema carries per-property detail while the description carries the behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both top-level parameters and most nested properties with descriptions like 'RGB color [r,g,b] 0-1' and 'Nullable asset reference'. The description adds cross-cutting conventions that apply across the whole properties object: color format, map fields taking asset ids, and patch behavior. This exceeds the baseline 3 by clarifying semantics no single schema entry can express.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource+scope: 'Set any combination of properties on a material asset in one call.' It enumerates representative property families (diffuse, emissive, metalness, gloss/shininess, opacity, maps) and explicitly distinguishes itself from set_material_diffuse and create_assets. An agent can tell exactly what this tool does versus its siblings without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit 'When NOT to use' section naming two alternatives with concrete conditions: set_material_diffuse for single diffuse color changes and create_assets type='material' for material creation. This is exactly the routing guidance that prevents wrong tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as non-destructive and idempotent, and the description avoids contradiction. It adds useful behavioral detail: only supplied fields are modified and the tool returns the resulting mode/space, which tells the agent the observable effect and response shape without an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler: the core action and accepted values come first, the partial-update contract and return value are second, and the exclusion/alternative is last. Every sentence carries information needed to call the tool safely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, fully-optional-parameter setter with rich schema descriptions, the description covers the action, the exact settings, the partial-update behavior, the return value, and the key alternative. Nothing essential is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the three parameters are already described with enums and types. The description adds value by restating the semantic groups (mode, coordinate space, snapping) and, more importantly, by stating the partial-update behavior that governs how the optional parameters should be passed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Set the viewport transform gizmo', naming a specific verb and resource, then enumerates exactly what can be controlled: mode, coordinate space, and snapping. It also distinguishes itself from the nearby transform-modification tools by warning that it does not actually move/rotate/scale entities, which is the key sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when not to use the tool ('to actually move/rotate/scale an entity') and names the alternative ('use modify_entities on its transform'). It also clarifies that only provided fields change, so callers know they can issue partial updates without respecifying all settings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value beyond annotations by disclosing the return shape and the behavioral nuance that the listed mutation operations 'reload the editor,' implying the agent should re-query state afterward. It does not contradict the read-only annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, zero filler. The core purpose and return payload are front-loaded in sentence one, usage triggers in sentence two, and exclusions in sentence three. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only status check with no output schema, the description is complete: it fully specifies what is returned, when to invoke it (including triggering operations), and which sibling tools to use instead for related but different queries. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so the baseline of 4 applies—there is no parameter documentation burden. The description instead documents the return payload, which is the meaningful input/output contract for a parameterless status tool; no parameter semantics are missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Read the current version-control state') and enumerates the exact return payload: the active branch ({ id, name, latestCheckpointId }), projectId, and merge-in-progress flag. This distinguishes it sharply from siblings like list_branches (lists all branches) and list_checkpoints (lists checkpoints).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use guidance is provided: 'Use this to confirm which branch you are on, especially after create_branch/switch_branch/restore_checkpoint/hard_reset_checkpoint (which reload the editor).' It also gives explicit when-not-to-use instructions with named alternatives ('to list branches (use list_branches) or checkpoints (use list_checkpoints)').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important non-obvious behavior beyond the annotations: finalize:true writes the merge checkpoint, reloads the editor, waits for reconnect, and returns vcs_status, while finalize:false does not reload. This is meaningful contextual information that the annotations alone do not provide, and it does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well structured: one summary sentence, the two-call protocol, the side-effect/reload warning, and the explicit when-not-to-use alternative. Every sentence earns its place and the most important constraints are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the required call sequence, the side effects of finalize:true, and the abort alternative. It is slightly incomplete in that it does not describe the return behavior or resulting state of the finalize:false pass, but given the small parameter surface and the rich two-phase guidance, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100% for both parameters, so the description does not need to restate them. It adds value by clarifying the behavioral difference between finalize:false and finalize:true and by referencing where mergeId originates ('from start_merge'). Minor extra detail about mergeId format would be nice, but the existing schema plus description is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('apply'), a clear resource ('a merge'), and a precondition ('whose conflicts are all resolved'). It also separates this tool from the broader merge workflow by naming cancel_merge as the abort alternative, so an agent can identify what apply_merge does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is made explicit: 'Call twice: first with finalize:false to prepare and review, then finalize:true to commit.' It also provides a direct exclusion with an alternative tool: 'When NOT to use: to abort a merge (use cancel_merge).' This gives clear, actionable guidance with no inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag it as a destructive, non-read-only, idempotent write; the description builds on this with write-time validation behavior — unknown paths or missing components fail immediately with an error listing the entity's valid paths, enabling one-shot self-correction — plus the return shape (post-edit entity summaries) and per-edit targeting semantics. No contradiction with annotations; the idempotentHint is consistent with set/unset semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but front-loaded: the operative verb+resource lands in the first clause, followed by path grammar, then failure behavior, then exclusions. Every sentence carries semantic weight, though some phrasing ('so you can fix it in one shot instead of retrying blind') is mildly editorial and the example list could be trimmed without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive write tool with one complex parameter, a low-coverage schema, and no output schema, the description covers virtually everything: valid values, grammar, units, prerequisites, failure mode, return shape, and sibling routing. The one remaining gap is batch semantics — if an edits array contains several entries and a later edit fails, it is not stated whether earlier edits already committed or the whole batch rolled back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is minimal, and the description compensates fully: it enumerates valid top-level paths with units and coordinate space ([x,y,z] local for position, euler degrees for rotation), gives the component-path grammar with four concrete examples, states the has-component prerequisite, and clarifies that each edit targets exactly one entity id + one path. This goes well beyond the schema's terse 'Property path in dot notation.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource pair — 'Set or unset properties on existing entities by dot-notation path' — and then enumerates the exact valid path space (top-level: name, enabled, position, rotation, scale, tags; component: components.<type>.<prop>). The scope is crisp: this tool mutates properties on entities that already exist, which visibly separates it from create_entities, add_components/remove_components, and modify_scene_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit 'When NOT to use' section naming three alternatives with the exact condition that routes to each: create_entities for creation, add_components/remove_components for component lifecycle, and modify_scene_settings for scene-wide changes. It also gives positive routing guidance ('add it with add_components first') for the component-prerequisite case. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds critical behavioral context: it renders the editor preview only, with scripts/physics/animation NOT running. This clarifies the interpretation of the screenshot and prevents the agent from expecting runtime state. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each earning its place: definition, tip, key rendering note, and when-not-to-use. The most important scoping constraint (editor preview, no runtime) is prominent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only tool with an output format and clear constraints, the description covers what it returns (WebP screenshot), when to use it, prerequisites (focus_viewport), limitations (no scripts/physics/animation), and the alternative (capture_runtime). Nothing needed from an output schema because the tool's output is self-describing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage, so there is nothing to document. Per the zero-parameter baseline this is a 4; the description appropriately focuses on behavior rather than params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the verb 'Capture', the resource 'editor viewport', the output format 'downscaled WebP image', and the purpose 'visual verification of edit-time state'. Explicitly distinguishes from capture_runtime by naming the runtime behavior alternative, so an agent can differentiate it from the sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a direct when-not-to-use with the alternative tool: 'use capture_runtime after launch_start'. Also gives a tip to call focus_viewport first to frame entities, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses significant non-obvious behavior beyond the annotations: the editor reloads, the tool waits for reconnect, and it returns the resulting vcs_status on the new branch. It also states the uniqueness constraint and maximum name length. Nothing in the description contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: action and purpose, default source behavior, important reload/return behavior, naming constraints, and the explicit alternative. The description is compact, front-loaded, and free of redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creating-and-switching tool with no output schema, the description covers the essential behavioral context: creation, switching, reload, return value, name constraints, and the sibling alternative. The remaining parameter details are fully covered by the input schema, so nothing necessary for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds extra meaning by specifying the uniqueness requirement for 'name' and explicitly calling out the default source branch, which complements the schema's 'defaults to the current branch' note. It does not repeat all parameter details, but the schema already documents them well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific operation ('Create a new branch'), its purpose ('scope a feature on its own branch'), and the immediate side effect ('switch the editor to it'). It also distinguishes itself from switch_branch by explicitly naming the alternative in the NOT-to-use note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use the tool ('create a new branch') and, more importantly, when not to use it ('to switch to an existing branch, use switch_branch'). It also clarifies default branching behavior and uniqueness requirements, which gives an agent enough context to decide between create_branch and switch_branch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint, idempotentHint), the description adds crucial behavioral details: deletion is permanent and not undoable, includes all descendants, excludes the scene root, and returns { deleted: <count> }. This meaningfully exceeds what annotations provide and gives an agent a clear mental model of 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the primary action comes first, followed by important warnings, return value, and usage alternatives. Every sentence contributes meaningful information with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter), and the description covers the essential aspects: destructive permanence, descendant deletion, the scene root limitation, return value, and when not to use it. The annotations cover idempotency and destructiveness, so no critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only one parameter and 0% schema description coverage, the description helps by clarifying that the ids refer to entities to be deleted along with their descendants, and that the scene root cannot be deleted. While the schema indicates UUID format, the description adds semantic constraints not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action and scope: 'Permanently delete entities and all of their descendants.' It also distinguishes itself from related tools by explicitly naming alternatives like modify_entities and remove_components, making it easy for an agent to identify when this tool is the right choice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'When NOT to use' guidance with specific alternatives: hiding an entity should use modify_entities, and removing a single component should use remove_components. It also conveys the destructive, permanent nature and the special restriction that the scene root cannot be deleted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and the description adds meaningful behavioral detail: pagination semantics (limit/offset, nextCursor, meta fields), default compact vs full payloads, and the fact that an empty result is a success, not an error. This is exactly the kind of nuance an agent needs and cannot get from schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then layers pagination, filtering, the full flag, empty-list behavior, and the sibling alternative without wasted words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema, the description covers the return contract (compact fields, meta fields), pagination mechanics, filter semantics, performance consideration for full=true, and error semantics for empty results. An agent has enough to call it correctly without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds value beyond the schema by explaining how parameters work together (default limit of 50, offset used with nextCursor, filters combinable by type/name/tag) and when full is worth the size cost.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('List project assets') and immediately defines the default return shape (compact summaries with id, name, type, folder, tags). It also distinguishes itself from the public asset search by explicitly pointing to store_search, which makes it easy to tell apart from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'When NOT to use: to search the public asset store (use store_search)' is an explicit routing rule to the correct sibling. It also states when full=true is appropriate, giving the agent actionable selection criteria beyond the raw schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses that the current scene is unloaded and that loading is asynchronous by default, returning only after the scene is active with wait=true. These are meaningful side effects and timing behaviors an agent needs to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short, front-loaded sentences with no filler. Every sentence contributes either core semantics, timing behavior, or routing guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with annotations covering idempotence and destructiveness, the description covers operation, side effects, default behavior, the wait option, and alternatives. No critical calling information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents both parameters, so the baseline is 3. The description adds value by explaining the wait parameter's behavioral effect (queued load vs waiting until active), though it adds little beyond schema for uniqueId.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Load (switch the editor to) a scene by its uniqueId') and explains the switching semantics ('unloads the current scene and opens the target one'), making it clearly distinct from read-only operations like get_scene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when not to use the tool and names the alternatives (get_scene for reading, create_scene for creating), and explains the wait=true option versus the default queued-return behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, and the description reinforces this with 'Read' and clarifies important behavioral details: it requires launch_start first, empty results indicate success rather than error, the runtime shares the same GUIDs as edit-time, and it returns specific fields including rigidbody and element data when present. This is substantial beyond what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but intentionally so, given the tool's complexity and the absence of an output schema. It is front-loaded with the core purpose, then covers return fields, filtering, pagination, use-case examples, and exclusions in a logical order with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a runtime inspection tool with no output schema, the description is comprehensive: it explains prerequisites, return contents, filtering semantics, pagination metadata, success semantics, and alternatives. An agent has everything needed to decide when to call it and what to expect in response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter already has a clear description in the schema. The tool description adds useful context beyond the schema, such as omitting both filters to page through every entity, the runtime using the same GUIDs, and the meaning of offset via nextCursor, though most parameter semantics are already well documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read'), a precise resource ('LIVE runtime state of entities in the RUNNING Launch instance'), and distinguishes this from edit-time scene data by calling it the 'non-visual ground-truth read-back'. It also explicitly contrasts with sibling tools like list_entities and query_viewport_state, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear when-to-use guidance with concrete example questions ('did the ball actually move?', 'is the rigidbody simulating?'), and an explicit 'When NOT to use' section naming list_entities, pre-launch usage, and modify_entities/inject_input. It also states the prerequisite launch_start and explains when to use ids vs name vs neither.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses essential runtime behavior: newest entries first, pagination metadata, default level behavior, filter semantics, and that an empty result means success rather than failure. This is rich, actionable context that goes well beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, prerequisite, ordering, pagination, defaults, filtering, empty-result semantics, and an explicit exclusion. It is front-loaded with the tool's core value and immediately clarifies boundaries with the sibling editor-log tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only logging tool with no output schema, the description covers the essential operational context: when it applies, what it returns, how results are ordered and paginated, how to widen/narrow results, and when not to use it. Nothing critical is left to guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds useful meaning: it clarifies that the default level means 'warnings + errors', explains how level='all' widens the search, and describes pagination fields (total/count/hasMore/nextCursor) that help an agent interpret results. This is meaningful added value beyond the raw parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Read') applied to a specific resource ('console output... from the RUNNING Launch instance'), and explicitly labels it as 'the first-line signal for runtime bugs.' It also distinguishes itself from sibling read_editor_logs by noting this is the launched app only, preventing confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the prerequisite ('Requires launch_start first') and provides a direct 'When NOT to use' clause pointing to edit-time editor logs, which is the key alternative. It also clarifies default behavior, filtering options, and empty-result semantics, giving an agent clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses matching semantics ('case-insensitive substrings', 'exact=true'), the return shape ('summaries (resource_id, name, path, components)'), and error behavior ('empty result is successful, empty list (not an error)'. This is rich behavioral context that an agent needs for correct invocation and interpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each with a distinct purpose: purpose/value, matching default, return shape, and anti-guidance. It's front-loaded and every sentence earns its place. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only tool with no output schema, the description covers purpose, parameters, return format, error semantics, and routing to an alternative. Nothing critical for an agent to invoke this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters at 100% description coverage. The description addds meaningful behavior: it explains the default case-insensitive substring matching and explicitly connects exact=true to full-name matching. While somewhat redundant with the schema, it adds the default-behavior context that the schema only implies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a precise verb and resource: 'Resolve entities by name into their resource_ids and hierarchy paths'. It clearly states what is produced and why, and the final sentence explicitly differentiates from list_entities. The agent can confidently tell this tool apart from siblings without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete use case ('drive follow-up calls without shuttling UUIDs') and an explicit 'When NOT to use' with the correct alternative (list_entities). It also explains when to set the exact parameter. Both positive and negative guidance are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already marks this as safe, and the description adds valuable behavioral detail: pagination via limit + cursor with meta.nextCursor, backend defaults (limit 25, max 50), and the exact record shape. These details go beyond the annotation and tell the agent what to expect from the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but compact: purpose, ordering, return shape, pagination, default limits, and a routing directive all fit in four short sentences. Every sentence earns its place and no content is redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list operation with zero required parameters and full schema coverage, the description covers everything needed: what is returned, how pagination works, what defaults apply, and how to distinguish it from list_branches. There is no output schema, but the description supplies the essential return contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description goes further by explaining the effective default limit (25), the max boundary (50), the pagination contract via meta.nextCursor, and that branchId defaults to the current branch. This adds practical meaning beyond the raw parameter names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List checkpoints'), a clear resource ('on a branch'), and a precise scope (current branch by default) with ordering ('newest first'). It also names its closest alternative, list_branches, and the distinct use case, eliminating any ambiguity between siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the checkpoint id with restore_checkpoint or hard_reset_checkpoint, linking this read tool to the related mutation tools. It also gives a clear 'When NOT to use' directive: to list branches, use list_branches, which is direct guidance an agent can act on.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![editor-mcp-server MCP server](https://glama.ai/mcp/servers/playcanvas/editor-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/playcanvas/editor-mcp-server)

Score Badge

Copy to your README.md:

[![editor-mcp-server MCP server](https://glama.ai/mcp/servers/playcanvas/editor-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/playcanvas/editor-mcp-server)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/playcanvas/editor-mcp-server'

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