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

The description is consistent with readOnlyHint=false, and adds the useful detail that the output is a WAV of the mixer output. However, it omits behavior an agent would want: what happens if a capture is already running, whether the file is finalized only on audio_capture_stop, and any overwrite/auto-numbering 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?

A single, front-loaded sentence with no filler. The resource and scope come first, and nothing redundant is included.

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 tool with no output schema, the description covers the essential purpose adequately. It is slightly incomplete regarding the capture lifecycle (how to stop, whether a capture can be started twice), but nothing critical is missing for 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% for the single optional 'path' parameter, so the baseline is 3. The description adds no extra semantics about the path or auto-numbering beyond what the schema already states.

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 (start), resource (audio capture), and format/source (WAV of mixer output), which cleanly separates it from audio_capture_stop and audio_capture_status. It does not explicitly name or contrast with those siblings, so it falls short of a 5.

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

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

There is no when-to-use guidance, no prerequisites (e.g., mixer must be active), and no mention of the related stop/status tools an agent would need to complete the capture workflow. The description only says what it does, not when to reach for 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?

The readOnlyHint=true annotation already declares this is a safe read, and the description adds no further behavior beyond restating that it checks capture state. It does not say what the check returns (boolean vs. status object) or whether it blocks.

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

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

A single front-loaded sentence with no filler; every word earns its place.

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

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

For a simple no-argument status query it is nearly adequate, but with no output schema the description should hint at the return value (e.g., in-progress boolean or capture details) that the agent will receive.

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 schema is trivially complete and the description need not explain inputs. Baseline 4 for a no-parameter tool.

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

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

States a specific verb ('Check') and resource ('whether an audio capture is in progress'), clearly distinguishing it from audio_capture_start/stop and paralleling video_capture_status. It is clear, though it does not explicitly name the sibling it complements.

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

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

Usage is only implied — an agent can infer it is used to poll capture state after starting an audio capture — but there is no explicit when-to-use, no mention of audio_capture_start, and no stated conditions or alternatives.

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 annotation readOnlyHint=false already indicates this is not a read-only operation, and the description's 'Stop' is consistent with that. However, the description adds no behavioral detail beyond the annotation, such as whether an active WAV file is finalized, what happens if no capture is running, or what the call returns.

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

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

The description is a single front-loaded sentence with no wasted words. It states the action and resource immediately, which is ideal for a simple control command.

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 parameterless stop command with no output schema and a minimal annotation, the description is nearly complete: it says exactly what operation is performed. It could add a note about the expected effect on an active capture, but an agent has enough information to invoke it correctly.

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

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

The tool takes zero parameters, so the schema has no parameter semantics to document. The description correctly does not introduce any parameter details, and the baseline for zero-parameter tools is 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 gives a specific verb ('Stop') and resource ('WAV audio capture'), clearly distinguishing it from siblings such as audio_capture_start, audio_capture_status, and video_capture_stop. An agent can identify the correct 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?

The description states what the tool does but gives no explicit guidance on when to use it versus alternatives. It does not mention calling audio_capture_start first, checking audio_capture_status, or any condition that would select this tool over another.

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?

readOnlyHint=false signals a state-changing operation, and the description adds genuine behavioral detail beyond that annotation: it reads a token, probes the API, negotiates a protocol version, and returns a precise failure reason. This tells the agent the call has a multi-step side effect and produces diagnostic error output. It stops short of describing idempotency or auth/permission requirements.

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

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

One front-loaded sentence with the action verb first, followed by a compact clause on failure reporting. No filler or restated 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 and no parameters, the description covers the essential contract: what is attached to, the handshake steps, and that failures are reported with a reason. It omits what a successful return looks like (e.g., negotiated version or session handle), a minor gap for a connect tool.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The absence of parameters also matches the 'attach to whatever instance is running' framing.

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 ('attach'/'connect') and resource ('the running dosbox instance'), and the phrase 'running' implicitly separates it from bridge_start/bridge_stop. It doesn't explicitly name the sibling boundary, but an agent can still tell this negotiates a connection rather than launching a bridge.

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?

'Attach to the running dosbox instance' implies the precondition that the instance is already running, which is useful context. However, it never states when to call this versus bridge_start, bridge_status, or bridge_disconnect, nor what to do if it fails, leaving usage 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 only supply readOnlyHint=false, so the description usefully clarifies that the underlying instance is unaffected by the detach. It says nothing about session-side effects (whether the connection is re-establishable, whether any local state is lost, or required auth), leaving gaps for a mutation of connection state.

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

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

A single short sentence with the key behavioral constraint ('keeps running') front-loaded immediately after the action. Every word earns its place.

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

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

For a no-parameter, no-output-schema tool, the description covers the essential distinction from bridge_stop. A pointer to bridge_connect for reattaching would make it fully complete, but nothing critical 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?

The tool takes zero parameters and the schema is empty, so there is nothing to document; baseline 4 applies. No parameter information is needed in the description.

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 ('Detach') and resource ('the instance'), and the clause 'it keeps running' implicitly distinguishes it from the sibling bridge_stop, which presumably terminates the instance. It does not name the sibling explicitly, so it falls short of a 5.

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

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

The phrase 'it keeps running' implies when to prefer this over bridge_stop, but the description never states that alternative or any precondition (e.g., must be connected first). Usage is implied 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. With no output schema, the description is the sole source of return information and it fully discloses the payload (version, connection state, full tool list with one-line descriptions), which is meaningful added context. It doesn't mention pagination or payload size for the all-tools listing, but for a zero-side-effect tool the coverage is solid.

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

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

A single, tightly packed sentence that front-loads the core idea ('One-call orientation') before enumerating the three components returned. No filler, no redundancy.

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

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

For a zero-param, read-only orientation tool with no output schema, the description supplies everything needed to know what comes back. The only gap is routing guidance versus the overlapping bridge_version/bridge_status/bridge_swagger siblings, which the description does not address.

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 by the rubric the baseline is 4. There is nothing for the description to explain beyond confirming this is a no-argument call, which it implicitly 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?

The description names a specific verb-driven purpose (one-call orientation) and enumerates exactly what it returns: version, connection state, and a catalog of every tool with one-line descriptions. This is clear and concrete, but it never distinguishes itself from siblings like bridge_version or bridge_status, which cover overlapping subsets of the same information.

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?

