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

Annotations already mark destructive/write behavior to no surprise, and the description adds substantial operational context: API key resolution from env or file, re-read every call and never returned, 403 error messages naming the required permission, a built-in key probe (info what:'key'), return size limits, pending async handles, and the critical distinction that luau/instance read the published place, not the Studio session. These details go far beyond what annotations convey.

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

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

The description is long but appropriately dense for a tool with 55 parameters across 12 actions. It front-loads the most critical constraints (defaults, authentication, error behavior) before listing actions, and each action group is compactly summarized. A few sentences could be tightened, but overall the structure aids scanning.

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 enormous scope and absence of an output schema, the description covers essentials: authentication setup, default scoping, override mechanism, error probing, result size limits, async polling pattern, publishing workflow, and where the tool does not apply (open place → run tool). No critical usage detail appears to be 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 98%, so the baseline is 3; the description adds meaningful cross-cutting semantics: default universe/place/creator resolution with overrides, etag-based conditional writes, memory store TTL behavior, message size limits, and the action-specific op groupings. It also refers users to field-level help ('arg help is on each field'), acknowledging the schema's completeness while clarifying global defaults.

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 clear resource and scope: 'Roblox Open Cloud for the place open in Studio.' It enumerates a dozen distinct actions, making the tool's breadth apparent. However, it does not explicitly contrast with sibling tools like observe/run/playtest, though the name and subtitle imply a cloud API access role.

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

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

The description gives explicit routing guidance: 'For the OPEN place use the run tool,' distinguishing when not to use this tool for instance operations. It also explains sequencing ('Do this before luau / instance, which read the PUBLISHED place, never the Studio session') and environmental caveats ('message … in live servers, not playtests'). While not covering every possible alternative, it provides clear context for major decision points.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context beyond that: the ring buffer eviction behavior (dropped > 0 means events were evicted), the long-poll timeout semantics, the cursor contract, and the relationship to the push socket. It doesn't describe every edge case, but it discloses the non-obvious behaviors that matter for correct use.

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 dense but well-organized: it front-loads the core backfill behavior and return contract, then filters, then long-polling, then the fallback relationship. Every sentence carries information. It is longer than the typical description, but the complexity of the tool (cursor semantics, ring eviction, long-polling, push fallback) justifies the length. A slight deduction for the dense run-on style in the first sentence.

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, idempotent, non-destructive tool with 100% schema coverage and no output schema, the description is remarkably complete. It explains the return shape, the cursor contract, the eviction failure mode, the long-poll behavior, and the relationship to the push alternative. An agent has everything it needs to call this tool correctly, including how to recover from dropped events.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters. The description adds meaning for kinds and levels by enumerating the accepted values, and for timeout_ms by explaining the long-poll behavior. However, since the schema already covers the basics, the description's added value is moderate rather than transformative. 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 a specific verb and resource: 'Backfill from the bridge's event journal', and immediately distinguishes itself from the push alternative. It names the exact return shape and the semantics of each field, so an agent can tell exactly what this tool does and how it differs from siblings like observe or look.

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 when to use this tool: as the portable fallback to push, and after any dropped > 0 or seq gap on the socket. It also names the preferred alternative (Monitor on ws://127.0.0.1:<port>/events) and explains the conditions that select between them. This is explicit when/when-not guidance with a named alternative.

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

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

The annotations are all false and provide no safety profile, so the description carries the full burden. It thoroughly discloses action execution order, hold/release semantics, 50 ms click timing, coordinate-space behavior with GUI inset, the fact that screenshot pixels are not viewport pixels, absence of MouseWheel events, key release on abort/cancel, per-step result format, and non-aborting failure behavior unless abort_on_error is set.

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 dense and every sentence contributes necessary operational detail, with no filler. It is front-loaded with the core purpose and action list, but the heavy use of parentheticals and run-on sentence structure makes it harder to parse than a more bulleted layout would be. Still, it is appropriately sized for the tool's complexity.

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

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

Given the tool's complexity and lack of an output schema, the description is complete: it covers action order, hard limits, coordinate-system calibration, result shape, abort and error semantics, key-release behavior, no-scroll limitation, window rendering prerequisite, and when to delegate to playtest or run. An agent has everything needed to invoke 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?

While the schema provides descriptions for dm, session, wait_ms, and abort_on_error, the complex `actions` array properties lack schema descriptions. The description compensates by defining each action type and its fields (key, down, hold_ms, x/y, button, dx/dy, text, path, ms, gui) with constraints and coordinate defaults, adding substantial meaning beyond the schema.

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

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

The description states exactly what the tool does: it provides human-like input through the real input pipeline in a play client, with a detailed breakdown of supported action types (key, click, move, look, text, focus, wait). This clearly distinguishes it from siblings like observe, run, and playtest, and goes far beyond a restatement of the title.

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 routing guidance: for reactive or long-running input, install a controller with `playtest`; for camera rotation that the default script ignores, drive workspace.CurrentCamera from a `run` instead. It also states a key prerequisite—input only reaches the game while the Studio window renders (not minimized)—so an agent knows when the tool will not work.

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 indicate destructiveHint=true)Skiputations; the description thoroughly details cancel's behavior: stops at next yield/slice, rolls back edit-DM, job finishes with error.code 'cancelled'. It also explains survival across reconnects and expiration. This goes well beyond annotations, providing comprehensive behavioral context.

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 dense but organized by subcommands, front-loading the core purpose. Each sentence carries meaningful info (status format, wait limits, cancel rollback, expiration). Minor redundancy: repeating {job_id, status:'running'} and action details could be trimmed, but overall efficient.

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

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

