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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, and the description adds valuable behavior beyond that: results come from the running binary, members are returned as signatures, deprecated members are only counted and never listed, and deprecated members still execute with warnings. This is non-obvious, important behavioral context that is fully consistent with the annotations.

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

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

The description is front-loaded with purpose and every paragraph carries a distinct, useful point. It is longer than a minimal definition, but the length is warranted by the need to explain deprecation semantics, signature format, and sibling differentiation, so there is no wasted text.

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, the description takes on the burden of explaining what the agent will receive: member signatures, inherited counts, and the fact that deprecated members are counted but not listed. It also covers both operations and their typical usage, making it complete for an introspection tool.

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

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

Schema description coverage is 100%, so each parameter already has a meaningful description, giving a baseline of 3. The tool description adds genuine value by explaining the semantic difference between describe and classes and by justifying why inherited defaults to false, complementing rather than merely repeating the schema.

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

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

The description opens with a specific verb-resource pair: 'Lists the properties, methods and events of any Roblox class, read from the engine that is running.' It explicitly contrasts with the sibling inspect, which reads values on an existing instance, so the agent can differentiate the two tools without inspecting schemas.

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

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

It explicitly states when to use the tool: 'Use it before writing Luau against a class you are not certain of.' It also explains when not to use it, drawing a clear line against inspect, and gives guidance for choosing between the describe and classes operations.

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

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

Annotations only supply coarse hints (destructiveHint, openWorldHint, readOnlyHint=false); the description supplies the specifics an agent actually needs: grants are permanent with no revocation, publish silently fails to update EditableImage/Mesh/PartOperation, restart bleeds servers over 10 minutes, uploads are moderated and quota-bound, bake is scoped to the data model session and does not survive into a playtest, and an API key must be set via the `cloud` command. This is far beyond what the annotations convey.

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

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

For an 8-operation, 30-parameter tool, the length is largely earned and each paragraph is scoped to one operation, with safety-critical guidance front-loaded. It loses a point for editorializing asides ('the raw percentage lies', 'the oldest hazard on the platform') and for restating schema content such as the `restart` behavior, which already appears in the restart property.

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

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

Given the tool's breadth, the absence of an output schema, and only one required parameter, the description covers everything an agent must know: which op to pick, the auth prerequisite, quota/moderation caveats, irreversibility, and sibling routing (e.g. audio ids belong in `audio op="graph"`). Nothing material is missing.

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

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

Schema coverage is 100% and the schema descriptions are already rich, so the baseline is 3. The description adds genuine non-schema meaning: the filters are applied client-side with multiple pages fetched, Roblox's own sort/creator filters are accepted and silently ignored (so they are deliberately not exposed), and minVotes/minDuration exist to correct for vote-count and duration skew.

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 enumerates eight distinct operations with specific verb+resource pairs ('search looks through...', 'insert puts one into the place by id', 'publish sends a .rbxl or .rbxlx from disk to a place') and even calls out that 'bake' is unrelated to the Creator Store. An agent can identify each capability and distinguish it from siblings like 'audio', 'generate' and 'universe' 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?

It gives explicit when/when-not rules and named alternatives: check `hasScripts` before inserting, use `peek` when scripts are present but the model still looks worth having, ask `op="quota"` before a batch, do not upload speculatively. It also states when `grant` is NOT needed ('You do NOT need this for your own assets in your own game').

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

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

Annotations already declare destructive/openWorld/non-idempotent, so the bar is lower, and the description adds real value on top: the silent-failure mode ('completely silent, with no error anywhere'), that pin-name validation happens before wiring, that 'inspect' surfaces Connected = false links the Explorer hides, and that 'graph' runs in one undoable step. It never states what mutation is destructive, which keeps it from 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-loaded with the one-line summary and then the mental model, and every paragraph carries information (ops, failure mode, alternatives). It is somewhat long and ornate for a tool description, but the length is justified by 12 parameters and the subtle graph semantics.

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, and the description compensates by explaining what 'inspect' returns (every connection, including false ones). It covers the domain model, the three ops, and the parameter concepts well enough that an agent can call it correctly on a complex 12-parameter 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 100%, so a 3 is the baseline. The description nonetheless adds conceptual meaning: it frames pin names, direction and sink choice as 'where it actually goes wrong', explains the world-vs-ui sink distinction, and justifies omitting 'path'/'asset'. That is more than repeating 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 specific verbs and resources for each op — 'graph builds a whole working chain', 'wire joins two existing instances', 'inspect reads a graph back' — and frames the tool as building/inspecting the modern audio API. It distinguishes itself from the sibling 'create' tool explicitly, so an agent can tell them 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?

Gives explicit when-to-use per op ('graph is the one to reach for', 'wire joins two instances you already have', 'inspect reads an existing graph back') and names the alternative: 'The old Sound instance still works... use create for that. Come here when the case needs effects, per-listener mixing, or one emitter fed by several sources.' When-not guidance is present.

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

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

Annotations only declare generic flags (readOnlyHint=false, openWorldHint=true, destructiveHint=false, idempotentHint=false). The description adds real behavioral context beyond them: `kill` exercises the death/respawn path, `teleport` skips triggers and collisions, `moveTo` reports whether it ACTUALLY ARRIVED and how far short, and a running playtest is required. This is materially more than the annotations convey.

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

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

Front-loaded with the core purpose, then well-paragraphed by op and by sibling routing; almost every sentence carries actionable detail. Slightly long and a few clauses are decorative ('which is how combat gets tested'), keeping it short of 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?

For a 17-parameter, multi-mode tool with openWorld semantics and no output schema, the description covers the operational context an agent needs (preconditions, mode selection, sibling routing, key side-effect caveats). It stops short only on how `state`/`path` results are shaped, which the missing output schema would otherwise have to cover.

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 and the schema already carries the per-parameter documentation. The description nevertheless adds cross-parameter semantics that the schema alone doesn't: teleport-vs-walk trade-offs, the equip/activate chain as the combat-test path, and the `costs` avoidance intent. That is worth one step above baseline.

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 concrete verb+resource (drives the player character during a running playtest) and enumerates its `op` modes with distinct purposes. It explicitly distinguishes itself from the `input` sibling for control-bound tests and from `playtest op=play` for entering run mode.

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 routing: use `input` for anything bound to a control rather than movement, walk rather than teleport when testing triggers/collisions, call `state` before and after anything else, and note it requires a running playtest with the playtest's studioId, not the editor's.

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

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

