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

With no annotations, the description carries the full burden and does disclose meaningful behavior: Preview creates separate material/asset variants and real before/after renders; Apply preserves geometry/textures and refuses changed assignments; unsupported-field warnings are surfaced. It omits auth/permission requirements and reversibility guarantees, but the behavioral disclosure is unusually rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose, then layers mode-specific behavior in short clauses. Dense semicolon-heavy phrasing and a slightly scattered ordering cost it, but every sentence carries information and nothing is padding.

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 6-param, zero-annotation, no-output-schema tool, the description covers behavior well but not the full contract. Missing explanations for plan_id and paths, and no indication of mode values or what a plan/selected-row lifecycle looks like, leave an agent guessing on 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 0%, so the description must compensate. It maps some params meaningfully ('fields: color, roughness, texture_scale' to fields, 'reference can be a native material or model' to reference, 'selected row IDs' to selected, 'mode' implied by Preview/Apply), but leaves paths and plan_id completely unexplained — a real gap for a 6-param tool.

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 specific verbs (preview, apply/undo) against specific resources (material slots on Unity prefabs or UE static meshes), and clarifies the reference input can be a native material or model. An agent can tell this apart from siblings like create_variants or match_game_style 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 distinguishes its two modes clearly, saying what Preview does vs what Apply does, and adds a caution ('do not claim visual equality across different shaders'). It does not name sibling alternatives or prerequisites for choosing this over create_variants/set_scene_look, so it stops short of explicit 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?

With no annotations, the description carries full behavioral burden. It usefully discloses that reduction may fail when its deviation limit cannot be met and that existing imported geometry stays usable, which covers failure mode and preservation. However, it omits whether the operation is destructive to the retained source, what permissions are required, or whether the change is reversible.

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 concise sentences, front-loads the core action, and each sentence adds relevant information about purpose, preset use, and failure behavior. There is little wasted wording, though the second sentence is slightly redundant with the first.

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-annotation, no-output-schema tool with low parameter coverage, the description covers purpose and failure behavior but leaves gaps in usage guidance and asset_id semantics. It is minimally adequate but an agent would still need to guess about routing and parameter meaning.

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 must compensate. It clarifies the preset parameter by naming three preset values and describing what the preset controls (triangle budget, texture resolution, LOD ratios). It says nothing about asset_id, leaving one of two parameters 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 states a specific verb ('Prepare') and resource ('retained source') and names the target preset categories (mobile_prop, scene_prop, hero_prop) with LOD preparation. It is clear enough to distinguish from generic asset tools, but it does not explicitly contrast with the sibling prepare_asset tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no when-to-use or when-not-to-use guidance, and does not name alternatives or prerequisites. An agent must infer that this tool applies only to retained sources with existing imported geometry, but the routing against siblings like prepare_asset is left ambiguous.

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?

With no annotations at all, the description carries the full burden and does well: it discloses collision checks and undo support, the 32-instance cap, the mutation semantic that 'Existing instances move, extra ones are duplicated,' that fit can shrink under-anchor props, and the two queued states (inspection vs. arrangement) with recovery instructions. It omits permission/auth requirements and any timing or rate considerations for a placement 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?

The core purpose is front-loaded in the first sentence, followed by compact, high-density clauses covering item shape, relations, mutation semantics, and error recovery. No sentence is filler, and the terse fragment style suits an agent audience.

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 an 8-parameter mutation tool with no annotations, no output schema, and 0% schema coverage, the description covers the important behavioral and error-recovery surface but leaves several parameters (gap, anchor_id, face_anchor, snap_to_surface) and the return/result shape unexplained. It is useful but not fully self-sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it partially does: it documents the items shape ({asset_id, count=1, object_id?}), the 32 cap, the valid relation values (around, along, under, right, front), and the fit shrink behavior. It says nothing about gap units/meaning, anchor_id selection, face_anchor, or snap_to_surface, leaving four of eight parameters undocumented anywhere.

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 concrete verb+resource+scope: 'Place managed props relative to a selected real scene anchor,' which is far more specific than a tautology and clearly separates it from build/create/import sibling tools. It never explicitly names a sibling such as compose_scene or edit_selected_prop, so differentiation is inferred from the anchor-relative placement framing rather than stated.

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 operational routing for queued/failed calls ('retry with inspection_request_id', 'poll its exact request with get_task_status; do not submit the layout again'), which is useful when-to guidance for the error path. However, it never says when to pick this tool over the many adjacent scene-editing siblings (compose_scene, edit_selected_prop, create_prop_set), leaving the primary selection decision 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?

With no annotations, the description carries the full burden and does well: each script builds from scratch, default scene objects must be deleted, an Export collection must be created, meshes linked, supported PBR/emission/alpha graphs bake automatically, and unsupported materials fail explicitly. It omits failure semantics beyond that (what a partial build leaves behind) and permission/robustness details, keeping it below a 5.

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 primary action is front-loaded in the first sentence and the remaining notes are dense, non-repetitive constraints. It is a bit aggregated into two long blocks rather than cleanly separated rules, which costs one point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-annotation, no-output-schema, 4-parameter mutation-ish tool this is reasonably complete: it covers the build contract, material support envelope, and the asset_id/position semantics. Gaps remain around the collider parameter and what the agent gets back after the queued engine import.

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 must compensate. It does add real meaning for asset_id (lowercase letters/digits/_/-) and position (engine XYZ meters, applied only on first placement), but says nothing about collider or the expected content/constraints of blender_python. Two of four parameters remain 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 opening sentence states a specific verb chain and resource: execute bpy code in background Blender, then save a .blend and queue an engine import. That is far more informative than a restated name. It does not, however, explicitly differentiate itself from nearby siblings like design_asset, create_prop, or create_interactive_prop, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives one useful usage rule: reuse a stable asset_id to update the same asset, and position only applies on first placement. That is implied guidance rather than explicit when-to-use/when-not-to-use routing against the many alternate asset-creation siblings, so an agent still has to guess whether build_asset or design_asset/create_prop is the right entry point.

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?

With no annotations, the description carries the full behavioral burden and does so fairly well: it discloses the 24-module cap, that invalid plans fail before editor mutation, and that checking uses sampled standing capsules rather than a NavMesh or full controller simulation. It omits what remove mode destroys, permission/auth needs, and return behavior, but the failure semantics and validation limits are genuinely informative.

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?

Purpose is front-loaded and the dense settings block follows in a single compact stanza with no filler sentences. The prose block is somewhat run-on and merges schema-like detail with behavioral caveats, but every sentence carries 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 no-annotation, no-output-schema tool with a free-form settings object, the description covers construction constraints, failure conditions, and check fidelity. What is missing is the mode semantics (valid values and effect of remove) and any indication of what the call returns; otherwise it is sufficient to call 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 0% across 3 parameters, so the description must compensate. It documents the settings object in rich detail (modules structure, cell/kind/direction enums, cell_size, story_height, door dimensions, capsule metrics, max_step, position, yaw), but says nothing about level_id and only implies the mode values through the leading verb list.

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 opening clause names a specific verb set (plan/build/check/remove) and a well-defined resource (connected modular level with collision clearance), which maps directly onto the modes it supports. No sibling tool does level building, so an agent can distinguish this from edit_scene, compose_scene, or arrange_props without opening any 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?

Usage is implied by the mode verbs and constraints (max 24 modules, stairs need two landings, disconnected plans fail), but the description never explicitly says when to choose this over siblings like edit_scene or compose_scene, nor when-not to use it. It gives enough context to operate but leaves routing 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?

With no annotations, the description carries the full burden, and it does disclose one genuinely useful trait: cancellation is best-effort and an in-progress native import may complete anyway. It omits permissions, whether partial output is retained, and whether cancellation is reversible, so disclosure is partial.

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, front-loaded with the action and then the important caveat. No filler, though the telegraphic style leaves obvious questions unanswered.

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-ish lifecycle tool with no annotations, no output schema, and an undocumented required parameter, the description is thin. It conveys the best-effort nature of cancellation but not the identifier semantics or what an agent should do after calling it beyond "check status".

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 is one required parameter, request_id, with 0% schema description coverage, and the description never mentions it or its expected format (task id vs. import id). It therefore does not compensate for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"Request cancellation" names the action but not the resource being cancelled (task vs. import vs. workflow), and the phrasing largely restates the tool name. The second sentence hints the target is an import job, but an agent cannot distinguish this cleanly from siblings like get_task_status or resume_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?

No explicit statement of when to use this versus get_task_status or other lifecycle tools. "check status" implies a follow-up call but does not say under what conditions to cancel or what the preconditions are.

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?

No annotations exist, so the description carries the full burden, and it does disclose real behavior beyond the schema: identical camera framing is enforced, the review_id/view must be reused, the capture requires waiting for completion, and lighting differs by source (engine project lighting vs Blender studio rig). It omits permissions, failure modes, and whether tasks can be canceled or are idempotent.

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?

Front-loads the core purpose in one sentence, then a compact workflow line and a routing/lighting note. Three short paragraphs with essentially no filler, though the final lighting sentence sits apart from the invocation guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter, no-annotation, no-output-schema tool, the description covers the workflow and points to get_review/get_preview for results, but leaves asset_id semantics and stage parameter detail undocumented. Adequate to call the tool, incomplete for edge cases.

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 must compensate. It meaningfully explains view (studio rig for Blender source previews) and the review_id reuse rule, and implies stage via before/after wording, but asset_id is never addressed and stage values are only inferable from the workflow text.

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 ('Capture a native before/after comparison') with the distinguishing scope of identical saved camera framing. An agent can tell this apart from get_review, get_preview, and capture-adjacent siblings like inspect_target without opening a 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?

