C64 Debug MCP

by henols

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.14
Disambiguation4/5
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.
Naming Consistency3/5
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.
Tool Count4/5
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.
Completeness4/5
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.
Average 3.9/5 across 18 of 18 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the side effect of loading and optionally starting, but does not disclose what happens to the current session state, whether prior programs are overwritten, what file types are supported, or what errors may occur.
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 a single concise sentence with no filler. It front-loads the primary action and includes the optional start behavior, though it could have used the saved space to add more useful guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a state-changing emulator tool with no annotations and a terse description. It lacks important invocation context such as file type expectations, behavior when autoStart is false, relationship to execute, and what the tool returns when loading fails. The existence of an output schema reduces the need to describe return values, but invocation semantics remain incomplete.
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 67%, with autoStart and fileIndex already documented in the schema. The description adds only the general idea that a C64 program is loaded and optionally started, which is a mild clarification for the undocumented filePath parameter but does not explain format, image behavior, or fileIndex usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Loads a C64 program' and adds the optional start behavior. It is clearly distinct in purpose from siblings like memory_read or breakpoint_set, though it does not explicitly differentiate itself from execute as a sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as execute or memory_write. The phrase 'optionally starts it' hints at behavior but does not describe when autoStart should be true or false, nor when another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. The word 'Lists' clearly signals a read-only operation, which is useful, but the description does not mention the effect of the includeDisabled parameter, default behavior, or any side effects. For a simple listing tool the basic behavior is conveyed, but richer behavioral context is absent.
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 a single focused sentence that immediately states the action and resource. There is no wasted wording, and the essential purpose is front-loaded without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with an output schema, the core behavior is adequately stated. However, the description is thin: it omits the meaning of includeDisabled and provides no usage context relative to related breakpoint tools. The output schema reduces the need to describe return values, but the description still leaves an agent to infer important details about the single parameter and when to choose this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the single parameter includeDisabled, so the description must compensate. However, the description does not mention includeDisabled at all, leaving its semantics to inference from the property name and default value. The schema's default true and property name provide partial meaning, but the description adds no parameter-level value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lists' and the resource 'current breakpoints and watchpoints', making the tool's purpose immediately understandable. It is distinct from the sibling mutation tools breakpoint_set and breakpoint_clear, though it does not explicitly name them or contrast itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool instead of siblings like breakpoint_set, breakpoint_clear, get_monitor_state, or get_session_state. The description implies a read-only listing operation but gives no context about prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It reveals that the operation is destructive but does not say whether the breakpoint must exist, whether deletion is idempotent, what happens on invalid IDs, or whether the running target is affected.
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 a single front-loaded sentence with no redundant words. It states the action and the identifying parameter immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter tool with an output schema, so the return value need not be described here. However, with no annotations and no mention of edge cases like nonexistent breakpoints or side effects, the description is only minimally viable rather than fully informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It only adds 'numeric,' which largely duplicates the integer type in the schema, and does not explain where the ID comes from, how it is validated, or its relationship to list_breakpoints.
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 states a specific verb ('Deletes') and a specific resource ('a breakpoint by numeric id'). It clearly distinguishes this from siblings like breakpoint_set and list_breakpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the verb 'Deletes' and the parameter name breakpointId, but there is no explicit guidance about when to use this tool versus related breakpoint tools, nor any exclusions or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of disclosing behavior. It describes creation and address formats, but not side effects such as whether setting an existing breakpoint replaces or duplicates it, whether the target must be running/halted, or how the optional condition/temporary flags affect behavior. This is a meaningful gap for a mutating debugger command.
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?
Two sentences with no filler: the core action is front-loaded and the address/range rule follows immediately. Every sentence contributes useful constraint information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient to make a basic breakpoint/watchpoint call and the output schema covers return shape. However, for an 8-parameter tool with no annotations, it omits guidance on kind semantics and the optional condition/temporary/label fields, leaving an agent to infer what those params do.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 38% of parameters described in the schema, the description needed to compensate, but it only restates the start/end/data_length relationship and reuses the hex/decimal format already present in the schema. It gives no semantics for kind, condition, label, enabled, or temporary, all of which are undocumented in the schema.
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?
States a specific action ('creates') and a specific resource ('execution breakpoint or read/write watchpoint'), which clearly distinguishes it from the list/clear/monitor siblings. The inclusion of 'watchpoint' also signals the read/write kinds supported by the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete how-to usage: specify start_address plus either data_length or end_address. It does not, however, state when to prefer this tool over list_breakpoints or breakpoint_clear, nor mention any prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses a non-obvious side effect: it automatically resumes the emulator if stopped and restores the previous pause state. This is valuable behavioral context, though it does not discuss all possible side effects.
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 concise and front-loaded, with one sentence for purpose and one for behavioral side effect. Minor spelling errors slightly reduce polish but do not hide the meaning.
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 this simple four-parameter tool with a rich schema and an output schema, the description covers the purpose and the key state-restoration behavior. It could be more explicit about tap duration semantics, but the schema handles most required detail.
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?
All four parameters are described in the schema with enums and purpose, so the schema already provides strong semantic coverage. The description does not add additional parameter meaning beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the core action: sending joystick input to C64 joystick port 1 or 2. This is a specific verb and resource, and the joystick target distinguishes it from keyboard_input, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over keyboard_input or other input methods. It does not state prerequisites or exclusions; the only extra sentence describes automatic resume behavior, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the primary behavior: capturing a screenshot, saving it to a PNG, and returning the path. However, with no annotations provided, the description carries the full burden and does not mention potential side effects like file location, overwrite behavior, or how the useVic parameter affects capture behavior.
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 a single concise sentence that clearly states the action, target, output format, and return value. There is no filler, redundancy, or irrelevant detail.
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?
This is a simple tool with one optional boolean parameter, a complete schema, and an output schema. The description covers the essential behavior. It is slightly incomplete due to missing usage guidance and side-effect details, but it remains adequate for a tool of this complexity.
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?
The single parameter useVic is fully described in the input schema with default e true and an explanation of its meaning. The description adds no additional parameter semantics beyond the schema, so the baseline score of 3 applies.
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 states a clear verb and resource: it captures the current screen, saves it as a PNG, and returns the path. This is distinct from sibling tools like get_display_state and get_display_text, which inspect state rather than produce an image file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use capture_display versus sibling tools such as get_display_state or get_display_text. The description gives no conditions, exclusions, or alternatives, so the agent is left to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a genuinely useful behavioral note: pause and resume are idempotent and safe to call multiple times. However, with no annotations provided, it leaves important side effects undisclosed, such as what reset modes actually destroy or how stepping interacts with paused state.
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 two tight sentences: the first front-loads the action set, and the second adds a useful behavioral caveat. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return values, and the enums cover the parameter space, so the description does not need to restate those. However, it does not clarify differing semantics between step, step_over, and step_out, nor the side effects of hard/nuclear reset, which a debugger-control tool could reasonably be expected to disclose.
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 75%, with count, resetMode, and waitUntilRunningStable already documented. The description does not add parameter-level detail, but at this coverage level the schema carries the semantic weight adequately. The idempotence note relates to actions rather than parameter meaning.
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 opens with 'Controls execution with' and then enumerates pause, resume, step, step_over, step_out, and reset. This clearly identifies both the resource (execution) and the action set, and distinguishes the tool from sibling tools focused on registers, breakpoints, memory, and display.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's usage context is clear: any execution-control action belongs here, and no sibling tool claims that responsibility. It does not name specific alternatives or exclusion conditions, but the context signals make the routing unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Returns' strongly implies a read-only operation, which is helpful, but the description does not explicitly promise no side effects, mention whether it reads current emulator state versus cached state, or disclose any behavioral caveats.
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?
A single, tight sentence leads with the verb and resource, then lists the returned components in a clear list-like structure. There is no redundant wording or filler.
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?
This is a simple no-parameter getter with an output schema available, so the description does not need to explain return values or parameter behaviors. The description plus output schema provide enough context for an agent to call the tool correctly.
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?
With zero parameters, the schema fully covers parameter semantics and the description does not need to compensate. The baseline of 4 applies because there are no parameters requiring explanation.
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 names a specific action ('Returns') and a specific resource ('display state'), then enumerates the exact contents: screen RAM, color RAM, graphics mode, screen memory addresses, and border/background colors. This clearly distinguishes it from sibling tools like get_monitor_state, capture_display, and get_display_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over alternatives such as capture_display or get_display_text. The description implies its purpose by naming the return data, but it does not state use cases, exclusions, or when another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'Returns' implies a read-only operation and the listed contents are useful, but it does not mention error conditions, whether the emulator must be running, or whether the state is a snapshot versus a live value.
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 a single, front-loaded sentence with no filler. Every phrase adds information about the returned session state.
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?
For a zero-parameter getter with an output schema, the description is complete enough: it names the resource and the three key state categories. The output schema can carry the detailed return structure, so nothing essential is missing.
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?
The tool has zero parameters, so there is no parameter meaning for the description to add. The schema coverage is effectively 100%, meeting the baseline for a no-parameter tool.
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 states a specific verb ('Returns') and a clear resource ('emulator session state'), then enumerates the contents: transport/process status, auto-resume state, and the most recent hit checkpoint. This is distinct from sibling getters like get_registers or get_display_state by its session-focused scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as get_monitor_state or wait_for_state. The description only states what it returns, leaving the agent to infer when it should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It meaningfully adds the 'Requires emulator to be stopped' precondition, but it does not describe side effects, failure behavior, or what happens when optional fields are omitted, leaving notable gaps.
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?
Two focused sentences: the first states the core action, the second covers accepted formats and the critical precondition. There is no filler or redundant elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic operation, formats, and precondition, and an output schema exists, so return-value details are not required. However, it fails to clarify why address is not required in the schema and what happens if it is omitted, which is a significant gap for an agent deciding how to invoke the tool.
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 baseline is 3. The description restates the format details already in the schema and adds only 'mixed formats allowed', which is minor. It also introduces ambiguity by mentioning hex string address prefixes while the schema declares address as an integer.
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 raw byte values into C64 memory', specifying the action, resource, and value type. This distinguishes it from sibling tools like set_registers, write_text, and memory_read without needing to inspect them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear contextual guidance by stating 'Requires emulator to be stopped', which is a crucial precondition. It does not explicitly name alternatives or when-not-to-use cases, but the raw-memory-write purpose is specific enough to imply appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It transparently conveys the blocking nature of the call, the target-state condition, and the optional stability-window requirement. The schema complements this by documenting timeout behavior, though failure/timeout return semantics are not described.
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 one efficiently front-loaded sentence: the verb 'waits' appears immediately, followed by the resource, target condition, and optional stability window. There is no redundant or filler wording.
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?
The tool is simple, all parameters are documented in the schema, and an output schema exists, so the description does not need to explain return values. The only gap is the absence of explicit guidance about timing out or how this differs from sibling state-query tools, but this is minor given the schema and sibling names.
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 all three parameters well, including the running/stopped enum and the timeout default. The description adds no significant parameter meaning beyond mirroring the execution-state and stability-window concepts already in the schema.
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 states a specific verb ('waits') and resource ('emulator') with an explicit condition ('target execution state') and the stability-window nuance. It clearly differentiates the wait behavior from sibling getter tools like get_monitor_state or get_session_state, which do not block.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The waiting semantics implicitly signal use when the agent needs to block until the emulator reaches a particular state, but the description does not explicitly name alternatives or state when not to use this tool. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses automatic resume if stopped, pause-state restoration, escaped/PETSCII token support, and the 64-byte request limit—all genuinely useful beyond the schema. It does not cover error behavior or side effects, but the core semantics are transparent.
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?
Three concise sentences, front-loaded with the primary action, followed by behavior, syntax support, and a hard limit. Every sentence contributes necessary information with no filler.
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 single-parameter write tool with an output schema, the description covers action, behavior, accepted token syntax, and size limit. It omits an explicit pointer to keyboard_input as the alternative for individual key presses, but nothing essential for making a correct call is missing.
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?
Schema coverage is 0% and the text parameter has no schema description. The description compensates strongly by explaining what text may contain (escaped characters, PETSCII brace tokens, color names) and the 64-byte constraint, which is essential for constructing a valid request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Types text into the C64.' Adds useful scope via auto-resume, token support, and byte limit. It is clearly oriented to text entry, though it does not explicitly differentiate itself from the sibling keyboard_input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when the tool is applicable—typing text, using PETSCII tokens, respecting a 64-byte limit—but gives no exclusions or explicit comparison to alternatives such as keyboard_input. Usage is mostly implied rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it returns readable text and that it's conditional on text mode, but it doesn't state what happens if the C64 is not in text mode (e.g., error, empty result). It also doesn't describe the text formatting (e.g., line endings, color codes). This is adequate but not rich, and since the tool is a simple read, the lack of error handling details is a minor gap.
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?
A single, front-loaded sentence with zero waste. It conveys the action, the resource, and the condition in a compact form. Every word earns its place.
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 zero-parameter tool with an output schema present, the description is nearly complete. It clearly states what the tool returns and when it is valid. The only missing piece is explicit handling of the non-text-mode case, but this is a minor omission given the condition is stated and the output schema defines the return format. Overall, an agent can confidently invoke this tool correctly.
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?
The tool has zero parameters, so the schema is trivially complete. Per the rubric, 0 parameters earns a baseline of 4. The description doesn't need to explain parameters since there are none. No deficiency here.
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?
States a specific verb ('Returns') and resource ('the current text screen') with a clear condition ('when the C64 is in a text mode'). This distinguishes it from siblings like capture_display (which likely captures regardless of mode) and get_display_state (which reports state rather than text). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear usage context: 'when the C64 is in a text mode' tells the agent when to call it. However, it doesn't explicitly mention alternatives or when not to use it (e.g., graphics mode). Still, the conditional is enough to guide basic selection, meeting the bar for clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. 'Returns' clearly frames this as a read-only query, and 'when available' sets correct expectations about optional fields. It does not detail failure behavior, but that is minor for a simple state getter.
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 a single front-loaded sentence with no filler. Every clause adds useful information about the tool's output and optional availability of fields.
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 parameterless getter with an output schema, this description is mostly complete: it names the core state fields and the availability qualifier. It falls slightly short by not contrasting with wait_for_state or explicitly confirming that it is non-blocking and non-mutating.
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?
The tool has zero parameters and full schema coverage, so there is no parameter meaning for the description to add. Instead, the description enriches the response semantics by naming stop reason and program counter, which helps an agent know what the tool provides.
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 uses the specific verb 'Returns' and identifies a precise resource: whether the C64 is running or stopped, along with stop reason and program counter. This clearly separates it from sibling getters like get_registers and get_session_state, so an agent can recognize its role immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for querying current C64 monitor state, but it never explicitly states when to prefer it over wait_for_state or get_session_state, nor does it mention when not to use it. The usage context is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full transparency burden. It discloses a non-obvious side effect: the tool automatically resumes if stopped and restores the pause state afterward. It also communicates the one-to-four-key cap and the supported action types. It does not cover failure modes, but an output schema is present.
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?
Two concise sentences deliver purpose, a key side effect, and the intended use cases. The core scoping fact is front-loaded, and no sentence is wasted.
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?
Given a complete input schema, an output schema, and moderate tool complexity, the description provides enough context for an agent to call the tool correctly. It covers what the tool sends, how many items it accepts, and its side effects on emulator pause state. It does not explicitly route to alternatives, but the use-case sentence gives sufficient selection 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 baseline is 3. The description repeats the one-to-four-key limit and PETSCII token idea already present in the keys property, but adds no format, syntax, or operational nuance beyond the schema. The action enum and durationMs are already well described in the input schema.
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 states a specific verb and resource: it sends one to four keys or PETSCII tokens to the C64. It also defines the intended operations (presses, releases, and taps), which clearly differentiates it from sibling input tools like joystick_input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use for key presses, releases, and taps', providing clear context for when the tool is appropriate. It does not name alternative tools or state when not to use it, but the intent is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral transparency burden. It discloses the output representation ('Returns byte values as decimal numbers') and accepted address formats. 'Reads' implies a non-mutating operation, and the description gives enough behavioral context for a read primitive, though it does not discuss error cases or limits.
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?
Three sentences with no filler. The first states purpose, the second states the required parameter combination, and the third covers address formats and return representation. Every sentence earns its place and the key information is front-loaded.
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?
For a low-complexity read tool with full schema coverage and an output schema present, this description is complete. It provides all invocation-critical details: which parameters to use, how addresses may be formatted, and what the response represents. Nothing essential is missing.
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 the baseline is 3. The description adds meaning beyond the schema by stating the required combination of start_address with exactly one of data_length or end_address. It repeats the hex-format information already present in the schema, and the hex-string wording mildly conflicts with the integer schema types, preventing a higher score.
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 opens with a specific verb and object: 'Reads a memory chunk.' It clearly defines the tool's action, distinguishes it from memory_write, and reinforces intent by stating the output is byte values. There is no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear invocation guidance: 'Specify start_address and either data_length or end_address.' This clarifies the required parameter relationship, which is not enforced by the schema. However, it does not explicitly name alternatives or provide when-not-to-use exclusions, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It clearly discloses that the tool mutates register state and requires the emulator to be paused, even naming the exact prior action. It does not detail failure behavior if called while running, but the stated precondition is the key behavioral trait.
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?
Two sentences with no filler. The core function and the critical prerequisite are front-loaded, and every word serves a purpose.
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 mutating debugger tool with no annotations, the description covers the purpose, the parameter shape, and the prerequisite. The presence of an output schema means return-value documentation is already handled externally. It could add more about downstream effects, but nothing essential for invoking it correctly is missing.
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?
The top-level schema coverage is 0%, so the description must compensate. It adds meaning with 'one or more' and 'by field name,' clarifying that the registers parameter is a partial mapping of named fields. The nested schema provides detailed descriptions and ranges for each register field, so the parameter semantics are reasonably complete.
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 action: 'Sets one or more C64 registers by field name.' This names a specific verb and resource, and the contrast with the sibling get_registers makes its purpose unambiguous.
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 gives an explicit precondition: 'Requires emulator to be stopped - call execute(action="pause") first if running.' This directly routes the agent to the correct sibling action and tells it when to do so, leaving no ambiguity about sequencing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral disclosure burden. It clearly signals a read-only operation ('Returns... snapshot') and discloses the critical prerequisite of a stopped emulator. It does not explicitly state what happens if called while running, but the requirement implies calling it in that state would be invalid.
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 a single sentence with no filler. The core function is stated first, followed by the necessary usage prerequisite, making it efficient and easy to parse for an agent.
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?
For a parameterless read-only snapshot tool with an output schema already present, the description covers all necessary operational context: what it returns and the required emulator state. No additional information is needed to invoke it correctly.
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?
The tool takes zero parameters, and the schema confirms this with an empty properties object. There is no parameter-level information for the description to add, so the baseline for a no-parameter tool applies.
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 a specific action: 'Returns the current C64 register snapshot.' This identifies both the resource (C64 registers) and the operation (retrieve a snapshot), and it is easily distinguished from sibling tools like set_registers, which writes rather than reads.
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 gives an explicit precondition ('Requires emulator to be stopped') and a concrete remedial action ('call execute(action="pause") first if running'). This tells the agent exactly when the tool is valid to call and how to get the emulator into that state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![c64-debug-mcp MCP server](https://glama.ai/mcp/servers/henols/c64-debug-mcp/badges/card.svg)](https://glama.ai/mcp/servers/henols/c64-debug-mcp)

Score Badge

Copy to your README.md:

[![c64-debug-mcp MCP server](https://glama.ai/mcp/servers/henols/c64-debug-mcp/badges/score.svg)](https://glama.ai/mcp/servers/henols/c64-debug-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/henols/c64-debug-mcp'

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