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

Annotations only set readOnlyHint=false and openWorldHint=false. The description adds genuinely useful behavior beyond that: message content is untrusted text and never transfers a permission, lease, or task assignment — a security-relevant constraint the agent could not derive from annotations. It stops short of covering TTL/expiry or ack semantics, so not a 5.

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

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

Three tight sentences: purpose first, addressing second, safety caveat last. No filler, and the most decision-relevant information is front-loaded.

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

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

For a multi-action tool with 11 parameters, a nested object, and no output schema, the description omits how the three actions differ in required inputs (e.g., messageId for ack, to/body for send) and what inbox returns. Purpose and security context are covered, but action-level behavior is not, leaving meaningful 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 only 27% across 11 parameters, so the description carries real burden. It does clarify the `to` field's addressing syntax ('short name, runtime id or role mailbox such as role:verifier') and implicitly maps verbs to the `action` enum, but leaves kind, ttlMs, taskId, messageId, includeAcked, and the nested agent binding undocumented — partial compensation only.

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

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

The description names the exact three verbs (send, read, acknowledge) that map to the `action` enum and a specific resource (a bounded task-scoped message between runtimes). This cleanly separates it from siblings like agent_presence and agent_monitor, which observe runtimes rather than exchange messages.

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 'bounded task-scoped message between runtimes,' giving general context, but there is no explicit when-to-use or when-not guidance and no alternatives named (e.g., when to prefer agent_monitor for observation). Bounded and task-scoped hint at the intended scope, but the agent must infer the rest.

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 establish readOnlyHint=false and openWorldHint=true. The description usefully adds that auth checks run 'without logging in or running a model' via 'permitted commands', clarifying scope. However, it buries the fact that writePage defaults to true, so a state-mutating file write happens by default – the description frames writing as a trailing option rather than the default 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?

The primary purpose is front-loaded in the first sentence, which earns its place. The second sentence is a long run-on chaining two alternatives with commas, making it denser than needed for the amount of information conveyed.

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

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

With no output schema, 4 parameters at 25% coverage, and a nested object, the description should carry more of the load. It gives a usable overview of capabilities but omits refreshSeconds behavior, the writePage default, and any hint about the returned summary format.

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 low (25% – only the nested agent object is documented). The description compensates partially by implicitly mapping 'check existing CLI sign-in status' to checkAuthentication and 'write a self-contained HTML page' to writePage, but refreshSeconds is never mentioned and no defaults or boolean semantics are explained.

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

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

States specific verbs and resources – summarising runtimes, presence health and installed launchers, with optional sign-in checks and HTML page output. An agent can grasp the monitor's scope, though it does not explicitly distinguish itself from the closely named sibling agent_presence.

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 enumerates optional capabilities but gives no when-to-use guidance, no conditions selecting it over agent_presence, and no prerequisites. 'Optionally' signals flexibility but not context for the agent to choose 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 declare readOnlyHint=false and openWorldHint=false, so the mutating-but-local nature is already signaled; the description usefully adds that the server mints a UUID/key and short name on first call, that later calls are refreshes, and that the granted name carries no filesystem/command permission. It does not mention rate limits, idempotency, or what happens on credential mismatch, which keeps it out of 5 territory.

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

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

Four short sentences, front-loaded with what the tool does and immediately followed by the credential lifecycle, which is the most decision-relevant fact. Slight redundancy between 'No model/name handshake question is needed' and the schema's 'no extra handshake' note, but nothing is wasted 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?

