How to Call Docusign Mcp Tools From Salesforce Agentforce Using a Custom Apex Bridge

Key takeaways

• You can connect Agentforce to the Docusign MCP Server right now with a custom Apex bridge that handles JSON-RPC 2.0 messaging and JWT Bearer OAuth 2.0 authentication without waiting for a native connector.

• A Named Credentials-based setup lets Salesforce handle token lifecycle and JWT signing for you.

• Once the Apex class is deployed, you expose it to Agentforce through an Autolaunched Flow, a custom Agentforce Action, and a Subagent assignment. 

• The Docusign MCP Server gives agents access to Docusign capabilities such as envelope status, structured agreement metadata, and workflow routing.

Salesforce’s Agentforce can reason over customer and business data, but it can’t reach Docusign on its own when someone asks about an agreement, sends an envelope, or starts an agreement workflow. The Docusign MCP Server makes Docusign tools available through the Model Context Protocol so an agent can invoke them.

The MCP Server currently requires service-level authentication, which Agentforce doesn’t support out of the box. To bridge that gap, this guide uses a custom Apex class to manage authentication and message handling between the two systems.

You’ll configure Salesforce to authenticate with Docusign, build an Apex class that sends JSON-RPC 2.0 requests to the MCP Server, and expose that class to Agentforce through a Flow and custom action. The result is an Agentforce agent that can invoke Docusign tools from a natural-language request.

This pattern is intended for Salesforce solution engineers and architects building agreement-aware workflows for enterprise environments.

What you'll build

The completed integration uses the following request path: Agentforce → Autolaunched Flow → Apex class → Named Credential → Docusign MCP Server. 

By the end of the guide, you’ll have:

• A Docusign integration key configured for JWT Bearer Flow authentication

• A JKS keystore that Salesforce can use for server-to-server signing

• A Salesforce Named Credential that points to the Docusign MCP Server

• An Apex class, DocusignMCPAgent, that sends JSON-RPC 2.0 requests and returns structured tool responses

• An Autolaunched Flow and Agentforce Action that expose the Apex class to an agent

• A Subagent assignment that lets the agent invoke Docusign tools from conversational requests

Before you start

You’ll need access to both Docusign and Salesforce, along with a few local command-line tools.

Docusign

• A production or developer account

• An integration key with a service integration configured for JWT Bearer Flow. If you’re new to JWT Bearer Flow authentication in Docusign, review this resource before continuing.

• Admin access to create an RSA key pair and grant administrative consent

Salesforce

• A Salesforce org with Agentforce enabled

• Admin access to Named Credentials, Certificate and Key Management, Flows, and Agentforce Builder

• Permission to upload certificates and configure outbound callouts

Local tools

• OpenSSL

• Java keytool

Note: The examples in this guide use the Docusign sandbox endpoints account-d.docusign.com and mcp-d.docusign.com. Replace them with the corresponding production endpoints before deploying the integration to a production environment. 

How the integration works

In this pattern, Salesforce acts as the MCP client. The Apex class sends JSON-RPC 2.0 requests to the Docusign MCP Server, which translates them into calls to Docusign APIs.

Depending on the tool invoked, these calls can retrieve envelope status through eSignature, access structured contract metadata through Agreement Manager, or initiate multistage routing through Workflow Builder. Refer to the Docusign MCP Tool Reference for additional use cases.

The Agentforce agent does not call Docusign directly. Instead, it invokes a Flow, which calls the Apex class. The Apex class handles the HTTP callout and parses the MCP response. This approach keeps credential management within Salesforce while giving the agent a defined interface for accessing Docusign tools. 

For a detailed walkthrough of the Salesforce credential configuration process, see the implementation guide for JWT authentication. This post uses the Named Credential approach exclusively to keep authentication and token management within Salesforce.

Because the MCP Server uses endpoint URLs that differ from standard Docusign REST API endpoints, confirm the current MCP Server specifications before configuring the connection.

Step 1: Implement the Apex MCP bridge