Annotations declare destructiveHint=true and idempotentHint=false but say nothing concrete; the description supplies the specifics an agent needs — groups are not undoable, not session-scoped, the built-in Default group cannot be removed, and a same-named group in a WorldModel is a different group. It also discloses that a wrong collisionGroup yields a plausible-but-wrong answer and that a miss returns hit:false.

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 and organized into clear conceptual blocks, and every section is relevant. It is on the long side for a single description and includes persuasive flourishes ('Geometry wrong in exactly those ways looks perfect in inspect') that, while justifying the tool, 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 23-parameter, seven-action tool with no output schema, the description covers the group lifecycle, the world-vs-place scoping, the query semantics and their failure modes. An agent has enough to select the right action and interpret a null/false result without further inference.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds genuine conceptual meaning beyond the schema — the create/assign/collidable ordering, that assigning a Model assigns every part inside it, that an empty group does nothing, and that collisionGroup is 'required for a truthful answer.' It stops short of per-parameter detail, but the added semantics exceed the schema's field-level docs.

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 ('controls which parts physically collide with which') and explicitly covers the tool's two halves: group management (create/assign/collidable/remove) and collision queries (cast/overlap). An agent can distinguish it from siblings like inspect, tree, or geometry because the description names exactly what unique question it answers.

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 routes between alternatives: use groups rather than turning CanCollide off, which 'disables collision against everything.' It gives the ordering (create → assign → collidable), the when-to-remove rule, the worldModel-vs-Workspace condition, and the cast-vs-overlap choice. This is close to exhaustive when/when-not guidance.

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

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

Annotations already cover the read-only/idempotent safety profile, yet the description adds substantial behavior beyond them: cursor is session-and-player scoped, 2000-line eviction, late stack traces reappearing as 'update', drain-mode cursor semantics, and the caveat that silence is not an all-clear. This is exactly the extra context annotations cannot carry.

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?

Long (nine parameters, dense caveats), but front-loaded with the purpose and mostly earned sentences. Some repetition exists — session isolation is stated twice and the closing paragraph on Studio-emitted messages runs long — which keeps it off 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?

With no output schema and nine parameters, the description still covers return semantics (nextCursor, update marker, evicted/skipped lines reported) and the multi-session model an agent must understand to target the right log. Nothing essential 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 100% so the baseline is 3, but the description goes further: it explains that cursors belong to one session/player, that filters must stay stable while draining, and that a filter beats a large limit. It doesn't restate every enum, which the schema already handles, so 4 rather than 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?

States a specific verb and resource ('Reads Studio or playtest client output — prints, warnings and runtime errors') and immediately distinguishes itself from siblings execute_luau and script_read by positioning itself as the way to see what happened after a run. An agent can tell it apart from script_read/script_grep 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?

Explicit when-to-use ('after a playtest or an execute_luau call'), when to choose target="client" vs the editor log, when to filter vs raise limit, and a clear boundary case ('check the Output window yourself, or ask the user'). Alternatives and their selection conditions are 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?

Beyond the annotations, the description adds valuable behavioral context: creation happens "as one undoable step," nested builds are "both faster and safer," and property names are validated against the live Roblox API dump before anything is sent to Studio. It also explains why child creation is safer, which helps the agent reason about failure modes. No contradiction with the annotations.

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

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

The description is compact and well-structured: one sentence for purpose, one paragraph for nesting strategy, one for API validation, and one for the sibling tool. Every sentence earns its place and no information is redundant with the schema.

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

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

For a complex creation tool, the description covers the key operational contexts: nesting, undo behavior, validation, and script-specific routing. The rich schema and annotations handle the parameter-level detail. The only minor gap is that with no output schema, the description does not describe the return value, though for a create operation this may be self-evident from Studio context.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining the rationale for `children` (paths are not knowable until existence, same-named siblings make guessing unreliable) and by framing properties/attributes/tags as set-at-creation. It does not repeat parameter syntax, which is already well documented in the schema.

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

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

The description opens with a specific verb and resource: "Creates instances with their properties, attributes and tags set at creation, as one undoable step." It also differentiates from the closest sibling by saying "Use `script_create` for Script, LocalScript and ModuleScript," so an agent can distinguish this tool from script creation without opening either 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 gives explicit when-to-use guidance: build whole models in one call via `children`, and avoid the separate create-then-address pattern because paths are unknowable until creation. It also names the exact alternative for scripts (`script_create`) and the condition for choosing it. This is concrete, actionable 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?

The description goes well beyond the annotations, disclosing that writes on kind='data' cannot be undone, that confirm: true is required, that DataStore needs a Studio API access setting, and that live snapshots are limited to one per UTC day while still reporting success on duplicate calls. There is no contradiction with the annotations.

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

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

The description is long but every section earns its place for an 18-parameter, dual-target tool. It is front-loaded with the core purpose and sibling differentiation, then moves through workflow, safety warnings, authentication prerequisites, live targeting, ordered stores, and snapshot limits in a labeled, scannable structure 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 tool with no output schema, it is remarkably complete: it covers preconditions, auth requirements, live vs studio behavior, per-kind constraints, failure wording, the snapshot safety net, and the exact workflow needed to diagnose lost progress. An agent has enough context to invoke every operation correctly and know what to expect.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds substantial operational meaning around parameters: the meaning of kind, the behavior of target='live', the confirm requirement, the read-before-write advice for value, and the special semantics of op='snapshot'. It does not repeat every schema field, which is appropriate given the schema already documents 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 opens with a specific verb and resource: 'Reads and writes the game's saved data — DataStore and MemoryStore.' It then distinguishes itself from all sibling tools by saying it is the only tool that looks outside the place file, answering a different question than 'is the instance right'.

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 guidance on when this tool is appropriate versus every other tool, and further divides usage between studio and live targets. It also outlines a concrete bug-report workflow: list stores, list keys, get the player's key, then versions and get with a version to see the prior state.

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

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

The description discloses many non-obvious behaviors beyond annotations: breakpoints fire once per run, log expressions cannot see loop control variables, a breakpoint on a return/end may never fire, and set can return Verified even when the log expression later throws. It also clarifies that capture breakpoints resume themselves and never leave Studio frozen. This far exceeds what annotations alone provide.

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

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

The description is long but front-loaded with the core purpose and organized into thematic paragraphs covering limitations, parameters, and remotes. Some illustrative anecdotes and repeated 'measured, not guessed' phrasing add bulk, so it is not maximally concise, but the length is largely justified by the tool's complexity.

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

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

Despite having no output schema, the description covers what each operation returns: snapshots returns captures, set returns Verified, and remotes returns counts, calls/sec, and argument-shape samples. It also explains truncation, session scoping, and the need to set breakpoints before playtesting. For a tool with 10 parameters and multiple modes, nothing essential is missing.

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

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

Schema coverage is already 100%, but the description adds crucial meaning: condition must be a Luau expression, logMessage is also a Luau expression rather than a template string, prose causes syntax errors, and line placement affects whether a breakpoint fires. This significantly deepens an agent's understanding of how to correctly set parameters.

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

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

The description states a specific verb and resource: it sets breakpoints that record stack and variables, then reads back captured snapshots. It also differentiates itself by explaining these are tracepoints, not a step debugger, which separates it from sibling inspection tools. The first sentence alone gives an agent a precise mental model.

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 when-to-use guidance, e.g., 'Reach for the log when you know what to watch, the capture when you do not.' It also names an alternative, console, for loop-by-loop value watching, and warns against using breakpoints for stepping. This is exactly the kind of routing information an agent needs.

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

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

