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

Annotations only supply destructiveHint/idempotentHint flags; the description goes well beyond them with atomicity, per-action revision requirements, the REVISION_MISMATCH refusal for stale files, the create-asserts-absence rule, and the fact that a path may appear only once per call. It correctly aligns with destructiveHint=true (write/edit/delete/move operations) and does not contradict idempotentHint=false (the idempotency_key is an opt-in replay mechanism, not inherent idempotence).

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

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

Front-loaded with the core purpose and the sibling routing decision, then dense per-action rules, and it closes with a concrete example. Efficient overall, though some sentences restate revision rules already carried in the schema property descriptions.

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 3-parameter, nested, destructive multi-file mutation tool with annotations and an output schema, the description covers atomicity, revision/auth preconditions, error codes, per-action semantics, and the request-size envelope. An agent has everything needed to call it correctly.

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

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

Schema coverage is moderate (67%), and the description compensates by explaining which actions require vs. reject revision, that create asserts absence, and the whole-lines semantics of content ('' is zero lines, trailing newline adds a blank line). It also duplicates some schema text (line numbers refer to file as read) and provides a worked example, so it adds value but is partly redundant with the schema.

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

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

States a specific verb+resource ('Apply line-addressed file changes atomically') and immediately distinguishes itself from the sibling apply_patch by naming the selection condition (when you know the line numbers). An agent can pick between the two without opening either schema.

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

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

Explicit when-to-use ('prefer this over apply_patch when you know the line numbers') and when-not ('use apply_patch to chain several edits onto one file'), plus the constraint that paths appear once per call. Both the alternative and the switching condition are named.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety bar is lower. The description still adds real behavioral detail beyond the annotations: atomic application, the graded matching order (exact → trailing whitespace → indentation), that the used grade is returned as match_quality, that multiple updates to one path chain in order, and the returned fields. It never explicitly warns that hunks overwrite file content, which is the one 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?

Front-loaded with the core action, then progressively more specific constraints and a pointer to the full format reference. Dense but each sentence carries a distinct rule about patch authoring. The inline example is justified given the custom patch grammar, though it adds length.

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

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

An output schema exists, so the mention of revision/total_lines/changed_ranges is surplus but harmless. The custom V4A format is documented well enough to author a valid patch, idempotency replay and the IDEMPOTENCY_KEY_REUSED error are covered by the schema param text, and a reference doc is cited for full grammar. Only the dry_run semantics and the destructive-overwrite warning are thin.

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

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

Schema coverage is only 33%, so the description must compensate for 'patch' and 'dry_run'. It does so substantively for 'patch': V4A envelope structure, unique-context requirement, scope headers, end-of-file anchoring, blank-line conventions, and an inline example. 'dry_run' is only implied by 'Stage, validate' and is not spelled out, which keeps this below a 5.

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?

Opens with a specific verb triad and resource: 'Stage, validate, and atomically apply a V4A patch envelope.' An agent immediately knows this is the patch-application tool. It does not, however, distinguish itself from the sibling 'apply_changes', leaving the boundary between the two patch-oriented tools to inference.

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

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

Usage guidance is framed as format mechanics (add a scope header, use '*** End of File', how blank context lines are written) rather than when-to-use steering. There is no statement of when to reach for apply_patch instead of apply_changes, write_file, or exec_command. A reader can infer it handles multi-hunk patches, but the routing is implicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds modest value by signaling the response is 'lightweight' and reflects state 'known to the server' (i.e., a cached snapshot rather than a live probe), but says nothing about freshness, auth, or failure behavior.

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

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

A single compact sentence that front-loads the verb and the resource. Nothing is padded, though the phrase 'known to the server' is slightly opaque.

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

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

An output schema exists, so the description need not document return values. For a zero-parameter diagnostic, the description supplies adequate context, with the only gap being when to reach for it versus exec_command.

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

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

The tool takes zero parameters, which is the baseline-4 case; there is no argument surface the description could or should explain. Schema coverage is 100% but trivially so, since the schema has no properties.

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 (Return) and resource (exec_command sandbox and environment status), so an agent knows this is a read-only status probe rather than a command runner. It is clear but does not explicitly contrast itself with exec_command or read_output, leaving sibling differentiation to inference.

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

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

No explicit when-to-use or when-not-to-use guidance is given. Usage is only implied by context — an agent would infer you call this before exec_command to learn the sandbox environment — but nothing states that or names an alternative.

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/openWorld/non-idempotent, and the description adds substantial context beyond them: the yield-vs-lifetime distinction, that a command keeps running under its command_id after the call returns (not killed), per-stream output bounding, and the reconnect-safe workdir convention. These are real operational traits an agent cannot infer from the annotations.

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

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

