Provides DOS game emulation through js-dos, allowing AI assistants to launch and play classic DOS games like DOOM, Super Mario, Tetris, and Duke Nukem 3D in a browser window with configurable controls.
Runs the MCP-DOS server that enables access to classic DOS games, with requirements specifying Node.js ≥20.0.0 for proper functioning.
Used for package management in the MCP-DOS project, with specific commands for installing dependencies, building, and running the server.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP DOS - Classic DOS Gaming Server open doom"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides access to classic DOS games through js-dos emulation. Play legendary games like DOOM, Super Mario, Tetris, and Duke Nukem 3D directly from your AI assistant.
Classic DOS Games: Play iconic DOS games including DOOM, Super Mario, Tetris, and Duke Nukem 3D
Web-based Emulation: Uses js-dos for authentic DOS gaming experience in the browser
Fullscreen Support: Enjoy games in fullscreen mode with proper controls
Keyboard Mapping: Pre-configured key mappings for each game with on-screen controls
Server Management: Tools to start, stop, and manage the gaming server
Related MCP server: Flappy Bird MCP App
DOOM (doom) - The legendary first-person shooter
Super Mario (super-mario) - Classic platformer adventure
Tetris (tetris) - The timeless puzzle game
Duke Nukem 3D (duke3d) - Action-packed FPS adventure
Add this server to your MCP client configuration:
{
"mcpServers": {
"mcp-dos": {
"command": "npx",
"args": ["-y", "mcp-dos"]
}
}
}Each game comes with pre-configured controls displayed on screen:
Arrow Keys: Movement (Forward/Back/Left/Right)
W: Use
S: Fire
A/D: Strafe left/right
Enter: Menu navigation
Arrow Left/Right: Movement
Alt: Jump
7/8: Move left/right
9: Rotate piece
Space: Drop piece
Enter: Menu navigation
Arrow Keys: Movement
Ctrl: Fire
A: Jump
Enter: Menu navigation
List DOS GamesLists all available DOS games that can be played through the server.
Returns:
Array of available game slugs
Instructions on how to play games using the open-dos tool
open-dosOpens and plays a specific DOS game using js-dos emulation in a browser window.
Parameters:
game (string): DOS game slug to play (e.g., 'doom', 'super-mario', 'tetris', 'duke3d')
Features:
Launches game in a new browser window
Displays game-specific controls on screen
Fullscreen support
Authentic DOS gaming experience
close-appCloses an existing running mcp-dos server instance.
Parameters:
port (number): The port number of the server to close
Use Cases:
Clean up server instances
Resolve port conflicts
Server maintenance
# Install dependencies
pnpm install
# Build the project
pnpm build
# Run the server
pnpm startNode.js ≥20.0.0
Modern web browser with JavaScript enabled
Internet connection for js-dos CDN resources
This project is built using the xmcp framework.
Close an existing running mcp-dos server. You can use this tool if you are getting erros when starting a new server.
| Name | Required | Description | Default |
|---|---|---|---|
| port | Yes | The port of the app to close. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=true, covering key behavioral traits. The description adds context about closing a server to resolve errors, which is useful but doesn't elaborate on effects like termination or cleanup beyond what annotations imply.
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?
The description is two sentences, front-loaded with the main action and followed by usage guidance. Every sentence adds value without redundancy, making it efficient and well-structured.
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?
Given the tool's complexity (simple destructive operation), rich annotations, and no output schema, the description is mostly complete. It explains the purpose and usage context but could benefit from more detail on what 'close' entails (e.g., termination effects) to fully compensate for the lack of output schema.
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 description coverage is 100%, with the parameter 'port' fully documented in the schema. The description doesn't add any additional meaning or details about the parameter beyond what the schema provides, so it meets the baseline for high coverage.
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?
The description clearly states the action ('Close') and resource ('existing running mcp-dos server'), making the purpose understandable. However, it doesn't explicitly distinguish this tool from its sibling 'open-dos' beyond the opposite action, missing a direct comparison that would warrant a 5.
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?
The description provides explicit guidance on when to use this tool: 'if you are getting erros when starting a new server.' This gives a clear context for usage, helping the agent decide when to invoke it versus alternatives, though it doesn't name specific siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available DOS games
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, repeatable read operation. The description adds minimal behavioral context beyond what annotations provide - just the scope of 'all available' games. No rate limits, authentication needs, or return format details are mentioned.
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?
The description is perfectly concise - a single sentence that directly states the tool's purpose with zero wasted words. It's front-loaded with the core functionality and doesn't include any unnecessary elaboration.
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 simple listing tool with good annotations (read-only, idempotent, non-destructive) and no parameters, the description is adequate but minimal. It lacks information about what the output contains (game names, metadata, etc.) and doesn't provide usage context relative to sibling tools. The annotations cover safety aspects, but the description could add more operational context.
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?
With 0 parameters and 100% schema description coverage, there are no parameters to document. The description appropriately doesn't waste space discussing nonexistent parameters. A baseline of 4 is appropriate for parameterless tools where the schema already fully documents the empty parameter set.
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?
The description clearly states the verb ('List') and resource ('DOS games'), making the purpose immediately understandable. It specifies 'all available' which provides scope, though it doesn't explicitly differentiate from sibling tools like 'open-dos' or 'close-app' beyond the listing function.
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?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when this listing operation is appropriate, or how it relates to sibling tools like 'open-dos' (which might be for launching games) or 'close-app'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open and play a DOS game using js-dos. Use list to see the exact key you need to use and the available games.
| Name | Required | Description | Default |
|---|---|---|---|
| game | Yes | DOS game slug to play (e.g., 'doom', 'doom2'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond annotations by explaining that users need to check available games first and mentioning 'js-dos' as the implementation technology. While annotations already declare this as a safe, read-only, idempotent operation, the description provides useful practical guidance without contradicting the annotations.
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?
The description is perfectly concise with two sentences that each earn their place - the first states the purpose, the second provides critical usage guidance. No wasted words, perfectly front-loaded with the core functionality.
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?
Given the simple single-parameter tool with excellent annotations (readOnlyHint, idempotentHint, destructiveHint) and no output schema needed, the description provides sufficient context. It could potentially mention what happens when the tool is invoked (e.g., opens a game interface), but the annotations cover safety concerns adequately.
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?
With 100% schema description coverage, the schema already fully documents the single 'game' parameter. The description adds minimal value beyond the schema by mentioning 'exact key' and referring to the list tool, but doesn't provide additional parameter semantics beyond what's already in the structured data.
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?
The description clearly states the specific action ('Open and play') and resource ('a DOS game using js-dos'), distinguishing it from sibling tools like 'close-app' and 'List DOS Games'. It provides a concrete example of what the tool does rather than just restating the name.
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?
The description explicitly states when to use this tool ('to see the exact key you need to use and the available games') and provides a clear alternative ('Use `list`'), giving perfect guidance on when to use this tool versus its sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
close-appList DOS Gamesopen-dosEach tool has a clearly distinct purpose: close-app manages server lifecycle, List DOS Games provides a catalog, and open-dos launches a specific game. There is no overlap in functionality, and the descriptions clearly differentiate their roles.
The naming is inconsistent with mixed conventions: close-app uses kebab-case, List DOS Games uses title case with spaces, and open-dos uses kebab-case. There is no uniform verb_noun pattern, and the styles vary significantly across tools.
With only 3 tools, the count is borderline for a gaming server scope. It covers core operations (list, open, close), but feels thin compared to typical gaming servers that might include more features like save/load, settings, or game management. However, it is functional for basic play.
The tool set covers the essential lifecycle: list games, open a game, and close the server. Minor gaps exist, such as no tools for saving game progress, adjusting settings, or managing multiple sessions, but agents can perform basic gaming workflows without dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Games for AI agents. Each game runs inside a single context window.
Build browser games on gamedev.pl from your coding agent.
Savecraft serves real save game data and expert game knowledge to AI assistants.
Build, version, review, and export websites, web apps, and games from a conversation.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/basementstudio/mcp-dos'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