Gives the actual workflow sequence ('capture before, wait for completion, modify asset, then capture after with the same review_id and view'), which is strong when-to-use guidance, and routes to siblings ('get_review lists capture tasks; get_preview(request_id) returns images'). It stops short of stating exclusions or when this is not 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?

No annotations are provided, so the description carries the full behavioral burden. It hints at side effects ('automatic textures', 'engine import') but says nothing about reversibility, permission requirements, what happens to unselected variants, or rate/limit behavior for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler, and the core action is stated first. It is efficient, though its brevity contributes to the missing detail elsewhere.

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 annotations, no output schema, and zero parameter documentation, the description is inadequate. It gives a useful behavioral hint about automatic textures and engine import but leaves parameter meanings and safety profile entirely uncovered.

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 4 parameters at 0% schema description coverage, and the description mentions none of them (study_id, index, quality, position). Worse, 'at final quality' could mislead the agent into thinking quality is fixed when it is actually an optional parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a verb (Publish) and a resource (selected draft at final quality), which is more than a tautology. However, the name 'choose_variant' implies selecting among variants while the description talks about publishing a draft, and nothing distinguishes it from siblings like publish_blend or publish_prepared.

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 when-to-use guidance, no preconditions, and no mention of the alternative tools (get_variants, create_variants, publish_blend, publish_prepared) the agent should consider. The agent must infer usage from the name alone.

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

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

With no annotations, the description carries the full burden and does so substantively: it discloses that the operation is asynchronous ('Poll the returned workflow ID'), resumable ('Interrupted workflows resume without repeating completed stages'), and reversible ('Result has undo_id'), plus a kinematic limitation (arbitrary horizontal yaw yes, tilted anchors no). It omits auth/permission requirements and what gets destroyed or overwritten on save/place, keeping it short of a 5.

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 definition is front-loaded with the core purpose, then terse per-mode and per-constraint lines — dense but each sentence carries information. Domain jargon ('kit', 'upright anchors') is used without definition, so minor clarity is traded for brevity.

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 an 8-parameter, no-annotation, no-output-schema mutation tool this is fairly complete: modes, coordinate convention, async/polling behavior, resume semantics, and the undo_id return are all covered. Gaps remain on 'prefix', on what the workflow result otherwise contains, and on failure conditions, so it is not exhaustive.

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 must compensate, and it does for most parameters: position ('explicit position is metres in engine axes'), yaw (arbitrary horizontal yaw supported, tilted not), mode (save vs place semantics spelled out), template and asset_ids (referenced in the mode=save/place sentences), and anchor_id ('selected upright anchors supply position/yaw'). The 'prefix' parameter is never explained, which prevents a 5.

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 first sentence gives a specific verb chain ('Build and furnish a small scene, or save/place a reusable layout') and names the resource and scope. It spells out the three internal modes (create/save/place), so an agent understands the tool's remit. It does not, however, distinguish itself from scene siblings like arrange_props or edit_scene, which is the one missing element for 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?

Mode selection is clarified well: 'create builds a matching kit', 'mode=save records selected instances', 'mode=place duplicates saved instances' — that is real within-tool guidance. But there is no explicit when-to-use-this-vs-alternative guidance against the many sibling scene tools (arrange_props, edit_scene, create_prop_set), so the agent must infer the boundary.

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?

No annotations are provided, so the description carries the full behavioral burden. It does add one genuinely useful fact beyond structure — credentials are stored in the OS store, not returned or persisted inline — but omits whether an existing endpoint is overwritten, whether null values clear or preserve current settings, and whether the endpoint is validated on save.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, zero filler, with the core purpose front-loaded and the storage guarantee as the follow-up. Every clause 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 configuration-writing tool with three undocumented parameters, no annotations, and no output schema, the description is thin: it does not explain the effect of omitting each parameter, whether configuration is additive or replacing, or how success/failure is surfaced.

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% across three parameters (model, api_key, endpoint). The description only obliquely maps to two of them — 'vision endpoint' gestures at endpoint and 'credentials' at api_key — and says nothing about model choice, accepted formats, or the meaning of the null defaults.

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 (Configure) and resource (an optional OpenAI-compatible vision endpoint), so an agent knows exactly what this tool changes. No sibling performs vision-endpoint configuration, so differentiation is implicit rather than stated.

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 word 'optional' hints that a vision endpoint is not mandatory, but there is no explicit when-to-use guidance, no prerequisite conditions, and no mention of alternatives or what happens if it is never configured. The agent must infer the entire trigger 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?

With no annotations, the description carries the full burden. It does disclose genuinely useful behavior beyond the schema: pivot/offset are in local engine XYZ meters, and the first attachment mutates the managed StaticMeshActor into a native Blueprint while later revisions preserve that Actor. It still omits permissions, reversibility, error modes, and what happens for non-door/chest kinds.

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, front-loaded with the action, then the unit caveat, then the stateful-attachment note. The telegraphic style is dense but every sentence carries information; 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 13-parameter mutation tool with no annotations, no output schema, and 0% schema coverage, the description is far too thin. It communicates the moving-asset prerequisite and the one-time Blueprint conversion, but an agent still cannot correctly populate the majority of parameters from this 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?

Schema description coverage is 0% across 13 parameters. The description only clarifies the units/space of pivot and moving_offset; kind's allowed values, and the meaning of uses, angle, distance, event_id, demo_input, moving_asset_id, depleted_asset_id, and interaction_point are undocumented anywhere.

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 pair plus resource: 'Attach/update door/chest/pickup behavior', so an agent knows it configures interactive behavior on an existing asset. It does not, however, distinguish itself from close siblings like create_interactive_prop or edit_prop_part, so sibling routing is left to inference.

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 one real usage constraint: doors/chests require a separately prepared moving asset before this will work. There is no when-to-use vs when-not guidance, no statement about which kinds are valid, and no pointer to an alternative tool for creating rather than configuring interactions.

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?

With no annotations, the description carries full burden and does disclose meaningful side effects: it installs a bridge, creates a backup, and requires restarting UE afterward. However, it omits permissions/auth requirements, whether existing bridge configs are overwritten, and any rate or failure 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?

Three short sentences, front-loaded with the core action and followed by the client-specific path formats and the restart caveat. Efficient with little waste, though the second sentence could be slightly more explicit about which parameter it describes.

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 3-parameter mutation-style tool with no annotations and no output schema, the description covers the main action, path formats, and the restart requirement, but leaves install_bridge and blender_path unexplained and gives no return or verification information.

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% for 3 parameters. The description compensates partially by explaining the required project_path's format differs per client (Unity folder vs UE folder/.uproject), but blender_path and install_bridge are never addressed, leaving a real gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Connect) and resource (project) and clarifies it covers both Unity and UE clients plus bridge installation with backup. It does not explicitly contrast itself with siblings like list_projects or inspect_target, but the client/bridge scope is distinctive enough to identify it.

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 when-to-use or when-not-to-use guidance, and no alternatives named. The Unity/UE folder-format note implies the tool's context but never states prerequisites (e.g., that a project must already exist or when to prefer this over other project 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?

With no annotations, the description carries the full burden and does meaningfully: it discloses an asynchronous 'workflow' that must be polled until completed, retained base/moving mesh structure, Unity prefab / UE Blueprint output, and an optional demo requiring camera aim plus E. It omits permission/asset-overwrite behavior, but the async and artifact-model disclosure is substantial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core capability, then units/axes, then artifact retention, then the async polling contract. Dense but structured; the closing demo/input-binding sentence is the least essential and could be trimmed.

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 5-param mutation with no annotations and no output schema, the description covers units, axis convention, async polling, retained meshes, and the target engine artifact. The main gap is asset_id semantics (does it create or overwrite a library asset?), but overall it is sufficient to invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate: it defines dimensions as width/depth/height in meters, explains that position uses target engine axes, and implies the valid 'kind' values (door/chest/pickup). However, color and asset_id remain undocumented in both schema and text, so the compensation is partial.

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 ('Build a door, chest or pickup') and pins the differentiator: 'native gameplay behavior', which separates it from plain prop siblings like create_prop, revise_prop, and edit_prop_part. An agent can choose this tool without opening a 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?

Usage is implied by the phrase 'interactive prop' and the demo instructions, but the description never says when to prefer this over create_prop, create_prop_set, or configure_interaction, nor when it is inappropriate. Adequate but leaves routing 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?

With no annotations the description carries the full burden. It usefully discloses that PBR baking is automatic, that new assets are placed near the camera, and that revisions preserve transforms. It omits whether the call is long-running/async (siblings get_task_status/cancel_task imply tasks), what side effects occur, and any auth or permission requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first sentence, and the remaining sentences are short and information-dense with no filler. Slightly dense/fragmented but appropriately sized for the tool.

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?

A mutation/creation tool with no annotations, no output schema, and 0% parameter documentation should explain more. Key operational facts (async task behavior, return shape, what asset_id references, allowed kind values) are absent, leaving the agent under-informed 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 description coverage is 0% across 6 parameters, so the description must compensate. It only clarifies the quality parameter ("omit quality to inherit the project"); the meaning of kind, asset_id, collider, position, and the free-form parameters object is left entirely 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?

