ppsspp-dfx

Overview Schema Source Related Servers Discussions Admin

ppsspp_write_memory

Destructive

Write values to PPSSPP emulator memory to debug or apply cheats. Specify address, format (u8/u16/u32/bytes), and data; protected ranges need force.

Instructions

PURPOSE: Write u8/u16/u32 or raw bytes to memory.

USAGE: session_id + address ('0x' hex) + data + format ('u8'|'u16'|'u32'|'bytes'; bytes accepts hex or base64).

BEHAVIOR: DESTRUCTIVE. Protected ranges (kernel, top.prx code) need force=true (PROTECTED_ADDRESS).

RETURNS: {address, format, bytes_written, value, text}.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`data`	No	Value to write, as a string. For format='u8'/'u16'/'u32', a hex string (e.g. '0x00000001') or decimal string (e.g. '1'). For format='bytes', a hex string (e.g. 'AABBCCDD') or base64 string. Optional when 'value' is supplied (alias); omitting both is an error.
`force`	No	Set to True to write to protected code/data regions of the modules loaded in THIS session (kernel memory below 0x08800000, plus the top.prx code section as reported by the live module list); declared data addresses from addresses.yaml are exempt. Writing to those ranges without force=True raises ToolError to prevent accidental crashes.
`value`	No	Alias for 'data'. Accepted because sibling tools take a 'value'; 'data' remains the canonical name and wins when both are supplied.
`format`	No	Write format. 'u32' (default) writes a 32-bit int. 'u8'/'u16' write byte/halfword granules (byte patches). 'bytes' writes raw bytes (data is hex-decoded).	u32
`address`	Yes	Target address, as a hex string (e.g. '0x08804000').
`session_id`	Yes	Active session ID.

Output Schema

TableJSON Schema

Name	Required	Description
`text`	Yes	Unified text representation: 'Wrote 0xVAL → 0xADDR' for u32, 'Wrote N bytes → 0xADDR' for bytes.
`value`	Yes	For format='u32', the value written as hex string (e.g. '0x00000001'); None for 'bytes'.
`format`	Yes	'u32' or 'bytes'.
`address`	Yes	Target address, hex string (e.g. '0x08804000').
`bytes_written`	Yes	Number of bytes written.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.1.7Oct 7, 2026

addedInput schema / properties / data / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / data / default
```
Added value: +null
```

changedInput schema / properties / data / description

Previous value: -"Value to write, as a string. For format='u8'/'u16'/'u32', a hex string (e.g. '0x00000001') or decimal string (e.g. '1'). For format='bytes', a hex string (e.g. 'AABBCCDD') or base64 string."New value: +"Value to write, as a string. For format='u8'/'u16'/'u32', a hex string (e.g. '0x00000001') or decimal string (e.g. '1'). For format='bytes', a hex string (e.g. 'AABBCCDD') or base64 string. Optional when 'value' is supplied (alias); omitting both is an error."

removedInput schema / properties / data / type
```
Removed value: -"string"
```

changedInput schema / properties / force / description

Previous value: -"Set to True to write to protected code-section addresses (kernel memory < 0x08800000 or top.prx code section 0x08804000-0x08D34000). Writing to these ranges without force=True raises ToolError to prevent accidental crashes."New value: +"Set to True to write to protected code/data regions of the modules loaded in THIS session (kernel memory below 0x08800000, plus the top.prx code section as reported by the live module list); declared data addresses from addresses.yaml are exempt. Writing to those ranges without force=True raises ToolError to prevent accidental crashes."

addedInput schema / properties / value

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Alias for 'data'. Accepted because sibling tools take a 'value'; 'data' remains the canonical name and wins when both are supplied.",
+  "title": "Value"
+}

changedInput schema / required

Previous value: -[
-  "session_id",
-  "address",
-  "data"
-]New value: +[
+  "session_id",
+  "address"
+]

First observedv0.1.0Sep 16, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds real value beyond them: it defines which ranges are protected (kernel below 0x08800000 and top.prx code), states the exempt case (addresses.yaml), and notes that a ToolError (PROTECTED_ADDRESS) is raised without force. This is meaningful operational detail, not repetition of the annotation.

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

Conciseness4/5

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

The labeled PURPOSE/USAGE/BEHAVIOR/RETURNS structure is front-loaded and scannable, with no filler sentences. It is appropriately sized for a 6-parameter mutation tool, though the terse phrasings occasionally assume reader familiarity.

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

Completeness5/5

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

With annotations covering the safety profile, a full output schema documenting the return shape, and 100% schema coverage on all six parameters, the description supplies exactly the remaining context an agent needs: format options, destructive nature, force requirement, and error behavior.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents data, value, force, format, address and session_id in depth. The description echoes the format enum and the data/value roles without adding syntax or edge cases beyond the schema, matching the baseline 3 when structured fields do the heavy lifting.

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

Purpose4/5

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

The description opens with a specific verb+resource ('Write u8/u16/u32 or raw bytes to memory') and names the accepted formats, so the tool's function is unambiguous. It does not explicitly contrast itself with siblings like ppsspp_read_memory or ppsspp_write_register, leaving differentiation to the tool name.

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

Usage Guidelines3/5

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

The USAGE block lists the required inputs (session_id + address + data + format) and the BEHAVIOR block explains when force=true is needed, which implies usage context. However, it never states when to choose this tool over ppsspp_write_register or other mutation siblings, so alternatives are left to inference.

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