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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine value beyond that: it discloses exactly what is returned on fast completion (stdout/stderr plus exit code in the same call) and that a slow command silently converts into a persistent session returning a sessionId. It omits timeout/cancellation behavior and permission requirements, keeping 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?

Two tight sentences, front-loaded with the core action and followed by the conditional outcome, with no redundancy. The adverb 'efficiently' is mild filler that earns nothing, otherwise the structure is exemplary.

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 session-spawning shell tool with no output schema and zero parameter documentation, the description covers the most important unknown (what comes back and when it becomes a session) but leaves four of five parameters, timeout behavior, and session lifecycle unaddressed. Adequate but with clear 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 description coverage is 0% across 5 parameters, so the description carries the full burden and mostly fails it. It explains only detachAfterMs (indirectly, via the completion threshold) and the command parameter; cwd, shell, and timeoutMs are never mentioned, leaving the agent to guess their semantics and defaults.

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 ('Run a shell command') and the description's second sentence clarifies the execution model. However, it never distinguishes itself from the sibling process_start, which an agent could reasonably pick for the same task, 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?

Usage is implied rather than stated: nothing says when to use exec versus process_start, process_read, or process_input. The description does explain the conditional fallback to a persistent session, which hints at how the tool behaves, but there are no explicit when/when-not rules or named 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 readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety is covered. The description contributes genuinely new behavioral context by disclosing that recursion and result count are bounded, but it never says what happens at the bound (silent truncation, partial results, or error) or whether results are ordered.

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 core verb and resource come first and the two bounding constraints follow compactly.

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 listing tool with no output schema, an agent still lacks the return shape, entry ordering, and truncation semantics — though the annotations and the "bounded" phrasing cover just enough that the tool is callable. It is minimally viable rather than 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%, so the description must carry the parameter burden and largely does not: it alludes to recursion depth and entry caps conceptually but never names `depth` or `maxEntries`, their defaults (2 and 1000), or their limits. The only remaining signal comes from the schema's own min/max/default constraints, not from 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?

Specific verb ("List") plus resource ("directory tree") makes the operation unmistakable and separable from fs_read/fs_write/fs_manage siblings that operate on file contents rather than enumerating entries. It stops short of explicitly naming those siblings or the boundary between listing and reading.

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 statement of prerequisites (permissions, path must exist), and no routing to alternatives such as fs_manage for higher-level operations. The mention of "bounded recursion" hints at limits but does not tell the agent when this tool is the right pick.

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, readOnlyHint=false, idempotentHint=false, so safety is partly communicated by structure. The description adds nothing beyond the destination rule: it never says delete is irreversible or destructive, what force does on delete/move, or that mkdir with recursive creates parents. For a five-mode mutation tool this is 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 tight sentence, front-loaded with the operation list and ending with the one parameter constraint that matters. No padding, though the brevity contributes to the coverage gaps 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?

No output schema, no annotation elaboration, and 0% schema coverage mean the description is the only source of behavioral and parameter detail — yet it covers only one constraint on one of five parameters for a multi-mode destructive tool.

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

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

Schema description coverage is 0% across 5 parameters, so the description must carry the burden. It only clarifies that destination applies to move/copy, leaving force, recursive, and path semantics completely undocumented in both schema and 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?

Names a specific resource (filesystem) and enumerates the five operations (stat, mkdir, move, copy, delete), which lets an agent distinguish it from the read/write/list/patch siblings that cover other filesystem surface. It is clear but does not explicitly say how it differs from fs_write, fs_read, or fs_list.

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 supplies one conditional rule — destination is required for move/copy — which is genuine usage guidance for parameter selection. It gives no guidance on when to choose this tool over fs_write, fs_read, fs_list, or fs_patch, nor on prerequisites or the fact that it handles multiple unrelated 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 cover safety (readOnly=false, destructive=true). The description adds meaningful details beyond annotations: edits are applied in memory, match counts are validated, and the write is atomic. It doesn't mention atomicity guarantees or failure behavior, but adds useful operational context.

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 efficient sentence that front-loads the core operation and includes key constraints. No wasted words.

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 3 params and no output schema, the description covers the high-level flow but omits parameter details (e.g., expectedSha256, expected count semantics) and error handling. Annotations cover safety, but parameter-level guidance is missing.

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

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