For a 14-parameter, no-output-schema, nested-object tool the description covers the lifecycle and the shape of the first-call return value well. It still leaves most parameter semantics and the effect of 'stopped' undefined, which is a real gap even accounting for the credential explanation.

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 14% across 14 parameters, so the description must carry the load, yet it only glosses activity/project/task/model/phase and omits runtimeId/runtimeKey, stopped, source, capabilities, label, node, and includeHostMemory. Even the hinted fields get no format or constraint detail beyond what the schema enforces.

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 pair (announce/refresh) and a specific resource (this AI runtime's activity, project/task, model, phase), so it is clearly distinct from siblings like agent_monitor and agent_message. It never names a sibling explicitly, so it stops short of a 5, but an agent can place it correctly.

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 clear lifecycle context: the first call obtains server-issued credentials, later calls reuse them, and no separate model/name handshake is required. That answers the main 'when do I call this' question, but there is no explicit exclusion or pointer to an alternative tool for presence queries.

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 the annotations: it discloses the allowlist/root constraints, the 240000 ms cap tied to shell.maxTimeoutMs, that a run at the cap is killed, and that timedOut is returned with partial output captured so far. That kill/return semantics is exactly the operational context annotations cannot express.

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

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

Four sentences, each load-bearing, with the core capability front-loaded and the timeout/alternative details following in priority order. No filler or restatement of the tool name.

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

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

No output schema exists, and the description does cover the notable return case (timedOut plus partial output), but it does not sketch the general result shape (exit status, stdout/stderr). Combined with the kill and allowlist constraints, an agent has enough to call it correctly, though not a full picture of the response.

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?

With only 20% schema description coverage, the description compensates by defining command (allowlisted executable, no shell string), args (separate argument array), timeoutMs (240000 ms cap), and implying cwd must sit inside an allowed root. The agent param is left to its schema description, which is acceptable but leaves a small 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?

States a specific verb (Run) and resource (one allowlisted executable with a separate argument array inside an allowed root), plus the scope constraint that no free-form shell string is accepted. It also names process_start/process_output as the different alternative, so an agent can distinguish it from siblings 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 routes long-running work (e.g. coding-agent CLIs) to process_start and process_output, and implies the bounded-execution case is what this tool covers. It omits any guidance versus the closely related parallel_command_run sibling, so routing is not fully complete.

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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds a non-obvious behavior: large generated directories are skipped during recursive listing. It doesn't explain how 'large' is defined, what happens on truncation, or error behavior, so it adds some value but leaves gaps.

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 compact sentences with no waste. The skip behavior is a bit under-specified rather than verbose, so conciseness is fine.

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?

A list tool with 5 params, 20% schema coverage, a nested agent object, and no output schema. The description omits return shape, pagination/truncation behavior via maxEntries, maxDepth semantics, and the agent param entirely, leaving the agent under-informed 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 20%, leaving maxDepth, recursive, maxEntries, and path undocumented in the schema. The description mentions recursive listing in passing but doesn't explain maxDepth, maxEntries, defaults, or the agent binding parameter, so it fails to compensate for the low coverage.

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 clear verb (list) and resource (files and directories) scoped to an allowed root. It distinguishes from siblings like fs_read and fs_search reasonably, though it doesn't explicitly contrast with process_list or project_snapshot.

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 explicit when-to-use guidance, prerequisites, or alternatives. The agent must infer that this lists directory contents versus fs_search which likely searches by criteria, but nothing in the description says so.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is known. The description adds genuinely useful behavior beyond that: UTF-8-only encoding, confinement to an allowed root, and default blocking of secret-like files. It stops short of noting error/return behavior.

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

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

Two short sentences, zero filler, with the core operation and the key guardrail front-loaded. Nothing can be trimmed without losing meaning.

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 tool with readOnly annotations and no output schema, the safety side is covered, but the low parameter coverage leaves line-range semantics and path format unexplained. Adequate but with clear gaps given four parameters and nested agent binding.

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 25%, so the description carries the burden for startLine, endLine and the path format, yet it says nothing about them. The line-range parameters and whether path is relative/absolute are left entirely to the bare schema types.

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 a UTF-8 text file') with the scoping constraint (inside an allowed root) and a blocking rule for secret-like files. This clearly distinguishes it from fs_write/fs_replace/fs_list, though it does not explicitly name 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?

It implies the usage context by describing the allowed-root scoping and blocked secret files, but never says when to choose this over fs_search or fs_list, nor any exclusions or prerequisites. Guidance is inferred rather than stated.

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

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

Annotations already disclose the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), lowering the bar. The description still adds real value by disclosing a failure mode ('fails when the target text is absent or ambiguous') and the UTF-8 encoding constraint, which are not derivable from structured fields.

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, with the core purpose and the failure condition front-loaded. Nothing redundant or padded.

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

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

