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

With no annotations, the description carries the full burden, and it does add real behavioral facts: the message is local-only, it is not server chat, it cannot run commands, and tag/colors are config-driven. It omits whether the message is ephemeral or persisted, whether it requires permissions, and what the call returns on failure.

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

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

Two tight sentences: the capability and its rendering first, the exclusions second. No filler, and the most important constraint is front-loaded.

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

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

For a single-parameter, no-output-schema display tool this is close to complete: it says where the text appears, how it is formatted, and what it will not do. The main residual gap is error/return behavior, which the description does not mention.

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?

Only one parameter and 0% schema description coverage, so the description must compensate. It adds useful meaning ("progress message in English", the [AGENT] prefix, tag/colors from config), but the 1–2000 character constraint lives only in the schema and the parameter itself is never explicitly named or 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 ("display") and resource ("progress message in ... local Minecraft chat"), and pins down the rendering format including the [AGENT] prefix. It also carves itself away from server chat and command execution, which implicitly separates it from the `execute` sibling, though it never names that sibling.

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

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

Usage is only implied: it is for showing progress messages to the player. There is no explicit when-to-use, no mention of when to prefer `execute` or `read_output`, and no stated preconditions (e.g. player must be online, rate expectations).

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 substantial work: fresh context per run, native JsMacros and mod Java APIs available, console.log/print captured, and async early-return semantics with a task ID. It omits the security/permission implications of arbitrary code execution and error/exception behavior, 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?

Four short sentences, front-loaded with what gets executed, followed by environment, output capture, and return semantics. The 'GraalJS, not Node.js' caveat is terse and prevents a real class of invocation errors, so every sentence 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?

No output schema and no annotations mean the description is the only source of behavioral detail, and it covers execution environment and the early-return path well. However, for a three-parameter arbitrary-code-execution tool it leaves wait_ms semantics, code-vs-file precedence, and failure modes undocumented.

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

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

Schema description coverage is 0%, and the description only adds meaning for two of the three params: `code` (JS source) and `file` (must be an absolute local .js path). It never explains whether code and file are mutually exclusive or which wins, and `wait_ms` — with a 0–10000 range and 1000 default — is not mentioned at all despite being the control that determines whether the call returns early.

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 two concrete input modes: run JS code or an absolute local .js file, executed in a fresh JsMacros context. It also disambiguates the runtime ('GraalJS, not Node.js') and points at the async sibling read_output, so an agent can tell exactly what this tool does and how it differs from read_output/stop.

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 routes the agent to read_output when the call returns early with a task ID, which is the key alternative-selection rule for this tool family. It does not state when to prefer inline `code` over `file`, nor when not to use the tool at all, 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?

With no annotations, the description carries the full burden and does well: it discloses no filesystem dependency, single-reader semantics, non-repeating output, and a bounded buffer that surfaces dropped_chars on overflow. It omits what happens on an empty buffer and whether the call blocks, which is the main remaining behavioral 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?

Four short sentences, each carrying distinct information (what it reads, no filesystem, single-reader non-repeating semantics, buffer overflow reporting), with the core purpose front-loaded. Nothing is wasted.

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

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

There is no output schema and no annotations, so the description is the only source of contract detail. It covers stream behavior well but leaves the return shape and the wait_ms blocking semantics undefined, which matters for correct invocation of a streaming read.

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

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

Schema description coverage is 0% for both parameters, so the description must compensate and does not. 'for a task' loosely ties to the task argument, but wait_ms — a blocking hint with a 0-10000ms range and default 0 — is never mentioned, leaving the agent unable to infer that it can wait for output.

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 and consume newly buffered output for a task, plus its native execution state. Against siblings like execute, stop, screenshot and chat, it is unmistakably the output-retrieval tool, so no schema opening is needed to tell them apart.

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

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

Usage is implied by 'consume newly buffered output' and the single-reader warning, which tells the agent output is gone once read. However, it never states when to call this versus polling, nor what to do when no output is ready, and it names no alternatives among the siblings.

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 zero annotations the description carries the full burden, and it does disclose meaningful traits: what is included in the capture (HUD, menus, overlays) and that the image is returned inline rather than written to a shared directory. It stops short of latency/cost, whether the call blocks the game loop or requires a render tick, and whether capture works while paused.

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

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

Two short sentences, front-loaded with the capture scope and followed by the return mechanism. Every clause earns its place and nothing is redundant.

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

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

For a zero-parameter, no-output-schema tool this is nearly complete: it explains what is captured and that an image comes back directly. A minor gap remains around the image format/size or which content block carries the payload, which matters since there is no output schema to describe the return value.

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

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

The schema declares zero parameters, so there is nothing for the description to disambiguate; baseline for a parameterless tool is 4. The description correctly avoids inventing parameters and instead spends its words on scope and return behavior.

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

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

Specific verb ("Capture") plus a precisely scoped resource ("the actual Minecraft framebuffer including HUD, menus and overlays"). The word "actual" implicitly contrasts with a clean/render-only capture, and no sibling tool (execute, read_output, stop, chat) could be confused with it, though it never names an alternative explicitly.

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

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

Usage is implied rather than stated: an agent infers it should call this when it needs to see the current game screen. The note that "no shared screenshot directory is needed" removes a workflow blocker, but there is no explicit when-to-use, when-not-to-use, or comparison against siblings such as read_output.

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 delivers real side-effect disclosure: it cancels Baritone, releases scripted input, and explicitly does not touch the bridge service. It stops short of saying what happens to a task mid-execution or whether partial output survives.

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

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

Three short sentences, front-loaded with the primary action, then side effects, then the scope exclusion. No filler and nothing an agent must read twice.

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-param mutation with no annotations and no output schema, the description covers action, targets, side effects, and an explicit non-goal. The remaining gap is how to address a specific task and what, if anything, comes back.

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

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

Schema coverage is 0% and the single optional `task` parameter is a bare string. The phrasing "one ... task or all MCP tasks" implies omitting it stops everything, but the description never states that rule outright nor says whether the value is a task name, ID, or handle.

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 opens with a specific verb+resource ("Stop one MCP-owned JsMacros task or all MCP tasks") and immediately bounds the target set with "MCP-owned". The closing clause "Does not stop the bridge service" carves out scope so an agent can tell this apart from a session/bridge teardown.

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 scope (one task vs. all tasks) and the implicit motivation ("release scripted input for player takeover") hint at when to call it, but no sibling is named and there are no explicit when-not conditions against alternatives like execute. Usage is inferable rather than stated.

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