Front-loaded with purpose, then the timing semantics, an inline example, and the output-handling caveat. Every sentence carries information and none repeat the schema or annotations.

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

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

An output schema exists, so return values need not be explained, and annotations carry the safety profile. The description covers the critical async/timeout behavior well, but for an 11-parameter tool with 18% schema coverage the unresolved cwd vs workdir ambiguity and undocumented env/tty/verbosity params leave a 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 only 18%, so the description must compensate for the rest. It admirably clarifies the two most confusing params (yield_time_ms vs timeout_ms), the workdir rationale, and gives a concrete example, but it stays silent on nine others (cwd, env, tty, stdin, verbosity, preview_bytes, max_output_bytes) and never addresses the overlapping cwd/workdir pair. Partial compensation warrants a 3.

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 a bounded command under runtime policy') and immediately scopes it as bounded with a runtime policy. It also routes to siblings, telling the agent that a still-running command is continued via write_stdin or read_output and large output is paged via read_file or search_text.

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

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

Clearly explains the two timing knobs (yield_time_ms = how long this call waits; timeout_ms = total process lifetime) and when to use the async continuation path versus paging redirected output. It lacks an explicit 'when not to use' or a pointer to check_exec_environment for preflight, so it stops short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The word 'bounded' hints that output is truncated, but the description never explains the default cap (max_lines=200), the 1000 ceiling, or what happens when the range is exceeded.

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. It is efficient, though arguably too terse given the five-parameter surface it must support.

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

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

An output schema exists, so return values need not be explained. However, with five undocumented parameters and no usage context, the description leaves the agent guessing about line-range and revision semantics on a tool whose whole purpose is targeted line attribution.

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 five parameters, so nothing documents rev, start_line, end_line, or max_lines. The description's only nod to parameters is the vague adjective 'bounded', which does not tell an agent that max_lines defaults to 200 or that start/end_line are 1-based.

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 (blame) and resource (workspace file) with a useful scope qualifier ('bounded'). It is distinguishable from git_log/git_show, though the description never names a sibling to sharpen the boundary.

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

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

No guidance on when to reach for blame versus git_log, git_show, or git_diff. An agent must infer the use case from the tool name alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the genuinely useful behavior that untracked files are rendered as additions. However, it omits other behavioral traits such as max_bytes truncation, how staged and unstaged passes combine by default, and whether output can be truncated.

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

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

Two sentences, front-loaded with the verb and resource, with no filler. The trailing rationale about newly created files is mildly redundant with the schema description but still earns its place as usage framing.

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

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

An output schema exists, so return values need not be explained, but for a 7-parameter tool with 14% schema coverage the description is too thin. It leaves the agent without guidance on path vs paths, staged/unstaged interaction, or truncation 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 only 14%, with 7 parameters and only include_untracked documented, so the description is expected to compensate but largely does not. It never clarifies the path vs paths distinction, the staged/unstaged defaults, max_bytes truncation limits, or context_lines. It only restates the untracked behavior already covered by the schema.

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

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

States a specific verb and resource ('Return unified git diff for workspace changes'), which is unambiguous and distinct from siblings like git_status, git_log, and git_show. It stops short of explicitly contrasting itself with those siblings, so it is clear but not fully self-differentiating.

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 note that untracked files appear as additions and that a newly created file 'is verifiable here' implies a use case, but there is no explicit guidance on when to choose git_diff over git_status, git_show, or reading a file directly. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile is fully covered without the description. The description adds only that results are 'bounded' (the max_count cap of 100) and structured, which is modest extra context beyond the 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?

A single front-loaded sentence with no padding, which is appropriately sized for the tool. It loses a point only because 'bounded structured metadata' spends words without conveying real 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?

An output schema exists, so return values need not be explained. However, with four undocumented parameters at 0% schema coverage and no usage context against four sibling git tools, the description is too thin for a multi-parameter history query.

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

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

Schema description coverage is 0% for four parameters, so the description must carry the load, and it does not: ref, path, and skip are never mentioned or explained, and only 'recent'/'bounded' loosely gestures at max_count and skip. No format, default, or range semantics are added.

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 verb ('Return') and resource ('git commits'), which distinguishes it at a high level from git_status/git_diff. But 'bounded structured metadata' is vague filler that does not say what a commit record actually contains, and nothing separates it from git_show (single commit) or git_blame.

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

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