States a specific verb+resource ("Create an art-directed prop") plus the enabling mechanisms (saved project style, automatic PBR baking). It is clear what the tool does, though it never explicitly contrasts itself with the adjacent revise_prop/create_prop_set 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?

It implies a workflow (consult inspect_library for the nine recipes, parameters, parts and quality settings) and gives one concrete usage rule ("omit quality to inherit the project"). However there is no explicit when-to-use-this-vs-revise_prop guidance and no stated prerequisites.

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?

With no annotations, the description must disclose behavior. It does well by stating 'Create up to eight matching designs', 'Poll every returned task', and 'Partial submission reports already-started tasks'. These are important behavioral traits (batch limit, async task handling, partial failure behavior). It could still mention permissions or whether the style must pre-exist, but it goes beyond mere naming.

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: first sentence states the core action and batch limit, second sentence covers required fields, third lists optional fields, fourth gives critical usage instructions for polling and arrangement. It is efficient and well-structured, though the final sentence about partial submission could be integrated more smoothly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and zero schema description coverage, the description provides some context (batch limit, required/optional fields, task polling, partial failure) but lacks crucial details like authentication needs, rate limits, the format of 'parameters', or what a 'task' return entails. An agent would still need to infer a lot to invoke 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 0%, so the description should compensate. It states each item needs 'kind' and 'asset_id' and lists optional fields (parameters, position, collider). This adds some meaning but is incomplete: the schema has additionalProperties true with no defined structure, and the description doesn't explain the format or expected values for these fields. The guidance is minimal and leaves most parameter semantics 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 states a specific action: creating up to eight matching designs using one saved style. It distinguishes itself from create_prop (single prop creation) by emphasizing bulk creation and matching styles. However, it doesn't explicitly contrast against siblings like create_variants or create_style_kit, leaving some ambiguity for an agent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions a post-creation step ('use arrange_props for copies/placement'), which implies when to use arrange_props, but does not explain when to choose create_prop_set over create_prop or create_variants. The guidance is implicit rather than explicit about alternatives 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?

With no annotations, the description carries the full burden; it does disclose genuinely useful traits: an async workflow ('Poll each task to imported'), a uniqueness constraint ('A new prefix is required'), and a non-global side effect ('Does not change project-wide defaults'). It omits permissions/auth requirements, what happens on a prefix collision, and what the created tasks return, so it is partial rather than complete.

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, front-loaded with the core action and the variant list before the constraints. The final line ('Poll each task to imported') is grammatically garbled, which costs clarity but not length.

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 3-parameter mutation tool with no annotations and no output schema, the description covers the kit variants, prefix uniqueness, async polling, and non-global scope. It still leaves the 'quality' parameter undefined and gives no sense of what a completed task yields, so it is adequate but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It usefully enumerates the accepted 'kit' values (reading_corner, village_market, makers_workshop) and the requirement that 'prefix' be new, but says nothing about the optional 'quality' parameter, leaving one of three params entirely 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?

States a specific verb and resource (create a style kit) and enumerates the three kit variants, so the agent knows exactly what is produced. It does not differentiate itself from lookalike siblings such as create_prop_set or compose_scene, which keeps it short of 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?

There is no statement of when to reach for this tool versus create_prop_set, create_variants, or set_project_style. The only scoping hint is 'Does not change project-wide defaults,' which implies a use case but never names the alternative or the selecting condition.

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?

No annotations are provided, so the description carries the full burden. It discloses two important behavioral traits: drafts stay outside engine assets/scenes (i.e., non-destructive staging), and normal create_prop publishes directly. It does not state what the return value is or the cost/time implications of a generation call.

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, front-loaded with the core action, then scope, then workflow. No wasted words. Slightly fragmented phrasing ('Wait with get_variants, view get_studio_preview') but efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a generation tool with no annotations and no output schema, the description covers lifecycle and staging behavior well, but completely omits parameter documentation (0% coverage on 4 params). An agent can select the tool but cannot confidently populate required fields from the description alone.

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 there are 4 parameters, so the description must compensate — but it never mentions kind, count, asset_id, or parameters. It only implies 'two or three' from the count default. This leaves required parameters like kind and asset_id undocumented in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — generating 3D draft variants with identical lighting and three views. It does distinguish from a sibling: 'normal create_prop publishes directly,' clarifying the boundary. However, the term 'variants' and the exact artifact produced could be tighter.

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-to-use ('Use only when exploring alternatives is useful') and names the direct alternative ('normal create_prop publishes directly'). It also maps the surrounding workflow to specific sibling tools: wait with get_variants, view with get_studio_preview, publish with choose_variant.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses that this is an async job to poll and that vision labels require a configured endpoint, plus a behavioral guardrail ('Never claim content recognition from filenames alone'), but leaves failure modes, outputs, and side effects unaddressed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences plus a workflow clause, front-loaded with the core action and free of filler. Slightly dense, but every sentence carries actionable 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?

For a 3-parameter tool with no annotations and no output schema, the description covers the workflow and one key precondition but omits parameter meaning and return behavior. Adequate but with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 3 parameters and 0% schema description coverage, the description must compensate but largely does not. It gestures at 'provider' and 'allow_remote'-style concepts ('Optional vision labels require a configured endpoint') but never explains what paths, allow_remote, or use_provider actually control.

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 ('Capture') and resource ('model thumbnails and metadata'), which is clear. It doesn't explicitly distinguish itself from the many sibling asset tools, but the asset-description focus is inferable.

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 concrete routing: 'Without a provider, poll this job, call get_asset_evidence... then save_asset_description', and notes optional vision labels require a configured endpoint. It names the alternative tools to chain with, though it never states when NOT to use this tool.

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

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

With no annotations the description carries the full burden and does disclose non-obvious traits: the brief is immutable with its source revision, existing recipe revisions keep their original design, planning alone does not rebuild geometry, and no model API or beauty score is used. It omits permissions, overwrite semantics, and any failure behavior, keeping it short of a 5.

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?

Front-loads the save/read distinction and then proceeds through mode, params, defaults, and workflow. Sentences are dense and mostly earn their place, though the workflow tail ('Follow the returned design, then inspect a real render') is slightly tangential to invoking this specific tool.

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?

There is no output schema and no annotations, so the description carries everything, and it covers mode selection, key parameters, immutability, and the fact that no generative model is involved. The only meaningful gap is focal_point and any note on what the read mode actually returns.

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 must compensate, and it explains role values (environment/interactable/hero), the content of decisions (silhouette, structure, materials, story, avoid), the null-description read mode, and recipe_kind's default route. Only focal_point is left unexplained, so it is strong but not 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?

States specific verbs (save/read) and a specific resource (an asset design brief tied to game context and reference notes), and the dual-mode is explained by 'Omit description to read.' It does not name a sibling it is not, so it falls short of a 5, but the purpose 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?

Gives explicit read/write switching ('Omit description to read'), when to supply recipe_kind ('only if a listed form fits'), and a workflow cue ('Follow the returned design, then inspect a real render'). It does not name alternatives such as set_art_brief or game_art_direction, so usage routing against siblings is incomplete.

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?

With no annotations, the description carries the full burden and mostly does: it warns of the unlock prerequisite, states that untouched parts and engine instances retain identity, and sets expectations that a fused mesh is one part with no invented segmentation. It omits reversibility of locking and any rate/permission details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the action, then layers constraints and caveats in short declarative lines. Dense but nearly every sentence carries distinct information; a minor tightening of the naming/grouping paragraph is possible.

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 7-parameter mutation tool with no annotations and no output schema, the description supplies prerequisites, field semantics, replacement format constraints, and identity-preservation guarantees. Missing only explicit return/response behavior and lock/unlock reversal details.

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 must compensate, and it does: changes are defined as scale/offset/rotation XYZ in Blender Z-up plus linear color RGB, roughness and metallic; replacement_path is constrained to local GLB/glTF/FBX/BLEND fitted to part bounds; part/members semantics are explained. lock_geometry and lock_material are only implied by 'lock' and 'Unlock explicitly', leaving a small gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb set (group, edit, lock, replace) and a precise resource ('parts of an imported static model'), which separates it from edit_prop_part/edit_selected_prop by scope. It does not explicitly name those siblings, so it falls short of 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?

Gives concrete operational context: inspect_asset.report.parts lists source parts, members groups existing named parts, and geometry/material must be unlocked explicitly before changes. No explicit when-not-to-use or sibling routing, so not 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?

With no annotations, the description carries the full burden and delivers meaningful behavioral context: lock semantics (retains saved geometry/material, must unlock before editing locked properties), coordinate frame (Blender Z-up), and pivot conventions differing between recipes and imported parts. It omits permissions, reversibility/undo behavior, and 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?

Front-loaded with the core action and purpose, followed by a dense but well-organized list of change types and coordinate/lock caveats. Minor waste from a mid-sentence line break, but 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 mutation tool with no annotations and no output schema, the description supplies the key facts an agent needs: what can be changed, units, coordinate conventions, and lock behavior. Remaining gaps (return value, error behavior) are less critical given no output schema exists.

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 must compensate, and it does: it documents the opaque 'changes' object fields (scale XYZ, offset XYZ in meters, rotation XYZ in degrees, color linear RGB, material enum values, roughness, wear) and clarifies lock_geometry/lock_material semantics. 'part' is contextualized via inspect_asset, though asset_id remains 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?

