C64 Debug MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {
"enabled": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_monitor_stateA | Returns whether the C64 is running or stopped, along with the current stop reason and program counter when available. |
| get_session_stateA | Returns emulator session state including transport/process status, auto-resume state, and the most recent hit checkpoint. |
| get_registersA | Returns the current C64 register snapshot. Requires emulator to be stopped - call execute(action="pause") first if running. |
| set_registersA | Sets one or more C64 registers by field name. Requires emulator to be stopped - call execute(action="pause") first if running. |
| memory_readA | Reads a memory chunk. Specify start_address and either data_length or end_address. Address can be decimal (53248) or hex string with prefix ($D000, 0xD000). Returns byte values as decimal numbers. |
| memory_writeA | Writes raw byte values into C64 memory. Address and byte values support decimal, hex ($FF, 0xFF), and binary (%11111111, 0b11111111) formats. Requires emulator to be stopped. |
| executeA | Controls execution with pause, resume, step, step_over, step_out, or reset. Pause and resume are idempotent (safe to call multiple times). |
| wait_for_stateA | Waits for the emulator to reach a target execution state and optionally remain there for a stability window. |
| list_breakpointsB | Lists current breakpoints and watchpoints. |
| breakpoint_setB | Creates an execution breakpoint or read/write watchpoint. Specify start_address and either data_length or end_address. Address can be decimal (53248) or hex string with prefix ($D000, 0xD000). |
| breakpoint_clearB | Deletes a breakpoint by numeric id. |
| program_loadC | Loads a C64 program and optionally starts it. |
| capture_displayA | Captures the current screen to a PNG file and returns the saved image path. |
| get_display_stateA | Returns screen RAM, color RAM, the current graphics mode, screen memory addresses, and the current border and background colors. |
| get_display_textA | Returns the current text screen as readable text when the C64 is in a text mode. |
| write_textA | Types text into the C64. Automatically resumes if stopped and restores pause state after. Supports escaped characters and PETSCII brace tokens like {RETURN}, {CLR}, {HOME}, {PI}, and color names. Limit 64 bytes per request. |
| keyboard_inputA | Sends one to four keys or PETSCII tokens to the C64. Automatically resumes if stopped and restores pause state after. Use for key presses, releases, and taps. |
| joystick_inputA | Sends joystick input to C64 joystick port 1 or 2. Automatically resumes if stopped and restores pause state after. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 18 tools
Tools are mostly distinct and pair naturally (get/set_registers, memory_read/write, breakpoint_set/list/clear). Main ambiguities are get_monitor_state vs get_session_state and write_text vs keyoard_input, but descriptions give enough differentiation.
Most tools use readable snake_case, but the pattern is mixed: many are verb_noun (get_registers, set_registers, list_breakpoints) while several are noun_verb (memory_read, memory_write, breakpoint_set, breakpoint_clear, program_load) and two are noun phrases (keyboard_input, joystick_input). The names are still understandable, but not consistently predictable.
18 tools is above the typical 3-15 sweet spot, but each tool addresses a distinct debugger concern: execution, memory, registers, breakpoints, display, and input. No significant redundancy exists, so the count feels slightly heavy but justified for a full C64 debugger.
The set covers the core debugging lifecycle: load, run, step, pause, reset, breakpoints, watchpoints, memory/register inspection, display capture, and input. Advanced debugger features like conditional breakpoints or symbol support are absent, but there are no critical dead ends for normal C64 debugging.