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

Annotations declare destructiveHint=true and readOnlyHint=false, and the description adds genuinely new behavioral context: the prerequisite enablement state, the mcpb_event_allowlist constraint on trigger_event, and the in-band poll-queue result mechanism. It doesn't flag which specific ops are the destructive ones (teleport/freeze/send_nui), leaving some ambiguity for a destructive-annotated tool.

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

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

Front-loads the core purpose, then the target/op matrix, then the prerequisite — a sensible order with no filler sentences. It is dense and cramped into long clauses, but every clause carries information an agent needs.

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

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

An output schema exists, so return values need not be described, and the description still explains how client results arrive (poll queue, no FIVEM_SERVER_LOG). Combined with target/op routing, src requirement, timeout default and prerequisites, an agent has everything needed 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?

Schema coverage is 100%, so baseline is 3, but the description goes well beyond the schema by decomposing the opaque 'args' JSON string into per-op shapes ({resource, method, args}, {event, args, toClient?, player?}, teleport {x,y,z,heading?}, send_nui {resource, message, event?}). That is real added meaning the schema cannot convey; it only falls short of 5 because a few op argument sets are listed without field 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 concrete verb and resource ('Runs an operation through the mcpb bridge resource') and immediately differentiates itself from sibling command tools by naming the boundary ('the half neither devcon nor RCON can reach'). The op inventory further pins down exactly what the tool does.

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

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

Provides clear context for selection: server ops vs client ops, the rule that client ops 'needs src', and the prerequisite that the bridge must be installed, started and enabled. It stops short of explicitly naming when to prefer a sibling (e.g., server_command/client_command) over this tool.

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

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

Annotations already declare this is a non-readonly, non-destructive, non-idempotent action, so the safety profile is covered. The description's one useful addition is that the click occurs at the existing cursor position rather than at a supplied coordinate. It does not disclose latency, focus requirements, or how the click interacts with the target window.

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 sentence, action first, prerequisite in the parenthetical. Every clause carries information and there is 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?

The prerequisite is covered and annotations carry the safety profile, with no output schema needed for a fire-and-forget input action. Gaps remain around what 'double' does and whether the click targets the focused window, which an agent needs for correct invocation.

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

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

Schema description coverage is only 50%: 'button' has an enum and default, but 'double' is a bare boolean with no explanation anywhere. The description mentions neither parameter, so it adds nothing to compensate for the undocumented half.

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

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

States a specific verb (click) and the target (current cursor position), which clearly separates it from mouse_move, the sibling it explicitly names. The scope is unambiguous, though nothing states that this is a synthetic input event rather than a UI query.

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

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

Gives an explicit prerequisite: position with 'mouse_move absolute' first, and flags the NUI case where this matters. It stops short of saying when not to use click (e.g. vs. press_key or hold_key), so it is clear context without exclusions.

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

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

Annotations already declare destructiveHint=true, non-idempotent and non-readOnly, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: it runs over devcon with no screen focus and nothing typed into the game window, and it waits until output goes quiet before returning printed lines. It stops short of detailing the concrete destructive effect or auth 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?

The core action is front-loaded in the first sentence, and the behavioral and differentiation details follow in an ordered way. The chat-vs-console parenthetical is long but earns its place by preventing a common mis-selection; slightly verbose overall.

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

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

With no output schema, the description correctly discloses the return value (the lines the client console printed) and the waiting behavior, and it fully covers the guidance needed to invoke it correctly. The main gap is concrete detail on the destructive consequences implied by destructiveHint=true.

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

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

Schema description coverage is 100%, so command, timeoutMs and waitForOutput are already documented in the schema; baseline 3 applies. The description adds only the general note that no screen focus is needed, not parameter-level syntax or format detail.

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

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

States a specific verb and resource: type a LOCAL F8 console command into the running client over devcon, explicitly scoped to the process console context, not chat. It clearly separates itself from the chat command layer and names sibling server_command as the alternative.

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 states when to use this (process console commands like connect, quit, tooling) and when not to (commands registered with RegisterCommand are chat commands), and routes the agent to the correct alternatives (server_command or M2 input tools). Nothing is left to inference.

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

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

