dos-mcp

by 64kramsystem

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation4/5
Each tool targets a distinct emulator function, but the input-related tools (send_keys, key_event, type_text) are somewhat similar in purpose. The descriptions clarify the differences, but an agent might occasionally confuse send_keys with key_event.
Naming Consistency4/5
All tools consistently use the dosbox_ prefix and snake_case. Most use an imperative verb (capture, save, load, pause, resume, reset, swap, break, send, type, read), but a few are nouns (status, key_event), which is a minor deviation.
Tool Count5/5
With 13 tools, the server covers the key aspects of DOSBox control—state, input, display, memory, and execution—without being bloated. The count feels well-scoped for an emulator control surface.
Completeness4/5
The tool set covers core emulator operations such as state save/load, screen capture, keyboard input, and memory reads. Minor gaps exist, such as mouse control or disk image management, but the surface is largely sufficient for typical DOSBox automation.
Average 3.2/5 across 13 of 13 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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 Apache 2.0.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations and no annotation contradiction. With no annotations, the description alone does not disclose whether this is a side-effect/query, permission requirements, or what resources it touches. The term 'debugger state' is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence 'Report DOSBox-X run and debugger state.' is concise, but it is under-specified; it lacks parameters, output details, and any behavioral nuances, making it minimally useful.
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?
An output schema exists but the description does not explain return values or semantics. The sibling tools suggest a broad debugger domain, but no context helps the agent decide exactly what this 'report' yields. No description of side effects, preconditions, or related state.
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 0 parameters, so there is nothing for the description to explain. Baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Report DOSBox-X run and debugger state' but lacks a specific verb-object or resource to define what is being returned. It does not distinguish this tool from the many debugger-related siblings, such as dosbox_pause or dosbox_break.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to use this tool, what state information is expected, or how it relates to sibling debugger actions (pause, reset, send_keys, etc.).
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?
With no annotations, the description must disclose behavior. It only states that unmapped bytes are indistinguishable from zero, which is useful, but it fails to mention that reading memory likely requires the emulator to be paused, or that it may fail if running, or other potential side effects. The description is minimal and leaves the agent guessing about operational constraints.
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 extremely concise, consisting of a single sentence. Every word is meaningful, and the critical caveat about unmapped bytes is front-loaded. There is no wasted text, making it highly efficient.
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?
Despite the presence of an output schema and 5 parameters, the tool is relatively simple (reading memory). However, the lack of guidance on parameter semantics and operational prerequisites leaves the description incomplete. The output schema may clarify return values, but the description doesn't explain how to use the various options like output_path or allow_running, and the tool's complexity (interaction with emulator state) demands more detail than one sentence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 5 parameters, and the schema description coverage is 0%, meaning none of them are documented in the schema. The description mentions no parameter details at all aside from implying address and size in 'physical memory', but there is no explanation of 'overwrite', 'output_path', or 'allow_running', which are non-obvious. The description fails to provide the necessary compensation for the lack of schema documentation.
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 tool 'Read physical memory', which is a specific verb and resource. However, it does not explicitly differentiate from sibling tools, though none of the siblings are memory-related, so the distinction is implicit.
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?
The description gives no guidance on when to use this tool versus alternatives. It does not mention any prerequisites like pausing emulation, or that it should be used for debugging memory values, nor does it specify 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, but it only states 'Tap one simultaneous chord.' It does not disclose whether the keys are pressed and released, if there is any blocking or timing, whether the action affects the DOSBox state, or if it simulates a key-down/up event. This is a significant gap for a mutation-like action.
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 front-loads the key action ('Tap') and specifies the target ('DOSBox-X QKeyCode names'). No fluff or redundancy, making it appropriately concise for a tool of this simplicity.
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?
Given the tool's complexity (sending simultaneous key chords to a DOSBox-X environment) and absence of annotations or parameter details, the one-liner is incomplete. It omits mention of whether the chord is pressed and released, how to specify modifier keys, or any potential side effects. While an output schema exists, the description still lacks essential operational context.
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 schema has no parameter descriptions and coverage is 0%. The description adds that 'keys' should be QKeyCode names, which is a semantic hint, but it does not explain what QKeyCode names are, how to format them, or provide examples. This minimal information only partially compensates for the lack of schema documentation.
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 a specific action (tap one simultaneous chord) and resource (DOSBox-X QKeyCode names), making its purpose clear. It does not explicitly distinguish it from sibling tools like dosbox_type_text or dosbox_read_memory, but 'chord' implies a key combination, which differentiates it functionally from typing text or reading memory.
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 on when to use this tool versus alternatives such as dosbox_key_event or dosbox_type_text. The description does not mention context, preconditions, or scenarios where this tool is preferred, leaving the agent without decision support.
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 present, so the description must disclose behavioral details. It indicates that the tool presses or releases a key, implying a state change, but it does not mention side effects, timing, or whether it triggers events. The description gives a basic sense of behavior but lacks depth regarding the action's consequences.
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 words, which is efficient. It adequately covers the basic action without verbosity, though it could be slightly more structured to include parameter details without becoming lengthy.
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?
The description is minimal and does not address the output (if any), prerequisites, or limitations. Given that the input schema is sparse (no parameter descriptions) and no annotations exist, the description fails to provide sufficient context for full usability, leaving the agent to guess about return values and edge cases.
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 schema provides no descriptions for the parameters, and the tool description does not explain what values 'key' accepts (e.g., key names, codes) or the precise meaning of 'down' (true for press, false for release). While the description hints at the distinction ('press or release'), it does not define parameter formats or allowed values, leaving room for ambiguity.
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 action (press or release) and the resource (a single DOSBox-X QKeyCode key), distinguishing it from sibling tools like send_keys or type_text. It is specific enough for the agent to understand the tool's primary function, though it assumes prior knowledge of QKeyCode terminology.
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?
The description does not provide guidance on when to use this tool over alternatives. For example, it does not mention that this tool is for discrete key down/up events, or that send_keys might be used for multi-key sequences. Without explicit usage criteria, the agent may struggle to select the appropriate tool among many similar sibling tools.
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 exist. Not a contradiction either. Description doesn't disclose timing, input flow details, or possible side effects. It may be writing to guest standard input of an emulated system. But a mention of the active consumption as a metaphor: can be used as they type. Transclusion does not mean cannot append.
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 sentence is brief and dense. It includes a quirky 'Paced' which is a slight speed. It is overhead but acceptable.
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 is given but not described. The cases with guest type and Enter are included. Not specified if it is used, no return value. For 'paced type', evolution didn't note what happens; but the description in the context of DOSBox is helpful. It is part of a DOSBox-sibling family with no description of return, operational semantics in detail. Still the general context has not been set; output schema not exposed. Score 3
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 covers most (2 fields), but description does not provide parameter value; e.g. 'text' or 'press_enter' report. It is a device that is not reproducing but from interpreted text; nothing from the description is.
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?
Clear verb+object structure: 'Type US-ASCII text'. The phrase 'while the guest actively consumes input' indicates input is streamed to the guest. But it is differentiated from siblings like send_keys and key_event only partially.
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?
Missing when-to-use or when-not-to-use guidance. It does not articulate howit compares with direction keys (send keys). It does not identify scenarios like command entry, note, etc. Need better.
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 carries the full transparency burden, but it only names the action. It does not disclose preconditions (e.g., whether execution must be paused), side effects, idempotency, or error 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 focused sentence with no wasted words, placing the key verb first. It is appropriately sized for a zero-parameter control operation.
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 simple zero-parameter tool with an output schema, the description is mostly adequate, but it omits the essential paused-state precondition and any behavioral caveats. The presence of sibling tools like dosbox_pause provides context, but the description itself remains thin.
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 the schema coverage is effectively 100%, so the description has no parameter behavior to clarify. The baseline score of 4 applies because there is nothing additional the description could meaningfully add.
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 action ('Resume') and the target resource ('DOSBox-X execution'), making the purpose explicit. It is distinguishable from the sibling dosbox_pause by being its inverse, though it does not explicitly name that relationship.
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?
The description provides no guidance on when to use this tool, such as 'after dosbox_pause' or 'to continue a paused session.' The usage context is only implied by the verb 'resume,' and no alternative tools are mentioned or excluded.
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?
Without annotations, the description should disclose side effects (e.g., overwriting files, performance impact). It only says 'save' which implies persistence, but does not mention the overwrite behavior (though the parameter exists) or any failure modes. Minimal transparency beyond the core action.
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 that delivers the core message without verbosity. It is front-loaded and easy to scan, striking an appropriate balance for a simple tool.
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?
For a simple save operation with two parameters stunt, the description is too sparse. It does not explain the overwrite flag, mention any prerequisites (like the emulator being running), or provide context on what happens on success/failure. Even though an output schema exists, the lack of behavioral details leaves the agent guessing on edge cases.
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?
Description clarifies that 'path' is an absolute host path (useful), but provides no explanation for 'overwrite' or its default false behavior. Given 0% schema coverage, the description partially compensates for path but leaves the other parameter unspecified, so a 3 seems fair.
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: save emulator state to an absolute host path. It distinguishes itself from sibling tools like 'dosbox_load_state' (loads) and 'dosbox_status' (queries), making the 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, or when it should be avoided. For example, it doesn't mention it's useful for preserving game state before closing, or that it should not be used while the emulator is running. The description is purely functional with no context.
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?
With no annotations, the description carries full burden. It does not disclose side effects (e.g., whether breakpoint is one-time or persistent), any required state (GDB attached), or what happens after the break. The word 'next' implies a one-shot action but leaves ambiguity.
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 concise sentence that is front-loaded with the key action and target. No wasteful words; every word contributes to understanding the core purpose.
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 tool is simple with one parametrized boolean and an output schema, but the description omits the parameter's function and any details about the breakpoint behavior. It is minimally complete for a trivially simple action, but could clarify the 'enabled' semantics.
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 coverage is 0%, and the description does not explain the 'enabled' parameter (default true). The meaning (enable/disable the breakpoint) is absent, leaving the agent to guess. The description adds no value beyond 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 clearly states the action ('Break GDB') and the target ('the next DOS EXEC entry point'). It distinguishes itself from sibling tools which handle screen capture, state management, input, and memory—none of which relate to 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 description implies its use for debugging (breaking at a DOS EXEC) but provides no explicit context on when to use it versus alternatives, nor any conditions or prerequisites (e.g., GDB must be running). No exclusions or alternative tool mentions.
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?
With no annotations, the description carries the full burden. It only states the action and path requirement but fails to disclose potential side effects like overwriting current emulator state, required file format, or whether the emulator must be paused.
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, well-structured sentence with no filler. It is appropriately concise and front-loaded with the core purpose.
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?
The tool is simple, but the description is too sparse. It lacks context about state file requirements, overwrite behavior, and error conditions. The output schema exists but doesn't cover these behavioral aspects, so the description should provide more context.
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 description adds 'existing absolute host path' which provides key semantics beyond the schema's bare 'path' string. This clarifies that the path must be absolute and refer to an existing file, which is valuable for correct usage.
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 ('Load emulator state') and a resource ('emulator state'). It distinguishes from sibling tools like dosbox_save_state by the action verb, making it unambiguous.
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 on when to use this tool versus alternatives, nor any prerequisites (e.g., needing a previous save state). The context implies usage but doesn't explicitly state it.
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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. 'Advance' implies a mutation but lacks details on side effects (e.g., unmounting previous image, data loss risk, reversibility). It does not contradict annotations (none exist), but fails to add richer context for a write operation.
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. It front-loads the action and immediately clarifies the parameter values. Perfectly concise and structured.
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 simple tool with one parameter and an output schema, the description covers the essential purpose and parameter semantics. It could be more complete regarding side effects, but given the simplicity and presence of an output schema, it's adequate.
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 schema has one parameter 'drive' with no description and 0% coverage. The description compensates by explicitly mapping drive values 0 and 1 to A: and B:, which adds meaning beyond the bare schema. This is sufficient for the single parameter, though it doesn't cover edge cases like invalid values.
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 action ('Advance the mounted floppy image') and specifies the resource (floppy image in A: or B:). It distinguishes from sibling tools by focusing on floppy swapping, though it doesn't explicitly name alternatives.
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 usage (when you need to advance to the next floppy image) but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternative tools. The context is clear from the name, but no exclusions are stated.
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 carries full responsibility for disclosing behavior. It does not mention whether the pause is reversible, non-destructive, or if any state is saved. This lack of detail for a state-changing action is a notable 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?
The description is a single, concise sentence with no unnecessary words. It is perfectly sized for the simplicity of the action.
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 description fully explains what the tool does for a straightforward action with no parameters or output. It is complete in its context, though the lack of behavioral details (reversibility, side effects) slightly detracts from overall completeness.
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 tool has no parameters, and the schema coverage is 100% (empty properties). The description adds no parameter information because none exists, so the baseline score of 3 is appropriate.
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?
Clearly states the action (Pause) and the resource (DOSBox-X execution). The verb is specific and distinguishes it from sibling tools like dosbox_resume and dosbox_reset.
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 usage (to pause execution), but does not explicitly state when to use it versus alternatives (e.g., resume, reset, or stop). No explicit when-not guidance is provided.
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?
With no annotations, the description must convey behavioral details, but it only states the action. It does not disclose potential data loss, unpredictability, or what happens to the guest state, which is critical for a reset operation.
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 with no filler. It communicates the core operation and the key parameter distinction efficiently.
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?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description covers the essential purpose but omits any side-effect warnings or guidance on when to prefer it over state restoration. It is minimally adequate but leaves gaps in behavioral context.
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 phrase 'optionally without a full machine reset' directly explains the dos_only parameter, adding meaning beyond the bare boolean schema. It tells the agent what false (default) and true likely do, compensating for the 0% schema description coverage.
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 ('Reset') and the resource ('DOS guest'), and distinguishes it from sibling tools like dosbox_pause, dosbox_save_state, and dosbox_capture_screen. The optional modifier hints at two distinct behaviors.
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?
It implies two usage modes via the dos_only parameter but does not explicitly say when to choose a full machine reset vs. a DOS-only reset, nor does it compare to alternatives like dosbox_load_state or dosbox_break_on_next_exec. There is no guidance on when not to use this tool.
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 full disclosure responsibility. It states it captures the display, implying a read-only operation without side effects, but does not explicitly confirm non-destructiveness or any potential limitations (e.g., if display is unavailable). It adds minimal behavioral context beyond the literal act.
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?
Single sentence, no redundancy, perfectly concise and front-loaded with the action and result.
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 simple capture tool with zero parameters and no output schema, the description is adequate. It names the tool's function and output format. It could mention whether it saves to a file or returns inline, but 'as an MCP PNG image' implies the MCP response format. Complete enough for the tool's complexity.
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 parametersvier, so schema coverage is 100%. The baseline for no parameters is 4. The description adds no parameter semantics because none exist, but that's appropriate.
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?
Clear verb (capture), specific resource (current DOSBox-X display), output format (MCP PNG image). Clearly distinguishes from sibling tools like dosbox_save_state or dosbox_status, which have different purposes.
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 when to use (when a screen capture is needed) but provides no explicit guidance on alternatives or exclusions. It doesn't clarify if there are prerequisites (e.g., running DOSBox-X) or when not to use it. The purpose is clear enough that usage is implied.
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:

[![dos-mcp MCP server](https://glama.ai/mcp/servers/64kramsystem/dos-mcp/badges/card.svg)](https://glama.ai/mcp/servers/64kramsystem/dos-mcp)

Score Badge

Copy to your README.md:

[![dos-mcp MCP server](https://glama.ai/mcp/servers/64kramsystem/dos-mcp/badges/score.svg)](https://glama.ai/mcp/servers/64kramsystem/dos-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/64kramsystem/dos-mcp'

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