Schedules an asynchronous MAME save to the Color Computer 3 state directory and reports whether the file appears, allowing emulator state management.
Schedule a MAME save into the state directory. The save is asynchronous; fileFound reports whether the file appeared.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | State name stored under the state directory |
Changes observed during successful MCP inspections.
v2.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose two useful traits: the save is asynchronous and 'fileFound' reports whether the file appeared. It says nothing about permissions, failure modes, or whether an existing state with the same name is overwritten, which matters for a write tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero waste, with the action and its asynchronous nature front-loaded. Nothing repeats the schema or the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter write tool, the description covers the key gap an agent would hit: the operation is async and completion is signalled via 'fileFound'. It leaves overwrite/collision behavior and error conditions unaddressed, but there is no output schema to lean on for the return signal, and it partially compensates by naming 'fileFound'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'name' parameter, so the schema already explains that it is the state name under the state directory. The description adds no format, naming-convention, or collision semantics beyond that, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Schedule a MAME save') and resource ('state directory'), which cleanly separates it from coco_load_state and the other state/snapshot siblings. It stops short of explicitly naming a sibling or a condition that picks it over them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not guidance is given; the agent must infer that this is the counterpart to coco_load_state. The asynchronous note is contextual, not a usage rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.