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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only diagnostic but never states that it has no side effects, what failure modes mean (bridge down vs plugin not connected), or whether it blocks/retries.

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

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

A single tight sentence with the primary subject front-loaded and no filler. It is appropriately sized, though it leaves room for a short follow-on clause about what the result indicates.

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

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

There is no output schema, so the description should describe what the status result looks like (e.g. connected/disconnected states, error meaning) but does not. For a diagnostic tool that other Studio tools likely depend on, this leaves a real gap.

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

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

The tool takes zero parameters, so the baseline of 4 applies; there is no parameter surface for the description to clarify or for the schema to hide.

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

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

The description gives a specific verb ('Check') and two concrete resources ('HTTP bridge status', 'Studio plugin connection'), so an agent knows exactly what it inspects. It does not differentiate from siblings like studio_status or studio_launch, which sound adjacent and could plausibly overlap.

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

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

There is no statement of when to call this versus studio_status or studio_launch, no prerequisites, and no troubleshooting context (e.g. 'call this first if other Studio tools fail'). The agent must infer usage entirely from the name.

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

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

No annotations are provided, so the description carries the behavioral burden. It usefully discloses atomicity-style traits ('one undo step, one roundtrip'), but says nothing about what happens on partial failure, whether all requested items are returned, or any permission requirements.

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

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

Three tight fragments, front-loaded with the core benefit (MANY in ONE call) before the item shape and the room-building scenario. No wasted wording.

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

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

For a mutation tool with no annotations and no output schema, the definition covers the input shape and the atomicity benefit but omits the return value (e.g., created instances/IDs) and error semantics on partial failure. Adequate but with clear gaps.

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

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

Schema description coverage is 100% and there is a single parameter, so the schema already documents the item shape. The description merely restates {className, name?, parent?, properties?} without adding format rules, defaults, or constraints beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource (Create ... instances) with the distinguishing scope 'MANY in ONE call', which clearly separates it from the singular create_instance sibling. An agent can select it without opening the schema.

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

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

Implies usage through rationale ('one undo step, one roundtrip') and a concrete scenario ('Building a whole room in a single call'), which guides selection toward bulk work. However, it never explicitly names create_instance as the alternative or states when to prefer it, so the routing guidance is only implied.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Clear' honestly signals a destructive action, but the description doesn't say whether the discarded output is recoverable, whether there is an undo, or whether any state is required first. For a zero-annotation mutating tool, this is a meaningful gap.

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

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

A single sentence with the action and target front-loaded and no wasted words. It is appropriately sized for a trivial zero-argument tool.

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

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

For a zero-parameter tool with no output schema, the description is nearly complete: the action and target are clear. It could add a line about the consequence (buffer emptied, prior output lost) but nothing essential is missing for correct invocation.

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

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

The tool takes zero parameters, so the baseline of 4 applies. The description correctly implies no arguments are needed to specify what to clear, since there is only one output buffer.

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

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

States a specific verb (clear) and resource (plugin-captured output buffer), which is unambiguous. It doesn't explicitly name the complementary sibling get_output, but the resource is distinctive enough to separate it from other tools.

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

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

There is no statement of when to clear the buffer, when not to, or how it relates to get_output. The agent must infer usage entirely from the verb, and no prerequisites or conditions are given.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it mostly repeats schema facts (parent defaults to StarterGui). It does not state what happens on failure, whether an existing ScreenGui is overwritten, what the call returns, or any Studio-bridge/auth requirement for a mutation tool.

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

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

Compact and front-loaded: the core action comes first, followed by the parent location and the child spec. The parenthetical element list is slightly listy but every clause carries information.

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

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

For a nested-object, mutation tool with no annotations and no output schema, the description covers the input structure well but omits the result semantics (what is returned/which instances exist afterward) and error behavior. Adequate but with clear gaps for this complexity level.

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

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

Schema coverage is already 100%, so the baseline is 3, but the description adds real value by specifying the recursive child shape ({className, name, properties, children}) that the schema only labels as 'Nested element specs'. This is the key semantic an agent needs to build a nested GUI tree.

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

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

States a specific verb and resource ('creates ScreenGui') and scopes it to the GUI domain with concrete element examples (Frame/TextButton/TextLabel/ImageLabel). It implicitly separates itself from the generic create_instance/create_script siblings, but never names an alternative explicitly, so the differentiation is inferential rather than stated.

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

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

'Build GUI quickly' implies the intended scenario (mass-creating a GUI hierarchy in one call), but there is no explicit when-to-use vs. when-not, no mention of create_instance/bulk_create for non-GUI work, and no prerequisites such as an active Studio connection.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet for a mutating tool it says nothing about required permissions, error behavior on an invalid className or property, whether the creation is undoable, or what happens when a non-BasePart class receives an unsupported property. The only behavioral hint is the value-encoding convention, which is more parameter than behavior.

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

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

Two sentences, zero filler, with the core action and examples front-loaded and the value-encoding rule appended as a second, self-contained clause. Every element earns its place.

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

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

With no annotations, no output schema, and a nested free-form properties object, the description covers the creation call adequately but omits what the call returns (instance path/reference) despite sibling tools like get_instance, set_property and delete_instance operating on paths. An agent cannot tell from the description how to address the instance it just created.

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

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

Schema description coverage is only 50% (name and properties are undocumented), and the description fills the most important gap: the opaque 'properties' object accepts Roblox typed values via {__type:'Vector3'|'Color3'|'UDim2'|'CFrame'|'BrickColor', value:...} or plain JSON. That encoding rule is essential and unavailable in the schema, though it does not cover the 'name' parameter or default naming.

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

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

States a specific verb (Create) and resource (any Instance) and enumerates concrete class examples (Part, Model, Folder, PointLight, SelectionBox), which distinguishes it from specialized siblings like create_script and create_gui. No sibling is named as an alternative, so it stops short of full differentiation.

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

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

Usage is implied by 'Create any Instance' with optional parent/name/properties, but there is no explicit guidance on when to prefer this over create_script, create_gui, or bulk_create for multiple instances. The agent must infer routing from the sibling names alone.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about where the script lands beyond the parent parameter, whether creation requires an active Studio session, whether source is optional, whether the operation is undoable, or what is returned. It only restates the create action.

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

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

A single compact sentence with the verb and resource front-loaded and no filler. The slash-delimited type list is slightly terse but readable and mirrors the enum exactly.

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

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

For a mutation tool with no annotations and no output schema, the description is thin: it omits preconditions, the optionality of source, failure modes for bad parent paths, and post-creation state. An agent could call it, but not with confidence about side effects.

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

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

Schema coverage is 75%, just below the high-coverage threshold, and the description only restates the scriptType enum values already documented in the schema. It adds no syntax or format detail for 'parent' or 'source' beyond what the schema descriptions provide, so it neither compensates nor enriches.

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

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

States a specific verb (create) and resource (Script/LocalScript/ModuleScript), and the type enumeration matches the schema enum, so an agent knows exactly what this produces. It is separable from generic siblings like create_instance and bulk_create, though it never names them explicitly.

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

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

No when-to-use guidance at all: nothing says whether to prefer this over create_instance, write_script, or insert_asset, nor what preconditions exist (e.g., an open place). Usage is only inferrable from the resource name.

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

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