No when-to-use guidance and no reference to alternatives, despite four closely related git siblings (git_show, git_blame, git_diff, git_status). An agent must infer from the name alone that this returns a history listing rather than a single commit or a diff.

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 behavior. The description adds that output is bounded, which is useful context beyond annotations, but it does not explain truncation behavior, default diff inclusion, or what happens when max_bytes is exceeded.

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

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

The description is a single front-loaded sentence with no wasted words. However, for a six-parameter tool, it is arguably too terse to be considered fully well-structured.

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

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

An output schema exists, so return values need not be explained by the description. But with six parameters and 0% schema description coverage, the description is incomplete: it gives no parameter semantics, no usage guidance, and no behavioral detail beyond the single word 'bounded'.

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

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

Schema description coverage is 0% across six parameters, so the description must carry the burden. It hints at a revision and bounded output, but leaves path, paths, include_diff, context_lines, and the max_bytes limits undocumented.

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 says it returns git show output for a revision, which is a specific operation but largely restates the tool name and title. It does not distinguish itself from siblings like git_diff, git_log, or git_blame, leaving the agent to infer when git_show is the right choice.

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 guidance about when to use this tool versus alternatives such as git_diff, git_log, or git_blame. The description provides no context, exclusions, or workflow cues beyond the operation itself.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only 'working tree status' scoping and nothing about pagination via max_entries or how untracked files appear, so it contributes modestly beyond structured data.

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 concise sentence with the resource front-loaded and no filler. 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?

An output schema exists so return format needn't be explained, and annotations carry the safety semantics. The remaining gap is behavioral detail on parameters (truncation limits, untracked-file inclusion) and lack of routing guidance, leaving the definition only just adequate for a 3-param 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% and the description mentions none of the three parameters (path, max_entries, include_untracked). The parameter names and defaults in the JSON schema hint at meaning, but the description does nothing to compensate for the coverage gap, notably the truncation behavior implied by max_entries.

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 ('Return') and resource ('git working tree status') scoped to the workspace. It is readily distinguishable from siblings like git_diff, git_log and git_show, though it does not name or contrast them 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?

No guidance on when to use this versus git_diff, git_log, or git_show, and no prerequisites (e.g., that the path must be a git repo). Usage is only implied by the name and subject matter.

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. The description adds that the command must be server-managed and shows a KILL example, but does not explain escalation semantics (TERM vs KILL vs INT), what happens to buffered output, or the relationship between wait_ms and kill_wait_ms.

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

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

Two short sentences, with the purpose front-loaded and the example placed after it. The JSON example partially restates the schema but is compact and does not pad the text.

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 7-parameter destructive mutation with an output schema and 0% schema coverage, the description covers only 2 parameters and omits the wait_ms vs kill_wait_ms distinction, signal escalation behavior, and output verbosity controls. An agent cannot invoke it fully correctly from this text alone.

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 7 parameters, and the description only touches command_id and signal (via example). The five remaining parameters (wait_ms, kill_wait_ms, verbosity, preview_bytes, max_output_bytes) are undocumented anywhere, leaving a significant compensation 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?

The description states a specific verb (Terminate) plus a scoped resource (server-managed command) keyed by command_id, which distinguishes it from process-spawning siblings like exec_command and from write_stdin/read_output. It never names an alternative sibling explicitly, so it falls short of full 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?

Usage is only implied by 'Terminate a server-managed command.' There is no guidance on when to kill versus send input via write_stdin, no mention of prerequisites, and no conditions or exclusions.

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

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds only the workspace confinement, while omitting traversal behavior, entry limits, hidden-file handling, and other operational details beyond what annotations cover.

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?

It is a single front-loaded sentence with no wasted words. The structure is clean, though the extreme brevity borders on under-specification for 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?

For a tool with 7 optional parameters, 0% schema descriptions, and an overlapping sibling (list_files), the description is incomplete. Output schema and annotations cover returns and safety, but invocation guidance and parameter meaning remain largely absent.

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

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

The schema has 0% description coverage across 7 parameters, and the description mentions none of their meanings, defaults, or formats. It does not compensate for the schema documentation gap at all.

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 ('directory entries') and scope ('inside the configured workspace'). It is clear, but it does not distinguish this tool from the sibling list_files, so sibling differentiation is missing.

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

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

Provides no when-to-use guidance, no alternatives, and no exclusions. The agent must infer usage entirely from the tool name and the vague workspace scope.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context beyond them — nothing about truncation via max_results, default exclusion of hidden/ignored files, or result 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 filler and no repetition of the title. It is efficient, though the brevity reflects under-specification rather than disciplined editing.

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

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

