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

With no annotations present, the description takes on the full disclosure burden and handles it well: it states that a .reapat_bak backup is created automatically, that a mismatched old-byte aborts the whole batch, that each byte is read back and verified after writing, and that a failure triggers an automatic rollback from the backup. It does not cover file locking, permissions, or the response format, which keeps it from a 5.

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

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

The purpose is front-loaded in the first line, followed by a clear patch-record example and a short bullet list of invariants. Every line adds information an agent needs, with no restatement of the name or title.

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

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

For a 5-parameter mutation tool with no annotations and no output schema, the description covers the critical behaviors (backup, atomic rejection, readback verification, rollback, preview mode) that an agent needs before invoking it. Gaps remain around image_base semantics and what the tool returns on success or partial failure.

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, and it explains the patches array structure (offset/old/new), accepts 0x or va0x offsets, supports '?' byte wildcards in old, and defines the force and dry_run flags precisely. file_path and image_base remain undocumented, and image_base's interaction with va0x offsets is left unstated.

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 definition opens with a specific verb and resource ('打补丁（写回原文件）'), making clear that this tool writes the patched bytes back to the target file rather than verifying or restoring it. The 'write back to the original file' phrasing distinguishes it from siblings such as rea_patch_verify and rea_patch_restore, though neither sibling is named explicitly.

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

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

Usage is implied through the dry_run and force flags, and the atomic-rejection semantics hint at when a preview run is warranted. However, the description never states when to reach for this tool versus rea_patch_verify or rea_patch_restore, nor does it prescribe a verify-after-apply workflow.

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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that the operation is read-only and that offset accepts a 0x hexadecimal prefix, but it omits output format, length behavior, error conditions, and any limits on how many bytes can be dumped.

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, stating the core action and the most important parameter format 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?

For a tool with no annotations, no output schema, and 0% schema description coverage, the definition is too sparse. It does not explain the return value (which is important without an output schema), the default length of 16, or how length constrains the dump.

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 for all three parameters. It only addresses offset by mentioning 0x-prefix hexadecimal support, which is useful but also potentially conflicts with the schema's integer type; file_path and length are not explained 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?

The description clearly states a specific operation: read-only viewing of bytes at a file offset. It identifies the resource (file bytes at an offset) and the read-only nature, but does not explicitly differentiate this from sibling tools such as rea_patch_text_view or rea_patch_text_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?

The only usage signal is '只读查看' (read-only view), which implies safe inspection but gives no guidance on when to use this tool versus text_view, text_search, or other dump/inspection siblings. There are no exclusions or alternative conditions provided.

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?

With no annotations provided, the description carries the full behavioral burden and does disclose the key trait: this is a read-only, non-mutating inspection. It also names what is returned, so an agent knows no changes occur. It stops short of stating failure behavior for invalid or non-PE paths.

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

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

A single front-loaded clause: read-only qualifier first, then the resource, then the returned fields. No wasted words.

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

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

For a one-parameter read tool with no output schema, the description adequately signals the return contents and safety profile. Only minor gaps remain (error cases, path expectations).

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?

There is one parameter (file_path) at 0% schema description coverage, and the description adds no semantics for it. The parameter is largely self-explanatory, but nothing confirms it should be a local filesystem path versus a PE-relative path.

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-only view) and resource (PE file overview) and enumerates the returned content (image base, section table, size, SHA-256). It implicitly separates itself from the mutation siblings (apply/restore/patch), though it never names an alternative 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?

The '只读' qualifier implies this is the inspection step before patching, but there is no explicit when-to-use rule or pointer to a sibling such as rea_patch_sha256 for hash-only needs. Usage is inferable but not 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?

No annotations exist, so the description carries the full disclosure burden. It does usefully disclose that force overwrites the current file, which is the key destructive nuance, but says nothing about what happens if no .reapat_bak exists, whether the current file is preserved first, or what the tool returns.

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, both earning their place, with the restore action front-loaded before the force caveat. It is efficient, though arguably too terse for a mutation tool with zero schema documentation.

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

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

A destructive mutation tool with no annotations, no output schema, and 0% parameter documentation needs more: backup-absence behavior, file_path meaning, and routing against rea_patch_text_restore are all missing.

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

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

Schema coverage is 0%, so the description must compensate. It explains force well (overwrites the current file), but file_path is ambiguous — it is unclear whether it names the original file whose backup is restored or the backup itself. Half the parameters are effectively 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 (restore) and resource (the original file, sourced from the .reapat_bak backup), so the agent knows exactly what it does. It does not differentiate itself from the near-identical sibling rea_patch_text_restore, leaving the agent to infer which restore applies to which artifact.

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 restore versus rea_patch_apply/verify, or versus the text_restore sibling. The implied usage (undo an applied patch) is only inferable from the name, not 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?