No annotations are provided, so the description carries the full burden, and it says nothing beyond the bare mutation. It omits whether deletion is permanent or undoable (an `undo` sibling exists), whether descendants are removed with the instance, permission requirements, and error behavior for a bad path.

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

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

A single front-loaded sentence with zero filler and no redundancy. It is appropriately sized for the amount of content it conveys, though the content itself is thin.

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

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

For a destructive mutation with no annotations, no output schema, and an undocumented parameter, the definition is too sparse. An agent cannot tell what gets destroyed, whether it is recoverable, or what a failure looks like.

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

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

One parameter with 0% schema description coverage, so the description must compensate. "By path" does tell the agent the identifier is a path handle rather than a name or UUID, which is genuinely useful, but the format/origin of that path is still undefined.

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

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

States a specific verb+resource ("Delete an instance") and the identifying key ("by path"), which distinguishes it from create_instance, duplicate_instance, and rename_instance. It does not explicitly name those siblings as alternatives, but the action is unambiguous.

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

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

No guidance on when to use this versus delete_script, undo, or any other removal path, and no prerequisites (does the instance need to be unselected? does it recurse?). The agent must infer everything about context.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Delete' implies an irreversible mutation, but it does not say whether the file goes to trash, whether it is recoverable via the sibling undo tool, whether it requires the script to be closed, or what happens if the path does not exist.

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

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

A single seven-word sentence with the operation front-loaded and no padding. It is efficient, though there is no structure to speak of because there is so little content.

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

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

For a destructive mutation with no annotations, no output schema and no parameter documentation, the description is too thin. An agent cannot determine reversibility, error behavior on a missing path, or authorization needs before calling it.

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

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

Schema coverage is 0% and the single parameter is only named 'path' with type string. The description's 'by path' merely echoes the parameter name, adding no format details (absolute vs relative, .lua extension, project-relative roots). The schema is trivially simple, so the gap is small but real.

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

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

States a specific verb (delete) and resource (script) plus the lookup key (path), which cleanly separates it from read_script, write_script, create_script and list_scripts. It does not explicitly name a sibling, but the operation is unambiguous from the name/description pair.

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

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

No guidance on when to use this instead of write_script (to empty a script) or delete_instance, and no prerequisites or warnings. The agent must infer usage entirely from the name.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it under-delivers. It does not say where the copy is placed (same parent/sibling), whether the original is untouched, what the copy is named by default, or whether the new instance becomes selected — all relevant for a mutation tool in a Studio-editing context.

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

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

One front-loaded sentence with no filler or redundancy. It is efficient, though its brevity sits at the edge of under-specification given the absence of annotations and schema documentation.

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

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

For a mutation tool with no annotations, no output schema and 0% parameter documentation, this single sentence leaves too much unspecified — placement of the clone, default naming, and path format are all missing.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies that newName is optional ("optionally with a new name") but says nothing about what form 'path' takes (full path vs. instance name) or what happens to naming when newName is omitted.

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

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

"Duplicate (clone) an instance" states a specific verb and resource, and the parenthetical makes the intent unambiguous. It does not, however, contrast itself with create_instance or get_instance, so the agent must infer the distinction.

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

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

There is no explicit when-to-use guidance and no named alternative. The phrase "optionally with a new name" faintly implies the clone can be renamed inline instead of calling rename_instance, but that routing is left to inference rather than stated.

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

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

With no annotations, the description carries the full burden and does reasonably well: it discloses undo support, that return values and prints are captured, that multi-line code is allowed, and that execution happens in the Studio plugin context. It stops short of stating what can be destroyed, permission/auth requirements, or error/rate-limit behavior for arbitrary code, which are meaningful omissions for a high-power execution tool.

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

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

Three sentences, front-loaded with the core action, analogy, and output behavior. The 'unlocks EVERYTHING' clause is slightly promotional but does real routing work by signaling scope. No wasted sentences.

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

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

For a parameterized code-execution tool with no annotations and no output schema, the description covers the essentials: what runs, in what context, what comes back, and the undo affordance. It lacks safety/permission caveats and failure behavior, so it's strong but not exhaustive.

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

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

Schema description coverage is 100% – both 'code' and 'timeoutMs' are documented in the schema, including the `return ...` convention and the default timeout. The description adds little parameter-level meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Execute arbitrary Luau code inside Roblox Studio') and grounds it with a recognizable analogy ('Command-Bar equivalent'). The line about unlocking Toolbox, tools, services, and physics positions it as the general-purpose escape hatch relative to the many granular siblings (create_instance, set_property, etc.), so an agent can distinguish it without opening another schema.

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

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

Implied usage is clear: this is the catch-all for anything the specialized tools don't cover. However, there is no explicit when-to-use vs. when-not (e.g., 'prefer the dedicated tools for simple edits; use this for multi-step or uncovered operations') and no prerequisites named. Guidance is inferred rather than stated.

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

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

With no annotations, the description must carry the behavioral burden. It discloses scope (whole game) and a performance trait (faster than a full scene dump), which is useful, but says nothing about return format, whether paths/parents are included, result ordering, or the pagination limit behavior that the 500-cap suggests matters.

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

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

One tight sentence plus a concrete example, front-loaded with the core purpose and followed by the performance motivation. No filler or redundancy.

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

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

For a 4-parameter, no-output-schema search tool, the description covers the intent but omits what a caller receives (list of instances? paths? structured objects?) and how to page past the default 100 hits. Those are meaningful gaps when no output schema exists.

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

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

Schema coverage is 100%, so root, limit, className, and nameContains are already fully documented in the schema, including defaults and the max of 500. The description echoes name/class filtering but adds no semantic detail (e.g., how root interacts with className) beyond the schema.

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

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

States a specific verb (search) and resource (instances across the whole game) plus the two filter dimensions (name and/or class). It implicitly distinguishes itself from scene-dumping siblings via 'faster than dumping the full scene,' though it never names get_scene or get_children explicitly.

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

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

Provides an example use case ('all Scripts with Boss in the name') and a comparative hint against dumping the scene, which implies when to prefer it. However, no alternative tool is named and there is no explicit when-not-to-use guidance.

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

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

With no annotations, the description carries the full behavioral burden. It discloses what state is returned (CFrame components, Focus, FieldOfView), which implies a non-mutating read, but it never states read-only semantics, side effects, or whether the camera must be active in a Studio session.

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

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

A single front-loaded sentence with no filler. The verb comes first and the parenthetical scope list is compact and informative.

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

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

With no output schema, the description partially compensates by naming the key returned values, which is what an agent needs from a zero-parameter getter. It stops short of full completeness by omitting the read-only guarantee and any output structure detail.

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

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

The tool takes zero parameters, so there is nothing to document and the baseline of 4 applies. The description's parenthetical list describes return fields rather than parameters, which is harmless but not parameter-relevant.

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

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

The description gives a specific verb+resource ('Get current Studio camera') and enumerates the returned state (CFrame components, Focus, FieldOfView). The get/set pairing with the sibling set_camera makes the direction of the operation unambiguous, though it never names or contrasts that sibling explicitly.

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

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

Usage is only implied by the verb 'Get' with no parameters — an agent infers it is a read of current camera state. There is no statement of when to call this versus set_camera, get_scene, or execute_luau, and no prerequisites are mentioned.

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

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

