Skip to main content
Glama

mgba_write32

Write a 32-bit value to emulated memory for cheats and pokes. Overwrites four bytes starting at a system bus address with an unsigned 32-bit little-endian value.

Instructions

PURPOSE: Write an unsigned 32-bit little-endian value to emulated memory at the given system bus address. USAGE: Use for 32-bit cheats and pokes (timestamps, large counters, pointers on GBA). For 8/16-bit values use mgba_write8/write16; for big-endian layouts byteswap and use mgba_write_range. BEHAVIOR: DESTRUCTIVE: overwrites four bytes starting at address with no undo (snapshot via mgba_save_state first if you need rollback). Debug-direct memory write — bypasses MBC/mapper/DMA, see mgba_write8 notes. Returns an error if the address is unmapped, address+4 crosses an unmapped boundary, value < 0, or the bridge method is missing. RETURNS: Single line 'Wrote VAL_DEC (0xVAL_HEX) → ADDR_HEX'.

NOTE: writes use mGBA's debug-direct memory access, which bypasses the cartridge bus model. On Game Boy with an MBC cartridge, this means writes to ROM region (0x0000-0x7FFF) won't trigger MBC bank-switch / RAM-enable commands, and writes to SRAM (0xA000-0xBFFF) hit the underlying buffer regardless of MBC enable state. To seed cartridge SRAM cleanly, use mgba_save_state / mgba_load_state with a pre-prepared state file.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
addressYesSystem bus address to overwrite. Same address-space conventions as the read tools — full 32-bit for GBA (EWRAM 0x02000000, IWRAM 0x03000000, ROM 0x08000000), 16-bit for GB/GBC (WRAM 0xC000, SRAM 0xA000). Should be 4-byte aligned (multiple of 4); misaligned writes on ARM-class regions may corrupt adjacent bytes or be silently dropped. Writes go through mGBA's debug-direct memory access, so they ignore MBC enable state and bus protections — to seed cartridge SRAM with proper hardware semantics, use mgba_save_state / mgba_load_state instead.
valueYes32-bit value to write. Must fit in unsigned 32 bits (0-4294967295, 0x00000000-0xFFFFFFFF). LSB lands at `address`, MSB at `address+3`. Negative values return an error.
Behavior5/5

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

With no annotations, the description fully discloses destructive behavior ('overwrites four bytes with no undo'), bypassing MBC/mapper/DMA, and error conditions (unmapped address, boundary crossing, negative value, missing bridge method). The NOTE adds context about debug-direct access and hardware semantics.

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

Conciseness5/5

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

The description is structured with clear labeled sections (PURPOSE, USAGE, BEHAVIOR, RETURNS, NOTE). Every sentence is informative with no redundancy. Length is appropriate for the complexity of the tool.

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?

Despite no output schema, the description documents the return format and error conditions. It covers edge cases (alignment, MBC bypass, boundary crossing). The NOTE provides important hardware context. All critical behavioral aspects are addressed.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds significant value beyond the schema: address alignment instructions, endianness mapping, and specific error cases for negative values. It also clarifies the note about SRAM seeding.

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

Purpose5/5

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

The description clearly defines the action ('write 32-bit little-endian value') and the target resource ('emulated memory at given system bus address'). It explicitly distinguishes from siblings (mgba_write8, mgba_write16, mgba_write_range) by specifying bit-width and byte-order use cases.

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

Usage Guidelines5/5

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

The USAGE section explicitly states when to use this tool (32-bit cheats, timestamps, counters, pointers) and provides alternatives ('for 8/16-bit use mgba_write8/write16', 'for big-endian byteswap and use mgba_write_range'). It also advises snapshotting before writes for rollback.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dmang-dev/mcp-mgba'

If you have feedback or need assistance with the MCP directory API, please join our Discord server