dosbox-x-mcp

Overview Schema Source Related Servers Discussions Admin

dosbox_emulator_command

Trigger DOSBox-X recording, screenshot, or save/load state menu actions programmatically without focus or keystrokes. Stop recordings by firing the same action again. Works on Windows.

Instructions

Fire one of DOSBox-X's own menu items without focus and without a keystroke: record_opl, record_midi, record_wave, record_video, screenshot, save_state, load_state. Firing a record action again stops that recording. Windows only -- DOSBox-X draws its own menu elsewhere; see dosbox_capabilities.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "dosbox_emulator_command"
  }
}

Input Schema

Name	Required	Description	Default
`pid`	No
`action`	Yes	record_opl, record_midi, record_wave, record_video, screenshot, save_state, load_state.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Aug 24, 2026

TDQS

A3.7/5.0

Behavior4/5

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

It adds genuinely useful behavior beyond what the schema and annotations expose: firing a record action again stops that recording, actions are fired without focus, and Windows is a required platform because DOSBox-X draws its own menu elsewhere. These details are non-obvious and not available in the structured fields. The annotation flags (readOnlyHint=false, destructiveHint=false) align with the described behavior, and the description contradicts nothing.

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 compact and efficient: the first sentence delivers the core purpose and action list, the second adds the important toggling behavior, and the third isolates platform restrictions and a pointer to a related tool. It front-loads the most important information and keeps total length short, although it duplicate the action list from the schema somewhat.

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 there is an output schema, the return format does not need to be explained, and the tool's complexity is modest—one required parameter plus an optional pid. The description is enough to perform the call correctly for the typical case, but it does omit pid semantics and does not describe whether pid must refer to a specific session or process, leaving a small but real gap.

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 description adds meaning to the 'action' parameter by explaining that these are DOSBox-X menu items and that record actions toggle on/off. However, it mostly restates the list already present in the action parameter's schema description. More importantly, the 'pid' parameter has no description in the schema and none in the tool description, and at 50% schema coverage the description fails to compensate for explaining how or when the optional pid should be provided.

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 identifies a specific action: firing DOSBox-X's own menu items, and enumerates all seven supported action values. It also distinguishes itself from keystroke or focus-based input by explicitly saying it acts 'without focus and without a keystroke.' However, it does not explicitly distinguish itself from overlapping siblings like dosbox_record or dosbox_capture_screen, so an agent must infer those boundaries.

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 context is clear: it is for menu actions when keyboard/focus simulation is not appropriate, and it even notes a Windows-only restriction with a pointer to dosbox_capabilities. That said, it never explicitly says 'use this instead of X when Y' or mentions alternatives like dosbox_send_keys, dosbox_record, or dosbox_capture_screen, leaving some selection inference to the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.