With no annotations, the description must carry the behavioral burden. It discloses that the listing is shallow and returns Name/ClassName/Path, which is useful, but it does not mention permissions, error behavior, or confirm read-only status beyond the word 'List'.

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

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

The description is a single, front-loaded sentence with no wasted words. It states the action, scope, and return shape immediately.

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

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

For a simple one-parameter read tool with no output schema, the description usefully states the return fields, but it leaves the path syntax and any usage context unexplained. It is adequate but leaves clear gaps.

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

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

The single 'path' parameter has 0% schema description coverage, so the description should compensate. It only says 'of one instance', giving minimal meaning about the expected path format (e.g., instance hierarchy syntax) and adding little beyond the schema.

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

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

The description states a specific verb ('List') and resource ('direct children of one instance'), and the 'shallow' qualifier clarifies that it does not recurse. It does not explicitly name a sibling tool, so it lacks the explicit differentiation that would earn a 5.

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

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

There is no statement of when to use this tool versus alternatives such as get_instance, get_scene, or find_instances. The description only implies usage through the stated purpose and offers no conditions, exclusions, or prerequisites.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Get' implies a read, but it says nothing about the return shape, whether properties are fully serialized or reference/child-truncated, error behavior for an invalid or nonexistent path, or any permission prerequisites.

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

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

A single sentence with the verb, resource, addressing format, and a worked example front-loaded. Nothing is redundant and nothing is padded.

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

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

There is no output schema and no annotations, so the description should at least sketch what 'properties' means in the response. For a one-parameter read tool the purpose is clear enough to call, but the return-value gap leaves the agent guessing about the shape of the result.

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

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

Schema coverage is 0% for the single 'path' parameter, so the description must compensate, and it does: it specifies the dotted-path format and gives a concrete example ('Workspace.SpawnLocation'). What it does not clarify is indexing syntax for array children or how ambiguous names are resolved.

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

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

States a specific verb ('Get') and resource ('properties of one instance'), and the dotted-path example pins down the addressing model. It does not name or distinguish itself from near-neighbours such as get_scene, find_instances, or get_children, so the boundary is left to inference.

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

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

The phrase 'one instance by dotted path' implies the use case (a single, already-known instance), which implicitly contrasts with find_instances/get_children. However there is no explicit when-to-use, no exclusions, and no mention of how to obtain a valid path or what to do when the path is unknown.

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

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

With no annotations, the description carries the full behavioral burden, yet it does not state that this is a read-only operation, whether it requires elevated permissions, or how results are returned. Only the word 'Get' implies a safe read.

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

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

A single front-loaded sentence with no filler; it delivers verb, resource, and representative return fields immediately.

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

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

For a zero-parameter getter with no annotations or output schema, the description gives a useful sample of returned properties. It stops short of enumerating the full return shape or noting that results reflect current Studio lighting, but it is largely sufficient.

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

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

The tool has zero parameters, so per the rubric the baseline is 4. The property examples describe return content rather than inputs, which is beyond the schema's empty parameter object.

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

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

States a specific verb ('Get') and resource ('Lighting properties'), and lists concrete property names (ClockTime, Brightness, Ambient). This distinguishes it from the sibling set_lighting, which mutates the same resource.

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

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

No guidance on when to use this tool versus alternatives like get_scene or get_instance. The description implies retrieval but never states prerequisites, context, or exclusions.

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

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

With no annotations, the description carries the full behavioral burden and does not state whether this is a read-only operation, whether it requires an active Studio bridge, what 'recent' means, or how much log history is returned. 'Captured by the plugin' hints at the source but not the connection/auth requirements.

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

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

A single tight sentence that is front-loaded with the action and resource. It is efficient, though the terseness leaves meaningful gaps rather than being truly complete.

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

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

For a read tool with no annotations, no output schema, and an undocumented parameter, the description is too thin. It omits return shape, connection requirements, log scope, and default limit behavior that an agent needs to invoke it correctly.

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

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

The single 'limit' parameter has 0% schema description coverage, and the description does not explain its meaning, units, or default (behavior when omitted is unstated). The description adds no semantic value to compensate for the schema gap.

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

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

States a specific verb (Get) and resource (Studio Output log lines) with added context that they were captured by the plugin. This distinguishes it from the sibling clear_output, which clears rather than retrieves, though it does not explicitly name that sibling.

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

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

There is no guidance on when to use this versus alternatives or on prerequisites (e.g., requiring a connected Studio session or an active plugin). The implicit complementarity with clear_output is left for the agent to infer.

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

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

With no annotations, the description carries the full burden. It discloses that this is a read operation ('Read') and that the stats are live, and it lists the scope of metrics. It does not mention session prerequisites (e.g., Studio connection or active playtest), but for a simple read-only diagnostic tool this is largely sufficient.

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

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

Two short sentences, front-loaded with the core purpose and metrics, followed by the diagnostic use case. Every phrase earns its place; there is no redundant or filler text.

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

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

Given the low complexity, zero parameters, no output schema, and no annotations, the description is nearly complete: it states the purpose, lists the metrics, and gives a practical use case. The only minor gap is the absence of explicit session prerequisites or return-format details, but the listed metrics imply the output.

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

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

The tool takes zero parameters, so parameter semantics baseline is 4 per the rules. The description does not need to explain any input arguments, and it appropriately focuses on what the tool returns rather than on non-existent inputs.

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

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

The description states a specific verb ('Read') and resource ('live Studio performance stats'), and enumerates the exact metrics returned (FPS, frame time, physics, contacts, memory). It clearly distinguishes this tool from all siblings, none of which report performance data.

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

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

It gives a clear diagnostic context — 'Diagnose weak laptop vs real bugs' — which tells an agent when this tool is useful. However, it does not state explicit exclusions, prerequisites, or alternatives (e.g., when not to use it, or whether it requires an active playtest).

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

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

No annotations exist, so the description carries the disclosure burden; it does disclose the shape of the returned state, which matters because there is no output schema. However, it does not explain what values 'mode' can take, whether the read is cheap/side-effect-free, or how the flags relate to the playtest lifecycle.

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

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

One short sentence, front-loaded with the verb, with the parenthetical return fields appended compactly. No filler, no restating of the title.

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

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

For a zero-parameter read-only status getter with no annotations and no output schema, the description supplies the key return fields an agent needs to interpret the result. It is nearly complete, missing only the meaning/enumeration of the 'mode' value.

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

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

The tool takes zero parameters, so the baseline is 4. The description adds return-field semantics (isPlaying, isRunning, mode) but nothing about parameters is needed or possible.

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

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

Specific verb ('Get') plus resource ('current playtest state') with the returned fields named inline (isPlaying, isRunning, mode). It is clearly distinguishable from the playtest-control siblings (play_solo, run_game, stop_playtest), though it never says so explicitly.

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

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

Usage is implied by the name: query the playtest status, presumably before or after calling playtest/play_solo/run_game/stop_playtest. There is no explicit when-to-use statement, no mention of the control tools it complements, and no prerequisite or polling guidance.

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

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

With no annotations, the description carries the full behavioral burden; it does disclose that output is a descendant tree with ClassName/Name/Path. However it never mentions that results are truncated by maxNodes/maxDepth defaults (300 nodes / depth 3), which materially affects interpretation of a listing tool.

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

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

Two compact sentences, operation stated first, usage second — no filler. Well front-loaded.

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

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