'One-call orientation' implies the intended usage (bootstrap/discovery at the start of a session), but this is left to inference. There is no explicit when-to-use or when-not-to-use guidance, and no mention of when to prefer bridge_version, bridge_status, or bridge_swagger instead of this consolidated call.

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 establish readOnlyHint=true, and the description adds value on top: '(untrusted machine output)' warns the agent to treat the payload with suspicion, and the scoping clause discloses which instances are covered. This is meaningful behavioral context beyond the safety annotation, though it doesn't describe buffering limits or what happens when nothing is buffered.

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, no filler. The trust warning is placed immediately after the core purpose, so the most important safety signal is front-loaded and nothing is wasted.

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

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

For a read-only, single-optional-param tool with no output schema, the description covers purpose, scope, and trust level adequately. Minor gaps — buffering behavior and how to obtain instance handles — exist but don't block 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% and the single parameter 'n' is fully documented there ('Number of lines from the end (default all buffered)'). The description adds nothing about the parameter, so the baseline 3 applies — the schema carries the load.

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+resource: 'Tail of the spawned instance's output.' An agent can immediately tell this retrieves process output, and the scoping clause separates it from the other bridge_* tools (start/stop/status). It stops short of explicitly naming alternatives, but the purpose 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?

'Only covers an instance this bridge started' gives a real applicability constraint — it won't return logs for arbitrary processes. However, there is no explicit when-to-use guidance, no routing to siblings like bridge_status or bridge_help, and no mention of prerequisites for having an instance running. Usage is implied rather than prescribed.

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 only supply readOnlyHint=false, so this is a mutation the description must explain. It does add real context beyond the annotation: the change is scoped to 'safe' settings and requests involving the binary path or capability mode are rejected by design — non-obvious behavior an agent cannot infer from the schema. It stops short of saying whether changes persist across restarts or require a reconnect to take effect.

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, zero filler, with the core purpose front-loaded and the exclusion rule following immediately. Nothing could be removed without losing information.

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

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

For a small mutation tool with three optional parameters and no output schema, the description covers scope, the accepted fields, and the rejection behavior adequately. The remaining gap is effect semantics — whether the change is persisted or applied to a live bridge — which an agent might reasonably need but which is minor given the tool's narrow surface.

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

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

Schema description coverage is 100% and each parameter already has a short description, so the baseline is 3. The description enumerates the same three settings and adds the fact that two further settings exist but are deliberately excluded, which clarifies the parameter space without documenting syntax beyond what the schema provides.

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 ('Change') plus the exact resource ('safe bridge settings') and enumerates the three mutable fields (port, headless, protocol pin). It also carves out what it will not touch, which lets an agent separate it from siblings such as bridge_start, bridge_stop, bridge_version and bridge_status 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?

Clear about the context in which it applies ('safe bridge settings' only) and explicitly states that the binary path and capability mode are rejected here by design, which is a useful when-not rule at the parameter level. It does not, however, name an alternative tool for changing those excluded settings, nor does it state any prerequisites for calling 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 only supply readOnlyHint=false, so the description carries most of the burden and does so well: it discloses that the process is spawned from a human-edited config file, run with an isolated config dir, that it attaches afterward, and that it refuses when an instance is already managed. It stops short of describing failure modes beyond the busy case or what a successful spawn yields (PID, session id).

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 with no filler; the core action and the config-dir detail come first, and the refusal precondition lands last as a guard. Every clause earns its place.

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

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

For a no-parameter lifecycle tool with a thin annotation set and no output schema, the description covers the essential behavior and the key precondition. Remaining gaps — what is returned on success and the behavior on partial failure — are modest given the absent output 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?

The tool takes zero parameters, which sets the baseline at 4. The description correctly implies the binary/configuration comes from a human-edited config file rather than any argument, so an agent is not left hunting for a missing path parameter.

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 ('Spawn') and resource ('the dosbox binary named in the human-edited config file') plus the follow-on action ('attach to it'), so an agent knows this launches and binds to a new DOSBox instance rather than connecting to an existing one. It does not explicitly name the sibling it contrasts with (bridge_connect), which keeps it short of a 5.

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

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

Provides one hard precondition — 'Refuses while an instance is already managed' — which tells the agent when the call will fail. However, it never names the alternative to use instead (bridge_connect / bridge_stop) or when to prefer starting a fresh instance over attaching, so 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 readOnlyHint, and the description adds genuinely useful non-obvious context: that the token is reported only as presence and never as a value. It also signals the response is an enumeration of state fields rather than an action, reinforcing the no-side-effect 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?

A single front-loaded sentence with a compact field list. Every clause carries information, and the security caveat is placed prominently without 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?

No output schema exists, so the description must carry the return-value burden, and it largely does by enumerating engine version, protocol, features, capability mode, managed instance, and token presence. It does not hint at the format of items like capability mode or protocol, which is a minor residual gap.

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

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

Zero parameters, so there is nothing to document and the baseline is 4; the description correctly spends no words on arguments.

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

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

Names the resource (bridge and connection state) and enumerates the specific fields surfaced, which naturally separates it from the narrower bridge_version and session_info siblings. There is no explicit sibling callout, but the scope is unambiguous.

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

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

Usage is only implied: an agent can infer this is the read-side diagnostic for the bridge, but the description never says when to prefer it over bridge_version, bridge_logs, or session_info, nor any preconditions.

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 only readOnlyHint=false in annotations, the description usefully discloses the spawn-vs-attach ownership rule, which annotations cannot convey. However it says nothing about whether the stop is graceful or forced, whether it is idempotent, or what happens if the bridge only attached to the instance.

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

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

Two short sentences with zero filler; the core action is front-loaded and the scope caveat follows immediately. Every clause carries information the 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 no-parameter, no-output-schema action tool, the description covers the one non-obvious behavioral constraint. It could go slightly further on error behavior when the instance was attached rather than spawned, but nothing essential 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?

The tool takes zero parameters, so there is nothing for the description to clarify and the baseline of 4 applies. No parameter confusion is possible.

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

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

States a specific verb (Stop) and a precisely scoped resource (the instance this bridge spawned), which is enough to separate it from disconnect-style siblings. It does not name bridge_disconnect or bridge_shutdown explicitly, so differentiation relies on inference from the negative clause.

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 sentence 'Never stops an instance it merely attached to' is an explicit when-not condition that tells the agent this tool only applies to spawned instances. It stops short of naming the alternative tool to use for attached instances, leaving that to implication.

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?

readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the description's burden is lighter. It usefully discloses the content of the result (grouped route counts plus unknown routes) but says nothing about configuration requirements, protocol negotiation mechanics, or how the digest is produced.

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

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

A single tightly packed sentence with the output content front-loaded after the resource. Efficient, though the phrase 'negotiated protocol' is jargon that costs some immediate 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?

