contract-ops-mcp

One MCP server for the whole contract-ops CLI suite — wire it up once and an agent (Claude, Cursor, Codex, …) gets all nine local-first CLIs as tools: extract, draft, lint, compare, convert, review, and the template + signed-contract vaults. Signing stays human-gated.

Run this

// e.g. Claude Desktop / Cursor MCP config
{
  "mcpServers": {
    "contract-ops": { "command": "npx", "args": ["-y", "contract-ops-mcp"] }
  }
}

The CLIs themselves must be installed (the server shells out to them). Fastest way to get all nine:

curl -fsSL https://cli.drbaher.com/install.sh | sh     # local
# …or run the server + CLIs in one container: ghcr.io/drbaher/contract-ops

Call suite_status any time to see which CLIs are present and how to install any that aren't.

Tools

Curated, ergonomic tools (typed inputs, JSON out) for the common operations, plus two escape hatches for the long tail:

The curated set and catalog/run are discovery-driven — they ride the suite's uniform --catalog json contract, so they stay in sync as the CLIs evolve.

Safety

• Signing is human-gated. Only sign-cli's read/verify operations are exposed (verify_signature, verify_receipt, audit_show) — never request-create or sign. This is enforced: the run/catalog escape hatches reject any sign subcommand outside a read-only allowlist, so request-create/send/sign/approve can't be reached here. Those stay behind sign-cli's own MCP server with its per-signer approval tokens, so this server can't become an unguarded signing path.
• Filesystem lockdown. File-path arguments to the curated tools are confined to CONTRACT_OPS_MCP_BASE_DIR (default: the working directory). Set it to widen the sandbox.
• No shell. CLIs are invoked with execFile (no shell interpolation).

License

MIT. Part of the contract-ops CLI suite. See AGENTS.md for the agent contract.