No output schema exists, and the description compensates by naming the returned fields, but it omits any mention of truncation/limits the caller must know about for a potentially large tree. Otherwise complete for a read-only listing tool.

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

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

Schema description coverage is 100%, so root, maxDepth, maxNodes and includeProperties are already documented with types, defaults and caps. The description adds only the notion of a root parameter and nothing beyond schema baseline.

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

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

States a specific verb and resource — 'List scene tree (descendants) from a root' — and names the returned fields (ClassName/Name/Path). The 'descendants' scoping implicitly separates it from get_children/get_instance, though no sibling is named explicitly.

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

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

'Use for viewing the scene, finding GUI, checking builds' supplies concrete use contexts. It gives no explicit exclusions or named alternatives (e.g. get_children for one level), but the intended scenarios are clear.

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

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

No annotations are provided, so the description carries the full burden. It implies a safe read and hints that results are 'paths', but says nothing about behavior when nothing is selected, the return shape, or whether it requires an active Studio session.

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

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

A single short sentence with the key information front-loaded and no filler. It is arguably under-specified rather than bloated, so it stays efficient.

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

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

For a trivial zero-arg read tool with no output schema, the description gives the minimum viable picture. It leaves the actual return type (list of path strings vs instance references) unstated, which is the main remaining gap.

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

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

Zero parameters, which is the baseline-4 case. The description correctly implies no arguments are needed and adds no misleading parameter claims.

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

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

Specific verb+resource: 'Get current Studio selection' clearly states it retrieves the active selection, and the '(paths)' hint narrows the semantics. It does not explicitly name the inverse sibling set_selection, but the get/set verb pairing makes the distinction obvious to an agent.

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

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

No guidance on when to use this versus alternatives such as get_scene or get_instance, nor any prerequisite or state requirement (e.g. a place must be open). Usage is only implied by the verb.

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

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

No annotations exist, so the description carries the full burden. 'Get' strongly implies a non-mutating read and the enumerated fields describe what comes back, which is genuinely useful given there is no output schema. However, it says nothing about permissions, cost, or whether the values are cached/live.

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

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

A single compact sentence with the identifying noun up front and the payload listed after; no padding, no restatement of the title.

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

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

With no output schema, the description must convey the return shape, and it does so by naming the five stats. For a zero-parameter getter this is nearly sufficient; only the absent read-only/behavioral framing keeps it from being complete.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline of 4 applies. The enumerated stats describe outputs rather than inputs, which is a reasonable use of the space.

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

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

States a specific verb (Get) and resource (Workspace stats) and enumerates the exact fields returned: child count, part count, gravity, streaming, place name. This distinguishes it from stat-adjacent siblings like get_performance or studio_status, though it never names them.

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

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

There is no when-to-use guidance, no statement of prerequisites, and no mention of alternatives such as get_scene or get_performance, which an agent could plausibly confuse with this. Usage must be inferred entirely from the field list.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only search and hints at two matching modes (Lua pattern vs substring) but never states which is used, whether matching is literal or regex-flavored by default, whether the search is scoped or global, or what kind of results come back. Saying 'Lua pattern / substring' actually introduces ambiguity rather than resolving it.

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

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

A single tight sentence with the object of the search front-loaded. It is efficient, though the brevity here reflects under-specification as much as economy.

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

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

For a search tool with no annotations, no output schema, and two undocumented parameters, this is insufficient. An agent cannot know the default match semantics, the scope of the search, or the result shape, and there is no way to discover this from the structured fields.

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

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

Schema description coverage is 0% and neither parameter is documented in the schema. The description only gestures at the 'pattern' parameter (and muddies whether it is a Lua pattern or a plain substring); the 'root' parameter, which likely controls what the search is scoped to, is completely unexplained.

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

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

States a specific verb (search) and resource (script sources) plus what it matches (Lua pattern or substring), which is more informative than a bare name restatement. However it does not distinguish itself from siblings like list_scripts, read_script, or find_instances, so an agent must infer the boundary.

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

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

There is no when-to-use guidance and no mention of alternatives. Nothing tells the agent whether to prefer grep_scripts over list_scripts plus read_script, or when a substring search is appropriate versus a full read.

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

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

Annotations are absent, so the description carries the full burden. It says nothing about prerequisites (does the asset need to be free/owned?), whether this requires an open Studio session or network access, how failures are surfaced, or that it mutates the place -- all material for an insert operation, though the LoadAsset reference does hint at the auth model.

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

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

One compact sentence, front-loaded with the verb and resource, followed by an API reference and a brief example. Every element is brief and none is wasted, though the trailing 'E.g.' adds little.

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

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

For a two-parameter tool with full schema coverage and no output schema, the description covers the essentials: what is inserted, by what identifier, and via which API. It omits failure/permission behavior and what the caller receives back, so it is adequate but not complete.

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

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

Schema description coverage is 100%, with both 'parent' (default Workspace) and 'assetId' documented inline, so the baseline is 3. The description only restates that the ID is numeric, adding nothing beyond the schema.

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

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

The description states a specific verb and resource -- insert an asset by numeric ID into the game -- and cites the underlying operation (InsertService:LoadAsset), so an agent knows exactly what happens. It does not name or distinguish itself from the nearby toolbox_search/toolbox_info siblings, which would have made it a 5.

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

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

There is no when-to-use or when-not-to-use guidance and no alternative tool is named. 'E.g. free models, meshes' illustrates asset types rather than usage context, so the agent must infer that this follows a toolbox_search or a known assetId on its own.

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

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

With no annotations, the description carries the full behavioral burden. It usefully scopes the tool to a 'playtest character', implying a running playtest session is required, but it omits whether the operation errors outside a playtest, whether the kill is reversible, and that only the target player is affected. Useful context, but incomplete for a destructive action.

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

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

One sentence, action front-loaded, with a compact parenthetical for intent. No wasted words or redundant restatement of the tool name.

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

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

For a simple one-parameter tool with no output schema, the description covers purpose and rough context adequately, and the schema covers the parameter. It falls short on the preconditions and side effects an agent needs before firing a destructive playtest action (state requirements, error behavior, reversibility).

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

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

Schema coverage is 100%: the single optional 'player' parameter, including its 'default: first player' behavior, is fully documented in the schema. The description adds nothing about the parameter, so the baseline 3 applies when the schema does all the work.

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

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

Specific verb + resource ('kill a playtest character') with the intent spelled out (testing death screens, respawn, Entity kills). It is clearly the inverse of respawn_player, though it never names that sibling explicitly, so perfect sibling differentiation is left to inference.

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

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

The parenthetical lists scenarios (death screens, respawn, Entity kills), which implies this is a mid-playtest testing action rather than a general operation. There is no explicit when-not guidance or named alternative (e.g. respawn_player to undo, or stop_playtest), so usage is implied rather than stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. It is clearly a read operation and it usefully discloses the default root ('game'), but it says nothing about recursion depth, result shape (paths vs. instances), volume limits, or pagination — all relevant for a tree-traversal listing.

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

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

A single front-loaded sentence with no filler; the scope qualifier and default value are packed efficiently into one clause.

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

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

For a simple no-output-schema list tool the description covers the essentials, but with zero annotation coverage and no return-shape disclosure an agent still cannot predict whether results are recursive, what identifiers come back, or whether there are size limits.

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

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

