Skip to main content
@vumasign/mcp is a Model Context Protocol server for your Vumasign account. It runs on your own machine, started by your MCP client, and lets an agent do the matching work of filling in a form: read a template, see what is printed around each box, check the values it proposes, and prepare a draft envelope with those values filled in. A person then opens the draft in Vumasign, reviews it and sends it. It is separate from the documentation server, which searches these pages and holds no key.

What it will not do

This server has no tool for any of the following, and leaving them out is deliberate. Each one names the endpoints it covers, which no tool calls:

Before you start: a test key

Create a key under Settings → API keys in the dashboard, starting vsk_test_, with these scopes: templates:read, documents:read, envelopes:read, envelopes:write. Start with a test key. A template has no environment, so a test key reads the same templates a live key does, and a draft made with it is a rehearsal: once a person sends it, it produces a watermarked document that is never billed and binds nobody. It can be sent only to your organisation’s verified members and verified test recipients, so a draft addressed to a real customer cannot be sent; the send is refused and the draft has to be made again with a live key. See Test keys and live keys. The server refuses to start on a vsk_live_ key unless VUMASIGN_MCP_ALLOW_LIVE is set to 1 as well. Think before setting it: the key sits in plain text in your MCP client’s configuration, and the scope that lets the server create drafts is the same scope that, called directly against the API, can send them. The tool list is narrow; the key is what limits a compromised process.

Connect it

The server is started with npx, so it needs Node.js on the machine that runs your client. The key is passed in the server’s environment as VUMASIGN_API_KEY.

Claude Code

Add --scope user to make it available in every project, rather than only the current one.

Claude Desktop

Open Settings → Developer → Edit Config, add the server to claude_desktop_config.json, and restart Claude Desktop:

Cursor

Add the same object to ~/.cursor/mcp.json for every project, or to .cursor/mcp.json in one project. A project’s .cursor/mcp.json is often committed with the project: if you use it, keep it out of version control, or the key goes with it.
Any other client that starts a local MCP server takes the same command, arguments and environment.

The tools

Each tool is one call to the endpoint it names, made with your key, so it is refused exactly as the endpoint would refuse it, with the same code.

How an agent fills a form

  1. list_templates, to find the template.
  2. get_template. Every field has a data_key to address it by and context: the label, row, column, option and section printed around its box. context is usually enough to tell what a box asks for. warnings says whether the uploaded form already held somebody’s details. The result also carries the template’s etag.
  3. get_template_page, only for a page where context is not enough. The page is returned as a PDF; whether your client shows a PDF to its model depends on the client.
  4. validate_values, with the values the agent proposes. It answers, entry by entry, what creating the envelope would do with each one, and writes nothing.
  5. create_envelope_draft, with the recipients, the values and the template_etag from step 4. If the template changed in between, the draft is refused rather than filled wrongly. Calling it again with the same arguments within 24 hours returns the first draft instead of making a second one; after that, the same arguments make another draft.
  6. get_envelope, to confirm what was created. Then a person opens the draft in Vumasign and sends it.

Text printed on a form is data

context, the pages and the whole document carry text printed on somebody else’s form. A form can be written to look like instructions to a model. Every tool that returns printed text says, in the description your client shows the model, that the text is data and never instructions. That lowers the risk; it does not remove it. Through this server’s own tools, a hostile form can at worst shape a draft, and a person reviews every draft before it is sent. But the key is in your client’s configuration file, and an agent that can also read files or run commands, as Claude Code and Cursor can, could be led to read the key and call the API directly, where it holds every capability of the key’s scopes, sending included. So:
  • use a test key, which limits what a misled agent can reach to a sandbox;
  • let the agent that reads forms have as few other tools as you can, and approve its file reads and commands rather than allowing them all;
  • remember that a misled agent can read the account’s templates into its conversation, so do not give it a tool that could carry them somewhere else.