Makefile MCP

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 by default for trusted local use and deny-by-default when governed.

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

Quick start

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

Given:

test: ## Run tests
	pytest -q

lint: ## Run lint
	ruff check .

Makefile MCP exposes make_test and make_lint as MCP tools.

makefile-mcp list
makefile-mcp doctor
makefile-mcp run test
makefile-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 callable, with no caller-controlled Make variables.

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

Only enabled (context, target) pairs are callable. 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 target
makefile-mcp serve --tools generic   # list_tasks / describe_task / run_task
makefile-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. Architecture — runtime flow, responsibilities, lifecycle, invariants, and dependency rules.
2. Design rationale — key tradeoffs, full product-property map, and deliberately rejected alternatives.
3. CLI reference — commands, options, result model, root detection, and exit codes.
4. Configuration — authoritative .makefile-mcp.yaml fields, defaults, and precedence.
5. Static Make discovery — supported syntax, fail-closed behavior, includes, limitations, and cache semantics.
6. Governed mode — explicit exposure, typed inputs, risk metadata, and operating model.
7. MCP presentations — direct, generic, both, schemas, result/error semantics, naming, and lifecycle.
8. Contexts and capabilities — monorepo scoping, (context, target) authorization, and semantic mappings.
9. MCP client setup — Codex, Claude Code, LangChain/LangGraph, Cursor, VS Code, and uvx examples.
10. Security — trust boundary, Make input safety, arbitrary strings, discovery, environment/path controls, and execution bounds.
11. Development — contributor workflows, code ownership, regression expectations, and Definition of Done.
12. Deployment — Docker/stdio deployment, production checklist, and provisioning custom tools plus Makefiles.
13. 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.