What can you do with this server?

The SendForSign MCP Server provides template management integration with the SendForSign API, offering dual transport modes and flexible authentication. Core Features: * Template Operations: List all available templates with metadata and retrieve specific template content using template keys * Dual Transport Support: stdio transport for MCP clients and HTTP Stream transport for web APIs and custom integrations * Flexible Authentication: API keys via environment variables (SFS_API_KEY, SFS_CLIENT_KEY) or HTTP headers (X-Sendforsign-Key, X-Client-Key, Authorization: Bearer) * Client Override: Override default client key for specific operations via clientKey parameter Deployment & Monitoring: * Docker containerization for easy deployment and scaling * Health check endpoint (/health) for monitoring server status * TypeScript-based with comprehensive development environment

Which integrations are available for this server?

Provides integration with n8n workflow automation through HTTP Stream transport, allowing n8n workflows to access SendForSign templates and manage document signing processes.

How do I use SendForSign MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SendForSign MCP Server list my available document templates" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

SendForSign MCP Server

Official

by sendforsign

Overview Schema Source Related Servers Discussions Admin

JavaScript

Hybrid

A Model Context Protocol (MCP) server implementation that integrates with Sendforsign for document template management and signing workflows.

Features

Template listing and content reading
Flexible authentication (API keys via env vars or HTTP headers)
Dual transport support (stdio for MCP clients, HTTP Stream for web APIs)
Docker ready deployment
Health monitoring

Related MCP server: BoldSign MCP Server

Installation

Running with npx

env SFS_API_KEY=YOUR_API_KEY SFS_CLIENT_KEY=YOUR_CLIENT_KEY npx -y @sendforsign/mcp

Manual Installation

npm install -g @sendforsign/mcp

Running on Cursor

For the most up-to-date configuration instructions, please refer to the official Cursor documentation on configuring MCP servers: Cursor MCP Server Configuration Guide

To configure SendForSign MCP in Cursor:

Open Cursor Settings
Go to Features > MCP Servers
Click "+ Add new global MCP server"

Enter the following code:

{
  "mcpServers": {
    "sendforsign-mcp": {
      "command": "npx",
      "args": ["-y", "@sendforsign/mcp"],
      "env": {
        "SFS_API_KEY": "YOUR-API-KEY",
        "SFS_CLIENT_KEY": "YOUR-CLIENT-KEY"
      }
    }
  }
}

Running on Windsurf

Add this to your ./codeium/windsurf/model_config.json:

{
  "mcpServers": {
    "sendforsign-mcp": {
      "command": "npx",
      "args": ["-y", "@sendforsign/mcp"],
      "env": {
        "SFS_API_KEY": "YOUR_API_KEY",
        "SFS_CLIENT_KEY": "YOUR_CLIENT_KEY"
      }
    }
  }
}

Running with HTTP Stream Mode

To run the server using HTTP Stream locally instead of the default stdio transport:

# Option 1: Using HTTP_STREAMABLE_SERVER
env HTTP_STREAMABLE_SERVER=true SFS_API_KEY=YOUR_API_KEY SFS_CLIENT_KEY=YOUR_CLIENT_KEY npx -y @sendforsign/mcp

# Option 2: Using CLOUD_SERVICE
env CLOUD_SERVICE=true SFS_API_KEY=YOUR_API_KEY SFS_CLIENT_KEY=YOUR_CLIENT_KEY npx -y @sendforsign/mcp

Use the url: http://localhost:3000/mcp

Configuration

Environment Variables

Required

SFS_API_KEY: Your SendForSign API key
SFS_CLIENT_KEY: Your SendForSign client key

Optional

HTTP_STREAMABLE_SERVER: Set to true to enable HTTP Stream transport
CLOUD_SERVICE: Set to true to enable HTTP Stream transport (alternative to HTTP_STREAMABLE_SERVER)
SSE_LOCAL: Set to true to enable HTTP Stream transport (alternative to HTTP_STREAMABLE_SERVER)
PORT: Server port (default: 3000)
HOST: Server host (default: localhost)

Usage with Claude Desktop

Add this to your claude_desktop_config.json:

{
  "mcpServers": {
    "sendforsign-mcp": {
      "command": "npx",
      "args": ["-y", "@sendforsign/mcp"],
      "env": {
        "SFS_API_KEY": "YOUR_API_KEY_HERE",
        "SFS_CLIENT_KEY": "YOUR_CLIENT_KEY_HERE"
      }
    }
  }
}

Available Tools

1. List Templates (`sfs_list_templates`)

List all SendForSign templates for the authenticated client.

Best for:

Discovering available templates
Getting template metadata

Usage Example:

{
  "name": "sfs_list_templates",
  "arguments": {}
}

Returns: Array of templates with their keys and metadata.

2. Read Template (`sfs_read_template`)

Read the content of a specific SendForSign template.

Best for:

Getting template content for editing or analysis
Template inspection

Usage Example:

{
  "name": "sfs_read_template",
  "arguments": {
    "templateKey": "your-template-key"
  }
}

Returns: Template content and metadata.

HTTP Stream API

When running in HTTP Stream mode, the server provides REST endpoints:

GET /health - Health check
POST /mcp - MCP protocol endpoint

Authentication via HTTP Headers

Send API keys in HTTP headers:

API Key (choose one):

X-Sendforsign-Key: YOUR-API-KEY
X-Api-Key: YOUR-API-KEY

Client Key:

X-Client-Key: YOUR-CLIENT-KEY

Example API Call

curl -X POST http://localhost:3000/mcp \
  -H "Content-Type: application/json" \
  -H "X-Sendforsign-Key: YOUR-API-KEY" \
  -H "X-Client-Key: YOUR-CLIENT-KEY" \
  -d '{"jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": {}}'

Docker Deployment

Build and Run

# Build image
docker build -t sendforsign/mcp:latest .

# Run container
docker run --rm -p 3000:3000 \
  -e CLOUD_SERVICE=true \
  -e SFS_API_KEY=YOUR-API-KEY \
  -e SFS_CLIENT_KEY=YOUR-CLIENT-KEY \
  sendforsign/mcp:latest

Health Check

curl -sS http://localhost:3000/health

Development

# Install dependencies
npm install

# Build
npm run build

# Run development server
npm run dev

License

MIT License - see LICENSE file for details

Available Tools

2 tools

sfs_list_templatesC

List SendForSign templates and their keys for the current clientKey.

ParametersJSON Schema