For a mutating, 5-parameter tool with 20% schema coverage and a nested object, the description leaves gaps: it never explains replaceAll's replace-one-vs-replace-all semantics, whether the file must already exist, or atomicity. No output schema exists, so return behavior is also unaddressed.

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

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

Schema description coverage is only 20%, so the description must compensate; it gives semantic meaning to path, oldText (exact target) and newText, but is silent on replaceAll (the most consequential flag, defaulting to false) and on the nested agent parameter. Partial compensation only.

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 ('replacing an exact string in a UTF-8 file') and a precise scope ('exact string'), which implicitly distinguishes it from whole-file writes. However, it never names or contrasts with the sibling fs_write, so an agent must infer the distinction rather than read it.

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

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

Usage is only implied: the phrase 'precise text edit' suggests this is for surgical edits when the exact target text is known. There is no explicit when-to-use, when-not-to-use, or routing to alternatives such as fs_write or fs_search despite those siblings existing.

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 and openWorldHint=false, so safety is covered. The description adds that traversal is recursive, constrained to an allowed directory, and returns matching lines, but says nothing about result caps, regex behavior, or that non-text files are skipped.

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 well-formed sentence with no filler and the key scoping constraint front-loaded. Efficient, though arguably too thin to structure a 7-parameter tool.

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

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

A 7-parameter tool with a nested object, no output schema, and 14% schema coverage needs far more from the description than one sentence. Filtering options, result limits, and error behavior are all absent.

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

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

Schema description coverage is only 14% (only the nested agent object is documented), and the description does not compensate. It says nothing about regex, extensions, caseSensitive, or maxResults, leaving six parameters semantically unexplained.

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 (search), resource (text files), scope (recursively under an allowed directory), and output (matching lines). It is distinguishable from fs_list/fs_read in spirit, but never names a sibling or contrasts behavior, so it stops short of a 5.

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

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

No when-to-use, when-not-to-use, or alternative guidance. An agent cannot tell from the description whether to reach for fs_search, fs_read, or fs_list for a given need.

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, idempotentHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is carried structurally. The description adds genuine context beyond that — UTF-8-only content and the parent-directory precondition — but says nothing about auth/permission requirements, error behavior when the root is not allowed, or that content is silently discarded when replacing.

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

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

Two short sentences with zero filler, front-loading the core action before the precondition. Every clause earns its place and 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?

With no output schema and annotations covering only the safety profile, the description needs to carry parameter and failure semantics. It covers scope and the parent-directory precondition adequately but omits overwrite behavior, allowed-root boundaries, and error outcomes for a 4-parameter destructive write 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 only 25% (just the optional 'agent' object), so the description must compensate for path, content, and especially 'overwrite' (which defaults to true and silently replaces existing data). It only obliquely implies path/content via 'text file inside an allowed root' and never mentions overwrite at all, leaving the most consequential parameter undocumented in both places.

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 pair ('Create or replace') and resource ('one UTF-8 text file') with a scope constraint ('inside an allowed root'). It is distinguishable from fs_read and fs_search by the write semantics, though it never names fs_replace, the sibling whose whole-file-overwrite behavior is most easily confused with it.

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

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

The phrase 'Create or replace' implies the tool handles both new and existing files, and 'The parent directory must already exist' gives a real precondition. However there is no explicit when-to-use versus fs_replace or fs_write alternatives, and no statement of when this tool should not be chosen.

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 and openWorldHint=false, so safety is covered. The description adds one genuinely useful behavioral trait – output is capped by the server – but never says what the cap is or how truncation surfaces to the caller, and does not explain failure modes for non-repo paths.

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 action and the output-cap caveat both earn their place. It is lean to the point of being under-specified, but nothing is wasted.

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

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

Four parameters including a nested agent object, 25% schema coverage, and no output schema leave the description carrying too little. An agent cannot tell how `path` and `file` interact, whether `staged` and working-tree can be combined, or what a capped response looks like.

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 25%, so the description must compensate and largely does not. It gestures at the staged/working-tree choice (mapping to `staged`) but says nothing about the required `path`, the `file` filter, or how the nested `agent` binding affects attribution.

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 a git working-tree or staged diff") and names the two modes of the diff, which implicitly separates it from git_status and git_log. It is clear what the tool does, though it never explicitly contrasts itself with those siblings.

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

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