The custom Apex bridge controls header management, JSON-RPC payload formatting, and response parsing. After configuring authentication, deploy the bridge using the reference implementation below. 

Note: The Apex implementation below is an architectural reference. Review and adapt it to your project requirements and organizational standards before deploying it to production. 

Named Credentials-based agent 

The following approach delegates token management and JWT signing to Salesforce. The callout:DocuSign_MCP/mcp binding causes Salesforce to automatically inject the OAuth bearer token into outbound headers.

public with sharing class DocusignMCPAgent {

    /**
     * Invocable method for Agentforce or Salesforce Flows to run Docusign MCP tools.
     * Offloads all OAuth and token lifecycle management to Salesforce Named Credentials.
     */
    @InvocableMethod(label='Invoke MCP Tool (Named Credentials)' description='Sends a JSON-RPC payload to Docusign MCP via Named Credentials and returns the unwrapped text result')
    public static List<ResponseWrapper> invokeTool(List<RequestWrapper> requests) {
        List<ResponseWrapper> responses = new List<ResponseWrapper>();
        for (RequestWrapper req : requests) {
            ResponseWrapper response = new ResponseWrapper();
            try {
                HttpRequest httpReq = new HttpRequest();
                // Binds the callout to the Named Credential and appends the target MCP path
                httpReq.setEndpoint('callout:DocuSign_MCP/mcp');
                httpReq.setMethod('POST');
                httpReq.setHeader('Content-Type', 'application/json');
                httpReq.setHeader('Accept', 'application/json, text/event-stream');
                httpReq.setBody(req.jsonPayload);

                Http http = new Http();
                HttpResponse res = http.send(httpReq);

                if (res.getStatusCode() == 200) {
                    response.responseBody = unwrapMcpResponse(res.getBody());
                    response.isSuccess = true;
                } else {
                    response.responseBody = 'HTTP Error ' + res.getStatusCode() + ': ' + res.getBody();
                    response.isSuccess = false;
                }
            } catch (Exception e) {
                System.debug(LoggingLevel.ERROR, 'DocuSign MCP Callout Failed: ' + e.getMessage());
                response.responseBody = 'Execution Exception: ' + e.getMessage();
                response.isSuccess = false;
            }
            responses.add(response);
        }
        return responses;
    }

    /**
     * Parses the JSON-RPC response structure according to Model Context Protocol standards.
     * Extracts the raw text returned by the target tool.
     */
    private static String unwrapMcpResponse(String rawBody) {
        try {
            if (String.isBlank(rawBody)) {
                return '';
            }
            // Isolate JSON to remove potential Streamable HTTP/SSE transport artifacts
            Integer firstBrace = rawBody.indexOf('{');
            Integer lastBrace = rawBody.lastIndexOf('}');
            if (firstBrace == -1 || lastBrace == -1) {
                return rawBody;
            }
            String jsonPart = rawBody.substring(firstBrace, lastBrace + 1);
            Map<String, Object> root = (Map<String, Object>) JSON.deserializeUntyped(jsonPart);
            if (root.containsKey('result')) {
                Map<String, Object> resultNode = (Map<String, Object>) root.get('result');
                if (resultNode.containsKey('content')) {
                    List<Object> contentList = (List<Object>) resultNode.get('content');
                    if (!contentList.isEmpty()) {
                        Map<String, Object> contentItem = (Map<String, Object>) contentList[0];
                        if (contentItem.get('type') == 'text') {
                            return (String) contentItem.get('text');
                        }
                    }
                }
            }
            return rawBody;
        } catch (Exception e) {
            System.debug(LoggingLevel.WARN, 'MCP Payload Parsing Error: ' + e.getMessage());
            return rawBody;
        }
    }

    public class RequestWrapper {
        @InvocableVariable(label='JSON Payload' required=true
            description='Structured JSON-RPC 2.0 payload containing the tool name and arguments')
        public String jsonPayload;
    }

    public class ResponseWrapper {
        @InvocableVariable(label='Tool Result' description='Extracted textual result from the Docusign MCP tool execution')
        public String responseBody;

        @InvocableVariable(label='Is Success' description='Indicates if the HTTP callout and tool execution completed successfully')
        public Boolean isSuccess;
    }
}

