Skip to main content
Glama
dmang-dev

mcp-retroarch

retroarch_read_ram

Read up to 4096 bytes from emulated memory using the CHEEVOS address space, returning a hex dump. Use as fallback when the core lacks a memory map.

Instructions

PURPOSE: Read up to 4096 bytes from emulated memory via the achievement (CHEEVOS) address space (READ_CORE_RAM) and return them as a hex dump. USAGE: Fallback memory-read tool — use when retroarch_read_memory returns 'no memory map defined' (older cores or those without an exposed system memory map can still respond to the older CHEEVOS read API). To poke back, pair with retroarch_write_ram at the same CHEEVOS address. Maximum 4096 bytes per call (NCI line-length limit). BEHAVIOR: No side effects — pure read. Transport: RetroArch's Network Control Interface (NCI) over UDP (default 127.0.0.1:55355, requires network_cmd_enable = true in retroarch.cfg). Reads work whether emulation is paused or running. Returns an error if the address is invalid for the CHEEVOS space, length < 1, length > 4096, or the UDP query times out. Like read_memory, RetroArch may return fewer bytes than requested at memory-region boundaries.

RetroArch exposes TWO distinct memory APIs with different address spaces: • READ_CORE_MEMORY / WRITE_CORE_MEMORY (used by retroarch_read_memory / retroarch_write_memory): goes through the libretro core's system memory map. Preferred when the loaded core advertises a memory map (most modern cores do). Errors with 'no memory map defined' if the loaded core doesn't. • READ_CORE_RAM / WRITE_CORE_RAM (used by retroarch_read_ram / retroarch_write_ram): uses the achievement (CHEEVOS) address space. Works even when no core memory map is defined, but addresses follow CHEEVOS conventions, not the system bus. Use as a fallback when read_memory returns 'no memory map defined'. Both APIs depend on the loaded core's exposed mapping — addresses you used on a different core / system will NOT carry over.

RETURNS: Header line 'ADDR_HEX [N bytes, CHEEVOS]:' followed by space-separated 2-digit uppercase hex bytes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
addressYesStarting address in the CHEEVOS (achievements) address space — distinct from the libretro system memory map used by retroarch_read_memory. CHEEVOS addresses follow per-system conventions used by RetroAchievements (e.g. SNES CHEEVOS addresses for WRAM start at 0x000000, not the SNES system bus 0x7E0000). If unsure, retroarch_read_memory is usually the right starting point.
lengthYesNumber of consecutive bytes to read (1-4096). Hard cap is RetroArch's NCI single-datagram size. May return fewer bytes at region boundaries.
Behavior5/5

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

With no annotations, the description fully discloses: no side effects (pure read), transport details (NCI over UDP), configuration requirement (network_cmd_enable = true), behavior during pause/run, error conditions, and potential to return fewer bytes at region boundaries. This is comprehensive.

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 description is lengthy but well-structured with clear sections (PURPOSE, USAGE, BEHAVIOR, RETURNS). Every sentence adds value, though some sentences could be merged for brevity without losing clarity.

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 includes return format. It covers purpose, usage, behavior, parameter nuances, and compares with sibling tool. No important context is missing, making it fully self-contained.

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

Parameters5/5

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

Though schema coverage is 100%, the description adds significant context: explains CHEEVOS addresses vs. system memory map, provides examples (SNES WRAM), and clarifies the length cap rationale. This enriches the schema's minimal descriptions.

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 reads up to 4096 bytes from emulated memory via the CHEEVOS address space and returns a hex dump. It distinguishes from sibling retroarch_read_memory by explaining the two distinct memory APIs, making the purpose precise and differentiated.

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 states this is a fallback when retroarch_read_memory returns 'no memory map defined' and that it pairs with retroarch_write_ram. Also advises that read_memory is preferred when the core advertises a memory map, providing clear when-to-use and when-not-to-use guidance.

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-retroarch'

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