turbosign-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TURBOSIGN_HOME | No | Credential store location. | ~/.turbosign-mcp |
| TURBODOCX_ORG_ID | No | Value for the x-rapiddocx-org-id header. | |
| TURBODOCX_API_KEY | No | Bearer token for TurboDocx API. | |
| TURBODOCX_APP_URL | No | Console URL, used for turbosign_setup. | https://app.turbodocx.com |
| TURBOSIGN_TIMEOUT | No | Per-request timeout in seconds. | 90 |
| TURBODOCX_BASE_URL | No | Base URL for the API. | https://api.turbodocx.com |
| TURBODOCX_SIGNUP_URL | No | Signup URL. | https://www.turbodocx.com |
| TURBODOCX_SENDER_NAME | No | Shown in the request emails. Defaults to API key's name. | |
| TURBOSIGN_MAX_FILE_MB | No | Upload cap in megabytes. | 10 |
| TURBODOCX_SENDER_EMAIL | No | Reply-to email address; the API rejects sends without it. | |
| TURBOSIGN_ALLOWED_DIRS | No | Root directories documents may be sent from. | $HOME |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| turbosign_setupA | Start here on a machine that has never sent a signature request. Reports which credentials are missing and where the present ones came from, then gives the URLs for creating a TurboDocx account and finding the API key and organization id. Follow the URLs, then call turbosign_configure() with the three values. Set open_browser=True to also try opening the console locally — it is best-effort and reports whether it worked, since a server without a desktop has no browser to open. |
| turbosign_configureA | Save this machine's TurboDocx credentials after checking they work. The credentials are verified against the live API before anything is written, so a mistyped key fails here rather than on your first real send. They are stored owner-only in ~/.turbosign-mcp/credentials.json. Get the values from turbosign_setup(). sender_email is the reply-to address recipients see. sender_name is optional and defaults to the name on the API key. base_url is only for a non-production endpoint. The key is never echoed back — only a masked fingerprint. PRIVACY: whatever you pass here travels through this conversation and is written to its transcript on disk. For a scoped key on a test account that is usually fine. For a long-lived key, or a session token that can do everything the user can, tell the human to run this in their own terminal instead — same verification, same store, and the key never enters the conversation: |
| turbosign_whoamiA | Show which TurboDocx account this machine sends as. Reports the masked API key, organization id, sender address, and where each value was resolved from — useful when the same server is installed on several machines with different accounts. With verify=True it also checks the credentials against the live API. |
| get_instructionsA | Return this server's usage instructions and recommended workflow. Call this after a context compaction, or whenever it is unclear which tool to reach for. |
| refresh_toolsA | Refresh the client's cached tool list after a server restart or upgrade. Call this instead of falling back to raw HTTP requests. |
| turbosign_sendA | Send a document out for signature. This emails the recipients. THERE IS NO SANDBOX — TurboSign has one environment and it is production. This reaches a real inbox and cannot be recalled, only voided. On a new machine, new document layout or new account, run turbosign_whoami(verify=True) then turbosign_review() first, and make your first real send to your own address. turbosign_review() takes these exact arguments and emails nobody. file_path: absolute path to a PDF (DOCX and PPTX also work, but only with an explicit anchor or fields, since they cannot be measured). recipients: "Bob Smith bob@example.com, ann@example.com", or a JSON array of {name, email} objects. placement: "auto" reads the document, uses {Signature1}-style anchors if they are there, and otherwise places a signature and date box per recipient at the foot of the last page. "anchor" requires anchors. "coordinates" forces automatic positioning. "explicit" requires a fields array. sequential: false (default) lets everyone sign at once; true makes them sign in the order listed. Returns the document_id — keep it, every other tool needs it. |
| turbosign_reviewA | Prepare a document and get a preview URL WITHOUT emailing anyone. Same arguments as turbosign_send. Use this to check where the signature boxes landed before committing to a real send — open the returned preview_url in a browser and look. Worth doing the first time you send a particular kind of document. |
| turbosign_statusA | Check where a signature request has got to. Reports the document's state (pending, completed, voided) and, where the API returns them, each recipient's state and id. The recipient ids are what turbosign_resend() needs. |
| turbosign_downloadA | Download a completed signed document to a local file. Only completed documents can be downloaded. output_path must be an absolute path in an existing directory. |
| turbosign_voidA | Cancel a signature request that has not completed. The reason is recorded in the audit trail and is required. This cannot be undone — send the document again if you need to restart. |
| turbosign_resendA | Resend the signature request email to recipients who have not signed. recipient_ids is a comma-separated list of recipient UUIDs — get them from turbosign_status(). Only recipients whose turn it is in the signing order will actually be emailed. |
| turbosign_audit_trailA | Get the tamper-evident history of a document. Returns hash-chained entries — prepared, sent, viewed, signed, voided — newest last. Use this to answer "has Bob opened it yet?". |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Each tool has a unique, focused purpose: setup guides credential configuration, configure saves credentials, whoami displays current identity, send/review/status/download/void/resend/audit_trail handle distinct stages of the signing workflow, and get_instructions/refresh_tools are server utilities. The only near-overlap is send vs review, but the explicit 'emails nobody' distinction makes them unambiguous.
Ten of twelve tools use the turbosign_ prefix, which is a strong pattern, but get_instructions and refresh_tools break it. Within the prefixed tools, some names are verbs (send, review, download) and some are nouns (status, audit_trail, whoami), so the convention is not perfectly uniform.
With 12 tools, the server covers the full signing lifecycle plus setup and utility functions without redundancy. This is a well-scoped size for an e-signature MCP server.
The toolset covers the entire document signing workflow: credential setup, configure, send, review, status, download, void, resend, and audit trail. Minor gaps, like a list-documents tool, but the core workflows are fully supported.