Annotations already mark the tool as destructive and non-idempotent that the description reinforces by saying 'Destroys instances and everything inside them.' Beyond that, the description adds crucial behavioral details: it is undoable, it returns a descendant count, services are refused, and paths shift after deletion. This goes well beyond the annotation hints. Slight deduction because it doesn't mention authorization or rate limits, but those are not expected for this tool type.

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

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

The description is concise and front-loaded: the first sentence captures the primary purpose)Skip subsequent sentences add exactly the details an agent needs (consequences, constraints, and pre/post-recommendations) without fluff. Each sentence earns its place, and the structure flows from the what to the how to the caveats.

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

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

Given there is no output schema, the description compensates by telling the agent what to expect in the response (descendant count). It also covers the major edge cases (services, path invalidation). It doesn't specify the exact format of the response or error cases, but for a destructive tool this is sufficient. A slight extra note about what happens on invalid paths (e.g., not found) would be helpful, but overall it's complete enough for an agent to use it correctly.

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

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

The schema already covers both parameters (paths and studioId) fully (100% coverage), so the baseline is 3. The description adds value by warning that paths are volatile and must be re-read before a second delete, and that services are refused. That's behavioral context on the 'paths' parameter beyond the schema's type/item description, making it more useful for correct invocation.

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

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

The description opens with a specific verb and resource: 'Destroys instances' as one undoable step GOVERNED by one verb. It clearly distinguishes itself from the many sibling tools (create, modify, move, etc.) by focusing on destruction and by noting what it does NOT do (services cannot be deleted). Any agent can tell this is the delete operation without reading 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 gives concrete usage guidance: it tells the agent to check the response's descendant count, to avoid deleting services, and to re-fetch paths from find/tree after a deletion because paths shift. This substantially helps the agent sequence operations. It doesn't explicitly say when NOT to use this tool relative to alternatives (e.g., vs. move or modify), but it does give clear operational guidance for correct use, so it earns above average.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the bar is lower, yet the description adds real side-effect context: `stop` restores the editor viewport AND clears network shaping, and a leftover device/network shapes every later screenshot invisibly. It does not restate reversibility explicitly, which keeps 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 core action is front-loaded in the first sentence, and the paragraph-per-op structure is easy to scan. Several passages are rhetorically padded ("A menu that works at 0ms is not evidence that it works at 300"), so it is longer than strictly necessary for an 11-param 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?

With no output schema and 11 optional params, the description carries the load well: it covers the workflow, the effect of each mutating op, network shaping rationale, and cleanup. The gap is the unmentioned `state` op and the absence of any indication of what `list`/`state` return.

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

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

Schema description coverage is 100% (baseline 3), and the description still adds value by expanding the `preset` table, explaining the `loss` cap and the `direction` in/out semantics narratively, and giving per-op meaning for `list`/`set`/`network`/`stop`. It omits the `state` op entirely, so one enum value is undocumented in prose.

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

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

