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 |
Capabilities
Features and capabilities supported by this server
| 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 | |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/disciplin-run-org/turbosign-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server