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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true). It discloses non-obvious behavior: built ids are session-local, unuploaded, unmoderated; rig mismatch fails silently with no error; the returned id is a bare hash that breaks if prefixed; preview freezes the rig until `stop`. This is exactly the context an agent needs to avoid failure modes.

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

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

Five paragraphs, each carrying distinct operational info (read rationale, rig/R15-vs-R6 gotcha, build session-locality, preview mechanics, pose syntax, id format), so nothing is pure filler. Slightly long for a tool definition, but it is front-loaded with the core verb+resource statement and each later paragraph earns its place.

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

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

For an 11-param, no-output-schema, multi-op tool, the description covers op selection, the session-local id behavior, rig requirements, and pose formatting. Minor gaps remain: multi-studio targeting (`studioId`) and the `hold`/`loop`/`priority` interactions are left to the schema, but nothing critical to calling 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 baseline is 3, but the description adds real meaning: the pose string syntax ('0, 1, 0 | 0, 45, 0'), why `rig` matters for `build` (custom rigs, weapons, Blender imports may attach poses in the wrong order), and the accepted forms of `assetId`. It doesn't add much on `studioId` or the `keyframes` array beyond the schema.

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

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

The description opens with a precise verb+resource statement ('Reads an animation's actual keyframes, and builds new ones') and explicitly carves out its territory against a named sibling: '`inspect` on an Animation instance returns an asset id and stops there'. An agent can distinguish this from inspect, generate, or assets 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?

It routes each op by intent: `read` for answering questions without scrubbing the editor, `preview` for posing a rig for `screenshot` in edit mode (no playtest), `build` to try an idea but explicitly 'the wrong way to ship one'. It names the alternative (`inspect`) and its limitation, and states the op-ordering (`preview` persists until `stop`).

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses several crucial behaviors: results come 'from the running binary rather than from a published dump', members return as signatures, deprecated members are 'never listed, only counted', and the `describe` vs `classes` operational split. These are non-obvious traits that directly affect how the tool should be called and interpreted, adding real value over the annotations alone.

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

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

The description is long but every paragraph earns its place. The first sentence states the core purpose, and subsequent paragraphs each cover a single behavioral aspect—freshness, return format, deprecation handling, and relationship to `inspect`—without redundancy. The ProximityPrompt example is illustrative, not filler.

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

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

For a 6-parameter tool with no output schema, the description fully covers what an agent needs to know: the return shape (signatures), default behaviors, deprecation semantics, and how to discover class names. There are no missing pieces that would leave an agent guessing how to invoke 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?

Even though the schema covers 100% of parameters, the description adds substantial semantic context: it clarifies the two enum values of `op`, explains the `inherited` parameter's default and trade-off with a concrete example ('ProximityPrompt has 2 methods of its own and 42 inherited'), and specifies case-sensitivity of `className`. This goes well beyond what the JSON schema alone provides.

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

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

The description opens with a specific verb+resource: 'Lists the properties, methods and events of any Roblox class', and later explicitly differentiates from sibling `inspect` ('This is not the same as `inspect`. `inspect` reads the values on an instance...'). An agent can immediately tell what this tool does and how it differs from closely related tools.

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

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

Explicit when-to-use guidance is present: 'Use it before writing Luau against a class you are not certain of.' It also names when not to use it by contrasting with `inspect` ('this reads the shape of a class whether or not anything in the place is one'). This leaves no ambiguity for tool selection.

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 the annotations by disclosing client-side filtering, silently ignored Roblox sort options, permanent grants with no revocation, publish API limitations that report success anyway, bake's data-model-session scoping, moderation and quota effects on uploads, and restart's 10-minute bleed-off behavior. No statement 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 description is long and repeats some schema-level details such as `restart`, `audioType`, and `confirm`, but it is well organized by operation, front-loaded with the core purpose, and uses line breaks and warnings to keep the density navigable. It could be tightened, but the length is largely justified by eight operations and thirty parameters.

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 30 parameters, no output schema, and multiple mutating operations, the description is unusually complete. It covers return information, failure modes, authentication setup, safety hazards around scripts, upload moderation, quota checking, and the edit-mode/playtest distinction for baking. An agent has enough context to call the tool correctly and avoid the documented pitfalls.

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 real meaning to parameters: filters like `excludeScripts`, `maxTriangles`, `verifiedOnly`, `freeOnly`, and `minVotes` are applied locally, `audioType` defaults to SoundEffect because the engine's own default is Music, `confirm` is mandatory for permanent or live actions, and `file` omitted on upload checks credentials without sending anything.

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

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

The opening sentence gives a specific verb and resource: 'Searches Roblox's Creator Store and inserts models into the place.' It then clearly enumerates all eight operations (search, peek, insert, bake, upload, grant, publish, quota) and explains what each does, so an agent can distinguish the tool's many modes and its boundaries.

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 repeatedly gives explicit when-to-use and when-not-to-use guidance: use `peek` whenever `hasScripts` is true, do not use `grant` for your own assets, do not use `bake` in edit mode expecting playtest persistence, and ask `op="quota"` instead of guessing. It also names exclusions like 'It does not help generate at all' and warns against speculative or repeated uploads.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true), it discloses a key non-obvious behavior: an otherwise valid graph is silent until wires connect named pins. It also explains that inspect surfaces Connected=false connections hidden in Explorer, and that graph is undoable. This adds real diagnostic value that annotations alone do not 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 longer than most but earns its length given 12 parameters and a non-obvious domain. It is front-loaded with the core mental model before enumerating operations, and every paragraph contributes. A little narrative is arguably unnecessary, so it is not quite 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 complex tool with no output schema, it covers the main operations, common failure causes, edge cases (channel splitter pin, asset left out), and alternative tools. Nothing essential for selecting and invoking this tool 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%, so the baseline is 3, but the description adds meaning beyond the schema: it explains the failure mode behind toPin/fromPin, enumerates accepted effect classes, clarifies what omitting asset/path does, and distinguishes world versus ui placement. This makes parameter selection significantly safer.

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 domain (Roblox's modern audio graph) and a concrete set of operations (graph, wire, inspect) along with the instances involved. It explicitly contrasts with the old Sound instance and the sibling create tool, so an agent can distinguish this tool 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 routing: use graph for a complete chain, wire for joining existing instances, inspect for reading back and debugging silence-through-missing connections. It also states when NOT to use it ('old Sound ... use create for that') and when to prefer it (effects, per-listener mixing, multiple sources into one emitter).

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?

The description discloses key behavioral traits beyond the annotations: groups are not undoable, not session-scoped, and removal unregisters the group entirely. It also explains world scoping (worldModel) and that assigning a Model assigns all parts inside. It does not contradict annotations (readOnlyHint false, destructiveHint false) and adds contextual details like the fact that a group with nothing assigned does nothing. It could mention rate limits or auth, but those are less relevant here.

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 well-structured, with clear sections for group management and queries. It front-loads the core purpose and differentiators, then explains ordering, scoping, and pitfalls. Every sentence adds value, though it could be slightly tightened. The structure makes it easy to scan for key facts.

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 23 parameters and no output schema, the description is remarkably complete. It covers the return values of casts and overlaps (part, hit point, normal, material, distance), explains the significance of hit: false, details the world scoping, and clarifies the operation ordering. It also addresses the common pitfall of running a cast with the wrong collisionGroup. Nothing essential seems missing 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?

Schema coverage is 100%, so the schema already documents parameters. The description adds meaning beyond the schema by explaining the purpose of collisionGroup ('Required for a truthful answer'), respectCanCollide ('matching the engine'), and the usual use case for ignore (the character doing the looking). It also clarifies the action enum's groups vs queries. This extra context helps an agent select and fill parameters correctly.

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 ('Controls which parts physically collide') and a resource ('which parts'), and explicitly differentiates from siblings by noting that it answers geometry queries (cast/overlap) that the Explorer and inspect cannot. The opening line is unambiguous about the tool's 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?

It provides explicit when-to-use guidance, contrasting with the alternative of turning CanCollide off, and identifies the specific question it answers that the Explorer cannot. It also gives a clear operation order (create, assign, collidable) and explains the difference between cast and overlap. This leaves no ambiguity about when to choose this tool.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial non-obvious behavior: per-session logs keyed to plugin load time, no pre-load history, client output unreachable due to HTTP restrictions, and Studio-emitted messages landing in the session that raised them. The warning about not treating a quiet log as an all-clear is exactly the kind of caveat an agent needs.

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 and well-structured, with the purpose in the first sentence. It is longer than strictly needed: the fact that client output is unreachable and the 'silence is not an all-clear' point are each stated twice, which costs some tightness.

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 model itself (up to 2000 lines held, newest last) and covers session scoping, filtering, and the key blind spots. An agent has everything needed to call it correctly and interpret empty results.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds usage meaning beyond the schema: level to isolate errors, pattern to follow one subsystem's logging, and a rationale for using filters instead of a large limit. It doesn't add new syntax, but it does add selection guidance for the 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?

States a specific verb and resource ("Reads the Studio Output window") and enumerates what it contains (prints, warnings, runtime errors, newest last). It routes the agent to siblings explicitly — script_read to open a named script/line and list_studios to find a target session — so it is distinguishable from the rest of the toolset.

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 triggers ("after a playtest or an execute_luau call") and concrete when-not conditions (client output is never reachable; the editor log will not contain playtest prints). It names alternatives (list_studios, script_read, checking the Output window manually) and advises preferring a filter over a large limit.

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 that creation is a single undoable step, that property names are validated against the live Roblox API dump before transmission, and that typos return closest real names instead of engine errors. It also warns that an instance's path is unknowable until it exists and that same-named siblings make guessing unreliable. These are meaningful behavioral details not present in annotations.

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

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

The description is four tight sentences with no filler. The core purpose is front-loaded in the first sentence, followed by nested usage rationale, validation behavior, and a sibling-routing instruction. Every sentence earns its place.

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

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

Given the rich input schema, relevant annotations, and the absence of an output schema, the description covers what the agent needs: what the tool does, when to use an alternative, how to structure complex creates, and how errors are surfaced. Nothing critical for correct invocation is missing.

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

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

The input schema already provides 100% coverage with detailed parameter descriptions, so the baseline is 3. The description adds extra semantic value by explaining why children should be used for building models and how property validation handles typo'd names. It does not duplicate schema content but enhances conceptual understanding of 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 opens with a specific verb and resource: 'Creates instances with their properties, attributes and tags set at creation, as one undoable step.' It clearly differentiates from the sibling by explicitly directing Script, LocalScript, and ModuleScript creation to script_create. The purpose is unambiguous and not a tautology.

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: 'Use script_create for Script, LocalScript and ModuleScript — it takes source directly.' It also explains when nesting children is preferable and why, addressing the reliability of addressing newly created instances. This provides strong decision support for selecting between alternatives.

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

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

The 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?

Beyond annotations, the description discloses critical non-obvious behaviors: breakpoints fire once per run, log expressions cannot see loop control variables, log errors surface in console rather than here, set returns Verified even when the expression fails to compile, and breakpoints never leave a thread stopped. This is exactly the kind of behavioral context annotations alone cannot 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 earns its length: every paragraph addresses a distinct operational risk or decision point, and the first sentence front-loads the core purpose. The structure moves from what it is, to non-obvious limitations, to cost tradeoffs, to practical placement advice, all without 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 complex tool with no output schema, the description is remarkably complete. It covers all four operations implicitly through parameter behavior, explains what snapshots return, warns about session scoping, and tells the agent to set breakpoints before playtesting. The only omitted details are the exact snapshot output format and exceptions behavior, both of which are partially covered by the schema and less critical than the behavioral warnings provided.

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 substantial meaning on top: condition must be a Luau expression evaluated in scope, logMessage is also Luau and not a template string, and line placement matters because certain lines can verify but never fire. These are value-add clarifications an agent could not infer from the schema 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 opening sentence states a specific action and resource: sets breakpoints that capture stack and variables, then reads back the captures. It goes further and explicitly distinguishes itself from a step debugger, making the tool's purpose crisp and differentiated from siblings like console, inspect, and playtest.

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

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

The description gives direct selection guidance: use the log form when you know what to watch, and the capture form when you do not. It also tells the agent when this tool is not appropriate (stepping through code) and directs log output to be read through the sibling console.

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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses serious behavioral traits: that stop also clears network shaping, that a left-over device silently corrupts every later screenshot, that a lingering 400ms delay makes everything feel broken, and that nothing on screen explains why. This is exactly the side-effect and cleanup context the annotations cannot convey.

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

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

The core purpose is front-loaded and the paragraphs are cleanly separated by concern (motivation, workflow, list, network, stop). It is longer than average, with the 'Most Roblox players are on a phone' paragraph being expository, but the length is largely justified by 11 parameters and 5 operations.

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

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

There is no output schema, and the description covers what an agent needs across all operations: set/list/network/stop behavior, cleanup requirements, and pairing with screenshot and playtest. The only op not explicitly narrated is 'state', which the schema itself defines as reporting-only.

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 field, making 3 the baseline. The description adds meaning on top: concrete device-id examples ('iphone_16', 'ipad_a16', 'samsung_galaxy_s25_ultra'), the framing of network shaping as deliberately degrading the connection, and the semantics of the presets and direction of degradation.

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: 'Resizes the Studio viewport to a real device, so you can see what a player on that device sees.' It further distinguishes itself from siblings by naming playtest and screenshot and clarifying that it operates on the editor viewport rather than a running game's HUD.

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 an explicit workflow ('set a device, screenshot, look'), states when to use it (finding device-specific UI breakage invisible in the data model), routes to alternatives ('Pair it with playtest to check a running game's HUD rather than the editor'), and states when to undo it ('stop... Do that when you are finished').

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

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

Goes well beyond the destructiveHint and openWorldHint annotations by disclosing that there is no timeout, infinite loops can hang Studio, changes may not be undoable as one step, live mode touches production with no undo, and playtest servers run code through a ModuleScript with plugin-only APIs unavailable. It also exposes the require module-cache pitfall explicitly.

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 for a high-risk, 7-parameter escape-hatch tool. Core behavior and return semantics are front-loaded, then safety, playtest, require, and live-mode caveats are organized into logical sections with no meaningful fluff.

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 and serious destructive potential, the description covers return values, output capture, timeout behavior, live-vs-studio differences, production safety, async execution, and known VM pitfalls. It provides everything an agent needs to decide whether and how to invoke the tool correctly.

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

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

The schema already documents all 7 parameters at 100% coverage, including live-only constraints and the confirm requirement, so the baseline is 3. The description adds meaningful operational semantics beyond the schema: source runs with plugin permissions, print/return are the output channels, studio scripts have no timeout, and live execution is queued asynchronously and returns a state.

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: 'Runs Luau in Studio's plugin context and returns whatever it printed, returned, or threw.' It also positions itself as the escape hatch when no dedicated sibling tool fits, clearly differentiating it from tools like create, modify, delete, move, script_edit, and find.

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 instructs to reach for it only when no dedicated tool fits and names the sibling tools that validate input, type values, and wrap writes in undo recording. It gives concrete good uses and also warns against using require to read live game state, 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.

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description still adds real behavioral insight: tag searches are served from CollectionService's index rather than a tree walk (hence fast on large places), TOO_BROAD is a possible outcome with a documented remedy, and `selector` executes matching in C++ so only survivors return. These are non-obvious performance and error behaviors 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 capability and an example before any caveats, and the paragraph breaks map cleanly to tags/selector concerns. It is somewhat long for a description, but nearly every sentence carries distinct routing or behavioral content rather than restating 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 12-parameter, 0-required, no-output-schema tool, the description covers the filter model, tag discovery workflow, subtree narrowing, and the selector escape hatch. Pagination and per-item detail are left to the schema, which documents them fully, so nothing an agent needs to invoke the tool 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 baseline is 3, but the prose meaningfully extends it: it explains the purpose of `op="tags"`, that every supplied filter must match, that `selector` 'combines with the other filters', and that `path` is the remedy for broad results. It stops short of covering paging (`limit`/`cursor`), which only the schema documents.

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 ('Searches the data model by name, class, property value and/or tag') and immediately distinguishes itself from siblings, naming `tree` and claiming to replace separate name/class/property/tag search tools. The concrete example ('anchored BaseParts under Workspace.Map whose name contains door') makes the scope unambiguous.

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

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

Explicit routing advice: 'Prefer it over `tree` whenever you know what you are looking for', 'Narrow with `path` if a search reports TOO_BROAD', and a full paragraph on when to call op="tags" before filtering by tag. It also states when to reach for `selector` (shape-of-tree questions or two-class queries). When-to-use, when-to-narrow, and alternatives are all 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?

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?

Annotations already mark this as destructive and non-read-only, and the description goes far beyond them: it explains that subtract can succeed without cutting anything, intersect returns an error-style empty result, results lose Roblox's material/color/anchoring if not retained, mirror copies by default with a specific default plane, mesh only works on owned assets, segment is slow, and each call is one undo step. This is rich behavioral disclosure that materially changes how an agent should invoke and interpret the tool.

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

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

The description is long but earns its length: every paragraph explains a distinct operation, a failure mode, or a practical caveat, and the bold section headers plus inline code formatting make it scannable. The title sentence front-loads the tool's purpose, and there is no filler or repetition of 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 28-parameter polymorphic tool with no output schema, this description is unusually complete. It covers per-operation semantics, parameter behavior, failure modes, ownership constraints, performance characteristics, undo behavior, and material retention. An agent has enough context to choose the right operation, set parameters correctly, and interpret surprising results.

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

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

Even though schema coverage is 100%, the description adds substantial meaning to the core parameters: path as 'the one cut from, for subtract,' pivot as 'a door needs its hinge edge here,' steps as 'too few cuts corners off an arc,' checkAgainst as 'an empty array checks against everything,' and copy/about defaults for mirror. This goes well beyond the schema's field-by-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 scopes the tool precisely ('Every operation that reshapes solid geometry') and the description enumerates each operation with concrete verbs and resources: union, subtract, intersect, fragment, sweep, segment, mesh, mirror. This is unambiguous and clearly differentiated from sibling tools like create, modify, and move because it names the exact family of geometry-reshaping behaviors.

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 fragment for rubble and segment for articulation,' 'This is how to build a shape that is not a box without importing a mesh,' and calls sweep 'the only real answer' to collision questions. It also points to inspect as the verification step before subtract. This is strong when-to-use and alternative-routing guidance, both across the tool family and between operations within the tool.

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

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

Annotations mark it as a non-read-only, non-idempotent, open-world mutation; the description goes far beyond that by explaining the client-script parenting mechanism, that nothing is reported as sent until the client confirms, that missing confirmation yields an error not a success, and that cursor drawing is on by default. This is exactly the behavioural 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?

Front-loaded with the purpose and sibling routing, then escalates to mechanics. Nearly every sentence earns its place, but the window-resize anecdote ('435 to 952 pixels wide') is longer than the guidance it delivers and the block is dense enough to risk skimming.

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

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

For a 4-param, one-required, mutation-style tool with no output schema and no structured annotation coverage of mechanics, the description covers coordinate semantics, the `landed` reply, emulated-device distortion, focus handling for text, failure/error behaviour, and prerequisites. Nothing needed to invoke 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 baseline is 3, but the description adds real meaning the schema lacks: the distinction between `hold` (how long a key stays down) and `after` (wait before the next step) with a concrete example, that `text` targets the FOCUSED TextBox and requires a click in the same call, and that coordinates are viewport pixels to be paired with `screenshot`.

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 ('Sends real keyboard and mouse input to a running playtest') and immediately distinguishes itself from the sibling `character` tool: movement vs. input-bound controls. An agent can pick between the two 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?

Explicitly routes: 'Use `character` for going places and this for controls', enumerates the test cases it is for (does pressing E open the door, sprint key, Escape closing menu), and states prerequisites — a running playtest addressed by the playtest's studioId from `list_studios`, 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 cover the read-only/idempotent/non-destructive profile, and the description adds real behavior beyond that: partial-failure semantics ('bad paths come back under failures' and do not abort the batch), per-detail cost/expense profiles, and the fact that property selection tracks the live API dump. This is exactly the kind of context an agent cannot get 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 the core capability and the batching rationale, then a compact bulleted breakdown of detail levels, then the failure-handling note. Every sentence carries information; nothing is 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?

With no output schema, the description still covers parameters fully and discloses the key return-side behavior (the `failures` bucket), but it does not describe the overall response shape beyond that. Sufficient to invoke correctly, slightly short of complete for a read tool with no output schema.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds class-specific meaning ('Part gets Size, Position, CFrame, Anchored, Material...') for the detail levels. Minor inconsistency: the description says concise returns 'class and child count only' while the schema says 'name + class only'.

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 properties, attributes, tags and children of one or more instances.' It is easy to distinguish from siblings such as tree (structure listing), find (search) and script_read (source). The scope (one or more instances, batched paths) is explicit.

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

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

Gives clear operational guidance: batch all paths into one call, and reserve 'full' detail for one or two instances because it is expensive. It does not name a specific alternative sibling (e.g. when to prefer tree or find), but the when-to-use context for each detail level is unambiguous.

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

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

Annotations already 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?

Annotations declare openWorldHint=true and destructiveHint=false (though the tool stops/discards state). The description goes further: it states that play adds a second connected session hosting the game, that the call is non-blocking and reports the reached state, that stop discards changes exactly like pressing Stop, and that EndTest's value surfaces as lastResult. This is rich behavioral detail beyond the annotation flags, though it doesn't enumerate failure modes or edge cases (e.g., what happens if stop is called before any test).

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

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

Dense but every sentence earns its place: op semantics up front, then async behavior, then studioId routing, then stop/EndTest contractholics. No filler, well-organized into scannable paragraphs.

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?

Comprehensive for a control tool. It explains non-blocking behavior, side effects of stopping, how to discover the right studio, and the return-value semantics. Minor gaps: no failure modes or preconditions (e.g., must be in edit mode for play), and no mention of auth, but the description is unusually complete for the domain.

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

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

Even though the schema already documents all 4 parameters at 100% coverage, the description adds substantial semantic value: it explains the async nature of the reply ('returns the state reached'), how args is consumed inside the test, and the meaning of the state operation as a pure reporter. That goes beyond the schema's enumerations and helps an agent avoid misusing op as a blocking call.

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

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

The description uses specific verbs ('starts', 'stops', 'reports') tied to a clear resource ('playtests') and enumerates the five op values with distinct one-line meanings. It distinguishes the modes play/run/multiplayer and singles out state as read-only, so an agent can tell them apart 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 explains when to use play vs run vs multiplayer, warns that stop is the only way to end a test besides EndTest, and instructs calling list_studios after starting so console/performance/execute_luau target the playtest's studioId. This is actionable routing guidance with no ambiguity.

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

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

Annotations cover read-only and idempotent safety, and the description adds non-obvious context: it captures the user's current camera angle, behaves differently during playtest (slower, needs editor connection), and marks playtest captures with the caption `playtest client`. 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 action, then organized into when-to-use, camera behavior, and playtest caveats. Every sentence earns its place, including the illustrative wall/backwards/GUI examples that justify why a screenshot is needed.

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

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

Even without an output schema, the description explains the return is an image, warns about playtest latency and editor connectivity, and names the required `viewport` sibling interaction. An agent has enough context to invoke it correctly in both normal and playtest scenarios.

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 documents both parameters at 100% coverage, and the description adds beyond it: width guidance about sharpness versus cost, and studioId semantics for targeting a playtest client. This helps the agent choose parameter values, not just understand names.

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

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

The description states a specific verb and resource ('Takes a picture of the Studio viewport') and immediately distinguishes itself from sibling tools that 'read the data model.' An agent can tell this is the visual-reality-check tool rather than a data query tool.

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

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

It gives explicit timing guidance: take a screenshot after building something visual and before reporting success. It also names the prerequisite `viewport op="focus"`, explains when to rely on data tools instead, and covers the playtest scenario with studioId targeting.

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 the annotations. It discloses all-or-nothing batch semantics, the STALE_SCRIPT conditional write behavior, bottom-up line edit application, the fact that source replacement discards user changes, the live target's one-edit whole-source no-undo behavior, the fact that it changes the saved place not running servers, and the undo behavior via ScriptEditorService. This is exemplary behavioral disclosure. The annotations (destructiveHint=true, readOnlyHint=false) are consistent with the description's emphasis on destructive potential.

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. It is front-loaded with the core purpose, then organized by edit mode, then revision semantics, then live target, then deployment caveats. It is dense but not redundant. It could arguably be tightened, but the complexity of the tool (three edit modes, two targets, revision safety) justifies the length. The structure with clear paragraphs and mode labels helps an agent parse it.

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 8 parameters, no output schema, and complex semantics, the description covers everything an agent needs to call it correctly: the three edit modes, the revision requirement, the live target's special constraints, the all-or-nothing batch behavior, and the post-edit restart guidance. The only thing not described is the return value, but there is no output schema and the description's focus on behavior is more important for correct invocation. The description is complete for the tool's complexity.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds significant meaning beyond the schema: it explains the three edit modes (find/replace, startLine/endLine, source) and how they relate to the parameters, clarifies that find is literal not a pattern, explains the uniqueness requirement and replaceAll, explains the revision parameter's role in conditional writes, and clarifies the live-only parameters. It doesn't document every parameter individually, but the schema already does that. The description adds mode-level semantics that the schema lacks.

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: 'Edits Luau source through the Studio script editor' and immediately states it is the tool for any change to existing code. It distinguishes itself from siblings like script_create (creation) and script_read (reading) by framing itself as the editing tool for existing code.

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: 'This is the tool to use for any change to existing code.' It also provides clear alternatives and exclusions: it mentions script_read for reading, and contrasts with live target behavior. It explains when to use find/replace vs line ranges vs source replacement, and when to use target='live' with confirm:true. It even tells the agent to follow with universe op='restart' for live changes. This is comprehensive 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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the description doesn't need to repeat those safety attributes. The description adds valuable behavioral detail about the live buffer ('unsaved edits are searched too') and the return format (matching lines with paths and line numbers), enhancing transparency beyond 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 concise and well-structured: it opens with the core function, then explains when to use it, clarifies the pattern vs. literal distinction, and closes with the live buffer behavior. Each sentence contributes unique useful information without redundancy, and the flow is logical.

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 complexity (9 parameters, no output schema), the description covers all essential aspects: the return format, the search scope, the pattern semantics, and a key behavioral caveat (live buffer). Combined with the thorough schema descriptions, it provides enough context for an agent to correctly invoke the tool without missing critical details.

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

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

The schema provides 100% coverage of parameters with descriptions, and the description supplements this by explaining the nuance of Lua patterns (e.g., `%` escaping), the behavior of `ignoreCase` when combined with pattern classes, and the recommendation to use `literal` for identifiers. This goes beyond simply restating the schema.

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

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

The description clearly states the tool's function: searching inside Luau source across the place and returning matching lines with paths and line numbers. It uses specific verbs (searches, returns) and specifies the resource (script source). It also implicitly differentiates from sibling tools like 'find' or 'inspect' by focusing on script source content.

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 the tool: 'find where something is defined or used before editing it' and contrasts it with reading whole scripts. It also provides practical guidance on using Lua patterns vs. literal search and the `literal` parameter for identifiers, which is actionable and clear.

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

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

Annotations only say openWorldHint=true and destructiveHint=false, so the description carries the burden and exceeds it. It discloses that source comes from the live editor buffer, that file-bound scripts are a race with no failure reporting, that open rearranges the user's screen, that live mode has Instance API limitations (Folders/scripts only, GUID addressing, round-trip cost, seconds), and that list shows contents instead of reading. These are exactly the behavioral traits an agent needs to avoid incorrect calls.

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 paragraph earns its place: buffer semantics, batching guidance, file-bound race, open behavior, live-mode limits, and list behavior. It is front-loaded with the core read action and line-number contract, then expands into mode-specific guidance. Slightly dense, but not padded.

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

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

For a 10-parameter tool with no output schema, the description covers the critical context: what source is read, how to batch, how windows work, what open does, what live mode can and cannot do, and how to navigate with list. The only minor gap is not describing the result shape, but with no output schema and the description already explaining the flagged file-bound scripts, the agent has enough 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 the baseline is 3. The description adds meaning beyond the schema by explaining the top-level startLine/endLine act as defaults for entries without their own, that an entry may be a bare path or a window object, and that list:true with an empty path list shows the top level. It also clarifies the live-mode constraints on paths. This is meaningful added semantics, though the schema already documents each parameter well.

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

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

The description opens with a specific verb and resource: 'Reads Luau source from one or more scripts' and immediately distinguishes itself from script_edit by noting line numbers are accepted back verbatim. It also covers the open variant and the live target, so an agent can tell exactly what this tool does versus siblings like script_grep or 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?

The description gives explicit when-to-use guidance: read the live buffer rather than saved property to avoid stale code, pass all scripts in one call, use open when pointing the user at something, and use target='live' to check the published place. It also names alternatives implicitly by explaining what open and list do instead of reading, and warns against editing file-bound scripts. This is rich 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?

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 indicate destructiveHint=true and readOnlyHint=false, but the description adds extensive behavioral detail: terrain snaps to a 4-stud voxel grid, positions are the centre of the solid, fill applies multiple solids as one undo step, clear with confirm=true wipes everything, stats cannot report where terrain is because Roblox exposes no bounding box, and carving is done via Air material. These insights go far beyond the annotations and give the agent a realistic model of the tool's side effects and limitations.

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 carries essential information: the core purpose, the differentiation from instance tools, per-operation details, shape requirements, carving, position/grid behavior, and advice for usage. It is front-loaded with the most important fact (what it does) and then progresses logically. No filler or repetition; the length is 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?

Given the tool's complexity (multiple operations, shapes, carving, destructive potential) and the lack of an output schema, the description covers everything an agent needs: all operations and their semantics, parameter details, positional conventions, grid snapping, undo behavior, and strategic advice (call stats first, use screenshot). 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?

While schema coverage is 100%, the description enriches the parameters significantly. It explains that `fill` takes an array of solids and applies them as a single undo step, that `replace` swaps materials without changing shape, that `clear` can be scoped to a region or globally with confirm, and that `stats` only reports presence, not location. It also ties shape types to their required parameters (e.g., block needs size, ball needs radius) and explains the carving mechanic via Air. This is value beyond the schema's brief property 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 first sentence states exactly what the tool does: 'Fills, repaints and clears Roblox terrain — hills, water, caves, roads.' It uses specific verbs and a resource, and clearly distinguishes itself from instance tools by explaining that terrain is not made of instances and that this is the only way to shape it (besides hand-written FillBall calls). This unequivocally differentiates it from siblings like create, modify, and delete.

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

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

The description explicitly states when to use this tool: 'none of the instance tools reach it: there is nothing to create, no path for find, and no property for modify. This is the only way to shape it short of writing FillBall calls by hand through execute_luau.' It also gives tactical advice, such as calling `stats` first in an unfamiliar place and taking a `screenshot` to see the shape. This covers both when to use and what alternatives exist (execute_luau), leaving nothing 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 establish readOnly/idempotent/not-destructive, so the safety profile is covered. The description then adds genuinely unexpected behavior an agent would never guess: the ~120 hidden root services, the fact that omitting path lists only authored containers, the hidden-services count appearing in the response, and the flat-over-nested design rationale. This is exactly the kind of domain gotcha the description is the only place to surface.

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

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

Three tight paragraphs with a clear job each: what it returns, when to use it, and the root/path edge behavior. The hidden-services admission—a place where most tools would hide a bug—earns its place in the final sentence. Everything is front-loaded (purpose first), with zero filler or ceremonial language.

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

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

For a read-only discovery tool with 100% schema coverage, no output schema, and 0 required parameters, the description covers every decision point an agent faces: what the response shape is, what surprising root behavior exists, how to avoid the find/tree ambiguity, and how cost scales with depth. The pagination and filter params are fully documented in the schema where they belong. The only thing an agent might want to know—the actual return shape—is explained ('flat array of paths'), and the response hint about the hidden-services count is disclosed. 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?

At 100% schema description coverage, the schema carries the parameter-documentation burden, so the baseline of 3 applies. The description reinforces the cost model of `depth` and `detail` in prose, but that's complementary to, not a replacement for, the schema's work. No meaningful gap to compensate for.

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 ('Lists the instance hierarchy under a path') plus the exact algorithm ('breadth-first to a given depth') and return type ('flat array of paths'). The explicit contrast with the sibling 'find' — 'Use `find` instead when you already know what you are looking for' — provides exactly the sibling differentiation the rubric rewards.

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?

States when to use it ('orient yourself in an unfamiliar place'), when not to use it ('when you already know what you are looking for'), names the alternative explicitly ('use `find` instead'), and gives a cost rationale for the boundary ('wastes context on instances you will never touch'). Textbook when/when-not/alternative coverage.

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?

The description adds significant behavioral detail beyond annotations: restart bleeds off over 10 minutes rather than Roblox's default hard shutdown, message delivery is unacknowledged, bans without durationSeconds are permanent, and confirm is required because 'none can be undone from here.' This fully complements the destructiveHint and openWorldHint 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 organized by operation with a front-loaded key contrast, then per-op explanations, then shared auth context. It is long because the tool has 14 parameters and 7 operations, but every sentence contributes actionable information without 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?

It covers auth setup, per-operation caveats, and rough return meanings for bans, user, and inventory. There is no output schema, and the description does not state precise response shapes for restart, message, ban, or unban, but an agent has enough context to invoke the tool correctly and interpret basic outcomes.

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 useful extra semantics: userId is 'the name-to-id step most other calls need,' bans scope via placeId, and inventory reports passes/badges/assets. It does not repeat every schema detail, but it adds meaning beyond the structured fields.

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 scope: 'Acts on the PUBLISHED experience and the people in it — not on the place open in Studio.' It then enumerates each operation with a distinct verb and target, so an agent can tell what the tool does and how it differs from Studio-side tools.

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

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

It gives concrete when-to-use guidance, especially for restart ('This is the step people forget') and message ('success here does not mean delivery'). It also states the auth prerequisite. It does not systematically name sibling alternatives or explicit when-not-to-use conditions, but the context is strong enough for operation selection.

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.