States a specific verb (edit/lock) on a specific resource (one named part of a recipe or imported model) and points to inspect_asset for enumerating parts. It is clear, though it does not explicitly distinguish itself from close siblings like edit_imported_part or edit_selected_prop.

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 some routing guidance (inspect_asset lists parts) and a conditional instruction (explicitly unlock before changing locked properties), which implies how to use locking. However, there is no explicit when-to-use vs. when-not guidance against the many closely named sibling edit 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?

With no annotations present the description carries the full burden. It usefully discloses that the result contains an undo_id for restoring the edit and that asset scope affects all LOADED instances (implying unloaded instances are untouched), but it says nothing about permissions, whether edits persist across a rebuild, or other 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?

Front-loaded with the core purpose, then scope rules, then value formats, then return behavior. Dense and mostly waste-free, though the line-broken layout makes it read slightly like a spec dump rather than prose.

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 annotations, the description supplies the important load-bearing details: operation families, scope behavior, value units, and the undo_id return. Gaps remain around operation enumeration and ground/focus value shapes, but an agent has enough to call 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 0%, so the description must compensate and largely does: it defines scope semantics, unit conventions for transform (meters, degrees, multipliers), and tint color/material formats, plus asset_id's role. It still never enumerates valid values for the required 'operation' parameter, though the opening sentence hints at them.

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 ('edit') and resource ('scene') plus the concrete operation families it supports: transform, tint, ground, focus. 'Without a Blender rebuild' signals the engine-level nature and implicitly separates it from Blender-rebuild siblings like build_asset or prepare_asset, though no sibling is named 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 explains the two scope modes ('selected' vs 'asset') and their effect, which is real usage guidance for choosing the right call. However, it never says when to use edit_scene versus alternatives such as edit_selected_prop, edit_prop_part, arrange_props, or undo_scene_edit, nor any prerequisites.

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?

With no annotations, the description carries the full burden and does disclose meaningful behavior: edits propagate to the shared recipe covering all instances, a strict single-selection precondition, and the queued-inspection resume path. It stops short of stating reversibility, permissions, or what happens to unmentioned fields.

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?

Purpose and scope are front-loaded in the first sentence, followed by tight precondition and edge-case notes. Three short sentences with no filler, though the last sentence about imported static models is slightly tangential to the primary recipe-edit purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a five-parameter mutation tool with no annotations and no output schema, the description covers the essential preconditions and propagation scope but leaves the parameter payloads and expected result under-described. Adequate, not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% across five parameters, so the description must compensate. It touches most of them in passing ('named recipe part', 'geometry/material edits and locks', 'inspection_request_id'), but 'changes' and the lock semantics are only implied and no formats or valid values are given.

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 ('edit a named recipe part') and adds a distinguishing scope mechanism ('Resolve the engine selection... without typing an asset ID'), which separates it from ID-taking siblings like edit_prop_part. It does not explicitly name those siblings, but the selection-based entry point makes the intent 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?

Gives the key precondition ('Requires exactly one selected managed asset') and a recovery path ('If inspection is queued, resume with inspection_request_id'). It never names an alternative tool or states when to prefer this over edit_prop_part or edit_imported_part, so routing 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?

With no annotations, the description carries the full burden, and it does disclose useful traits: 'Partial updates retain omitted fields' and that changes affect future briefs rather than already imported assets. However, it omits permissions/auth requirements, whether writes are reversible, and return behavior, which matters for a read/save tool with 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?

Front-loads the purpose and packs field-value guidance efficiently with no filler. The terse 'view:'/'construction:' shorthand is dense but readable; a little structure (bullets) would help but nothing is wasted.

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 with no annotations and no output schema, the description covers field semantics, partial-update behavior, and forward-scope effects, which is most of what an agent needs. Missing return/permission details are minor given the absence of an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single 'settings' parameter is an opaque object with 0% schema description coverage, so the description must compensate. It does so well, naming keys (view, construction, detail, style_notes) and enumerating allowed values (isometric/top_down/..., handcrafted/salvaged/machined, auto/readable/balanced/closeup), adding real 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?

States a specific verb pair (read/save) and the resources it manages (gameplay, world, style_notes, view, construction) for 'this game', and distinguishes itself from set_project_style for palette. The scope is clear, though the exact field semantics of 'gameplay'/'world' remain a bit opaque.

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 one explicit alternative ('Use set_project_style for palette') and a scoping rule ('This changes future briefs, not already imported assets'), but gives no guidance on when to prefer it over close siblings like set_art_brief or set_scene_look. Usage is implied rather than fully specified.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses a few traits (retry via resume rather than a new plan, review_images returns actual images), but says nothing about permissions, side effects, whether plans are persisted, or the cost/mutation profile of a gateway that can invoke any action. For a tool with this much latent power, that is a serious gap.

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 text is a run-on block with sentences broken mid-clause by line wraps ('a saved plan containing\nrecipe/custom/source/template/interactive items'), and mixes workflow instructions with feature notes without front-loading the core purpose. Several sentences do not earn their place against the ambiguity they leave.

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 gateway with no annotations, no output schema, zero schema description coverage, and a free-form 'values' parameter, the description omits the essentials: how actions are discovered, how the 'values' payload maps to the routed tool, and what a response looks like. Given the complexity of routing to ~50 sibling tools, it is under-specified.

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 there are four parameters (query, action, values, operation). The description only obliquely hints at 'action' ('exact action name') and 'operation' ('search/describe'), and never explains 'query' or the free-form 'values' object, which is the payload that drives every routed call. It does not compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies this as a single entry point for game-development tasks and a gateway that exposes 'existing tools ... by their exact action name,' which hints at routing behavior. But 'One entry for a game-development task' does not state a concrete verb+resource, and it never clarifies what the tool itself does versus what the sibling tools do. It is only partially distinguishable from the many specific siblings listed.

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 some sequencing advice ('Start with context and find_assets/find_designs, then produce a saved plan...', 'Retry with resume, not a new plan') and tells the agent to 'Search/describe only the capability needed.' However, it never says when to call game_workflow instead of the concrete siblings (e.g. build_asset, compose_scene, resume_workflow), and it references tools (find_assets, find_designs, review_images) that do not appear in the sibling list, leaving the routing decision ambiguous.

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?

With no annotations, the description carries the full behavioral burden and does unusually well: it discloses credit consumption, that cancellation stops local work but a submitted provider task may still consume credits, that saved provider IDs survive interruption without resubmission, and that candidates default to outside the scene. It does not describe error/rejection behavior or the shape of the returned candidates.

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?

Purpose is front-loaded in the first sentence and the remaining clauses each carry distinct, non-redundant information. The telegraphic, line-broken style is dense but every clause earns its place; it reads slightly run-on rather than tight prose.

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 9-parameter generation tool with no annotations and no output schema, the description covers cost, cancellation, and publication semantics well but omits the meaning of four parameters and gives no sense of the return payload or how candidates are surfaced for review.

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% across 9 parameters, so the description must compensate. It explains provider, allow_paid, candidate_count, preview_only behavior and the 1-4 PNG/JPEG references for image_paths, but leaves asset_id, prompt, position, and settings completely unexplained.

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?

Opens with a specific verb+resource+output ('Generate 1-3 textured GLB candidates') and situates it in the pipeline, noting that publish_prepared selects one. An agent can distinguish this from siblings like prepare_asset or publish_prepared without opening any 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?

Gives clear operational context: configure providers in the local app, use allow_paid only when authorization covers the provider/count, and use publish_prepared to select a candidate. It stops short of explicit when-not-this-tool exclusions versus list_generation_providers or prepare_asset.

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?

No annotations are provided, so the description carries the disclosure burden. 'Return' implies a read-only retrieval, but the description says nothing about the returned image format, size, availability state, or auth needs. For a zero-argument getter this is acceptable but thin.

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 compact clause with the object of the action front-loaded. The trailing 'notes are in open_workbench' is relevant but slightly ambiguous about whether it refers to notes on the reference or the review.

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 annotations, no output schema, and no parameters, the description is the only context an agent gets. It identifies the artifact and the companion tool for notes but omits any return-format or failure context, leaving gaps for a retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline of 4 applies. There is nothing for the description to clarify beyond what the empty schema already shows.

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: 'Return the saved reference image'. The scoping word 'saved reference' and the pointer to open_workbench for notes help an agent tell it apart from siblings like get_preview or get_review, though it never explicitly contrasts 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?

Implies usage ('for client visual review'), which gives an agent a sense of when this is relevant, and it routes to open_workbench for notes. There is no explicit when-not or named alternative, so guidance remains inferred rather than stated.

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?

With zero annotations, the description carries the full burden and discloses almost nothing: no read-only assurance, no auth/permission requirements, no return format details, and no note on what happens if the evidence_id is missing. Only the implicit fact that it returns a thumbnail is conveyed.

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 short sentence with no padding, and the resource is front-loaded after the verb. It is efficient, though arguably too terse to be fully useful.

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 annotations, no output schema, and an undocumented parameter, the description leaves key information an agent needs unstated. It does not clarify the return value, the id source, or how this differs from the many sibling retrieval tools.

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% for the single required parameter 'evidence_id', and the description adds no meaning about what an evidence id is, where it comes from, or its format. The description fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (Return) and resource (native thumbnail), which is clearer than the tool name 'get_asset_evidence' suggests. However, it does not distinguish itself from closely related siblings such as get_preview, get_studio_preview, or get_art_reference, leaving the agent to guess which retrieval tool to use.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance and no named alternatives. The phrase 'that supports an asset description' hints at context but never states when this evidence thumbnail should be fetched versus a general preview.

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?

