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

No annotations exist, so the description carries the full burden. It does disclose that this mutates Studio state, can create new instances, and requires a studio_id when multiple Studios are open — meaningful behavioral context. It says nothing about whether existing textures are overwritten, what happens with partially invalid targets, or what the call returns.

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

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

Purpose is front-loaded in the first clause and the rest is dense, useful parameter guidance with no filler. The run-on construction and stacked parentheticals make it slightly harder to scan than it needs to be.

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 6-parameter mutation tool with no annotations and no output schema, the description covers targeting, instantiation, per-class property mapping, and extra property setting. The notable remaining gap is the absence of any statement about return values or failure behavior, which matters given there is no output schema.

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

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

At 50% schema coverage with 6 params (one nested), the description compensates well: it distinguishes bake (flipbook settings come from the recipe) from texture (no flipbook settings), explains targets vs create semantics, gives the default className, and states that properties uses the same format as set_properties. Only studio_id and parent path syntax are left to 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?

Opens with a specific verb and resource ("Puts an uploaded bake ... on instances in Studio") and enumerates the class-specific property each target type receives (ParticleEmitter flipbook fields, Texture on Beam/Trail/Decal, TextureID on MeshPart). That level of specificity clearly separates it from vfx_bake and vfx_upload, though it never names those 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 explains the internal mode split well — "targets: existing instances; create: { parent, name?, className? } makes a new one (default ParticleEmitter)" — and clarifies bake vs raw texture. It does not state prerequisites such as needing a prior vfx_bake/vfx_upload, nor when to prefer vfx_preview or vfx_viewer, so usage is implied rather than routed.

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 well: it discloses file side effects and exact write paths (bakes/<out>.png, bakes/<out>.json), the recipe contents, alpha/colour-spread handling, supersampling and returned warnings plus a preview. It omits whether an existing bake with the same name is overwritten and gives no sense of render cost or time limits.

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 verb and output are front-loaded, but the body is a single sprawling sentence with triple-nested parentheses describing layouts and file naming, which is hard to parse on first read. Nothing is irrelevant, but the structure should have been split into discrete sentences or bullets.

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 10-parameter mutation with a nested values object and no output schema, the description covers the returns (paths, flipbook settings, warnings, preview) and the artifact layout thoroughly. The remaining gaps are overwrite semantics and cost, which matter for a tool that writes files.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds meaning the schema does not, notably the 'sharper than Roblox's 1024 cap' tiling use case and the bakes/<out>-<row>-<col> naming for tiles. It says nothing extra about ss, margin, mode, values or duration, so not a full 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?

Opens with a specific verb and resource ('Renders a node into its final PNG') and enumerates the artifact variants (still, 2x2/4x4/8x8 flipbook, tiles x tiles). The word 'final' implicitly separates it from preview/render siblings, but it never names vfx_render or vfx_preview to make that distinction explicit.

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 a clear downstream step ('Upload it with vfx_upload') and implies use when you need exported assets rather than previews. It offers no explicit when-not guidance and no comparison against vfx_render or vfx_preview, leaving the agent to infer which sibling to pick.

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 declares irreversibility ('no undo') and non-cascading side effects (a bake survives node deletion, the Roblox asset survives). It omits behavior on failure (missing name), permission requirements, and what confirmation/response to expect.

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

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

Two sentences, no filler. The destructive action is front-loaded and the constraints follow, so the agent reads the risk before the conditions.

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

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

For a destructive two-parameter tool with no annotations and no output schema, the definition covers scope, target formats, irreversibility, and survival of related artifacts. Missing only error/failure behavior and any confirmation return semantics.

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

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

Schema coverage is only 50% (the enum for 'kind' is undocumented in the schema), but the description compensates by explaining both enum values and what 'name' refers to in each case. This adds real meaning beyond the schema rather than restating it.

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 (deletes) plus both resource variants it handles, and maps each to a concrete file path (shaders/<name>.wgsl vs bakes/<name>.png plus recipe). This clearly separates it from the read/write/upload 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?

