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 the notable behavior that both the input scope and the output are 'bounded,' implying result truncation, but it never explains the truncation rule, error cases (missing/unreadable file), or performance characteristics on large intervals.

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, efficiently pairing the operation with its result. It is terse to the point of under-specifying, but nothing in it 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?

No output schema and no annotations beyond the safety hints, so the description must explain return shape, bounding/truncation semantics, and parameter behavior — none of which it does. For a 5-parameter file-comparison tool this leaves the agent guessing.

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

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

Schema description coverage is 0% across 5 parameters, so the description carries the burden. 'Bounded intervals' weakly alludes to offset/length and 'bounded difference ranges' hints at max_ranges, but path_a/path_b, offset=0, length=null, and the max_ranges=100 default/truncation behavior are all left 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+resource ('Compare bounded disk-file intervals') and names the return artifact ('bounded difference ranges'), which clearly separates it from siblings like binary_read, binary_inspect, and binary_patch_preview. It does not explicitly name a sibling, 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 statement of when to use this versus binary_patch_preview/binary_patch_apply or binary_inspect, no prerequisites (e.g. whether the two files must be the same size), and no exclusions. The agent must infer the use case from the name alone.

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

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

Annotations already declare read-only safety and a closed-world scope. The description adds useful constraints ('allowed ordinary disk file') and optional hash streaming, but does not state return format, error behavior, size limits, or what 'allowed' entails.

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

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

The description is a single front-loaded sentence with no wasted words. It stays focused on the core operation and optional behavior.

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 0% schema description coverage, the one-sentence description leaves too much unspecified: return shape, hash format, path rules, and sibling differentiation. Annotations cover read-only safety but not enough to make this definition complete for an inspection 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%, so the description must compensate. It alludes to the path parameter ('disk file') and the hashes parameter ('requested hashes'), but gives no format, accepted algorithms, or path constraints, leaving both parameters largely unspecified.

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

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

The description names a specific verb ('Inspect') and resource ('allowed ordinary disk file'), plus an optional behavior around hashes. It is clear what the tool does, but it does not differentiate itself from siblings like binary_read or binary_search.

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 on when to use this tool versus alternatives, nor any when-not conditions. The phrase 'optionally streaming requested hashes' hints at a use case but does not route the agent among siblings such as binary_read, binary_search, or binary_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=false, destructiveHint=false and idempotentHint=false; the description usefully confirms the non-destructive behavior by stating the original is preserved and output is written elsewhere. It does not explain what happens on an expected_hex mismatch, whether the preview token expires, or anything about atomicity/partial writes.

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

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

A single tight sentence with the outcome up front and no filler. It is arguably too terse given six undocumented parameters, but nothing in the sentence is wasted.

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

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

For a six-parameter mutation tool with no output schema and zero schema documentation, the description leaves the caller without format for hex values, offset interpretation, and token/expected-value failure semantics. It should do considerably more.

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 required parameters, so the description carries the full burden and mostly fails: path, offset, expected_hex, replacement_hex and preview_token are never explained. Only output_path is obliquely covered by 'new output file'.

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 (apply) and resource (a previewed disk replacement) and adds the key outcome detail that output goes to a new file while the original is preserved. It does not name the preview sibling it depends on, but 'previewed' plus 'disk replacement' distinguishes it reasonably from editor_patch_apply.

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 word 'previewed' implies a prerequisite call to binary_patch_preview, which is useful, but the usage condition is only implied. There is no explicit when-to-use/when-not guidance or named 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?

Annotation readOnlyHint=true is consistent with 'preview'/'verify'. Beyond the annotation, the description discloses the non-obvious state coupling: the tool emits a token that a later copy-on-write apply depends on, which is genuine context an agent would otherwise miss. It stops short of describing failure behavior when expected bytes don't match.

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

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

A single tight sentence with no filler, and the verification/preview action is front-loaded ahead of the token detail. It is arguably too compressed given four undocumented parameters, but nothing in it is wasted.

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

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

With no output schema, no annotations covering inputs, and 0% schema description coverage on four required parameters, the description should explain parameter meaning, hex format, offset units, and the mismatch outcome. It supplies only the token/apply lifecycle, leaving the bulk of invocation-relevant context missing.

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

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