There is no when-to-use guidance, no statement of when to prefer git_diff over git_status or git_log, and no prerequisites (e.g., needing a repo initialized at the path). The staged parameter hints at a use case but the agent must infer 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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description earns some credit for the 'inside an allowed root' sandbox constraint, but says nothing about result ordering, backfill depth, or what happens when path is outside the root.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though the terseness is partly why parameter and usage detail is missing.

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

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

For a simple read-only tool with no output schema, the essentials are present, and return values need not be explained. However, with two undocumented parameters and no indication of output shape or ordering, the definition is only minimally 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?

Schema description coverage is only 33% — the agent object is documented, but the required 'path' and the 'limit' parameter (default 15, max 100) are not explained anywhere. The description mentions 'repository' without clarifying how path resolves to one, and ignores limit entirely, so it 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?

States a specific verb (Read) plus resource (recent git commits) and scope (repository inside an allowed root). It is clearly distinct from git_status and git_diff in intent, though it never names those siblings to sharpen the distinction.

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

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

The description gives no guidance on when to prefer this over git_status, git_diff, or command_run with a raw git command. The implicit usage (inspecting commit history) is self-evident from the name, but no conditions or exclusions are stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds two useful behavioral facts the annotations don't carry: output is 'compact' and the path must be inside a permitted root. It says nothing about what happens for a path outside the root or a non-repository directory, so a 3 is appropriate.

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 14-word sentence that front-loads the verb, resource, and output character ('compact'), with the scoping constraint at the end. No filler or 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 simple read-only status tool with annotations covering safety and no output schema, the definition is nearly complete; the agent knows what it reads and where it may read from. Only edge behavior (invalid path, non-repo dir) and any return-shape expectation are left unaddressed.

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

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

Schema coverage is 50%: the nested 'agent' object carries its own description, while the required 'path' parameter has none. The phrase 'for a repository inside an allowed root' partially compensates by implying path is a repo directory constrained to an allowed root, but no format or failure semantics are given.

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

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

States a specific verb ('Get') and resource ('git branch and working-tree status') with explicit scope ('for a repository inside an allowed root'). This cleanly separates it from siblings git_diff (diffs) and git_log (history) without needing their schemas.

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

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

Usage is only implied: an agent infers you call this to inspect branch/dirty state before diffing or committing. There is no explicit when-to-use statement, no mention of when to prefer git_diff or git_log instead, and no prerequisite 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 destructiveHint=true, openWorldHint=true and readOnlyHint=false, so the risk profile is carried structurally. The description usefully adds two behavioral facts the annotations do not cover: host restriction and that redirects are not followed. It says nothing about timeouts, response size limits, or what 'bounded' actually constrains.

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 scope constraint and the redirect caveat, with no filler. Appropriate size for the content given, though the brevity leaves gaps rather than being genuinely tight.

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 five-parameter, open-world HTTP tool with a nested object and no output schema, the description is too thin: it never explains how a caller discovers the 'configured local hosts', what the 'bounded' limits are, or what failures look like. Annotations cover safety but not calling mechanics.

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 20% (just the nested 'agent' object), and the description adds no meaning for url, body, method, or headers. With five parameters and a low-coverage schema, the description should compensate but does not — e.g. no note that method defaults to GET or how headers/body interact.

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

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

The description states a specific verb and resource (make an HTTP request) and scopes it to 'configured local hosts', which clearly separates it from the fs_*, git_*, and process_* siblings. It is not tautological, though 'bounded' is left unexplained.

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 hard precondition ('only to configured local hosts') but never says when to reach for this tool versus command_run or agent_message, nor what to do when a host is not configured. Usage is only loosely implied.

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 openWorldHint=true, so the risk profile is set; the description adds genuinely new behavior: per-command process isolation, scheduler slots, audit request ids, separate stdout/stderr, and a hard timeout cap of 240000 ms that the schema's maximum does not express. It stops short of describing permissions/allowlist failure modes, so a 4 rather than 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: the capability plus constraints first, then the routing decision. Every clause carries information; nothing is padded or repeated.

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

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