The description names a specific action and resource ("Resizes the Studio viewport to a real device") and separates its four sub-operations. It does not, however, differentiate itself from the closest sibling, `viewport`, which an agent must still disambiguate by 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 states the workflow explicitly (`set` → `screenshot` → look), names companion tools (`playtest` for a running game's HUD, `screenshot`), and gives an imperative cleanup rule (run `stop` when finished) with the cost of skipping it. The sequencing and alternatives leave little to inference.

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

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

The description carries an enormous amount of behavioral disclosure well beyond the readOnlyHint/destructiveHint annotations: input is not validated, writes may not be undoable as one step, no timeout on target='studio' (infinite loop hangs Studio), output caps (200 lines, 10 returns, table depth 4), the module-cache duplicate-copy problem with require, loadstring being disabled on playtest servers, relay cleanup, and the live-data danger requiring confirm. This all aligns with destructiveHint=true and readOnlyHint=false — no contradiction.

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 long, but length is justified for an escape-hatch tool that can hang a Studio session or mutate live production data. The highest-stakes warnings ('BE CAREFUL WITH IT', the live-data danger, confirm requirement) are front-loaded and surfaced in caps; each paragraph covers a distinct concern (usage, output, require caveat, per-target behavior) with no redundancy. Slightly more than needed, but every sentence earns its place given the blast radius.

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 wildly variable return values, the description must explain return behavior on its own — and it does: print is captured and returned, return works for tables as structures, output caps are specified, and live returns a state of COMPLETE/FAILED rather than a bare value. It covers all three target modes, their prerequisites (running playtest server, published place), the exact caveats for each, and the confirmation flow. Nothing an agent needs to invoke this safely is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds substantial semantic depth beyond the schema: it explains what each target actually means in practice ('live' runs against the PUBLISHED place with no undo; 'client' runs in the player's playtest VM with a live require cache), why confirm is mandatory for live, what timeouts imply, and that source carries plugin permissions. This meaningfully exceeds what the schema's property strings convey.

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 ('Runs Luau in Studio's plugin context') and immediately frames it as 'the escape hatch' — the tool you reach for when dedicated tools don't fit. It explicitly names the siblings it is not (create, modify, delete, move, script_edit, find) and contrasts its behavior against them. An agent can unambiguously distinguish this from every one of the 34 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 explicit when-to-use guidance ('reading something no tool exposes, a one-off calculation, calling an engine API the tools do not cover') and when-not-to ('only when no dedicated tool fits'). It further sub-divides usage by target: 'live' is for production reads/repairs, and it warns against using require for live state. No other tool in the sibling list gets this level 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld). The description still adds non-obvious behavior: tag searches are served from CollectionService's index rather than a tree walk (fast on large places), selector matching runs in C++ with only survivors returned, and results can come back TOO_BROAD. It does not discuss result shape or pagination beyond what the schema's cursor implies.

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

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

Front-loaded with the core purpose, then layered paragraphs each carrying distinct operational advice. It is long for a description but nearly every sentence provides selection or invocation value, with no boilerplate.

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, no-output-schema search tool, the description covers the conceptually hard parts: filter composition, the tag-discovery workflow, and selector's syntax boundaries. The remaining parameters (limit, cursor, detail, studioId) are fully specified in the schema, so the definition 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 100%, so baseline is 3, but the description meaningfully extends it: it explains that all supplied filters are ANDed, that selector has no substring or < > comparisons (pushing those to nameContains/propertyValue), and why op="tags" exists. It does not add semantics for limit, cursor, detail, or studioId, but those are already fully documented.

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 (searches) and resource (the data model) with the exact filter axes (name, class, property value, tag), and explicitly names the sibling it replaces and the one it supersedes (`tree`). An agent can select it 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?

Gives explicit routing rules: prefer over `tree` when you know what you are looking for, call op="tags" before filtering by tag on an unfamiliar place, and reach for `selector` when tree shape is the question. It also names the fallback (nameContains/propertyValue) when selector cannot express the query.

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

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

Beyond the annotations, the description discloses latency ('tens of seconds per call'), metering/moderating failures, anchoring on arrival, edit-mode-only persistence, and the emptiness of MeshContent/TextureContent in playtests. None of this contradicts the annotations.

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

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

The definition is long but every sentence carries operational value, and the structure uses a clear opening, bullets, and bolded warnings. It front-loads the most important argument (schema) and organizes limitations so an agent can use it without rereading.

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 generative tool with no output schema, the description covers purpose, schema selection, failure modes, retry behavior, anchoring, edit-mode limitations, and related tools. No critical operational gap remains.

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

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

Schema description coverage is 100%, but the description adds substantial meaning: it explains `Body1` vs `Car5`, fixed wheel names, `groups` as an override, `imageAssetId` conditioning, and the faceted effect of low `maxTriangles`. This goes well beyond the schema's field descriptions.

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

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

The opening line, 'Makes 3D geometry from a text prompt,' states a specific verb and resource, and the rest of the description elaborates on the kinds of geometry and schemas. It is clearly distinct from siblings like `geometry` or `assets`, which are operation/modification tools.

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

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

The description gives explicit when-to-use guidance for each schema ('Right for props', 'Right for anything that has to drive'), tells the agent to 'generate for building and greyboxing', and names alternatives such as `geometry op="segment"` for post-hoc cutting and `assets op="bake"` as a non-fix. It also conditions expectations around rate limits and retries.

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

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

Beyond the destructive/openWorld/idempotent annotations, the description discloses non-obvious failure semantics ('intersect' errors on no overlap while 'subtract' silently returns an unchanged full-size copy), ownership refusal on foreign meshes with per-part skip reporting, that material/colour/texture/anchoring are preserved, that mirror copies by default, that 'segment' takes tens of seconds, and that each call is one undo 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?

It is long for a description, but for an eight-op / 28-parameter tool most sentences carry distinct caveats, and bold group headers make it skimmable and front-loaded. Minor waste comes from restating schema defaults verbatim ('It COPIES by default; pass `copy: false`') and from prose that repeats default-value behavior already in the schema.

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

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

For a high-complexity, multi-operation, destructive tool with no output schema, the description covers op selection, failure modes, side effects, permission limits, latency, and undo behavior. An agent has enough to choose an op and anticipate the result's shape and risks without further context.

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 already 100%, so the baseline is 3, but the description adds op-level parameter interaction that the flat schema cannot: that `groups` overrides `schema`, that `checkAgainst` reports overlaps and `keep: false` measures then cleans up, and how `spin`+`pivot` compose for a hinge. It stops short of covering the generic plumbing params (`parent`, `studioId`, `name`), which the schema handles alone.

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 tool's domain (reshaping solid geometry) and then enumerates all eight operations with a specific verb+resource for each, grouped under Boolean/Breaking apart/Motion/Read/Mirror headings. An agent can tell which `op` value maps to which intent without opening the schema, and siblings like `inspect` and `modify` are named where relevant.

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 routing guidance is given for overlapping ops: 'Use `fragment` for rubble and `segment` for articulation', `sweep` for 'does this door hit the wall', and 'check the positions overlap with `inspect` first' before relying on `subtract`. When-not conditions are also stated, e.g. mesh only works on meshes the user owns, and mirror exists because Studio has no engine API for it.

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?

Even with annotations present, the description adds a large amount of behavioral context: reserved keys are refused with a warning, steps execute in order, delivery is confirmed by the client before success is reported, failure produces an error, and input is parented into the client's PlayerGui. It also discloses pointer drawing, viewport measurement pitfalls, and emulated-device distortion, all beyond what the annotations state.

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 long but appropriately so for a high-complexity tool with no output schema. It is front-loaded with the core purpose and then organized into clearly motivated sections covering alternatives, reserved keys, sequencing, client execution, pointer behavior, screenshot timing, and text focus — each of which earns its place by preventing a likely misinvocation.

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

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

Given the tool's complexity, 4 parameters, and absent output schema, the description is remarkably complete. It covers prerequisites, return and error semantics, ordering, coordinate systems, failure modes, and interactions with siblings like `character` and `screenshot`, leaving no critical gap an agent would need to guess about.

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?

Although schema coverage is 100%, the description adds meaning well beyond the schema: x/y are viewport pixels from the top-left, `after` and `hold` control sequencing and duration, `target` focuses TextBoxes, `cursor` defaults to on so users can see synthetic input, and `text` types into the focused TextBox. It even explains coordinate discrepancies between the reply's `landed` and viewport pixels so the agent does not treat them as an error.

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 states a specific verb and resource: sends real keyboard and mouse input to a running playtest, producing the same events as a person. It also explicitly distinguishes itself from the sibling `character` tool by contrasting 'can it get to the door' with 'does pressing E open it', so an agent can tell them apart without opening schemas.

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

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

The description gives explicit selection guidance: use `character` for movement and this tool for controls, and pair it with `screenshot` for coordinate targeting. It also specifies the prerequisite of a running playtest and warns that the playtest's studioId from `list_studios` must be used, not the editor's.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is low, and the description clears it with non-obvious behavior: bad paths do not fail the call, they are returned under `failures` while valid instances still resolve. That partial-success contract plus the cost profile of the 'full' detail level and the live API-dump sourcing are exactly the kind of context an agent cannot get from the annotations.

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

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

Front-loaded with the core action, then the batching advice, then a scannable breakdown of the three detail levels, then the failure semantics. Every paragraph carries information, though the API-dump justification sentence is slightly more explanation than the agent strictly needs to make the call.

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 six parameters, full schema coverage and a complete annotation set, the description fills the remaining gaps: it covers the detail-level tradeoff, batching strategy, and one failure key in the response. It is nearly complete, but with no output schema it still leaves the overall response shape to inference beyond the mention of `failures` and the child listing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: it explains that property selection is derived from the live Roblox API dump for each instance's actual class and stays correct across engine updates, and gives a concrete example of what 'standard' yields for a Part (Size, Position, CFrame, Anchored, Material).

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 set: 'Reads properties, attributes, tags and children of one or more instances', which tells the agent exactly what comes back. It is clear and self-contained, but it never names or contrasts itself with the read-oriented siblings (tree, find, script_read), so the agent must infer the boundary from the schemas of those tools.

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

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

Gives real usage context: batch every path into one call because batching costs one round trip instead of N, and warns that 'full' is expensive and should be limited to one or two instances. It stops short of naming an alternative tool or stating an explicit when-not-to-use-this case (e.g. when 'tree' is the better choice).

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

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

Annotations already mark readOnly, idempotent, non-destructive. The description adds crucial behavioral nuances not captured in annotations: 'Each Studio is queried live, so placeName is the published name,' and the playtest context explanation that a second entry appears and its changes are thrown away. It also clarifies that 'no Studio is targeted by default when multiple are connected,' which is a behavioral surprise. No contradiction with annotations.

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

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

The description is somewhat long but well-organized into four paragraphs that each serve a purpose: listing result details, usage guidance, default targeting, and the playtest caveat. It front-loads the main action and then adds usage nuances. No redundant filler, though it could be tightened slightly. Still, for a tool with multiple gotchas, the length is justified.

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

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

Given there is no output schema, the description does the job of explaining return values. It covers the fields returnedholistically. It also covers edge cases (never-saved place name, playtest context) that are essential for correct interpretation. It clearly distinguishes when to use this vs set_active_studio. Fully 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?

There are zero parametersaine; schema description coverage is 100%. The description explains the output structure and the meaning of each field (studioId, placeName, transport, connected time) and the context field. Since there are no params, the description is the sole source of semantic meaning, and it fully explains the tool's behavior.

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

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

The description begins with a precise verb and resource: 'Lists every Roblox Studio window currently connected to this server,' then enumerates the exact fields returned (studioId, placeName, transport, connection time). It differentiates from siblings like set_active_studio and studio_status by explaining its role in discovery and the default targeting behavior.

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 states when to call it: after AMBIGUOUS_STUDIO, or when the user references 'the other place'/'my other window'. It also tells when NOT to call it (single Studio open, because others auto-target), and describes the workflow: default is no targeting, so pick with set_active_studio or pass studioId. This is clear decision guidance.

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

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

Beyond the annotations (destructiveHint, readOnlyHint), the description discloses important behavior: the batch is one undoable step, it is all-or-nothing, rejected values cancel the recording and revert every instance, and one entry can apply the same change to many instances. This gives agents an accurate model of side effects and failure semantics.

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 paragraphs, each with a distinct job: core purpose, batch path behavior, atomicity, and notation/alternative tool. The main capability is front-loaded and every sentence earns its place.

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

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

The description covers the essential operational context: batch semantics, failure atomicity, value notation, and the script_edit alternative. There is no output schema, but for a mutation tool the absence of a return-value description is acceptable. Slightly more could be said about success/error responses or prerequisites, but the definition is strong overall.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that values use the same notation as the Properties panel, that one entry can apply a change to many paths, and that attribute values may need a { type, value } wrapper. These clarifications augment the schema rather than repeat 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?

The description opens with a specific verb and resource: 'Sets properties, attributes and tags on existing instances.' It clearly distinguishes itself from siblings like create, delete, and move, and later explicitly distinguishes itself from script_edit. No ambiguity remains about what the tool operates on.

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

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

The description gives clear guidance: use it to set properties/attributes/tags on existing instances, combine with find to build path lists, and use script_edit instead for changing a script's code. It doesn't enumerate when to prefer create/delete/move, but the scope is clear enough for an agent to route correctly.

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

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

Annotations already mark destructiveHint=true and readOnlyHint=false, so the description doesn't need to restate that. It adds valuable behavioral context beyond annotations: the operation is undoable ('one undoable step'), and it discloses a critical edge case ('Moving an instance into itself or its own descendant is refused: it silently detaches... and undo does not bring it back'). This is genuine extra information that changes how an agent should call it.

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 (two short paragraphs) and front-loaded with the core purpose. Every sentence earns its place: purpose, mode distinction, and a critical caveat. The critical edge-case warning is placed at the end, clearly separated, which is appropriate since it's a warning rather than primary instruction.

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 2 parameters, 100% schema coverage, and no output schema, the description covers everything an agent needs: what it does, how to switch modes, what happens on an invalid self-move, and that it's undoable. The annotations cover the destructive nature. Nothing critical is missing for correct invocation.

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

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

Schema coverage is 100% (all parameters have descriptions in the schema), so baseline is 3. The description adds extra value by explaining the mode semantics ('Set mode: clone to copy instead of move') and tying the 'name' parameter to the clone use case ('optionally renaming it in the same call'). It also explains the 'items' array semantics ('Moves to apply together as one undoable step'). This goes beyond the schema descriptions.

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

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

The description clearly states the tool's core function ('Reparents instances, or clones them into a new parent, as one undoable step') and explicitly differentiates 'move' vs 'clone' modes. It names what it operates on (instances) and the key action (reparent or clone), distinguishing it from siblings like 'create', 'delete', or 'modify'.

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

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

The description gives clear context for when to use clone ('that is how to duplicate something') and implies the main use case for moving. It doesn't explicitly list sibling alternatives or say when NOT to use this tool in favor of others, but the context and mode explanation provide useful guidance.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), but the description adds substantial behavioral context beyond them: `profile` blocks for `seconds`, instrumentation is fixed at compile time and per-data-model, place-starting scripts report 0 lines as unmeasurable, `audit` deliberately surfaces asset load errors in Output, and frame/network figures are only meaningful while running. It even discloses that `enable` is remembered for the place and re-applied by future sessions, a persistent side effect worth flagging.

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 long, but it is organized as op-labeled paragraphs front-loaded with the tool's role, and most sentences carry load-bearing detail. A few clauses (e.g. the restatement of camera-dependence) could be tightened, so it falls just short of fully 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?

With no output schema, the description carries the return-value burden and does so for every op: snapshot's counters, profile's CPU consumers, coverage's executed lines, scene's categories/triangles/assets/unparented, and audit's dead references. Given the tool's complexity and 7 parameters, nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents each parameter and the baseline is 3. The description nevertheless adds workflow meaning the schema lacks — the enable→play→read-back-from-playtest ordering, the per-data-model instrumentation caveat, and the camera-framing dependency for `scene` triangles — which raises it above baseline.

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 concrete verb+resource and then differentiates all five ops (`snapshot`, `profile`, `coverage`, `scene`, `audit`) with distinct purposes. It explicitly positions itself against siblings, noting unparented instances are 'invisible to `find` and to `tree`,' so an agent can separate this tool from those 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 explicit when/when-not and sequencing for each op: start a playtest before `profile`, pass `enable` first then play then read coverage from the playtest session, point the camera with `viewport op="focus"` before `scene`, and compare views only if framed identically. It also states the condition that selects `audit` over 'play the game and notice something missing.'

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?

Far exceeds the annotations (destructiveHint, idempotentHint, openWorldHint): it discloses that stopping discards all playtest changes, that the call is non-blocking, that EndTest's value surfaces as lastResult, that play/multiplayer return a studioId, connection-timeout behavior, and the permission/lock model including an explicit anti-bypass warning.

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 op semantics, then behavior, then permission rules, and every section is functional. It is on the long side (~300 words), but the tool has six ops plus a permission lock, so the length is largely justified rather than 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?

With no output schema, the description carries return-value disclosure itself: studioId on connect, the state reached, and lastResult on a later state call. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100% so the schema already documents each param, but the description adds meaning beyond it: the returned studioId is linked to downstream tools (console, performance, execute_luau), and args is framed as the way to tell a test which case to exercise.

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 (starts/stops playtests) and enumerates each op's distinct effect (play spawns a character, run executes scripts with no player, multiplayer/addPlayers manage multi-player tests, state reports only). It is clearly distinguishable from siblings like execute_luau and list_studios.

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 describes when each op applies and when not: build in edit mode then play, use studioId for console/performance/execute_luau, and use edit-mode tools when `playtests off` locks starting simulation. Names the alternative behaviors (state/stop remain available) and exclusions (lock only blocks starting simulation).

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds valuable behavioral context: it captures the user's current camera angle (not agent-controlled framing), playtest captures are slower, require editor window connection, and are labeled 'playtest client'.

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?

Well-structured with three focused paragraphs: purpose, usage context, and playtest specifics. Front-loads the core function. Slightly verbose in places but every sentence adds value - no obvious 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?

Covers the essential aspects: what it does, when to use it, the key limitation (user's camera angle), how to frame subjects, and playtest behavior. With no output schema, it explains that it returns an image. Could mention resolution limits tied to width parameter more explicitly, but that's in the 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 coverage is 100%, so parameters are fully documented in the schema. The description mentions `viewport op="focus"` for framing and playtest's studioId usage, but doesn't add significant meaning beyond what the schema already provides for each 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 specific verb+resource ('Takes a picture of the Studio viewport'), and explicitly distinguishes itself from all sibling tools by noting 'Every other tool here reads the data model'. The agent immediately understands this is the only visual verification 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?

Clearly states when to use it ('after building something visual, and before reporting that it worked') and mentions playtest usage context. However, it doesn't explicitly name sibling alternatives like `inspect` or `tree` for when the agent needs data rather than visuals, though the distinction is strongly implied.

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

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

The description goes well beyond the annotations by disclosing that batch creation happens inside a single ChangeHistoryService recording, that Studio may refuse to open another recording, what the response indicates, and how Studio's warning output behaves for `LocalScript` in starter containers. These are meaningful behavioral details not available from the annotations alone. No contradiction with annotations.

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

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

The description is front-loaded with the core purpose, then adds the batching/undo behavior, then the nuanced script-type guidance, and finally the sibling routing. Every sentence carries meaningful information and none is redundant with the schema or annotations.

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

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

For a creation tool with no output schema, the description covers the most important runtime caveats: undo batching, recording refusal, starter-container behavior, and warnings. It could be slightly more complete by describing the full response shape or error behavior, but the essential invocation context is present.

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

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

Schema coverage is 100%, so the schema already documents all parameters; the baseline is 3. The description adds valuable semantics for `className` and `runContext`, explaining where `LocalScript` actually runs and how starter containers behave. It does not cover `source`, `disabled`, `parent`, or `studioId`, but those are already described in the schema.

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

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

The description opens with a precise verb and resource: 'Creates Script, LocalScript or ModuleScript instances with their source.' It clearly distinguishes itself from the sibling `script_edit` by naming it directly, and the restriction to script classes separates it from the generic `create` sibling.

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

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

It gives explicit routing guidance: 'Use `script_edit` to change a script that already exists.' It also provides strong contextual guidance on when to prefer `Script` with `runContext: "Client"` vs `LocalScript`, including the starter-container exception. However, it does not mention the generic `create` sibling or when that should be used instead, so the alternative-selection guidance is not fully complete.

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

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

The description goes far beyond annotations, detailing all-or-nothing batch semantics, mode-specific failure conditions (non-unique find, STALE_SCRIPT), revision-based concurrency control, writes through ScriptEditorService with undo behavior, live vs studio differences, and effects on running servers. It even explains that `source` discards user changes. No contradiction with annotations; instead it enriches them.

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

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

The description is long but every sentence earns its place—no filler. It is front-loaded with the core purpose, then systematically covers batch behavior, modes, revision, live target, and server effects. The structure is logical and scannable, with clear section breaks.

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

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

Given the tool's complexity (multiple modes, live vs studio, concurrency), the description is remarkably complete. It covers failure modes, undo scope, server rollout, prerequisites, and even notes the returned `rev` for follow-up edits. There is no obvious gap an agent would need to fill.

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?

Even though schema coverage is 100%, the description adds critical meaning: it explains how modes correspond to parameter combinations (find/replace vs startLine/endLine vs source), clarifies `revision` as a concurrency guard, warns about `replaceAll` behavior, and describes `target="live"` constraints. It turns raw parameter descriptions into actionable 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 ('Edits Luau source through the Studio script editor') and explicitly frames it as the tool for any change to existing code, which clearly distinguishes it from script_create (new scripts) and script_read (reading). The purpose is unambiguous and context-aware.

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 when-to-use guidance ('any change to existing code'), explains the three edit modes with conditions for each, advises to batch related changes, and names the alternative tool (script_read) for reading. It also specifies when to use `target="live"` and prerequisites like `confirm: true`. Nothing is left to inference.

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

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

Annotations already cover safety (readOnlyHint, destructiveHint=false, idempotentHint). The description adds valuable context: results come from the live editor buffer and include unsaved edits; results are grouped by script with a rev that script_edit accepts. This cross-tool hint is beyond what annotations provide. Lacks pagination/cursor behavior detail but implies it via 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-loaded with the core verb/resource/return shape, then usage, then pattern semantics, then multi-pattern behavior, then result grouping and cross-tool link. Every sentence earns its place with no filler.

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

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

Given 11 params, no output schema, and rich annotations, the description covers what the agent needs: when to use, pattern language differences, identifier-search guidance, result grouping format, and a cross-tool link (rev → script_edit revision). Nothing important is missing for correct invocation.

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

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

Schema description coverage is already 100%, so baseline is 3. The description adds meaningful semantics on top: Lua patterns are not regex with specifics about %, alternation, and lazy quantifier; literal mode advice; multi-pattern single-pass guidance with max 16. This goes beyond schema descriptions and materially helps correct usage.

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 (Searches) and resource (Luau source across the place), with a clear description of what it returns (matching lines with paths and line numbers). Differentiates from siblings by positioning it as cheaper than script_read and references script_edit.

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 when to use ('find where something is defined or used before editing it') and implicitly when not to ('far cheaper than reading whole scripts'). Prescribes literal mode for identifiers and multi-pattern mode for several identifiers, giving concrete guidance across the alternatives available.

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

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

Annotations are sparse (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false), so the description carries the burden. It discloses that reading includes unsaved changes from the live buffer, that `open` modifies the user's editor view, and that live mode has real limitations (only Folders/scripts, GUID round trips, seconds). It also flags disk-bound scripts as a race. This goes well beyond what annotations provide.

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 long but every sentence earns its place. It front-loads the core purpose, then systematically covers the live buffer, multi-script batching, disk-bound race, `open` behavior, `target="live"` constraints, and `list`. The structure uses clear paragraphs and examples, making it easy to scan. No redundancy or filler.

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

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

Given the tool's complexity (10 parameters, multiple modes), the description covers all critical aspects: the live vs studio distinction, open vs read, line windows, defaults, list navigation, and output hints (line numbers for script_edit, disk-bound flag). It even notes the absence of output schema by implying return content. An agent can call this correctly without further clarification.

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%, but the description adds substantial meaning: it explains the default startLine/endLine behavior for entries without their own, the two entry formats (bare path vs object with window), the semantics of `open` (returns nothing, puts cursor at line), and the purpose of `list: true` for navigation. It also clarifies `target="live"` limitations that the schema only hints at. This is a model of parameter enrichment.

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

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

The description opens with a specific verb and resource: 'Reads Luau source from one or more scripts' and immediately ties it to `script_edit` by mentioning line numbers it accepts back. It clearly distinguishes from siblings like `script_edit` (editing) and `script_grep` (search) by focusing on reading. The mention of the live buffer vs saved property further clarifies its unique role.

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

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

The description explicitly advises when to use this tool: 'Pass every script you need in one call' and contrasts with reading the saved property to avoid stale code. It explains when `open` is appropriate ('when you are pointing at something they should see') and when `target="live"` is the right choice (checking deployed code). It also warns about the race condition for disk-bound scripts, giving clear 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?

Although annotations already indicate non-read-only, non-destructive behavior, the description adds substantial beyond-schema context: persistence until changed or disconnected, AMBIGUOUS_STUDIO refusal when no choice exists, per-connection state isolation, and the silent subagent retargeting hazard. This is rich disclosure of consequences beyond any structured field.

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

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

The description is longer than average, but it is front-loaded with the core purpose and usage, and every later paragraph covers a real behavioral consequence. The subagent warning is verbose but vital; a slight tightening would make it fully concise, so 4 rather than 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?

For a stateful selector with connection-scoped side effects, the description covers the full lifecycle: when to invoke it, what happens while multiple studios are connected, how state persists, and how it interacts with subagents. No output schema is needed, and nothing required to call it correctly is missing.

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

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

Schema description coverage is 100%, and the only parameter, studioId, is documented in the schema as coming from list_studios. The description reinforces the source and warns subagents to pass studioId directly, but it does not add new format, range, or default semantics beyond what the schema already states. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: it 'Chooses which connected Studio window every other tool targets by default.' It is immediately distinguishable from siblings like list_studios and studio_status because it names the selection role and the effect on other tools.

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

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

Usage is explicit: use after list_studios when several places are open, and again when the user asks to switch. It also gives a firm exclusion, telling subagents to pass studioId on each call instead of invoking this tool, which is exactly the kind of when-to-use vs. when-not-to-use guidance an agent needs.

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

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

Annotations already mark it read-only and safe, and the description adds behavioral limits and caveats: selection is capped at 50 entries, selected text at 400 characters, no focused-tab API exists, and it returns JSON. It also positions the call as the cheapest diagnostic for disconnection, which helps the agent interpret failures.

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 dense paragraphs front-load the tool's purpose in the first sentence and every subsequent sentence adds decision-relevant detail: sequencing, deictic interpretation, and truncation limits. No filler is present; the length is justified by the absence of an output schema.

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

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

The description covers what the tool returns, when to use it, how to interpret openScripts without a focused-tab API, and the truncation behavior that affects agents needing more data. Combined with the read-only annotations and schema-documented studioId, an agent has everything needed to call and interpret this tool correctly.

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

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

The single optional studioId parameter is fully documented in the schema itself ('Omit to use the active one'), so the description need not repeat it. The description adds no additional parameter-level meaning, but with 100% schema coverage the 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 opens with 'One-call snapshot of the connected Roblox Studio' and enumerates the exact fields returned: place name/id, edit/run/play mode, selection, open scripts, and data model size. This clearly differentiates it from siblings like list_studios and find by scoping it to the connected Studio session.

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

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

It explicitly instructs the agent to call this tool FIRST in any Studio session, on NO_STUDIO/TIMEOUT, and before/after playtest. It also gives a concrete alternative rule: for deictic requests, use openScripts data instead of searching the place or asking the user, and prefer tabs with a selection. This is the strongest possible usage guidance.

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

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

Annotations already flag destructive=true, non-idempotent, openWorld; the description goes well beyond that by disclosing exact destruction semantics ('deleting a file deletes the script, one Ctrl+Z in Studio'), trash/conflict locations ('.rbx-sync/trash', '.rbx-sync/conflicts/'), the first-sync no-delete guarantee, and the conflict-wins resolution rule. This is unusually rich behavioral disclosure 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?

The purpose is front-loaded and paragraphs are organized by concern (mirror, layout, ops, safety, build files, conflicts). It is long — roughly 350 words — and the trailing conflict-resolution paragraph could be folded into the earlier safety paragraph, but for an 8-op tool the length is largely earned.

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 9 parameters, 8 enum ops, no output schema, and destructive/open-world behavior, this tool has substantial complexity, and the description covers layout mapping, per-op semantics, deletion safety, conflict handling, and the export/build round trip. Nothing an agent must know before invoking it appears missing.

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

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

Schema description coverage is 100%, so the per-parameter baseline is 3, but the narrative adds meaning the enum text does not: it explains what `watch` does over time, how `prefer` interacts with conflicts, and the consequence of `rebind` ('almost never what you want'). It stops short of documenting `dir`/`studioId`/`files`/`paths` beyond what the schema already states.

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 concrete verb and resource ('mirrors the place's scripts into a folder on disk') and frames the whole workflow (edit locally, send back to Studio in one call). It is immediately distinguishable from siblings like script_read, script_edit, and modify, whose scope is single-script rather than folder-tree mirroring.

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 which op to reach for (`status` before destructive runs, `sync`/`pull`/`push` directionality, `watch` until `stop`) and routes verification work to siblings ('use playtest, screenshot, console and input to check the result'). It stops short of saying when NOT to use this tool versus in-place editing tools like script_edit, so it is clear context rather than full 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?

Beyond annotations (which already flag destructive/non-idempotent), the description discloses that `fill` applies all solids as a single undo step, that carving is done by filling with material Air (not a special mode), that `clear` on everything requires confirm=true, and that `stats` cannot report terrain location. It also warns about the 4-stud voxel quantization and that nothing thinner than ~4 studs survives — real behavioral constraints an agent cannot infer from the 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-loaded with a one-line summary followed by op-specific paragraphs; nearly every sentence carries actionable information. It runs long and a few clauses (e.g. the FillBall aside) are conversational, but the length is justified by the tool's four-op complexity.

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

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

With no output schema, the description steps in to cover return-relevant behavior (stats reports only whether terrain exists), the fallback for visualizing shape (screenshot), coordinate/units conventions, and the voxel-grid limitation. An agent has everything needed to choose an op and call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning: the per-shape parameter requirements (block/wedge need size, ball needs radius, cylinder needs radius+height), positions as the centre of the solid in studs, and the Air-carve convention. Much of this is mirrored in the schema descriptions, so it is additive rather than essential.

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 names specific verbs (fills, repaints, clears) and the exact resource (Roblox terrain), then enumerates concrete use cases (hills, water, caves, roads). It also explicitly separates itself from the instance-based siblings: 'none of the instance tools reach it: there is nothing to create, no path for find, and no property for modify.'

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?

Each op gets a when-to-use: `fill` for building, `replace` for swapping material while leaving shape intact, `clear` for emptying, and `stats` explicitly recommended as the first call in an unfamiliar place. It names the alternative route (`execute_luau` FillBall calls) and frames itself as the preferred path over it.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the flat-array return format, the depth-multiplication cost warning, and the fact that ~120 engine-internal root services are hidden with a count reported. It stops short of covering pagination/error behavior, but that is a minor omission.

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 behavior, then guidance, then the omit-path edge case — a sensible progression. Three paragraphs is slightly long, and the 'flat is both cheaper and easier to act on' rationale is arguably more justification than an agent needs, 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?

With no output schema, the description carries the burden of describing the return value, and it does (flat array of paths, hidden-service count). Combined with the sibling routing and the omit-path explanation, an agent has everything needed to call this correctly.

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

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

Schema coverage is 100%, so the schema itself documents all 8 parameters including the omitted-path behavior. The description still adds value on `path` (what the omitted case actually yields and why services are hidden) and on `depth` (cost implication), going modestly beyond the schema's own 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: 'Lists the instance hierarchy under a path, breadth-first to a given depth.' It also states the return shape (flat array of paths) and explicitly distinguishes itself from the sibling `find`, so an agent can select it without opening either 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 explicit when-to-use ('orient yourself in an unfamiliar place') and when-not ('Use `find` instead when you already know what you are looking for'), plus the cost rationale for avoiding deep trees. It also explains the omit-path case, which selects a materially different behavior.

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

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

The annotation `destructiveHint: true` is already declared, but the description meaningfully adds context: it discloses the partial-failure behavior ('the stack runs out, and an undo that did nothing otherwise looks exactly like one that worked'), clarifies that the server's own writes are pre-wrapped in undo recordings, and warns that the history 'covers the whole session, including the user's own edits.' These are important behavioral traits that annotations alone cannot convey. There is no contradiction between description and annotations.

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

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

The description is moderately long, but every paragraph earns its place — it fronts the core statement of what it does, then explains when to use it, then the critical edge case, and finally the safety warning. Nothing is wasted, and for a destructive tool, the added length is fully justified. It could be tightened slightly, but the density of information is well-matched to the risk profile.

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

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

For a tool with no output schema, the description's disclosure that 'It reports how many steps actually applied' is essential return-value context. The description covers the full picture — the mechanics, the failure modes (stack exhaustion), the risks (resetting user work), and the safety guardrail — while the parameters and annotations are all declared. The tool's complexity (3 params, a destructive flag, no nested objects) is thoroughly addressed. There is no meaningful gap an agent would need to resolve before calling this 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?

With 100% schema description coverage, the schema already documents all three parameters completely, so the baseline is 3. The description adds extra value by explaining the edge case relevant to the `steps` parameter — that over-requesting is possible and will silently return fewer steps, and by clarifying how the `action: 'status'` semantics let the caller inspect before mutating. It would have been a 5 with even more explicit per-parameter cross-referencing, but this exceeds the baseline.

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

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

The description clearly states the tool's purpose: 'Steps Studio's undo history backwards or forwards' — a specific verb with an explicit resource and scope. It differentiates this from other operations by explaining what it reverses and why ('as cleanly as the user pressing Ctrl+Z — one tool call is one step'). Even though it's named just 'undo', the title 'Undo and redo' plus the description make the full scope clear.

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

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

The description provides explicit usage conditions: 'Use it when the user says an edit was wrong, instead of trying to reconstruct the previous state by hand, which is guesswork and usually incomplete.' It also sets clear boundaries with 'Undo only what you just did, and only when asked', and explains the danger case where undoing beyond your own edits will revert the user's work. This is exactly the kind of when-to/not-to guidance that an agent needs.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, yet the description still adds substantial non-obvious behavior: default 10-minute bleed-off vs. Roblox's hard shutdown, MessagingService topic matching with no delivery feedback, relative server versioning semantics, permanent-ban risk when durationSeconds is omitted, ~3-minute log latency and warnings/errors-only retention, and create-time name checking that prevents duplicate products. It also correctly labels confirm as required for the irreversible ops rather than contradicting the destructive hint.

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?

Long but fully earned: one paragraph per op group, backticked op names, front-loaded with the single most important distinction (live vs. Studio), and no repetition of schema text. Every sentence carries either a behavioral or routing fact.

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-op, 24-parameter tool with no output schema, the description covers return shape where it matters (servers lists players/uptime/frame rate/memory/version; logs carries stack traces and structured context; products lists ids and prices), plus the auth/setup requirement. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the schema carries most parameter meaning and the baseline would be 3. The description still adds real semantics beyond it — placeId scoping ('scope it to one place... or leave that out to cover the whole experience'), the create-vs-change contract of itemId, and the confirm requirement for the externally visible ops — so it edges above baseline.

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 precise scope statement — 'Acts on the PUBLISHED experience and the people in it — not on the place open in Studio' — that immediately separates it from every studio-side sibling (execute_luau, playtest, viewport). Each of the 11 ops is then named with a concrete verb+resource, so an agent knows what this tool does 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?

Explicitly says when to use restart (after publish, because publishing alone changes nothing for live players), when to prefer it over Roblox's harsh default, when message delivery is not guaranteed, when logs are the right source ('where a player's bug report actually happened; Studio only shows your own test'), and the prerequisite (Open Cloud key + universe id set via `cloud`). Alternatives and exclusions are named, not implied.

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

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), and the description adds genuinely new behavioral context: layout is live in edit mode with no playtest needed, distance is computed from subject size and FOV, and each query op's return shape (position/normal/distance/material for raycast). It does not state which ops mutate Studio state vs. only read, which annotations leave fuzzy at the whole-tool level.

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?

Organized op-by-op with lead sentences per capability, so it is scannable despite its length. It is on the verbose side and includes editorializing ('which no amount of reading properties can', 'answers nothing'), which is justified for a broad multi-op tool but not uniformly 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 6-op, 20-param tool with no output schema, the description is thorough: it explains what raycast, ui, and textbounds return and what select/focus/camera change. The one gap is that select/camera return values are never characterized, but given the query ops are documented, completeness is strong.

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

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

Schema description coverage is 100%, so the baseline is 3, but the prose adds conceptual meaning beyond the per-parameter strings: how focus computes distance and frames both a doorway and a whole map similarly, that `at` substitutes for an instance, that ui measures against the current `device`, and that textbounds falls back to the label's own text/font/size when fields are omitted.

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 each of the six ops with a concrete verb+resource: 'select sets/extends/shrinks the Studio selection', 'focus aims the camera', 'raycast fires a ray', 'ui audits an interface', 'textbounds measures rendered text'. It explicitly distinguishes itself from siblings ('studio_status reports the current selection; this sets it'), so an agent can route 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?

Nearly every op carries a when-to-use: 'select what you just built or changed', 'build, focus, screenshot', 'use ui... twice: once as-is, then device op="set" a phone and again'. It names the related tools (screenshot, device, studio_status) and the condition that selects each, leaving little to inference.

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