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

With no annotations, the description carries the full burden and does so: thread identity 8, per-run global scope, executor-vs-game _G distinction, requirement to yield on heavy scans, spawned threads surviving a timeout cancellation, and large results being written to a temp file. These are non-obvious runtime traits an agent could not infer elsewhere.

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 and return shape are front-loaded in the first sentence, followed by tightly scoped bullets. Every bullet carries operational information (scope, yielding, timeout side effects, ordering) with no filler.

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, but the description compensates by describing exactly what comes back (return values, serialized tables/Instances/Vector3s, print/warn, traceback, temp-file path for large results). Combined with the timeout and logging caveats, an agent has everything needed to call this correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning: code vs file are framed as alternatives, and the timeout is explained behaviorally ('the run itself is cancelled, but threads it spawned keep running'), which the schema's plain 'Seconds to wait for the result' does not convey.

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 Luau in the Roblox client') plus the exact return payload: return values, print/warn output, and errors with traceback. It also implicitly separates itself from the 'logs' sibling by noting that post-return output lands there instead.

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 routing conditions: use the file parameter for local files, use logs sinceExecute=true for prints/errors emitted after the run returns, and note that parallel calls may interleave unpredictably. The getgenv()/_G/getrenv() state guidance tells the agent when state must be persisted rather than re-declared.

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

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

With no annotations present, the description carries the full burden and does so well: it discloses ordering (newest last), output-shaping behaviors (repeated lines collapsed to (xN), long messages truncated with full results saved to a greppable temp file), and error provenance tagging ('mcp:<line>' vs 'Opiumware:<line>'). These are non-obvious operational traits an agent could not infer from the 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 leads in the first clause, followed by three tight bullet-style lines covering the debug loop, error tagging, and output shaping behavior. Every sentence carries information; there is no filler or repetition.

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 six-parameter tool with no annotations and no output schema, the description covers ordering, truncation, collapsing, and provenance tagging well enough to call it correctly. It stops short of describing the shape of individual returned entries, which is the only notable remaining gap.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond it: it explains what sinceExecute actually captures (everything since that run started, including deferred errors and spawned loops) and frames grep as the way to filter the provenance tags. That is genuine added context on top of the schema's own 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 ('Read the Roblox client console') and scopes it precisely to print/warn/error from all scripts, including the game's own. This clearly separates it from siblings like network, status, and screenshot without the agent needing to open 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?

The description gives explicit conditional guidance: call with sinceExecute=true after an execute run to catch deferred errors and spawned loops, or new=true for everything since the previous logs call. That is clear routing between parameter modes, though there is no explicit statement of when NOT to use this tool.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that start replaces the previous log, that hooks exist only during capture, that the log is retained after stop, that executor-originated calls are tagged [by executor], and that long results are truncated to a temp file. Missing peripheral details like auth or port behavior, but the key lifecycle and side-effect traits are covered.

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 capability is stated first, then bulleted semantics for each action and each read mode. Every line carries information — no filler, no repetition of the schema, and the bullets make it 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?

There is no output schema, so the description properly explains the return shape (per-remote summary vs. individual calls, truncation with temp-file fallback). Combined with the action semantics, an agent has enough to invoke and interpret results, though a note on how the temp file path is returned would close the last gap.

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

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

Schema already describes all five parameters (80% coverage), yet the description adds genuine meaning: the two read modes (summary vs. individual calls collapsed), what collapsing means, and concrete use of `exclude` (hiding noisy remotes). It exceeds the baseline-3 expectation for high-coverage schemas.

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 ("Capture remote traffic between the client and server") and enumerates exactly what is captured — outgoing FireServer/InvokeServer with return values and calling script, plus incoming OnClientEvent. This level of specificity makes it trivially distinguishable from siblings like logs or scripts.

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 clearly documents when to use each action (start/stop/read), notes that read works while running, and gives actionable advice ("stop as soon as you have what you need"). It stops short of explicitly routing against alternative sibling tools such as logs or scripts, so it lands at 4 rather than 5.

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

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