Schema description coverage is 0%, so the description could compensate but doesn't name any parameters. However, it does describe the core semantics of 'edits' and match validation. The nested 'expected' field is not explained. Baseline of 3 is appropriate given the schema does some structural work but lacks descriptions.

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

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

The description states a specific verb (apply text replacements), the target resource (a file), and the mechanics (in memory, atomic write). It clearly distinguishes fs_patch from fs_write (full write), fs_read, and fs_manage.

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 use for exact text replacements and mentions match validation, but doesn't explicitly say when to use fs_patch versus fs_write or fs_manage. No exclusions or 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 readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuine context beyond that: two encoding modes and line-slicing support for text vs base64 for binary. It omits truncation/error behavior (e.g. what happens when maxLines is hit).

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, with the core action stated first and the sibling routing last. Every sentence earns its place.

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

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

No output schema exists, so the description should hint at the return shape and truncation semantics; it does not say whether content is truncated at maxLines/maxBytes or how binary results are returned. For a read tool with five parameters and silent defaults, that is a meaningful gap.

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

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

Schema description coverage is 0%, so the description carries the burden, and it only partially does: 'UTF-8 line slicing' maps to maxLines/offsetLine and 'base64 for binary files' maps to encoding. maxBytes, the default 1000-line cap, and the 20MB ceiling go unexplained, yet these strongly affect output.

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

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

States a specific verb and resource ('Read one local file') and explicitly eliminates its nearest sibling with 'Prefer fs_read_many when several files are needed.' An agent can select between them without opening either schema.

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

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

Gives a clear routing rule to the alternative tool (fs_read_many for multiple files), which is exactly the ambiguity in this tool family. It stops short of any exclusion beyond that, e.g. when to use fs_list or search instead of reading directly.

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 safety is covered. The description adds the UTF-8 encoding constraint and the single-call batching rationale, but says nothing about partial-failure behavior, per-file errors, or truncation via maxBytesEach.

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

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

Two sentences, zero filler, with the core capability front-loaded and the routing advice immediately after. 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 0% schema coverage and no output schema, the description should explain the return shape (per-file content vs. errors) and the maxBytesEach truncation semantics. For a batch tool where partial failures are likely, these omissions matter.

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 carry parameter meaning. It implies a plural path input but never explains the paths array, and completely omits maxBytesEach — including that it silently caps per-file content — leaving the truncation parameter undocumented everywhere.

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 (multiple UTF-8 files) with explicit batch scope, and distinguishes itself from the fs_read sibling by framing the batch case. An agent can tell it apart from fs_read 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?

"Use this instead of repeated fs_read calls when gathering project context" gives an explicit condition and names the alternative tool. It stops short of stating when a plain fs_read is still preferable, so it lacks full exclusion 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=true, idempotentHint=false, openWorldHint=false). The description adds non-obvious behavioral context beyond that: atomicity is the default and expectedSha256 serves as an optimistic concurrency guard. That's genuinely useful. However, it omits what happens on concurrency conflict, whether append is atomic, or what atomic=false implies.

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

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

Two sentences, zero waste. The primary verbs and the default behavior are front-loaded, followed by the concurrency-guard 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?

