re_write

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals the supported operations and data formats, but fails to mention that memory writes are destructive and irreversible, may corrupt the target process, require attached permissions, or have alignment/endianness constraints. This is a critical gap for a mutation 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?

The description is extremely compact, using shorthand notation to convey operation signatures and supported types in a single line. Every word contributes; there is no filler or redundancy.

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

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

The description adequately summarizes the core functionality and parameter mappings, but it omits important contextual details such as destructive side effects, process requirements, alignment/endianness, and error behavior. Given the lack of annotations and output schema, more behavioral context is needed for safe autonomous use.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by mapping each operation to its required parameters (e.g., bytes uses address+data, values uses address+type+values) and providing a compact type enumeration, which helps the agent understand parameter combinations beyond the schema's isolated property descriptions.

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

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

The description opens with 'Write memory,' a specific verb+resource phrase that immediately identifies the tool's purpose. It distinguishes from sibling read/disasm/scan tools by being the write operation, and it enumerates four distinct operation modes (bytes, values, string, wstring).

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 statement of when to use this tool versus alternatives, nor any exclusions or prerequisites. The name and sibling context make it obvious that this is the write counterpart to re_read/re_scan, but the description itself provides no guidance on selection or situational use.

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