Given no output schema, the description defines the exact output snapshot for status/wait (fields like status, op, dm, elapsed_ms). It covers all actions, edge cases (lost IDs, reconnect, expiration), and parameter constraints. An agent has full info to invoke correctly.

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

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

Schema description coverage is 67% (job_id and wait_ms are described, but action enum values are not). The description compensates by explaining each action's meaning and input expectations (e.g., wait_ms ≤ 50000). But it doesn't add additional parameter-level details beyond what schema provides, so a 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 that this tool tracks long operations and demonstrates the subcommands (status, wait, list, cancel) with their exact output formats. It clearly identifies the resource (job handles) and the actions available. However, it doesn't explicitly name sibling tools to differentiate from, relying on the subcommands to convey purpose.

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 to use each action: status to check progress, wait to block until finish, list to find lost IDs, cancel to stop and rollback. It also notes jobs survive reconnects and expire after 10 minutes, giving clear context. It doesn't explicitly say when NOT to use this tool versus alternatives, but the subcommands are self-contained.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=false, and openWorldHint=true, covering the safety and side-effect profile. The description adds valuable behavioral context: the screenshot never enters the user context, the tool returns a text answer, it can return 'not visible' when inconclusive, and it details watch termination conditions and failure handling. No contradictions 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 lengthy but information-dense, covering modes, parameters, providers, and examples. It front-loads the core purpose and the key benefit (text answer, no image tokens) before diving into details. Some redundancy, such as repeating model defaults, but each section serves a purpose. Not excessively verbose for the complexity.

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

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

Given the tool's complexity (one-shot, watch mode, region cropping, model overrides, provider differences), the description provides comprehensive coverage: it explains the output fields, event structure, diff_only behavior, stop conditions, and failure handling. It also references sibling tools for alternatives and lists concrete example questions. The schema and annotations cover the rest, so nothing critical 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% as all parameters are described in the schema. The description adds some context beyond schema, such as default values for interval_s (5, min 2; 15 on claude-cli) and max_frames (60), and notes diff_only default true. However, this is mostly redundant with the schema descriptions and adds limited new meaning, so baseline 3 is appropriate.

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

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

