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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this tool can mutate state. The description adds a credit-spend warning not present in annotations, which is useful, but it does not explain what 'call' actually changes, whether actions are reversible, or how results are returned.

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 short and front-loads the main actions, but the sentence 'Includes logs, screenshots, input, assets.' is ambiguous and does not clearly earn its place. The action-to-parameter mapping is also left implicit, reducing structural clarity.

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

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

For a complex meta-tool with six parameters, nested objects, a destructive annotation, and no output schema, the description is severely incomplete. It omits return value details, how arguments are used in the call action, and the specific consequences of each action, leaving the agent under-informed.

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 six parameters, so the description must carry full parameter meaning. It hints at uses (e.g., 'names' for list, 'describe ONE schema', 'page a saved result') but never explicitly maps parameters like tool, arguments, result_id, limit, or offset to their actions, falling far short of compensating 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 enumerates several actions (list, describe, call, result) that map to the action enum, but it never states a single clear verb+resource for the tool as a whole. It does not differentiate itself from the many sibling roblox_* tools, leaving the agent to guess when to use this advanced interface.

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 guidance is 'use only when asked' tied to credit spending. There is no explicit when-to-use, when-not, or comparison to sibling tools, leaving the selection criteria largely to inference.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and non-idempotency. The description adds genuinely valuable context beyond that: the whole batch is a single Undo recording and any failure cancels the batch (atomicity), which is critical for a destructive multi-operation call, plus the typed-value encoding format.

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?

Extremely dense and front-loaded: the action list leads, followed by atomicity, then type encoding, then addressing. Every sentence carries information, though the telegraphic fragments (e.g. 'Use as/ref to address newly created instances') trade readability for brevity.

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, nested-operation mutation tool with no output schema, the description covers the essentials: what it mutates, that edits are atomic and undoable, how values are typed, and how new instances are referenced. It omits return/error shape and operation-limit behavior (maxItems 100), but the core calling contract is 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?

With 50% schema coverage, the description must compensate. It does add the typed-value grammar for the 'value' parameter (Vector3/Color3/CFrame/UDim2/Enum/Instance) and explains the as/ref addressing mechanism, which the schema leaves as bare strings. But it says nothing about path, parent, properties, remove, or name, so the coverage gap is only partially filled.

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

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

The description names the specific resource (Roblox instances) and enumerates the seven operations it performs (create/set/move/clone/delete/attribute/tag), so an agent knows exactly what the tool does. It does not explicitly differentiate itself from siblings like roblox_script or roblox_query, but the operation list is distinctive enough to imply the scope.

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 closing constraint 'Edit mode only' gives one clear usage condition, and the action list implies batch editing is the use case. However, it never says when to prefer this over roblox_script or roblox_advanced, and no alternative is named, leaving routing to inference.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so safety is covered. The description adds that only requested properties plus attributes/tags/child count are returned, which is useful since there is no output schema, but it omits limits, error behavior for bad paths, and result size characteristics.

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 clauses, zero filler, with the retrieval scope front-loaded and the path convention appended. Appropriately sized for a simple read 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?

With no output schema the description partially carries the return-value burden by naming what is inspected. It is still thin on path failure cases, the 30-property cap, and whether inspection recurses into children, which matters given the 64-element path limit.

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

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

At 33% schema coverage the description must compensate, and it does explain path as an array of exact names with [] meaning game — a genuinely necessary detail. However it only gestures at the properties parameter ('requested properties') and says nothing about the maxItems caps or the studio_id reference.

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 (Inspect) and resource (an instance) plus exactly what is retrieved: properties, attributes, tags, child count. This contrasts implicitly with mutating siblings like roblox_edit and roblox_script, 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 guidance on when to choose this over roblox_query or roblox_advanced, and no stated prerequisites or exclusions. The reader must infer it is the read/inspect counterpart to the edit tools.

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

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

Annotations already flag destructive=true and non-idempotent, and the description reinforces this with 'Arbitrary code may mutate the game'. It adds genuinely new behavioral context beyond annotations: 'no automatic retries', so the caller must handle failure itself, and 'Return compact aggregates', which hints at response 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?

Five telegraphic clauses, front-loaded with the core action and scope, and every clause carries information (context modes, precondition, risk, retry policy). Style is terse rather than padded, though the fragmentary phrasing slightly hurts readability.

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, non-idempotent code-execution tool with no output schema, the description covers the key gaps: execution context, prerequisite ID, mutation risk, and no-retry behavior, plus a note on return shape. Missing only guidance on which sibling to prefer and any sandboxing or size semantics for 'code'.

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 schema description coverage at only 33%, the description must compensate, and it partially does: it clarifies studio_id must be the official IDE/plugin ID (reinforcing the schema hint) and enumerates the Edit/Server/Client execution contexts. But the most important parameter, 'code', gets no semantic detail beyond the 200k length cap, so the compensation is incomplete.

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 (Execute) and resource (Luau code) and names the three datamodel contexts (Edit/Server/Client), which maps directly to the datamodel_type enum. However, it does not distinguish itself from close siblings like roblox_script or roblox_edit, leaving the agent to guess which execution tool to pick.

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 one hard prerequisite ('Official studio_id required') that routes the agent through roblox_studio first, and implies a raw code-execution use case. But it offers no explicit when-to-use vs alternatives among the seven siblings, nor any exclusion criteria.

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

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