With no output schema, the description does useful work by stating each command yields its own stdout/stderr and result, covering the return shape at a high level. It leaves the `agent` attribution parameter and partial-failure semantics (what happens if one of 32 commands fails) unexplained, which is the remaining gap for a batch mutation 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 50%, and the description compensates partially by restating the 2-32 command range and, more usefully, revealing a 240000 ms effective timeout cap that the schema maximum does not. It says nothing about the nested per-command fields (id, cwd, args) or the `agent` binding, so half the parameter surface remains unexplained.

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

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

States a specific verb and resource ('Run ... commands concurrently'), names the execution mode (parallel, allowlisted), and quantifies scope (2-32). It is immediately distinguishable from the sequential command_run 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?

Gives an explicit routing rule: 'Use this instead of sequential command_run calls when commands do not depend on each other.' That names the alternative and the exact condition that selects it, which is the strongest form of usage 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 destructive=true, idempotent=true, openWorld=false, so the safety profile is covered. The description adds one genuinely useful constraint — the tool only kills processes this server spawned — but says nothing about graceful vs. forced termination, error behavior for unknown/stale ids, or whether descendants are affected.

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, front-loaded with the action verb and carrying the scoping constraint. Nothing to trim.

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 one-shot tool with no output schema, the description covers the core action and the eligibility rule, and annotations cover safety and idempotency. It still leaves failure modes and the meaning of the id parameter undocumented, which an agent would want before calling it on an uncertain handle.

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 50%: the nested `agent` object is documented in the schema, but `id` has no description anywhere. The description's "a process previously started by this MCP server" hints that id is a handle from process_start, but adds no format, origin, or validity detail beyond that hint.

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 ("Stop") plus resource ("a process") and a scoping qualifier ("previously started by this MCP server") that separates it from process_start and process_list. It stops short of naming the sibling it pairs with, but the resource is unambiguous.

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

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

The scope clause implies the eligibility condition (only processes this server started), which is real routing guidance. However there is no explicit when-to-use framing, no mention of process_list/process_output for identifying a target, and no guidance on already-exited or foreign processes.

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 provide readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the scoping detail that only processes started by this MCP server are returned, which is useful context, but it does not cover return format, pagination, or ordering.

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

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

A single front-loaded sentence with no wasted words. It is appropriately sized for a simple read-only listing tool.

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

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

For a simple read-only list operation with annotations covering safety, no output schema, and fully described schema parameters, the description is nearly complete. It could still specify ordering or filtering context, but nothing essential for 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 description coverage is 100%, including the nested 'agent' object with its own explanation, so the schema carries the parameter semantics. The description adds no additional parameter meaning, making the baseline 3 appropriate.

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

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

States a specific verb ('List') and resource ('processes started by this MCP server'), and the scope phrase distinguishes it from process_output, process_kill, and process_start. It does not explicitly name any sibling tool, 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?

The description implies a use case but gives no when-to-use guidance, no exclusions, and no alternative tool routing. An agent can infer this tool is for viewing processes, but nothing directs it against the nearby process_output or process_kill tools.

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 and openWorldHint=false, so the safety profile is covered. The description adds that output is 'recent captured' stdout/stderr, implying a buffered tail rather than a live stream, but it never mentions truncation, buffer limits, or whether output can be lost before reading.

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 and the scoping constraint stated immediately. It is efficient, though its brevity is part of why the other dimensions have gaps.

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

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

There is no output schema, so the description bears some burden of describing what is returned, which it only gestures at with 'stdout/stderr.' For a 3-parameter tool with a nested agent object and a 200k-char tail limit, the definition is minimally adequate 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 only 33%: only the nested 'agent' object is documented in the schema, while 'id' and 'tailChars' carry no explanation. The phrase 'recent captured' faintly signals that tailChars bounds the returned window, but the description supplies no meaning for id or the agent binding.

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 (recent captured stdout/stderr) and scopes it to 'a process started by this MCP server.' An agent can separate it from process_list, process_start, and process_kill, though no sibling is named 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 by the phrase 'for a process started by this MCP server,' which suggests pairing with process_start. There is no explicit when-to-use, when-not-to-use, or direction toward process_list for enumerating processes.

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 openWorldHint=true, but the description adds real lifecycle context: scheduler-coordinated startup, independent execution under ProcessManager ownership, no timeout, and closed stdin for agent CLIs. It does not cover failure behavior or what 'allowlisted' actually permits, leaving a modest gap.

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

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

