PlayCanvas Editor MCP Server

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.