Gives an explicit gate: 'Only on the developer's request', which tells the agent not to invoke it speculatively. It does not name an alternative (e.g. which tool to use instead to remove or revert a shader), leaving that inference to the sibling list.

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 disclose useful behavior, namely that omitting the section parameter returns the index and overview. However, it does not state that the tool is read-only/side-effect free, nor characterize the response size or format of each section.

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 purpose and followed by the default-behavior rule and the recommended reading order. The fragment style ('Without section: ...') is slightly awkward but wastes no space.

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

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

For a single-parameter documentation tool with no output schema, the description supplies purpose, valid values, default behavior, and reading order. It does not say what each section actually contains, which would help an agent jump straight to the right section instead of reading overview and node first.

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% (a bare untyped 'string'), so the description must compensate, and it does: it enumerates every valid section value (overview, node, helpers, examples, quality, roblox) and defines the default behavior when the parameter is omitted. This is exactly what an agent needs and is not available anywhere else.

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 content: it covers writing, rendering, baking, uploading, applying and previewing VFX lab nodes as WGSL baked into Roblox textures, and that it returns a guide by section. This is clearly separable from siblings like vfx_render or vfx_bake, which perform those actions. It never uses an explicit verb like 'returns documentation', so the exact nature of the response is inferred 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?

'Read overview and node first' gives explicit sequencing guidance for a guide tool. The default behavior with no section is also given. It stops short of stating when to consult this versus calling the sibling operation tools directly, which would be the final piece of 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?

With no annotations, the description carries the full burden and does substantial work: it discloses the TimeScale 0 freeze, that TimeScales are restored afterward, how burst (Enabled false) versus enabled emitters emit, and that the camera auto-frames unless camera_position/look_at_position are supplied. It does not cover permissions, whether the viewport state is otherwise disturbed, or failure behavior, which keeps it below 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?

Four dense sentences, each carrying distinct information (action, emitter timing rules, camera behavior, cleanup), with the main action front-loaded. No filler sentences.

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 the description does not say what the captured images are returned as (paths, base64, a viewer handle) or how multiple moments map to results. Everything else an agent needs for a 6-parameter, 1-required tool is present, so this is one real gap rather than a general shortfall.

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

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

Schema coverage is 50%, yet the description explains the semantics of the under-documented parameters: 'at' as the moments after emit, 'emit' as a per-burst override of EmitCount, 'targets' as emitters at or under the given paths, and that camera_position/look_at_position override auto-framing. Only studio_id is left to the schema, which documents it adequately.

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 chain and resource: plays ParticleEmitters under targets in the Edit viewport, freezes them at each moment, and captures one screen image per moment. That is far more specific than a restated name and clearly separates it from siblings like vfx_upload or vfx_delete. It never explicitly distinguishes itself from the closest siblings (vfx_render, vfx_viewer), 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?

There is no statement of when to choose this tool over vfx_render or vfx_viewer, no precondition for calling it, and no exclusion. The only usage signal is the implicit 'Edit viewport' / open-Studio requirement, which the agent has to infer from the studio_id parameter.

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 discloses key traits: GPU rendering, non-destructive behavior ('The file is not changed'), per-cell stats, quality warnings, and backdrop choices. It still omits operational traits such as performance or auth requirements, which prevents a full 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 description is front-loaded and dense with useful details, avoiding filler. Its semicolon-heavy style makes some mode distinctions harder to scan, but every sentence contributes 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 an 11-parameter rendering tool with nested sweep and no output schema or annotations, the description covers the essential modes, output stats, quality warnings, and non-mutation. It is not fully exhaustive about every parameter, but the schema supplies most remaining 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 high at 82%, so the baseline is 3, but the description adds meaningful semantics beyond the schema: the phases mode, the sweep object's purpose and defaults, and the backdrop options. It does not add much for ss, size, frames, margin, values, or duration, but the added nested-object guidance is valuable.

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: 'Renders a node on the GPU and shows it as one image,' with concrete grid behavior. It indirectly distinguishes itself from write-oriented siblings by saying 'The file is not changed,' though it does not name 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?

