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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint/openWorldHint, so 'idempotency=read-only' and 'Safety: read-only' add no value. The description does add cost=medium and the 'active-client' precondition, which are genuine context beyond the structured fields, but no return-shape or failure behavior detail.

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 purpose leads, which is good, but the dash-separated metadata block is partly redundant ('idempotency=read-only', 'Safety: read-only' duplicate annotations) and 'idempotency=read-only' conflates two distinct properties. Some statements do not earn their 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 output schema, the description carries the return-value burden but only says 'Produces: structured-result', which is too vague for a probe/matrix tool. 'On failure' guidance pointing to tool-schema helps, but what the matrix actually contains is underspecified.

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 there is a single optional threadContext whose schema description already explains it. 'Signature: { threadContext: number? }' merely restates the schema without adding format, default, or scoping meaning, 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?

The first sentence names a specific resource: a read-only matrix covering Actors, LuaStateProxy, event objects, and aliases. An agent can distinguish this enumeration/probe surface from siblings like list-actors or get-actor-details. It lacks an explicit contrast to those siblings, hence not 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?

'Phase: verify' and 'Requires: active-client' hint at a workflow position and a precondition, but the description never says when to choose this over list-actors, get-actor-details, or get-lua-state-actors. No when-not or alternative routing is 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?

Annotations already flag destructiveHint=true and idempotentHint=false, and the description adds real context beyond them: it changes persistent executor-side observer/hook state, requires active-client and explicit mutation approval, and needs confirm=true for start/stop. It stops short of describing exactly what observer state is left behind or how to recover it.

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

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

The key behavioral warning is front-loaded in the first sentence, and the phase/cost/safety lines are terse. The verbatim Signature block partially duplicates the input schema and adds density, but overall it remains compact and scannable.

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 'Produces: bounded-event-snapshot' line and 'Verify with: assert-state' pointer cover the return contract. Requirements, safety, and a failure fallback (inspect tool-schema) are all present, leaving little an agent must infer 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 description coverage is 100%, so the baseline is 3, but the description adds genuine meaning: confirm must be true before start/stop runs, and the buffer is bounded to 200 (matching the limit cap). The signature block itself mostly repeats schema fields, but the confirm and buffer details go beyond it.

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

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

The description states a concrete mechanism: connect to on_actor_added / on_actor_state_created, retain a bounded 200-event buffer, and poll it. This tells an agent what the tool does and how it differs from a live-scan approach. It does not explicitly name the nearest sibling (lua-state-event-monitor), so sibling differentiation is only implicit.

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 usage context (poll without repeated game-tree scans; start/stop require confirm=true) but never states when to prefer this over alternatives like lua-state-event-monitor or watch-value. The start/poll/stop lifecycle implies usage, but no explicit when-not guidance is present.

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 cover read-only/idempotent, but the description adds non-obvious behavior: it never silently chooses between distinct accounts, capability probing is safe but slower, and the tool never mutates game state. It also gives a failure path (inspect tool-schema), which annotations cannot convey.

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

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

Front-loads 'READ-ONLY' and the core purpose efficiently, then structures the rest. However, the trailing 'Phase: observe; cost=medium; idempotency=read-only' and the full signature line partially duplicate the annotations and schema, adding mild 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?

There is no output schema, so the description must describe return contents, and it does: connected clients, selection resolution, game identity, executor identity/capabilities, and next steps. Combined with usage triggers and failure guidance, an agent has everything needed to call and interpret 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 description coverage is 100%, so all seven optional parameters and their defaults are already documented in the schema. The signature line in the description largely restates the schema (listing them as 'any?') rather than adding format or interaction guidance, 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 ('Bootstrap an AI agent with the current MCP/session/game context in one call') and enumerates exactly what the brief contains. It is clearly distinguishable from siblings like get-active-client, get-game-info, and get-executor-info because it is the aggregating one-call bootstrap rather than a single-field getter.

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

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

Explicitly says when to use it ('at the start of a task or after a reconnect') and what it replaces ('instead of separately guessing which client, place, executor, or capability set is active'). It even states the disambiguation behavior when multiple clients are connected, which is a real routing rule an agent needs.

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

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

Annotations already cover readOnly/idempotent/destructive/openWorld, but the description adds real behavioral context: memory is scoped by game/place/executor, persisted only to the local playbook store (not the game), 'do not store secrets or tokens', and failure recovery via tool-schema. It does not describe the recall return shape or any capacity/retention 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?

Purpose and usage are front-loaded, which is good, but the long 'Signature: { operation: ... }' block is pure duplication of the 100%-covered schema, and the Phase/cost/idempotency/Safety tail repeats annotation data. Roughly a third of the text does not earn 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 an 8-param tool with nested facts and no output schema, the description covers operations, scoping, storage location, and safety caveats, and points to tool-schema on failure. The main gap is that recall's structured-result format is never described, which an agent needs to consume 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?