An output schema exists so return values need not be described, but with 8 undocumented parameters, zero schema coverage, and no alternatives named against list_dir/search_text, the definition is not complete enough 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 0% across 8 parameters, so the description carries the full explanatory burden and fails it. 'Glob filters' gestures at glob/patterns/exclude_patterns but says nothing about path, sort, max_results, include_hidden, or include_ignored.

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

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

Specific verb+resource ('List workspace files') plus a mechanism hint ('using glob filters'), which is more than a tautology. However, it never distinguishes itself from closely related siblings such as list_dir or search_text, so an agent cannot route between them from the description alone.

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

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

No when-to-use guidance, no prerequisites, and no mention of the obvious alternatives (list_dir for directory listing, search_text for content search). The agent must infer the use case entirely from the name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the constraint that reading occurs 'inside the configured workspace' and the file must be UTF-8 text, which is useful context beyond annotations, but it does not disclose error behavior, slice behavior, or performance characteristics.

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 concise sentence that front-loads the action and resource. 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?

With an output schema present, return values need not be explained, but the lack of parameter documentation and usage guidance leaves the definition incomplete for a tool with six parameters. It covers the core operation but misses operational details.

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 should compensate but does not. It only mentions 'slice' suggesting line-range parameters, but provides no details on the six parameters (path, encoding, start_line, end_line, max_bytes, max_lines), leaving them semantically opaque despite clear names.

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 ('Read') and resource ('UTF-8 text file slice'), making the core operation unambiguous. However, it doesn't explicitly differentiate from sibling tools like read_output or view_image, which also involve reading content.

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 is provided on when to use this tool versus alternatives such as list_files or search_text. The description only states what it does, leaving agents to infer appropriate contexts.

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 and destructiveHint=false, so the safety profile is covered. The description then adds genuinely useful behavior: the head-plus-rolling-tail retention model and the fact that middle bytes may be evicted and surfaced as evicted_gap_bytes. It stops short of describing pagination progression or error behavior for a stale ref.

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 dense sentences with no filler: purpose and provenance first, retention semantics second, a concrete invocation example last. Everything is front-loaded and each 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?

An output schema exists, so return values needn't be enumerated, and the description still flags the notable field evicted_gap_bytes. With 4 params at 0% schema coverage, a little more on the stream parameter and limit bounds would make it fully self-sufficient for invocation.

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

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

Schema description coverage is 0%, so the description carries the burden, and it does reasonably: the example maps offset and limit to concrete values, output_ref is tied to exec_command/write_stdin, and the stdout/stderr stream distinction is implied. The `stream` enum and limit bounds (1..1048576) are still only discoverable from the schema.

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

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

States a specific verb (Read) plus the exact resource (retained command output) and pins the provenance to output_ref values produced by exec_command/write_stdin. That distinguishes it cleanly from siblings like read_file or git_show, which read different sources.

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 tells the agent when this tool applies: retrieving retained output using a ref returned by exec_command or write_stdin. The trigger condition is explicit, though it never states when not to use it (e.g., versus re-running a command or reading a file on disk).

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 safety is covered. The description adds only the UTF-8 encoding constraint and regex capability; it says nothing about result truncation, preview byte limits, or ordering behavior that would be useful 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?

A single front-loaded sentence with zero filler, and the core verb and scope lead. It is efficient but arguably under-specified rather than tight, which is more a completeness issue than a structure flaw.

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 10 parameters, 0% description coverage, and no annotation gaps on safety, the description should explain the filtering and output-shaping knobs, but it does not. An output schema exists so return shape needn't be described, yet the input contract remains largely opaque.

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 10 parameters, so the description carries the full burden and largely fails: it only loosely gestures at 'text or regex' (query/regex). Globs, path default, max_results, context_lines, and preview byte limits are undocumented anywhere.

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) and resource (UTF-8 workspace files) plus the match modes (text or regex), so an agent immediately knows the operation. No sibling tool overlaps this capability, so explicit differentiation isn't needed, but the description doesn't note scope limits relative to read_file/list_files.

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 mention of alternatives (e.g., read_file for a single file, list_files for names), and no prerequisites or exclusions. The agent must infer usage entirely from the one-line purpose.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety and determinism profile is fully covered by structured data. The description adds the scope of returned metadata (that auth and policy details are included), which is useful but is content rather than behavior; it says nothing about freshness, caching, or auth requirements.

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

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