With no annotations, the description carries the burden and delivers real behavioral context: the 30s wait ceiling, that a timeout stays 'queued/unknown', that 'superseded' means another revision is current, and what 'Imported' contains. It still omits auth requirements and whether the read is safe/non-mutating, but the status-state disclosures are genuinely useful.

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?

Front-loads the core action in the first clause, then adds three tight sentences of qualifying detail with little waste. Slightly jargon-heavy ('engine receipt'), but efficiently sized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without annotations or an output schema, the description must stand alone, and it partially does by explaining several status values. It does not cover asset_id semantics or state the return shape exhaustively, leaving gaps for a tool whose statuses are the whole point.

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 must compensate. It explains request_id's role (prevents stale success) and wait_seconds' cap (up to 30s), but asset_id is left entirely undefined, so roughly a third of the parameters remain 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?

States a specific verb and resource ('Read an engine receipt' for an asset) and clarifies the wait semantics, so an agent can tell it returns build/asset status. However it never distinguishes itself from the closely related sibling get_task_status or inspect_asset, leaving overlap ambiguous.

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 conditional guidance on parameters ('pass the build's request_id to prevent stale success', 'optionally wait up to 30s'), which implies when to wait vs. poll. But it never states when to choose this over get_task_status or inspect_asset, so the when-to-use decision 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?

With no annotations, the description carries the full burden. It does disclose the output format (PNG) and the retry-queued-captures behavior, which is useful, but says nothing about failure modes, what happens with an invalid asset_id, or whether the call blocks on queued work.

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, front-loaded sentences with the core output stated first and the conditional view semantics after. No padding, though the playcheck-specific wording assumes context the agent may lack.

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 3-parameter tool with no annotations and no output schema, the description covers the primary purpose and some view/request_id behavior, but leaves asset_id undocumented and the interplay with get_studio_preview unresolved. Adequate but with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It partially does by explaining view='before' versus the default post-interaction image and the request_id retry path, but it omits asset_id entirely and never mentions the schema's default view value of 'studio', leaving one parameter fully 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?

"Return an engine PNG" states a specific verb and output, and the note about retrying queued captures clarifies the secondary function. However, it never distinguishes itself from the sibling get_studio_preview, so an agent may not know which preview tool to pick.

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 via 'Retry queued captures with their request_id' and the playcheck/view='before' scenario, but it never states when to prefer this over get_studio_preview or when a request_id is actually required. Usage is inferable rather than explicit.

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

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

With no annotations, the description carries the full burden. 'Read' and 'persistent' usefully imply a safe, non-mutating call on stored state shared by Codex, Harness, props and prop sets, but it does not confirm no side effects, whether a style must exist first, or what is returned.

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 front-loaded sentence with no filler. The scope of the shared style is stated immediately and nothing is redundant.

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-arg read tool without an output schema, the description is adequate but thin: it does not say how to obtain or set a style, nor what the returned art direction consists of, leaving the agent to infer behavior on an empty style.

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 nothing for the description to disambiguate; baseline for a parameterless tool is 4.

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: reading persistent art direction. It is clear this is the read side of project style, but it never names the sibling set_project_style, so the agent must infer the pairing from the name alone.

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 when-to-use guidance is given. There is no mention of set_project_style as the write counterpart, nor any condition indicating when reading the style is appropriate versus inspecting an asset or reading an art brief.

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?

With no annotations, the description carries the full behavioral burden. It implies a read-only call by saying it avoids creating another capture and discloses that before/after states are returned, but says nothing about permissions, error/not-found behavior, or what the states contain.

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?

It is a single front-loaded sentence with no filler, which is good, but the wording is circular and nonstandard ('native capture task states'), so the brevity comes at the cost of clarity rather than 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 one-param retrieval tool with no annotations and no output schema, the description should at least explain the review_id and the returned shape. Instead it omits both and does not clearly route the agent among the several review/capture siblings, leaving meaningful gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the single parameter 'review_id' is undocumented in both the schema and the description. The description does not explain what a review_id refers to, where to obtain one, or how it relates to captures, so the param is effectively opaque.

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?

It names a verb ('Return') and a resource ('before/after native capture task states'), but the resource is oddly phrased and does not clearly correspond to the tool name 'get_review' or to a review object, leaving the actual payload ambiguous. An agent cannot confidently tell what get_review retrieves versus siblings like capture_review or review_quality.

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 'without creating another capture' implicitly contrasts this call with capture_review, hinting that it should be used to read existing state rather than create one. However, it never states the condition or when-not explicitly, and there is no mention of prerequisites or alternatives by name.

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?

No annotations are provided, so the description carries the burden. It usefully discloses an output-semantics trait (label as Blender studio, not an engine screenshot) and that isolated drafts are included, but says nothing about auth, cost, latency, or whether a render is generated synchronously.

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, no filler, with the core action front-loaded. The labeling instruction is a little operational rather than descriptive, but nothing is wasted.

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 annotations, no output schema, 0% schema coverage, and two undocumented required parameters, the description is too thin. It never explains what request_id is for, how the render is returned, or what happens on failure, leaving real gaps for a render-producing tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It supplies the meaningful values for the 'view' parameter (studio/front/back) that the schema lacks, but leaves asset_id and request_id entirely unexplained, so compensation is only partial.

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 ('Return an actual Blender source render') with view variants and scope (isolated drafts). It explicitly distinguishes itself from the sibling get_preview, so an agent can tell the two apart without opening a 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?

Names the alternative ('get_preview shows the game scene') and thereby implies the selecting condition: use this for Blender studio renders, get_preview for the game scene. No explicit prerequisite or when-not guidance beyond that routing hint.

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?

With no annotations, the description carries the burden and does disclose a blocking wait behavior capped at 30 seconds. However, it omits other relevant traits such as authentication needs, polling vs long-polling behavior, failure modes, and what statuses may be returned.

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 is front-loaded with the core action and contains no unnecessary words. It is appropriately sized for the tool's scope.

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 annotations, no output schema, and 0% schema description coverage, the description is too sparse. It omits the meaning of request_id, what status values or task types to expect, and how it relates to sibling task-status or cancellation tools.

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 must compensate. It gives some meaning to wait_seconds by saying 'wait up to 30 seconds,' but it never mentions the required request_id parameter or what it identifies, leaving a major gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Query or wait) and resource (task status), with broad scope covering editor actions, previews, and builds. It does not distinguish itself from the sibling get_asset_status, so it falls short of 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?

The description implies usage by saying it can query or wait for any task, but it never states when to use this tool instead of alternatives like get_asset_status or cancel_task. No explicit exclusions or prerequisites are provided.

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?

With no annotations, the description carries the burden. It implies a read-only operation and specifies included data (status, report, preview) and excluded data (no aesthetic score), but omits permissions, side effects, pagination, and response format details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that states the action, scope, and exclusion without filler. It is appropriately concise for a simple read tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and 0% schema coverage, the description is insufficient. It does not document the required study_id parameter, return structure, or when to prefer this tool over siblings like get_review or get_preview.

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% for the single required parameter study_id. The description never mentions study_id or explains what identifier it expects, adding no meaning beyond the schema's bare type and title.

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 resources ('exact status, report and preview views') and explicitly excludes aesthetic score, distinguishing its scope. However, it does not differentiate from sibling tools like get_preview or get_review, and 'candidate' is not tied to the tool name's 'variants' without inference.

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 alternatives such as get_review, get_preview, or choose_variant. The description is purely declarative and does not mention prerequisites, context, or 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?

With no annotations, the description carries the full burden and does so substantially: it states the original file is unchanged, that opaque Principled PBR and glTF ORM inputs are baked while rigs/transparency/mixed shaders fail explicitly, that up_axis is applied after format conversion, and that CC0 provenance is retained and no generation service is billed.

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?

Purpose is front-loaded and most sentences carry distinct operational detail, but the middle section reads as a dense run-on of format/bake/correction rules rather than cleanly grouped points.

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 5-parameter tool with no output schema and no annotations, the description covers the important behavioral ground (baking, failure modes, preview workflow, polling, provenance). Only the asset_id and position parameters and a clear sibling comparison 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?

Schema coverage is 0% with a nested free-form source and settings object, so the description must compensate and largely does: it specifies the source shape ({provider: local, path} or {provider: polyhaven, id}), enumerates settings keys including texture_size values, lod_ratios ordering, collision options, and explains preview_only. It leaves asset_id and position 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 first sentence names a specific verb (import) and resource (asset) plus supported formats and two source providers. It is clear what the tool does, though it does not explicitly differentiate itself from close siblings like prepare_asset or build_asset despite calling itself 'Prepare and import'.

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 useful workflow guidance: preview_only produces an isolated draft whose source is later fed to publish_prepared, and the user should poll the exact request. However, it never states when to choose import_asset over prepare_asset or build_asset, leaving the key sibling choice 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?