With no annotations, the description carries the full behavioral burden and delivers real value: it discloses that capture bypasses window occlusion and that each image costs ~1K tokens, a meaningful rate/cost signal. It omits any permission or error behavior and does not state what is actually returned, so it stops short of fully covering the operation.

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

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

Two tight sentences with zero waste: the capture semantics come first, then usage, then the cost caveat. Every clause contributes information an agent needs.

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

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

For a one-optional-parameter read tool with no output schema, the description supplies the key operational facts (what is captured, why to call it, token cost). It could note that the result is image content and any failure modes, but nothing essential to invoking 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% ('Opiumware port of the Roblox instance'), so the sole optional parameter is fully documented in structured form. The description adds no port-selection guidance, which is the baseline expectation when the schema does the heavy lifting.

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 ('Capture the Roblox window') plus a distinguishing qualifier ('as the player sees it, works even if other windows cover it'). This cleanly separates it from siblings like logs, network, scripts, execute, and status, which retrieve non-visual data.

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

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

Gives a concrete use case ('Use to verify visual scripts (ESP, UI, menus)') and a frugality constraint ('use sparingly') driven by token cost. It stops short of naming an alternative or an explicit when-not-to-use condition, so it is clear context rather than 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?

With no annotations, the description carries the full disclosure burden and does well: it states the scope limitation ('server Scripts never reach the client'), the caching side effect (decompiled sources saved as .luau in a temp folder mirroring the game tree), the first-call latency, and the pagination window (150 lines at a time). It does not mention permissions/auth or failure modes, but the read-oriented nature is clear.

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 before the bulleted per-action breakdown, and every sentence carries information (scope, caching, latency, pagination). Slightly dense, but nothing is padding.

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-parameter tool with no annotations and no output schema, the description supplies the missing context an agent needs: what the actions do, that results are also readable on disk, the shape of search matches, and the read windowing. Only minor gaps remain (exact auth/port semantics, failure behavior when nothing decompiles).

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 88%, so the baseline is 3, and the description adds real meaning on top: read defaults to 150-line windows governed by startLine/endLine, path must be the full path as shown by list/search, and search output is path:line matches. This clarifies parameter interrelationships (query vs limit, filter vs path) that the schema only 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?

The description names a specific resource (the game's client-side code: LocalScripts, ModuleScripts) and enumerates the three concrete operations (list/search/read) with what each returns. None of the siblings (screenshot, status, execute, logs, network) overlap with script source inspection, so an agent can place this tool unambiguously.

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?

Each action is given a clear purpose ('list: script paths (optionally filtered)', 'search: regex across all decompiled sources', 'read: one script's source'), which serves as when-to-use guidance for the sub-commands. It also flags the cost condition ('The first search decompiles everything (a few seconds)'), but offers no explicit exclusions or comparison to an alternative tool.

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

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

No annotations are provided, so the description carries the full burden. It discloses what is inspected (ports, game/player, decompiler state), implying a non-mutating read, and it tells the agent to run it before other operations. It never explicitly states it is read-only/side-effect free, which is the one gap for a no-annotation tool.

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

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

Two sentences, zero waste. The subject of the check is front-loaded and the usage instruction follows immediately; every clause adds information.

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

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

With no output schema and no annotations, the description compensates by enumerating the reported fields. It is complete enough to invoke correctly, though it omits any hint of response shape (e.g., per-instance list vs. summary) that an agent might want.

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, which is the baseline-4 case. There are no argument semantics to explain, and the description correctly implies a parameterless probe.

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 ('Check') and resource ('the connection') and enumerates exactly what is reported: live Roblox instances/Opiumware ports, the game/player per instance, and whether the decompiler is running. Among siblings (screenshot, execute, logs, scripts, network), it is unmistakably the diagnostic/health tool, so an agent can distinguish it 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?

'Call this first or when something isn't working' gives explicit conditions for invocation, which is unusually useful for a diagnostic tool. It does not name a specific alternative tool to use instead, so it falls short of full when/when-not routing, but the trigger conditions are clear.

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