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. 'Durable' hints at persistence, but nothing is said about permissions, idempotency, name-uniqueness constraints, what happens if the host job already exists, or what state the job starts in.

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 tight sentence with the verb and resource front-loaded and the usage rule trailing. Nothing is redundant or 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?

The output schema relieves the description of explaining return values, but for a mutation tool with zero annotations and three undocumented required parameters, the description is too thin. An agent cannot tell what to put in 'goal' or what guarantees 'durable' provides.

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 all three required parameters rely on the description, which explains none of them. 'Single-host' loosely implies the host parameter, but 'goal' and 'name' are entirely undefined — no format, no constraints, no examples (e.g., a natural-language objective vs. an enum).

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?

Names a specific verb ('Create') and a specific resource ('durable single-host modeling job'), and 'single-host' implicitly contrasts with the multi-host planning siblings. It stops short of naming an actual sibling, but the resource is concrete enough to distinguish 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?

'Use one job per host in an interop plan' gives a cardinality rule that implies this tool is invoked repeatedly, once per host, after planning. It never states when to prefer this over studio_plan_workflow or studio_execute_action, nor any prerequisites such as requiring an existing plan.

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 does substantial work: it discloses the serialization/concurrency constraint, the mandatory revision check, workspace-relative path resolution, the opt-in gate for scripts, the extra integrity requirement (expected_source_sha256) for Blender run_script with input_blend, and the narrow meaning of the returned status. It still omits side effects, reversibility, and failure modes for the mutating actions.

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?

Roughly five short sentences, front-loaded with the core operation and followed by preconditions in decreasing generality. No filler; the only weakness is that the line-wrapped fragment structure makes the precondition list slightly harder to scan than a single ordered sentence would.

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?

An output schema exists, so return values needn't be described, and the status caveat is a nice addition. But for a tool multiplexing ten distinct actions with an untyped parameters object, the description leaves too much unspecified: no action-by-action parameter contract and no preconditions or side effects for the destructive actions. Adequate as a policy statement, incomplete as an invocation guide.

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 parameters field is free-form with additionalProperties, so the description must carry the load — yet it only explains workspace-relative paths and names two keys (input_blend, expected_source_sha256) for one action. The per-action shape of 'parameters' for the other nine enum values, and the semantics of job_id and expected_revision, are left unaddressed.

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 concrete verb and resource: execute one serialized native action and validate output evidence. The 'serialized' qualifier differentiates it from the planning/inspection siblings, which don't run actions. It stops short of naming or contrasting siblings explicitly, and never enumerates what the ten actions mean.

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?

Several preconditions are implied ('Revision is required', scripts need server-side opt-in), and 'Return status describes this action, not completion of every project goal' is a useful interpretive rule for an agent reading results. But there is no statement of when to pick this over the other studio_* tools, no per-action eligibility rules, and no when-not-to-use guidance.

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

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

No annotations are provided, so the description carries the full burden; it does at least imply a read-only inspection and discloses that it performs consistency verification, which is meaningful behavioral context. However, it says nothing about whether verification has side effects, cost/rate characteristics, or error behavior for inconsistent chains. The output schema handles return-value explanation.

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 waste, but it is under-specified rather than efficient; the brevity buys no clarity and omits basic scoping information the agent needs.

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

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

Because an output schema exists, return values needn't be described, and a one-parameter read tool is simple enough that this is nearly adequate. Still, with eight sibling tool and zero annotation coverage, the definition leaves key questions (what state, when to prefer it over studio_status or studio_reconcile_job) unanswered.

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 (job_id) at 0% schema description coverage, and the description adds nothing about it — no format, no source, no example. With coverage this low, the description should have compensated by explaining what a job_id refers to and how to obtain one, and it does not.

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 gives verbs (read, verify) and objects (durable state, event-chain/snapshot consistency), so the general intent is inferable from the name plus text. But it never says the resource is a job, and 'durable state' is abstract jargon that could mean many things. Nothing distinguishes it from close siblings like studio_status, studio_recovery_report, or studio_reconcile_job.

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 many other studio_* introspection tool, no prerequisites, and no exclusions. The agent must guess whether this is a pre-recovery check, a general status read, or a diagnostic.

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. It adds useful behavioral context by saying it rechecks current SHA-256 and size and scopes to completed-action artifacts, but it does not state whether the operation is read-only, whether rechecking updates stored metadata, or what happens if artifacts are missing.

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

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

The description is a single front-loaded sentence with no wasted text. It leads with the primary action ('List') and appends the verification behavior efficiently.

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

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

The tool is simple and has an output schema, so return-value explanation is not required. However, with no annotations, an undocumented required job_id, and no usage guidance, the description leaves important context missing for correct invocation.

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

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

The only required parameter is job_id, and schema description coverage is 0%. The description never mentions job_id or explains that the listed artifacts are scoped to that job, so it does not compensate for the undocumented parameter.

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

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

The description uses a specific verb and resource: it lists completed-action artifacts and rechecks their SHA-256 and size. This is clear enough to distinguish from status/job-planning siblings by the artifact-focused purpose, but it does not explicitly name or compare against alternatives.

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

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

There is no explicit guidance on when to use this tool versus siblings such as studio_inspect_job or studio_status. The phrase 'completed-action artifacts' implies a post-completion verification use case, but the description gives no exclusions or alternative routing.

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

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 key trait that this produces requirements rather than a scene, and that modeling happens client-side through native actions — valuable. It omits whether planning is idempotent, how the seed influences output, and any side effects or limits of the planning step.

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 purpose, with no filler. Tight and readable, though the defaults sentence is somewhat vague in what it is asserting.

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?