Schema coverage is 0% for the single 'root' parameter, so the description must compensate. It does add real meaning by noting the parameter is a root container and defaults to 'game', but stops short of specifying the expected format (instance path string vs. reference) or how deep the traversal goes.

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

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

States a specific verb (List) and resource (Script/LocalScript/ModuleScript), and clarifies the scope is 'under a root'. It is distinguishable from grep_scripts and create_script by naming the exact instance classes, though it doesn't explicitly contrast with siblings like get_children or find_instances.

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

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

Usage is only implied by the verb — an agent can infer this is for enumerating scripts, but there is no explicit when-to-use, no when-not-to-use, and no pointer to alternatives such as grep_scripts for content search or find_instances for generic enumeration.

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

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

No annotations exist, so the description carries the full disclosure burden. It does reveal that this launches a playtest session and names verification tools, but omits whether Studio must already be open, whether it ends/replaces a running session, or whether it blocks.

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

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

Two short sentences: the action is front-loaded, and the second sentence is pure routing value with no filler. Nothing is padded or restated.

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

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

For a no-param start action with no output schema, the essential 'what it does' and 'what to do next' are covered. Missing preconditions (Studio/bridge state) and disambiguation from the closely related playtest, run_game, and stop_playtest siblings leave a gap.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly adds no parameter prose, and the empty schema has no semantics left to document.

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

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

States a specific verb and resource: 'Start Play Solo playtest (F5)'. The (F5) cue identifies the mode distinctly from the generic sibling playtest/run_game, though it never says explicitly what makes it different from those tools.

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

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

Gives downstream guidance ('Agent can then check behavior via get_output / get_play_state / execute_luau'), which implies the intended workflow after invocation. It does not say when to choose this over siblings like playtest or run_game, nor any exclusion or precondition.

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

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

With no annotations, the description carries the burden and does well: it discloses the sequential behavior (start Play Solo/Run, wait, capture Output + play state, stop, return report). It omits failure/timeout handling, whether the call blocks, and connection prerequisites, but the operational flow is clearly conveyed.

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

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

Two sentences, front-loaded with the key differentiator ('FULL playtest in ONE call'), and the step sequence follows immediately. No wasted words.

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

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

With no output schema, the description usefully states what the report contains (Output + play state), covering the return value at a high level. It could specify report structure or failure modes, but for this composite tool it is largely complete.

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

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

Schema description coverage is 100%, so the schema already documents mode, seconds, and outputLimit with enums and defaults. The description adds only 'waits N seconds' and the mode names, which are redundant with the schema. Baseline 3 applies.

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

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

The description states a specific verb and resource ('FULL playtest in ONE call') and enumerates the composite steps -- start, wait, capture, stop, return. This clearly distinguishes it from the granular siblings (play_solo, get_output, get_play_state, stop_playtest) by showing it collapses them into a single call.

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

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

'The core of the agent debug loop' implies the primary use case, giving useful context. However, no explicit when-to-use/when-not guidance or named alternatives (e.g., using the granular step tools for finer control) are provided, so selection is left to inference.

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

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

No annotations are provided, so the description carries the full burden. 'Read' implies a safe, non-mutating operation, but it says nothing about permission requirements, behavior when the path does not resolve, truncation of large sources, or whether the returned source is the live script text.

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

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

One sentence, front-loaded with the action and resource, with the example paths appended tightly. Nothing is wasted and no filler is present.

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

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

For a one-parameter read tool with no output schema, the description covers how to address the script but not what comes back (the source text) or error behavior for an unresolved path. Adequate but with a visible gap around the return value.

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

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

The schema has 0% description coverage and the single required 'path' parameter is bare, but the description compensates by giving two concrete dot-notation path examples, which is exactly the format detail the schema omits.

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

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

States a specific verb+resource ('Read Source of a script') and the path format with concrete examples like 'ServerScriptService.MyScript'. An agent can distinguish this from write_script, list_scripts, and grep_scripts, though siblings are never named explicitly.

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

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

No when-to-use guidance and no routing to alternatives. With siblings like list_scripts and grep_scripts present, the description never says whether to reach for this tool versus those for inspecting scripts.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, yet only states the basic action. It doesn't say what happens when there is nothing to redo, whether the change is re-applied silently, or whether it requires Studio to be connected/active.

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

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

A single, front-loaded sentence with zero waste. Appropriate for a simple zero-argument action.

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

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

For a trivial zero-param tool the description is serviceable, but with no annotations and no output schema it omits edge-case behavior (empty history, error conditions) that an agent would want before invoking a state-mutating command.

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

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

The tool takes zero parameters, so there is no parameter semantics to document; the baseline for a no-arg tool applies. Nothing misleading is present.

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

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

States a specific verb ('Redo') and resource ('last undone Studio change'), which is precise enough to distinguish it from its obvious sibling 'undo'. It stops short of naming the sibling explicitly, but the pairing is unambiguous.

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

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

Usage is implied by the description ('last undone change') and the presence of a sibling 'undo' tool, but there is no explicit guidance on when to use it, what happens if the undo history is empty, or interaction with the undo sibling.

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

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

With no annotations, the description carries the full behavioral burden, and it discloses only that a mutation occurs. It does not state whether renames propagate to references, whether reserved/duplicate names are rejected, what permissions are needed, or what happens on failure. For a mutation tool with zero annotation coverage this is a significant gap.

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

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

The single sentence is efficient and front-loaded, so it is not verbose. But brevity here stems from under-specification rather than tight writing, so it earns only a middling score.

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

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

A mutation tool with no annotations, no output schema, and two fully undocumented parameters needs substantially more description to be safely callable. Nothing about return value, failure modes, or naming constraints is covered anywhere in the structured fields.

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

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

Schema coverage is 0% for two required, undocumented parameters. The description never clarifies what 'path' means (a full instance path string? a dotted hierarchy?) or any constraints on 'newName' (length, uniqueness, allowed characters). With no compensating detail, an agent must guess at the input format.

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

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

States a specific verb and resource ('Rename an instance'), so the basic action is unambiguous. However, it offers no differentiation from siblings that also affect instance names, notably set_property (which could rename via the Name property) or duplicate_instance. The purpose is clear but sibling-blind.

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

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

There is no guidance on when to use rename_instance versus alternatives like set_property with a Name attribute, nor any prerequisites (e.g., a locked or read-only instance, ownership constraints). The agent is given no context for tool selection.

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

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

With no annotations, the description carries the full behavioral burden. It does not disclose whether children move along with the instance, whether the old parent reference is cleared, whether cycles or invalid parents cause errors, or what the call returns on success or failure. For a mutation tool this is a meaningful gap.

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

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

A single short sentence with the action front-loaded and zero wasted words. It is appropriately sized, though so terse that conciseness shades into under-specification.

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

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

For a two-parameter mutation tool with no annotations and no output schema, the definition omits too much: the 'path' parameter's meaning, the effect on children, and failure behavior are all unstated. An agent could invoke it, but not confidently predict the outcome.

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

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

Schema coverage is only 50%: 'newParent' has a schema description and example, but 'path' (the instance being moved) is undocumented in both schema and description. The description adds no format or semantics beyond the word 'parent', so it fails to compensate for the coverage gap.

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

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

