Skip to content
contract.cli

Agent integrations

Built for Claude, Cursor, Codex — and anything that speaks MCP.

sign-cli ships a 19-tool MCP stdio server. Wire it into any MCP-aware client and the agent gets typed, schema-validated tools for the entire signing surface — with the per-signer-token guardrail intact so the agent can drive every step except the actual signing gesture.

One install, every client — npm i -g @drbaher/sign-cli — then drop the wire-up snippet below into your client's MCP config. Every command is also a stable MCP tool with input/output schemas; agents discover the live catalog via sign mcp tools.

Smithery — one-click install (no setup)

The fastest path for Claude Desktop, Cursor, Codex, and any other Smithery-aware client: head to the hosted listing and follow the per-client install flow.

smithery.ai/servers/drbaher/sign-cli ↗

The Smithery listing exposes the same 19 tools / 4 prompts / 12 resources as the local stdio path. It runs against an ephemeral demo database (read-only mode, wiped every 4 hours) so it's safe to explore but not suitable for real signing — for that, use the local install with the wire-up snippets below.

Claude Code

Add to ~/.config/claude-code/settings.json (or the project-level .claude/settings.json):

.claude/settings.json
{
  "mcpServers": {
    "sign-cli": {
      "command": "npx",
      "args": ["-y", "@drbaher/sign-cli", "mcp", "serve"]
    }
  }
}

After Claude Code restarts, every sign-cli MCP tool shows up. Ask the agent to "send contract.pdf to alice@acme.com and bob@beta.com via SignWell" and it will call the right tools with the right arguments. The agent never sees per-signer tokens — those go to the human signers directly.

Claude Desktop

Same as Claude Code, but the file is ~/Library/Application Support/Claude/claude_desktop_config.json on macOS:

claude_desktop_config.json
{
  "mcpServers": {
    "sign-cli": {
      "command": "npx",
      "args": ["-y", "@drbaher/sign-cli", "mcp", "serve"],
      "env": {
        "SIGN_DB_PATH": "/Users/you/.sign-cli/data.db",
        "SIGN_LOCAL_AUTOCOMPLETE": "false"
      }
    }
  }
}

The env block is optional. Setting SIGN_DB_PATH pins the persistent storage location so multiple Claude Desktop sessions share state. SIGN_LOCAL_AUTOCOMPLETE=false tells the local provider to hold at "sent" until a signer explicitly runs sign sign — required for the agent-as-signer flow.

Cursor

Cursor's MCP config lives at ~/.cursor/mcp.json:

~/.cursor/mcp.json
{
  "mcpServers": {
    "sign-cli": {
      "command": "npx",
      "args": ["-y", "@drbaher/sign-cli", "mcp", "serve"],
      "env": {}
    }
  }
}

Cursor's agent will see the tool catalog on next restart. Ask it to verify a signed PDF or detect a signature field in any document open in the workspace — the tool calls work the same way.

Codex / GitHub Copilot Workspace

Codex and similar OpenAI-based agents support MCP via the same mcpServers config shape. The exact location varies; recent versions read ~/.config/openai-codex/mcp.json. Same JSON as Cursor:

codex MCP config
{
  "mcpServers": {
    "sign-cli": {
      "command": "npx",
      "args": ["-y", "@drbaher/sign-cli", "mcp", "serve"]
    }
  }
}

OpenAI Agents SDK

The OpenAI Agents SDK can attach MCP servers as tool sources. For Python:

Python
from agents import Agent
from agents.mcp import MCPServerStdio

sign_server = MCPServerStdio(
    name="sign-cli",
    params={"command": "npx", "args": ["-y", "@drbaher/sign-cli", "mcp", "serve"]},
)

agent = Agent(
    name="Contract Ops",
    instructions="Help the user send, track, and verify PDFs for signature.",
    mcp_servers=[sign_server],
)

langchain (Python or JS)

langchain doesn't speak MCP natively, but you can either use the langchain-mcp-adapters package or wrap the CLI directly. The langchain wrapper starter is shipped in integrations/ in the sign-cli repo.

HTTP / non-MCP clients

If your agent framework doesn't speak MCP, sign-cli also exposes the same 19-tool surface as 20 HTTP routes at /v1/* via sign serve:

sign serve --port 4000 --auth-token <bearer> --read-only true --rate-limit 5
curl http://localhost:4000/v1/openapi.json    # full OpenAPI 3.1 spec