Schema description coverage is 0% for all four parameters, so the description carries the full burden and largely fails it. 'Verify disk bytes and preview replacement' loosely gestures at expected_hex vs replacement_hex, but path and offset are never explained, and no hex format or offset-base conventions 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 specific verbs and resource: 'Verify disk bytes and preview replacement' plus the copy-on-write apply that consumes the token. It implicitly distinguishes itself from binary_patch_apply through the preview/apply pairing, though it never names the sibling outright.

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?

'Retain its token for a copy-on-write apply' implies the preview-then-apply workflow, so the intended usage is inferable. There is no explicit statement of when NOT to use it, no mention of what happens on a byte mismatch, and no direct pointer to binary_patch_apply as the follow-up call.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavior beyond that: reads are bounded, disk-sourced, and byte-offset addressed rather than buffer/line-based. It stops short of disclosing what happens on out-of-range offsets, any max length limit, or how the text_preview flag alters output.

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

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

A single front-loaded sentence with a semicolon-delimited exclusion clause; no filler, no restatement of the tool name. Every clause carries information the caller needs.

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

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

No output schema exists, but for a read-only byte fetch the description needn't explain return format. The real gap is invocation correctness: text_preview is undocumented anywhere, so an agent cannot know whether it gets raw bytes or a decoded preview, and length/offset edge behavior is unstated.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It clarifies that offset is zero-based and that length bounds the read, and 'from disk' implies path semantics, but the fourth parameter (text_preview, default true) is completely unexplained in both schema and description, and length limits/path format are left unspecified.

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

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

States a specific verb+resource ('Read bounded bytes from disk') with a precise addressing mode ('zero-based byte offset'), and explicitly contrasts scope with a sibling capability ('never read an editor buffer'). An agent can tell this apart from editor_read without opening either schema.

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

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

The clause 'never read an editor buffer' functions as a when-not rule, steering the agent to the editor_* tools for buffer content. However, it never names the alternative tool or explains when to prefer binary_read over binary_search or binary_inspect, so the routing is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral detail — that overlapping matches are included — but says nothing about result ordering, the max_results cap, or what happens when length is omitted.

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 search scope comes first and the matching behavior second. It is efficient, though its brevity is partly a symptom of 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?

For a five-parameter tool with no output schema and no parameter documentation, the description leaves too much unstated: return format (offsets? match counts?), result limiting, and the required hex encoding of pattern_hex. An agent could invoke it, but only by guessing at the semantics.

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 the description carries the full burden. It hints at offset/length via 'bounded disk interval' and at pattern_hex via 'hex bytes', but leaves length semantics, the max_results default of 100, and the hex string format entirely 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) and resource (a bounded disk interval for hex bytes), which is clearly distinct from siblings like binary_read, binary_inspect, and binary_diff. However, it never names or contrasts those siblings, so differentiation is inferred rather than stated.

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

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

The description gives no when-to-use guidance, no prerequisites, and no indication of when binary_read or binary_inspect would be preferable. An agent must guess from the name alone whether this is the right tool for a given disk-search task.

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 a genuinely useful behavioral guarantee beyond that: the read does not alter the current selection, which readOnlyHint alone does not promise. No return format or staleness/caching behavior is described.

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 verb and returned fields come first and the non-side-effect guarantee is appended compactly. Every clause earns its place.

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

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

For a zero-parameter read tool with no output schema, listing the returned fields (identity, dirty state, selection) makes the definition sufficient to call correctly. It stops short of distinguishing this from the similarly named editor_status, which an agent may weigh against it.

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 is nothing for the description to disambiguate, and schema coverage is 100%.

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 enumerates the resource fields returned: active buffer identity, dirty state, and selection. The phrase 'without changing selection' implicitly contrasts it with editor_select, but no sibling is named explicitly, so it falls just short of 5.

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

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

Usage is only implied: an agent can infer this is for non-mutating inspection that must not disturb the cursor. There is no explicit when-to-use, no statement of when to prefer editor_status or editor_read instead, and no preconditions given.

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

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

