DocuSign

Reusable DTwo policies for Docusign MCP servers — the official remote Docusign MCP Server (https://mcp.docusign.com/mcp, the same server behind the Claude / Claude Cowork connector) plus the community luthersystems/mcp-server-docusign and CData read-only SQL implementations. The MCP surface spans directory and profile reads (getUsers, getUserInfo), envelope and agreement reads that carry filled tab values and AI-extracted contract terms (getEnvelope, listRecipients, getAllAgreements, getAgreementDetails), externally visible writes (createEnvelope with status: "sent", updateEnvelopeRecipients, sendReminder), workflow controls (triggerWorkflow, cancelWorkflowInstance, pauseNewWorkflowInstances), and — on community servers — whole-PDF export (download_envelope_document). Its risk profile is dominated by legally significant, irreversible action: a status: "sent" envelope emails a real signature request to counterparties under your company's brand, a void permanently invalidates an executed record, and envelopes are PII by construction and routinely carry financial terms, PHI, or SSN/bank tab values — making Docusign a standing SOX/HIPAA evidence surface.

Available policies

Tool naming on the DTwo gateway

The official Docusign server sends camelCase, no-prefix tool names on the wire (createEnvelope, updateEnvelope, getUsers, getAllAgreements); a DTwo gateway prepends the configured server name (e.g. docusign-createEnvelope). The community luthersystems server uses snake_case with richer verbs (create_envelope_from_template, download_envelope_document), and CData uses a {servername}_run_query prefix pattern. The policies here match on the suffix (createenvelope, create_envelope, updateenvelope, getusers, download_envelope_document, etc.) and lower-case the tool name so they stay portable across both naming conventions — but confirm the exact tool name your gateway sends using the dump-input debug technique before deploying. Per-tool JSON schemas for the official server are not published on a static page; the argument-shape assumptions in each policy are drawn from the mapped REST bodies and should be verified against a live tools/list before relying on exact-match behavior.

Identity claims

The identity-gated policies read input.subject.claims.groups with placeholder group names: esign-senders (force-draft-envelopes), contract-ops (freeze-destructive-ops), and admin / contracts-read (cap-directory-and-document-egress). Replace these with your own IdP group names at import time. Missing or empty claims fail closed for grants — no group means not exempt (still forced to draft, still denied the void, still truncated, still denied the download). guard-external-recipients and redact-tab-values-egress require no claims.

Contributing

To add a Docusign policy:

1. Create apps/docusign/<policy-slug>/ with policy.md and a tests.yaml test file.
2. Add a row to the table above.
3. Declare apps: ["docusign"] in the policy frontmatter, plus any industry / bundle slugs that apply.
4. Tag any framework bundle slugs the description backs with a control citation (soc2, hipaa, pci-dss, gdpr-ccpa, sox) in the policy frontmatter bundles field; if a matching thematic bundle landing page exists under bundles/, link to it.
5. Run pnpm manifest from the repo root.

See CONTRIBUTING.md for the full process.