Every MCP tool has a 1:1 HTTP equivalent. Same input shape, same path-traversal guards, same read-only gating. Useful for langchain, Llama Index, AutoGen, CrewAI, or any framework that can speak REST.

Sandboxed mode

For agents that should inspect and track without mutating state, run with --read-only true and an explicit tool allow-list:

sign mcp serve --read-only true \
  --tool request_show --tool audit_verify --tool pdf_detect_signature_field \
  --tool pdf_inspect_signatures \
  --emit-events ./mcp-events.ndjson \
  --emit-events-redact true

Mutating tools return FORBIDDEN_READ_ONLY with exit 3. --emit-events writes one NDJSON line per tool call to disk for replay or audit. --emit-events-redact true masks token-shaped fields in the log.

The asymmetry: what the agent can and can't do

Agent does Human approves
Send a PDF to one or many signers The actual signing gesture (per-signer token)
Track status, retry, rotate providers Provider configuration changes (`sign init`, secret writes)
Verify signed PDFs + audit chains offline Audit-chain anomalies surfaced for investigation
Anchor with RFC 3161 timestamps Anything outside declared per-signer / TTL guardrails
Detect signature fields, stamp previews, draft NDAs Sign-off before finalize on negotiations

The mechanism is the per-signer approval token: TTL-bounded, scoped to one email, single-use. The requester (which can be the agent) holds the token at create-time and DMs it to the human signer; the signer pastes it into sign sign --token .... The agent never sees signer tokens. Pre-sign safety checks (--require-hash / --require-title / --require-signer-email) throw structured errors before any state mutation, so an agent computing a hash earlier can refuse to sign if the document was swapped in flight.

The other two CLIs — agent-friendly, not MCP servers

sign-cli ships an MCP server because it's the one with persistent state (a signing request is a multi-step object that benefits from typed tools). The other two CLIs in the suite are pure functions: they take input, return output. For those, agents drive them directly over stdio with a stable JSON contract.

nda-review-cli — drafting + reviewing + negotiating

Single-file Python (stdlib only at runtime). Every command emits structured output behind --json; deterministic-by-default, opt-in LLM adjudication via Anthropic / OpenAI / Ollama. The two-party negotiation flow uses a hash-chained JSON state file that bounces between counterparties — each round is signed by exactly one party and tampering is detected on load.

agent loop: review a counterparty NDA
nda-review-cli --catalog json                     # discover commands + flags
nda-review-cli draft --template mutual-nda > our.json  # seed our position
nda-review-cli review counterparty.json --json   # score against house policy
nda-review-cli negotiate --party-a our.json \
                          --party-b counterparty.json \
                          --stance-a conservative \
                          --json                  # round-by-round JSON output

Hash-chained state, deterministic stance + clause priority engine, fatigue-concession rule that force-resolves clauses that have bounced too many times. The agent drives every step; humans only sign each finalized round (via sign-cli, optionally).

docx2pdf-cli — the conversion step

Node.js. Six hybrid backends auto-selected by availability (LibreOffice, Gotenberg, ConvertAPI, Pages, Word, textutil-cups). --capabilities returns a stable JSON contract; --doctor probes host readiness and emits per-host install commands so the agent can self-check before invoking.

agent preflight + batch convert
docx2pdf --capabilities                # which flags exist, on this version
docx2pdf --doctor json                 # which backends are usable on this host
docx2pdf --catalog json                # full CLI command + flag inventory
docx2pdf in.docx out.pdf --json        # one-shot, structured success/error
docx2pdf --batch jobs.ndjson \
         --concurrency 4 --json        # NDJSON in/out for batch flows

Success rows include outputBytes and durationMs; failures include exitCode. --strict-fidelity refuses the text-only fallback when the agent needs a guarantee that the visual layout was preserved. --why prints the backend-selection decision tree for debugging.

Discovery — never hardcode

Three commands every agent should call at startup rather than parsing prose:

sign --catalog json    # full CLI command + flag inventory
sign mcp tools         # live MCP tool catalog (inputSchema + outputSchema per tool)
sign --version

The same pattern works across the suite — draft --list-placeholders --json, nda-review-cli --catalog json, and docx2pdf --capabilities are the corresponding discovery commands for the other CLIs.

See also

Edit this page on GitHub