Server Quality Checklist

Tool Scores

• viewportA
  3.5/5.0
  Behavior3/5

  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.

  Conciseness2/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines4/5

  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.

• performanceA
  4.1/5.0
  Behavior1/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• createA
  4.2/5.0
  Behavior4/5

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

  Annotations state this is a destructive mutation (readOnlyHint: false, destructiveHint: true), and the description aligns with that. Since annotations carry the primary burden here, the description adds value by clarifying the behavior at creation time: the 'undoable step' framing, atomicity with children, and the important caveat that paths are unknowable until the instance exists. The note about API validation against the live Roblox dump is a genuine behavioral insight beyond what annotations provide. Not a perfect 5 because the validation behavior could have mentioned what the sibling tool does for scripts (it does, via script_create).

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

  Conciseness4/5

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

  The description is dense but not bloated; it front-loads the core action, then explains the nested optimization, then gives the validation warning, then the sibling pointer. The only redundancy is that 'as one undoable step' appears in both the first sentence and the second paragraph, adding negligible value the second time.

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

  Completeness4/5

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

  For a destructive (but not irreversible in the Studio sense, since it's a single undo step) mutation tool, the description and annotations together tell an agent what it mutates, why it's safe to use in a loop (atomic), and how to avoid common error states (path guessing). The `parent` field being required only at top level is in the schema, but the description could have been more explicit about how nested children interact with the parent's absent `parent` field.

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

  Parameters4/5

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

  Schema has 100% coverage, so the description doesn't need to re-document parameters. It goes beyond the schema by explaining the rationale behind the `children` parameter (avoid path guessing) and hinting that property values follow Studio's display format ('12, 0, 5' for Vector3). A full point taken off only because it doesn't detail all possible property formats—it gives examples instead of an exhaustive list.

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

  Purpose4/5

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

  The description clearly states the tool creates instances with properties, attributes, and tags as one atomic undoable step. It mentions real behavior (schema validation, nested creation) that distinguishes it from generic creation tools. It loses a point because naming the sibling 'script_create' as the alternative for scripts is more thoroughly covered under 'Usage Guidelines', and the verbose initial sentence buries the core purpose slightly.

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

  Usage Guidelines5/5

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

  Explicitly names the alternative tool for script creation (script_create) and the exact condition for choosing it. The description also gives best-practice guidance on nesting vs. creating parents separately, stating which is preferable and why. This is textbook guidance on when and why to use the tool in a certain way.

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

• deleteA
  4.4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• assetsA
  4.5/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• moveA
  4.5/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• inspectA
  4.6/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• playtestA
  4.6/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• script_readA
  4.6/5.0
  Behavior5/5

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

  Annotations already cover read-only and idempotent hints, but the description adds valuable context: it reads the live editor buffer (including unsaved changes) and returns line numbers acceptable to script_edit. This goes beyond what annotations provide and warns against stale saved data.

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

  Conciseness5/5

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

  Front-loaded purpose in first sentence, followed by two concise paragraphs each adding essential context—source-buffer rationale and batching/range guidance. Every sentence earns its place with zero redundancy.

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

  Completeness4/5

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

  Covers critical operational details: live buffer source, line-number compatibility, batching, and range semantics. With no output schema, the note about line numbers hints at the return format, but an explicit return structure would make it fully complete.

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

  Parameters4/5

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

  Schema covers all parameters with descriptions, but the description adds operational semantics: startLine/endLine apply to all given paths, and paths should be batched. This clarifies parameter interaction beyond raw schema, earning above baseline.

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

  Purpose5/5

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

  Description clearly states it reads Luau source from scripts, and explicitly distinguishes from the script_edit sibling by noting line-number compatibility. The verb and resource are specific and unambiguous.

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

  Usage Guidelines4/5

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

  Provides concrete usage guidance: batch all scripts in one call, and explains that startLine/endLine apply uniformly across all given paths. It clarifies the data source (live buffer vs saved property) which informs when to use this tool, though it doesn't explicitly exclude other read-like siblings like script_grep.

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

• set_active_studioA
  4.6/5.0
  Behavior5/5

  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.

  Conciseness4/5

  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.

  Completeness5/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• geometryA
  4.7/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• modifyA
  4.7/5.0
  Behavior4/5

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

  Annotations already mark destructiveHint=true and readOnlyHint=false, so mutation is known. The description adds valuable transactional semantics: the batch is all-or-nothing with revert, and values use the Properties-panel notation. A 4 rather than 5 only because it doesn't spell out undo scope beyond 'one undoable step' (which it does state) or side effects on dependent instances, but annotations cover most of the safety profile.

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

  Conciseness5/5

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

  Four short paragraphs, each earning its place: purpose, batching pattern, atomicity, and notation pointer. Front-loaded with the core action. No fluff.

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

  Completeness5/5

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

  For a complex mutation tool with 100% schema coverage and no output schema, the description covers the critical behavioral aspects (batching, atomicity, notation, alternative for scripts) that aren't in the structured fields. An agent has enough to invoke it correctly. No output schema means no expectation to explain return values.

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

  Parameters4/5

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

  Schema description coverage is 100% and the schema itself explains fields in detail. The description additionally clarifies that multiple paths share one entry and references the notation details in the 'properties' field. It adds value by explaining the batching intent and pointing to a schema field rather than restating every parameter. A 4 because it leans on the schema for most detail, which is appropriate given 100% coverage.

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

  Purpose5/5

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

  States a specific verb+resource ('Sets properties, attributes and tags on existing instances') and distinguishes itself from siblings like 'create' (for new instances) and 'script_edit' (for changing a script's code). The scope is unambiguous.

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

  Usage Guidelines5/5

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

  Explicitly says to combine with 'find' to build path lists, and notes when to use 'script_edit' instead (for script code). This gives an agent clear decision criteria among siblings.

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

• studio_statusA
  4.7/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• treeA
  4.7/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• characterA
  4.8/5.0
  Behavior5/5

  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.

  Conciseness4/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• deviceA
  4.8/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• execute_luauA
  4.8/5.0
  Behavior5/5

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

  Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description discloses crucial behaviors: no input validation, no undo recording, no timeout (infinite loop hangs Studio), the print/return capture mechanism, and the playtest-specific loadstring limitation. It elaborates on edge cases and failure modes that the annotations only hint at, giving the agent a full behavioral picture.

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

  Conciseness4/5

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

  The description is lengthy but every paragraph serves a distinct purpose: purpose, when to use, output behavior, and edge cases. It is front-loaded with the primary action and then builds context. While compactness is slightly sacrificed, the density of critical operational details warrants the length for a tool with this power. It is efficiently structured and not repetitive.

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

  Completeness5/5

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

  Given the tool's complexity, absence of an output schema, and the fact that annotations only cover destructive/read-only hints, the description covers all agent-relevant aspects: return semantics (print/return/throw, table as structure), the undo caveat, the timeout risk, and the playtest mode difference. No critical behavioral aspect is left to inference, making it complete for safe and correct invocation.

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

  Parameters4/5

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

  The schema already describes both parameters fully (source and studioId), and the description adds extra context: the source param is granted plugin permissions and can access game/workspace/plugin APIs, and the studioId param defaults to the active Studio. For the playtest scenario, it explains the compilation alternative, adding meaning beyond the schema. Since schema coverage is 100%, the baseline is 3, but the description enriches the parameters with runtime details, justifying a 4.

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

  Purpose5/5

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

  The description states a specific action ('Runs Luau') and the exact context ('Studio's plugin context') and outcome ('returns whatever it printed, returned, or threw'). It also names the sibling tools it is not (create, modify, delete, move, script_edit, find) to explicitly distinguish itself as the escape hatch. This fully clarifies what the tool does and how it differs from alternatives.

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

  Usage Guidelines5/5

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

  The description gives explicit when-to-use and when-not-to-use guidance: 'Reach for it only when no dedicated tool fits' and lists the dedicated tools that validate and wrap writes. It then provides concrete good uses (reading unexposed data, one-off calculations, calling uncovered APIs) and highlights the consequences of using it (typos become runtime errors, changes may not be undoable). This is model usage guidance.

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

• undoA
  4.8/5.0
  Behavior5/5

  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.

  Conciseness4/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• collisionA
  4.9/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• debugA
  4.9/5.0
  Behavior5/5

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

  Annotations only state general hints (readOnly=false, openWorld=true, etc.). The description adds critical behavioral context: a capture breakpoint stops briefly and resumes on its own, a logMessage breakpoint never stops, only one breakpoint per line, and nothing leaves a thread stuck. It also clarifies session ownership and the inability to retroactively catch code. This far exceeds the annotation baseline and matches them without contradiction.

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

  Conciseness4/5

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

  The description is long but well-organized: an opening summary, sections on condition and logMessage, a comparison of costs, placement advice, session constraints, and a safety reassurance. Some sentences restate earlier points (e.g., 'So the two kinds cost different things'), and the anecdote about moving a breakpoint is illustrative but slightly extraneous. Overall it earns its length for a nuanced tool, but a tighter edit would slightly improve density.

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

  Completeness5/5

  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 covers all necessary operational details: how to set, clear, read snapshots, and handle exceptions. It explains return behavior ('gives you the whole frame — every local and its type'), common pitfalls (line placement, syntax errors, session timing), and reassures that it never blocks the thread. Nothing an agent needs to know 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.

  Parameters5/5

  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 beyond simple field definitions. It clarifies that `logMessage` is a Luau expression, not a template string, providing a concrete syntax example and warning against prose. It explains `condition` evaluation in scope and gives examples. It also explains how `mode` defaults and the semantics of `clear` and `snapshots`. These details are not in the schema and are essential for correct usage.

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

  Purpose5/5

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

  The description starts with a clear, specific statement: 'Sets breakpoints that record the stack and variables when they are hit, then reads back what they caught.' It distinguishes itself from a step debugger explicitly, and details two operational modes (log vs capture) with distinct purposes. The resource (breakpoints in scripts) and operations (set, clear, snapshots, exceptions) are unambiguous, and it differentiates from sibling tools like console and execute_luau.

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

  Usage Guidelines5/5

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

  The description provides explicit usage context: it explains when to use this tool versus a step debugger ('not possible this way'), when to prefer log vs capture ('Reach for the log when you know what to watch, the capture when you do not'), and directs reading log output via console. It also warns about placement (lines that do something) and timing (set before playtest). This gives an agent clear decision criteria.

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

• findA
  4.9/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• list_studiosA
  4.9/5.0
  Behavior5/5

  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.

  Conciseness4/5

  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.

  Completeness5/5

  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.

  Parameters5/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• apiA
  5/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters5/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• consoleA
  5/5.0
  Behavior5/5

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

  Description adds context beyond annotations: it explains that output is only available after plugin loaded, that client sessions are not reachable due to HTTP restrictions, and that filtering is available. No contradictions with readOnlyHint or idempotentHint.

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

  Conciseness5/5

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

  The description is structured: first states purpose, then usage context, then filtering tips, then session details. Although longer than the minimal, every sentence contributes valuable information without redundancy.

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

  Completeness5/5

  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 gives enough context: it specifies the content (prints, warnings, errors) and ordering (newest last). It also covers all parameters and edge cases (client sessions, pre-load). It is complete for an agent to call correctly.

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

  Parameters5/5

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

  Each parameter is described in schema, and the description adds clarifications: pattern uses Lua escaping with %, studioId affects which session's log is read, limit default and max are mentioned. This adds meaning beyond the schema.

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

  Purpose5/5

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

  Clearly states it reads the Studio Output window with specific content (prints, warnings, errors) and order (newest last). The verb and resource are specific, distinguishing it from sibling tools like script_read or execute_luau.

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

  Usage Guidelines5/5

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

  Explicitly mentions when to use it: after a playtest or execute_luau call to find out what happened. Provides filtering guidance (use level and pattern) and warns about limit. Also explains session-specific behavior, telling users to target the playtest studioId.

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

• inputA
  5/5.0
  Behavior5/5

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

  The description goes far beyond the annotations by revealing the non-obvious client-side execution model: input is delivered through a script parented into PlayerGui, and success is only reported after client confirmation. It also explains the on-screen pointer, ordering of steps, hold/after semantics, and error behavior when confirmation never arrives.

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

  Conciseness5/5

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

  The description is long but every sentence earns its place, covering purpose, usage boundaries, prerequisites, parameter behavior, and failure semantics. It is front-loaded with the core function and then progresses naturally to operational details an agent would need before calling the tool.

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

  Completeness5/5

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

  For a tool with no output schema and non-obvious execution behavior, the description is complete: prerequisites, alternatives, coordinate system, visual cursor behavior, client-side routing, confirmation semantics, and error handling are all covered. An agent can correctly select and invoke this tool without needing additional context.

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

  Parameters5/5

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

  Even though the schema already documents all parameters at 100% coverage, the description adds meaningful operational meaning: it clarifies the distinction between `hold` and `after`, explains that steps execute in order as a sequence, and defines mouse coordinates as viewport pixels from the top-left for use with screenshots. This enriches the schema without merely repeating it.

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

  Purpose5/5

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

  The description names a specific verb and resource: sending real keyboard and mouse input to a running playtest. It explicitly differentiates this from the sibling `character` tool, stating that `character` handles movement while this handles controls. The title also removes ambiguity from the generic tool name.

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

  Usage Guidelines5/5

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

  It gives explicit when-to-use guidance: use this for input-bound behaviors and `character` for movement. It also states a hard prerequisite (running playtest), tells the agent to use the playtest's studioId from `list_studios`, and recommends pairing with `screenshot` for coordinate targeting.

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

• screenshotA
  5/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters5/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• script_createA
  5/5.0
  Behavior5/5

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

  Discloses transactional behavior (created inside one ChangeHistoryService recording), a failure mode (Studio refuses while another recording is in progress), and that the response indicates whether the recording opened. This goes beyond the annotations' basic readOnly/destructive hints.

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

  Conciseness5/5

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

  Three concise paragraphs: purpose, batching/transaction details, and guidance/preference. Each sentence adds value with no redundancy. The most important information (what it does) is front-loaded.

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

  Completeness5/5

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

  Comprehensive for the tool's complexity: it covers creation, batching, undo, failure modes, parameter preferences, and sibling tools. Though no output schema is provided, the description hints at what the response contains (whether the recording opened).

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

  Parameters5/5

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

  Although the schema already describes all parameters (100% coverage), the description adds valuable context: the purpose of batching for undo, the interplay between `className` and `runContext`, and the recommendation to prefer `Script` over `LocalScript`. This enriches parameter understanding.

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

  Purpose5/5

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

  Clearly states it creates Script, LocalScript, or ModuleScript instances with source. Explicitly differentiates from `script_edit` for modifying existing scripts, so the agent knows exactly what this tool does.

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

  Usage Guidelines5/5

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

  Provides concrete usage guidance: batch related scripts for a single undo, prefer `Script` with `runContext: 'Client'` over `LocalScript`, and directs to `script_edit` for existing scripts. This helps the agent decide when to use this tool versus alternatives.

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

• script_editA
  5/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters5/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• script_grepA
  5/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters5/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.