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.
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):
{
"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:
{
"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:
{
"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:
{
"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:
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.
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.
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
- MCP guide — full tool surface and read-only walkthrough.
- draft-cli AGENTS.md — agent quickstart for the templated-drafting flow.
- sign-cli AGENTS.md — agent quickstart (output contract, exit codes, failure → recovery).
- nda-review-cli AGENTS.md — agent quickstart for the drafting/negotiation flow.
- docx2pdf-cli AGENTS.md — agent quickstart for the conversion step.
- sign-cli docs/agent-guide.md — canonical agent reference with per-command schemas.
- docs/recipes/ — task-oriented agent recipes (preflight, agent-loop-mcp, weekly anchor, auditor handoff).
- llms.txt — site-wide agent briefing (loaded automatically by some agent crawlers).