Annotations already declare destructiveHint=true, non-idempotent, non-read-only, so the safety profile is covered structurally. The description adds lifecycle context (stop when finished), but never warns that 'stop' tears down playtest state or that 'start' mutates a running Studio session — meaningful behavioral detail the annotations alone imply but do not explain.

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 with the core action front-loaded, then the follow-up workflow. No filler, though the semicolon-chained clauses pack three distinct pieces of guidance into one breath.

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, so return values needn't be described, and both parameters are covered by schema or enum. Still, for a destructive lifecycle tool it omits what 'state' reports and what the session must look like before 'start' succeeds.

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 50%; studio_id is documented in-schema and action's enum self-documents state/start/stop. The description merely restates the same three verbs the enum already lists, adding no format, prerequisite, or validation detail.

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 (get state, start, stop) and resource (official playtest), which is clear and actionable. It does not explicitly differentiate itself from siblings like roblox_studio beyond naming the follow-up tools, but the lifecycle scope is unambiguous.

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

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

Gives real workflow routing: use roblox_luau Server/Client for assertions after start, advanced tools for logs, and stop when finished. This tells the agent the ordering and the alternatives, though it gives 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?

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description contributes real behavioral context by noting that count_only returns only a count in a single call and that results are paginated, but says nothing about error behavior, matching rules, or the shape of returned instances.

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

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

Four terse sentences with zero filler, and the governing concept (exact search) is front-loaded. The clipped style borders on under-specification rather than pure conciseness, so it falls short of a 5.

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

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

For a 10-parameter, no-output-schema search tool, the description is too thin. It never clarifies how name/tag/class filters combine, what 'exact' means versus the contains flag, or what a returned instance looks like, so an agent is left guessing on most of the call surface.

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 10%, so the description must carry the load, and it only explains count_only. Parameters such as tag, name, class, root, contains, children_only, limit and offset receive no elaboration in either place, leaving most of the 10-parameter surface undocumented.

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 operation (exact instance search) with a clear distinguishing qualifier ('exact'), so an agent knows it is a precise-match lookup rather than a fuzzy or tree traversal. It does not explicitly differentiate itself from siblings like roblox_get or roblox_advanced, which keeps it at a 4.

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 implies a search use case but gives no when-to-use condition or named alternative among the many siblings. The closest thing to guidance, 'No source/tree dump', hints at what other tools are for but never routes the agent explicitly.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds real context beyond that: replace requires a 'unique exact' match and write enforces an 'expected_source concurrency guard'. It still omits what happens on a non-unique match, permission requirements, and failure 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 tight sentences, front-loaded with the four modes and followed by the key anti-pattern. No filler, and the most decision-relevant content comes first.

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

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

For a 12-parameter mutation tool with 8% schema coverage and no output schema, the description is too thin. It neither compensates for the undocumented parameters nor explains per-action behavior or results, leaving the agent to guess for most inputs.

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 8% across 12 parameters, so the description must carry weight. It implies mappings for find (literal grep), replace (unique exact), expected_source (concurrency guard), and line-range params, but leaves root, path, offset, limit, line_count, and studio_id undocumented in both the description and 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 names the four concrete operations (read a line range, literal grep, exact replacement, write with a concurrency guard), which map cleanly onto the action enum. It is clearly distinct from lookup-oriented siblings, though it never explicitly restates the resource (script) beyond the tool name.

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 closing sentence 'Never read whole codebase to locate a name' implies using grep/find instead of read for name lookups, which is useful routing guidance. However, it gives no explicit when-to-use versus siblings like roblox_query, roblox_get, or roblox_edit, nor prerequisites for each action.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only the workflow hint about selecting IDs before edits; it says nothing about what 'state' returns, pagination, or session freshness.

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 no filler; the primary capability is stated first. The trailing workflow sentence is slightly cryptic but earns its place as the only usage guidance 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?

With no output schema, the description is the only place return content could be described, yet 'inspect official Studio state' leaves the shape of that state opaque. For a read-only two-mode tool this is adequate but leaves an agent guessing about what list and state actually yield.

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 50%: the studio_id field carries its own description, and the enum values list/state are self-describing. The description echoes both modes but adds no meaning beyond the schema for either parameter — no detail on what an official Studio ID looks like or what the 'state' inspection returns. Baseline 3 for partial coverage.

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

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

The description states two specific verb+resource modes that map directly to the action enum: listing Studio/plugin sessions and inspecting official Studio state. It distinguishes the tool as a discovery/inspection entry point in a large sibling set (roblox_edit, roblox_query, etc.), though it doesn't explicitly name which sibling to use for edits.

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?

"Select explicit IDs before edits" implies a workflow prerequisite (resolve IDs here before mutating via another tool) but does not name the alternative edit tool or state an explicit when-not-to-use condition. Usage is inferable but not spelled out.

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