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?

Annotations already signal mutability (readOnlyHint=false), openness (openWorldHint=true), and non-destructiveness (destructiveHint=false). The description adds meaningful beyond-annotation behavior: search returns hasScripts, insert reports and names scripts so it 'can still be undone,' and private or deleted ids fail with a message instead of silently no-oping. This is useful context not available from annotations.

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

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

The description is compact and well-organized: summary sentence, operation specifics, critical safety warning, and access constraints. Every sentence contributes meaning, with no filler or repetition of schema fields.

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 adequately covers return-relevant behavior: search results include ids, names, creators, vote ratios, and hasScripts; insert reports script count and names. It also communicates the safety check, undo possibility, and failure mode for private/deleted assets. The schema handles parameter detail, so nothing essential is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by clarifying that 'Only models insert as instances' for category, that only public assets can be inserted (relevant to assetId), and by reinforcing the op semantics. This lifts 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?

The description opens with a specific verb and resource: 'Searches Roblox's Creator Store and inserts models into the place.' It then clearly distinguishes the two operations, search and insert, and their corresponding outcomes. This separates the tool from unrelated siblings like script_edit or geometry without ambiguity.

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 usage context: search finds assets, insert adds one to the place, and it instructs the agent to 'ALWAYS check hasScripts before inserting.' It also states that only public assets can be inserted. It doesn't name alternatives or exclusions, but no sibling appears to offer a similar capability, so the guidance is strong.

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 key behavioral traits: moveTo reports whether it actually arrived and how far short it stopped, teleport skips triggers and collisions, state reports position/health/walk speed/activity, and the tool drives the Humanoid directly rather than simulating keystrokes. This is substantial, operationally important context that the 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 well-structured with clear sections for moveTo, act, and state, plus a use-case comparison and a requirement note. It is long, but justified given the tool's complexity and nine parameters; it avoids repetition and front-loads the core purpose.

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

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

This is nearly a complete operational guide: it gives prerequisites, alternative-tool routing, per-operation behavior, caveats around teleport, parameter relationships, and even suggests calling state before and after actions. It is sufficient for an agent to know when and how to invoke the tool, including the playtest-instance context that could otherwise be a common failure.

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

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

Schema coverage is 100%, but the description adds real semantic value: it clarifies the purpose of moveTo vs act vs state, documents that equip takes a Tool from Backpack/StarterPack, notes activate corresponds to a mouse click, and explains which operations use the path parameter. It doesn't enumerate every single parameter (e.g., direct and canJump are only lightly touched on), but the extra context meaningfully improves understandability.

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 specific verb and resource: 'Moves and acts as the player character in a running playtest,' and breaks out the three operations moveTo, act, and state. This makes the tool's scope unmistakable and distinguishes it from sibling tools like input, which is explicitly described as sending real key and mouse events.

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 unusually explicit usage guidance: it tells agents to use this tool for movement/character actions, to use input for control-bound interactions, and to use playtest op=play when there is no running playtest. It even explains what to do when a route is unreachable via the direct parameter, as well as to address calls to the playtest 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?

Beyond the annotations (readOnlyHint: false, etc.), the description discloses important behavioral traits: groups are not undoable, not scoped to a session, and removing unregisters a group entirely. It also explains that assigning a Model assigns all its parts and that a group with no assignments does nothing, adding significant transparency.

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 well-structured: it starts with the core purpose, then covers the primary use case and alternative, followed by operational order and caveats. Each sentence adds value with no fluff, making it efficient and easy to follow. Despite being slightly long, it remains concise due to the density of useful information.

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

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

Given the absence of an output schema, the description provides enough contextual information for an agent to use the tool correctly. It explains behavior, side effects, constraints (Default group cannot be removed), and the exact sequence of actions. No critical aspect is left unexplained, making it complete for practical use.

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 descriptions already cover all parameters (100% coverage), so the baseline is 3. The description adds meaningful context by explaining the action flow (create, assign, collidable) and clarifying that 'remove' is not the same as un-assigning parts, which helps interpret the 'action' parameter. This goes beyond the schema but not maximally, so a 4 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 clearly states the tool's purpose with a specific verb ('Controls') and resource ('which parts physically collide with which'), immediately distinguishing it from sibling tools like geometry or script_edit. It also provides a concrete use-case ('these should pass through each other') and contrasts with the CanCollide alternative, making the purpose unmistakable.

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

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