Annotations declare readOnlyHint=false, asserting the tool mutates its environment, while the description explicitly says writes are disabled and only an error code is returned, i.e. the tool is effectively read-only. This directly contradicts the structured annotation, so it scores 1 despite the useful disclosure of the disabled state.

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

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

A single, front-loaded sentence with no filler. It is efficient, though the colon construction compresses the error code and rationale into one clause that could be marginally clearer.

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 stubbed tool that only returns an unsupported-capability signal, communicating that fact is the main requirement, and no output schema or parameter docs are needed to act on it. The missing piece is any guidance on what the agent should do instead of applying the patch.

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?

All five required parameters (buffer_id, offset, expected_hex, replacement_hex, preview_token) have 0% schema description coverage, and the description supplies no meaning for any of them. The only oblique hint is that they relate to an unsaved-buffer write, which is far short of compensating for the 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 concrete action (report CAPABILITY_UNSUPPORTED) and the specific resource it concerns (atomic unsaved-buffer writes), so an agent understands this call is a no-op error report rather than a patch application. It does not, however, name or exclude siblings like editor_patch_preview or binary_patch_apply, so differentiation is left implicit.

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 tool is unusable ('disabled this release') but never states when to reach for it versus editor_patch_preview/binary_patch_apply, nor what the agent should do instead. There is no explicit when-to-use, when-not-to-use, or alternative routing.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds non-obvious behavior beyond that: the result's can_apply flag is false and no mutation token is issued, telling the agent this call cannot be chained into a write. That is genuinely useful state/auth context not present in the structured fields, though return shape and pagination/scope behavior remain unstated.

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

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

A single short clause with no filler; the read-only guarantee is front-loaded. It is efficient, though the extreme brevity is under-specification rather than true conciseness, which keeps it from a 5.

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 four required, completely undocumented parameters, no output schema, and a write-adjacent preview role, the description is far too thin. It never explains the argument contract (what expected_hex/replacement_hex must contain) nor what the preview returns beyond can_apply. Annotations cover the safety profile, but the operational contract is missing.

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

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

Schema description coverage is 0% for all four required parameters (buffer_id, offset, expected_hex, replacement_hex), so the description carries the full burden and provides nothing. It gives no hint about offset semantics, hex encoding expectations, or what buffer_id identifies. An agent cannot construct a valid call from the description plus schema alone.

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

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

The description gives a verb pair and an object ("Verify and preview live bytes"), so the agent can infer this is a dry-run check rather than a mutation. However, it never says what is being verified against (the expected_hex parameter) and offers no differentiation from the near-identical sibling binary_patch_preview, or from the paired editor_patch_apply. The purpose is implied rather than stated.

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

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

The clause "can_apply is false and no mutation token is issued" implies a preview-before-apply workflow and signals this call cannot be the one that commits a change. But no alternative is named explicitly (editor_patch_apply, binary_patch_preview), and there is no stated condition for choosing this tool over its siblings. Usage is only 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 cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds genuinely non-obvious behavioral context: the read targets the live buffer state including unsaved bytes and will not silently fall back to disk. It does not disclose error behavior for a missing buffer_id or an out-of-range offset/length, so it is not fully transparent.

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 with the highest-value constraint front-loaded. No filler, no restatement of the tool name, and the qualifier 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?

With no output schema and 0% parameter coverage, the description carries the full burden and leaves major gaps: return format (raw bytes vs encoded string), units for offset/length, behavior when the range exceeds the buffer, and any auth or locking requirements for reading a live buffer.

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?

All three required parameters have 0% schema description coverage and the description says nothing about them. Critically, it never clarifies whether offset and length are byte-based or character-based, which is exactly the ambiguity an agent needs resolved before calling a buffer read.

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 a precisely scoped resource (the intended live in-memory buffer), plus a key qualifier ('including unsaved bytes; no disk fallback') that separates it from disk-oriented siblings like binary_read. It stops short of naming the sibling it competes with, so the differentiation is inferable rather than explicit.

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

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

