Muse Dash Mod MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GH_TOKEN | No | Alias for GITHUB_TOKEN. | |
| GITHUB_TOKEN | No | Optional GitHub personal access token to increase API rate limits. | |
| MD_DIRECTORY | No | Path to the Muse Dash game directory. The server also attempts to detect common Steam installation paths. | |
| MUSE_DASH_PATH | No | Alternative path to the Muse Dash game directory, used as a fallback. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_mod_projectB | Create a C# Muse Dash mod using MuseDash.Mod.Template. |
| build_modB | Build a Muse Dash mod project and report generated DLLs and compiler errors. |
| deploy_modA | Build and explicitly copy the primary mod DLL into the game's Mods directory. |
| launch_gameA | Launch MuseDash.exe for local mod testing without waiting for it to exit. |
| get_environment_infoA | Inspect MD_DIRECTORY, MelonLoader, dotnet, the template, and installed mod DLLs. |
| search_mdmods_reposB | Search read-only MDMods GitHub repository metadata. |
| get_mdmods_repo_fileB | Read a text file from an MDMods GitHub repository. |
| list_modding_docsA | List the built-in Muse Dash mod development documentation topics. |
| get_modding_docA | Read one built-in documentation topic by its slug. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| new_mod_workflow | Provide a guided prompt for creating and testing a new mod. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Each tool has a distinct purpose: creating a project, building, deploying, launching, inspecting the environment, searching repositories, reading files, and accessing docs. There is no overlap; even build_mod and deploy_mod are clearly separated by deploy's explicit copy-to-game-directory behavior.
All tool names follow a consistent verb_noun pattern in lowercase with underscores (create_mod_project, build_mod, deploy_mod, launch_game, get_environment_info, search_mdmods_repos, get_mdmods_repo_file, list_modding_docs, get_modding_doc). The mix of verbs (create, build, deploy, launch, get, search, list) is predictable and readable.
The 9 tools are well-scoped for a modding workflow, covering the core development cycle (create, build, deploy, launch) plus environment inspection, repository browsing, and documentation access. The count is within the ideal 3-15 range and feels neither sparse nor bloated.
The toolset covers the entire mod lifecycle from creation to testing, with environment diagnostics and documentation support. Minor gaps exist, such as no explicit uninstall/remove tool or dependency management, but these are not critical to the primary workflow and can be worked around.