It explicitly states when to use this tool over the alternative (CanCollide) by explaining the downside of the alternative (ghost falls through floor). It also gives a step-by-step order of operations (create, assign, collidable) and clarifies when to use 'remove' versus un-assigning, leaving no ambiguity about usage scenarios.

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 readOnlyHint annotation, disclosing that logs are kept per session from plugin load, that editor and playtest logs are separate, that client output is never reachable, and that a quiet log does not prove nothing was printed. It even documents inconsistent Studio-originated messages, making its failure modes unusually clear.

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 typical but well organized, front-loaded with core behavior, then filters, then session caveats, then failure modes. A small amount of redundancy exists around client output being unreachable, but the extra detail is necessary for this tool's unusual behavior.

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 diagnostic tool with no output schema, the description covers ordering, filtering, retention, session semantics, and known gaps in coverage. It also tells the agent what to do when results are suspiciously absent, which is exactly the context needed to use 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?

Although schema coverage is already 100%, the description adds material meaning to each parameter: level is tied to filtering errors, pattern uses Lua patterns, limit interacts with the 2000-line retention cap, and studioId is explained in terms of per-session logs and playtest targeting. This is useful beyond the 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 description opens with a specific verb and resource: 'Reads the Studio Output window — prints, warnings and runtime errors, newest last.' It clearly identifies the tool's function and the data it returns, which distinguishes it from siblings like execute_luau or performance.

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 says this is how to find out what happened after a playtest or execute_luau call, and it directs the agent to script_read for opening error locations and list_studios for targeting the playtest's session. It also gives filtering guidance and warns when the editor log is the wrong source.

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?

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?

The description reveals a persistent side effect: leaving an emulated device active makes later screenshots the wrong shape, and nothing on screen obviously explains why. It also clarifies that the tool is the only way to see device-specific interface problems without owning hardware, beyond what the annotations express.

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 prose is economical and front-loaded: the core behavior appears first, followed by a motivating use case and a concrete workflow. The longer explanation about why mobile testing matters earns its place because it clarifies when this tool is indispensable.

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 main operations, the workflow, the list output conceptually, and the necessary stop cleanup. It does not fully specify the exact return shapes of list and state, but with no output schema and strong schema-level parameter descriptions, the remaining ambiguity is minor.

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 all parameters with detailed descriptions, so the baseline is high. The description strengthens this by showing example ids, mentioning form factor and resolution in list output, and explaining why orientation is worth testing separately.

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 the exact verb and resource: it resizes the Studio viewport to a real device, and the opcode enum distinguishes list/set/stop/state. It is clearly separated from sibling tools like viewport and screenshot by framing itself as device emulation.

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 an explicit workflow: set a device, screenshot, look, then stop. It recommends pairing with playtest for running-game HUD checks, tells you to use list to find device ids, and says to stop when 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?

Annotations already mark this as destructive, non-read-only, and non-idempotent, and the description adds substantial behavioral detail on top: no validation, no unified undo recording, no timeout so infinite loops can hang Studio, plugin context behavior, and playtest-mode changes like disabled loadstring and script identity. It even warns about the module cache pitfall with require. 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 paragraph earns its place: summary, usage guidance, output handling, timeout warning, playtest caveat, and require pitfall. It is structured with clear paragraphs and front-loaded with the core behavior, making it easy for an agent to scan and extract the critical warnings.

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

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