No output schema exists, so the description carries the return-value burden alone. It sketches the two return components but not their shape or format, and the meaning of routes 'unknown to the negotiated protocol' is left for the agent to infer.

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

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

The tool takes zero parameters, so there is no parameter semantics for the description to carry; the baseline of 4 applies. Nothing in the description contradicts the empty schema.

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

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

The description names a specific resource (the instance's OpenAPI surface) and states exactly what it yields: route counts per group and routes unknown to the negotiated protocol. That distinguishes it from diagnostic siblings like bridge_status, bridge_version, and bridge_logs, though it never explicitly differentiates itself from them.

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

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

There is no statement of when to call this versus bridge_status, bridge_help, or bridge_logs, and no prerequisites or context for the 'negotiated protocol' framing. The agent must infer it is a diagnostic/digest call.

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?

readOnlyHint=true already tells the agent this is a safe, non-mutating read, and the description does not contradict that. Beyond safety it adds nothing: no indication of whether it reports a locally installed bridge or a connected remote one, whether a connection is required, or what fields come back. With annotations covering only safety, this is a thin 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?

A single tight sentence with no filler, and the core subject (version) is front-loaded. Slight deduction because it reads as a noun phrase rather than a complete statement of action, but nothing is wasted.

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

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

For a no-argument, read-only query with no output schema, the description conveys enough to select and call it correctly. The lack of any note on connection requirements or output shape is a minor gap, but annotational and structural complexity here is near zero.

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 schema imposes nothing to explain; baseline 4 applies. The description's mention of 'protocol level' usefully characterizes the return content rather than any input.

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

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

The description names the specific resource (bridge version) and the shape of the data it surfaces (the protocol level implemented), which is more informative than the bare tool name. It implicitly contrasts with siblings like bridge_status and bridge_logs, though it does not explicitly say how it differs from them.

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

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

There is no statement of when to call this versus bridge_status, bridge_help, or bridge_swagger. The agent must infer from the name alone that this is a lightweight version query. No prerequisites or conditions are given.

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

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

Annotations supply only readOnlyHint=false, i.e. 'this mutates'. The description adds genuine behavior beyond that: segment registers 'update the cached physical base', a non-obvious side effect an agent would not infer otherwise. It stops short of noting reversibility, permissions, or error behavior, so not a 5.

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 action, then the two register classes. Every sentence carries information and nothing is padded or repeated.

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 two required parameters, no nested objects, and no output schema, the description covers what is needed: the operation, the accepted values per class, and the segment-base side effect. Minor omission of any failure/validation behavior keeps it from a 5.

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

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

Schema description coverage is 100%, so the schema already documents both 'value' and 'register', including the register enumeration and value ranges. The description's bit-width rules largely restate 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+resource ('Write a CPU register') and even splits the resource into two register classes with their widths. Clear on its own, but it never distinguishes itself from adjacent write tools in the sibling list such as mem_write or port_write, so an agent gets no explicit routing signal.

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: the register lists tell you what it operates on, but there is no statement of when to reach for this instead of mem_write/port_write or any prerequisite context. No exclusions or alternatives are offered.

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 supply only readOnlyHint=false, so the description must carry the behavioral load. It does disclose the key precondition (execution must already be paused) and that this resumes rather than restarts, but it omits what happens if the target is not paused and whether any execution state is reset, leaving real gaps for a mutation tool.

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

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

A single short sentence with the verb and the precondition front-loaded and no filler. Every word earns its place.

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

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

For a stateless, zero-parameter control action with no output schema, the description covers the essential mechanics. The only shortfall is unstated error behavior when no pause is active, which is a minor omission given the tool's simplicity.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. No misleading parameter information is present.

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

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

The description gives a specific verb ('Resume') and resource ('emulation') plus the scope ('from the current pause point'), which distinguishes it from debug_pause and debug_step without needing the schemas. It stops short of explicitly contrasting itself with those siblings, so it falls just under the top band.

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: the phrase 'from the current pause point' suggests it is paired with debug_pause, and the sibling set makes that inference easy. However, it never states when to use this versus debug_step or what precondition must hold, so no explicit guidance is 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 only annotation is readOnlyHint=false, which is consistent with a state-changing debug control but conveys almost nothing on its own. The description does not say whether the pause is immediate or at the next instruction boundary, whether it requires an active debug session, or that debug_continue is needed to resume, so the behavioral burden is largely unmet.

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

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

A single short sentence with no filler and the key action front-loaded. It is efficient, though its brevity comes at the cost of the missing behavioral detail noted elsewhere.

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 parameters, no output schema, and only readOnlyHint=false, the description is the sole carrier of context — and it omits the prerequisites (running emulation, debug session), the effect on execution state, and how to resume. For a debug control in a dense sibling family, that is insufficient.

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 is no parameter semantics to document or compensate for. The empty schema fully describes the call 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?

The description uses a specific verb and resource ('Pause emulation') and adds the scope qualifier 'at the current instruction', which lets an agent distinguish it from debug_step (advance one instruction) and debug_continue (resume). It stops short of naming those siblings explicitly, so it is clear but not fully differentiated.

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

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

There is no when-to-use guidance: nothing says the emulator must be running, nothing says this is the counterpart to debug_continue, and no condition for choosing it over debug_step or freeze_set is given. An agent must infer all of this from the sibling list.

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

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

The readOnlyHint annotation already establishes that this is a safe, non-mutating read. The description adds value by listing the reported contents (paused, breakpoints, current instruction), which is the only source of return-shape information since no output schema exists. It stops short of stating behavior when the debugger is not paused or whether breakpoints are a count versus a list.

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

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

A single terse fragment with no wasted words, and the resource is front-loaded. It is arguably too clipped (no verb) but every word 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 carries the burden of describing the return value, and it does so only as a bare field list. For a zero-parameter read-only status call this is close to adequate, but edge-case behavior (debugger not paused, empty breakpoint set) is 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?

The tool takes zero parameters, so per the baseline there is nothing for the description to disambiguate. No parameter semantics are missing.

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

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

The description names the resource (debugger state) and enumerates the key fields it reports: paused status, breakpoints, and current instruction. It is distinguishable from mutating siblings like debug_pause, debug_step, and debug_continue, though it lacks an explicit verb such as 'report' or 'return'.

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

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

There is no guidance on when to call this versus debug_pause, debug_continue, or debug_step, nor any mention of prerequisites (e.g., that the debugger must be attached or running). Usage must be inferred from the name alone.

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

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

Annotations only declare readOnlyHint=false, so the description usefully adds the post-condition ('pause again') that the schema and annotations do not convey. It still omits prerequisites (must the target already be paused?) and side effects on CPU/register state, which matters for an execution tool.

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

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

A single front-loaded sentence with no filler; the action and its resulting state are both stated immediately.

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

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

For a zero-parameter, no-output-schema tool the description covers what happens and the resulting paused state, which is nearly enough. A brief note on the paused-state prerequisite or step granularity would close the small 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?

The tool takes zero parameters, so there is nothing for the description to document and the baseline of 4 applies. No parameter meaning is missing.

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 pairs a specific verb ('Execute') with a precise unit of work ('one instruction') and states the resulting state ('pause again'), which clearly separates it from debug_continue. It does not name that sibling explicitly, but the 'one instruction' scoping makes the distinction inferable.

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

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

There is no explicit when-to-use or when-not-to-use guidance. The agent must infer that this is for single-stepping rather than continuing (debug_continue) or halting (debug_pause); no alternatives are named.

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 only declare readOnlyHint=false, so the description's 'Irreversible' is genuinely additive: it tells the agent the operation destroys the session and cannot be undone. It stops short of stating whether state or capture artifacts are lost, but it goes well beyond the annotation.

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, seven words total, with the action first and the risk caveat second. Nothing extraneous.

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 lifecycle tool, the description covers the essential action and its destructive nature. A note on side effects (e.g., lost captures or session state) would make it fully complete.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Schema coverage is 100% and no input semantics are missing.

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 ('Shut down the emulator'), which is clear enough to distinguish it from the many *_stop siblings that target sub-components rather than the emulator itself. However, it does not explicitly name any sibling or scope boundary to remove residual ambiguity.

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

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

No guidance on when to use this versus alternatives such as bridge_disconnect, bridge_stop, or script_stop, nor any prerequisites or cleanup ordering. The word 'Irreversible' implies caution but gives no decision criteria.

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

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

Annotations already cover the safety profile (readOnlyHint=true), and the description adds genuine return-value behavior: the conditional status.archive field that appears only while a mount waits on an archive, with its activity/byte-count subfields. That conditional-field disclosure is real context 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?

Three sentences, front-loaded with the core purpose before the conditional archive detail. The third sentence is dense but earns its place by explaining a non-obvious return field.

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 and does convey the headline fields (program, mount, version) plus the conditional archive field. It doesn't enumerate the full response shape, leaving a modest gap for a status tool with no 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?

The tool takes zero parameters, so the baseline is 4. There is nothing to document and the description correctly ignores parameter 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 resource and enumerates what it reports: running program, mount status, version. Distinguishes itself as the machine-state snapshot tool. It stops short of naming the adjacent siblings (session_info, debug_status) it must be told apart from, so it's clear but not fully differentiated.

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?

"One call answers 'what is the machine doing right now'" implies the usage context but gives no explicit when-to-use vs when-not, nor names alternatives like debug_status or session_info. Usage is implied rather than stated.

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

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

The readOnlyHint annotation already establishes this is a safe, non-mutating operation, so the bar is lower. The description still contributes real context by disclosing what the tool actually enumerates: a walk of the MCB chain and the PSP-owner-to-block mapping, plus the scope of 'full conventional memory layout'. It stops short of noting edge cases such as fragmented chains, UMBs, or unavailable/terminated PSPs, but adds meaningful behavioral value beyond the annotation.

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, no filler. The operative clause (walk the MCB chain, report PSP ownership) comes first, with the summary of the output scope second. 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?

With no output schema, the description must hint at what comes back, and it does: PSP-to-block ownership and the conventional memory layout. Combined with the readOnlyHint and empty parameter schema, an agent has enough to decide and invoke. Only minor gaps remain, such as whether the report is raw MCB entries or a rendered map, and any failure conditions when no MCB chain is present.

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

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

The tool takes zero parameters, so there is no parameter semantics to document; per the rubric this yields a baseline of 4. The description correctly implies the tool is argument-free and operates on an implicit whole-system scope.

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

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

Specific verb+resource: 'Walk the DOS MCB chain and report which PSP owns which memory block' names the exact mechanism (MCB chain), the mapping produced (PSP → memory block), and the resulting artifact (full conventional memory layout). This clearly distinguishes it from sibling readers like mem_read, mem_search, or screen_text, which operate on bytes or UI rather than DOS memory-manager structures.

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

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

Usage is implied by the purpose — an agent would infer it should call this when it needs a map of conventional memory ownership rather than raw contents. However, there is no explicit when-to-use statement, no contrast with mem_read/mem_search, and no note about when the MCB walk is valid (e.g. only meaningful inside DOS). Adequate but with a clear 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?

With only readOnlyHint=false available, the description does real work by disclosing that omitting the address destroys ALL freezes — an agent needs that scope warning to avoid accidental mass mutation. It still omits reversibility, permissions, and any indication of what a successful clear returns.

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

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

One compact sentence pair with zero filler; the core action leads and the branching behavior follows immediately. Every clause earns its place.

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

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

For a single-optional-parameter mutation with no output schema, the description covers the action and both branches completely. Only the destructive-scope caveat could be expanded (e.g., that the clear-all is irreversible), which keeps it short of a 5.

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

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

Schema coverage is 100% and the single parameter's own description already says "Omit to clear all." The description restates this rather than adding format, type, or range detail beyond the schema, so the baseline of 3 applies.

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

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

"Remove a freeze" states a specific verb and resource, and the paired parameter guidance makes the operation unambiguous. It never names freeze_set or freeze_list, so the agent distinguishes it from siblings only via the tool name rather than explicit description text.

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 clearly explains the two operating modes (targeted removal vs. clearing everything), which implies when to pick each. It offers no guidance on when this tool is preferred over related tools such as freeze_list, and no prerequisites 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=true, so the safety profile is covered. The description adds the useful scope qualifier that only active freezes are returned, but it does not describe pagination, ordering, or return shape, leaving some behavioral context unstated.

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

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

A single short sentence that is front-loaded with the verb and resource. Every word earns its place and there is no unnecessary 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 simple read-only, parameterless listing tool, the description is nearly sufficient. It could mention the return format or ordering, but the complexity is low and the essential scope is covered.

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

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

The tool has zero parameters, and the schema is empty, so there are no parameter semantics to document. The baseline for a parameterless tool is 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 gives a specific verb (List) and resource (active memory freezes), clearly distinguishing it from siblings such as freeze_set and freeze_clear. An agent can immediately tell this is the read-only listing operation for the freeze subsystem.

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 states what the tool returns but provides no explicit guidance on when to use it versus alternatives like freeze_set or freeze_clear. It implies usage by naming 'active' freezes, but does not state conditions or exclusions.

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

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

Annotations only declare readOnlyHint=false, so the agent knows this writes. The description adds genuinely useful behavior beyond that: the value is continuously re-written every frame (persistent lock semantics), and the write is little-endian. It stops short of covering failure modes (invalid address, already-frozen addresses) or how the lock is released.

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, zero filler, core action and persistence behavior front-loaded before the width/endianness detail. Nothing redundant with structured fields except the width restatement.

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 only readOnlyHint=false, no output schema, and full schema coverage, this covers the essential mechanics (persistence, width, endianness). It leaves a small gap on lifecycle (how to unfreeze) and error behavior, which is minor given the presence of freeze_clear/freeze_list siblings.

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; the description earns above-baseline by adding little-endian byte order, which the schema does not state and which determines how `value` maps to memory bytes. The width restatement (1/2/4 bytes) duplicates the schema but is harmless.

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 ("Lock a memory address to a value") and the persistence model ("rewritten every frame, trainer-style"), which implicitly separates it from the one-shot mem_write sibling. It does not explicitly name freeze_clear/freeze_list, so differentiation is inferential rather than stated.

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

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

"trainer-style" and "rewritten every frame" imply when this tool is appropriate versus a single mem_write, but the description never states when-not to use it, that freeze_clear releases the lock, or how it relates to mem_write/mem_read. Usage is implied rather than guided.

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 only declare readOnlyHint=false, so the description correctly implies a state-changing input action via 'press or release'. It does not disclose failure behavior (e.g., invalid key name), whether a press must be balanced by a release, or any timing/hold semantics.

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 action and followed by the disambiguation rule. Nothing 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 simple 2-parameter, no-output-schema input tool, the description covers purpose, key format, and the sibling that it supersedes. Only edge-case behavior (invalid names, release without press) is unaddressed.

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

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

Schema coverage is 100% with only 2 parameters, so the schema already documents both 'key' and 'pressed'. The description reinforces the KBD_* name format and the press/release intent but adds no format or constraint detail 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?

Specific verb (press/release) plus resource (a single key) with the KBD_* naming convention stated, which cleanly distinguishes it from the sibling input_type and input_sequence 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?

Explicitly names the alternative (input_type) and the condition that selects this tool ('special keys ... that input_type cannot produce'). It doesn't cover when to prefer input_sequence for multi-key chains, 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 only declare readOnlyHint=false, so the description carries the behavioral load and does so richly: relative-only mouse movement, the corner-sweep workaround to pin the cursor, and the press/release decomposition of a click. It also states that unknown fields are rejected with a helpful error, which the 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?

Front-loaded with the core action, then progressively details the non-obvious relative-positioning constraint, the workaround, click composition, and error behavior. Every sentence earns its place 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?

For a complex input tool with no output schema, the description covers the operationally critical quirks an agent would otherwise get wrong (relative movement, click decomposition). It omits timing-model guidance beyond the schema's own t/delay_ms descriptions, but the schema handles 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 baseline is 3, but the description adds genuine meaning beyond the schema by explaining the relative coordinate semantics and the corner-pinning technique for reaching absolute positions, which the schema's x_rel/y_rel descriptions do not cover.

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 ('inject') and resource ('timed sequence of key, mouse, and wheel events'), and the phrase 'complex input patterns or recorded replays' sets it apart from the single-event siblings input_type and input_key.

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?

'For complex input patterns or recorded replays' clearly signals the context in which this tool is preferred over simpler input tools, but it never names the alternatives (input_key/input_type) or states an explicit exclusion, leaving the routing slightly implicit.

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 annotations only declare readOnlyHint=false, so the description carries real weight and does add genuine behavioral detail: pacing to avoid the 8-slot i8042 buffer overflowing, and a supported-character restriction (printable ASCII, common symbols, US layout). It stops short of saying what happens on unsupported characters, whether it blocks until completion, or what the call returns.

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 action, followed by the mechanism and the input constraint. No filler or restatement of the tool name.

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

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

For a two-parameter input tool with no output schema and minimal annotations, the description is nearly sufficient: what it types, how it paces, and what characters are valid. It omits only operational context such as which session receives the input and any failure behavior, which are minor gaps.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: the US-layout printable-ASCII constraint on 'text' and the rationale for 'cps' (pacing to protect the keyboard buffer). That is useful semantic enrichment over the raw 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?

States a specific verb and target: 'Type a string on the DOS keyboard,' which is clearly a text-injection action rather than a read or query. It does not, however, differentiate itself from the sibling tools input_key (single key) and input_sequence, so an agent must infer the boundary between typing a string versus pressing keys.

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

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

Usage is implied by the verb (type literal text into DOS), but there is no explicit when-to-use statement or routing against input_key or input_sequence, which are the obvious alternatives for keyboard input. No prerequisites or session/focus requirements are mentioned.

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

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

The readOnlyHint annotation already establishes the safety profile, so the description's real contribution is disclosing the return payload: base64 data plus current CPU register state. That return-shape disclosure is genuinely useful and not derivable from the schema, though nothing is said about the 64KB cap or error behavior on invalid offsets.

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, no filler, and the core action is front-loaded ahead of the return-value detail. Every clause carries information.

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

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

With no output schema, the description usefully specifies the return contents, and it covers the essential mechanics of a two-parameter read. It is nearly complete, missing only execution-context preconditions that a memory-read tool would ideally state.

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

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

Schema coverage is 100%, with both offset and length documented in the schema itself, so the baseline of 3 applies. The description adds no syntax, alignment, or address-space clarification beyond what the schema already states.

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 (read) and resource (guest physical memory), which cleanly separates it from the sibling mem_write and mem_search tools. It stops short of explicitly naming those siblings, but an agent can identify the operation unambiguously from the verb+resource alone.

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 no when-to-use guidance, no prerequisites (e.g., must the guest be paused?), and no routing to alternatives like mem_search for locating values or dos_memory_map for address translation. The agent must infer all context from the tool name.

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

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

readOnlyHint=true already tells the agent this is a safe, non-mutating read. The description usefully adds the little-endian interpretation and the return type (physical addresses), which goes slightly beyond the annotations, but says nothing about cost, result limits, or behavior on a very large range.

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, front-loaded sentences with zero filler; the core action is stated first, followed by return value and the width/endianness qualifier.

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

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

For a read-only scan tool there is no output schema, and the description does state the return shape (matching physical addresses). Only minor gaps remain, such as how matches are ordered or whether the range size is bounded.

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

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

Schema coverage is 100%, so all four parameters (start, end, value, width) are already documented in the schema. The description restates width values and adds endianness, but contributes little the schema does not already carry. 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 ('Scan') and resource ('guest memory'), plus what it returns ('matching physical addresses'). It is distinguishable from mem_read/mem_write, though it never names those siblings explicitly to sharpen 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 by the description (searching memory for a value), but there is no explicit statement of when to pick this over mem_read, mem_write, or dos_memory_map. No prerequisites or exclusion conditions are given.

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

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

readOnlyHint=false already tells the agent this is a mutation, and the description correctly reinforces that it targets guest physical memory. However, for a memory-write tool it discloses no behavioral risk: no indication that bad offsets can corrupt or hang the guest, no bounds/alignment constraints, and no return or error behavior. With no output schema, the burden is higher than a 3.

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

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

One short sentence with the verb and target front-loaded, zero filler. Appropriately sized for a two-parameter tool.

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

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

For a mutating tool with no output schema and no annotation detail beyond readOnlyHint=false, the description is too thin. It omits safety caveats, offset validity expectations, and behavioral outcomes an agent needs before writing to arbitrary physical memory.

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 parameters (base64 data, integer offset) are fully documented in the schema. The description adds no format, encoding, or alignment detail 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 specific verb (write) and resource (guest physical memory bytes), which is immediately distinguishable from mem_read/mem_search by the mutation verb. It stops short of any explicit sibling differentiation, relying on the name and verb to carry the distinction.

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

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

There is no guidance on when to use this tool versus alternatives, no preconditions, and no mention of the mem_read sibling. The agent must infer usage entirely from the name.

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

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

The readOnlyHint=false annotation aligns with the mutating verb 'Set', so there is no contradiction. The description adds the useful nuance that it is 'user volume' on a named channel, but it says nothing about persistence, clamping of out-of-range values, or whether the change is reversible.

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

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

A single front-loaded sentence with the verb first and the parenthetical examples doing useful work. Nothing is wasted or 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 simple three-parameter setter with no output schema, the description is adequate on the target channel but leaves the volume scale semantics (linear 0.0+, dB, or percent) and return behavior unstated. Annotations are minimal, so more behavioral detail would have helped.

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

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

Schema coverage is already 100%, so the baseline is 3, but the description's concrete channel-name examples (SB, GUS, CDAUDIO, SPKR) give enum-like guidance the generic 'Channel name' schema field lacks. The left/right parameters get no added meaning beyond the schema's '0.0+' ranges.

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

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

States a specific verb ('Set') and resource ('a mixer channel's user volume'), and the channel-name examples (SB, GUS, CDAUDIO, SPKR) make the target concrete. It does not explicitly distinguish itself from the sibling mixer_volume (likely master volume), so it stops short of a 5.

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

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

There is no when-to-use guidance and no mention of the alternatives (mixer_volume, mixer_mute, mixer_unmute, mixer_status). The agent must infer that this is the per-channel variant rather than the master-volume 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?

readOnlyHint=false already signals a state-changing operation, and 'Mute...output' is consistent with that. The description usefully scopes the effect to the master output, but does not disclose whether the mute is a durable state change, whether it toggles, or what observable effect it has on playback.

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

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

A single front-loaded sentence with no wasted words; the scope ('master') is stated immediately.

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

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

For a no-parameter, no-output-schema toggle with annotations covering the write nature, this is nearly sufficient. The only meaningful omission is the relationship to mixer_unmute (is this a toggle or an absolute set), which would remove the last ambiguity.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify beyond the schema; the baseline for a 0-param tool 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 (Mute) and resource (the master mixer output), and the qualifier 'master' distinguishes it from the per-channel sibling mixer_channel_volume. It does not explicitly name the sibling it is not, so it falls short of a 5.

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

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

The description gives no when-to-use guidance and never mentions mixer_unmute as the reversing alternative or any precondition. The agent must infer usage from the name alone.

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

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

readOnlyHint=true already covers the safety profile, so the description only needs to add context, and it does: it discloses exactly what state is reported (master level, mute flag, all channels with volumes and rates). It stops short of stating whether state is live/cached or how frequently it should be polled.

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

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

A single front-loaded sentence with the resource first and the enumerated contents after the colon. No filler, no 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?

With no output schema, the description carries the burden of explaining what comes back, and it does so by listing master volume, mute, and all channels with volumes and sample rates. It is complete enough to call correctly; only freshness/timing semantics are absent.

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

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

The tool takes zero parameters, so the baseline is 4. The empty schema leaves nothing ambiguous, and the description correctly implies no filtering arguments are available.

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

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

States a specific verb (Get) and resource (mixer state) and enumerates the returned fields: master volume, mute, per-channel volumes and sample rates. It is distinguishable from mutating siblings like mixer_volume and mixer_mute by the 'Get' framing, though it never names them.

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

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

Usage is implied by the read-only verb, but there is no explicit guidance on when to call this versus mixer_volume, mixer_mute, or mixer_channel_volume, nor any note about calling it before/after mutations. Adequate but leaves routing to inference.

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

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

The readOnlyHint=false annotation already signals a mutating operation, consistent with the description. The description adds the useful scope detail that only the master output is affected (not per-channel), but says nothing about idempotency or behavior when already unmuted.

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

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

A single front-loaded sentence with no wasted words; the action and its target are stated immediately.

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

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

For a zero-parameter, no-output-schema toggle, the description is sufficient to invoke correctly. Minor gap: it does not note what happens on an already-unmuted mixer, but that is unlikely to block a correct call.

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

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

Zero parameters, so the baseline is 4. The phrase 'master mixer output' reinforces that no channel argument exists, confirming scope rather than contradicting the empty 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 (unmute) and resource (master mixer output), which cleanly distinguishes it from the sibling mixer_mute and from mixer_channel_volume. It does not name the alternative explicitly, but the inversion is unambiguous.

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

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

Usage is only implied: an agent infers this is the inverse of mixer_mute and applies it when the master output is muted. No explicit when-to-use, prerequisites, 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 declare only readOnlyHint=false, so the description carries the behavioural burden. 'Set' confirms a mutation, but nothing is said about scale/units beyond the schema, whether the value persists, whether muting overrides it, or how it relates to mixer_channel_volume. It adds essentially no context beyond the annotation.

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

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

A single short sentence with no filler, and the operation is front-loaded. Its brevity is genuine conciseness rather than padding, though it is arguably terse to the point of leaving questions unanswered.

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

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

For a two-parameter setter with 100% schema coverage, no output schema and no nested objects, the description is minimally sufficient. The main gaps are the value range/units and the interplay with mute and per-channel volume, which an agent would likely need.

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%: both left and right are documented with type and a '(0.0+)' lower-bound note. The description adds nothing about maximum range, channel independence, or stereo linkage, so the baseline 3 for a fully-covered schema 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?

Specific verb (Set) plus resource (master mixer volume), and the word 'master' implicitly scopes it against the sibling mixer_channel_volume. However, the sibling is never named, so an agent must infer the master-vs-channel distinction rather than being told it.

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

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

No when-to-use guidance and no alternatives named, despite obvious siblings (mixer_channel_volume, mixer_mute, mixer_unmute, mixer_status) that an agent must choose between. Only implicit usage is conveyed by the phrase 'master ... volume'.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered by structured data. The description adds nothing beyond that about side effects (some I/O port reads can clear status or have hardware effects) or what value is returned, and there is no output schema to compensate.

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, front-loaded sentences with no filler; the core operation comes first and supplementary detail follows.

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

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

For a two-parameter read tool this is close, but with no output schema the description should say what is returned (the read value, its type/width relationship). That return-value gap keeps it at minimum-viable.

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 'port' address range and 'width' semantics are fully documented in the schema. The description's width explanation ('1 (byte) or 2 (word)') merely repeats the schema, adding no new 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 ('Read') and resource ('x86 I/O port'), which cleanly contrasts with the sibling port_write. However, it never names the alternative or any other sibling, so differentiation is left implicit rather than stated.

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

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

Gives concrete when-to-use context ('VGA registers, sound cards, HGC control ports'), which tells an agent the domain the tool applies to. It stops short of exclusions or warnings about when reading a port is risky or inappropriate.

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 annotations only declare readOnlyHint=false, and the description confirms this is a write. Beyond that, it does not disclose safety implications, unsupported ports, error behavior, reversibility, or side effects. For a low-level hardware write operation, this leaves important behavioral context missing.

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-load the core action, then specify width and use cases. There is no filler, and the structure lets an agent quickly identify purpose and applicability.

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 annotations are sparse, so the description carries most of the contextual burden. Given the risk and complexity of hardware I/O writes, it should include cautions, expected effects, or failure behavior, but it does not.

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 port range, value, and width semantics. The description repeats the width meaning but does not add format, constraint, or edge-case details beyond the schema, making the baseline 3 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 gives a specific verb and resource: 'Write to an x86 I/O port.' This clearly distinguishes the tool from the sibling port_read and from memory-writing tools such as mem_write. Width and concrete hardware use cases add further specificity.

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 names concrete contexts for use ('Mode X unchaining, Hercules graphics, hardware config'), which implies when the tool is appropriate. However, it does not say when not to use it, nor does it point to alternatives like port_read or mem_write for related operations.

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

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

Annotations already declare readOnlyHint=true, so the safe read-only nature is covered. The description adds the output format (PNG), which is useful behavioral context, but it does not say whether the image is returned inline or written to a file, nor anything about size limits or timing of the capture.

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 action and output format. Every clause earns its place; nothing is padded.

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

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

For a no-argument, read-only snapshot tool with annotations covering safety, the description is nearly sufficient. The only meaningful gap is how the resulting PNG is delivered (returned vs. saved), which the absent output schema leaves unaddressed.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter explanation is needed.

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 ('Capture'), resource ('current screen'), and output format ('PNG image') in one sentence. This is enough to distinguish it from siblings like screen_text (text extraction) and video_capture_start (video recording) 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?

'Works in all video modes' removes a compatibility caveat an agent would otherwise have to check, which is implied usage guidance. However, it never says when to prefer this over siblings such as screen_text or screen_info, so the routing 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?

readOnlyHint=true already establishes this is a safe read, and with zero parameters there is little risk behavior to disclose. The description adds the returned fields, which is useful since no output schema exists, but it omits any cost, caching, or freshness caveats for a live frame query.

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

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

A single compact fragment with the subject and payload front-loaded and no filler. Very terse, but nothing is wasted.

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

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

With no output schema, the description must carry the return-value burden, and it names three concrete fields. It is adequate for a trivial no-arg read, though it may not be exhaustive if more frame fields exist.

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 no parameters, so there is nothing to disambiguate; the baseline for zero-param tools applies. The description's enumeration of returned fields is a mild bonus but not parameter guidance.

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 resource (frame metadata) and enumerates the payload (resolution, pixel format, palette status). It is distinguishable from siblings like screen_text and screen_capture by implication, but it never names them to make the distinction explicit.

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

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

No when-to-use context is given. It does not say whether this should be called before screen_capture, or how it relates to screen_text/session_info, leaving the agent to infer the 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 readOnlyHint=true, so the safety profile is covered. The description adds genuine value beyond that by disclosing the return type (string) and, more importantly, the failure condition (text modes only), which the agent needs to avoid a bad call. It does not describe truncation, buffer dimensions, or error behavior.

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

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

Two short sentences, zero filler, with the core action front-loaded and the constraint immediately after. Every clause earns its place.

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

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

For a zero-parameter read tool with annotations covering safety and no output schema, the description is nearly sufficient: it states what is read, the format returned, and the mode restriction. The remaining gap is that it does not point the agent to the graphics-mode alternative when the precondition fails.

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 and schema coverage is 100%, so there is nothing for the description to disambiguate. Baseline 4 applies for a no-argument tool.

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

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

States a specific verb and resource ('Read the DOS text-mode screen buffer') plus the return format ('as a string'), which is enough to tell it apart from screen_capture and screen_info in spirit. It stops short of naming those siblings explicitly, so the differentiation is inferential rather than stated.

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

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

The clause 'Works only in text modes (CGA/EGA/VGA/Hercules text)' is a real precondition that tells the agent when this tool applies. However, it never says what to use instead in graphics modes (screen_capture is the obvious alternative) and gives no exclusions or routing advice.

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 only declare readOnlyHint=false, and the description adds that execution is sandboxed and runs on the emulation thread — useful context beyond the annotation. It does not disclose lifecycle behavior (whether the script keeps running until script_stop, blocking or async execution, or error handling), which matters for an arbitrary-code-execution tool.

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

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

Three short sentences, front-loaded with the action, each contributing distinct information (what it does, how it runs, when to use it). No redundancy.

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

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

For a tool that executes arbitrary code in a sandboxed emulator, the description omits lifecycle and error semantics despite sibling tools (script_status, script_stop) implying asynchronous execution. With no output schema and only an annotation flag, more behavioral detail would be warranted.

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

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

Schema coverage is 100% with a single 'script' parameter documented as 'Lua source code to execute.' The description adds no syntax, size, or format constraints beyond that, 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?

The description states a specific verb and resource — 'Load and start a Lua script' — which is unambiguous and clearly distinct from script_status and script_stop. It does not explicitly name those siblings as the way to check or halt the script, so it falls short of the top score.

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 third sentence gives a clear use condition: reach for a Lua script when a DOS automation capability has no dedicated tool. There is no explicit statement of when NOT to use it (e.g., prefer the dedicated tool when one exists), but the routing intent 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 readOnlyHint=true, so the safety profile is covered. The description adds genuinely useful context beyond that (scripts communicate via dosbox.output['key'] = value), but says nothing about behavior when no script is running, whether state polling is synchronous, or how output is reset between runs.

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 action and followed by the one piece of context an agent cannot infer. 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?

With no input schema and no output schema, the description carries the load and does explain the result channel via dosbox.output. It stops short of describing the shape of the state value or the output table's contents, but for a simple read-only status probe it is close to complete.

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

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

The tool takes zero parameters, so the schema has nothing to document and the description cannot add parameter meaning. Baseline of 4 applies for a parameterless tool.

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

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

States specific verbs and resource: check the state of the 'running script' and read its 'output table'. This separates it cleanly from script_run and script_stop, though it does not name those siblings explicitly.

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

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

Usage is implied rather than stated: the mention of reading the output table hints at when an agent would call it (to harvest results), but there is no explicit when-to-use vs. script_run/script_stop guidance, no prerequisites, and no 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?

The readOnlyHint=false annotation already signals this is a mutating call, and the description only restates that with 'Stop'. It discloses nothing beyond the annotation: not whether termination is graceful or forced, what happens if no script is running, whether it blocks, or whether the stopped script can be resumed.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though so terse that nothing beyond the minimum is conveyed.

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 mutation with no output schema, the definition is serviceable but thin — an agent gets no indication of error behavior when no script is active or what state the session is left in after the call.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No argument semantics are needed here.

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

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

States a specific verb (Stop) and resource (a running Lua script), which is enough to tell it apart from script_run and script_status by inference. It stops short of explicitly naming those siblings or scoping when a stop is appropriate.

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

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

Usage is implied by the verb and the sibling set (script_run / script_status), but there is no explicit when-to-use, no statement of preconditions (must a script be running?), and no routing away from alternatives.

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 readOnlyHint=true already declaring safety, the description adds valuable security context beyond the annotation: the token value is never returned, stays out of transcripts by design, and the curl example reads the token from its file. This tells the agent exactly how credentials are handled.

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

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

Three tight sentences: first states what the tool provides, second states when to use it, third gives a critical security caveat. Front-loaded and 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?

With no output schema, the description fully covers the return contents (base URL, token location, curl example) and the key operational constraint (token never returned). 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?

The tool takes zero parameters, so per the baseline rule this scores 4. The description appropriately does not discuss arguments, and there is nothing for it to clarify beyond the empty schema.

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

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

The description specifies exactly what the tool returns—connection details for the REST API, including base URL, token location, and a curl example—and distinguishes it from sibling MCP tools by positioning it as the escape hatch for endpoints the MCP tools don't wrap.

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 an explicit condition for use: 'Use this when you need an endpoint the MCP tools don't wrap, such as saving a video frame to a file.' The default alternative (MCP tools) is implied, and the example makes the boundary concrete.

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?

readOnlyHint=false already tells the agent this is not a passive read. The description adds meaningful context beyond that: the recording codec (ZMBV) and the captured surface (emulator screen). It omits the side effects an agent would want — output file location, whether an existing recording is overwritten, and whether a stop call is required.

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

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

A single front-loaded sentence with no filler; the action, codec, and target are all stated immediately.

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

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

For a zero-parameter action the invocation bar is low, and the format/target detail is helpful. However, with no output schema and no description of the return value, the agent cannot tell whether this yields a file path, a status object, or nothing.

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 schema carries no semantics to document and the baseline of 4 applies. Nothing in the description is needed or missing on this dimension.

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

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

The description gives a specific verb+resource ("Start ZMBV video recording of the emulator screen"), making it immediately distinguishable from video_capture_stop and video_capture_status in the sibling list. It stops short of explicitly naming the counterpart tools, so it earns a 4 rather than a 5.

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

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

Usage is implied by the name and description — start recording versus the sibling stop/status tools — but there is no explicit when-to-use guidance, no prerequisite (e.g. emulator must be running), and no statement of what happens if a recording is already in progress.

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?

readOnlyHint=true already tells the agent this is a safe, non-mutating read. The description adds only the semantic subject of the check (capture in progress), with no detail on return shape, latency, or whether it reflects a queued vs. active capture. With annotations carrying the safety profile, this is acceptable but thin.

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

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

A single, front-loaded sentence with no filler. Every word carries meaning and the purpose is stated immediately.

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

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

For a parameterless, read-only status probe with no output schema, the description is sufficient to call the tool correctly. The only mild gap is that it never states the return form (boolean vs. state string), though 'whether' strongly implies a boolean.

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 baseline this lands at 4. The description correctly implies no inputs are needed, and there is nothing further for it to document.

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

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

States a specific verb and resource ('Check whether a video capture is in progress'), so an agent knows exactly what this tool answers. It does not explicitly differentiate itself from the video_capture_start / video_capture_stop siblings, but the noun phrase makes the distinction obvious enough.

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

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

Usage is implied by the purpose — you call it to determine capture state, presumably before starting or stopping capture. There is no explicit when-to-use statement, no mention of the start/stop siblings, and no prerequisites or exclusions.

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

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

The only annotation is readOnlyHint=false, which merely confirms it mutates state. The description adds no behavioral context such as what happens to the captured file, where it is written, whether finalization is immediate, or how a 'nothing is recording' condition is reported. 'ZMBV' names the codec but is not 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?

A single front-loaded sentence with no filler; the action and target are stated immediately and nothing is wasted.

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

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

For a zero-parameter, no-output-schema tool the definition is close to sufficient, but it omits the one thing an agent would want after stopping: whether the recording is saved and where the resulting file can be found, which the video_capture_status sibling presumably reports.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond what the empty schema already shows. Baseline 4 for a no-parameter tool.

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

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

The description gives a specific verb ('Stop') and a specific resource ('ZMBV video recording'), making the action unambiguous. It implicitly separates itself from video_capture_start and the audio_capture_* family via the 'ZMBV video' qualifier, though it never names those 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?

Usage is only implied: an agent can infer this is called to end an in-progress recording. There is no statement of prerequisites (a recording must be active), no mention of video_capture_start/video_capture_status as related calls, and no guidance on sequencing.

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