With no annotations provided, the description carries the burden and does disclose the key behavioral trait '只读' (read-only, no file mutation). However, it says nothing about error behavior (e.g., missing file), or the format of the computed hash, leaving meaningful behavioral gaps.

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

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

A single short sentence, front-loaded with the read-only trait and the core operation. Zero waste, though the terseness borders on under-specification.

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

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

For a simple one-parameter read-only tool with no output schema, the description conveys the core operation, but omits what is returned (the hash string/format) and any parameter or error handling detail. Adequate but with clear gaps.

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

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

Schema coverage is 0%, so the description must compensate. It only implies that '文件' (file) is the input being hashed, without clarifying the format, path conventions, or whether directories are accepted. This is marginal guidance over an undocumented file_path parameter.

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

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

The description states a specific verb+resource ('计算文件 SHA-256' / compute file SHA-256), which is unambiguous. It doesn't explicitly contrast with siblings, but no sibling performs hashing, so the purpose is inherently distinguishable. Slightly weaker because it doesn't name what 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?

No explicit when-to-use guidance or alternatives are provided. The '只读' qualifier hints at a non-mutating use case, but the agent is left to infer when hashing is appropriate versus the other rea_patch_* tools.

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

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

With no annotations, the description carries the full burden and does so well: it discloses automatic backup to <file>.reapat_txt_bak, in-memory simulation of all ops with whole-batch rejection on any failure, post-write readback verification with rollback from backup, and dry_run preview semantics. It omits what `force` overrides and any permission/encoding caveats, which keeps it from a 5.

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

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

The description is front-loaded with the one-line purpose, then the op table, then the safety-net paragraph, with no filler. The op table is long but every line corresponds to a genuine schema gap, so the length is earned.

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

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

For a mutation tool with no annotations and no output schema, the description covers the essentials an agent needs: atomicity, backup, rollback, verification, and preview. The remaining gaps (`force`, `encoding`, and what a successful call reports back) are minor but real.

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, and it does for the hardest part: the `ops` array items are untyped in the schema, and the description supplies the full op vocabulary (replace/regex/line/json/ini) with field meanings including count and occurrence. Two of five parameters, `force` and `encoding`, get no explanation at all, so it falls short of complete.

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

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

The opening line names a specific verb and resource: patch text/code files, and adds scope ('多语言通用'). It implicitly separates this tool from the binary-oriented sibling rea_patch_apply by specifying text/code files, but it never names a sibling explicitly, so an agent must infer the split.

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 explains how each op type behaves and that dry_run only previews, which implies usage for the common cases. However, it never states when to choose this tool over rea_patch_text_search, rea_patch_text_verify, or rea_patch_apply, nor when not to use it (e.g., binary files).

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?

With no annotations, the description does flag the key destructive trait: it overwrites the current file, and `force` controls that overwrite. It is silent on what happens when force=false and the target exists (refuse? skip?), whether the backup is consumed after restore, and whether the backup must exist.

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, no waste, with the backup-suffix scoping stated before the overwrite condition. Well front-loaded for such a small 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?

No annotations and no output schema, so the description is the sole behavioral source — and it omits error/precondition behavior (missing backup, existing target without force) and whether the restore is reversible. Adequate for the happy path, thin for a file-mutating operation.

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

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

Schema description coverage is 0%, so the description must carry the params — and it largely does: `file_path` is the original file whose '.reapat_txt_bak' companion is read, and `force` overwrites the current file. Only the exact force=false behavior is left ambiguous.

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

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

Names a specific verb+resource: restoring the original file from a '<file>.reapat_txt_bak' text backup. The backup-suffix convention separates it from the generic sibling rea_patch_restore, though the description never says so 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?

States the mechanics but never when to use this instead of rea_patch_restore, rea_patch_restore, or rea_patch_text_apply. An agent must infer the recovery-after-text-apply workflow from the tool name and backup suffix 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?

With no annotations, the description carries the full burden; it does usefully declare read-only semantics and that the result is matched line numbers. However, it omits behavior an agent needs: whether encoding affects matching, whether results are truncated, and whether matching is case-sensitive or multiline.

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 read-only constraint and ends with the return value. 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?

For a tool with no annotations, no output schema, and 0% schema description coverage across four parameters, the description is too thin. It should explain the regex toggle and encoding semantics, and at least hint at result limits or match formatting.

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. The description alludes to pattern (关键字/正则) and file_path (文本/代码文件), but leaves the regex boolean and especially the encoding parameter unexplained 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?

The description names a specific verb (搜索定位 = search/locate) and resource (文本/代码文件 = text/code files) and states the return shape (命中行号 = matched line numbers). It is clearly distinguishable from mutation siblings like rea_patch_text_apply or rea_patch_text_restore, though it doesn't explicitly contrast with rea_patch_text_view.

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 text states the operation is read-only (只读), which sets usage context, but never says when to choose this over rea_patch_text_view or how it relates to the apply/verify/restore siblings. No exclusions or prerequisites are 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?

