MCP Server

@theterms/mcp is a Model Context Protocol server that exposes the TheTerms REST API as tools for AI coding and agent clients. Instead of hand-writing REST calls, you can ask an MCP-aware assistant to list containers, draft and publish documents, and send signing requests conversationally.

The server communicates over stdio — it runs as a local subprocess of your MCP client, not a hosted or remote service. There is no OAuth flow or URL to configure; you provide the same API key you’d use for direct REST access.

Supported Clients

Any MCP client that supports stdio-transport servers can use @theterms/mcp, including:

• Claude Code
• Claude Desktop
• Cursor
• Other stdio-MCP-compatible clients

Installation & Configuration

Add @theterms/mcp to your client’s MCP server configuration. Most clients use an mcpServers block in JSON, launching the package via npx:

{
  "mcpServers": {
    "theterms": {
      "command": "npx",
      "args": ["-y", "@theterms/mcp"],
      "env": {
        "THETERMS_API_KEY": "tt_your_api_key_here",
        "THETERMS_API_BASE_URL": "https://app.theterms.app/api/v1"
      }
    }
  }
}

Caution

THETERMS_API_BASE_URL must include the /api/v1 suffix. Each tool appends a bare resource path (e.g. /containers, /documents/{id}/draft) directly onto this base URL, so a value ending in anything other than /api/v1 will 404 on every call.

See Authentication for how to create a THETERMS_API_KEY — the same org-scoped API key used for direct REST access works here, sent as the X-Api-Key header on every request the server makes on your behalf.

Tool Reference

The server exposes exactly 10 tools — no webhook or template tools, no delete operations.

Tool	Description	Key Inputs
list_containers	List all containers (top-level document collections) in your organization. Takes no input.	—
create_container	Create a new container — a top-level collection that documents are organized into.	name (required, 1–100 chars), description (optional, ≤500 chars)
list_documents	List documents within a specific container.	containerId (required, UUID)
get_document	Get a single document by id, including all of its versions (draft, active/published, and archived) under versions. Each version has its own id, which is the versionId used by tools like send_signing_request.	id (required, UUID)
create_document	Create a new document inside a container. This also creates the document’s initial DRAFT version, but the response contains only the document record — it does not include the new draft version’s id. Call get_document afterward if you need that version’s id.	containerId (required, UUID), name (required, 1–100 chars), description (optional, ≤500 chars)
update_draft	Replace a document’s current draft version’s content (clauses) and settings. This replaces the entire clauses array — there is no patch/merge on the server, so any clause you omit is permanently deleted. You must call get_document first to fetch the current draft, then pass its full content.clauses array back here alongside any edits.	id (required, UUID), content.clauses (full array), settings (expiry_days, redirect_url)
publish_document	Publish a document’s current draft version, making it the active, signable version. No request body.	id (required, UUID)
send_signing_request	Create a signing request — send a signing invite to a signer for a specific, already-published document version. Requires a versionId, not a documentId, and the target version must already be published (ACTIVE), not a draft. To obtain a versionId, call get_document and read the id of the entry in its versions array with status ACTIVE. create_document’s response does not include a version id — only get_document, update_draft, and publish_document responses carry the version record itself.	versionId (required, UUID), signerName (required), signerEmail (required, valid email)
get_signing_request	Get a single signing request by id, including its current status (PENDING, ACCEPTED_FULL, ACCEPTED_PARTIAL, REJECTED, VOIDED, or EXPIRED).	id (required, UUID)
list_signing_requests	List signing requests for your organization, optionally filtered by status, versionId, free-text search, or a relative date range, with pagination via limit/offset.	status, versionId, search, dateRange (7d/30d/90d), sortBy, sortDir, limit (default 25, max 100), offset — all optional

Tip

update_draft and send_signing_request are the two tools most likely to trip up an agent: update_draft requires the full clause list on every call (no partial patch), and send_signing_request needs a version’s id, not the document’s id. Both descriptions above call this out for exactly that reason.

Known Limitations

Note

Attribution. Every action taken through the MCP server is attributed to the organization’s owner in TheTerms’ activity records, regardless of which team member’s API key was actually used to authenticate the request. This is a pre-existing characteristic of the REST API’s current API-key auth model — it applies to any API-key-based integration, not something specific to or introduced by the MCP server, and the MCP server cannot change it.

Caution

Rate limiting. The REST API enforces a per-API-key rate limit (a token-bucket limit on requests per minute at the time of writing — subject to change, so treat the exact numbers as informational rather than a fixed contract). Heavy conversational use in a short window can hit this limit. When it does, the server surfaces a clear, retryable tool error (rather than crashing or hanging) so your MCP client can back off and retry.