For a 6-parameter mutation tool with no annotations on atomic semantics and no output schema, the description supplies the critical missing context (atomic write, optimistic concurrency). It leaves append-mode behavior and conflict/error semantics unexplained, so it isn't 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%, so the description must compensate. It explains the purpose of two non-obvious parameters: atomic (default overwrite atomicity) and expectedSha256 (optimistic concurrency guard). It does not cover mode semantics (overwrite vs append), createParents, or path/content, but the parameters it does address are the highest-value ones.

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 (create, overwrite, append) and resource (UTF-8 file). It is distinguishable from fs_read and fs_patch by naming the write semantics, though it doesn't explicitly contrast with fs_patch, which also modifies files. Clear but no sibling differentiation.

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 tool versus fs_patch (for edits) or when to choose append vs overwrite mode. The description conveys capability but no selection criteria or conditions.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered externally. The description adds only that the target is an 'interactive persistent process session', which is useful target context but discloses nothing about blocking behavior, what the input overwrites, or error 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?

A single front-loaded sentence with no filler or repetition. It is appropriately sized as a fragment, though it is arguably too terse for the amount of behavior it needs to convey, which is captured under contextual completeness rather than bloating this dimension.

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 destructive, non-idempotent mutation tool with 0% parameter coverage and no output schema, the description omits critical context: that a session must already exist, whether the write appends a newline, whether it blocks, and how failures surface. Annotations carry the safety profile, but the remaining gaps are substantial.

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% across three parameters, so the description must compensate and largely does not. The word 'input' loosely maps to the input parameter, but sessionId, and especially the newline default of true, receive no clarification.

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 clear verb (Send) and resource (input) against a specific target (interactive persistent process session). It is distinguishable from siblings like exec or process_start because it targets an existing session, though it does not explicitly name any alternative 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?

No when-to-use guidance, no prerequisites (e.g., a session must first be created via process_start), and no comparison to alternatives like exec or process_start. The phrase 'persistent process session' weakly implies the context but leaves everything to inference.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds genuinely new context beyond them: the blast radius extends to the child process tree, and that tree behavior is Windows-specific. It still omits whether termination is graceful or forced and what happens on non-Windows hosts.

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 with the action front-loaded and zero filler. The Windows qualifier is placed where it is most relevant, immediately after the scope claim.

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 destructive tool whose annotations fully declare the safety profile and which has no output schema, the description covers the essential what and blast radius. Minor gaps remain around failure modes (invalid or already-dead sessionId) and graceful vs forced termination.

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

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

Only one parameter, and schema coverage is 0%, so the description must carry meaning but never mentions sessionId at all. The schema's uuid format plus strict pattern partially self-documents the expected value shape, but the description adds nothing about where to obtain a valid sessionId, so 3 is the ceiling.

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 (terminate) and resource (a persistent process session), which is enough to distinguish it from process_read, process_input, and process_start. It does not explicitly call out which sibling to use instead, so it stops short of full sibling differentiation.

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 guidance, no mention of prerequisites (e.g. a valid active sessionId), and no routing to alternatives such as process_list or process_input. The only usable cue is the implicit 'this ends the session', which the agent must infer.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description's only added behavioral detail is the temporal filter ("active and recently completed"), which usefully signals that older history is excluded, but it says nothing about ordering, pagination, or result volume.

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 with no filler, front-loading the verb and resource with the scope qualifier attached. Every element of the sentence does work.

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 list tool with annotations covering the safety profile, the description is nearly sufficient. Since no output schema exists, it could have hinted at what each listed session contains or how results are ordered, but this is a minor gap for such a simple operation.

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 explain; the baseline for a parameterless tool is 4. The description correctly avoids inventing filtering options that the empty schema does not support.

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 ("persistent process sessions") with a qualifying scope ("active and recently completed"). This clearly separates it from process_read/process_input/process_kill, which act on a single session, though it does not name or reference 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 only implied: an agent can infer this is the discovery step before process_read or process_input, but the description states no explicit when-to-use condition, no prerequisites, and no contrast with sibling tools. Nothing is misleading, but nothing is spelled out either.

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, non-destructive, openWorld=false, but idempotentHint=false is notable and the description explains why: omitting the cursor consumes new events incrementally while supplying one replays from a fixed position. That stateful-consume behavior is genuine value beyond the annotations, though waitMs semantics and buffer/consumption behavior remain undisclosed.

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

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

