Send a Contract for Signature from Cursor

Sending a contract is not a coding task, which is exactly why doing it from Cursor is useful. The interruption is not the work — it is the context switch: leaving the editor, finding the dashboard tab, retyping an email address that is already in the terminal scrollback above you.

Signvoy's MCP server works in Cursor over streamable HTTP with no install and no API key. Here is the setup and the handful of workflows that actually earn their place.

Configure Cursor

Create .cursor/mcp.json in your project root:

{
  "mcpServers": {
    "signvoy": {
      "url": "https://api.signvoy.com/mcp",
      "transport": "streamable-http"
    }
  }
}

Cursor detects the file and lists the server under Settings → MCP. Click to authorize, approve the browser consent screen, and the tools appear.

Note what is not in that file: no key, no token, no secret. The server implements OAuth 2.1 with Dynamic Client Registration, so Cursor registers itself and holds a short-lived token scoped to one workspace. That property is what makes the file safe to commit — a teammate who clones the repository gets the integration and authorizes with their own Signvoy account. Do not extend that habit to servers that expect a static API key in the same file, which is the more common design in this category.

Project or global

Both scopes exist and the choice is straightforward.

.cursor/mcp.json in a repository applies to that project and is visible to everyone who clones it. Use it when the integration is part of the project — a repo where you send contracts, or a signing integration you are building.

~/.cursor/mcp.json applies to every project you open and stays private to your machine. Use it when Signvoy is a personal utility rather than a project dependency.

If both define a signvoy entry, the project-level file wins for that project.

Verify

Open the chat and ask for something that needs a read tool:

List my Signvoy templates.

A list of names means you are connected. Two failure modes cover nearly everything else: the server is listed but shows no tools, which means OAuth was never completed — look for a sign-in prompt on the entry in Settings → MCP; or the server shows a red status, which means the URL is wrong or unreachable. The troubleshooting guide has the rest, including the JSON-RPC error codes.

One local-development note: if you are pointing at a Signvoy instance you are running yourself, check the port. The example config in the repository uses 4000 while the API defaults to 3001, and the resulting failure looks like a connection error rather than a configuration mistake.

Workflows worth having

Send from the terminal you are already in. You just finished a contractor's onboarding script and need their NDA signed:

Send the contractor NDA to Priya at priya@example.com.

Cursor calls signvoy_list_templates, then signvoy_get_template to read the recipient role keys — a template might define signer and witness, and each recipient must match one. Then signvoy_create_document, and it stops. What comes back is a draft plus a review_url. No email has gone out. You open the link, check the document, and confirm before signvoy_send_document runs.

The two-call structure is deliberate: an agent misreading "draft an NDA" as "send an NDA" produces something you delete rather than something in a counterparty's inbox.

Check status without leaving the editor.

Which Signvoy documents are still waiting on signatures?

signvoy_list_documents filtered by status, then signvoy_get_document_status for per-recipient detail with timestamps. Add "remind whoever is outstanding on the Acme MSA" and it calls signvoy_remind_document once.

Build against the API with the schemas in context. This is the workflow unique to an editor, and the best reason to have the server configured while you code.

I'm adding signature requests to our onboarding flow. Look at the Signvoy MCP tools to see the document lifecycle, then write the integration against the REST API.

Cursor reads the live tool schemas — parameters, return shapes, status constraints — and uses them as a specification while writing your code. Then you send a real test document through the same server and watch the status transitions. Write the integration and verify it in one loop, without a browser.

Worth being clear about the boundary: the MCP server is for interactive work. Production code should call the REST API with @signvoy/node, retries and webhooks. A model-driven MCP call is the wrong shape for a job that runs ten thousand times a day. Build an AI agent that sends contracts covers using both together.

Debug a signing flow.

Get the audit trail for the Acme MSA.

signvoy_get_audit_trail returns the append-only event log — send, view, sign, decline, void and remind, with actor, IP address and timestamp. Anything an agent did is tagged actorSource: "mcp", so when you are reconstructing why a test document behaved oddly, agent activity stays distinguishable from your own dashboard clicks.

What to expect from Cursor's agent

Two habits that make the difference between this working smoothly and being fiddly.

Name the template. "Send the contractor NDA" beats "send an NDA." With several similarly named templates the model will sometimes pick wrong, and you will not notice until the review step.

Supply the email address. The agent cannot invent a contact. Giving it the address up front avoids a send_blockers round trip through signvoy_update_document — and note that passing recipients to that tool replaces the whole list rather than merging, so a multi-signer fix touches every recipient.

Get started

Create a free Signvoy account, publish one template, then drop the config above into .cursor/mcp.json. The Cursor setup guide has the details, and the thirteen-tool reference documents every parameter and return shape.