write_memory

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

Annotations already flag destructiveHint=true, but the description adds the non-obvious behavior an agent could never infer: default rejection of writes over hooked function entries, the crash mechanism behind it, and the fact that even identical bytes cause a crash in that case. It also discloses acceptable targets (module headers) and the force override semantics.

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

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

Front-loaded with the danger, then prerequisites, then the hook rule, then args – a sensible order with no wasted framing. The retrospective detailing (Windows event log, 'c0000005', 'tested twice') is more narration than an agent needs, though it does substantiate the rule.

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 dangerous 3-parameter mutation with no output schema and thin annotations, the description covers risk, prerequisites, refusal semantics and per-param encoding. It never states what a successful call returns (e.g. new bytes or a status), which is the one gap an agent might notice.

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%, but the args section documents all three parameters: address is hexadecimal, hex_data is a hex string with a concrete encoding example ('0000803f' = float 1.0), and force is an opt-in override whose default false means refuse. This fully compensates for the absent schema 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?

States a specific verb and resource: writing raw bytes into a game process's memory, which is clearly distinct from reading or hooking. It does not explicitly say how it differs from set_field_value, the sibling that presumably writes values at a typed/higher level, so the boundary needs 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?

Gives explicit when-to-use and prerequisite steps (verify the address with read_memory first, back up the original value, prefer simple float/int payloads) and an explicit refusal case with two documented escapes (force=True or unhook first). The agent knows exactly what to do before and instead of calling this.

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