Step 2: Connect the Apex bridge to Agentforce

After deploying the Apex class, connect it to Agentforce through an Autolaunched Flow, a custom Action, and a Subagent assignment. 

Create an Autolaunched Flow

The Flow accepts a JSON-RPC payload from the agent, calls the Apex class, and returns the response.

1. Navigate to Setup > Process Automation > Flows and click New Flow.

2. Select Autolaunched Flow (No Trigger).

3. Define the input variable:

   1. API Name: mcpPayload

   2. Data Type: Text

   3. Available for Input: Checked

4. Define the output variable:

   1. API Name: mcpResult

   2. Data Type: Text

   3. Available for Output: Checked

5. Drag an Action element onto the canvas and select Invoke MCP Tool (Named Credentials).

6. Map the action's jsonPayload input parameter to the Flow variable {!mcpPayload}.

7. Drag an Assignment element and assign {!mcpResult} to the Apex action's output responseBody.

8. Save the Flow as DocuSign_MCP_Gateway_Flow and click Activate.

Define the Agentforce custom action

1. Navigate to Setup > Einstein > Einstein Generative AI> Agentforce Studio> Agentforce Assets> 

2. Select Actions, then click New Agent Action.

3. Select Flow as the reference action type and map it to DocuSign_MCP_Gateway_Flow.

4. Add a clear natural-language description for the tool. For example: “Invokes the Docusign MCP Gateway. The input must be a valid JSON-RPC 2.0 payload for a supported Docusign MCP tool.” 

5. Provide clear descriptions for the Flow's inputs and outputs to help the LLM construct valid arguments during conversational runs.

6. Click Save to publish the action to the Agentforce Asset Library.

Add the action to an Agentforce Subagent

In the Agentforce Assets screen, open Subagents and select New Subagent.

Use the following configuration:

• Name: Agreement Management

• Classification Description: "Handles all operations involving legal contracts, e-signatures, status checks, clause analysis, and agreement workflows."

• Scope:  “Access agreements associated with particular account names; retrieve contract specifics including lifecycle status, document types, and metadata; perform direct agreement queries against the Docusign MCP Server; and apply attribute-based filters for classification and status tracking”

Click Add Action within the newly created Topic and select the DocuSign_MCP_Gateway_Flow action.

Add Topic instructions that guide the agent on when to invoke the tool. For example:

"When a user asks about contract statuses, expiration dates, or legal clauses, construct the corresponding JSON-RPC payload and run the DocuSign_MCP_Gateway_Flow action. Always present the returned result in clear natural language."

Click Activate to publish the changes.

Add the Subagent to an Agentforce Agent

Open Agentforce Studio and locate the agent you want to use for the integration. Find the Subagent you configured in the previous step, then assign it to the agent.

Configuration guidance

Keep the following points in mind as you configure the Subagent. 

Define a narrow scope: Agentforce uses the Classification Description to decide when to invoke the action. A specific description reduces false triggers and improves response quality. 

Write instructions for the LLM: The instructions should be specific enough that the LLM consistently constructs valid JSON-RPC payloads instead of answering agreement-related questions from its own training data.

Keep controls within Workflow Builder: Agentforce triggers Workflow Builder to launch the workflow, but the workflow’s key controls remain within Docusign Workflow Builder. This separation helps reduce the risk of unintended updates or actions by ensuring that the workflow runs according to the controls already defined in Docusign.

Constraints and limitations

Authorization scope: Service account only

This architecture uses the server-to-server JWT Bearer Flow, so Agentforce performs Docusign operations through one dedicated service account.

Docusign audit logs will attribute envelope checks and workflow initiations to that service account rather than to the individual end user. The MCP Server and Agentforce do not currently support delegated user-level authentication.