The description gives a specific verb ('Move') and resource ('an instance') with the target destination ('to a new parent'), so the action is immediately unambiguous. It does not explicitly distinguish itself from adjacent siblings such as duplicate_instance or create_instance, but the operation is distinct enough that an agent can place it.

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

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

There is no statement of when to use this tool versus alternatives (e.g., creating a new instance under a target parent instead of moving an existing one). No prerequisites, no conditions, no exclusions are given; the agent must infer usage entirely from the name and description.

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

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

No annotations are provided, so the description carries the full burden. It never states whether a playtest session must be active, whether the player must be alive, what happens to the existing character, or whether the action requires elevated permissions — all material for a force-mutation tool.

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

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

One short sentence with the action front-loaded and a useful parenthetical use case. No filler, though it is arguably terse for a state-mutating tool.

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

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

For a mutation tool with zero annotations and no output schema, the description should at least state the precondition (an active playtest) and the effect on the player. Neither is present, leaving the agent guessing about safe invocation.

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

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

Schema coverage is 100%, with the single parameter documented as 'Player name (default: first player)'. The description adds no syntax, format, or lookup guidance beyond what the schema already provides, so the baseline of 3 applies.

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

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

States a specific verb ('Force-respawn') and resource ('a playtest character'), and the parenthetical clarifies the testing intent. It doesn't explicitly contrast with nearby siblings like kill_player or teleport_player, but the action is unambiguous.

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

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

The parenthetical '(tests spawn logic, retry buttons)' implies the scenario where this tool is appropriate, which is more than nothing. However, it names no alternatives (e.g., kill_player + playtest) and gives no when-not condition, so usage must be inferred.

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

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

With no annotations, the description carries the full disclosure burden. It does add real behavioral context — this is a server-only, player-less simulation, so no client-side player state exists — but it says nothing about prerequisites (Studio connection, an open place), whether it disrupts an existing session, or how the run terminates (the sibling stop_playtest).

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

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

A single short sentence that leads with the action and follows with the disambiguating detail. No filler, nothing redundant with the name.

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

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

For a no-parameter, no-output action tool this is nearly sufficient: an agent knows what it starts and what that mode means. The remaining gap is lifecycle context (that stop_playtest ends it and that Studio must be up), which is minor given the sibling list.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline of 4 applies to a no-argument action tool.

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

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

Names a specific action (start) and target (Run mode), and the parenthetical 'F8, server-only simulation without player' concretely defines what mode is being started. It doesn't explicitly contrast with the sibling playtest/play_solo tools, so an agent must infer which mode is which, but the purpose itself is unambiguous.

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

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

The phrase 'without player' implicitly signals when this is preferable to a player-inclusive playtest, but the description never names or excludes the obvious alternatives (playtest, play_solo). Usage is therefore only implied, not stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not say whether this overwrites the existing file, whether it works for never-saved places, what permissions or Studio connection state are required, or what happens on failure — all material for a write-to-disk operation.

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

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

Two short sentences with the core action front-loaded and no filler. Slightly under-specified rather than verbose, but structurally efficient.

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

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

With no annotations and no output schema, the description must supply the surrounding context, and it does not. Missing are the save semantics (overwrite vs save-as), preconditions, return value, and error behavior, leaving an agent unable to predict the outcome of the call.

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

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

Schema coverage is 0% for the single parameter, so the description must compensate. Saying filePath is an optional 'hint for logging' adds a little meaning, but it sits awkwardly against the claim that the place is saved 'to its file' — an agent cannot tell whether filePath influences the save target or is purely informational.

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

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

States a specific verb and resource ('Save the current place'), and the parenthetical '(to its file)' clarifies the destination is the place's own file rather than an arbitrary path. This is enough to distinguish it from siblings like studio_open_place and studio_list_places, though it never names those siblings explicitly.

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

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

No guidance on when to use this versus alternatives, nor any preconditions (e.g., a place must already be open, or a distinction between saving an existing file and an unsaved place). The only usage note is about an optional parameter, not about tool selection.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no statement that this mutates editor state, no undo/redo interaction, no permission or connection requirements, and no indication whether the change persists. Only the parameter formats are described.

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

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

One compact, front-loaded sentence with no filler; the parenthetical carries dense parameter information. Slightly telegraphic phrasing, but nothing is wasted.

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

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

For a mutation tool with no annotations and no output schema, the description leaves key invocation ambiguities unresolved: whether a CFrame supersedes position/focus, which parameters are required (schema says none), and what happens when only one is supplied. It is not adequate for correct invocation without guesswork.

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

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

Schema coverage is 0% (all three properties are empty), so the description must compensate, and it does: it specifies that position and focus are {x,y,z} vectors or CFrame tables and that fov is a number. It stops short of explaining how position and focus interact or which are optional.

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

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

Specific verb+resource: it moves (sets) the Studio camera and enumerates the fields it controls (position, focus, fov). The contrast with the sibling get_camera is implicit in the verb, but the description never explicitly differentiates itself from other camera or scene tools.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as execute_luau or playtest camera behavior. The agent must infer that this is the way to reposition the Studio viewport camera.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It only indicates that properties are set and lists examples; it omits whether the operation requires an open place, whether changes are permanent, what happens on invalid property names, or what the return value looks like.

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

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

The description is a single, front-loaded sentence with no wasted words. The trailing ellipsis is slightly unhelpful, but otherwise the structure is efficient.

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

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

For a mutation tool with a nested object parameter, no annotations, and no output schema, the description is too thin. An agent would still lack essential context such as required permissions, the shape of the 'properties' object, and how to handle unknown property names.

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

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

Schema coverage is 0% and the only parameter ('properties') is an undocumented nested object. The description partially compensates by listing example property names (ClockTime, Brightness, Ambient, etc.), but it does not explain the expected map structure or value formats.

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

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

The description states a specific verb ('Set') and resource ('Lighting properties'), and gives concrete examples of the properties involved. It distinguishes itself from 'get_lighting' by the verb, but does not explain how it differs from siblings like 'set_property' or 'set_properties'.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as 'set_property' or 'set_properties'. The reader must infer usage from the name and description alone, with no conditions or exclusions provided.

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

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

With no annotations, the description carries the full behavioral burden and does not meet it. It does not disclose whether existing properties are merged or replaced, whether the write is reversible, what permissions are required, or whether it errors on partial failure.

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

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

A single front-loaded sentence with no filler, so it is well-structured and readable. Its brevity, however, reflects under-specification rather than disciplined trimming of richer content.

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

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

For a mutation tool with no annotations, no output schema, 0% schema coverage, and a nested-object parameter, this one sentence is inadequate. An agent lacks merge/replace semantics, error behavior, and property-format details needed to call it correctly.

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

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

Schema description coverage is 0%, so neither "path" nor the nested "properties" object is documented anywhere. The description maps loosely to the properties parameter but gives no format, key-naming, or value-syntax guidance for the nested object, leaving the gap uncompensated.

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

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

States a specific verb+resource ("Set ... properties on an instance") and adds scope with "multiple ... at once," which implicitly distinguishes it from the singular sibling set_property. It is clear enough to select, though it never names the sibling it complements.

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

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

No explicit when-to-use or when-not. The phrase "at once" hints at a batching role versus set_property, but the agent is left to infer that the batch tool should be preferred for multiple writes. No prerequisites or exclusions are stated.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose permission requirements, error behavior for unknown paths/properties, or how flexible types are handled for 'value'. For a mutation tool with zero annotation coverage this is a real gap.

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

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