The description clearly states that the tool performs visual inspection of the Roblox Studio window via a vision model, returning text answers. It specifies the verb 'Look at' and resource 'the Roblox Studio window', and distinguishes from siblings by stating it is for pixel-level information, while exact state tools like observe are preferred for other queries.

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 guidance on when to use this tool versus alternatives: 'Prefer observe tree|props|find|player for state — they are exact and free. look is for what only pixels can tell.' It also explains when to use one-shot versus watch mode, and details the difference between providers and models.

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 indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds significant detail beyond these: it explains that 'screenshot' works occluded and un-minimizes without focus (with a 'restore' parameter), that 'geometry' samples beyond max and has tolerance for touching faces, that 'props' omits unreadable props, and that 'detailed' response has a ~200 KB cap. These behaviors are not implied by the annotations, so the description adds value. However, some behaviors like rate limits or auth are not mentioned, but not contradictory.

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 extremely long, listing every mode in bullet points with detailed sub-options. While it is well-structured and front-loaded with the core purpose, it is far from concise. Every sentence does add information, but the sheer volume makes it hard to scan. The formatting helps, but it could be trimmed by relying more on the schema for parameter details.

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 (33 parameters, 14 modes), the description is remarkably complete. It covers all major modes, explains output shapes, provides defaults, and gives usage tips. It even addresses edge cases like sample thresholds and response size limits. There is no output schema, so the description is the primary source for return value structure, and it handles this comprehensively.

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 97%, so the schema already documents most parameters well. However, the description adds critical context for parameters like 'max' (different defaults per mode), 'dm' (routing), 'wait_ms' (job handle behavior), and 'response_format' (size caps). It also explains that 'script' is not cut at 8 KB, which is not in the schema. Since coverage is high, the baseline is 3, but the extra semantic details justify a 4.

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?

Purpose is clearly stated as a 'Read-only view of Studio' with a comprehensive list of read operations (status, tree, props, find, diff, logs, script, stats, selection, geometry, player, screenshot, windows, selftest). It distinguishes itself from siblings by emphasizing it is read-only, while siblings like 'run' and 'playtest' likely perform actions. The description is specific and resource-oriented, making it easy to identify when to use this 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?

Provides explicit guidance on when to use different modes, e.g., 'Prefer structured reads (exact, cheap); screenshots only for visual checks (`look` answers them in text).' It also explains when to use 'dm' to route reads into playtest, and mentions 'selftest: use after install or when results look wrong.' While it doesn't name sibling alternatives explicitly, it references the sibling 'look' for visual checks, and the structured reads vs. screenshots trade-off is clearly stated.

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

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

Annotations declare destructiveHint=true, and the description elaborates on this: 'push ... ephemeral, not undoable' and 'replace (default true) removes a same-name, same-class sibling first (never Terrain, the camera, a character)'. It also discloses the restart cost (~3 s), state loss ('loses play-DM state'), persistence semantics ('persist: kept by the bridge, re-installed whenever that DM appears in a later playtest'), and async behavior ('Slow actions return {job_id, status:"running"} after wait_ms; use `job`'). This goes well beyond the annotations, which only say destructiveHint=true. The only minor gap is that it doesn't explicitly state that start/stop are also destructive in the sense of ending a running playtest, but the 'Keep ONE playtest alive' warning covers that.

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 dense but well-structured: it opens with the most important constraint ('Keep ONE playtest alive'), then groups actions with their parameters in a compact notation. Every sentence carries information: the restart cost, the no_peer workaround, the predicate semantics, the persist behavior, the push replacement rules, and the async job handle note. It loses one point because the density makes it somewhat hard to parse at a glance – the action-parameter groupings are packed into a single paragraph without line breaks, and an agent might need to re-read to extract the exact parameter list for a given action. Still, it is far from verbose and front-loads the critical warning.

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

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

For a tool with 23 parameters, no output schema, and a complex multi-action surface, the description covers the essential behavioral context: what each action does, which parameters apply, what the return values look like (e.g., {running, mode, players, peers, started_ms}), and the async job handle pattern. It also covers edge cases like no_peer, persist, and replace. It doesn't fully document every return shape for every action (e.g., status returns {running, mode, players, peers, elapsed_s, controllers} but stop only shows {stopped_ms}), and it doesn't explain the `args` parameter's role in run_until beyond 'available to the program as ARGS'. Given the tool's complexity, these are minor gaps; the description is remarkably complete for a 23-parameter tool.

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

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