This pattern is therefore not suitable for solutions that require audit trails tied to individual Agentforce users. Monitor the Docusign developer roadmap opens in a new tab for updates related to delegated identity support for the MCP Server.

Before deploying to production

The examples in this guide are architectural references and use Docusign sandbox endpoints. Before deploying the integration to production: 

• Replace the sandbox endpoints with the current production endpoints listed in the Docusign documentation.

• Confirm that administrative consent has been granted for the JWT Bearer Flow.

• Add the MCP endpoint to Setup > Security > Remote Site Settings in Salesforce.

• Review the Apex implementation against your organization’s security, error-handling, and maintenance requirements.

• Make sure the JKS alias follows Salesforce Developer Name conventions by using only alphanumeric characters and underscores. Otherwise, Salesforce may reject the keystore upload without providing a clear error message.

FAQ

Is the Apex approach the only available connection option?

The custom Apex bridge described in this post is the available approach today. It provides programmatic control over headers, payload structure, and response filtering.

Once the Docusign connector for Agentforce is available, it will provide a declarative path for registering the Docusign MCP Server directly in Agentforce.

Is the Apex bridge production-ready as written?

The implementation in this post is an architectural reference. Before using it in production:

• Move integration keys and user IDs to Custom Metadata.

• Add explicit error handling and retry logic for transient failures.

• Review the unwrapMcpResponse parsing logic against the current MCP Server response schema.

• Plan for ongoing maintenance if the MCP response format changes.

When a Named Credential uses an OAuth flow that provides a refresh token, Salesforce automatically attempts to refresh the access token after it expires.

How do I test this before connecting it to a live Agentforce agent?

You can test the DocusignMCPAgent Apex class directly in the Developer Console using Execute Anonymous.

Pass a valid JSON-RPC 2.0 payload to the jsonPayload input used by the Flow, then inspect the responseBody and isSuccess outputs.

The following examples show how to list the available tools and call specific MCP tools.

Example payloads:
to get the list of tools
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {
    "arguments": {
      "accountId": "3c9c0391-01ac-4a98-8fab-adb9d0e548d2"
    }
  }
}
to call specific tool  like  getWorkflowInstancesList
{
  "jsonrpc": "2.0",
  "id": 4,
  "method": "tools/call",
  "params": {
    "name": "getWorkflowInstancesList",
    "arguments": {
      "params": {
        "accountId": "7f09961a-a22e-4ea2-8395-d7648b81f20c",
        "workflowId": "84acbb50-42bb-48bb-b6ac-c3e930c8d415"
      }
    }
  }
}
another example like calling tool  getWorkflowsList
{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "getWorkflowsList",
    "arguments": {
      "params": {
        "accountId": "3c9c0391-01ac-4a98-8fab-adb9d0e548d2"
      }
    }
  }
}

Next steps

After the basic bridge is working, you can extend and refine the pattern in several ways. 

• Add more MCP tools to the Topic: The current setup exposes a single MCP gateway action. You can create additional Apex methods or Flow actions for specific Docusign operations, such as envelope creation, template triggering, or agreement search, and add them as separate actions within the Agreement Management Subagent. 

• Refine the Topic instructions: As you test the agent, update the Classification Description and instructions based on how accurately Agentforce invokes the Docusign action rather than answering from its own knowledge.

• Use Named Credentials for all token management: If you began with an alternative approach for flexibility, migrate to Named Credentials before moving to production. This architecture is more maintainable and secure, and it removes the need to manage token expiration directly in code. 

With the bridge in place, Agentforce can invoke Docusign MCP tools through a reusable Flow and Apex pattern that you can refine as your agreement workflows expand.

Resources

• Docusign Developer Center

• Docusign eSignature API reference

• Salesforce Named Credentials documentation opens in a new tab

• Salesforce JWT Bearer Flow documentation opens in a new tab

• Docusign MCP Server documentation