Skip to main content
Glama
simen

VICE C64 Emulator MCP Server

by simen

runTo

Execute C64 program until reaching a specific memory address for debugging. Sets temporary breakpoint at target address and continues execution automatically.

Instructions

Run execution until a specific address is reached.

Sets a temporary breakpoint at the target address and continues execution. The breakpoint is automatically deleted when hit.

Use for:

  • "Run until this function" → runTo(functionAddress)

  • "Skip to the end of this loop" → runTo(addressAfterLoop)

Related tools: continue, step, setBreakpoint

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
addressYesAddress to run to (0x0000-0xFFFF)

Implementation Reference

  • src/index.ts:806-845 (registration)
    Registration of the "runTo" MCP tool, including description, input schema, and handler function.
    server.registerTool(
      "runTo",
      {
        description: `Run execution until a specific address is reached.
    
    Sets a temporary breakpoint at the target address and continues execution.
    The breakpoint is automatically deleted when hit.
    
    Use for:
    - "Run until this function" → runTo(functionAddress)
    - "Skip to the end of this loop" → runTo(addressAfterLoop)
    
    Related tools: continue, step, setBreakpoint`,
        inputSchema: z.object({
          address: z.number().min(0).max(0xffff).describe("Address to run to (0x0000-0xFFFF)"),
        }),
      },
      async (args) => {
        try {
          // Set temporary breakpoint
          const bpId = await client.setBreakpoint(args.address, { temporary: true });
    
          // Continue execution
          await client.continue();
    
          return formatResponse({
            running: true,
            targetAddress: {
              value: args.address,
              hex: `$${args.address.toString(16).padStart(4, "0")}`,
            },
            temporaryBreakpointId: bpId,
            message: `Running to $${args.address.toString(16).padStart(4, "0")}`,
            hint: "Execution will stop when target address is reached. Use status() to check state.",
          });
        } catch (error) {
          return formatError(error as ViceError);
        }
      }
    );
  • Handler function that implements the "runTo" tool logic: sets a temporary breakpoint at the specified address and resumes execution with continue().
    async (args) => {
      try {
        // Set temporary breakpoint
        const bpId = await client.setBreakpoint(args.address, { temporary: true });
    
        // Continue execution
        await client.continue();
    
        return formatResponse({
          running: true,
          targetAddress: {
            value: args.address,
            hex: `$${args.address.toString(16).padStart(4, "0")}`,
          },
          temporaryBreakpointId: bpId,
          message: `Running to $${args.address.toString(16).padStart(4, "0")}`,
          hint: "Execution will stop when target address is reached. Use status() to check state.",
        });
      } catch (error) {
        return formatError(error as ViceError);
      }
    }
  • Zod input schema defining the required 'address' parameter (0-65535) for the "runTo" tool.
    inputSchema: z.object({
      address: z.number().min(0).max(0xffff).describe("Address to run to (0x0000-0xFFFF)"),
    }),
Behavior4/5

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

With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it sets a temporary breakpoint, continues execution automatically, and the breakpoint auto-deletes when hit. It doesn't mention potential side effects like program state changes or execution limits, but covers the core behavior adequately.

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 perfectly structured: first sentence states the core purpose, next two explain the mechanism, 'Use for:' section provides practical examples, and final line references related tools. Every sentence earns its place with zero wasted words, and information is front-loaded appropriately.

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

Completeness4/5

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

For a debugging tool with no annotations and no output schema, the description does well by explaining the tool's behavior, usage scenarios, and relationship to other tools. It could be more complete by mentioning what happens if the address is never reached or describing the execution state after stopping, but covers the essentials adequately given the context.

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 the address parameter range (0-65535) and format. The description adds minimal value beyond this by implying the address is a target location, but doesn't provide additional semantic context like address format examples or validation rules.

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 specific action ('Run execution until a specific address is reached') and distinguishes it from siblings by explaining it sets a temporary breakpoint that auto-deletes. It uses concrete verbs like 'run', 'sets', 'continues', and 'deleted' that precisely define the operation.

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 description provides explicit guidance on when to use this tool with two concrete examples ('Run until this function' and 'Skip to the end of this loop'), mentions related tools (continue, step, setBreakpoint) for comparison, and implicitly suggests alternatives by distinguishing its temporary breakpoint behavior from setBreakpoint.

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/simen/vice-mcp'

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