No annotations are provided, so the description carries the full disclosure burden. It does state the operation is read-only, which is useful. But it says nothing about what happens when the assertion fails (error thrown vs. boolean returned), how encoding is handled, or whether regex mode changes matching semantics—all critical for a verify tool.

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

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

A single front-loaded sentence with no filler. It is appropriately sized for what it covers, though the size itself reflects the under-specification rather than deliberate economy.

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 5-parameter tool with no annotations and no output schema, one terse sentence is insufficient. The agent cannot determine result semantics (return value vs. exception on failed verification), encoding behavior, or the interaction between contains and not_contains.

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

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

With 5 parameters at 0% schema description coverage, the schema supplies bare titles only. The description alludes to the contains/not_contains distinction and regex matching, but says nothing about file_path, encoding, or the type/meaning of the regex boolean. Most parameters remain undocumented in both places.

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

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

The description names a specific verb (只读校验) and resource (文本/代码文件) with a clear scope: checking for presence or absence of a keyword or regex. An agent can grasp the operation immediately. It stops short of differentiating itself from the close sibling rea_patch_text_search, which likely performs a similar content lookup.

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

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

The phrase 只读校验 implies a validation/assertion use case rather than a discovery/search use case, which hints at when to prefer this over rea_patch_text_search. However, no explicit when-to-use, when-not-to-use, or alternative tool is named, leaving the routing decision to inference.

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

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

No annotations are provided, so the description carries the full burden. It does disclose two real behavioral traits: the operation is read-only, and encoding is auto-detected across UTF-8/GBK/UTF-16. It omits what happens on binary files, output/line-number format, size limits, and behavior when end_line is null.

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 read-only guarantee and encoding detection front-loaded and no filler. It is efficient, though its brevity is partly the cause of the documentation 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?

With no annotations, no output schema, and 0% schema description coverage on 4 parameters, the description should explain line-range semantics, output shape, and limits. It covers only the read-only nature and encoding handling, leaving an agent unable to predict what a call returns.

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 4 parameters, so the description must compensate and largely does not. The encoding auto-detection remark hints at the encoding parameter's role, but start_line and end_line — the core of 'by-line' viewing — are never explained (defaults, inclusivity, omitted end_line semantics).

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

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

States a specific verb (按行查看 / view by line) and resource (文本/代码文件) plus a read-only constraint. An agent can distinguish it from siblings like rea_patch_text_search or rea_patch_text_apply by the 'view' action, though the description never names those alternatives 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 rea_patch_text_search, rea_patch_dump, or the apply/verify siblings. Usage is only implied by the word 'view' — no preconditions, no exclusions, no routing advice.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that omitting image_base triggers automatic PE header reading, but it does not state the return format, error behavior for invalid PE files, or validation constraints.

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 definition is a single front-loaded sentence with the key optional-parameter behavior in parentheses. Every part earns its place and there is no redundant 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 three-parameter conversion helper with no output schema and no annotations, the description covers the core action and image_base fallback. It still leaves out the return value and error conditions, so an agent has enough to attempt the call but not full context.

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 clarifies va as a virtual address and explains image_base's fallback behavior, but file_path remains undocumented beyond its name, leaving partial compensation for the coverage gap.

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

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

The description names a specific verb and resource: converting a VA virtual address to a file offset, and it adds the image_base fallback. It does not explicitly distinguish itself from sibling patch tools, but the operation is clear and unlikely to be confused with PE info, dump, apply, or text tools.

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

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

Usage is implied by the conversion purpose: use it when a VA needs to become a file offset. However, the description gives no explicit when-not conditions, prerequisites, or alternative-tool routing, so guidance is only minimal.

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?

With no annotations, the description carries the full burden, and it does disclose the key trait: it does not modify the file. However, it says nothing about what verification returns (boolean? error?), permissions, or failure behavior at the offset.

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, purpose front-loaded, then the parameter example. No wasted words. Nothing padded, though it could afford one more sentence on the offset format.

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-param tool with no annotations and no output schema, the definition is thin: it doesn't specify the offset format or what the verification result looks like. The critical non-write behavior is covered, but key calling details are missing.

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

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

Schema coverage is 0%, so the description must compensate. It adds real meaning for 'expected' (hex string, with example 90909090), but leaves 'offset' ambiguous (byte offset? decimal or hex?) and 'file_path' undocumented. Partial compensation only.

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

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

States a specific verb+resource: verify bytes at a file offset. The parenthetical '(不写文件)' explicitly frames it as the non-mutating counterpart to rea_patch_apply, aiding sibling differentiation. It stops short of naming the alternative tool explicitly, so not a full 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?

'Does not write the file' implies this is the safe pre-check before rea_patch_apply, but the description never explicitly says when to use this versus rea_patch_apply, rea_patch_dump, or rea_patch_text_verify. Usage is implied rather than stated.

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