Two tight sentences with the core action first and the cursor semantics second. No filler, nothing repeated from the 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?

No output schema exists, yet the description never characterizes the returned events or the cursor value an agent should pass next, and waitMs is unexplained. For a streaming-read tool this leaves real gaps an agent would need to probe at runtime.

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 carry the param burden. It explains cursor's two modes well, but sessionId is left to the schema and waitMs (a 0-10000 long-poll-style delay) is never explained despite being the least self-evident 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 and resource: reading output events from a persistent process session. The scope word 'persistent process session' separates it from fs_read and search, though it never names a sibling or explains the boundary with process_input.

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 conditional guidance for the cursor parameter (omit for incremental, provide for replay), which is really parameter usage rather than tool selection. It offers no statement of when to reach for this tool versus process_list, process_input, or fs_read.

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, non-read-only, and this description's 'without waiting' adds genuinely new async behavior context. However, it does not disclose consequences (e.g., that starting a command spawns a persistent process/session requiring later process_kill), nor any resource or permission notes.

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 tight sentence that front-loads the action and the key behavioral differentiator ('without waiting'). 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?

Covers the core async behavior and return value, but a mutation tool that spawns persistent OS processes ought to mention that the resulting process must be managed (process_kill) and clarify cwd/shell semantics. Given no output schema and zero param coverage, more disclosure is 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 description coverage is 0%. The description only explains the required 'command' implicitly, and provides no meaning for 'cwd' (working directory) or 'shell' (shell selection). With three parameters undocumented in both schema and description, the tool relies entirely on param-name inference.

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 action and resource: 'Start a ... command' and states the key outcome 'return a sessionId without waiting'. This clearly distinguishes it from 'exec' (synchronous execution) and from process_read/process_input/process_kill which operate on an already-started session.

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 'long-running or interactive' indicates the use case well, but no explicit exclusion of 'exec' or mention of following up with process_input/process_read. For a session-oriented tool this is clear context without full routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds what the tool surfaces (runtime, security scope, active process sessions), which is useful, but says nothing about freshness, cost, or output shape. Appropriate credit over the annotation baseline, but not rich.

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 list of exposed facets is dense but every clause is informative.

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 itself, and it does name the three main pieces of information returned. It lacks detail on format or scope boundaries, but for a zero-parameter status tool this is close to sufficient.

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 clarify; the baseline for a parameterless tool is 4. There is nothing in the description that misrepresents the inputs.

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 ("Show") and a concrete resource (Rob Desktop Commander runtime, security scope, active process sessions). It is distinguishable from process_list because it describes runtime/security introspection rather than process enumeration, though it never explicitly names a sibling.

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

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

There is no statement of when to call this versus the many process_* and fs_* siblings, nor any prerequisite or trigger. Usage is only weakly implied by the word "status".

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, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context (ripgrep-backed, local, and the output format for content mode), but it omits behavioral details like the ignoreCase=true and includeHidden=false defaults or maxResults capping that affect result sets.

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 identity of the tool, then the mode distinction. 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?

For an 8-parameter tool with 0% schema coverage and no output schema, the description is far too thin — six parameters are unexplained and there is no statement of return shape, result ordering, or result-limit behavior.

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% across 8 parameters, so the description carries the full burden. It clarifies only the mode enum (content vs name); glob, literal, ignoreCase, maxResults, and includeHidden are left with no explanation of their semantics or defaults.

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+resource ('local search') and its engine (ripgrep), and it disambiguates the two operating modes with their output shapes (line/column vs file paths). It does not, however, contrast itself with nearby siblings like fs_list, fs_read, or exec, which an agent must still infer.

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 explains what each mode does but never says when to use this tool rather than fs_list, fs_read, or exec, nor any prerequisite such as the path needing to exist. With 13 siblings, no routing guidance is a real gap.

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