It explains the default flipbook behavior, when phases are useful, and what sweep does, which implies usage contexts. However, it never explicitly says when to choose vfx_render over vfx_preview, vfx_bake, or other siblings, nor does it state 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 load and does well: it discloses ordering, atomicity ('all or nothing'), the uniqueness precondition on each old, the matching exception via all: true, and explicitly warns that the source is not echoed back. It stops short of permissions, conflict/retry semantics on concurrent edits, or whether the hash can be used as a precondition.

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 tight sentences, front-loaded with the operation and its atomicity, then the precondition, then the return contract. Every sentence carries non-redundant 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 an unannotated mutation tool with no output schema, the description supplies the return shape (new hash + verdict), the atomicity guarantee, and the precondition. The main residual gap is concurrency: 'latest version' hints at a race but no stale-hash or conflict behavior is described.

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

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

Schema coverage is only 50% (the edits array items have no field descriptions), and the description compensates substantially by defining the occurrence constraint on 'old' and the meaning of 'all: true'. However, it never explicitly defines 'new' as the replacement text nor whether it may be empty to delete a match, so a gap remains.

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: changes a node via exact text replacements, applied in order to the latest version. That distinguishes it in spirit from a full-rewrite sibling like vfx_shader_write, but no sibling is named, so the agent still has to infer the split.

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 mechanics imply the usage case (targeted text substitution rather than wholesale writes), but the description never says when to pick this over vfx_shader_write or vfx_shader_read, and gives no guidance on retry/conflict behavior when operating on 'the latest version'.

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 carry the burden, and it does surface meaningful traits: the library path resolution via $VFX_LAB_LIBRARY with a default, the problem-reporting format (line:column), and the side effect/cost that it compiles each shader on the GPU. It stops short of stating read-only safety explicitly or the latency/abort behavior when a compile fails.

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

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

Two sentences, no filler, and the scope (whole library) is front-loaded before the detail about returned fields and the GPU compile note. Every clause carries information an agent would otherwise have to guess.

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 there is no output schema, the description must describe the return payload, and it does: hash, state (clean or line:column problems), and per-parameter type/range/default. For a zero-param listing tool that is nearly complete; only the GPU compile cost and failure behavior are left 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?

The tool takes zero parameters and the schema is an empty object, so there is nothing parameter-level to document. Baseline 4 applies; the description adds the only relevant configurability context, the $VFX_LAB_LIBRARY environment variable.

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?

"Every node in the VFX library" is a specific scope plus a resource, and the sentence enumerates the returned fields (hash, state, parameters). It implicitly contrasts with single-shader tools like vfx_shader_read by saying "every node," but it never names a sibling or explicitly draws 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: it is obviously the tool to call when you want the whole library enumerated. There is no explicit when-to-use statement, no exclusion such as "for one shader use vfx_shader_read," and no note on whether calling it repeatedly is costly because every shader is compiled.

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 returned surface area: source, hash, state/problems, and parameters. It says nothing about read-only safety guarantees, behavior when the node is missing, or permission requirements, leaving meaningful gaps.

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

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

A single front-loaded sentence covering the return surface with no filler. The parenthetical 'what vfx_shader_write's replaces names' is grammatically garbled and slightly hard to parse, which keeps it from a 5.

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

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

No output schema exists, so the description must convey what comes back, and it does enumerate source, hash, state, problems, and parameters. It is largely complete for a one-parameter read tool, with only error/missing-node behavior left unstated.

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

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

Schema coverage is 100%, and the schema already documents the name format ('ring/shock, letters, digits, _ and -'). The description adds only the possessive 'a node's', so baseline 3 is appropriate.

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

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

The description names the resource (a node) and enumerates what it surfaces: source, hash, state, problems, and parameters, which distinguishes it from vfx_shader_write/vfx_shader_edit. The retrieval verb itself is only implied by the tool name rather than stated, so it falls short of a clean verb+resource statement.

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?

