Name: GameCode MCP2
Author: navicore

LABSCO SUMMARY

Auditability chosen over features, and said so plainly.

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.

What it is

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.

What you get

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

Requirements

No account and no key. Clone it, build it with cargo build --release --bin gamecode-mcp2, write your tools into ~/.config/gamecode-mcp/tools.yaml, 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.

Setup effort

Build from source — git clone https://github.com/navicore/gamecode-mcp2.git

See installation options

USE CASES

01

Exposing a few internal scripts to a model safely

Declare each script as its own tool with typed, described arguments, so the model calls named operations instead of composing shell commands.

02

Changing the tool set without a rebuild

Edit the YAML and restart; no recompilation is involved in adding or removing a tool.

03

Reviewing exactly what a model can do

The tool file is the whole surface — reading it tells you every operation available, with no generic escape hatch.

INSTALLATION

Connect your client

Server setup

TERMINAL

git clone https://github.com/navicore/gamecode-mcp2.git
cd gamecode-mcp2
cargo build --release --bin gamecode-mcp2

Write your tools in ~/.config/gamecode-mcp/tools.yaml, in the format shown under Tool Configuration in the README (the examples/tools.yaml the README mentions is not in the repository). The server reads that file when it is started by a client from another directory.

MCP Clients

Claude Desktop

CLAUDE DESKTOP · JSON

{
  "mcpServers": {
    "gamecode": {
      "command": "<YOUR_PATH_TO_GAMECODE_MCP2>"
    }
  }
}

<YOUR_PATH_TO_GAMECODE_MCP2> is the full path to target/release/gamecode-mcp2 inside your clone.

GameCode MCP2