The distinctive decision is refusing the meta-tool pattern: instead of one `run` tool that accepts any command, each capability is declared and named, so the surface a model sees is exactly the surface you wrote down. That is a real safety property, and the author pairs it with an unusually blunt caveat about the whole category. Note that the GitHub repository is archived and development continues elsewhere.
A clean-room MCP implementation in Rust whose stated priorities are as few dependencies as possible and a configuration you can audit. Tools are declared in a `tools.yaml` file and exposed directly, not funnelled through a generic "run" meta-tool, so a client sees the actual tool names and parameter schemas you wrote.
- Direct tool exposure: whatever you define in `tools.yaml` becomes a first-class MCP tool with its own name and description, rather than being hidden behind a generic command runner
- Dynamic loading — change the YAML and the tool set changes, with no recompile
- Both external commands and internal handlers, so a tool can shell out to a binary or be served by a built-in handler
- Per-argument declarations in the YAML: a name, a description for the model, whether it is required, a type, and either a CLI flag or a positional slot
- Pure JSON-RPC 2.0 over stdio with no external protocol dependencies, implementing `initialize`, `tools/list` and `tools/call`
No account and no key. Build it with `cargo build --release --bin gamecode-mcp2`, copy an example `tools.yaml` next to it, and point your client at the resulting binary; it communicates over stdio. The GitHub copy is archived and no longer maintained — the project has moved to `git.navicore.tech/navicore/gamecode-mcp2`. The author's own security notice is worth reading before you wire it up: allowing a model to execute system commands is inherently risky, and the design trades features for the ability to read every line that processes a model's requests.