'No disk fallback' implies when this tool is appropriate (you want the editor's in-memory state rather than persisted bytes), but there is no explicit when-to-use guidance, no named alternative, and no stated precondition that buffer_id must come from editor_status or editor_context.

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

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

Annotations already declare non-read-only, non-destructive, non-idempotent. The description adds meaningful context with 'intended live buffer' (targets live content, not a scratch copy) and 'configured trusted root' (a security/sandbox constraint). It still omits what the template execution can change, error behavior, or reversibility.

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

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

A single tight sentence with the key scoping constraints front-loaded. No wasted words, though its brevity leaves gaps elsewhere.

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

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

For a mutating tool with no output schema and zero parameter documentation, one sentence is not enough. It should say what template execution produces or modifies, expected failure modes, and how the trusted-root resolution works.

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 both required parameters. The description loosely implies buffer_id ('intended live buffer') and template_path ('from a configured trusted root'), but gives no format, path resolution rules, or ID semantics to compensate for the undocumented 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 (Run) and resource (.bt template), scoped to a configured trusted root and the intended live buffer. This distinguishes it from siblings like editor_patch_apply or editor_read, though what executing a template actually does to the buffer remains implicit.

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 instead of editor_patch_apply or other editor mutation tools. The 'trusted root' constraint hints at a precondition but is not framed as usage guidance or an exclusion.

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, so the agent knows this mutates editor state harmlessly and non-repeatably. The description adds that the target buffer must be 'live' and that offsets are zero-based byte positions, but says nothing about failure behavior for a stale buffer or what the selection actually affects.

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 and scope, with no filler or restatement of the tool name. Every clause contributes semantics.

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 mutation tool with no output schema and no annotation coverage of return or error behavior, the description is only minimally adequate. It does not explain what a completed selection produces or how failures surface, though annotations cover the safety profile.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does partially: buffer_id identifies the live buffer, offset is a zero-based byte position, and the range has a length. It still leaves units/edge cases (zero-length selection, out-of-bounds offsets, whether length is bytes or characters) 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 concrete verb pair (select/navigate) and the resource (a zero-based byte range), plus the scoping qualifier 'live buffer'. It is distinguishable from editor_read (reading content) and the patch tools (mutating content), though it never names a sibling 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?

No when-to-use or when-not-to-use guidance, and no routing to alternatives such as editor_read or editor_context. The only implied precondition is 'explicitly identified live buffer', which is a constraint on the input, not usage context.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds that the tool checks for an existing editor/bridge, which is real context, but it says nothing about what happens when no editor is found or how the capability report is shaped (and there is no output schema to fall back on).

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

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

A single tight sentence with the action and the result front-loaded. No filler, no redundancy.

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

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

For a no-parameter probe with no output schema, the description should at least sketch the return payload (e.g., attachment state, capabilities list) and the negative case. 'Report supported live capabilities' gestures at it but leaves the agent guessing about the response shape.

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

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

The tool takes zero parameters, so there is nothing to document and the baseline of 4 applies. The description correctly implies a no-argument probe.

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

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

States a concrete verb pair (detect, report) and a specific resource (editor/bridge plus its live capabilities). It is distinguishable from editor_read/editor_patch_* and from the generic server_status, though it does not explicitly name which sibling it is not.

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 phrasing implies this is a discovery/preflight call before using the other editor_* tools, but there is no explicit "use this when…" or comparison against server_status. Usage must be inferred from the name and the word 'detect'.

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 goes beyond that by enumerating what the report contains (availability, configured limits, local path boundaries), which is meaningful behavioral context for a diagnostics call, though it says nothing about return format.

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 most important information (that this reports availability) comes first. Every word earns its place.

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

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

With no parameters and no output schema, the description carries the burden of indicating what comes back, and it does so by listing the three reported categories. It is nearly complete, only lacking any note on output shape or when the result would be stale/refreshable.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain; the baseline for a parameterless tool applies. The description correctly refrains from inventing inputs.

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

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

States a specific verb ('Report') and a concrete set of resources: backend availability, configured limits, and local path boundaries. The scope is clear, but it does not differentiate itself from the sibling editor_status, which likely reports an overlapping status domain.

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 statement or named alternative. Usage is only implied by the content ('check this to learn backend availability and path boundaries'), which is adequate but leaves the agent to infer when this is preferable to editor_status.

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