Annotations already flag it as a non-read-only, non-idempotent mutation of window state, so the bar is lower; the description adds genuinely useful behavior beyond that by disclosing the foreground steal, the automatic restore/minimize-out step, and that the prior window is remembered for restore_focus. It does not say what happens if the game is not running or if the steal fails.

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 core action and followed by the practical routing note. Every clause earns its place; nothing is redundant with the title or schema.

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

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

For a zero-param, no-output-schema tool this covers the essential behavior and the relationship to restore_focus and the input/screenshot family. Minor gaps remain around failure modes (game not launched, no window to focus), but nothing an agent needs to call it correctly is missing.

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

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

The tool takes zero parameters and the schema is empty, so there is no parameter semantics to document; baseline 4 applies. The description correctly adds no spurious parameter discussion.

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 ('steals foreground') with concrete mechanics (restores/minimizes-out if needed), which cleanly separates it from siblings like restore_focus and window_status. The title reinforces rather than restates, and the parenthetical naming of restore_focus tells the agent how the two tools relate.

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?

'Every input/screenshot tool calls this automatically' is a strong routing signal telling the agent it usually does not need to invoke this manually, and it names restore_focus as the counterpart tool. It stops short of an explicit when/when-not rule (e.g. only call if window_status shows it is not foreground), so it is clear context rather than full exclusions.

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

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

Annotations already declare readOnly=false and idempotent=false, but the description adds real lifecycle behavior not in the schema: the key remains held until released, and held keys are auto-released if the process exits. That process-exit caveat is exactly the kind of context annotations can't convey.

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

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

Front-loads the critical semantics ('stays pressed until release_key') before the long key enumeration. The key list is lengthy but earns its place given 0% schema coverage; minor redundancy with 'arrows up down left right'.

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-parameter, no-output-schema tool this covers the essentials: hold semantics, the release counterpart, valid key names, and process-exit cleanup. Only gap is behavior on repeated calls with the same key, which is a minor omission.

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

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

Schema coverage is 0% for the single 'key' parameter, so the description carries the full burden — and it does, enumerating accepted key names (W/A/S/D, space, enter, esc, tab, modifiers, arrows, f1-f12, letters/digits). The 'letters/digits' bucket is vague on case/format, so it falls just short of fully specifying syntax.

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 action ('key stays pressed until release_key') and names the complementary tool, which cleanly distinguishes it from the sibling press_key (a momentary tap). An agent can tell immediately that this is the sustained-input tool.

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

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

Gives concrete usage context ('use for movement (W) and camera') and points to release_key as the terminating call. It stops short of an explicit when-not (e.g., 'for a single tap use press_key instead'), so the routing decision against the sibling is implied rather than spelled out.

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

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

Annotations already declare the safety profile (readOnlyHint=false, non-idempotent, non-destructive), so the description only needs to add what they cannot. It does so by disclosing the non-blocking return ('Returns immediately') and pointing at the status tools that reveal when the game is actually up — genuine behavioral context. It still omits what happens if a client is already running, which matters given idempotentHint=false.

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

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

Three compact sentences, front-loaded with the action and the optional variant before operational notes. The 'Default target is the configured game port' sentence largely duplicates the schema default, which is the only minor 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 one-optional-param mutation tool with no output schema and solid annotation coverage, the description supplies the key missing piece — that it is asynchronous and how to observe readiness. The only gap is the undefined behavior when the game is already launched.

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 beyond the schema by tying connectTo to the 'fivem://connect link' concept and restating the default target. That is a modest but real semantic addition over the structured field.

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

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

