Skip to main content
Glama

mgba_write8

Write a single unsigned byte (0-255) to emulated memory at a given system bus address for cheats, debug pokes, or game-state mutations.

Instructions

PURPOSE: Write a single unsigned byte (0-255) to emulated memory at the given system bus address. USAGE: Use for single-byte cheats, debug pokes, and game-state mutations (give a player N lives, unlock a flag, set a counter). For 16/32-bit values prefer mgba_write16/write32 (single call instead of byte-at-a-time); for spans use mgba_write_range. To seed cart save RAM realistically (with proper MBC bank/enable behavior on Game Boy, or to install a known-good progression state on GBA), prefer mgba_save_state / mgba_load_state with a pre-prepared state file rather than poking SRAM bytes here. BEHAVIOR: DESTRUCTIVE: overwrites whatever was at address with no undo (snapshot via mgba_save_state first if you need rollback). The write is debug-direct memory access — bypasses MBC bank switches, cartridge mapper side-effects, RAM-enable gates, and bus protections — so it cannot be used to emulate cartridge hardware. Writes to ROM region addresses succeed at the memory level but produce no MBC effect on GB/GBC. Returns an error if the address is unmapped, value < 0 or > 255, or the bridge method is missing. Works whether emulation is paused or running. 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). 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.
valueYesByte value to write. Must be 0-255 (0x00-0xFF). Values outside this range return an error before the write is attempted.
Behavior5/5

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

No annotations exist, so description carries full burden. It discloses destructive nature (no undo), debug-direct memory access bypassing MBC and bus protections, behavior for writes to ROM/SRAM regions, and error conditions (unmapped address, out-of-range value). This provides comprehensive behavioral transparency.

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?

Description is well-structured with clear sections (PURPOSE, USAGE, BEHAVIOR, RETURNS). While somewhat lengthy, every sentence provides necessary guidance. Minor redundancy with schema descriptions, but overall efficient.

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?

Given no output schema, the description covers return format and error conditions. It also notes the tool works even when emulation is paused. For a mutation tool with detailed side effects, the description is fully complete.

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 has 100% coverage, so baseline is 3. The description adds extra context beyond schema: address conventions for GBA/GB, MBC bypass implications, and that value errors return before write attempt. This enriches parameter understanding.

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 states the tool writes a single unsigned byte to emulated memory, specifies value range and address domain. It distinguishes from sibling tools (mgba_write16, mgba_write32, mgba_write_range) by stating when to prefer them, and from save/load state for cartridge SRAM seeding.

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?

Explicitly lists appropriate uses (single-byte cheats, debug pokes, mutations) and explicitly says when not to use this tool (prefer write16/write32 for larger values, write_range for spans, save/load state for cartridge SRAM). Also suggests snapshotting via save_state as a precaution.

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