A single front-loaded sentence with no preamble and no filler. The verb and the payload categories are stated immediately, which is the ideal shape for a zero-argument informational 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?

An output schema exists, so the description is not obligated to describe return values, and the enumerated categories give a useful preview of the payload. Zero parameters means no argument documentation is required. The only real omission is guidance on when this tool should be preferred over 'workspace_guide'.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There are no arguments whose semantics need explaining, and the schema confirms an empty, additionalProperties=false object.

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 ('Return') and enumerates the resource domains covered: server, workspace, project-context, auth, policy, and fixed-tool metadata. This is concrete enough that an agent knows exactly what class of information it retrieves. No sibling tool covers the same ground, so explicit differentiation isn't needed.

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 indication of when to call this tool, in what situation it is useful, or how it relates to the sibling 'workspace_guide', which by name appears to touch overlapping workspace context. The agent receives no routing guidance at all, only a content list.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and closed-world behavior, so the safety profile is clear. The description adds useful context by stating the return type is MCP image content, but it does not disclose resizing behavior, size limits, or what happens when an image exceeds max_bytes. Given the strong annotation coverage, 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 front-loaded sentence with no filler. Every word earns its place, and the purpose is stated immediately.

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

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

The output schema exists, so return values need not be explained, and annotations cover the safety profile. However, for a tool with four optional parameters that control resizing and size limits, the description omits all parameter behavior and gives no usage guidance, leaving meaningful gaps for an agent trying to invoke it correctly.

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

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

Schema description coverage is 0% for 5 parameters, and the description does not mention any parameter by name or explain max_bytes, max_width, max_height, or auto_resize. The only implied semantics come from the phrase 'workspace image,' which minimally contextualizes path but leaves the four optional constraints completely undocumented.

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 (Return) and resource (workspace image) and names the output format (MCP image content), which distinguishes it from text-returning siblings like read_file. It does not explicitly name or rule out alternatives, so a perfect 5 is not warranted.

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 use this tool versus read_file or other siblings, nor does it mention any preconditions. Usage is only implied by the tool name and the word 'image'.

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

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

Annotations already cover read-only, idempotent, non-destructive, closed-world semantics, so the bar is low. The description still adds real value: it warns that the tool grants no execution or permission, and that returned metadata must be followed by reading the full files before acting — behavior not derivable from the annotations.

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

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

Two tight sentences, zero filler, with the core action stated first and the caveat ('no execution or permission grant') front-loaded in the same breath. Every clause earns its place.

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

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

An output schema exists, so return-value explanation is not required. The description covers what the tool produces (instructions/skill metadata), the required follow-up action, and its safety posture; only the relative ranking against sibling discovery tools (search_text, list_dir) is 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?

Single optional 'path' parameter with 100% schema description coverage, so the schema already documents purpose, type, and default. The description's 'for a target path' merely restates it without adding format or path-resolution detail; baseline 3 applies.

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

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

States a specific verb ('Find') and a specific resource ('applicable repository instructions and skill metadata') scoped to a target path. It is distinguishable from read_file/list_dir/search_text by being about discovering rules/skills metadata rather than raw content, though it never names those siblings as alternatives.

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?

'Read the selected full files before acting' implies a two-step workflow (this tool locates, another read retrieves content), which is useful. However, there is no explicit statement of when to prefer this over search_text or list_dir, or what conditions make it inapplicable.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description usefully adds the behavioral rule that empty chars waits and non-empty chars writes to stdin, plus a concrete call example, but omits blocking semantics of yield_time_ms and any note on side effects of writing.

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

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

Three short sentences, front-loaded with the core mechanism and followed by an immediately usable JSON example. Dense and waste-free, though the example parameter could be trimmed.

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

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

An output schema exists, so return values need not be explained. However, with 6 parameters at 0% schema coverage for a non-idempotent write tool, the description leaves too much of the parameter surface unexplained to be 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% across 6 parameters, so the description carries the full burden. It explains chars (empty vs non-empty) and hints at yield_time_ms via the example, but leaves verbosity, preview_bytes, and max_output_bytes 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?

States a specific verb and resource: interact with or poll a running command identified by command_id. It conveys the dual purpose (waiting vs writing), but never names the sibling read_output, so an agent must infer which of the two retrieval tools to pick.

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 'running command' and the empty-vs-non-empty chars rule, which tells the agent when to wait versus when to send input. It gives no explicit guidance on when to prefer this over read_output or how long 'wait' actually blocks.

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