Four dense sentences, front-loaded with purpose and return value before lifecycle and the command_run alternative. Every sentence carries actionable information, though the coding-CLI note is a touch long.

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 no output schema and existing annotations, the description covers lifecycle, polling/termination siblings, and the timeout contrast to command_run. Missing parameter-level detail (cwd/args) is the main shortfall, but the safety and lifecycle picture is otherwise 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 only 25% (only the nested 'agent' field is documented), yet the description never explains command, args, or cwd semantics. The coding-CLI example hints at how args are used, but it does not compensate for the undocumented 75%.

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 ('Start a long-running allowlisted local process') and the immediate return value (its id). It also distinguishes itself from command_run by naming the 240000 ms cap that forces the switch, so an agent can differentiate it from siblings without opening schemas.

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 explicit routing rules: use it for runs that may exceed command_run's timeout, then poll process_output and terminate with process_kill. It even adds a conditional usage note for coding-agent CLIs (closed stdin, use streaming output flags), which is prescriptive guidance an agent could not 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 and openWorldHint=false, so the safe, local-read safety profile is covered. The description usefully discloses the snapshot content, but adds nothing about cost/latency, whether it shells out to git, error behavior for a non-repo path, or truncation of large diffs.

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 that names the action first and then the payload items; every clause earns its place and there is no filler or restatement of the 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?

With no output schema, the description carries the return-value burden and does so by enumerating the snapshot contents, which is the key information an agent needs. It stops short of describing structure, size limits, or failure modes, and leaves the required 'path' argument entirely unexplained.

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%: the nested 'agent' object is documented, but the required 'path' parameter has no schema description. The description adds no meaning to either parameter — it never clarifies whether 'path' is the repo root, a subdirectory, or a working directory, so the gap is not compensated.

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 ('Collect') and enumerates exactly what the resource returns: repo root, git status, diff summary, recent commits, package scripts, package manager, and MCP-managed processes. An agent can immediately see this is an aggregate bundling the outputs of git_status, git_log, and process_list into one call, distinguishing it from those single-purpose siblings.

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

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

The phrase 'in one call' implies the intended usage is to get broad context efficiently rather than calling git_status/git_log/process_list separately, but this is left implicit. There is no explicit when-to-use/when-not wording, no prerequisite about running it from a repo, and no stated alternative tool for narrower needs.

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 and openWorldHint=false, so safety is covered. The description adds value by disclosing what state is actually inspected (limits, active work, queue, locks), which matters because there is no output schema to reveal the return shape. It stops short of noting auth requirements or lock 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?

One front-loaded sentence with no filler; the resource comes first and the inspected facets follow. Nothing could be trimmed without losing information.

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

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

With no output schema, the description usefully enumerates the categories of state returned, and the sole parameter is optional and documented in the schema. It omits whether calling it requires specific permissions or whether scheduler state is snapshotted at call time, which keeps it from a 5.

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

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

Schema coverage is 100% and the single 'agent' parameter (a nested runtime binding object) is fully documented in the schema, including that it is optional and only used for monitor attribution. The description adds nothing about this parameter, so the baseline 3 is appropriate.

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

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

States a specific verb ('Inspect') and a clearly scoped resource ('Local Commander execution scheduler'), then enumerates the facets exposed: limits, active work, queue, resource locks. That is enough to distinguish it from process_list or process_output, but the description never names a sibling to contrast against, so it stops short of a 5.

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

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

There is no explicit when-to-use or when-not-to-use guidance, nor any pointer to an alternative like process_list or process_output. The intended use (checking scheduling capacity before launching work) is only implied by the enumerated facets.

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