There is no output schema, so the description correctly explains return values, including printed output, returned tables as structures, and thrown errors. It covers failure modes, permission differences, undo behavior, and live-state hazards, leaving no major ambiguity for an agent deciding whether and how to invoke this dangerous escape hatch.

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 meaningful context beyond the schema for the source parameter by explaining plugin permissions, playtest identity restrictions, and return behavior via print/return. It does not add much for studioId beyond the schema, but the added source semantics justify a slightly higher score.

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: 'Runs Luau in Studio's plugin context and returns whatever it printed, returned, or threw.' It also distinguishes the tool from siblings by calling it the 'escape hatch' and contrasting it with dedicated tools like create, modify, and 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: 'Reach for it only when no dedicated tool fits,' and lists concrete good uses such as reading something no tool exposes or calling engine APIs not covered. It also provides a clear exclusion — 'Do not use require to read live state out of a running game' — and points to safer alternatives like reading from the DataModel or using 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?

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), the description discloses important execution behavior: 'Every filter you supply must match' clarifies AND semantics, and 'Tag searches are answered from CollectionService's index rather than by walking the tree, so they stay fast on large places' reveals performance characteristics. It also preempts error handling by advising to narrow with `path` when TOO_BROAD. These details add substantive behavioral context beyond the structured 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 a well-structured paragraph that front-loads purpose, then explains the AND semantics with a concrete example, then provides routing guidance, performance note, and error-handling tip. Each sentence earns its place; there is no fluff. It is compact yet information-dense, appropriate for a tool with 10 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?

Given the tool's complexity (10 parameters, no output schema), the description is remarkably complete. It explains the search logic, performance considerations, error handling, and the cost of different detail levels. The annotations already cover safety via readOnlyHint and destructiveHint. An agent has all necessary information to invoke it correctly for a wide range of queries and to interpret potential TOO_BROAD errors.

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 parameter. The description adds meaning beyond field descriptions: it explains that all supplied filters must match (AND logic), which is not in the schema. It also gives cost guidance for `detail` levels ('concise = name + class only, cheapest... full = every readable property, expensive') and hints at error recovery via `path`. This goes beyond a baseline 3 by enriching understanding of parameter interactions and trade-offs.

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: 'Searches the data model by name, class, property value and/or tag.' It specifies the resources (data model instances) and the exact search dimensions. It also distinguishes itself from siblings by noting it replaces separate search tools and explicitly positioning itself against `tree`: 'Prefer it over `tree` whenever you know what you are looking for.' This makes its purpose unambiguous and separate from 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?

The description gives explicit when-to-use guidance: 'Prefer it over `tree` whenever you know what you are looking for.' It also provides troubleshooting advice: 'Narrow with `path` if a search reports TOO_BROAD.' It explains the benefit of combining filters in one call, which clarifies the intended use case for complex queries. While it doesn't enumerate every alternative, it clearly differentiates from `tree` and offers practical direction on when to narrow the search.

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 key behavioral details: originals are consumed unless `keepOriginals` is set, the whole operation is one undo step, `subtract` returns the subject unchanged when there is no overlap, `intersect` returns an error on no overlap, and results inherit material/color/anchoring. It even warns about Roblox returning grey MeshParts. This is excellent behavioral disclosure for a destructive 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 every sentence earns its place. It front-loads the core purpose, then moves through operation examples, failure modes, material preservation, and consumption semantics in a logical order. The caveats about subtract and intersect are high-value and would otherwise be discovered only at runtime.

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

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

For a destructive, multi-operation tool with 10 parameters and no output schema, the description covers all critical runtime behaviors: operation semantics, overlap requirements, failure modes, material inheritance, input consumption, undo behavior, and performance trade-offs. The remaining parameter details are already fully documented in the schema, so nothing essential is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantic context beyond the schema: it explains the failure modes of `subtract` and `intersect`, clarifies that `keepOriginals` affects consumption of inputs, and notes that results retain material/color/anchoring. This helps the agent reason about parameter effects without reading 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 description opens with a specific verb and resource: 'Cuts, joins and shatters parts with real constructive solid geometry.' It then enumerates the four operations and gives concrete examples (subtract a door out of a wall, union parts, etc.), which clearly distinguishes this from sibling tools like create, modify, or 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 explains when this tool is the right choice: 'This is how to build a shape that is not a box without importing a mesh.' It also directs the agent to use `inspect` to verify overlap before subtracting, which is a practical alternative. It does not explicitly list all the sibling tools it should not be used instead of, but the use case is clearly scoped.

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: it explains that input is delivered through a client-side script, that success is only reported after the client confirms delivery, that errors occur on missing confirmation, that a pointer is drawn on screen, and that coordinate offsets are reported as `landed`. This gives crucial failure-mode and execution-context insight.

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 adds distinct, non-redundant guidance for a genuinely complex tool. It is front-loaded with purpose and sibling differentiation, then proceeds through prerequisites, visualization, execution semantics, coordinates, and text input in a logical order.

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, the description covers prerequisites, error behavior, coordinate space, cursor behavior, timing semantics, and client/server delivery. The schema already documents parameter defaults and constraints, so no essential calling information 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?