No annotations are provided, so the description carries the full burden. 'Read' implies a non-mutating operation and it usefully enumerates the returned content ('source script, recipe parameters and successful revisions'), but it says nothing about permissions, rate limits, or behavior on a missing asset.

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 front-loaded sentence with no filler; the action and the returned artifacts come first and the timing cue ('before editing') closes it. Efficient, though its terseness is close to under-specification.

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, no-annotation, no-output-schema read tool the description covers the essentials (what is read, when) but omits what the asset is, whether the read is safe/idempotent, and how it relates to the many sibling inspect tools.

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 never mentions asset_id or what identifies a valid asset. The sole parameter's name is semi-self-documenting, but nothing compensates for the documented gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Read') and enumerates the resources returned: source script, recipe parameters, and successful revisions. An agent knows what it gets back, but the description never differentiates this from siblings like inspect_target, inspect_scene, or inspect_library, so routing still requires inference.

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?

'before editing' gives one implied usage context (pre-edit inspection), which is genuine guidance but minimal. It names no alternatives (e.g., inspect_target for targets) and states no when-not condition, leaving the agent to guess which inspect_* tool applies.

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?

No annotations are provided, so the description carries the full behavioral burden. 'List' implies a read-only, non-destructive operation, but the description says nothing about scope (global vs project), whether results are cached/stale, or how large the payload is. For a tool with zero annotation coverage this is thin.

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 front-loaded sentence with no filler, and the enumeration is compact. It could arguably be tightened, but nothing is wasteful.

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, no annotations, and no parameters, the description is the only source of information, and it only gives broad category names rather than the shape or fields of what is returned. It is minimally adequate but leaves the agent unable to predict the response structure.

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 and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies; the enumeration of returned categories even adds slight value in the absence 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 gives a verb ('List') and enumerates the kinds of items returned (styles, quality budgets, recipe parameters, semantic part names), so the agent knows this exposes a catalog. However, it does not distinguish the tool from the many sibling inspection tools (inspect_target, inspect_scene, inspect_asset, inspect_performance), nor does it explain what 'the library' is. Purpose is inferable but 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?

There is no statement of when to call this versus the other inspect_* siblings, and no mention of prerequisites or context. The agent must guess that this is a discovery/lookup step, likely before applying presets or styles.

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?

With no annotations, the description carries the full burden and does well: it discloses async queued-then-retry behavior, warns that texture bytes are an RGBA8+mip estimate rather than measured VRAM, notes shared meshes are identified, and explicitly states FPS/draw calls are never inferred. This is a genuinely useful limitation set; only the read-only nature is left implicit.

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?

Front-loaded with the read scope, then compact caveat sentences. Every line earns its place (retry hint, preset budgets, texture-byte caveat, shared-mesh note, FPS/draw-call exclusion). Slightly dense but not padded.

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 4-param tool with no annotations and no output schema, it covers behavior and caveats well, but leaves asset_id unaddressed and wait_seconds (an async timing control) unexplained. Adequate but with a clear remaining gap around parameter-driven latency behavior.

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 must compensate, and it explains two of four params: request_id (used to retry a queued request) and preset (mobile_prop/scene_prop/hero_prop, with budgets). asset_id and especially wait_seconds are left undocumented in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Read) and resource set (native triangles, vertices, material slots, textures, LOD counts), so the agent knows this is an asset performance inspection tool. It is distinguishable from generic inspect_asset/inspect_scene by the performance-metric focus, though it never names a sibling 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?

Gives an operational rule (retry with request_id if queued) and names the presets that expose budgets, which implies when to use it. However, it never says when to prefer this over inspect_asset or inspect_library, nor any preconditions or exclusions. Usage is implied rather than stated.

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?

With no annotations, the description carries the full burden. 'Read' implies a safe, non-mutating operation, and 'actual selected' usefully signals it reflects live state rather than a declared selection. Beyond that, no return format, side effects, or permission requirements are disclosed.

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 front-loaded sentence with no padding, and the core action leads. It is slightly cryptic in places ('managed props', 'this object') but every word carries weight.

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 tool with no output schema, the agent still cannot tell what a 'scene' read returns or what 'managed props' are. Complexity is low, so this is adequate but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to document; baseline 4 applies. No parameter-related misinformation is present.

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 ('read') and resource ('active scene and actual selected managed props'), and adds the goal of resolving 'this object'. However, it doesn't distinguish itself from nearby siblings like inspect_target, inspect_asset, or inspect_library, leaving the agent to infer the difference.

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 'to resolve this object' hints at a scenario, but there is no explicit when-to-use, no exclusions, and no named alternative such as inspect_target. The agent gets a rationale rather than 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?

No annotations are provided, so the description carries the full disclosure burden. 'Inspect' implies a read-only diagnostic, but the description never confirms side-effect behavior, cost, latency, or whether it triggers any engine/Blender interaction. The listed domains hint at a broad status probe but omit what is actually returned or measured.

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 front-loaded sentence with no padding. The enumerated list is slightly comma-heavy but every item conveys scope, so it 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 zero-arg diagnostic tool with no output schema, the description should explain what kind of report comes back. It gestures at the domains checked but leaves the return shape and purpose (status vs. validation) underspecified, so an agent knows roughly what area it covers but not what to expect or how to 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?

The tool takes zero parameters, so per the baseline there is nothing for the description to disambiguate. No penalty applies; the schema is trivially 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 verb 'inspect' is clear and the sentence enumerates the inspected domains (engine, coordinates, Blender, editor heartbeat, pending/completed assets). However, the noun 'target' is never defined, and the description does nothing to distinguish this from the many sibling inspect_* tools (inspect_scene, inspect_library, inspect_asset, inspect_performance), so an agent cannot confidently route between 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives despite at least four sibling inspection tools. An agent must guess whether this is a status check, a health probe, or something else.

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?

With no annotations, the description carries the full burden, and it partially meets it by disclosing that secrets are never returned and that only 'optional configured' adapters appear. However it omits auth requirements, return format, and whether disabled/unconfigured providers are excluded.

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 front-loaded sentence with zero waste: it names the resource, the qualifier, and the security guarantee compactly.

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 list tool with no output schema, the description covers what is listed and the key safety trait. It could note the return shape or empty-config behavior, but nothing critical to 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?

The tool takes zero parameters, so the schema has nothing to document and the baseline of 4 applies. The description adds no param semantics needs and none are required.

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 (List) and resource (optional configured Meshy/self-hosted generation adapters), and the Meshy/self-hosted qualifier distinguishes it from siblings like generate_model. The term 'adapters/providers' is slightly jargony but the intent is 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?

No when-to-use guidance and no named alternatives. There is no indication of when an agent should call this versus other listing tools such as list_projects or inspect_library, leaving the trigger entirely 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?

No annotations are provided, so the description carries the behavioral burden. It does disclose one genuine trait – that listing works without an active connection – but says nothing about return format, ordering, pagination, or what "saved/local" scoping means.

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 front-loaded sentence with no wasted words; the discovery verb leads. The trailing "without a connection" qualifier is well placed to convey scope quickly.

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-param list tool with no output schema and no annotations, the description covers the essentials but is thin. It omits any hint of what the results contain or how many, leaving the agent with only the resource name.

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 the schema has nothing to document and the description has nothing to compensate for. Baseline 4 is appropriate for a no-argument tool.

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 clear verb ("Discover") and resource (saved/local projects, Blender and recipe defaults), so an agent knows this enumerates projects. It is slightly muddled by lumping three different resource types together, which blurs the boundary with siblings like connect_project, but the intent is legible.

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?

"without a connection" implies this is the pre-connection discovery step and contrasts implicitly with connect_project, which is useful context. However, no alternative is named explicitly and no condition for preferring this tool is spelled out.

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?

With no annotations, the description carries the full behavioral burden. It does disclose one useful trait ('Originals are retained', implying non-destructive handling), but omits permission/auth requirements, what 'retry' actually mutates, and any side effects or limits — thin coverage for a multi-mode operation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the operations front-loaded and no filler; the retained-originals note is a slightly orphaned trailing clause but overall the text is economical and well 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 two-parameter, multi-mode tool with no annotations, no output schema, and 0% schema coverage, the description is too sparse: it does not define the mode values, explain `paths`, describe what a 'job' is, or state expected outcomes, leaving an agent without enough 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 0%, so the description must compensate. It loosely hints at three modes (scan/inspect/retry) but never maps them to the `mode` parameter or its default value ('status'), and says nothing about what `paths` accepts or how it interacts with the modes.

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 three distinct actions (scan the inbox, inspect jobs, retry failed revisions) on an 'asset inbox' resource, so the general purpose is discernible. However, it does not explain what the 'designated source inbox' is, and it never distinguishes this multi-mode tool from closely related siblings like get_asset_status, inspect_asset, or resume_workflow, leaving the agent to guess.

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 alternatives, nor when to choose each of the three listed modes. The description enumerates capabilities but offers no conditions, prerequisites, or routing to 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?