A single efficient sentence with the action front-loaded and compact illustrative examples. No wasted words, though it is arguably too terse given the undocumented parameters.

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

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

With no annotations, no output schema, and 0% parameter documentation, the description should do more. It omits value-type handling, error semantics, and path format, leaving an agent under-equipped for a mutation tool.

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

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

Schema description coverage is 0% for all three parameters. The examples imply that 'path' is an instance path, 'property' a property name, and 'value' the new setting, but no format details, accepted value types, or path syntax are given to compensate for the coverage gap.

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

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

States a specific verb and resource ('Set a single property on an instance') and gives concrete examples (Anchored=true, Color, Position). The word 'single' implicitly contrasts with the sibling set_properties, though it never names it explicitly.

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

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

No explicit when-to-use or when-not-to-use guidance. The 'single property' framing hints that set_properties is the multi-property alternative, but the agent must infer this rather than being told.

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

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

No annotations are provided, so the description must carry behavioral disclosure. It states the selection is set to given paths but omits whether existing selection is replaced, what an empty array does, required Studio state, or path format constraints.

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

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

A single front-loaded sentence with no wasted words. It is appropriately sized for a simple setter tool.

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

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

For a state-mutating tool with no annotations, no output schema, and an undocumented parameter, the description is too thin. An agent lacks enough detail to invoke it correctly without guessing path syntax and selection semantics.

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

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

Schema description coverage is 0% for the single required 'paths' parameter. The description calls them 'instance paths', which adds marginal meaning beyond the parameter name, but does not explain format, hierarchy, or accepted values.

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

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

States a specific verb 'Set' and resource 'Studio selection', making the action clear. It does not explicitly differentiate from siblings like get_selection, though the verb implies the inverse. No sibling is named to guide selection.

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

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

The description offers no when-to-use guidance, prerequisites, or alternatives. It does not mention get_selection or any condition under which setting selection is appropriate versus other operations.

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

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

With no annotations, the description carries the full behavioral burden. It does not say what happens if no playtest is running, whether in-progress state is discarded or saved, whether the call is idempotent, or what the caller receives — all meaningful for a state-changing control action.

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

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

A single short sentence with the action front-loaded and no filler. Nothing in it is wasted.

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

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

For a trivial no-arg control tool with no output schema, the description is close to sufficient, but it omits the no-op case (no playtest running) and any indication of the resulting state, which is the one thing an agent might need to handle correctly.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No argument syntax is needed or expected.

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

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

States a specific verb ('Stop') and resource ('any running playtest / Run mode'), so an agent can distinguish it from start-side siblings like playtest, run_game, and play_solo. It does not explicitly name those siblings, but the action is unambiguous.

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

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

Usage is only implied by the word 'running' — the agent infers it should be called when a playtest is active, and get_play_state is the sibling that would confirm that. No explicit when-to-use, precondition, or alternative is stated.

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

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

With no annotations, the description must carry the behavioral burden. It does disclose the mechanism ('taskkill'), which implies a forceful termination of every instance rather than a graceful save-and-quit, but it omits the critical consequence for this class of tool: unsaved work is lost and the action is irreversible (undo/redo siblings cannot help).

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

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

A single front-loaded sentence with zero filler, and the parenthetical mechanism note earns its place by clarifying how the close is performed. Nothing could be trimmed without losing information.

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

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

For a zero-parameter, no-output-schema action tool, the description covers what happens and how. The one meaningful gap is the absence of any warning that unsaved place state is discarded, which matters because sibling tools include save_place and undo.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly implies a no-argument, all-instances scope, and there is nothing further to document.

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

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

States a specific verb ('Close') and an unambiguous resource ('all running Roblox Studio instances'), which an agent can distinguish from siblings like stop_playtest or studio_status. It does not explicitly name the nearest confusable sibling, so it stops short of a 5.

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

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

The description says what the tool does but never when to reach for it versus alternatives such as stop_playtest (ends a session) or studio_status. There is no guidance on prerequisites, confirmation, or the conditions under which a hard process kill is appropriate.

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

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

With no annotations, the description carries the full burden. It does add genuine behavioral context by stating 'No plugin required,' implying an OS-level launch rather than a bridge/plugin launch, which matters given siblings like bridge_status and studio_status. However, it omits whether it blocks, whether launching with an existing instance conflicts, and permissions needed.

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

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

A single front-loaded sentence with no padding. It is appropriately sized, though the parenthetical could be tightened and could carry more routing information in the same space.

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

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

For a launch tool with 100% schema coverage and no annotations, the description covers the core action but leaves return behavior and interaction with an already-running Studio unspecified. Since no output schema exists, some indication of what happens on completion would help.

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

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

Schema description coverage is 100%, so the schema already documents placeId, placeFile, and universeId. The description echoes the two opening modes but adds no syntax, precedence, or mutual-exclusion detail beyond the schema; baseline 3 applies.

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

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

States a specific verb and resource ('Launch Roblox Studio') plus the optional opening modes (local .rbxl/.rbxlx file or published place). It does not distinguish itself from the close sibling studio_open_place, which appears to be a separate operation, so the scope boundary is unclear.

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

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

There is no guidance on when to use this versus studio_open_place or the plugin-based launch path. The 'No plugin required' note hints at a context, but it is not framed as a when-to-use condition, and no prerequisites or exclusions are stated.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the default scan behavior (common folders) and, together with the schema, the max-depth-3 traversal, but "common folders" is never defined and there is no statement of read-only nature, permissions, or result shape.

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

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

A single front-loaded sentence with the default behavior stated first and the override parenthetically. No filler or redundancy.

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

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

For a one-parameter, no-annotation tool with no output schema, the description is serviceable but thin: it neither enumerates which folders count as "common" nor indicates what the returned listing contains (paths, names, metadata). Just enough to call it, not enough to predict results.

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

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

Schema coverage is 100% and the single parameter is already documented as directories to scan with max depth 3. The description adds the useful nuance that dirs overrides the default common-folder scan, but supplies no format or default-value detail beyond that.

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

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

States a specific verb (List) and resource (.rbxl/.rbxlx place files), with the scope narrowed to local files in common or supplied folders. It contrasts implicitly with studio_open_place/studio_launch but never names a sibling, so it stops short of a 5.

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

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

There is no guidance on when to call this versus studio_open_place, studio_launch, or studio_status, nor any prerequisite or ordering note. Usage is only inferable from the name and the "or given dirs" phrase.

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

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

No annotations are provided, so the description carries the full disclosure burden. It says nothing about whether opening replaces the current session, whether a bridge/Studio instance must be active, whether the operation is destructive to unsaved work, or what happens on failure—all critical for an open/load operation.

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

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

A single front-loaded sentence with the verb and both input modes stated up front and no filler. It is efficient, though slightly terse for a tool whose structured metadata is this sparse.

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

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

With no annotations, no output schema, and 0% parameter description coverage, the description is the only source of truth, and it leaves the tool's lifecycle behavior (launch vs. attach, session replacement, error conditions) entirely undocumented. An agent can guess the input shape but not the consequences of calling it.

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

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