Name	Required	Description	Default
`clientKey`	No

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states it's a list operation, implying read-only behavior, but doesn't disclose details like pagination, rate limits, authentication needs, or what happens if clientKey is invalid. For a tool with no annotations, this lacks critical behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, direct sentence with no wasted words, front-loading the key action and resource. It's appropriately sized for a simple list tool, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, 0% schema coverage, no output schema, and a sibling tool, the description is incomplete. It covers the basic purpose but misses usage differentiation, parameter details, behavioral traits, and output information, leaving significant gaps for agent understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It mentions 'clientKey' as a parameter, adding some meaning beyond the schema, but doesn't explain its role (e.g., how it affects the listing, if it's optional or required). With 1 parameter and low coverage, this is insufficient to fully clarify semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resource 'SendForSign templates and their keys', making the purpose understandable. It doesn't distinguish from the sibling tool 'sfs_read_template', which likely reads a specific template rather than listing them, but the basic action is clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides minimal guidance by specifying 'for the current clientKey', implying usage when you have a clientKey context. However, it doesn't explain when to use this tool versus the sibling 'sfs_read_template' or any other alternatives, leaving gaps in contextual decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sfs_read_templateC

Read a SendForSign template content by templateKey.

ParametersJSON Schema

Name	Required	Description	Default
`clientKey`	No
`templateKey`	Yes

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Read' which implies a read-only operation, but doesn't clarify permissions, rate limits, error handling, or what 'content' entails (e.g., metadata, fields, or full template). For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes directly to the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (2 parameters, no annotations, no output schema), the description is incomplete. It lacks details on parameters, behavioral traits, and output expectations. For a read operation with undocumented parameters, more context is needed to fully understand how to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the schema provides no parameter details. The description mentions 'by templateKey', which maps to one of the two parameters, but doesn't explain 'clientKey' or provide any semantic context for either parameter (e.g., format, source, or purpose). It adds minimal value beyond the schema's structural information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Read') and resource ('SendForSign template content by templateKey'), making the purpose understandable. It doesn't explicitly differentiate from its sibling 'sfs_list_templates', which would list templates rather than read a specific one's content, but the distinction is implied through the verb 'Read' versus 'List'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It mentions 'by templateKey' but doesn't specify prerequisites, such as needing a valid templateKey or when to choose this over 'sfs_list_templates'. There's no explicit when/when-not or alternative usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesv1.0.0Sep 30, 2025
- First observedsfs_list_templates
- First observedsfs_read_template

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3/5.0

Scored 2026-04-18 08:35 across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one lists templates with their keys, while the other reads the content of a specific template. There is no overlap in functionality, and an agent can easily differentiate between them based on their descriptions.

Naming Consistency5/5

Both tools follow a consistent 'sfs_verb_noun' naming pattern, using snake_case and starting with the 'sfs' prefix. The verbs 'list' and 'read' are appropriately descriptive and aligned with common conventions for such operations.

Tool Count2/5

With only two tools, the server feels under-scoped for a SendForSign domain, which typically involves more operations like creating, updating, or sending templates for signing. The count is too low to support comprehensive workflows, limiting agent capabilities.

Completeness2/5

The tool surface is severely incomplete for a SendForSign server. It lacks essential CRUD operations such as creating, updating, or deleting templates, as well as core actions like sending documents for signing or managing signatures. This will cause significant agent failures in handling typical e-signature tasks.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

APISign A
io.apisign
Send documents for legally binding e-signature and manage the reusable templates behind them.
Legal & Compliance Workplace & Productivity
121
Aoexl Sign
io.github.AryanSingh
Create signing requests, check status, send reminders, and manage Aoexl templates.
App Automation Workplace & Productivity
2
SignatureAPIOAuth
com.signatureapi
E-signature API: send documents for signature, track envelopes, get signed files.
Legal & Compliance App Automation
1
FormifyOAuth
eu.formify
Send agreements for e-signing, use templates, track signatures, send reminders, get signed documents
Legal & Compliance Workplace & Productivity
1

Related MCP Servers

MCP Server for eSignatures
Legal & Compliance App Automation
esignaturescom
A
license
B
quality
C
maintenance
Facilitates contract and template management for eSignatures, enabling users to create, send, update, and manage contracts and templates with customizable options through a user-friendly interface.
Updated 2 months ago (2026-07-14 13:13 UTC)
13
28 PyPI
40
MIT
BoldSign MCP Server
App Automation Developer Tools
Synctest-hub
A
license
A
quality
D
maintenance
Enables interaction with the BoldSign e-signature platform through its API. Supports managing documents, templates, contacts, users, and teams for electronic signature workflows.
Updated a year ago (2025-08-26 05:02 UTC)
14
71 npm
MIT
docuseal-mcp-server
App Automation Legal & Compliance Documentation Access
caffeinebounce
F
license
A
quality
F
maintenance
Enables interaction with DocuSeal instances to manage document templates, create signature requests, and track submission statuses. It provides tools for uploading PDFs, managing submitters, and downloading signed documents via the DocuSeal API.
Updated 7 months ago (2026-02-17 02:37 UTC)
10
-
eSignatures MCP Server
Legal & Compliance Workplace & Productivity
mikeysrecipes
A
license
A
quality
D
maintenance
Enables managing electronic signatures and contracts through the eSignatures API, including creating, sending, and withdrawing contracts, as well as managing templates and collaborators.
Updated a year ago (2025-07-22 14:00 UTC)
13
MIT

Features

Installation

Running with npx

Manual Installation

Running on Cursor

Running on Windsurf

Running with HTTP Stream Mode

Configuration

Environment Variables

Required

Optional

Usage with Claude Desktop

Available Tools

1. List Templates (sfs_list_templates)

2. Read Template (sfs_read_template)

HTTP Stream API

Authentication via HTTP Headers

Example API Call

Docker Deployment

Build and Run

Health Check

Development

License

Available Tools

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

MCP Server for eSignatures

BoldSign MCP Server

docuseal-mcp-server

eSignatures MCP Server

1. List Templates (`sfs_list_templates`)

2. Read Template (`sfs_read_template`)