With no annotations, the description carries the full behavioral burden and does so well. It discloses that no external vision service is invoked, existing assets are not changed, the host interprets images, the tool validates/saves rather than scores beauty, and confidence below 0.6 preserves current defaults. These are meaningful behavioral constraints that an agent could not infer from the schema alone.

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 purpose and then walks through the workflow, which is appropriate for a two-step vision tool. It is dense but every sentence adds useful information. There is minor redundancy between 'current AI host's vision' and 'The host interprets images', and the run-on style could be tighter, but overall it is well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, stateful, two-step tool with no annotations and no output schema, the description provides enough context to use it correctly. It explains what is returned (images and source_token), how to continue (call again with token and analysis), what the tool affects (future designs), what it does not affect (existing assets), and its safety profile. The remaining gap—analysis object shape—is deferred to the returned schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain the four parameters, and it largely does. evidence_ids is tied to describe_project_assets, use_reference is tied to set_art_brief's saved image, source_token is explained as coming from the returned images, and analysis is described as using the returned schema. It does not provide detailed type/format expectations for analysis, but the semantic mapping is strong.

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 gives a specific verb and resource: recognizing the project's visual look from actual images using host vision. It also states the downstream effect of applying inferred palette, roughness, shape, density, and art notes to future designs. However, it does not explicitly distinguish this tool from sibling style tools such as get_project_style or set_project_style, leaving some ambiguity about how it differs from 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 clearly outlines a two-step workflow: first obtain evidence IDs from describe_project_assets or use_reference for set_art_brief's saved image, then call again with the returned source_token and analysis. It also states the confidence threshold below which defaults are kept. It does not explicitly say when to use this tool instead of get_project_style or set_project_style, so the alternative-tool guidance is incomplete.

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?

With no annotations provided, the description carries the full burden, and it does disclose a genuine behavioral trait: host capability determines whether a UI is rendered. It does not state whether the call is read-only, whether it mutates session/selection state, or what the caller receives back, so the behavioral picture is only half-drawn.

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, front-loaded with the action, and the host-capability caveat follows. The clause "an embedded UI is never required for the workflow" largely restates the preceding sentence's point about non-MCP clients, so there is a small amount 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 zero-parameter tool with no output schema and no annotations, the description covers the host-compatibility question well. It is still incomplete on the essentials an agent needs: what the workbench surfaces after opening, whether any state changes, and how it relates to workbench_action in the same family.

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 nothing for the description to disambiguate and the baseline is 4. Schema coverage is 100% and no parameter semantics are needed.

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?

It states a verb and resource ("Show the unified ... workbench") and enumerates the surfaces it unifies (task, selection, preview, generation, review), so the intent is not a pure tautology. But it never says what calling it actually accomplishes for the agent, and it draws no line against the sibling tool workbench_action, which an agent must distinguish from.

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 real conditional guidance: MCP Apps-capable hosts can render it in chat, other clients can use the normal tools, and an embedded UI is never required. That tells the agent when this tool is appropriate and when it can be skipped. It stops short of naming alternatives explicitly (workbench_action, resume_workflow) or stating any prerequisite.

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?

With no annotations, the description carries the full burden and delivers richly: it discloses that it verifies stale candidates, preserves GUID/native references, records inverse moves, saves native files yet does not roll back unrelated scene edits, leaves protected/scripts/scenes/data in place with reasons, keeps Unreal redirectors, and does not rewrite code/config paths. It even clarifies security/cost behavior ('No model provider, visual AI guessing or paid calls' and 'excluding sensitive data').

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?

Dense but well-organized, front-loading the core purpose then a mode-by-mode breakdown. Each sentence adds distinct operational or behavioral details. Slightly long and run-on in places, but 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?

Complete for a multi-mode, mutating asset-organization tool with no output schema. The description covers the full lifecycle (scan→plan→inspect→apply→undo), safety semantics, exclusions, and cost/behavior constraints. Nothing critical to 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 0%, so the description must compensate. It explains mode values (scan, plan, settings, inspect, history, apply/undo), the settings sub-object (destination, rename bool, group_by 'type'/'source', exclude, overrides, rules), plus the scan_id/plan_id relationship, providing substantial meaning beyond the bare schema. It could be clearer on some top-level params like limit/offset/scope.

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/resource: 'Automatically name/classify project assets through native Unity/UE moves; supports undo.' This clearly distinguishes it from siblings like search_project_assets or tag_project_asset. It does not explicitly name a sibling alternative, preventing 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?

The mode-by-mode walkthrough (scan, plan, settings, inspect, history, apply/undo) gives clear sequential usage context and specific flow instructions like 'plan: use scan_id equal to the completed scan request_id'. However it lacks explicit when-not-to-use guidance or named 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?

With no annotations, the description carries the full burden and does disclose real behavior: a failed error/budget check queues nothing, engine identities/instances survive a successful reimport, geometry locks apply to recipe edits, and preparation may reduce geometry. That is unusually rich side-effect disclosure. It loses a point for not clarifying permissions, cost, or response shape.

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?

Purpose is front-loaded and the text is short, but sentences are terse to the point of being cryptic ('Review source before/studio and engine captures') and lean on unexplained domain jargon, reducing practical clarity.

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 reprocessing/mutation tool with no annotations, no output schema, and 0% schema coverage, the behavioral notes are a genuine asset, but parameter meaning and failure/response expectations remain underspecified.

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% across two parameters, so the description must compensate, and it largely does not. 'Uses import_asset settings' faintly gestures at the settings object but says nothing about its shape, defaults, or what asset_id must reference.

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 opening sentence names a specific verb and resource: 'Reprocess an imported asset from retained source with measured simplification and LODs.' That distinguishes it from import_asset and build_asset well enough. It stops short of a 5 because the relationship to siblings like build_asset and publish_prepared is left implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies context ('Uses import_asset settings', 'Review source before/studio and engine captures') but never states explicitly when to choose prepare_asset over import_asset, build_asset, or restore_asset. Usage is inferable rather than spelled out.

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?

No annotations are provided, so the description carries the full behavioral burden. It does not disclose whether saving is destructive or reversible, whether any permissions/auth are required, what the native-scan dependency implies, or what a 'save' overwrites - critical gaps for a tool whose default mode is read but which also mutates shared defaults.

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 front-loaded sentence with no filler; the operations are stated up front. It is efficient, though its brevity is partly a symptom of under-specification rather than disciplined density.

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 three-parameter, multi-mode tool with no annotations, no output schema and 0% schema coverage, this one sentence is far from complete. It omits mode-to-parameter mapping, the shape of settings, the origin of scan_id, and any return-value or error behavior.

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% across all three parameters, so the description must compensate and largely does not. The words 'read/save/suggest' loosely imply the mode param and 'native scan' hints at scan_id, but there is no explicit mapping, and the settings object's expected keys (naming, folder, preparation, intake) are only indirectly gestured at.

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 specific verbs (read/save/suggest) and a resource (shared naming, folder, preparation and intake defaults), so an agent can roughly grasp the domain. However, it bundles three distinct operations into one vague clause and never distinguishes itself from siblings like get_project_style/set_project_style, leaving the boundary of 'conventions' fuzzy.

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 when-to-use guidance, no when-not-to-use, and no named alternative. The 'or suggest prefixes from a native scan' clause hints at a conditional mode but never explains when an agent should pick read vs save vs suggest, or how this differs from the project-style 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?

With no annotations, the description carries the full burden. It discloses some behavioral context: missing protected slots block later imports, and generated property/hierarchy changes are outside the preservation contract. However, it does not state permissions, reversibility, what set/clear actually alters, or the effect of the default inspect mode, leaving significant gaps for a mutation-capable 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?

Four sentences, front-loaded with purpose and then dense parameter notes. Every clause contributes: path constraints, units, and preservation scope. Minor density and crypticness, but 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 4-parameter tool with no annotations or output schema, the description covers purpose and key parameter formats but omits the asset_id meaning, mode semantics, and what set/clear operations do to existing data. It is adequate but incomplete for safe 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 must define the parameters. It describes bindings ({slot, material_path}) with allowed path roots, sockets ({name, position, rotation}) with coordinate units, and implies mode values inspect/set/clear from the opening sentence. The required asset_id remains unexplained, but the description adds substantial meaning beyond the bare 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?

States a specific set of capabilities: inspect/set/clear custom material overrides and persistent root attachment points. It does not distinguish the tool from siblings like inspect_asset or restore_asset, so an agent cannot confidently route among them, but the verb and resource are 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?

No explicit when/when-not guidance or named alternatives. The note that missing protected slots block later imports implies some context, but the agent is left to infer when to call protect_asset versus inspect_asset or restore_asset.

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?

No annotations are supplied, so the description must carry the behavioral burden. It discloses the key behavioral fact that the original .blend is not modified and that file auto-execution is disabled, plus async 'queued/result' semantics. But it leaves side effects vague and doesn't state auth needs, failure modes, or whether publishing is reversible.

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?

Front-loads the core purpose in the first sentence and follows with usage and cross-references. Three compact sentences with no obvious filler, though the 'material contract' phrase is opaque.

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?

There is no output schema and no annotations, so the description should ideally cover return format and mutation safety. It partially does (original preserved, queued/result semantics) but leaves params, error behavior, and return shape unaddressed for a mutating tool with 4 undocumented parameters.

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 all four parameters (asset_id, blend_file, collider, position) are undocumented in the schema. The description adds no per-parameter meaning, required-vs-optional guidance, or format for blend_file/position. This is a significant gap for a 4-param tool.

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+resource: publishing the Export collection of an existing saved .blend while preserving the original. It distinguishes from publish_prepared by name. However, the notion of a 'material contract' and 'queued/result semantics' is jargon an agent cannot independently verify.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to use this after another Blender tool has modeled and saved an asset, and names publish_prepared as the alternative for a reviewed import_asset preview. This gives a clear selection condition, though it doesn't state when publishing would be inappropriate beyond that.

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?