Even though schema description coverage is 100%, the description adds substantial meaning: `after` is explained as wait-before-next-step, `action` press/release across steps is clarified, `text` requires a focused TextBox that can be clicked in the same call, and mouse coordinates are tied to viewport pixels and `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?

The first sentence states a specific verb and resource: sends real keyboard and mouse input to a running playtest. It also explicitly distinguishes itself from `character` by contrasting input-driven controls with movement/Humanoid-driven behavior, so an agent can tell which sibling to choose.

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 `character` for going places and this for controls. It also states prerequisites (a running playtest, the playtest's studioId from `list_studios`) and explains the intended use of `after`, `hold`, `cursor`, and text focus.

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 readOnly/idempotent/no-destructive annotations, the description discloses failure isolation (bad paths return under failures), live Roblox API property selection, and the relative cost of detail levels. This materially improves agent prediction of side effects and outcomes.

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 action and top-level batch advice come first, then detail options in scannable bullets, then edge-case behavior. Each sentence adds a distinct fact and the length is proportionate to 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?

The description covers failure handling, cost of detail levels, and property freshness, and annotations cover safety. It does not spell out the exact success-response shape (e.g., per-path objects), and there is no output schema, which leaves a minor inference gap for agents.

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

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

Schema coverage is high (100%), but the description enriches the detail and properties parameters with concrete mode semantics (class/child count, characterizing properties, expensive full mode) and explains batching intent. It doesn't add much beyond schema for paths/studioId/includeChildren, so a modest premium over baseline 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 'Reads properties, attributes, tags and children of one or more instances', a specific read verb plus a concrete resource. The wording clearly separates this inspect operation from mutation siblings, so an agent can identify the tool's role even before reading schema details.

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 strong operational guidance: batch all desired paths into one call, choose detail level by need, and reserve full mode for one or two instances. It does not explicitly mention sibling alternatives like tree/find for when to choose them instead, so it stops short of full alternative routing.

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

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

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?

The description is highly transparent about behavior, including blocking profile calls, per-data-model instrumentation, and the fact that unparented instances are not in the tree. However, it explicitly documents that coverage's `enable` is 'remembered for the place and re-applied by each new session as it loads', which is a persistent side effect, while annotations declare `readOnlyHint: true`. This is an annotation contradiction, so per the rubric this dimension must score 1.

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 every sentence: each paragraph maps to one operation, uses code spans for parameter values, and front-loads the core purpose before diving into caveats. It is dense, well-structured, and contains no filler.

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

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

Given the tool's multi-operation complexity and lack of an output schema, the description is remarkably complete. It covers what each operation returns, prerequisites, timing constraints, state persistence, and limitations. Remaining details like `studioId`, `frequency`, and `includePlugins` are adequately covered by the input schema, so nothing essential is missing.

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

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

Schema coverage is already 100%, so the baseline is 3. The description adds meaningful behavior beyond the schema: it explains the profile workflow, the coverage lifecycle from enable through playtest session to stop, and the practical caveat that profiling an idle edit session returns nothing. This is enough to push the score 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 opening sentence states a specific activity — reading engine counters and running the script profiler — and the description then cleanly differentiates the four operations: snapshot, profile, coverage, and scene. It also distinguishes itself from sibling tools like find and tree by noting that unparented instances are invisible to both, making its unique resource 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 gives explicit when-to-use guidance for each mode: snapshot to answer 'why is this place heavy', profile after starting a playtest, coverage with the enable-then-play-then-read flow, and scene for composition and memory breakdowns. It also states exclusions — idle profiling returns nothing, and scripts compiled before the plugin exists are unmeasurable.

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?

Beyond the annotations, it discloses critical behavior: all-or-nothing batch semantics, non-unique find refusal, bottom-up application of line edits, preservation of unsaved work, per-script undo scope, and the fact that source replacement discards user changes. No contradiction with the destructiveHint annotation.

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 earned: the core purpose is front-loaded, the three edit modes are clearly separated, and the implementation and undo details are directly relevant to correct use. Every sentence either clarifies a parameter, sets expectations, or prevents misuse.

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, destructive edit tool, the description covers invocation semantics, failure modes, concurrency behavior, and undo behavior comprehensively. No output schema exists, but the agent has everything needed to construct correct calls and predict consequences.

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 meaningfully to the parameters: it explains the three mutually exclusive edit modes, why find is literal, when replaceAll is needed, how line numbers relate to a previous script_read, and what source replacement implies. This goes well beyond the schema's 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 description states a specific action — editing Luau source through the Studio script editor — and explicitly frames it as the tool for any change to existing code. This clearly distinguishes it from creation or read-only tools like script_create and script_read.

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

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

It gives explicit when-to-use guidance ('the tool to use for any change to existing code') and provides mode-level selection guidance: find/replace is preferred, line ranges come from script_read, and source replacement is only for small files or rewrites. This is actionable and reduces guesswork.

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

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

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 already indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond that: it reads from the Studio editor's live buffer, includes unsaved user edits, and produces line numbers intended for script_edit. This is exactly the kind of non-obvious behavior an agent needs to know.

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 tight and well-structured: first sentence states what it does, second explains the live-buffer rationale, third explains batching and windowing. Every sentence adds useful information with no filler, and front-loads the core purpose.

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

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

The description covers the tool's behavior, input forms, line-number semantics, and rationale thoroughly. Without an output schema, it does not explicitly describe the exact return format, but 'source with line numbers' plus compatibility with script_edit gives a reasonably clear picture. Minor gap 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 parameter. The description adds meaning by explaining the relationship between top-level startLine/endLine defaults and per-entry windows, and by describing the bare-path versus {path, startLine, endLine} forms. This goes beyond the raw schema definitions.

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 'Reads Luau source from one or more scripts', which is a specific verb and resource. It also ties to script_edit by noting line numbers are accepted back verbatim, helping an agent understand this is the read counterpart to script_edit rather than a search or write 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 strong usage context: pass every script needed in one call, use the live buffer rather than saved property to avoid stale code, and use per-entry or top-level line ranges. It does not explicitly contrast against script_grep or other sibling tools, but it clearly communicates when and why to use this tool.

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

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

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 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 discloses that 'select' sets the selection (versus 'studio_status' reporting) and explains the effect of 'focus' on the camera. However, it inaccurately claims 'camera' can both 'set or read' the camera, while the schema only defines parameters for setting. This minor inconsistency and lack of side-effect discussion leaves some ambiguity.

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 excessively long and employs a repetitive, poetic style (e.g., 'Build, focus, screenshot.'). It could be condensed to a few clear sentences without losing meaning. This violates the principle of being appropriately sized and front-loaded.

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

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

The description thoroughly explains the purpose and reasoning behind each operation, including why 'focus' is necessary for screenshots and why 'raycast' is useful for queries. It covers all operations and their parameters contextually, leaving no major gaps for an agent to misunderstand the tool's functionality.

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 complete parameter descriptions (100% coverage). The tool description adds minimal extra semantic value—it mentions defaults for 'from' and 'padding' but repeats schema info. Per the rubric, a baseline of 3 is appropriate when schema coverage is high and the description adds little.

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 domain (3D view and Studio selection) and enumerates the four operations (select, raycast, focus, camera). However, it is more verbose than necessary and includes a stray reference to 'studio_status' that could confuse, so it doesn't reach a perfect 5.

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

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

The description provides usage context by comparing to sibling tools: it contrasts with 'studio_status' for selection reporting, and implies using 'focus'/'camera' before 'screenshot'. This is helpful but not as explicit as naming when to use each operation versus alternatives.

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