Makefile MCP

Makefile MCP

[PyPI] [Python] [CI] [License]

Expose trusted GNU Make targets to AI agents — without exposing a generic shell or replacing Make with another workflow system.

Makefile MCP turns an existing Makefile into typed MCP tools. It is zero-config and run-safe by default, and deny-by-default when governed.

Makefile  →  Makefile MCP  →  Codex / Claude / LangChain / Cursor / VS Code / MCP client

Threat model

Design for a compromised agent: any text it reads can carry a prompt injection. Makefile MCP keeps the worst case short. A hijacked agent can run only the targets you listed, with values you typed, and a human approves the risky ones. Read the threat model for the threats, controls, tests that prove them, and limits.

Details: threat model, SECURITY.md, and security model.

Quick start

pipx install makefile-mcp        # or: uv tool install makefile-mcpmakefile-mcp serve

Given:

test: ## Run tests	pytest -q
lint: ## Run lint	ruff check .

Makefile MCP exposes make_test and make_lint as MCP tools. Other targets are listed but not runnable until you govern them.

makefile-mcp listmakefile-mcp doctormakefile-mcp run testmakefile-mcp run test --preview   # GNU Make --dry-run; not a sandbox

One-shot use: uvx makefile-mcp serve.

Why Makefile MCP

Makefile MCP is intentionally narrow: the repository's Makefile remains the executable source of truth, while Makefile MCP supplies a governed agent-facing capability boundary.

See Design rationale for the full capability/property map and the alternatives deliberately left out.

Architecture

                         Makefile                            |                    conservative catalog                            |              +-------------+-------------+              |                           |            auto                       governed         no config                   .makefile-mcp.yaml              |                           |              +-------------+-------------+                            |                       Application                  +---------+---------+                  |                   |              MCP direct         MCP generic                  +---------+---------+                            |                         Executor                            |                      exact `make -f`

One catalog. One execution path. Thin CLI and MCP adapters.

See Architecture.

Governed mode

Without .makefile-mcp.yaml, Makefile MCP runs in auto mode: every conservatively discovered root target is listed, but only test, lint, check, and fmt can run, with no caller-controlled Make variables. --legacy-auto-run restores the old run-everything behavior (deprecated).

Add .makefile-mcp.yaml to switch to explicit governance:

schema_version: 1
contexts:  backend:    directory: backend
tasks:  test:    contexts: [root, backend]    risk: safe
  deploy:    risk: dangerous    variables:      ENV:        type: enum        values: [staging, production]        required: true
capabilities:  verify: test
audit:  path: .makefile-mcp/audit.jsonl
pin:  paths: [scripts]       # freeze Make code and scripts the agent must not change

Only enabled (context, target) pairs are callable. dangerous tasks additionally need human approval (defaults.require_approval), and audit writes one JSON line per call. See Governed mode, Configuration, and Contexts and capabilities.

MCP presentations

Makefile MCP supports three MCP presentations over the same callable catalog. Choose the presentation that best fits your requirements.

makefile-mcp serve --tools direct    # default: one typed tool per callable targetmakefile-mcp serve --tools generic   # list_tasks / describe_task / run_taskmakefile-mcp serve --tools both      # both views, same execution core

See MCP presentations and client setup.

Security

Makefile MCP assumes the repository, Makefiles, included Make code, wrapper scripts, and provisioned tools are trusted operator-controlled code. The security boundary is the invocation: an MCP/CLI caller chooses an exposed task/context and, in governed mode, supplies declared values. Makefile MCP authorizes and validates that request; it does not sandbox hostile Makefiles.

Runtime bounds, cancellation/process-group cleanup, stdin isolation, and locking are primarily execution-correctness properties. They limit failure modes around trusted automation rather than turning Make into a sandbox. The built-in MCP server is stdio-only: no HTTP listener, remote-auth layer, TLS, tenancy, or network-service lifecycle is hidden inside the product.

See SECURITY.md for the security policy, reporting process, trust boundary, and limitations. Detailed implementation notes are in docs/security.md.

Intentional scope limits

• GNU Make on Linux/macOS; Windows is not currently supported.
• Trusted repository assumption: Makefiles, includes, scripts, and provisioned tools are operator-controlled code.
• Static discovery is deliberately conservative, not a complete GNU Make parser.
• Preview is GNU Make dry-run, not sandboxing; Make evaluation can still have side effects.
• Direct tool inventory is registered at startup; generic catalog calls can observe supported Makefile changes.
• .makefile-mcp.yaml is startup policy; changes require restart and fail closed until then.
• Foreground/bounded tasks only; deliberately detached daemons are outside Makefile MCP's process-group containment model.
• No HTTP server, auth stack, scheduler, job queue, workflow persistence, plugin execution framework, or arbitrary shell tool.
• Reload behavior:
  • .makefile-mcp.yaml is startup policy. Restart Makefile MCP after adding, removing, or editing it.
  • Makefile discovery refreshes when the conventional Makefile or tracked literal includes change.
  • Generic calls see the refreshed catalog immediately.
  • Direct tool inventory is a startup snapshot: adding or removing direct tools requires a restart. Existing direct tools still re-check the live catalog when invoked.

Requirements

Python 3.11+ · GNU Make · Linux or macOS

Documentation

1. Threat model — why agents should not get a shell, threats and controls, the policy and audit log, guarantees and limits. Start here.
2. Architecture — runtime flow, responsibilities, lifecycle, invariants, and dependency rules.
3. Design rationale — key tradeoffs, full product-property map, and deliberately rejected alternatives.
4. CLI reference — commands, options, result model, root detection, and exit codes.
5. Configuration — authoritative .makefile-mcp.yaml fields, defaults, approval, audit log, and precedence.
6. Static Make discovery — supported syntax, fail-closed behavior, includes, limitations, and cache semantics.
7. Governed mode — explicit exposure, typed inputs, risk metadata, human approval, and operating model.
8. MCP presentations — direct, generic, both, schemas, result/error semantics, naming, and lifecycle.
9. Contexts and capabilities — monorepo scoping, (context, target) authorization, and semantic mappings.
10. MCP client setup — Codex, Claude Code, LangChain/LangGraph, Cursor, VS Code, and uvx examples.
11. Security — trust boundary, Make input safety, arbitrary strings, discovery, environment/path controls, and execution bounds.
12. Development — contributor workflows, code ownership, regression expectations, and Definition of Done.
13. Deployment — Docker/stdio deployment, production checklist, and provisioning custom tools plus Makefiles.
14. Releasing — version/tag contract, clean-package smoke test, PyPI Trusted Publishing, provenance, GitHub Releases, and MCP Registry metadata.

Security reporting: SECURITY.md. Contributing: CONTRIBUTING.md.