With no annotations, the description carries the full burden. It does disclose meaningful side-effect behavior: the original is retained, and materials, LOD settings, and source attribution survive publication, and the original remains reprocessable. It is silent on permissions, error cases, and whether publication is reversible, so it is only partially complete.

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, front-loaded with the action and followed by the required arguments and persistence guarantees. No filler, though the third sentence slightly restates the retention point already made in sentence one.

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?

There is no output schema and no annotations, so the description must carry more weight. It covers the key persistence behavior but not return values, error semantics, or what 'the engine' entails, leaving gaps for a tool that appears to be a terminal publishing step.

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 both parameters are undocumented in the schema and the description must compensate. It contextualizes asset_id as 'the completed preview's asset_id' but says nothing about what request_id is or where it comes from, so the coverage gap is only half filled.

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: 'Send an accepted isolated import_asset preview to the engine.' It names the source artifact (an accepted preview from import_asset), which lets an agent distinguish it from siblings like publish_blend or prepare_asset. It does not explicitly contrast against those siblings, so it stops short of 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?

The prerequisite is implied through 'accepted' and 'completed preview's asset_id,' suggesting this is the terminal step after a preview is accepted. However, there is no explicit when-to-use guidance, no when-not guidance, and no named alternative (e.g., publish_blend), leaving the agent to infer the workflow position.

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?

With no annotations, the description carries the full burden and does disclose meaningful behavior: a hard limit of two repairs including automatic grounding, rejection of assets changed outside the review, and an asynchronous 'wait for the returned review request' pattern. It omits permission requirements, reversibility, and what happens to prior repairs, keeping it below the top tier.

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, front-loaded with the core action before the constraints and workflow. No padding, though the awkward line breaks make the sequence slightly harder to parse than a single clean paragraph.

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 annotations, no output schema, and a nested object parameter at 0% schema coverage, the description covers the workflow and constraints but leaves parameters and return behavior unexplained. It is adequate on process, incomplete on inputs.

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 none of the three required parameters (request_id, part, changes) are documented in the schema. The description alludes to a 'part repair' and 'changes' only obliquely and never explains the request_id or the shape of the nested changes object, so it fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Apply a concrete part repair to a completed quality review') and ties the action to a completed review, which is more specific than the generic sibling names. It does not explicitly contrast itself with near-neighbors like edit_prop_part or review_quality, so it stops short of the top tier.

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 a clear precondition (a completed quality review) and the follow-up flow ('then recapture and recheck', 'Wait for the returned review request, then inspect its fresh before/after images'). Constraints like the two-repair cap and rejection of externally changed assets further bound when it applies, though no alternative tool is named.

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?

No annotations are provided, so the description bears the full disclosure burden. It does reveal one meaningful behavioral trait — scene instances are retained across the reimport — but says nothing about permissions, whether the prior state is overwritten or versioned, or side effects on the existing asset.

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 front-loaded sentence with no filler; the key action leads and the retained-instances detail follows. It is efficient, though its brevity is partly under-specification rather than disciplined concision.

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 annotations, no output schema, and zero parameter documentation, this description is too thin. An agent knows roughly what happens but not how to choose the revision, what permissions are needed, or what the operation does to the current asset state.

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 must compensate for both parameters and does not. It never explains what asset_id refers to or when/how the optional 'revision' should be supplied versus left null, which is the parameter most likely to cause an incorrect call.

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 verb 'Reimport' plus 'a previous successful source' conveys that an existing asset is being brought back, which is more than a restatement of the name. However, 'source' is ambiguous (source file? source revision? source asset?), and the description never distinguishes this from sibling tools like import_asset or resume_workflow that also deal with previously produced artifacts.

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 explicit when-to-use guidance, no prerequisites, and no exclusions. The phrase 'previous successful source' weakly implies it applies only to assets with a prior successful build, but the agent is left to infer that restoration is appropriate versus import_asset or resume_workflow.

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?

No annotations are provided, so the description carries the full behavioral burden. It does not say whether resuming is idempotent, what happens if the referenced task was never interrupted or already completed, whether it blocks, or what state mutation it performs. Only the phrase 'saved stages' hints at how resumption works.

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 focused sentence with no filler, and the key qualifier ('interrupted') is front-loaded after the verb. It is short without being cryptic, though it is arguably too terse for a mutation tool.

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 state-mutating workflow control tool with no annotations, no output schema, and an undocumented identifier parameter, the description is insufficient. An agent cannot tell what happens on success, what errors arise for a non-interrupted request_id, or how this differs from the other task-lifecycle tools.

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 single required parameter request_id has no description anywhere. The description never explains what a request_id is, how to obtain it (presumably from a prior task or get_task_status), or whether it must reference an interrupted task specifically.

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?

Clear verb+resource: 'Resume an interrupted ... task', scoped to composition, quality and generation work, which is more specific than a bare name restatement. It does not differentiate itself from siblings such as get_task_status or cancel_task, which operate on the same task lifecycle, so an agent must infer the boundary.

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 word 'interrupted' implies the precondition for use, but there is no explicit when-to-use statement, no exclusions, and no reference to alternatives like get_task_status (check progress) or cancel_task (abandon). With numerous task/scene siblings, this leaves the routing decision to guesswork.

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?

With no annotations, the description carries the full burden, and it does disclose genuinely useful non-obvious behavior: it reuses the native asset, does not duplicate files, and does not claim new authorship. It omits scene side effects, whether placement is reversible/undoable, and any permission requirements, so significant gaps remain.

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 lines, front-loaded with the action and constraint, with no filler. The final get_preview sentence is slightly terse and reads as a dangling operational note rather than integrated guidance, but overall it is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-parameter tool with no annotations, no output schema, and 0% schema coverage, the description covers the core action and reuse semantics but leaves positional placement, return/response semantics, and failure modes unaddressed. Adequate but with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 3 parameters, so the description must compensate. It effectively documents 'path' and implies 'mode' via 'Preview or place', but the 'position' parameter is never mentioned, leaving a third of the parameters undocumented in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb pair ('Preview or place') and clearly names the resource ('existing project model/prefab/Blueprint by its returned native path'). The second sentence distinguishes it from duplication/import siblings by noting it reuses the original native asset, though it doesn't name those siblings directly.

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 its returned native path' implies the path comes from an upstream lookup (e.g. search_project_assets), and the get_preview follow-up hints at the preview workflow. However, there is no explicit when-to-use vs alternatives, and it never explains when 'preview' mode is preferable to 'place'.

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?

No annotations are provided, so the description carries the full burden. It mentions reading conflicts but doesn't state whether it's read-only, whether it modifies state, what permissions are needed, or what happens on conflict. For a tool in an asset publication workflow, this is insufficient behavioral disclosure.

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, appropriately sized, but the phrasing is dense and jargon-laden ('native protected slot conflicts', 'completed prepared candidate'), which reduces clarity. It is concise but not well-structured for comprehension.

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 annotations, no output schema, 0% schema coverage, and two required parameters, the description is completely inadequate. It fails to explain the return value, the parameters, or the tool's behavior in any meaningful way.

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 mention either parameter (asset_id, candidate_request_id). It provides no semantic meaning for the parameters, leaving the agent to infer their purpose entirely from their names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses vague, jargon-heavy phrasing ('Read native protected slot conflicts before publishing a completed prepared candidate') that restates internal terminology rather than stating a clear verb+resource. It doesn't differentiate itself from siblings like publish_prepared or protect_asset, which are in the same workflow. An agent would struggle to understand exactly what this tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'before publishing' implies a pre-publish timing, which is a hint, but there is no explicit statement of when to use this vs alternatives like publish_prepared or protect_asset. No conditions or exclusions 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?

With no annotations, the description carries the full burden and does disclose meaningful behavior: a two-repair limit, the <=0.5m threshold gating auto_fix, the explicit absence of an aesthetic score, and that repair_quality auto-refreshes the comparison. Gaps remain around permissions, what state is mutated/consumed, and the async polling contract details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with the core purpose and every sentence adds distinct information (threshold, vision dependency, limit, polling). The prose is dense and jumps between concerns, but there is little filler, so the size is defensible for the behavioral content conveyed.

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 annotations, no output schema, and 0% schema-description coverage, the description covers workflow and behavioral limits well but leaves parameter meanings (preset, asset_id) unexplained and gives no expectation of the returned findings structure. Adequate but with clear gaps given the 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?

Schema description coverage is 0%, so the description must compensate for all three parameters. It explains auto_fix's semantics reasonably (alignment to a collision surface when gap <=0.5m) but says nothing about asset_id or the preset parameter (e.g., what values beyond the default 'scene_prop' mean), leaving most parameters 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 opening line states a verb-plus-resource ('Measure native issues and capture same-camera before/after with a two-repair limit'), which signals a quality-review tool, but 'native issues' is vague jargon and the phrase never crisply says what the tool produces. It is distinguishable from get_review and repair_quality only by inference, not by an explicit contrast.

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 real conditional guidance: auto_fix only aligns when the measured gap is <=0.5m, visual findings require get_preview/get_art_reference, and polling is done via get_task_status. It also implies repair_quality is the sibling that applies edits, so routing is largely covered even without an explicit 'do not use when' clause.

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?

With no annotations, the description carries the behavioral burden and does well: it discloses the global blast radius (every instance using the asset), that geometry/material locks remain independent, and the retention behavior when apply_design is omitted. It stops short of stating permissions, reversibility, or undo semantics for a broad mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.