With 0% schema description coverage and three bare numeric/string params, the description compensates by mapping placeFile to a local .rbxl/.rbxlx file and placeId+universeId to a published place, and implies mutual exclusivity via 'either…or'. It still omits requiredness (schema says none required), what happens if both forms are supplied, and any ID format expectations.

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

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

States a specific verb ('Open') and resource ('a place in Roblox Studio'), and distinguishes two supported input modes (local file vs published placeId+universeId). It does not differentiate itself from siblings like studio_launch or the save_place/studio_close pair, so it stops short of a 5.

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

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

Usage is implied by naming the two input shapes, giving an agent a rough sense of when this applies, but there is no explicit guidance on when to choose this over studio_launch, whether Studio must already be running, or how it interacts with an already-open place.

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

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

No annotations are provided, so the description carries the burden. It communicates that this is an observational status check and previews the returned fields, but it does not state whether the tool errors, returns an empty result, or actually launches Studio when nothing is running.

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

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

One sentence, front-loaded with the verb and resource, with no filler. Every clause adds information.

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

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

With no output schema, listing the returned fields (PIDs, exe path, version) usefully compensates. The only gap is the not-running behavior, which matters for a status tool.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate beyond returning no input.

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

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

States a specific verb+resource ('Check if Roblox Studio is running') and enumerates the returned facts (PIDs, exe path, version). It is distinguishable from process-control siblings like studio_launch and studio_close, though it doesn't explicitly name an alternative such as bridge_status.

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

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

No when-to-use guidance at all. The agent can infer this is a pre-flight/diagnostic check before launching or executing, but the description never says when to reach for it versus studio_launch or bridge_status.

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

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

With no annotations, the description carries the full behavioral burden. It implies a mutation of the active playtest character's position and hints at a play-session precondition ('playtest character'), but says nothing about required game state, permission/authority needs, failure cases, or whether the move is reversible.

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

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

A single front-loaded sentence with the verb and resource first, plus a compact parenthetical of use cases. No filler, no redundancy with the title or schema.

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

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

For a simple two-optional-parameter tool with 100% schema coverage, the description covers purpose and usage scenarios adequately; no output schema exists, so return values need not be explained. It is only missing explicit precondition/state guidance for calling it, which keeps it from a 5.

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

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

Schema description coverage is 100%, so both 'player' and 'position' (including the Vector3 format) are already documented in the schema. The description adds no format, default, or constraint detail beyond the word 'position', so the baseline 3 applies.

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

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

States a specific verb and resource ('Teleport a playtest character to a position') with a scope qualifier ('playtest') that separates it from studio-editing tools. It is clear, but it never explicitly distinguishes itself from the closest player-affecting siblings (respawn_player, kill_player), so it falls just short of 5.

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

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

The parenthetical 'testing checkpoints, boss rooms, mazes without walking' gives concrete when-to-use context, which is genuinely helpful for an agent choosing among player tools. No exclusions or alternatives are named, so it does not reach the explicit when-not/alternative routing of a 5.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the returned fields and that no plugin is required, which is useful for a read-only metadata lookup, but it omits error behavior, rate limits, and what happens with invalid or missing IDs.

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

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

Two short, front-loaded sentences with zero waste. The core action and return fields come first, and the plugin note is a useful qualifier.

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

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

For a simple read tool with a complete one-parameter schema and no output schema, the description is nearly sufficient: it states the action, the input domain, the returned fields, and that no plugin is needed. It could round out by pointing to toolbox_search as the way to obtain asset IDs.

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

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

Schema description coverage is 100%, and the single parameter assetIds is fully documented as 'Up to 100 numeric asset IDs'. The description reinforces that these are catalog asset IDs but adds no format or syntax detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource: 'Get details for catalog asset IDs', and enumerates the returned fields (name, type, creator, description). This clearly distinguishes it from toolbox_search, which finds assets rather than retrieving known IDs, though the sibling relationship is not made explicit.

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

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

The only usage-related note is 'No plugin required', which is context rather than guidance. There is no statement about when to use this versus toolbox_search or insert_asset, nor any prerequisite like already having numeric asset IDs.

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

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

With no annotations, the description carries the full burden, and it does disclose one useful trait: no plugin dependency. However, it omits how pagination works, whether results are cached/rate-limited, and what happens on empty results, so behavioral coverage is only partial.

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

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

Two tight sentences with zero filler; the capability statement and the handoff-to-insert_asset detail are both front-loaded and each earns its place.

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

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

For a 4-parameter read-style search with no annotations and no output schema, the description covers purpose, result type, and next step. It could say more about result ordering, paging behavior, or result count limits, but what is present is sufficient to call the tool correctly.

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

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

Schema coverage is 100%, so all four parameters are already documented with examples and value hints in the schema. The description adds no syntax, default, or format detail beyond what the schema provides, so the baseline of 3 applies.

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

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

States a specific verb (Search) and resource (Roblox Toolbox/catalog) plus the asset types covered. It also distinguishes itself from siblings by naming insert_asset as the downstream consumer and toolbox_info implicitly by scoping to search.

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

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

The description explicitly tells the agent what to do with the results ('asset IDs you can pass to insert_asset') and clarifies 'No plugin required', which is real invocation context. It stops short of naming when *not* to use it versus toolbox_info or another lookup path.

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

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

With no annotations, the description carries the full burden, and it does disclose the underlying mechanism (ChangeHistoryService), implying the operation is session-scoped and only affects editor-tracked changes. However, it says nothing about failure modes, whether the undo is reversible via redo, or whether it interleaves with other agents' changes.

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

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

A single front-loaded sentence with no filler; the action and its scope appear in the first three words. It is efficient, though the brevity leaves open questions that the definition never returns to address.

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

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

For a zero-parameter, no-output-schema tool this is nearly sufficient, but the absence of annotations and of any note on empty-history behavior or the undo/redo pairing leaves a small but real gap. Adequate rather than complete.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The parenthetical service reference is consistent with a no-argument operation.

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

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

States a specific verb (undo) and resource (last Studio change), and names the underlying mechanism (ChangeHistoryService), which scopes it to editor history rather than file or network state. It does not explicitly differentiate itself from its natural sibling 'redo', leaving the agent to infer the pairing.

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

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

No when-to-use guidance, no mention of the complementary 'redo' tool, and no conditions stated (e.g., behavior when the change history is empty or when a playtest is running). The agent must infer that this applies only after a mutating operation in the current Studio session.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It says it overwrites source of an existing script, implying destruction of prior content, but omits permissions, reversibility, error handling for missing scripts, and side effects.

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

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

A single front-loaded sentence with no wasted words. However, its extreme brevity contributes to underspecification rather than efficient completeness.

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

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

For a mutation tool with no annotations and no output schema, the description is too sparse. It should cover path format, overwrite behavior, and potential errors to be complete.

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

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

Schema description coverage is 0%, so the description must explain the two parameters. It alludes to a 'Source' (source) and an 'existing script' (path), but provides no format, constraints, or examples, leaving both parameters underspecified.

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

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

States a specific verb 'Overwrite' and resource 'Source of an existing script', making the core action clear. It implicitly distinguishes itself from create_script/read_script by targeting an existing script, but does not explicitly name alternatives.

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

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

Offers no guidance on when to use this tool versus create_script, read_script, or other script tools. No prerequisites, exclusions, or alternative conditions are given.

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