Using 'a node's' implies single-node retrieval versus vfx_shader_list's enumeration, and the hash parenthetical ties it to vfx_shader_write, so usage is inferable. But there is no explicit when-to-use, when-not-to-use, or named alternative (e.g., 'to see all nodes use vfx_shader_list').

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 optimistic concurrency behavior, that stale writes are rejected, the new hash is returned, and that verdict details include state and line:column problems. It does not cover permissions, side effects, or whether replacement 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 compact and front-loaded: creation/replacement semantics first, then the hash requirement, then return behavior, then the prerequisite guide. Every sentence adds useful information with no filler.

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

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

For a write tool with no annotations and no output schema, the description is nearly complete: it explains the mutation model, concurrency guard, returned hash/verdict, and prerequisite guide. The main remaining gap is that it does not discuss permissions or broader side effects.

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

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

Schema coverage is 67%, and the description fills the main gap by explaining that 'replaces' must be a hash from vfx_shader_read or the last write/edit, plus what happens if the hash is stale. Name and source are already described in the schema, so the description adds targeted value rather than repeating 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 and resource: creates a node or replaces one whole. The phrase 'replaces one whole' implicitly distinguishes this from partial editing via vfx_shader_edit, but it does not explicitly name or contrast the sibling 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?

It provides clear context for replacement: you must pass a hash from vfx_shader_read or your last write/edit, and the write is skipped if the file changed. It also directs the agent to read vfx_guide first. It does not explicitly say when to use this versus vfx_shader_edit for partial changes.

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 behavioral burden and does so well: it discloses that uploads are public, moderated and permanent, that they require an explicit request, that they run under the Studio user's account, and that duplicate uploads are suppressed unless force is true. This is unusually complete for a mutation tool with no annotation coverage.

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

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

Three compact sentences, front-loaded with the core action and followed by the critical safety and idempotency constraints. No sentence 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 permanent, public mutation tool with no annotations and no output schema, the description covers the important ground: auth context, moderation, permanence, when to use it, and duplicate handling. The main remaining gap is fuller explanation of the bake parameter, which is only indirectly described.

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

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

Schema description coverage is only 33%, so the description must compensate. It adds meaningful semantics for force (bypasses the duplicate-upload check and returns a new id) and implicitly ties bake to the baked PNG, but it does not explain the bake parameter's format or how studio_id is used beyond the schema's own note.

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: uploads a baked PNG via Roblox's Studio MCP and records the asset id in the recipe. That clearly distinguishes it from siblings such as vfx_bake (which produces the PNG) and vfx_render/vfx_preview (which do not publish assets).

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

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

It gives explicit usage conditions: "only on an explicit request, after the look is settled." That tells the agent when to invoke it and implies when not to, though it does not name a specific alternative tool for other cases.

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 well: it discloses once-per-machine startup, the port environment variable and default, live library following, Auto bake behavior, and Export side effects. It does not cover error handling, lifecycle/stopping behavior, or auth, but the core behavior is substantially transparent.

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

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

The description is front-loaded with the action and return value, then follows with useful feature and behavior context. It is somewhat lengthy and includes a dense feature inventory, but the information is structured and largely 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?

There is no output schema, so the description appropriately explains that it answers the URL, along with port selection and live-update behavior. Its main gap is not clarifying lifecycle or error cases, but it is complete 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?

The tool has zero parameters, so the baseline is 4 and no parameter explanation is required. The description correctly avoids inventing parameter semantics and instead focuses on invocation behavior and configuration via environment.

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: it 'Starts the local lab page' and 'answers its URL', making the core purpose clear. It does not explicitly differentiate itself from siblings such as vfx_preview or vfx_render, so it falls short of full sibling-distinguishing clarity.

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

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

It provides implied usage context ('for the artist to open in a WebGPU browser', 'once per machine') but gives no explicit when-to-use versus alternatives or when-not-to-use guidance. The agent must infer that this is the live interactive viewer rather than the render/preview/bake siblings.

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