Schema description coverage is 100%, so the baseline is 3. The description adds a little meaning beyond the schema (scope = game/place/executor label; learn-session summarizes the session's successful tool sequence), but the inline signature largely restates what the schema already documents field-by-field.

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?

Front-loads 'PERSISTENT AGENT MEMORY' and names the concrete verbs (store/recall/forget) plus the resource (compact facts and successful workflow notes). It also distinguishes itself from the playbook siblings by stating memory lives in 'the existing local playbook store, never in the Roblox game', so an agent can tell what this tool owns.

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 explicit triggers: 'use remember after a verified discovery or successful workflow; use recall before planning a similar task', and explains what learn-session is for. However, it never says when NOT to use it (e.g. vs playbook-save or session-* siblings) and leaves 'forget' without a usage condition.

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

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

Annotations declare destructive/mutating, but the description adds critical behavior: mutations are blocked by default, mutating steps are never retried unless retryMutations=true, maxSteps caps the run, stopOnError defaults true, and it requires explicit-mutation-approval. This is well beyond what the structured fields provide.

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

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

The lead sentence is strongly front-loaded, but the body is dense and includes a Signature block that duplicates the 100%-covered input schema, plus a metadata tail (Phase, cost, idempotency, Produces, Verify with) that is more inventory than guidance. Several sentences are load-bearing, but the piece is longer than needed.

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

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

For a high-complexity orchestration tool with no output schema, the description covers execution model, gating, retries, references, and failure recovery ('inspect tool-schema for exact fields'), and names produced artifacts (operation-receipt, step results, verification results). Nested step verification semantics are only lightly addressed but the picture 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 coverage is 100%, so the baseline is 3, and the description adds the `$steps.stepId.data.field` / `$result.stepId.data.field` reference syntax and reiterates default gating behavior (dryRun, allowMutations, retryMutations) in prose. The embedded Signature block largely restates the schema rather than adding new semantics.

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 ('ORCHESTRATES LIVE TOOLS', 'Execute an explicit discover→act→verify workflow') and frames itself as 'the main closed-loop execution surface for AI agents.' It distinguishes itself from nearby siblings like execute, batch-execute, tool-plan, and agent-context by positioning them as prerequisites or components.

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 explicit when-to-use guidance ('Use `agent-context` and `tool-plan` first when the goal is vague, then pass concrete `steps`'), plus exclusions ('set allowMutations=true only when the user authorized state changes') and a fallback behavior when `steps` is omitted. The alternative routing is named, not 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?

Annotations already flag destructiveHint=true and non-idempotent, and the description adds substantial context beyond them: type-guarded/pcall-wrapped behavior, exact error shapes ({ error = 'appendfile is not available...' }, { error = <message> }), the required UNC function, prerequisites (active-client, resolved-target, explicit-mutation-approval), and verification via file-exists. This is unusually rich behavioral disclosure.

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?

Front-loaded with purpose and the key write-file contrast in the first two sentences, which is where it matters most. It is long and carries some metadata (phase/cost/idempotency labels) that borders on noise, but nearly every clause contributes decision-relevant 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, the description fully compensates by documenting return values ({ path, ok = true } or { error }), error conditions, prerequisites, and a verification step. Nothing an agent needs to invoke this mutation correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description restates the signature ({ path, content, threadContext?, timeoutMs? }) but adds no format or constraint detail beyond what the schema provides. Baseline 3 is appropriate.

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

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

States a specific verb+resource (append content to the end of a file in the executor's workspace folder) and explicitly differentiates from the sibling write-file by noting write-file overwrites while this preserves contents. An agent can distinguish it without opening either 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?

Explains exactly when to use it (append to end, create if missing, preserve existing content) and names the alternative (write-file) with the condition that selects it. Also clarifies the executor-side vs Roblox-game scope, removing the most likely misuse.

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?

Goes well beyond the read-only/idempotent annotations: it discloses the fail-closed semantic ("Missing, unreadable, or incomplete state always fails instead of being mistaken for success"), the bounded execution model with scanLimit/readBudget/timeout, the requires-active-client precondition, and cost=medium. These are exactly the behavioral traits annotations cannot carry.

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 opening prose is tight and front-loaded, but the enormous inline Signature block restates the input schema verbatim and dominates the description, diluting the high-value guidance. Significant redundancy that a reader must wade through.

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 names the aggregate fields to consume (passed, passRatio, confidence) and the per-assertion evidence/error semantics, plus cost and preconditions. It stops short of full coverage of batching limits and defaults, but is close to complete for a verify-phase 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 the schema already documents every parameter. The inline "Signature" block merely re-renders the schema shape rather than adding syntax, format, or default meaning, so the baseline 3 is appropriate.

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

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

Opens with a specific verb+resource ("VERIFY LIVE OUTCOMES ... live-game snapshot") and enumerates the assertion families (path existence, property/attribute, GUI state, descendant search, character distance, camera facing, collection counts). An agent can distinguish it from the narrower verify-path-exists sibling 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?

Gives clear timing context ("Use this after actions") and tells the agent to consume aggregate.passed/passRatio/confidence as the outcome proof. It does not, however, name alternatives such as verify-path-exists or get-game-state, so the when-not and alternative-routing guidance is missing.

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?

Far exceeds the annotations: it discloses per-snippet loadstring compilation, independent pcall isolation, that one error never aborts the batch, input-order guarantees, serialization-safe value encoding, the guarded loadstring requirement, and the mutation/approval/safety profile. This is exactly the behavioral context annotations alone (destructive/readOnly hints) cannot convey.

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

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

Front-loaded with the core behavior and ordered logically, but the result shape is effectively stated twice ({ index, ok, value?, error? } and Returns { results = [...] }), which is mild redundancy rather than waste.

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 fully by documenting the return shape, ordering, error isolation, and prerequisites. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: only the FIRST return value is collected, snippets execute in input order, and the value is encoded so Instances/Vector3 survive. That meaning goes beyond the raw schema descriptions.

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

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

States a specific verb and resource ('Run several independent Luau snippets in sequence in a single round trip') and immediately frames the distinction from single-snippet siblings: one call instead of a separate tool call per snippet. An agent can tell it apart from execute/run-luau without opening a 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?

Gives concrete usage contexts ('read several instances, probe multiple remotes, or run a short script of steps in one shot') and states the requirement of loadstring. It does not explicitly name alternatives like execute or run-luau and when NOT to batch, so it stops short of full when/when-not 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 destructiveHint=true and readOnlyHint=false, but the description adds substantial context beyond that: the hook is GLOBAL and persists until stopped or client restart, state lives in getgenv().__mcp_blockedFns keyed by functionPath, a live hook CAN TRIP ANTICHEAT, and required capabilities (hookfunction, newcclosure, getgenv) plus failure returns are disclosed. This is rich behavioral detail that the annotations alone do not convey.

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

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

Front-loads the critical MUTATES STATE warning and the no-op contract before the workflow and caveats, which is well-structured. It is on the long side, with some meta-boilerplate (Phase/cost/idempotency line, 'Signature:' restatement, and a generic tool-schema pointer) that could be trimmed without loss.

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

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

For a stateful, destructive mutation tool with no output schema, the description covers the required capabilities, the start/stop lifecycle, persistence and registry semantics, anticheat risk, and failure modes. An agent has everything needed to invoke it and to clean up 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 100%, so the baseline is 3. The description adds meaning beyond the schema by clarifying the stateful relationship between the two actions — that 'stop' must address the same registry key created at 'start' — which is the key semantic hook for correct invocation.

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

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

States a specific verb ('Replaces a target function with a no-op'), the resource (a function), and the exact semantics (ignores arguments, returns nothing, never calls the original). It explicitly distinguishes itself from the sibling spoof-function-return, so an agent can route correctly without opening a 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?

Gives explicit when-to-use scenarios (silence an anticheat heartbeat, stop a kick function, neutralize telemetry, freeze damage), names the alternative and the condition that selects it (spoof-function-return forces a value; block-function is a no-op), and lays out the full start/stop workflow with the requirement to use the same functionPath.

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, openWorldHint=true and readOnlyHint=false, but the description adds real value beyond them: what blocking actually does to the game ('break the game, freeze replication, or disconnect the client'), the required library and approval prerequisites, mutation classification, and a verification path (assert-state). The only divergence is the 'idempotency=idempotent-write' taxonomy tag against idempotentHint=false, which reads as metadata shorthand rather than a behavioral contradiction of the tool's mutating/destructive profile.

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 destructive warning and core mechanism are front-loaded, then criteria, action semantics, prerequisite, signature, and a metadata tail (phase/cost/idempotency/verify/failure). Slightly dense and run-on, but every clause carries actionable information and nothing important is buried.

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 mutating, hook-installing tool with no output schema, the definition covers prerequisites, safety consequences, matching semantics, action lifecycle (start/stop), and post-call verification ('Produces: operation-receipt', 'Verify with: assert-state'), plus a failure fallback to tool-schema. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the per-parameter docs already exist and baseline is 3. The description adds the parameter-interaction semantics the schema omits: with neither minSize nor containsHex set, every outgoing packet is blocked, which is the single most important parameter-level fact for a correct call, plus an explicit signature line.

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 ('installs a RakNet send hook that DROPS matching outgoing packets') and names the exact mechanism and scope, so it is immediately distinguishable from siblings like block-remote, block-function, send-packet, or packet-spy. The title and first sentence align without redundancy.

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 strong operating context: the matching rule (Size >= minSize and/or payload contains containsHex), the dangerous no-criteria default, and the advice to 'use narrow criteria and stop promptly'. It also lists prerequisites (active-client, explicit-mutation-approval, raknet library) and phase/cost. It does not explicitly name an alternative tool (e.g., packet-spy for observation), so it falls just short 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?

The description asserts "idempotency=idempotent-write," which directly contradicts the annotation idempotentHint=false. An agent reasoning about safe retries would be actively misled by this conflict, which is the rubric's contradiction case despite the otherwise rich behavioral detail (mutation warning, engine support matrix, both-direction pre-validation).

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?

Front-loaded with the critical mutation warning and the core action, then metadata. It is dense but mostly earns its place; the only waste is mild redundancy between the opening "WRITES LIVE GAME STATE" and the later "Safety: MUTATING; writes live game/client state."

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

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

For a 6-parameter mutating tool with no output schema, the description covers the action, reversibility, prerequisites, success artifact (operation-receipt), verification step (assert-state), and failure handling. An agent has everything needed to call and validate it, aside from the idempotency inconsistency noted above.

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

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

Schema description coverage is 100%, so the baseline is 3. The description exceeds that by adding engine-dependent semantics not in the schema: Ketamine's support for outgoing remotes and incoming RemoteFunction callbacks, the unsupported incoming-RemoteEvent case, and the guarantee that Both-direction requests are validated before any state change.

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

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

The first words name a specific verb and resource ("Reversibly sets the selected spy's block state") and scope it to an observed remoteId or remotePath in a chosen direction. This distinguishes it cleanly from siblings like monitor-remote, ignore-remote, and fire-remote, which are the other remote-spy manipulation 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?

It states prerequisites (active-client, resolved-target, explicit-mutation-approval), the undo path (blocked=false), and a when-NOT condition (incoming RemoteEvent blocking returns an explicit unsupported error). It does not name an alternative sibling for filtering rather than blocking, so it falls short of an explicit alternative-routing statement.

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/no-destructive, but the description adds real value beyond them: it never runs Luau, never touches the game, degrades gracefully ('when the transport exposes them' for queue pressure), and points to tool-schema on failure. That is rich behavioral context rather than restating the hints.

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?

Front-loaded with the core purpose and scope, and most sentences earn their place. The tail ('Phase: observe; cost=low; idempotency=read-only... Safety: read-only') largely duplicates the readOnlyHint/idempotentHint annotations, adding some 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?

No output schema exists, and the description compensates by naming the return shape '{ session, active, bridgeLoad, clients }' and what each region contains. For a zero-param read diagnostic, an agent has everything needed to call and interpret 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?

The tool takes zero parameters, so the baseline is 4 and the empty schema is consistent with the description's 'Signature: {}'.

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: report bridge/session state as seen from this MCP session, without touching any game. It enumerates exactly what is reported (this session's id/label/selection, resolved active client, full client roster), which separates it cleanly from siblings like get-active-client, list-clients, and select-client.

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 explicit when-to-use context: debug multi-session routing, confirm two sessions point at different games, or check whether any client is connected at all. It does not name the sibling tools that are alternatives (e.g. get-active-client for a narrower view), so it stops short of full when/when-not routing.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive), yet the description adds substantial behavior beyond them: the BFS recursion over getprotos, the flattened return shape with parentIndex/depth, per-node proto/upvalue counts and source/line, and the fact that depth and node count are capped. It also names prerequisites (active-client, resolved-target) and that it produces an operation-receipt.

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?

Front-loaded with the core behavior and use cases in the opening sentences, then the operational metadata. There is minor redundancy where 'idempotency=read-only' and 'Safety: read-only' repeat the annotation hints, keeping it from a 5, but overall tight and well ordered.

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 carries the return-value burden and does so: flattened node list with parentIndex/depth for reconstruction, plus per-node proto/upvalue counts and source/line. Behavior, prerequisites, safety, and return shape are all present for a medium-cost read-only analysis 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 the baseline is 3; the description lifts above it by giving a concrete resolution example for functionPath ('getrenv().game.PlayerScripts.Main.someFunc' or a global) and restating that depth/node-count are capped. It does not add anything for maxDepth defaults or threadContext beyond what the schema already documents.

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 ('Build an IDA-style call graph (function tree) rooted at a target Luau function') and immediately scopes it with the mechanism (recursing through getprotos breadth-first). It is clearly distinguishable from siblings like get-function-protos or get-closure-protos, which are point lookups rather than a rooted tree walk.

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

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

Explicitly gives use cases: 'understand how a closure fans out into helpers, spot deeply nested logic, and pick disassembly targets.' That is clear when-to-use context. It stops short of naming an alternative tool to prefer in other situations (e.g. get-function-protos for a single level), so no explicit exclusion routing.

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

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

Goes well beyond the annotations by disclosing the loadstring-based target resolution, the type-guarded cache-library requirement, the pcall wrapping, and the { ok } / { error } return shape on failure. It also restates the mutating/live-state nature in prose, consistent with destructiveHint=true and readOnlyHint=false.

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 core purpose is front-loaded and the technique/rationale is genuinely useful, but the trailing metadata block (Phase/cost/idempotency/Requires/Produces/Verify with/Safety/On failure) is dense boilerplate that partly restates the annotations and schema. Slightly over-stuffed but well ordered.

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 mutating, non-idempotent tool with no output schema, the description covers prerequisites (cache library), failure semantics, mutation warning, and the return contract { ok } / { error }, so an agent has everything needed to invoke and interpret 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 description coverage is 100%, so all three parameters (instancePath, threadContext, timeoutMs) are already documented in the schema, including the 'return <expression>' evaluation. The description's signature recap and loadstring note add no meaning beyond that, 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 precise verb+resource: invalidating the executor's cached reference to a single Instance via cache.invalidate(inst), and clarifies the effect (next index returns a FRESH reference). This is functionally distinct from the other cache-* siblings (cache-is-cached, cache-replace) and an agent can tell what it does 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?

Gives clear use cases ('de-syncing a server-trusted object so your subsequent edits go unnoticed', 'forcing the executor to re-wrap a part you have been tampering with') plus prerequisites and verification guidance. It does not, however, explicitly name or exclude alternatives such as cache-replace or cache-is-cached, so the when-vs-which guidance is incomplete.

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 cover readOnly/idempotent/non-destructive, but the description goes further by disclosing that the cache library and cache.iscached are type-guarded, the call is pcall-wrapped, and the tool returns { error } rather than throwing when the library is missing or the call fails. That failure semantics is genuinely new information beyond the structured fields.

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?

Front-loaded with the purpose, then usage, then mechanics, then return/failure shape — a logical order. It is somewhat padded by repeated metadata ('Read-only' appears twice, plus 'Phase: observe; cost=medium; idempotency=read-only'), which costs it a point but does not bury the core 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?

No output schema exists, yet the description supplies return shapes ({ cached } or { error }), prerequisites (active-client, resolved-target, cache library present), failure handling, and even the phase/cost profile. An agent has everything needed to call and interpret this tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description recaps the signature and the loadstring('return ' .. expr) resolution mechanism, but that largely restates what the instancePath schema description already says ('Evaluated as `return <expression>`'), and it adds no meaning for threadContext or timeoutMs.

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 precise verb+resource ('Report whether the executor currently holds a cached reference for a single Instance') and names the exact API call it wraps (cache.iscached(inst)), which an agent can distinguish from the many other cache and inspection siblings.

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

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

Explicitly says when to use it: 'confirm an instance is cached before invalidating it, or to verify that an invalidate actually dropped the cached reference', and names the paired siblings cache-invalidate / cache-replace. Both the when and the alternatives 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?

The description adds strong behavioral detail beyond the annotations: the call is type-guarded and pcall-wrapped, returns { error } when the library is missing or on failure, and mutates live executor state. However, it claims 'idempotency=idempotent-write' while the annotations declare idempotentHint=false — a direct conflict on retry safety for a destructive tool, which misleads an agent into believing repeat calls are harmless. This contradiction caps the score despite the otherwise valuable disclosure.

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 core action is front-loaded in the first sentence, which is good. But the text is long and densely packed with generated metadata boilerplate (Phase/cost/Requires/Produces/Verify/Safety/On failure), and it redundantly restates the return shape and the 'mutates state' claim, so several sentences do not fully earn their 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 complex, path-resolving, state-mutating tool with no output schema, the description covers prerequisites, failure behavior, the { ok }/{ error } return, and a verification step (assert-state). That is nearly everything an agent needs to invoke it correctly, missing only the routing against sibling cache tools.

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 all four parameters (including optional timeoutMs/threadContext) are already documented in the schema. The description adds only the resolution mechanism (loadstring('return ' .. expr)) and a compact signature line, which the schema largely supplies already, 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 precise verb+resource+mechanism: it swaps the executor's cached reference for one Instance with another via cache.replace(a, b). An agent can distinguish it from cache-invalidate and cache-is-cached without opening either schema, and the redirection semantics are spelled out concretely (checkpoint/hitbox/remote-wrapper impersonation).

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 clear context and preconditions: requires the cache library (type(cache)=='table') with cache.replace, an active client, resolved targets, and explicit mutation approval. It explains the redirection use case. It stops short of naming the sibling alternative (cache-invalidate) or stating when not to use it.

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/non-idempotent, but the description adds substantial context beyond them: pcall-guarding and error reporting, the exact return shape on success and failure, side-effect/anti-cheat warnings, and the 'kind=raw' evaluation semantics at call time. This meaningfully de-risks a dangerous 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?

Long, but front-loaded with the critical 'EXECUTES THE FUNCTION' warning and each detail (guarding, return shape, raw semantics, safety) earns its place for a mutating tool. Some enumerations of example expressions are redundant with the schema, preventing 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?

No output schema exists, yet the description fully specifies the return object on both success and failure, plus failure guidance ('inspect tool-schema'). For a live-state mutating tool with 100% param coverage, nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description goes slightly further by surfacing the signature and stressing the kind='raw' path for non-primitive arguments — a subtlety that governs correct invocation. It largely mirrors the schema, so it earns only modest credit above baseline.

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

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

States a specific verb (call/invoke) and resource (a resolved Luau function/closure) with explicit scope. It names the concrete patterns it handles (remote handlers, metamethods, env members, GC closures) and is clearly distinct from siblings like eval-expression or run-luau, which evaluate code rather than invoke a resolved function object.

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 rich context on when to use it — 'invoke internal, hidden, or anonymous functions on demand' with several concrete examples of what those are. It does not explicitly contrast against close siblings such as invoke-closure or execute, so the agent must infer the boundary, but the usage context is otherwise clear.

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

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

Annotations already declare a mutating, non-idempotent, destructive write profile, and the description corroborates and enriches this: it emphasizes WRITES LIVE GAME STATE, clarifies the write is confined to the local camera, notes idempotency=contextual-write, and states that existing properties are returned so the change is auditable. It also points at assert-state for verification. This is well beyond what the structured fields alone convey.

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

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

It is front-loaded with the key mutating warning, which is good, but it is padded with a full Signature block that duplicates the input schema and a boilerplate tail (Phase/cost/Produces/Verify/Safety/On failure) that repeats the opening 'writes live game state'. Several sentences do not add information beyond the schema and annotations.

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

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

There is no output schema, and the description compensates by noting that existing camera properties are returned for auditability, and by specifying prerequisites, idempotency, and a verification path. It is complete enough for a 7-param, nested-object mutation, though return-shape detail is only summarized.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds cross-parameter semantics the schema does not: setCFrame requires position plus either lookAt or rotation in degrees. That constraint reasoning is genuinely useful beyond the per-field descriptions.

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

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

The description names a specific resource (the active/CurrentCamera) and concrete operations (read, set CFrame/position/look-at/FOV/CameraType). It even scopes it against the environment by stating it only changes the local CurrentCamera and does not move the character. An agent can tell exactly what this tool does and how it differs from generic instance/character tools.

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

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

Explicit routing is given: action=get for a one-shot read, action=setCFrame for movement, with preconditions (requires active-client and explicit-mutation-approval). It also states what the tool is NOT for (no character movement, no server replication). It stops short of naming a specific alternative sibling tool for those excluded cases, so it falls just under fully explicit.

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 read-only/idempotent, but the description adds substantial context beyond them: the executor-function dependency, graceful degradation with a structured { error }, and the required preconditions (active-client, resolved-target). This is exactly the kind of runtime behavior the schema cannot express.

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

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

Front-loaded and logically ordered: purpose, behavior on true/false, then preconditions and failure mode. The trailing metadata block (Phase/cost/idempotency/capabilities/safety) partly duplicates the annotations, which costs it the top 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?

The return shape ({ Signal, Instance?, CanReplicate, Note }) is described even without an output schema, the failure mode is covered, and executor dependency is called out. Nothing an agent needs to invoke and interpret this correctly is missing.

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

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

Schema coverage is 100%, so both parameters are already fully documented in the schema. The description restates the ownership/mutual-exclusion semantics ('pass the instance plus the signal member name, or leave signalName empty') but adds no syntax or format detail beyond what the schema provides; baseline 3 is appropriate.

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

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

States a specific verb+resource ('Query whether an RBXScriptSignal ... permits to be replicated') and explicitly names the sibling it feeds into (replicate-signal). An agent can distinguish this pre-flight check from the actual replication tool without opening either 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?

Gives explicit when-to-use ('pre-flight a signal before attempting replication') and both branches of the outcome: when true, replicate-signal fires it; when false, replicate-signal will be rejected and a different vector is required. Nothing 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?

Annotations cover the safety profile (readOnlyHint, destructiveHint=false, idempotentHint), but the description adds far more: the connection persists across calls until stopped, it survives across tool calls via getgenv().__mcp_logCapture, it fires on every logged line, the 1000-entry ring buffer drops oldest entries, messages are truncated to 500 chars, and failure shapes are { error } and { notRunning }. This is exactly the extra context annotations cannot carry.

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?

Front-loaded and well-sectioned (workflow, caveats, error returns), and every sentence carries operational information. It is dense and lengthy, however, with some redundancy between the workflow block and the trailing Signature/Phase/Cost summary, which keeps it short of a 5 on conciseness.

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

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

For a stateful, multi-action tool with no output schema, the description supplies return shapes for all three actions ({ started }, { count, returned, entries }, { stopped, captured }), the error variants, prerequisites (game:GetService('LogService'), getgenv), and the persistence caveat. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100% and the schema already documents action, limit, and threadContext, so baseline is 3. The description adds marginal value beyond the schema — it clarifies limit is newest-bounded against the 1000-entry buffer and that fetch does not clear captured messages — which nudges it above baseline but does not introduce syntax or defaults the schema lacks.

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 — connect LogService.MessageOut and record every emitted line into a ring buffer — and immediately scopes it against alternatives ('best way to watch a game's own console output over time', 'low-risk compared to the hook-based instrument tools'). An agent can distinguish it from siblings like get-console-output without opening a 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?

Gives an explicit three-step lifecycle (start/fetch/stop) with what each returns, names the concrete scenarios that call for it (see what a script prints when you trigger an action, catch stack traces as they happen), states when to stop, and contrasts it with hook-based tools. Conditions for use and non-use are both present.

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 read-only, idempotent, non-destructive behavior, so the description adds useful context beyond that: active-client requirement, medium cost, produced artifacts, and failure guidance pointing to tool-schema. It does repeat the read-only annotation, which slightly limits its added value.

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 purpose is front-loaded and the remaining operational details are compactly presented. Some fields (signature, idempotency=read-only, Safety: read-only) are redundant with structured data, but the text is not bloated.

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 probe with rich annotations and no output schema, the description covers requirements, outputs, cost, and failure handling. However, the produced observation ('structured-observation, operation-receipt') is vague and the return value is only implied by 'normally reports true.'

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 schema already documents threadContext as an optional Roblox thread identity with default behavior. The description only restates the signature without adding any semantic meaning beyond what the schema provides, so 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: calling Volt checkcaller to determine whether the current call originates from the executor. It clearly distinguishes the probe's behavior ('normally reports true for a direct MCP call'), though it does not name a sibling alternative to contrast with.

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 clear usage context: 'most useful as a capability/behavior probe before installing a hook.' This tells the agent when the tool is appropriate, but provides no explicit exclusions or alternative tools for different conditions.

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

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

The description discloses a great deal beyond the annotations: the error envelope when the function is missing, the pcall/type-guard wrapping, the return shape { cleared } or { error }, and the MUTATING safety profile — all of which align with destructiveHint=true. However, it asserts 'idempotency=idempotent-write' while the annotations declare idempotentHint=false, a direct conflict that an agent could rely on when deciding whether to retry.

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 first sentence is well front-loaded with the key action and its effect, but the definition then piles on a metadata block (phase/cost/idempotency/requires/produces) plus a generic 'On failure: inspect tool-schema…' instruction that is boilerplate rather than tool-specific. It is dense and mostly earns its place, but not tight enough for a 4-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?

With no output schema, the description compensates by specifying the return contract ({ cleared } or { error }), the failure envelope, the preconditions, and a verification path — everything an agent needs to invoke and check this mutation 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 100% and both parameters are already documented as optional deadline/thread-identity fields, so the schema does the heavy lifting. The description's restatement ('Signature: { threadContext: number?, timeoutMs: number? }') adds no semantics beyond the schema, matching the baseline 3.

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 ('clears any code previously queued with queueonteleport'), names the underlying executor function, and contrasts directly with the sibling queue-on-teleport ('After this, nothing will auto-run on the next teleport'). An agent can distinguish it from siblings without opening a 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?

Provides the precondition ('Requires: active-client, explicit-mutation-approval'), the phase ('act'), and a verification step ('Verify with: assert-state'), which tells the agent when this call is appropriate and what must happen around it. It does not, however, name an explicit alternative tool or an when-not-to-use condition, so it falls short 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?

The description claims 'idempotency=idempotent-write', but the annotations declare idempotentHint=false. These directly conflict on a stated behavioral attribute, so this is an Annotation Contradiction. Otherwise the description does add value (state is MUTATING, persistent executor-side observer state changes, block/ignore retained, monotonic call IDs), but the explicit contradiction triggers the score-1 rule.

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?

Purpose is well front-loaded ('WRITES LIVE GAME STATE. Clears...'), and the labeled metadata block is easy to scan. However, boilerplate restatement of the signature and the generic tail ('On failure: inspect tool-schema for exact fields, defaults...') do not earn their place for this specific tool, diluting conciseness.

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 output schema, the description covers the essentials: safety profile, prerequisites, produced artifacts (bounded-event-snapshot, operation-receipt), and a verification route (assert-state). The only gap is the unreliable idempotency claim, which is a correctness issue rather than a missing-information one.

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 enum values, default, and thread-identity semantics are already documented in the schema. The description merely restates the signature ('{ engine: "cobalt" | "ketamine"?, threadContext: number? }') without adding format or constraint detail beyond what the schema provides, so 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: 'Clears the selected engine's MCP buffer and GUI history.' It also scopes the operation by noting what is retained (block/ignore settings) and that capture continues, which distinguishes it from siblings like block-remote, ignore-remote, and get-remote-spy-logs. An agent can identify the action 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?

Provides real invocation context: 'Phase: act', 'Requires: active-client, explicit-mutation-approval', and a follow-up action 'Verify with: assert-state.' This tells the agent when the tool is eligible and what prerequisites must hold. It does not, however, name any alternative tool or an explicit when-not-to-use condition, so it stops short of full routing 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 cover read-only, idempotent, and non-destructive, so the bar is lower. The description earns credit for disclosing post-condition routing behavior and the produced operation-receipt, though the repeated "idempotency=read-only / Safety: read-only" lines duplicate annotation data rather than adding to it.

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

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

The first two sentences are front-loaded and high value. The trailing metadata block (Phase/cost/idempotency/Requires/Produces/Safety) is somewhat boilerplate and partially restates annotations, but it stays compact and the failure pointer is useful.

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, annotation-covered operation with no output schema, the description supplies everything an agent needs: scope, post-state behavior, producing an operation-receipt, and what to do on failure.

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

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

The tool takes zero parameters, so per the rubric this is the baseline 4. The "Signature: {}" note correctly signals an empty argument set, matching the empty input 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 and resource ("Drop THIS session's client binding") with explicit scope, and clarifies it loosens a pin rather than disconnecting a client. An agent can distinguish it from select-client without opening any schema.

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

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

Explicitly says when to use it ("reset routing before re-selecting, or to hand control back to auto-resolution") and describes the post-state routing rules (auto-resolve with one client; must select-client again with several accounts). It also names the relevant sibling, select-client.

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 cover the safety profile (readOnly, idempotent, non-destructive), but the description adds real value: it clarifies this only clears a SERVER-SIDE embedding cache and does not touch the game or live scripts, and explains the active-client resolution with a no-op fallback. This goes meaningfully beyond the annotations.

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

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

Front-loaded with the core action and scope, then supporting detail. The trailing boilerplate ('Phase: observe; cost=low; idempotency=read-only... Safety: read-only... On failure: inspect tool-schema') partly repeats annotation data and is generic, but the overall structure is tight.

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-param, no-output-schema tool whose annotations already carry the safety profile, the description supplies the missing pieces: cache-only scope, session-based client resolution, no-op behavior, and the intended follow-up effect. Sufficient 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?

Zero parameters, so the baseline is 4. The description confirms the empty signature ('Signature: {}'), aligning with the schema and leaving no ambiguity about invocation.

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

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

States a specific verb+resource ('Drop the cached semantic index') and scopes it precisely to 'THIS session's active client'. This clearly distinguishes it from siblings like semantic-search-scripts, get-semantic-index-stats, and the generic cache-invalidate.

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

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

Explicitly names the trigger ('force the next semantic-search-scripts call to re-harvest and re-embed from scratch, e.g. after the game's scripts changed') and the related sibling it affects. Lacks explicit when-not guidance, but the context for use is clear.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds what actually happens: it writes live game state, runs any connected handler, requires the executor's firesignal, and degrades with a clear { error } when unavailable. It also names the failure path and a verification tool (get-gui-text), which is well beyond the annotation coverage.

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?

Front-loaded with the critical warning 'WRITES LIVE GAME STATE' and flows logically through mechanism, usage, behavior, and return shape. The trailing Phase/cost/capabilities metadata (e.g. idempotency=contextual-write, Capabilities: firesignal) is somewhat redundant and could be trimmed, keeping it just under the top mark.

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 compensates by describing the return shape ({ Path, Fired, ok } or { error }), the prerequisites, the degradation path, and a verification step. An agent has everything needed to invoke it correctly and interpret 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 100%, so the baseline is 3, but the description adds meaning: it spells out the signature and lists the exact signals fired when action is omitted (Activated, MouseButton1Down, etc.), which the schema only summarizes. It does not add much for threadContext 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 (click) and resource (Roblox TextButton or ImageButton) and explains the exact mechanism: firing GUI signals via firesignal so connected handlers run. This distinguishes it from siblings like fire-signal and virtual-input, which operate at a lower level.

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 a clear condition: 'Use when direct UI activation is needed inside the active client,' plus prerequisites (active-client, resolved-target, explicit-mutation-approval). It does not explicitly name the alternative tool (e.g. virtual-input or fire-signal) an agent should pick instead, so it stops short of full when-not 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description earns credit by disclosing the non-obvious retention mechanism: results land in getgenv().__mcp_closure_refs because functions can't cross JSON. It also names a produced handle type, though it doesn't explain lifecycle/release of the handle.

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?

Front-loads the purpose in the first sentence, then packages operational metadata into compact semicolon-delimited clauses. Information-dense with little waste, though the trailing 'On failure: inspect tool-schema...' clause is generic boilerplate.

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?

Despite no output schema, the description explains the return value (a reusable Reference expression stored in a named global), covers prerequisites, and flags a failure fallback. Complete enough for a 3-param tool, with only minor gaps around handle lifecycle.

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 each parameter is well documented in the schema, so baseline 3 applies. The description's signature line (functionPath, threadContext, key) merely restates what the schema already provides and adds no new semantic 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 (clone) and resource (function) and explains the mechanism and outcome: the result is retained in getgenv().__mcp_closure_refs and returned as a reusable Reference. This is clearly distinct from sibling closure tools (inspect-closure, get-closure-protos, invoke-closure), which don't produce reusable handles.

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 operating context via 'Phase: observe', 'Requires: active-client, resolved-target', and 'Produce: created-handle', which imply when the tool is usable. However, it never states when to prefer ou clone-function over alternatives like inspect-closure or get-closure-protos, nor any exclusions, so it only implies usage rather than routing.

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

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

Goes well beyond annotations: the clone starts parentless and is parented LAST only if parentPath is given, :Clone() returns nil on non-Archivable sources, and a parented clone immediately affects the running game and may replicate. These are rich behavioral disclosures the destructiveHint/readOnlyHint flags alone would not convey.

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

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

Front-loads the critical warning (WRITES LIVE GAME STATE) and proceeds through mechanism, use cases, caveats, return shape, and metadata. Dense and largely waste-free, though the signature/phase/requires metadata lines make it longer than strictly necessary.

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, but the description supplies the return shape ({ Source, Clone, Parented, ok } or { error }), failure behavior, prerequisites, and a verification tool (get-instance-properties). Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters in detail. The description adds minor sequencing context (parenting happens after cloning, threadContext defaults to server), but mostly restates what the schema provides, 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 (deep-copy an Instance), explains the exact mechanism (resolve a Luau expression, source:Clone() duplicates the instance and all descendants, optionally parent the clone), and is clearly distinguishable from siblings like create-instance and destroy-instance.

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 concrete when-to-use scenarios (duplicating a template Part/Model/GUI, spawning extra copies, snapshotting a subtree before mutating) and states prerequisites (active-client, resolved-target, explicit-mutation-approval). It does not explicitly name a sibling alternative, so it falls short 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds two useful behavioral facts beyond the annotations: primitives are NOT invoked ('without calling it') and an active-client is required. However, the remaining 'Phase/cost/idempotency/Safety' lines largely restate the annotation hints.

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 first sentence is a strong, front-loaded purpose statement, but it is followed by a templated block (Phase, cost, idempotency, Capabilities, Produces, Safety, On failure) that repeats annotation data and is only loosely integrated. The 'On failure' pointer to tool-schema is useful, but overall the entry 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?

For a zero-required-param, read-only probe with a fully documented schema, this is adequate. Yet there is no output schema and 'Produces: structured-result' gives no sense of what the capability matrix contains, leaving the agent unable to anticipate the return shape.

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 optional, so the baseline is 3. The description only echoes the schema with 'Signature: { threadContext: number? }' and adds no syntax, default, or semantic detail beyond it.

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

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

States a specific verb+resource ('reports the selected alias for every primitive without calling it') and identifies the scope as the official Volt closure library plus debug closure operations. It is distinguishable from introspection siblings like get-closure-protos, though it does not name a sibling to contrast against.

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?

'Phase: verify' and 'Requires: active-client' imply when the tool is relevant and what precondition is needed, but there is no explicit statement of when to choose this over tool-schema, list-tools, or get-closure-protos. Usage is implied rather than directed.

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 and readOnlyHint=false, but the description goes further: it flags that start/stop write live game state, that executor-side observer state persists, that explicit mutation approval is required, that the buffer is bounded to 200 messages, and where to look on failure. The remaining vagueness is what exactly 'writes live game state' mutates and whether poll itself is side-effect free.

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 lead sentence is front-loaded and the operational facts (confirm requirement, buffer size, key) come early. However, the inline Signature block duplicates the input schema field-for-field, and tag soup like 'Phase: act; cost=medium; idempotency=contextual-write' plus 'Capabilities: create_comm_channel' adds volume without much decision value.

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 mutating, 7-parameter tool with no output schema, the description covers mutation consequences, approval prerequisites, buffer bounding, and a failure-recovery pointer (tool-schema, assert-state), which is enough to call it safely. It stops short of describing what a poll returns beyond 'bounded-event-snapshot'.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds real semantics: which actions (start/stop) require confirm=true, that polling is keyed by monitor key, and that limit is a hard budget tied to the 200-message buffer. The signature block itself mostly restates schema fields, so it does not go beyond a 4.

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

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

The description states a specific verb and resource: connect to Channel.Event, retain a bounded 200-message buffer, and poll by monitor key. It is clearly distinguishable from generic execute/eval siblings, but it never names or contrasts with the closest siblings (actor-event-monitor, lua-state-event-monitor, get-comm-channel), leaving the agent to 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?

Usage is implied rather than stated: start/stop require confirm=true and polling is keyed, which tells the agent how to call it but not when to prefer it over sibling monitors or the one-shot get-comm-channel. No explicit when-not or alternative routing is 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?

Goes well beyond the readOnly/destructive/idempotent annotations by disclosing where state lives (getgenv().__mcp_gc_snapshots[name], per-game/per-session isolation) and hard caps (200000 objects walked, 4000 function pointers remembered) with truncation flags to treat large counts as approximate. Requires/preconditions (active-client, getgc capability) are also stated.

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?

Front-loaded with purpose and workflow, then return shapes and caps, so an agent can stop reading early. It is dense rather than bloated, though the trailing 'Phase/cost/idempotency/Safety: read-only' block partly restates annotation data already provided structurally.

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 carries the full burden of describing return values and does so precisely for both action='capture' and action='compare' (counts, fnSampled, countDeltas, newFunctions, freedApprox, truncated). Nothing an agent needs to call or interpret this tool correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3; the description adds sequencing semantics the schema lacks — capture must precede compare, and compare must reuse the same snapshotName, with distinct names keeping independent baselines. threadContext is not elaborated further than the schema already does.

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 ('take a census of the garbage collector (getgc) and diff it over time') and names the analyst goal ('leak-hunting / behaviour-attribution tool'). It is clearly separable from siblings like list-gc-functions or list-gc-tables, which enumerate rather than diff snapshots.

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 an explicit three-step workflow (capture baseline, perform an in-game action, compare with the same snapshotName), which tells the agent precisely when each action applies. It does not, however, name any alternative sibling (e.g. measure-memory, list-gc-functions) or state when this tool is the wrong choice.

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/non-destructive, and the description reinforces rather than contradicts them. Beyond that it discloses the capability dependency (requires compareinstances), the failure path (error when capability missing or an expression fails to evaluate), and a partial return shape ({ Same, TypeA, TypeB }) — useful behavioral context a bare annotation set would not convey.

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

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

Purpose is well front-loaded, but the trailing metadata block is redundant: 'Non-mutating', 'idempotency=read-only', and 'Safety: read-only' restate the same fact three times, and the signature repeats the schema. It 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?

There is no output schema, yet the description explains the return shape and error behavior, and it names the capability requirement. For a 3-parameter read-only tool this is essentially complete; only minor gaps like timeout/error field detail remain, and it points to tool-schema for those.

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

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

Schema coverage is 100%, so the schema already documents pathA, pathB and threadContext with examples. The description's signature line merely restates the schema and adds no syntax or format meaning beyond it, 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 (resolve/compare) and resource (two Luau expressions referencing an underlying Roblox instance). It further distinguishes its identity-comparison semantics from `==` or :GetFullName(), which a naive agent might otherwise use, so the tool's niche 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 a concrete motivating scenario ('confirm "is this captured remote actually game.ReplicatedStorage.RemoteEvent, or a lookalike?"') and states the prerequisite capability and non-mutating nature. It lacks an explicit when-not or a named alternative sibling, so it's clear context without full routing 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 flag destructiveHint=true and non-idempotent, but the description adds substantial non-structured context: omitted settings are preserved, resetFilters clears filters while preserving pause/history, and pausing/filtering does not unblock remotes or alter network delivery. It also discloses required preconditions (active-client, explicit-mutation-approval) and that permanent observer/hook state 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?

Front-loaded with the critical 'WRITES LIVE GAME STATE' warning, then scope, then behavior. Slightly bloated because the inline Signature block restates the input schema field-for-field, which the agent can already read, costing it a fifth point but not much 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 7-param, nested-object mutation tool with no output schema, the description covers everything an agent needs: preconditions, engine branching, preservation/reset semantics, side-effect boundaries ('does not unblock remotes'), return content, and a failure recovery pointer to tool-schema.

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

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

Schema coverage is 100%, so the baseline is 3 and the schema carries the field-level meaning. The description still adds cross-field semantics the schema can't express — omitted fields are preserved, resetFilters ordering, the Cobalt/Ketamine acceptance split, and per-engine applicability of GUI fields.

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

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

Opens with a specific verb+resource and scope: 'Configures an already-running spy without restarting or expiring IDs.' It explicitly distinguishes itself from the lifecycle starter by stating 'Reads/configuration never load a spy; start it with remote-spy first.' An agent can tell it apart from remote-spy/ensure-remote-spy without opening a 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?

Gives explicit when-to-use (patch filters, pause/resume, resize history, GUI control), names the prerequisite alternative ('start it with remote-spy first'), and states an engine-specific exclusion ('Cobalt accepts capture/buffer settings but rejects Ketamine GUI settings'). Nothing 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?

Goes well beyond the annotations by disclosing that the hook is global and persists until stopped or client restart, adds per-call overhead, and can trip anticheat, plus the pcall-isolation and call-through guarantee and the hookfunction/restorefunction fallback restoration path. This is exactly the mutation-safety context an agent needs before invoking a destructiveHint 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?

Front-loads the critical warning ('WRITES LIVE GAME STATE — INSTALLS A PERSISTENT GLOBAL HOOK') and the numbered workflow is easy to follow. It is long and carries some boilerplate meta footer (Phase/cost/idempotency/Safety) that slightly dilutes density, but nearly every sentence carries operational value.

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 stateful mutation tool with no output schema, it documents each action's return shape ({started,key}, {calls}, {stopped,calls}), the error conditions, the persistence model, and the required capabilities — nothing an agent needs to invoke and manage it correctly is missing.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds real value by explaining that action='fetch' polls without stopping, that functionPath doubles as the registry key across all three actions, and the underlying getgenv().__mcp_callCounts keying. threadContext is left unexplained but the schema already documents it.

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

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

States a specific verb and resource ('Lightweight call-frequency counter for any function') and explicitly distinguishes itself from the sibling hook-and-log-function by contrasting what each captures. An agent can tell exactly what this does and how it differs without opening a 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?

Names the alternative (hook-and-log-function) with the tradeoff that selects it, and gives concrete when-to-use scenarios ('confirming an anticheat tick fires, measuring how hot a code path is, or verifying a remote handler runs'). It also spells out the three-action workflow and that the same functionPath must be reused.

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 cover the read-only/idempotent safety profile, but the description adds operational context annotations cannot express: it depends on the executor's getconnections, degrades to a clear { error } when that is unavailable, and requires an active-client/resolved-target context at cost=medium. It also names the exact return shape, which matters since there is no output schema.

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 core purpose, breakdown fields, and routing guidance are all front-loaded in the first three sentences, which is exactly the information an agent needs. The trailing metadata block (phase/cost/idempotency/Safety: read-only) partially duplicates the annotations and the schema, adding length without new signal, which keeps it just 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 count-only read tool with no output schema, the description supplies the return field list, the dependency (getconnections), the failure mode ({ error }), the execution context requirements, and a pointer to tool-schema for exact fields on failure. An agent has everything needed to call it correctly and interpret 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 description coverage is 100%, so all three parameters are fully documented in the schema itself, including the instancePath/signalName interaction. The description's 'Signature' line restates the parameters without adding format or fallback semantics beyond what the schema provides, so baseline 3 is correct.

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 ('Resolve an RBXScriptSignal and return a fast numeric breakdown') and enumerates exactly what is counted (Total, Lua vs Foreign, Enabled vs Disabled, WithFunction). It distinguishes itself from its closest sibling by name, so an agent can tell it apart from list-signal-connections without opening a schema.

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

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

Explicitly frames itself as a 'lightweight first pass before list-signal-connections when you only need counts,' and supplies concrete trigger questions ('how many handlers are on this RemoteEvent?'). It also states the inverse condition ('Does NOT describe each function, so it is much cheaper than the full listing'), which routes the agent to the alternative when descriptions are needed.

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 readOnlyHint=false and destructiveHint=true, and the description adds substantially more: it writes live game/client state, requires confirm=true and explicit mutation approval, discloses the retention side-effect (stores the handle in getgenv().__mcp_comm_channels), specifies the reduced return surface, and gives failure guidance. This is well beyond what the annotations convey.

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

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

The critical warning is front-loaded and each clause carries real information (signature, phase/cost, requirements, verification, safety). It is dense rather than padded, though the 'On failure: inspect tool-schema...' boilerplate and the phase/cost tokens are template filler that dilute the signal slightly.

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 mutating tool with no output schema, the description covers the safety contract, preconditions, side effects, verification, and error path. It is close to complete; only explicit alternative-tool routing is missing.

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

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

Schema description coverage is 100%, so the schema already documents name, confirm, and threadContext in detail. The description restates the signature and marks confirm as required, but adds no syntax, format, or constraint detail beyond the schema — the baseline 3 for full schema coverage is appropriate.

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

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

The description leads with a specific verb+resource ('WRITES LIVE GAME STATE', create_comm_channel) and states the exact effect: create a channel, retain it in getgenv().__mcp_comm_channels, and return only its serializable identifier/metadata. That distinguishes it cleanly from siblings like get-comm-channel and fire-comm-channel.

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 prerequisites (active-client, explicit-mutation-approval, confirm=true) and a verification step (assert-state), which implies when the tool is appropriate. But it never names the sibling alternatives (get-comm-channel, fire-comm-channel, run-on-actor) or states when-not to use this tool, so routing guidance is only partial.

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 annotations already declaring destructive=true and non-idempotent, the description goes well beyond: pcall-guarded className validation, per-property pcall isolation collecting propErrors, Parent applied LAST, parentless-by-default behavior, and the replication warning. This is rich behavioral context an agent cannot derive from structured fields.

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 live-state warning is correctly front-loaded and the PROCESS paragraph is dense with useful detail. The embedded 'Signature:' line and phase/cost/idempotency meta largely restate schema and annotations, which is minor waste.

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, but the description documents the return shape ({ Created, ClassName, Parented, propErrors, ok } or { error }), failure handling, and a verification step. An agent has everything needed to invoke and interpret 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%, giving a baseline of 3, but the description adds ordering semantics beyond per-parameter docs — properties are applied before Parent, and parentPath is evaluated as a Luau expression. The duplicated signature line is redundant but the process detail adds real meaning.

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: 'Construct a brand-new Instance via Instance.new(className)' with optional Name, properties, and parenting. It is distinguishable from siblings like clone-instance, set-instance-property, and destroy-instance by its creation semantics.

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?

Explains when to use it with concrete debugging examples (Part, ESP marker, Folder, Value objects) and lists prerequisites (active-client, resolved-target, explicit-mutation-approval) plus a verification tool. It does not explicitly contrast with clone-instance for existing instances, leaving some alternative selection 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?

Goes well beyond the annotations by disclosing that the decoder probes both flat and namespaced forms, requires a crypt table, returns { error } rather than throwing when crypt is absent, and is pcall-guarded so malformed Base64 degrades to a clean error. This is exactly the runtime behavior an agent needs.

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?

Front-loads the core operation and error-handling semantics well. It is slightly padded with trailing metadata (Phase/cost/idempotency/safety restated alongside annotations) and a generic 'On failure: inspect tool-schema' boilerplate sentence.

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

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

Despite no output schema, the description specifies the return shapes ({ decoded } or { error }), the failure behavior, and the executor dependency, leaving nothing essential missing for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents data, timeoutMs, and threadContext with meaning. The description repeats the signature but adds no syntax or format detail beyond what the schema provides, so 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 (decode) and resource (Base64 string to raw bytes) plus the exact library used (executor's crypt library). It is immediately distinguishable from the sibling crypt-base64-encode.

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 establishes context (pure, side-effect-free, runs in-game) but never states when to prefer this tool over alternatives or when it is inapplicable. Usage is implied by the operation rather than explicitly spelled out.

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?

Goes well beyond the annotations (readOnlyHint/idempotentHint/destructiveHint), disclosing that it probes both flat and namespaced crypt forms, that a missing crypt table yields { error } rather than throwing, and that the call is pcall-guarded so malformed input degrades cleanly. This is exactly the kind of failure-mode context annotations cannot convey.

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

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

Purpose is front-loaded in a strong opening sentence, but the tail is padded with schema-duplicating signature text and annotation-duplicating metadata (idempotency=read-only, Safety: read-only) plus generic filler ('inspect tool-schema for exact fields...'). Roughly half the text is redundant boilerplate.

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 compensates by naming the return shapes ({ encoded } or { error }) and the failure path, and it states the active-client requirement. It is essentially complete for a simple read-only compute tool, with only the boilerplate tail adding noise rather than substance.

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 data, timeoutMs, and threadContext fully. The description repeats the signature but adds no syntax, format, or constraint meaning beyond what the schema provides, 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 (encode) and resource (string to Base64) and names the underlying mechanism (executor `crypt` library), which cleanly distinguishes it from the sibling crypt-base64-decode. An agent can identify the operation 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?

The description implies usage through its purpose and metadata (Phase: observe, Requires: active-client), but never states when to reach for this tool versus alternatives like crypt-hash or execute. There is no explicit when-to-use/when-not guidance, so usage 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?

Annotations already declare readOnly/idempotent/destructive, but the description adds real value beyond them: it discloses the pure side-effect-free nature, the executor requirement for crypt.decrypt, and the pcall-guarded failure contract where wrong key/iv/mode yields { error } rather than a throw.

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 core is front-loaded well, but the trailing metadata string ('Phase: observe; cost=medium; idempotency=read-only... Safety: read-only') repeats what the annotations and earlier sentences already convey, adding bulk without new meaning.

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 correctly explains return values ({ plaintext } or { error }) and failure handling. It covers the key facts an agent needs, though it does not detail output format nuances or timeout/threadContext usage.

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 baseline is 3, but the description adds a genuine cross-parameter constraint absent from the schema: key and iv must be the SAME Base64 values used at encrypt time, and mode must match if non-default.

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 a specific verb (decrypt), resource (ciphertext), and even the underlying executor function crypt.decrypt(data, key, iv, mode?). It is clearly distinguishable from crypt-encrypt and other crypt-* siblings by stating it recovers plaintext.

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 prerequisite guidance ('supply the same Base64 key and iv that were used to encrypt', plus the mode if non-default), but never names alternatives or when-not-to-use conditions. Usage is implied rather than spelled out.

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 cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantial context: pure/side-effect-free in-game compute, pcall-guarded so bad key/iv degrades to a clean error, and returns { ciphertext, iv } or { error }. This is rich, non-redundant behavioral disclosure.

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 purpose is front-loaded and clear, but the entry is long: it restates the full signature (already in schema) and appends metadata lines (Phase, cost, idempotency, Safety, Produces, and an 'On failure' pointer) that partly duplicate annotations and structured data.

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?

Despite no output schema, the description explains the return shape ({ ciphertext, iv } or { error }), error/degradation behavior, prerequisites, and the executor's fallback for omitted params. An agent has everything 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 100%, so the baseline is 3. The description notes Base64 key/iv, mode examples (CBC/CTR), and that the executor derives iv/mode when omitted, but most of this is already documented in the schema properties, so it adds only marginal value.

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 ('Encrypt a string with the executor's crypt.encrypt') and even gives the call signature. It is clearly distinguishable from siblings like crypt-decrypt, crypt-hash, and crypt-base64-encode.

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 clear context: a pure, side-effect-free compute that runs in-game, requires an active client, and depends on `crypt.encrypt` existing (returning { error } otherwise). It also routes to crypt-generate-key for obtaining the key. It doesn't contrast when to prefer this over crypt-decrypt or other crypto siblings, so no explicit 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?

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds real behavior: default size 16, clamp to 1..1024, pcall-guarded, returns { error } rather than throwing on unsupported executors, and pure side-effect-free in-game compute. That is meaningful context beyond the structured safety hints.

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 opening sentences are well front-loaded, but the trailing meta block (Phase/cost/idempotency/Requires/Produces/Safety plus a repeated signature) largely restates annotations and the schema, padding the definition without adding selection value.

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 correctly explains the return contract ({ bytes } or { error } as Base64) and the failure mode, which is what an agent needs to invoke and interpret it. Slightly long-winded but functionally 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 coverage is 100% and the schema already documents size with its default and 1..1024 clamp plus timeoutMs/threadContext. The description repeats the clamp/default without adding syntax beyond the schema, so 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 (generate) and resource (cryptographically random bytes) and names the underlying primitive crypt.generatebytes. It also points to the complementary crypt-base64-decode sibling for raw bytes, so an agent can place it in the crypto family without opening a 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?

Gives clear context: bytes come back Base64, decode with crypt-base64-decode if raw bytes are needed, and it requires an executor exposing crypt.generatebytes. It does not explicitly contrast with crypt-generate-key or crypt-hash, but the usage conditions 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?

Goes well beyond the annotations: discloses it is a pure, side-effect-free in-game compute, names the required `crypt.generatekey` capability, and states the failure contract (returns { error } instead of throwing, pcall-guarded). This is exactly the behavioral context annotations can't convey.

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

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

Front-loaded with purpose and return shape, which is good, but the trailing metadata (`idempotency=read-only`, `Safety: read-only`) duplicates the readOnlyHint/idempotentHint annotations and adds boilerplate weight without new 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, the description carries the return contract itself ("Returns { key } or { error }") and names the fallback tool (tool-schema) for deeper details. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so both params are already documented with their own descriptions. The description restates the signature and default-omission behavior but adds no new syntax or constraint meaning, 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 ("Generate a cryptographically random symmetric key") and names the downstream siblings it feeds (crypt-encrypt / crypt-decrypt). An agent can distinguish it from crypt-generate-bytes or crypt-hash without opening any 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?

Gives clear context for use: the key is Base64-suitable for crypt-encrypt / crypt-decrypt, and it notes the active-client prerequisite. It does not explicitly contrast against the nearest alternative (crypt-generate-bytes), so it stops short of full when/when-not routing.

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

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds genuinely new behavioral facts: it runs entirely in-game via the executor's crypt.hash, it is pcall-guarded, and on an executor lacking crypt.hash it returns { error } instead of throwing. Those failure semantics are not derivable from the annotations.

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

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

The core behavior and error semantics are front-loaded in the first two sentences. The trailing 'Phase/cost/idempotency/Safety/On failure' block is somewhat redundant with the annotations and footer-ish, but the overall structure remains scannable.

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 steps in to define the return shape ({ hash, algorithm } or { error }) and the failure path, and it points to tool-schema for exact fields. An agent has everything 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 100%, so the schema already documents data, algorithm (with enum + default), timeoutMs, and threadContext. The description restates the signature and adds only the note that the result is a hex digest string, which is marginal beyond the 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+resource ('Compute a cryptographic digest of a string') and enumerates the exact algorithm surface (sha1/sha256/sha384/sha512/md5) plus the default. This clearly separates it from adjacent siblings like crypt-encrypt, crypt-base64-encode, and generic execution 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 useful context for invocation: phase=observe, cost=medium, requires active-client, and that the tool degrades gracefully rather than throwing. It does not explicitly contrast against alternatives such as run-luau or execute-lua-state, which is the only real gap.

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 and idempotentHint=false, but the description adds substantial context beyond them: the operation cannot be undone, it is type-guarded and pcall-wrapped, delfile-missing yields a specific error object, and failures (missing file, permission) return { error = <message> }. It also states the return shape and the approval requirement, which annotations do not convey.

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

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

The purpose and scope are front-loaded in the first two sentences, which is good, but the description then trails into a long block of metadata-style fields (Phase, cost, idempotency, Capabilities, Produces, On failure) and a generic closing instruction to inspect tool-schema. Several of these clauses are filler relative to selection and invocation, so it is more verbose than it needs to be.

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 carries the return contract itself ({ path, ok = true } or { error }) plus error-case behavior, prerequisites, and a verification sibling. Nothing an agent needs to invoke and interpret this destructive tool correctly appears to be missing.

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

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

Schema description coverage is 100%, so the schema already documents path, timeoutMs and threadContext. The description restates the signature and reinforces that path is executor-relative rather than game-relative, which is useful disambiguation, but it adds no syntax, format, or default detail beyond the schema. Baseline 3 is correct.

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 ('Delete a single file from the executor's workspace folder') and immediately scopes it against siblings by clarifying it is executor-side I/O, not the Roblox game. An agent can distinguish it from delete-folder, read-file, write-file and append-file without opening any 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?

Gives clear operational context: the path is relative to the executor workspace on the host, not the game, and it lists prerequisites (active-client, resolved-target, explicit-mutation-approval) plus a verification step (file-exists). It does not explicitly contrast with the closest sibling, delete-folder, so it stops short of full when/when-not routing.

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

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

Goes well beyond the annotations by disclosing that deletion is recursive on most executors, irreversible, type-guarded and pcall-wrapped, with concrete error payloads and return shapes. Annotations cover the safety flags but the description adds substantial operational detail.

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?

Purpose and the critical NOT-the-game warning are front-loaded, and the metadata (phase, idempotency, requires, produces) is organized. It is dense and includes some boilerplate, but every part is scannable and 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 output schema, the description fully specifies return values, error cases, prerequisites, and a verification tool. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the schema already documents path, timeoutMs, and threadContext. The description restates the signature and the executor-relative path semantics, adding little beyond what the schema provides — baseline 3.

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 (folder) with explicit scope: the executor's workspace, not the Roblox game. This cleanly distinguishes it from siblings like delete-file and destroy-instance.

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 clear context (executor-side file I/O, phase=act, requires explicit-mutation-approval) and a verification path (file-exists). It implies when to use it, but does not explicitly contrast against delete-file for the folder-vs-file decision.

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, but the description adds substantial context beyond them: exactly what Destroy does (unparents the subtree, disconnects descendant events, locks Parent so re-parenting is impossible), the irreversibility, and the server-replication risk of destroying Characters or script instances. It also discloses the return shape and that path/ClassName are captured before destruction.

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 warning and mutation status are correctly front-loaded, and the destroy semantics are explained efficiently. However, the trailing meta-block (Phase/cost/idempotency/Requires/Produces/On failure: inspect tool-schema...) is boilerplate, and the irreversibility warning is stated twice, so a few sentences do not fully earn their 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 output schema, the description supplies the return contract ({ Destroyed, ClassName, ok } or { error }), the mutation and replication semantics, required preconditions, and a follow-up verification tool. Nothing an agent needs in order to invoke this correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents both parameters thoroughly (including the Luau-expression evaluation and the descendant caveat). The description adds a signature recap and the reminder to resolve the EXACT instance, which is a small amount of reinforcement rather than new semantic content.

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 (destroy/remove) and resource (a live Instance), explains the mechanism (inst:Destroy()), and distinguishes itself from the sibling clone-instance by naming it as the alternative. An agent can separate this from set-instance-property or create-instance without opening any 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?

Explicit when-to-use conditions are given: 'Only destroy instances you are certain about', 'use clone-instance first if you might need a copy', plus named prerequisites (active-client, resolved-target, explicit-mutation-approval) and a verification step (verify-path-exists). The condition selecting the alternative tool is stated outright.

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/non-destructive, and the description adds substantial non-obvious behavior: state lives client-side in getgenv().__mcp_snapshots[name] and persists across calls, per-game/per-session isolation, the maxInstances cap and its truncation risk, pcall-guarding that skips locked/destroyed instances, and the 200-entry detail cap with exact counts always reported.

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?

Front-loaded with the driving question, then the numbered workflow, then mechanics, then return shapes; nearly every sentence carries information. Minor redundancy appears in the tail ('Non-mutating', 'idempotency=read-only', 'Safety: read-only' restate the same trait) and the signature/phase line duplicates schema 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?

With no output schema, the description compensates fully by spelling out both return payloads (snapshot's {action,name,root,captured,truncated} and compare's counts/added/removed/changed shapes). For a 5-param verify-phase tool, an agent has everything needed to call and interpret 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 100%, so the baseline is 3, but the description contributes extra meaning: it clarifies that 'name' is the pairing key shared by snapshot and compare, that 'root' is an evaluated Luau expression with examples, and that a tighter root yields a faster/less noisy diff and mitigates truncation near maxInstances.

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 ('snapshotting an instance subtree, performing the action in-game, then diffing') framed around a concrete question the agent would ask. It is clearly separable from siblings like compare-instances, watch-value, and get-instance-tree because it pairs a pre/post snapshot around an in-game action rather than a live subscription or a static tree dump.

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 an explicit three-step workflow (snapshot → do the thing in-game → compare with the SAME name) and advises picking the smallest root and distinct names for independent baselines. It stops short of naming alternative sibling tools or stating when this approach is the wrong choice, so it is clear context but not full when/when-not routing.

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

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

Annotations already cover read-only/idempotent/non-destructive, so the bar is lower, yet the description adds real context beyond them: each list is capped at 200 entries, it requires an active client and a resolved target, cost is high, and it returns a structured-observation. It does not describe pagination or truncation behavior when caps are hit, which is the main remaining 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?

Purpose is front-loaded and dense with information, but the back half is a metadata block (Phase/cost/idempotency/Requires/Produces/Safety) that partly duplicates annotations ("idempotency=read-only", "Safety: read-only") and the schema's own signature. The generic "On failure: inspect tool-schema" tail is boilerplate that doesn't earn 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 output schema, the description carries the return-shape burden and does so reasonably: it enumerates the debug.info fields, closure kind, counts, hash, and optional tables, plus prerequisites and caps. It does not sketch the actual response envelope or how errors surface, which a high-complexity tool could still benefit from.

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 baseline is 3, but the description adds meaning the schema lacks: values in the constant/upvalue tables are coerced for display (Instances become GetFullName, functions become tostring), and it restates the call signature. It still doesn't clarify threadContext semantics beyond the schema's own text.

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 ("full IDA-style dump of a single Luau function in one call") and enumerates exactly what is bundled: debug.info, closure kind, counts, function hash, and optional constant/upvalue tables. It explicitly differentiates from siblings by naming inspect-closure and positioning itself as the bundling alternative to get-function-hash/get-closure-constants.

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 clear context for use (reverse-engineering-focused view, resolve target via a Luau expression that yields a function) and names inspect-closure as the complementary tool. However, "complements inspect-closure" is not an explicit when-to-prefer-this-vs-that rule, and no exclusions or preconditions for choosing between the two 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description goes beyond that by disclosing the fallback strategy ('checks the normal hierarchy first, then performs a bounded Workspace model search') and the bounded nature of the search, which is genuinely useful operationally.

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 core guidance is front-loaded in the first two sentences, which is where the value sits. The trailing metadata block (phase, cost, idempotency, safety) partly duplicates the annotations, adding some redundancy without derailing 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?

With no output schema, the description compensates by noting that resolved paths are returned and that failure routing points to tool-schema for exact fields. It covers the essentials for a read-only discovery call, though the exact shape of the returned candidates is not described.

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 limit, playerName, scanWorkspace, and threadContext are already documented. The description's signature line restates parameter names/types without adding semantic detail such as bounds or defaults that the schema lacks, 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 ('Find the active player's character') and precisely scopes the edge cases it handles: missing Humanoid/HumanoidRootPart or custom-named models. An agent can immediately distinguish it from get-local-player-info and generic instance lookups.

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

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

Explicitly says 'Use this after get-local-player-info reports a missing character' and tells the agent to consume the returned resolved paths rather than assuming the conventional path. The trigger condition and the sibling it follows are spelled out, so nothing 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?

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, but the description adds real value: it discloses the scan scope (LocalPlayer/leaderstats/PlayerGui/ReplicatedStorage/ReplicatedFirst), that no remotes are fired, the ranking heuristics, and the precondition "Requires: active-client". Minor redundancy between "Pure read", "Safety: read-only", and the annotations.

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

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

Front-loaded with purpose, then scoring, then usage and constraints — every major sentence earns its place. Slightly bloated by the trailing meta-block (Phase/cost/idempotency/Produces/Safety) which partially duplicates the annotations.

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

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

With no output schema, the description supplies the return shape ({ path, class, name, value, score, reasons[] }), the failure path (inspect tool-schema), and a bounded-result contract, leaving nothing an agent needs to invoke it correctly unspecified.

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 baseline is 3, but the description explains the scoring dimensions (name keywords, container weight, kind, magnitude), which gives concrete meaning to what minScore filters on and why leaderstats candidates rank highest. extraRoots is only listed in the signature block, not further explained.

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: auto-discovering money/score/XP value paths, with exact scan roots and a keyword-based scoring method. An agent can distinguish it from siblings like find-string-in-tables, search-gc-value, scan-number-range, and read-path-value without opening any 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?

"Use this as the first probe on any unfamiliar game" gives a clear when-to-use trigger and implies manual tree traversal as the alternative. However, no sibling tools are named as alternatives, so the routing is contextual rather than explicit.

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?

Goes well beyond the annotations (destructiveHint/readOnlyHint/idempotentHint) by disclosing the pcall-guarding so a bad handle won't abort the wipe, the exact error payload when Drawing is unavailable, the return shape ({cleared, failed, drawingClearCalled}), and the active-client plus explicit-mutation-approval prerequisites. This is rich operational context an agent cannot get from structured fields.

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 core behavior is front-loaded and dense but mostly earns its place, covering mechanism, guards, and return values. The trailing metadata block (Phase/cost/Requires/Produces/Verify/Safety) and the closing 'inspect tool-schema for exact fields' line are somewhat boilerplate, keeping it just 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?

Despite no output schema, the description fully specifies return values in both success and failure cases, the executor prerequisite, and the mutation approval requirement. For a destructive overlay-wipe tool whose safety profile is already in annotations, nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100% and both optional parameters (threadContext, timeoutMs) are fully documented in the schema. The description's 'Signature: { threadContext, timeoutMs }' adds nothing beyond what the schema already provides, 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 precise verb and resource ('Tears down the entire MCP-managed Drawing overlay') and details the exact mechanism (iterating __mcp_drawings handles, calling :Remove(), emptying the registry, optional Drawing.clear()). This clearly distinguishes it from the single-object sibling draw-remove and the read-only list-drawings.

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 explicit context: 'Use it as a one-shot reset between ESP sessions,' and names list-drawings as the verification step. It does not explicitly name draw-remove as the alternative for removing individual objects, so the when-not guidance 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?

Annotations already declare the mutation profile (destructiveHint=true, idempotentHint=false), and the description goes well beyond them: type-guard on the `Drawing` table, the exact error payload when unavailable, pcall-guarding on every call, the fact that handles persist across tool calls, and that failed properties appear in `applied` with ok=false without aborting the create.

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 opening sentence is well front-loaded and dense with useful detail, but the body is a very long single block that re-lists the full signature already present in the schema and appends machine metadata (Phase, cost, Capabilities, Produces, Safety) as one run-on string. Several clauses restate structured data rather than adding new 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, the description carries the return contract itself ({ id, type, applied[] } vs { error }) and covers failure modes, persistence, and executor availability. For a mutating 4-parameter tool this is complete enough that an agent could invoke it correctly without opening the schema.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning the schema lacks: the loadstring/Luau-expression-string convention for `properties` and per-type supported properties (Line: From/To/Thickness; Text: Text/Size/Position/Center/Outline; Circle: Center/Radius/NumSides/Thickness/Filled). It adds value beyond the schema without fully enumerating Quad/Triangle/Image props.

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 a new on-screen overlay object via the executor `Drawing` library') and enumerates exactly what it produces (handle stored in getgenv().__mcp_drawings, returns { id, type }). It is unmistakably distinct from the sibling draw-update / draw-remove / draw-clear / list-drawings tools.

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