RSign MCP Server

1. Overview

The RSign MCP Server is an enterprise-grade integration layer that exposes the RSign by RPost e-signature platform as a set of structured tools consumable by AI agents. It implements the Model Context Protocol (MCP) specification over JSON-RPC 2.0, enabling large language models such as Claude and custom LLM agents to perform authenticated digital signature workflows programmatically.

The server acts as an intermediary between AI agents and the RSign REST API, translating natural-language-driven tool calls into authenticated HTTP requests and returning structured, agent-compatible JSON responses.

1.1 Purpose

- Allow AI agents to initiate, track, and manage e-signature envelopes via RSign without direct API access.
- Provide a secure, stateful session model that maintains authentication tokens across tool calls.
- Expose a minimal, well-defined tool surface following MCP conventions.

1.2 Compatibility

- Claude Desktop (Anthropic)
- Custom LLM agents using the MCP
- Any MCP-compliant client

2. Architecture

The server follows a single-process, tool-based architecture. All communication between the AI agent and the MCP server occurs over standard input/output (stdio) using the JSON-RPC 2.0 framing defined by the MCP specification. The server then makes outbound HTTPS calls to the RSign REST API on behalf of the agent.

2.1 Communication Flow

2.2 Session State

Authentication tokens (AuthTokens) are stored in-memory within the server process for the lifetime of the session. Credentials and tokens are never passed to the AI model layer and are never written to logs. Each new server process starts with a clean authentication state.

3. Project Structure

 rsign-mcp-server/
 ├── src/
 │   ├── index.js                   # MCP server entrypoint
 │   └── tools/
 │       ├── authenticateUser.js     # Tool: authenticate_user
 │       ├── getTemplateByCode.js    # Tool: get_template_by_code
 │       ├── sendEnvelopeWithTemplate.js  # Tool: send_envelope
 │       └── getEnvelopeStatus.js    # Tool: get_envelope_status
 ├── .env                            # Runtime credentials (not committed)
 ├── package.json
 └── README.md

4. Requirements

5. Installation & Configuration

5.1 Install Dependencies

Navigate to the project root and install required Node.js dependencies:

 npm install

5.2 Environment Variables

Create a .env file in the project root with the following variables. These credentials are loaded at runtime and are never exposed to the model layer.

 RSIGN_BASE_URL=your_rsign_base_url
 RSIGN_USERNAME=your@email.com
 RSIGN_PASSWORD=your_password
 RSIGN_REFERENCE_KEY=your_reference_key

WARNING: Never commit the .env file to source control. Add it to .gitignore.

5.3 Claude Desktop Configuration

To use the server with Claude Desktop, add the following block to the claude_desktop_config.json file, replacing placeholder values with your actual credentials and server path:

 {
   "mcpServers": {
     "rsignbyrpost-mcp": {
       "command": "node",
       "args": [
         "C:/YourPathToServer/src/index.js"
       ],
       "env": {
         "RSIGN_BASE_URL": "your_base_url",
         "RSIGN_USERNAME": "YourUsername",
         "RSIGN_PASSWORD": "YourPassword",
         "RSIGN_REFERENCE_KEY": "YourReferenceKey"
       }
     }
   }
 }

6. Tools Reference

The MCP server exposes five tools via the tools/call method. All tools return structured JSON responses compatible with Claude and other MCP clients. The table below summarizes the available tools:

6.1 authenticate_user

Authenticates the agent session against the RSign API. Must be called before any other tool. On success, the returned AuthToken is stored in server memory and automatically attached to subsequent requests.

Input parameters
This tool takes no input parameters. Credentials are read from environment variables at runtime.

Response
 {
   "authToken": "eyJhbGciOiJIUzI1NiIsInR5...",
   "expiresAt": "2025-12-31T23:59:59Z"
 }

6.2 get_template_list

Returns all e-signature templates available in the authenticated RSign account. Used to discover template codes before calling get_template_by_code or send_envelope_with_template.

Input parameters
No input parameters required.

Response
 [
   {
     "templateCode": "TMPL-001",
     "templateName": "NDA Agreement",
     "createdAt": "2025-01-15T10:00:00Z"
   },
   ...
 ]

6.3 get_template_by_code

Retrieves full metadata and field definitions for a specific template identified by its unique code. Useful for understanding required recipient fields before sending an envelope.

Input parameters

Response
 {
   "templateCode": "TMPL-001",
   "templateName": "NDA Agreement",
   "fields": [ { "name": "SignerName", "required": true }, ... ],
   "recipients": [ { "role": "Signer1", "order": 1 } ]
 }

6.4 send_envelope_with_template

Creates and dispatches a new e-signature envelope using an existing RSign template. Recipients receive an email with a signing link. Returns a unique envelope code for status tracking.

Input parameters

Response
 {
   "envelopeCode": "ENV-20250101-ABC123",
   "status": "sent",
   "sentAt": "2025-04-14T12:00:00Z"
 }

6.5 get_envelope_status

Queries the current state of a previously dispatched envelope. Returns status, timestamps, and per-recipient signing progress.

Input parameters

Response
 {
   "envelopeCode": "ENV-20250101-ABC123",
   "status": "completed",
   "recipients": [
     {
       "email": "signer@example.com",
       "status": "signed",
       "signedAt": "2025-04-14T13:45:00Z"
     }
   ]
 }

7. Error Handling

All errors follow the JSON-RPC 2.0 error object format and are returned as structured MCP error responses. The server never throws unhandled exceptions to the agent.

Error response format
 {
   "jsonrpc": "2.0",
   "id": 1,
   "error": {
     "code": -32000,
     "message": "Not authenticated"
   }
 }

8. Security

SECURITY: Credentials and AuthTokens are stored exclusively in process memory. They are never logged, written to disk, or passed to the AI model layer under any circumstances.

8.1 Security Properties

- API credentials (username, password, reference key) are loaded from environment variables at startup, never hardcoded.
- AuthTokens exist only in server process memory and are scoped to a single session.
- No credential or token is ever included in tool responses returned to the agent.
- All outbound communication to the RSign API is made over HTTPS.
- The .env file must never be committed to version control.

8.2 Recommendations

- Use a secrets manager (AWS Secrets Manager, HashiCorp Vault, etc.) in production environments instead of a flat .env file.
- Rotate RSign API credentials on a regular schedule.
- Restrict network egress from the host running the MCP server to only the RSign API endpoint.
- Do not modify the server source code. For questions, contact integrations@rpost.com.

9. Typical Agent Workflow

The following sequence illustrates the standard flow for sending an envelope via an AI agent:

- Agent calls authenticate_user → server obtains and stores AuthToken.
- Agent calls get_template_list → discovers available template codes.
- Agent calls get_template_by_code → inspects required fields and recipient roles.
- Agent calls send_envelope_with_template with signer details → receives envelopeCode.
- Agent calls get_envelope_status with envelopeCode → monitors signing progress.