The description names a specific verb and resource ('Launch FiveM'), plus the optional scope (straight into a server via the fivem://connect link). No sibling tool launches the client, so the purpose is unambiguously separable from quit_game, window_status, and client_command.

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

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

It gives clear context for use and routes the agent to the right follow-up tools ('watch window_status/client_command to see when the game is up'), which is exactly the sequencing an agent needs. There is no explicit when-not guidance (e.g. re-launching while already running), but no real alternative tool exists, so 4 is appropriate.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds the data-source mechanism (handshake streams CVAR frames), which is useful context, but says nothing about volume, rate limits, or auth. With annotations carrying the safety burden, a 3 fits.

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 what gets returned, then the routing alternative, then the filtering behavior. No filler, and each sentence carries information. Slightly dense with domain jargon.

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?

An output schema exists, so return values need no explanation. For a read-only listing tool, the description covers the source, the sibling alternative, and the filter behavior. It is complete enough for correct invocation without being exhaustive.

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

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

Schema description coverage is 0%, so the description must compensate. It does: 'Filter with a case-insensitive substring' explains the semantics of the 'contains' param, including case-insensitivity, which the bare schema does not convey.

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

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

The description states the tool streams every command the client console knows, with the parenthetical '(CVAR frames)' clarifying the return. It distinguishes the client console from server commands and routes the latter to server_command, but the core action is conveyed through jargon ('devcon handshake') rather than a clean verb+resource statement.

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 an explicit alternative and the condition for using it: 'For server commands, run help through server_command instead.' That is a clear routing rule. It does not, however, address the other nearby siblings like client_command or read_console, so guidance is present but not exhaustive.

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 readOnly=false, idempotent=false, destructive=false, openWorld=false, which together mark this as a non-idempotent state-changing input action. The description adds the meaningful behavioral distinction that the same tool drives two different targets depending on which params are used. It does not say whether movement is instantaneous, how repeated calls accumulate, or what happens with no parameters (0 required), leaving gaps 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?

A single dense sentence with zero filler; the relative-mode semantics are front-loaded and the absolute-mode behavior follows. Every clause earns its place, and no words are wasted on restating the name or title.

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 four-parameter, zero-required tool with no output schema and thin annotations, the description covers the core mode semantics but leaves the agent without guidance on precedence between x/y and dx/dy, units, or the effect of calling with no parameters. Adequate but not complete.

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

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

Schema coverage is 0% and none of the four integer parameters carry descriptions, so the description carries the full semantic burden—and it does so well by mapping dx/dy to relative camera movement and x/y to absolute screen pixels. It omits units for dx/dy (degrees vs pixels), accepted defaults, and precedence when both pairs are provided.

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

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

The description states a concrete verb and resource (mouse movement) and splits it into two distinct modes: relative dx/dy for the in-game camera and absolute x/y for NUI cursors. That dual-mode semantics is more than the title 'Move the mouse' conveys. It stops short of naming which siblings (click, scroll) it should be paired with, 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?

It implies when each mode applies—relative for camera control, absolute for NUI elements—which is genuine routing guidance for two of the four parameters. However, it never states when to choose this tool over click/scroll or how the two modes interact if both are supplied, so usage is implied rather than spelled out.

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

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

Annotations already declare non-readOnly, non-destructive, non-idempotent behavior. The description adds genuine context by explaining these are scan codes read by DirectInput/raw input, which justifies why it targets games, but it says nothing about timing, default hold behavior, or focus 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?

Front-loads the action, then the technical rationale, then the accepted values. Slightly list-heavy but every element earns its place; 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 two-parameter input tool with no output schema, the description covers what it does, why scan codes matter, and valid inputs. It omits focus/window prerequisites and the holdMs default, though the latter is in the schema.

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

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

Schema coverage is only 50%, and the undocumented 'key' parameter is the required one; the description compensates by enumerating accepted key names (letters, digits, f1-f12, named keys). holdMs is covered by the schema, so the remaining gap is minor.

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 ('press and release a key') and the 'press and release' framing implicitly distinguishes it from the sibling tools hold_key and release_key. It stops short of naming those siblings explicitly, so differentiation requires inference.

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 tap semantics contrast with hold_key/release_key, but the description never states when to choose this over them or any prerequisites. The key-name list helps invocation but not tool selection.

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 say destructiveHint=true; the description adds how each path works — the graceful path prints 'quit' over devcon and waits for closure without typing into the window, while force kills the process tree. This mechanism-level detail goes well beyond the structured hints.

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

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

Two dense sentences, graceful path front-loaded before the force branch. Every clause earns its place with 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 one-param, no-output-schema tool, the description covers the critical decision (graceful vs. force) and the mechanics. It omits edge cases such as what happens if the graceful path times out or fails, which would matter for an agent deciding whether to escalate to force.

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

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

Schema coverage is 0% and the single 'force' parameter has no schema description, so the description carries the burden — and it does, explaining that force:true kills the process tree and that the default is a graceful quit. Full parameter meaning is conveyed, though without naming acceptable values beyond boolean semantics.

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

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

States a specific verb+resource ('quits the FiveM client') and immediately distinguishes the two shutdown paths (graceful console quit vs. force kill). No sibling tool does this, and the description makes that clear 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?

Explicitly states when to use the force path ('only when the game is wedged') and implies the default graceful path otherwise. This is actionable when/when-not guidance rather than mere context.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description adds real behavioral detail on top — it auto-selects the newest log file and returns lines without channel tags, unlike read_console. It does not describe how the pattern/contains filters affect the stream, which keeps it from 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?

A single front-loaded sentence naming the action, the target file, and the sibling contrast. Every clause 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?

An output schema exists, so return values need no explanation, and the file-selection behavior is covered. However, with 0 required params and two undocumented filter params, an agent lacks enough to use the filtering capability correctly.

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

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

Schema coverage is only 33% and the description says nothing about any of the three parameters. Pattern (regex vs glob?) and contains (substring, case sensitivity?) are left entirely undocumented in both places, so the description fails to compensate for the coverage gap.

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

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

Specific verb (tail) plus resource (newest CitizenFX_log_*.log under the FiveM install) and an explicit contrast with the sibling read_console. An agent can pick between the two without opening either schema.

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

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

The clause 'the same stream as read_console(client) but persisted across sessions' tells the agent the condition that selects this tool over its sibling. It stops short of an explicit when-not rule, but the routing context 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 readOnly/idempotent/non-destructive, but the description adds genuinely useful behavior the annotations cannot convey: the client buffer starts at first server connection, server output is a filtered tail of the last 512 KB, and afterSeq paging only works on the client. These data-freshness and paging constraints are exactly the non-obvious traits an agent needs.

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

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

Two sentences, front-loaded with the core guarantee ('without running anything') before splitting into the two target cases. Dense but every clause (buffer origin, 512 KB tail, filtering, afterSeq support) carries behavioral weight rather than 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?

With an output schema present, return formatting needn't be explained, and all six params are schema-documented. The description covers the hard part — per-target data sources and paging limits — though it omits the client-vs-server routing relative to the read_client_log sibling.

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

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

Schema coverage is 100%, so the schema already documents all six parameters including the 'client only' note on afterSeq. The description reinforces which parameters apply to which target but adds little syntax or format detail beyond that; baseline 3 is appropriate.

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

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

States a specific verb+resource ('Return recent console lines') and then breaks the behavior down per 'client' and 'server' target, so an agent can tell exactly which backing buffer is read. It does not, however, distinguish itself from the sibling read_client_log, which plausibly overlaps, leaving target selection between the two to inference.

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?

'without running anything' implicitly contrasts this with the command-execution siblings (server_command, client_command), and the requirement of rcon_password for 'server' appears in the schema. But there is no explicit when-to-use/when-not guidance and no named alternative such as read_client_log or wait_for_console.

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=false and destructiveHint=false, so the mutation profile is covered structurally. The description usefully discloses the 'all' sentinel behavior, which the schema does not, but says nothing about what happens if the key is not currently held or about failure behavior.

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

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

A single sentence, zero filler, with the scope constraint ('all') front-loaded and easy to scan. 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 one-parameter mutation tool with annotations covering safety, the description is close to adequate but omits error/edge behavior (e.g. releasing a key that is not held) and does not hint at the result. Not deficient, but not 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?

Schema description coverage is 0% for the single 'key' parameter, so the description must carry the semantics. It does add a meaningful sentinel value (key='all') that the bare string schema lacks, but leaves the format for individual key names unspecified.

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 (release) and resource (held key) plus the 'all' scope, so the action is unambiguous. It does not explicitly contrast itself with the sibling hold_key/press_key, so sibling differentiation is left to inference.

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 'release one held key' implies this is the inverse of hold_key, and the key='all' note conveys a usage option. However, there is no explicit when-to-use or when-not-to-use guidance relative to the 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?

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the agent knows this mutates foreground state. The description adds the stateful dependency on a previously focused window, but does not say what happens if there was no prior window, if the prior window has closed, or whether the call reports success.

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 trailing clause 'before this tool focused the game' is slightly muddled since focus_window, not this tool, performs the focusing, but the meaning survives.

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 whose annotations carry the safety profile, the description covers the core contract adequately. The main omission is edge-case behavior when no previous window exists, which is minor 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?

Zero parameters and no schema properties, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly avoids inventing parameters.

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 (returns/restores) and the exact target (the window focused before the game was focused), which is a precise and unusual resource. This implicitly distinguishes it from the sibling focus_window, since the agent can tell this is the undo counterpart rather than a fresh focus request.

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 by the semantics — an agent infers this should be called after focus_window to return the user to their prior application. No explicit when-to-use, when-not-to-use, or named alternative (focus_window is not mentioned by 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?

Goes well beyond annotations: it discloses the capture mechanism (PrintWindow with PW_RENDERFULLCONTENT), the black-swapchain fallback to BitBlt (and that occluding windows are then captured), and — critically — that the game is focused first, which explains the readOnlyHint=false annotation. The transcript-cost warning (shots are re-sent every later turn, multiplying latency) is a behavioral trait no structured field conveys.

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?

Every sentence earns its place — mechanism, fallback, cost, alternatives, and parameter advice are all non-redundant. It is dense with parentheticals and the cost warning arguably belongs before the mechanism detail, but there is no filler or repetition.

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

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

With no output schema, the description still specifies the return format (PNG), the resize behavior, and the failure/fallback path, plus cost and alternative-tool context. Nothing an agent needs to invoke this correctly — or to decide against it — is missing.

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

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

Schema coverage is 100%, so baseline is 3; the description adds operational meaning by tying maxSide to cost ('keep maxSide small (640 suffices for layout checks)') and by advising crop to the panel of interest, which the schema's bare types don't imply. It doesn't restate ranges or defaults, but the added usage-level semantics lift it above baseline.

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

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

States a specific verb+resource (capture PNG of the FiveM window) and immediately names the mechanism and scope, distinguishing it from text-oriented siblings like read_console and wait_for_console. An agent can tell what this returns and how it differs from the surrounding tools 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?

Explicitly says to prefer text probes (read_console, wait_for_console, bridge ops) and names the condition that justifies this tool: 'when pixels are the evidence'. It further routes usage with 'keep maxSide small (640 suffices for layout checks) and crop to the panel of interest', which is actionable when-to-use guidance.

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

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the bar is lower. The description usefully adds the direction convention and that NUI lists are the responsive target, but says nothing about focus requirements, rate limits, or repeat 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 with the direction convention front-loaded and zero 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 simple one-parameter input tool with annotations covering safety and no output schema, the definition covers direction and target context adequately. Remaining gaps (focus/prerequisite conditions) are minor.

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

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

Schema coverage is 0% and the single 'amount' parameter only exposes a -50..50 range with no description. The description supplies the crucial missing semantics ('positive = up'), which is exactly what the schema omits, though it doesn't state units or step granularity.

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 ('Scroll') and resource ('the wheel'), and adds sign semantics ('positive = up'). It is distinguishable from siblings like mouse_move and click, though it doesn't explicitly contrast with 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?

The clause 'NUI lists respond to it' implies a usage context but gives no when-to-use vs alternatives guidance, no prerequisite such as needing an open NUI or focused window, 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?

Annotations declare destructive/non-readonly, and the description adds substantial context beyond them: the UDP RCON transport, the two required credentials (rcon_password on the server plus FIVEM_RCON_PASSWORD locally), and a server-side rate limit (~5 burst). These are exactly the operational facts an agent needs before firing a destructive command.

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, front-loaded with the verb and transport, then reply semantics, then prerequisites. No filler, though the parenthetical command examples could be trimmed.

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

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

No output schema exists, yet the description explains that the reply carries the command's captured console output, and it covers auth, transport, and rate limiting. Nothing essential for correct invocation is missing.

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

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

Schema coverage is 100% and the schema already documents the single command parameter, including the no-leading-slash rule. The description adds only the category examples of valid commands, 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 (Execute) and resource (command on the server console) and scopes it via the transport (UDP RCON) plus examples of what the console accepts. It clearly contrasts with the sibling client_command, which acts on the client rather than the server.

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

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

The description implies usage by enumerating command categories (ensure/stop/restart, convars, registered commands), but it never states when to prefer this over siblings like client_command, list_commands, or read_console. No explicit when-not 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?

Annotations already cover read-only/idempotent safety, so credit goes to what the description adds: it discloses that this uses an out-of-band endpoint and requires no rcon_password, which is genuinely useful auth context. It does not mention latency, rate limits, or failure behavior, keeping it below 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?

Two tightly written sentences with no filler. The returned fields are front-loaded and the usage/credential note follows immediately, so nothing is buried.

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

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

An output schema exists, so the description need not explain return formatting, and it still conveniently previews the fields. For a simple, no-arg, read-only probe, everything an agent needs to call it correctly 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 per the baseline this scores 4; the description correctly adds no parameter syntax that would be redundant. There is nothing more needed for a no-arg call.

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 action (query the server's getinfo out-of-band endpoint) and enumerates exactly what it returns: hostname, players online, max clients, protocol, game build. It also implicitly separates this credential-free identity probe from the rcon-based siblings like server_command and status.

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 a clear use case ('use it to confirm which server you are pointed at') and the key selection condition ('works without rcon_password'), which routes the agent here rather than to credential-requiring tools. It stops short of an explicit when-not or naming the alternative tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety and repeatability profile is fully covered by structured data. The description adds real value by enumerating the three subsystems whose connection state is reported, but it says nothing about failure/degraded states or what a disconnected result looks like.

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: the first enumerates scope, the second is the usage directive. Nothing is redundant and the scope statement is front-loaded.

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

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

With an output schema present, return values need not be explained, and the description gives the agent enough to know what is being checked and that it should run this first. It is a near-complete diagnostic preamble, missing only guidance on interpreting a failed connection.

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 description correctly introduces no parameter semantics to confuse the agent, and the schema is trivially complete.

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 a specific verb ("Report") and three concrete resources it inspects: RCON configuration, the devcon connection to the FiveM client console, and the server log-file tailer. That is far more specific than the bare name/title "status / Connection status", though it does not explicitly differentiate itself from sibling diagnostics like server_info or read_console.

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

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

"Call this first" is an explicit, actionable ordering directive that tells the agent when to reach for this tool relative to the rest of the toolset. There is no when-not guidance or named alternative, so it stops short of a 5.

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

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

Annotations only declare the generic safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds real behavioral context beyond that: the input goes out as Unicode key events, it is consumed by F8 console and chat/NUI inputs, a focused target input is required first, and it deliberately omits the Enter keystroke. What it does not cover is failure behavior when no input is focused or whether repeated calls append.

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 dense sentences with no filler; the mechanism and its consumer surfaces come first, then the required precondition, then the boundary. Every clause carries information an agent needs.

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

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

There is no output schema, so return values are the description's responsibility and they are left unaddressed (success/failure signal, whether text is echoed). For a one-parameter input-injection tool the prerequisite and effect coverage is otherwise strong, so the gap is narrow rather than structural.

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 single 'text' parameter is completely undocumented in the schema (0% coverage, bare string type), so the description carries the burden. It does add meaning — the value is typed literally as Unicode key events, not interpreted as a key name or macro — but it stops short of spelling out constraints such as embedded newlines or special-character handling.

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 mechanism — 'Sends Unicode key events' — and names the exact surfaces that consume them (F8 console, chat/NUI inputs). This cleanly separates it from the sibling key tools (press_key, hold_key, release_key) without the reader needing to open any schema.

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

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

Gives an explicit precondition ('Open the target input first') and names concrete ways to satisfy it (client_command to focus, or a chat key like T). The closing 'Does not press Enter' is a useful boundary that implies press_key for submission, but the alternative is not stated outright, so it falls just short of fully explicit when/when-not routing.

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

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

Annotations declare readOnly, idempotent, non-destructive, closed-world, which already communicate safety. The description adds that this is meant to 'sleep between actions' with specific scenarios, providing useful context about when the tool is appropriate, though it doesn't describe maximum duration, blocking behavior, or whether it returns anything.

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, efficient sentence that front-loads the core action ('Sleep between actions') followed by illustrative examples. No wasted words, though the em-dash style is compact.

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?

Given the tool's simplicity (one parameter, no output schema), the description is adequate but doesn't mention the maximum wait time or that it blocks execution. An agent might need to know these details to avoid unexpected delays. However, for a basic wait tool, the essentials are 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?

Schema coverage is 0%, so the schema only shows that 'ms' is a required integer between 0 and 120000. The description says 'Sleep' but doesn't clarify that 'ms' is milliseconds or the max limit. However, the parameter name 'ms' is self-explanatory and the schema provides bounds; the description adds minimal value.

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

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

Titled 'Pause' and described as 'Sleep between actions', the tool clearly performs a delay. The examples ('loading screens, walk cycles, held-key sequences') clarify its use over generic sleep, and it is distinguishable from siblings like wait_for_console, but the description doesn't explicitly name 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 examples ('between actions – loading screens...'), which suggest when to insert a pause. However, there's no explicit when-to-use vs. wait_for_console or other alternatives, leaving some ambiguity for an agent.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior: the call blocks, 'client' watches a live stream while 'server' polls FIVEM_SERVER_LOG, and only lines appended after the call are considered. It does not describe what a timeout yields, which is the main remaining gap for a blocking 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 sentences, front-loaded with the core action, then the target mechanics, then the usage trigger. Every sentence carries distinct information 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?

With an output schema present, return values need not be explained, and the description covers the blocking model and target behavior. The only omission is timeout/partial-result behavior, which matters for a tool that blocks up to timeoutMs.

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 beyond it: the stream-vs-poll distinction for 'target' and the 'only lines appended after the call count' semantics that govern afterSeq and the freshness of matches.

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

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

States a precise verb+resource+mechanism: 'Block until a line matching a regex appears.' It also distinguishes itself from read-only siblings (read_console, wait) by describing the two observation targets and the streaming-vs-polling model, so an agent can tell what this tool does without opening a schema.

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

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

Explicitly says when to reach for it: 'Use after a fire-and-forget command, to watch for a resource's startup banner, an error, or a scripted RESULT: line.' That is concrete triggering context, though it never names a competing sibling (e.g., read_console) or says when not to use it.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so safety is covered. The description adds genuine behavioral context beyond them: it lists the state fields returned (existence, title/pid, rect, foreground) and discloses the non-obvious side-effect-free property that input/screenshot tools handle focusing on their own.

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 answer to 'what is this?' is front-loaded before the useful focusing caveat.

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?

An output schema exists, so the description need not explain return values, and annotations cover the safety profile. The description is complete enough for an agent to call it correctly, with only explicit sibling routing 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 to document in the description; 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?

States a specific resource (the FiveM game window) and enumerates exactly what it reports: existence, title/pid, on-screen rect, foreground status. It is clearly distinguishable from siblings like server_info or status, though it never names a sibling to contrast with.

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

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

Usage is implied rather than stated — an agent infers it should call this before input/screenshot work, and the second sentence helpfully notes that input/screenshot tools focus the window automatically. There is no explicit when-to-use/when-not guidance or named alternative (e.g. focus_window).

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