Whatever a target does, a connected client can trigger, so the practical control is which Makefile you point it at rather than any setting in the server. The author is unusually candid about the limits: argument parsing is heuristic, sanitisation is best-effort, and it may not work with your Makefile at all. Read as a way to expose a curated set of project commands, it is a neat idea; read as a general runner, the caveats are the point.
A Node server that reads a project's Makefile at startup and registers one tool per target, named `make_<target>`. The comment directly above a target becomes that tool's description, so a Makefile you already document is a tool surface you already documented. It parses arguments on a best-effort basis from the target's commands and comments.
- One tool per Make target, named `make_<target>` — a Makefile with `build`, `test` and `deploy` yields `make_build`, `make_test` and `make_deploy`
- Comments above each target become the tool descriptions the client reads
- A second launch argument points at the directory holding the Makefile; omit it and the current directory is used
- Optional arguments, parsed heuristically from the target's documentation and commands
- Some input sanitisation, which the author describes as best-effort rather than a guarantee
Node.js 16 or higher, `make` on your PATH, and a Makefile in the project directory. Clone, `npm install`, `npm run build`, then point your client at `node` with `build/index.js` and the project path. Package `makefilemcpserver`, version 0.1.0. Everything in the Makefile becomes reachable by any connected client, and the commands run with your permissions — the README labels it alpha and local-use-only for exactly that reason.