Schema description coverage is 96%, so the schema already documents most parameters. The description adds meaning by grouping parameters with their actions (e.g., 'start {mode: play|run|multiplayer, players}', 'run_until {dm, predicate | predicate_file, timeout_ms ≤ 120000, interval_ms, args}'), which clarifies which parameters apply to which action. It also adds constraints not fully in the schema, such as 'players (1-8, default 2)' and 'timeout_ms ≤ 120000'. The description doesn't repeat every schema description, but it adds the action-parameter mapping that the flat schema lacks. A 4 is appropriate because the schema does most of the work, but the description adds meaningful grouping and defaults.

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 clear verb and resource: 'Control the live playtest and the in-engine runtime.' It then enumerates each action (start, stop, status, run_until, install, uninstall, list, hotpatch, push) with its specific purpose, which distinguishes it from sibling tools like observe, look, run, input, events, skills, job, and cloud. The scope is unambiguous: this is the tool for managing playtests and the live DM runtime, not for observing or running code in other contexts.

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 guidance: 'Keep ONE playtest alive; a restart costs ~3 s and loses play-DM state.' It also gives conditional guidance for multiplayer ('no_peer: turn on "Load User Plugins In Run Modes" / install the plugin'), for run_until ('Luau predicate evaluated in-engine each Heartbeat until truthy'), and for push ('replace (default true) removes a same-name, same-class sibling first'). It names alternatives implicitly by listing all actions and their parameters, and the sibling list shows this is the only playtest control tool. The description also warns about slow actions returning job handles, which tells the agent when to expect async behavior.

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

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

Annotations carry only destructiveHint=true and no readOnly/idempotent flags, so the description must carry the behavioral burden—and it does. It discloses rollback semantics per dm mode ('ONE ChangeHistory recording… rolled back on error/timeout'), ephemerality of play DMs, geometry enforcement with policy outcomes, the running-job escape hatch, and the FIFO queue. None of this contradicts the annotations; it substantially extends them.

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

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

It is long, but the tool is complex and the density is justified. The text is organized into scannable blocks (dm modes, code input, S API, geometry, results/errors, long-running) and front-loads the core contract before enumerating API details. Every section earns its place, even if a future pass could trim the S-method listing.

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

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

Given 11 params, no output schema, and a mutation-heavy tool, the description is unusually complete: it defines the success result shape, error envelope with codes, geometry report structure, long-running job handle, and undo/dry-run caveats. It even covers edge cases like a raw `:Destroy()` not being rolled back. Nothing essential is missing for an agent to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds real value on top by explaining `code_file`'s bypass of shell/JSON escaping, `geometry_policy` outcomes in the result, `response_format`'s effect on CFrames, `dry_run` rollback limits, and `session` requirements. Slight gap: `args`/`timeout_ms` rely on the schema alone, but that is acceptable at full coverage.

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: 'Run a Luau program in Roblox Studio against the resident S API.' It goes beyond the name by defining the execution model ('Ship whole programs, not micro-calls') and enumerating provided globals, distinguishing it from siblings like playtest, observe, and job.

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

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

It gives explicit direction on when to use the tool: 'Ship whole programs, not micro-calls' and 'build, query and verify in one call,' and it points to the sibling `job` for long-running programs ('use `job`'). It also flags what not to do ('Never heredoc Luau') and when `session` is required. It doesn't contrast every sibling explicitly, but the context is clear enough for selection.

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

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

The description discloses important behavioral traits beyond the annotations: builtins are read-only, saving over a builtin overrides it, deleting the override restores it, and builtins themselves cannot be deleted. It also notes that run geometry is checked exactly as for `run`. The annotations already mark the tool destructive, and the description aligns with and expands on that.

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 dense but well-organized: it opens with a one-line definition and purpose, then compactly lists action signatures, then covers builtin behavior. Minor redundancy exists in repeating the run-result equivalence, but overall every sentence earns its place by conveying action-specific or behavioral information not present in the schema.

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

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

Given the tool's complexity (15 parameters, five actions, no output schema), the description covers the main action modes, return shapes, builtin handling, override semantics, and geometry behavior. It leans on the sibling `run` for the full run result shape, which is acceptable given the context signals, but it is not entirely self-contained.

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 93% schema description coverage, the schema does most parameter documentation work. The description adds action-specific parameter grouping (e.g., save uses source | source_file, run uses dm/undo_label/dry_run/etc.) and clarifies the relationship between source and source_file. This goes beyond the flat schema definitions and helps an agent assemble valid calls per action.

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 identifies the resource as a Luau program library on disk and enumerates five distinct actions (list, get, save, delete, run) with their signatures and result shapes. It also contrasts with the sibling `run` by noting skills run in the same environment and result shape as `run`, making the tool's purpose and scope 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?

The description gives practical guidance: 'Save programs you will run again; run them with args' and explicitly states that execution matches the `run` tool. It also explains builtin read-only behavior and override/restore semantics. It does not explicitly say when to prefer this over direct `run`, but the context strongly implies the distinction.

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