An output schema exists, so return-value explanation is not required, and the description does cover the pipeline role and the 'requirements not evidence' caveat. For a tool whose sole parameter is a complex nested brief with no property descriptions, the description leaves too much of the input semantics unaddressed.

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 roughly nine nested brief properties (goal, seed, style, zones, detail, size_m, target, triangle_budget, reference_policy, texture_resolution), and the description explains none of them individually. It mentions 'defaults target high detail' and 'complete occupied zones' vaguely, but an agent cannot learn what triangle_budget or reference_policy mean from the 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 ("Plan a detailed editable environment") and names the pipeline, Blender then Unreal. It stops short of naming a sibling such as studio_plan_workflow to disambiguate, so differentiation relies on the agent inferring from 'environment'.

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?

"This returns requirements, not a scene or evidence of completion" usefully signals this is a planning step that must be followed by actual modeling via the chat client. However, it never says when to prefer this over studio_plan_workflow or studio_create_job, and gives no explicit exclusions or 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?

No annotations are provided, so the description carries the full behavioral burden. 'Return' implies a read-only planning operation, and the one-to-three host limit and ordering behavior are useful context, but it does not state permissions, side effects, or what happens with invalid host counts.

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 redundant or filler content. Every clause adds a concrete detail about output scope, host count, or ordering.

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

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

The output schema covers return values, so the description need not explain them. However, with no annotations and zero schema descriptions, the missing explanation of the required 'goal' parameter and lack of usage guidance leave 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 description coverage is 0%, so the description must explain parameters. It adds the one-to-three host constraint for 'hosts', which is not in the schema, but says nothing about the required 'goal' parameter, leaving half the input 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 return type: role handoffs and acceptance requirements for hosts. It is clear what the tool produces, though it does not explicitly distinguish itself from the sibling studio_plan_environment.

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 guidance on when to use this tool versus alternatives such as studio_plan_environment or studio_create_job. Usage is only implied by the phrase 'plan workflow' in the tool 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that this records a claim, is not a rollback or independent idle detector, and enables new actions, but it leaves out details about mutation effects, permissions, expected_revision conflict behavior, and idempotency.

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 short, front-loaded, and each sentence adds useful information. It moves from purpose to preconditions to limitations without waste.

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

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

The output schema exists, so return values need not be described. However, for a no-annotation tool with four fully required and undocumented inputs, the description covers the safety narrative but not enough parameter semantics to reliably call it, especially for expected_revision.

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 explain all four required parameters. It gives an important semantic warning only for host_is_idle, but job_id, notes, and especially expected_revision are left 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?

The description states a specific action: recording a trusted operator inspection after an interruption so new actions can proceed. It distinguishes itself from rollback and idle-detection behavior, though it does not explicitly name or compare itself to sibling tools such as studio_recovery_report.

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

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

It gives clear preconditions: inspect the native host and output files and confirm the previous process stopped. It also warns that host_is_idle must not be inferred from the bridge lock alone, but it does not explicitly name alternative tools or state when to prefer them.

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 says the tool does not edit files, launch a host, detect native process idleness, repair files, or authorize replay. It omits operational details such as permissions or error behavior, so it is strong but not exhaustive.

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

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

The description is front-loaded with the core action, then adds report contents, exclusions, and usage guidance. Every sentence contributes and there is no redundant framing.

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?

An output schema exists, so return values need not be explained, and the behavioral boundaries are clear. However, the required job_id is completely unaddressed, which leaves a meaningful gap for an agent trying to invoke the tool correctly.

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

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

The required job_id parameter is never mentioned in the description, and schema description coverage is 0%. For a job-scoped recovery report, the description should explain what job_id identifies or where it comes from, but it provides no parameter guidance.

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: inspect durable recovery evidence. It also identifies what the report contains (unresolved intents and preserved run directories) and distinguishes the tool from reconciliation by saying it does not authorize automatic replay.

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

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

It gives clear context for use: inspect host and artifacts before explicit reconciliation. It also states exclusions (no idle-process detection, repair, or automatic replay), though it does not explicitly name the sibling studio_reconcile_job alternative.

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

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

With no annotations, the description carries the full burden, and it does disclose the key trait that this is non-destructive and does not modify a document. However, 'probe native hosts' leaves open what a probe entails (connection attempts, latency, failure behavior when no host is available) and whether repeated calls have 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?

A single sentence with no filler, front-loading the two actions (probe, list) before the non-mutation constraint. It is slightly dense with undefined jargon ('native hosts'), but nothing is wasted or buried.

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

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

The tool is simple (no params) and an output schema exists, so return values need not be described, and the description covers the core purpose and the read-only property. Still missing is any statement of prerequisites (e.g., that a host must be reachable) or what 'action names' are used for, which matters for a discovery step that gates the other studio_* 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?

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description adds no misleading parameter hints.

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 specific verbs and resources: 'probe native hosts' and 'list available action names', which meaningfully expands on the opaque name 'studio_status'. It also carves out a non-mutating scope ('without editing a document'), though it never names a sibling such as studio_list_artifacts or studio_plan_environment to sharpen 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?

Usage is only implied: the phrase 'without editing a document' suggests this is a safe pre-flight/discovery call before studio_execute_action or studio_create_job, but the description never says 'use this when...' or excludes an alternative. An agent must infer the sequencing itself.

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