Clerky vs Docusign

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Clerky
   Clerky✓fullprobed9/10

   Clerky's developer docs site serves a valid llms.txt (HTTP 200) with structured links to markdown-formatted docs pages, confirmed by direct probe evidence, satisfying the ability to point an agent at agent-oriented documentation. missing for 10: independent third-party confirmation of an agent successfully consuming the llms.txt in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://developers.clerky.com/llms.txt - [Lifecycle](https://developers.clerky.com/getting-started/lifecycle/ind…”
   • [claimed-docs] “# Introduction The Clerky Partner API lets partners bring a Clerky-powered formation workflow into their own product. It currently supports …”
   • [claimed-docs] “# Lifecycle A [document set][document-sets] moves through four partner-facing steps: create it, collect [form][forms] values, submit those v…”

   proof ↗⚑ flag

   Docusign~partialprobed5/10

   Docusign has no llms.txt (confirmed 404 probe) but does provide agent-oriented documentation such as the Claude MCP connector guide, an official MCP server, and machine-readable OpenAPI specs explicitly described as enabling 'computers to discover and understand the capabilities of the service.' This covers part of the story but lacks the specific llms.txt convention many AI-native tools expect. missing for 10: llms.txt file, dedicated agent-facing doc index, independent confirmation that agents can consume these docs successfully.

   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.docusign.com/llms.txt”
   • [probe] “official MCP server documented at https://developers.docusign.com/platform/mcp-server/”
   • [claimed-docs] “The Docusign Connector in Anthropic Claude via MCP server provides a supported way to connect Claude to Docusign IAM capabilities.”
   • [claimed-docs] “Retrieve agreement context and metadata... Query agreement status and key dates... Trigger workflow actions through IAM tools”
   • [github] “allows both humans and computers to discover and understand the capabilities of the service”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Docusign
   Clerky~partialclaimed3/10

   Clerky exposes a Partner API (create document sets, list forms, submit JSON, poll status) that could in principle be scripted, but authentication is an OAuth authorization-code flow tied to a human sign-in ('coming soon' per docs), and legal documents still require human e-signature, so true unattended/CI automation isn't demonstrated. Missing for 10: machine-to-machine/service-account auth, CLI or CI examples, and confirmation the workflow can complete without a human signing step.

   • [claimed-docs] “# Introduction The Clerky Partner API lets partners bring a Clerky-powered formation workflow into their own product. It currently supports …”
   • [claimed-docs] “# Lifecycle A [document set][document-sets] moves through four partner-facing steps: create it, collect [form][forms] values, submit those v…”
   • [claimed-docs] “# Authentication The Clerky Partner API will use OAuth 2.0 bearer tokens. OAuth-based access is coming soon; client registration, URLs, scop…”

   proof ↗⚑ flag

   Docusign~partialcommunity6/10

   Docusign exposes a REST API, official SDKs (e.g., Node.js client) and OpenAPI specs that let developers script sending/signing/approving documents programmatically, and the Gemini CLI + Docusign MCP integration explicitly supports automating agreement processes 'from your terminal.' However, there is no explicit CI/CD documentation, headless-mode guide, or automated pipeline example, and community feedback notes real integration friction (mixed embedded-API experiences). Missing for 10: dedicated CI/headless deployment guide, service-account/automation-focused docs, and independent verification of running the API in automated pipelines without a UI.

   • [claimed-docs] “Request Signatures & Automate Forms | REST API | Docusign”
   • [claimed-docs] “Send, sign, and approve documents using this client.”
   • [claimed-docs] “The Official Docusign Node.js Client Library used to interact with the eSign REST API. Send, sign, and approve documents using this client.”
   • [github] “We use OpenAPI/Swagger files to build many of our developer tools including our client SDKs”
   • [github] “allows both humans and computers to discover and understand the capabilities of the service”
   • [claimed-docs] “Query agreement data and automate agreement processes from your terminal by pairing Gemini CLI with Docusign MCP.”
   • [community] “We did exactly this embedded signing integration and it was fairly seamless - built a POC in Postman in about an hour and a Jr dev built a p…”
   • [community] “We use the v2 REST API creating embedded envelope signing URLs without issues. Documentation is fantastic in its thoroughness - opposite exp…”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round drawn
   Clerky✓fullprobed8/10

   Clerky publishes an official remote MCP server (https://mcp.clerky.com/mcp) with documented setup for Claude, ChatGPT, and other AI assistants, and a live probe confirms the endpoint is real and OAuth-gated as documented. Missing for 10: independent/community confirmation of real-world agent usage and full detail on the OAuth authorization flow completion.

   • [claimed-docs] “# Clerky MCP Server Clerky works with AI assistants that support remote [Model Context Protocol (MCP)](https://modelcontextprotocol.io/docs/…”
   • [probe] “PROBE remote MCP initialize (no token): {"error": "invalid_token", "error_description": "Authentication required"} HTTP 401 — live OAuth-gat…”
   • [claimed-docs] “# Authentication The Clerky Partner API will use OAuth 2.0 bearer tokens. OAuth-based access is coming soon; client registration, URLs, scop…”

   proof ↗⚑ flag

   Docusign✓fullprobed8/10

   Docusign documents an official MCP server (Docusign Connector via Anthropic Claude and Gemini CLI) with a dedicated developer platform page and guide, exposing IAM tools like retrieving agreement context/metadata and triggering workflow actions. Missing for 10: independent/hands-on verification of the MCP server's reliability and broader third-party adoption beyond vendor blog examples.

   • [claimed-docs] “The Docusign Connector in Anthropic Claude via MCP server provides a supported way to connect Claude to Docusign IAM capabilities.”
   • [claimed-docs] “Retrieve agreement context and metadata... Query agreement status and key dates... Trigger workflow actions through IAM tools”
   • [claimed-docs] “Query agreement data and automate agreement processes from your terminal by pairing Gemini CLI with Docusign MCP.”
   • [claimed-docs] “Build agreement workflows: Docusign MCP & Claude”
   • [probe] “official MCP server documented at https://developers.docusign.com/platform/mcp-server/”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Clerky—none0/10

   Clerky provides a Partner API and a remote MCP server, but no evidence of an official CLI tool for AI-native workflows; probes for docs/llms.txt found no CLI references.

   • [claimed-docs] “# Introduction The Clerky Partner API lets partners bring a Clerky-powered formation workflow into their own product. It currently supports …”
   • [claimed-docs] “# Lifecycle A [document set][document-sets] moves through four partner-facing steps: create it, collect [form][forms] values, submit those v…”
   • [claimed-docs] “# Clerky MCP Server Clerky works with AI assistants that support remote [Model Context Protocol (MCP)](https://modelcontextprotocol.io/docs/…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developers.clerky.com/llms.txt - [Lifecycle](https://developers.clerky.com/getting-started/lifecycle/ind…”

   proof ↗⚑ flag

   Docusign—none0/10

   The evidence pack shows SDKs, REST APIs, an MCP server/connector, and third-party CLI pairing (Gemini CLI + Docusign MCP), but no official Docusign-branded CLI tool is documented anywhere in the evidence.

   • [claimed-docs] “Query agreement data and automate agreement processes from your terminal by pairing Gemini CLI with Docusign MCP.”
   • [claimed-docs] “Request Signatures & Automate Forms | REST API | Docusign”
   • [claimed-docs] “The Official Docusign Node.js Client Library used to interact with the eSign REST API. Send, sign, and approve documents using this client.”

   proof ↗⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round to Docusign
   Clerky~partialprobed6/10

   Clerky publishes real developer documentation for a Partner API (developers.clerky.com, discoverable via llms.txt) covering document-set lifecycle, form schemas, and endpoints like POST /v1/document_sets and GET forms, which is genuine documented programmatic access. However, the docs themselves state OAuth-based authentication is 'coming soon' and not yet live, meaning the API isn't fully operational for external partner integration yet, and scope is limited to Delaware C-Corp formations only. Missing for 10: live/functional authentication flow, evidence of broader API scope, and independent developer reports of successful integration.

   • [claimed-docs] “# Introduction The Clerky Partner API lets partners bring a Clerky-powered formation workflow into their own product. It currently supports …”
   • [claimed-docs] “# Lifecycle A [document set][document-sets] moves through four partner-facing steps: create it, collect [form][forms] values, submit those v…”
   • [claimed-docs] “# Authentication The Clerky Partner API will use OAuth 2.0 bearer tokens. OAuth-based access is coming soon; client registration, URLs, scop…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developers.clerky.com/llms.txt - [Lifecycle](https://developers.clerky.com/getting-started/lifecycle/ind…”

   proof ↗⚑ flag

   Docusign✓fullprobed8/10

   Docusign publishes a well-documented public REST API (eSign REST API docs, Developer Center, OpenAPI/Swagger specs used to generate SDKs like the Node.js client), with community confirmation that thorough API-driven integrations (e.g., embedded signing) work well in production. This directly satisfies programmatic/API-driven use, though one community report describes a security workaround requiring a legacy API version, and there's no first-party llms.txt or discoverable openapi.json at the expected probe URLs. Missing for 10: a clean machine-readable OpenAPI spec at a standard endpoint (probe returned 404s) and stronger independent corroboration beyond one HN thread.

   • [claimed-docs] “Request Signatures & Automate Forms | REST API | Docusign”
   • [claimed-docs] “Docusign Developer Center | eSignature APIs & Resources | Docusign”
   • [github] “We use OpenAPI/Swagger files to build many of our developer tools including our client SDKs”
   • [github] “allows both humans and computers to discover and understand the capabilities of the service”
   • [github] “We use OpenAPI/Swagger files to build many of our developer tools including our client SDKs using `swagger-codegen`.”
   • [claimed-docs] “Send, sign, and approve documents using this client.”
   • [claimed-docs] “The Official Docusign Node.js Client Library used to interact with the eSign REST API. Send, sign, and approve documents using this client.”
   • [community] “We did exactly this embedded signing integration and it was fairly seamless - built a POC in Postman in about an hour and a Jr dev built a p…”
   • [community] “We use the v2 REST API creating embedded envelope signing URLs without issues. Documentation is fantastic in its thoroughness - opposite exp…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.docusign.com/openapi.json, https://developers.docusign.com/swagger.json, https://…”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Clerky
   Clerky~partialprobed4/10

   Clerky documents an OAuth 2.0 bearer-token model for its Partner API with an 'access model' limiting what each token can do, and a live remote MCP server gated by OAuth ('team access you authorize') confirmed via a 401 invalid_token probe rather than being open. However, OAuth for the Partner API is explicitly marked 'coming soon' with scopes/lifetime 'to be published,' and the MCP scoping described is team-level, not clearly a fine-grained least-privilege credential model for individual agents. Missing for 10: published granular scopes/permissions list, confirmed live least-privilege token issuance flow, and independent verification of scope enforcement.

   • [claimed-docs] “# Authentication The Clerky Partner API will use OAuth 2.0 bearer tokens. OAuth-based access is coming soon; client registration, URLs, scop…”
   • [claimed-docs] “# Clerky MCP Server Clerky works with AI assistants that support remote [Model Context Protocol (MCP)](https://modelcontextprotocol.io/docs/…”
   • [probe] “PROBE remote MCP initialize (no token): {"error": "invalid_token", "error_description": "Authentication required"} HTTP 401 — live OAuth-gat…”

   proof ↗⚑ flag

   Docusign—none0/10

   No evidence describes granular, scoped/least-privilege API credentials or OAuth scopes tailored for AI agents; the MCP connector docs mention triggering IAM workflow actions but not credential scoping controls. A community report even describes an API-user permission failure where embedded signing let a single API user's session expose the entire account's data, undermining any claim of fine-grained least-privilege access.

   • [claimed-docs] “The Docusign Connector in Anthropic Claude via MCP server provides a supported way to connect Claude to Docusign IAM capabilities.”
   • [claimed-docs] “Retrieve agreement context and metadata... Query agreement status and key dates... Trigger workflow actions through IAM tools”
   • [community] “We wanted embedded flows with one API user, but discovered that on page refresh, users could break out of the signing page and view/click ar…”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Docusign
   Clerky~partialprobed5/10

   Clerky publishes an official Partner API (REST, JSON schema-driven forms, document-set lifecycle) with docs and an llms.txt developer portal, plus a documented remote MCP server for AI assistants — both usable for programmatic/agentic integration. However there is no evidence of a packaged SDK (client libraries in Python/JS/etc.), and the API's OAuth authentication is explicitly still 'coming soon,' meaning full client access isn't yet live. Missing for 10: language-specific SDK packages, completed/live OAuth client registration, independent developer corroboration of successful integration.

   • [claimed-docs] “# Introduction The Clerky Partner API lets partners bring a Clerky-powered formation workflow into their own product. It currently supports …”
   • [claimed-docs] “# Lifecycle A [document set][document-sets] moves through four partner-facing steps: create it, collect [form][forms] values, submit those v…”
   • [claimed-docs] “# Authentication The Clerky Partner API will use OAuth 2.0 bearer tokens. OAuth-based access is coming soon; client registration, URLs, scop…”
   • [claimed-docs] “# Clerky MCP Server Clerky works with AI assistants that support remote [Model Context Protocol (MCP)](https://modelcontextprotocol.io/docs/…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developers.clerky.com/llms.txt - [Lifecycle](https://developers.clerky.com/getting-started/lifecycle/ind…”
   • [probe] “PROBE remote MCP initialize (no token): {"error": "invalid_token", "error_description": "Authentication required"} HTTP 401 — live OAuth-gat…”

   proof ↗⚑ flag

   Docusign✓fullprobed8/10

   Docusign ships official client SDKs (e.g., docusign-esign-node-client) built from OpenAPI/Swagger specs, backed by a dedicated developer center and REST API docs, and community reports include successful hands-on integrations using the REST API. Missing for 10: independent corroboration of SDK quality/completeness across all supported languages, and machine-discoverable API specs (llms.txt and openapi.json probes both returned 404), plus some community reports of API friction that temper confidence in a flawless experience.

   • [claimed-docs] “Send, sign, and approve documents using this client.”
   • [claimed-docs] “The Official Docusign Node.js Client Library used to interact with the eSign REST API. Send, sign, and approve documents using this client.”
   • [claimed-docs] “Request Signatures & Automate Forms | REST API | Docusign”
   • [claimed-docs] “Docusign Developer Center | eSignature APIs & Resources | Docusign”
   • [github] “We use OpenAPI/Swagger files to build many of our developer tools including our client SDKs”
   • [github] “We use OpenAPI/Swagger files to build many of our developer tools including our client SDKs using `swagger-codegen`.”
   • [community] “We did exactly this embedded signing integration and it was fairly seamless - built a POC in Postman in about an hour and a Jr dev built a p…”
   • [community] “We use the v2 REST API creating embedded envelope signing URLs without issues. Documentation is fantastic in its thoroughness - opposite exp…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.docusign.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.docusign.com/openapi.json, https://developers.docusign.com/swagger.json, https://…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Clerky—none0/10

   The Partner API docs explicitly describe a poll-based lifecycle model (create, submit, poll for state) rather than any webhook/event-subscription mechanism, and no evidence anywhere mentions webhooks or push notifications.

   • [claimed-docs] “# Lifecycle A [document set][document-sets] moves through four partner-facing steps: create it, collect [form][forms] values, submit those v…”
   • [claimed-docs] “# Introduction The Clerky Partner API lets partners bring a Clerky-powered formation workflow into their own product. It currently supports …”

   proof ↗⚑ flag

   Docusign—none0/10

   The evidence pack never mentions webhooks, event subscriptions, or DocuSign Connect (the product's known webhook feature); only REST APIs, SDKs, MCP connector, and unrelated product features are cited. Since webhook support is a plausible axis for an API-driven product like Docusign, absence of evidence makes this 'none' rather than 'na'.

   ⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to Docusign
   Clerky—none0/10

   Clerky is a legal document/formation platform with an MCP server and partner API for workflow automation, but there is no evidence of AI-generated insights or suggestions surfaced from the user's own data (e.g., analytics, recommendations, anomaly detection) inside the product. The MCP server exposes tools for AI assistants to act on data, not the product itself generating insights.

   • [claimed-docs] “# Clerky MCP Server Clerky works with AI assistants that support remote [Model Context Protocol (MCP)](https://modelcontextprotocol.io/docs/…”
   • [probe] “PROBE remote MCP initialize (no token): {"error": "invalid_token", "error_description": "Authentication required"} HTTP 401 — live OAuth-gat…”

   proof ↗⚑ flag

   Docusign✓fullclaimed7/10

   Docusign documents multiple AI-generated insight features directly in-product: AI-Assisted Summary and Q&A for signers, AI-Assisted Review that flags risky language, suggests redlines, and drafts new clauses against playbooks, and CLM's AI clause-compliance flagging and drafting. These are first-party vendor claims with no independent hands-on corroboration of the AI quality itself. Missing for 10: independent/third-party validation of AI insight accuracy, and no community evidence confirming these AI features work as described in practice.

   • [claimed-docs] “Our AI-Assisted Summary and Q&A features increase trust in agreements”
   • [claimed-docs] “Review and analyze agreements, flag potentially risky language, suggest surgical edits, and draft new language from an intuitive AI-powered …”
   • [claimed-docs] “Review agreements against your playbooks and ready-to-deploy agents and get suggested redlines to align terms with your requirements.”
   • [claimed-docs] “Docusign AI-Assisted Review integrates into MS Word to analyze, redline, and draft language based on your playbooks.”
   • [claimed-docs] “use AI to flag non-compliant clauses, suggest approved language, and draft new clauses on demand”
   • [claimed-docs] “AI-generated summaries and built-in Q&A give signers clarity faster so they can sign with confidence.”
   • [claimed-docs] “Leverage AI to easily create new contract review playbooks based on your standard templates or other reference documents.”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Docusign
   Clerky—none0/10

   Clerky's MCP server and Partner API let AI assistants or partner products interactively invoke Clerky tools (with team-scoped OAuth access), but nothing in the evidence describes autonomous, unattended background automations (e.g., scheduled triggers, event-driven workflows) running without a live user/assistant session initiating each action.

   • [claimed-docs] “# Clerky MCP Server Clerky works with AI assistants that support remote [Model Context Protocol (MCP)](https://modelcontextprotocol.io/docs/…”
   • [probe] “PROBE remote MCP initialize (no token): {"error": "invalid_token", "error_description": "Authentication required"} HTTP 401 — live OAuth-gat…”
   • [claimed-docs] “# Introduction The Clerky Partner API lets partners bring a Clerky-powered formation workflow into their own product. It currently supports …”
   • [claimed-docs] “# Lifecycle A [document set][document-sets] moves through four partner-facing steps: create it, collect [form][forms] values, submit those v…”

   proof ↗⚑ flag

   Docusign~partialprobed6/10

   Docusign offers configurable workflows, CLM automation, and an official MCP server that lets AI agents (e.g., Claude) trigger workflow actions and retrieve agreement context, which supports agentic automation. However, there's no explicit evidence of scheduled, unattended, or fully autonomous background execution (e.g., cron-like triggers, webhooks, or agent-initiated jobs without a live AI session) — missing for 10: documented background/scheduled automation, webhook/event-driven triggers, and independent confirmation that MCP-driven workflows run without active human/agent supervision.

   • [claimed-docs] “take advantage of configurable workflows to tackle your trickiest agreement challenges”
   • [claimed-docs] “Trigger workflow actions through IAM tools”
   • [claimed-docs] “The Docusign Connector in Anthropic Claude via MCP server provides a supported way to connect Claude to Docusign IAM capabilities.”
   • [probe] “official MCP server documented at https://developers.docusign.com/platform/mcp-server/”
   • [claimed-docs] “Generate contracts in a click with dynamic templates and use AI to flag non-compliant clauses, suggest approved language, and draft new clau…”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to Docusign
   Clerky—none0/10

   Evidence shows Clerky exposes an MCP server so external AI assistants (Claude, ChatGPT) can call into Clerky's tools, but this is the reverse of a built-in assistant inside Clerky's own product that a user delegates tasks to. No evidence of any in-app AI assistant/chat feature for delegating formation, hiring, or document tasks.

   • [claimed-docs] “# Clerky MCP Server Clerky works with AI assistants that support remote [Model Context Protocol (MCP)](https://modelcontextprotocol.io/docs/…”
   • [probe] “PROBE remote MCP initialize (no token): {"error": "invalid_token", "error_description": "Authentication required"} HTTP 401 — live OAuth-gat…”

   proof ↗⚑ flag

   Docusign~partialclaimed6/10

   Docusign ships AI-Assisted Review, AI-Assisted Summary/Q&A, and Iris-powered form conversion embedded within its products, letting users delegate agreement-analysis and drafting tasks to built-in AI features rather than a single unified conversational assistant that can be delegated arbitrary tasks. missing for 10: evidence of a general-purpose, agentic in-product assistant that can autonomously execute multi-step tasks (not just summarize/flag/draft within a specific workflow), and independent/hands-on validation of these AI features actually working as described.

   • [claimed-docs] “Our AI-Assisted Summary and Q&A features increase trust in agreements”
   • [claimed-docs] “Review and analyze agreements, flag potentially risky language, suggest surgical edits, and draft new language from an intuitive AI-powered …”
   • [claimed-docs] “Review agreements against your playbooks and ready-to-deploy agents and get suggested redlines to align terms with your requirements.”
   • [claimed-docs] “Docusign AI-Assisted Review integrates into MS Word to analyze, redline, and draft language based on your playbooks.”
   • [claimed-docs] “AI-generated summaries and built-in Q&A give signers clarity faster so they can sign with confidence.”
   • [claimed-docs] “use AI to flag non-compliant clauses, suggest approved language, and draft new clauses on demand”
   • [claimed-docs] “use AI powered by Docusign Iris to instantly convert PDFs and templates”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to Docusign
   Clerky~partialprobed7/10

   Clerky ships a live MCP server (mcp.clerky.com) enabling Claude/ChatGPT and other AI assistants to invoke Clerky tools with team-scoped access, which is the mechanism for natural-language operation; a probe confirms the endpoint is real and OAuth-gated rather than vaporware. Missing for 10: no hands-on transcript or independent report of actually issuing natural-language commands through the MCP tools, and no evidence of a broader in-app conversational/NL command interface beyond the MCP integration.

   • [claimed-docs] “# Clerky MCP Server Clerky works with AI assistants that support remote [Model Context Protocol (MCP)](https://modelcontextprotocol.io/docs/…”
   • [probe] “PROBE remote MCP initialize (no token): {"error": "invalid_token", "error_description": "Authentication required"} HTTP 401 — live OAuth-gat…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developers.clerky.com/llms.txt - [Lifecycle](https://developers.clerky.com/getting-started/lifecycle/ind…”

   proof ↗⚑ flag

   Docusign✓fullprobed7/10

   Docusign documents a supported MCP connector enabling Claude, Gemini CLI, and Copilot Studio to query agreement status/metadata and trigger IAM workflow actions via natural-language commands, plus AI-powered chat interfaces for contract review and summaries. This directly shows natural-language operation of core agreement workflows through agentic integrations. Missing for 10: independent/hands-on user verification of the MCP connector's reliability and breadth of NL command coverage beyond vendor blog examples.

   • [claimed-docs] “Retrieve agreement context and metadata”
   • [claimed-docs] “Trigger workflow actions through IAM tools”
   • [claimed-docs] “The Docusign Connector in Anthropic Claude via MCP server provides a supported way to connect Claude to Docusign IAM capabilities.”
   • [claimed-docs] “Retrieve agreement context and metadata... Query agreement status and key dates... Trigger workflow actions through IAM tools”
   • [claimed-docs] “Query agreement data and automate agreement processes from your terminal by pairing Gemini CLI with Docusign MCP.”
   • [claimed-docs] “Build agreement workflows: Docusign MCP & Claude”
   • [claimed-docs] “Internal enterprise GitHub Copilot”
   • [probe] “official MCP server documented at https://developers.docusign.com/platform/mcp-server/”
   • [claimed-docs] “Review and analyze agreements, flag potentially risky language, suggest surgical edits, and draft new language from an intuitive AI-powered …”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   Clerky—none0/10

   Clerky's developer docs describe the Partner API lifecycle, forms, and authentication in prose (clerky-docs-19/20/21) and llms.txt lists doc pages, but there is no evidence of an interactive API reference (e.g., Swagger/OpenAPI explorer) or runnable examples; explicit probes for openapi.json/swagger.json all returned 404 (clerky-probe-3).

   • [claimed-docs] “# Introduction The Clerky Partner API lets partners bring a Clerky-powered formation workflow into their own product. It currently supports …”
   • [claimed-docs] “# Lifecycle A [document set][document-sets] moves through four partner-facing steps: create it, collect [form][forms] values, submit those v…”
   • [claimed-docs] “# Authentication The Clerky Partner API will use OAuth 2.0 bearer tokens. OAuth-based access is coming soon; client registration, URLs, scop…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://handbooks.clerky.com/openapi.json, https://handbooks.clerky.com/swagger.json, https://handbo…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developers.clerky.com/llms.txt - [Lifecycle](https://developers.clerky.com/getting-started/lifecycle/ind…”

   proof ↗⚑ flag

   Docusign—none0/10

   Evidence only shows a general Developer Center and REST API docs page plus an OpenAPI/Swagger spec repo, but nothing indicates an interactive, runnable API console; probes actually found 404s for openapi.json/llms.txt at the developer site, suggesting no readily discoverable interactive reference.

   • [claimed-docs] “Request Signatures & Automate Forms | REST API | Docusign”
   • [claimed-docs] “Docusign Developer Center | eSignature APIs & Resources | Docusign”
   • [github] “We use OpenAPI/Swagger files to build many of our developer tools including our client SDKs”
   • [github] “allows both humans and computers to discover and understand the capabilities of the service”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.docusign.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.docusign.com/openapi.json, https://developers.docusign.com/swagger.json, https://…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round to Docusign
   Clerky—none0/10

   Clerky has a documented Partner API with REST endpoints and JSON schema forms, but explicit probes for OpenAPI/Swagger spec files (openapi.json, swagger.json, .well-known/openapi.json) all returned 404, and no docs page offers a downloadable machine-readable spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://handbooks.clerky.com/openapi.json, https://handbooks.clerky.com/swagger.json, https://handbo…”
   • [claimed-docs] “# Introduction The Clerky Partner API lets partners bring a Clerky-powered formation workflow into their own product. It currently supports …”
   • [claimed-docs] “# Lifecycle A [document set][document-sets] moves through four partner-facing steps: create it, collect [form][forms] values, submit those v…”

   proof ↗⚑ flag

   Docusign✓fullprobed8/10

   Docusign publishes and maintains a dedicated GitHub repository of OpenAPI/Swagger specifications used to generate their client SDKs, explicitly stated to let 'humans and computers discover and understand the capabilities of the service', plus a REST API developer docs site. Missing for 10: a directly discoverable openapi.json/swagger.json at the main developer site (probe found 404s at common well-known paths), so users must know to find the GitHub repo rather than a single canonical spec URL.

   • [github] “We use OpenAPI/Swagger files to build many of our developer tools including our client SDKs”
   • [github] “allows both humans and computers to discover and understand the capabilities of the service”
   • [github] “We use OpenAPI/Swagger files to build many of our developer tools including our client SDKs using `swagger-codegen`.”
   • [claimed-docs] “Request Signatures & Automate Forms | REST API | Docusign”
   • [claimed-docs] “Docusign Developer Center | eSignature APIs & Resources | Docusign”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.docusign.com/openapi.json, https://developers.docusign.com/swagger.json, https://…”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round drawn
   Clerky—none0/10

   Clerky's Partner API and MCP server docs describe production workflows (document sets, OAuth, live formation filings) but no evidence anywhere mentions a sandbox, test mode, or staging environment separate from production data.

   • [claimed-docs] “# Introduction The Clerky Partner API lets partners bring a Clerky-powered formation workflow into their own product. It currently supports …”
   • [claimed-docs] “# Lifecycle A [document set][document-sets] moves through four partner-facing steps: create it, collect [form][forms] values, submit those v…”
   • [claimed-docs] “# Authentication The Clerky Partner API will use OAuth 2.0 bearer tokens. OAuth-based access is coming soon; client registration, URLs, scop…”
   • [claimed-docs] “# Clerky MCP Server Clerky works with AI assistants that support remote [Model Context Protocol (MCP)](https://modelcontextprotocol.io/docs/…”
   • [probe] “PROBE remote MCP initialize (no token): {"error": "invalid_token", "error_description": "Authentication required"} HTTP 401 — live OAuth-gat…”

   proof ↗⚑ flag

   Docusign—none0/10

   The evidence pack contains no mention of a developer/demo sandbox account, test environment, or non-production testing capability for Docusign's API or MCP connector; only production docs, SDKs, and integration guides are cited. missing for 10: explicit sandbox/demo account documentation, guidance on testing without production data, any developer-center reference to a sandbox environment.

   ⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round to Docusign
   Clerky—none0/10

   The Partner API docs show endpoints prefixed with /v1/ but there is no evidence of a documented API versioning scheme, changelog, or deprecation policy anywhere in the docs, llms.txt index, or OpenAPI probes (which 404). Missing for 10: any explicit versioning/deprecation policy documentation, changelog, or migration guidance for breaking changes.

   • [claimed-docs] “# Introduction The Clerky Partner API lets partners bring a Clerky-powered formation workflow into their own product. It currently supports …”
   • [claimed-docs] “# Lifecycle A [document set][document-sets] moves through four partner-facing steps: create it, collect [form][forms] values, submit those v…”
   • [claimed-docs] “# Authentication The Clerky Partner API will use OAuth 2.0 bearer tokens. OAuth-based access is coming soon; client registration, URLs, scop…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://handbooks.clerky.com/openapi.json, https://handbooks.clerky.com/swagger.json, https://handbo…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developers.clerky.com/llms.txt - [Lifecycle](https://developers.clerky.com/getting-started/lifecycle/ind…”

   proof ↗⚑ flag

   Docusign!disputedcontradicted3/10

   Docusign does expose versioned REST APIs (e.g. v2 eSignature API, OpenAPI/Swagger specs on GitHub) that could support a deprecation policy story, but no documented deprecation/versioning policy page is present, and a hands-on account describes being forced onto a 'legacy API version with no promise against sunsetting' after a security fix, directly contradicting reliable API lifecycle guarantees. missing for 10: an explicit deprecation-policy document, versioning changelog, and independent confirmation that old API versions are sunset predictably.

   • [community] “We wanted embedded flows with one API user, but discovered that on page refresh, users could break out of the signing page and view/click ar…”
   • [community] “We use the v2 REST API creating embedded envelope signing URLs without issues. Documentation is fantastic in its thoroughness - opposite exp…”
   • [github] “We use OpenAPI/Swagger files to build many of our developer tools including our client SDKs”
   • [claimed-docs] “Request Signatures & Automate Forms | REST API | Docusign”

   proof ↗⚑ flag

Audit

1. legal-ops leadRely on a tamper-evident audit trail and completion certificate for every signed document

   weight 2 · round to Clerky
   Clerky~partialclaimed2/10

   Clerky documents that it logs every change made to a document set or workspace so admins can see who did what, which is a basic audit-log capability, but there is no mention of tamper-evidence (e.g., cryptographic sealing, hash-chained logs) or of a signing completion certificate being issued for executed documents. Missing for 10: tamper-evident/cryptographic audit trail mechanics, completion certificate artifact, and any independent verification of these claims.

   • [claimed-docs] “We log every change anyone makes to a document set or workspace, so you can always see who was responsible for what.”

   proof ↗⚑ flag

   Docusign—none0/10

   The evidence pack contains no mention of a tamper-evident audit trail, certificate of completion, or any compliance/audit documentation for signed envelopes — only generic e-signature marketing copy, integrations, and AI features. Although this is a core, expected capability for an e-signature platform (so the axis applies), nothing in the provided docs, GitHub, or community sources substantiates it. missing for 10: documentation of Certificate of Completion, audit trail/tamper-evidence mechanism (e.g., hash-sealing, timestamping), and any independent verification of its integrity.

   ⚑ flag

2. legal-ops leadRequire stronger signer identity verification (SMS, ID check, knowledge-based) on sensitive documents

   weight 1 · round to Docusign
   Clerky—none0/10

   No evidence anywhere in the pack mentions signer identity verification methods like SMS, ID check, or knowledge-based authentication for document signing; Clerky's documentation focuses on formation workflows, collaboration, and audit logs, not signer verification strength.

   ⚑ flag

   Docusign✓fullclaimed8/10

   Docusign Identify offers multiple ID verification methods explicitly (SMS one-time-passcode, government ID + biometric check, knowledge-based/risk-based verification) and a Risk-Based Verification workflow that dynamically escalates verification strength based on risk — directly matching the legal-ops need for stronger identity checks on sensitive documents. The pricing page also confirms '5 identity verifications' as a configurable feature tier. Missing for 10: independent/hands-on third-party validation of these verification flows in practice and clearer documentation on per-document/per-envelope configuration granularity.

   • [claimed-docs] “Check the authenticity of government issue identity documents or verify recipient identities in less than a minute.”
   • [claimed-docs] “Enable repeat users to verify their identity by entering a one-time-passcode sent to their phone in seconds.”
   • [claimed-docs] “Dynamically adjust the type of verification your signers must complete based on an automated and instant risk assessment with our Risk-Based…”
   • [claimed-docs] “Require recipients to upload a photo of their government ID & complete a quick biometric challenge.”
   • [claimed-docs] “Reduce fraud risk with 5 identity verifications”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round drawn
   Clerky—none0/10

   Evidence shows Clerky's Partner API and MCP server operate on a single document set at a time (create, fill forms, submit, poll) with no batch/bulk endpoints or bulk document/task operations documented; task assignment features are per-item, not bulk. Missing for 10: any bulk create/update endpoint, batch API operations, or bulk import/export capability across multiple items.

   • [claimed-docs] “# Introduction The Clerky Partner API lets partners bring a Clerky-powered formation workflow into their own product. It currently supports …”
   • [claimed-docs] “# Lifecycle A [document set][document-sets] moves through four partner-facing steps: create it, collect [form][forms] values, submit those v…”
   • [claimed-docs] “# Clerky MCP Server Clerky works with AI assistants that support remote [Model Context Protocol (MCP)](https://modelcontextprotocol.io/docs/…”
   • [probe] “PROBE remote MCP initialize (no token): {"error": "invalid_token", "error_description": "Authentication required"} HTTP 401 — live OAuth-gat…”

   proof ↗⚑ flag

   Docusign—none0/10

   The evidence pack shows Docusign has a REST API, SDKs, and an MCP connector for triggering workflow actions, but nothing explicitly describes bulk/batch operations (e.g., a bulk-send feature, batch API endpoint, or multi-item automation) that would let an AI-native user act on many items at once. Missing for 10: any explicit bulk-send/batch-processing feature, batch API endpoint documentation, or evidence of MCP/agent tools operating on multiple envelopes/agreements simultaneously.

   • [claimed-docs] “Request Signatures & Automate Forms | REST API | Docusign”
   • [claimed-docs] “Send, sign, and approve documents using this client.”
   • [claimed-docs] “Retrieve agreement context and metadata”
   • [claimed-docs] “Trigger workflow actions through IAM tools”
   • [claimed-docs] “Retrieve agreement context and metadata... Query agreement status and key dates... Trigger workflow actions through IAM tools”

   proof ↗⚑ flag

Compliance

1. legal-ops leadSee a compliance calendar of upcoming filing deadlines and get reminders before each one

   weight 2 · round drawn
   Clerky—none0/10

   No evidence in the pack of any compliance calendar, filing-deadline tracking, or reminder feature; Clerky's evidence covers document formation, collaboration, task assignment, and API/MCP integrations but nothing about deadline tracking or reminders.

   ⚑ flag

   Docusign—none0/10

   No evidence in the pack references a compliance calendar, filing deadlines, or deadline reminder features; Docusign's evidence covers e-signature, CLM, AI review, identity verification, and integrations but nothing about tracking regulatory/filing deadlines or proactive reminders for legal-ops compliance calendars.

   ⚑ flag

Compliance agentic

1. ai-native userDelegate an annual report or compliance filing to an agent that prepares it through the platform with minimal human input

   weight 2 · round drawn
   Clerky~partialprobed4/10

   Clerky offers a remote MCP server and Partner API that let an AI assistant interact with document sets, forms, and workflow state (clerky-docs-19/20/22), and IRS forms can be completed and submitted online (clerky-docs-5/15), suggesting some agent-driven compliance work is possible. However, the probe shows the MCP tools are read-only with team-scoped OAuth access (clerky-probe-5), and there is no evidence of an actual 'annual report' or ongoing compliance-filing product, nor of an agent completing filings end-to-end with minimal human input. missing for 10: evidence of annual report/compliance-filing capability specifically, evidence the MCP/API can autonomously submit filings (not just read/collect data), and confirmation that human sign-off isn't required at each step.

   • [claimed-docs] “# Introduction The Clerky Partner API lets partners bring a Clerky-powered formation workflow into their own product. It currently supports …”
   • [claimed-docs] “# Lifecycle A [document set][document-sets] moves through four partner-facing steps: create it, collect [form][forms] values, submit those v…”
   • [claimed-docs] “# Clerky MCP Server Clerky works with AI assistants that support remote [Model Context Protocol (MCP)](https://modelcontextprotocol.io/docs/…”
   • [probe] “PROBE remote MCP initialize (no token): {"error": "invalid_token", "error_description": "Authentication required"} HTTP 401 — live OAuth-gat…”
   • [claimed-docs] “Use Clerky to complete IRS forms and submit them to the IRS, completely online. No need for a fax machine.”
   • [claimed-docs] “Use Clerky to complete IRS forms and submit them to the IRS, completely online. No need for a fax machine. 100% in-house, not outsourced.”

   proof ↗⚑ flag

   Docusign~partialprobed4/10

   Docusign's MCP connector lets an agent (e.g. Claude) retrieve agreement context, query status, and trigger IAM workflow actions, and its CLM/AI-Assisted Review features can flag non-compliant clauses and draft language, suggesting a path toward agent-driven contract/compliance workflows. However, there is no evidence of an agent autonomously preparing a full 'annual report' or 'compliance filing' end-to-end with minimal human input — the evidence only covers discrete building blocks (signing, clause review, status queries) rather than a demonstrated compliance-filing delegation flow. Missing for 10: concrete example of an agent completing a compliance filing/annual report task autonomously, evidence of minimal-human-input completion, and independent corroboration beyond vendor blog/docs.

   • [claimed-docs] “The Docusign Connector in Anthropic Claude via MCP server provides a supported way to connect Claude to Docusign IAM capabilities.”
   • [claimed-docs] “Retrieve agreement context and metadata... Query agreement status and key dates... Trigger workflow actions through IAM tools”
   • [claimed-docs] “use AI to flag non-compliant clauses, suggest approved language, and draft new clauses on demand”
   • [claimed-docs] “Review and analyze agreements, flag potentially risky language, suggest surgical edits, and draft new language from an intuitive AI-powered …”
   • [claimed-docs] “Review agreements against your playbooks and ready-to-deploy agents and get suggested redlines to align terms with your requirements.”
   • [claimed-docs] “Build agreement workflows: Docusign MCP & Claude”
   • [probe] “official MCP server documented at https://developers.docusign.com/platform/mcp-server/”

   proof ↗⚑ flag

Clm agentic

1. ai-native userHave an agent monitor contract renewals and deadlines through the product's API and act before they lapse

   weight 2 · round to Docusign
   Clerky—none0/10

   Clerky's API and MCP server are scoped to formation document-set workflows (create, fill forms, sign, poll lifecycle state) — there is no evidence of tracking contract renewal dates, deadline alerts, or proactive lapse-prevention actions via the API or MCP tools.

   • [claimed-docs] “# Introduction The Clerky Partner API lets partners bring a Clerky-powered formation workflow into their own product. It currently supports …”
   • [claimed-docs] “# Lifecycle A [document set][document-sets] moves through four partner-facing steps: create it, collect [form][forms] values, submit those v…”
   • [claimed-docs] “# Clerky MCP Server Clerky works with AI assistants that support remote [Model Context Protocol (MCP)](https://modelcontextprotocol.io/docs/…”
   • [probe] “PROBE remote MCP initialize (no token): {"error": "invalid_token", "error_description": "Authentication required"} HTTP 401 — live OAuth-gat…”

   proof ↗⚑ flag

   Docusign~partialprobed7/10

   Docusign's REST API and new MCP connector explicitly expose agreement status, key dates, and metadata, and let AI agents (Claude, Gemini CLI, Copilot) trigger workflow actions through IAM tools, which supports agent-driven monitoring and pre-lapse action. However, there's no explicit documentation of renewal-specific alerts/triggers or an end-to-end example of an agent proactively acting before a deadline lapses, and no independent corroboration of this MCP monitoring workflow in production. Missing for 10: explicit renewal/deadline-triggered automation examples, third-party/hands-on validation of the MCP agent acting autonomously before lapse.

   • [claimed-docs] “Retrieve agreement context and metadata”
   • [claimed-docs] “Trigger workflow actions through IAM tools”
   • [claimed-docs] “The Docusign Connector in Anthropic Claude via MCP server provides a supported way to connect Claude to Docusign IAM capabilities.”
   • [claimed-docs] “Retrieve agreement context and metadata... Query agreement status and key dates... Trigger workflow actions through IAM tools”
   • [probe] “official MCP server documented at https://developers.docusign.com/platform/mcp-server/”
   • [claimed-docs] “Query agreement data and automate agreement processes from your terminal by pairing Gemini CLI with Docusign MCP.”
   • [claimed-docs] “Build agreement workflows: Docusign MCP & Claude”

   proof ↗⚑ flag

Clm authoring

1. legal-ops leadDraft, negotiate, and redline contracts in a controlled workflow instead of email attachments

   weight 3 · round to Docusign
   Clerky~partialclaimed4/10

   Clerky offers real-time collaboration, attorney review/comment, customization of key terms, and full audit logging of document set changes, which supports a 'controlled workflow instead of email attachments' for its own formation/equity documents. However, there is no evidence of redlining, track-changes, or multi-round negotiation with external counterparties—Clerky's workflow is field-based data entry and e-signature for standardized startup legal docs, not general contract redlining. Missing for 10: explicit redline/track-changes tooling, version comparison, negotiation cycles with external parties, and support for arbitrary (non-template) contracts.

   • [claimed-docs] “We log every change anyone makes to a document set or workspace, so you can always see who was responsible for what.”
   • [claimed-docs] “you can easily loop in your attorney to have them review and comment on the information you're entering.”
   • [claimed-docs] “Our software makes it easy to invite other people to collaborate on a document set, in real-time.”
   • [claimed-docs] “Our software makes it easy to invite other people to collaborate on a document set, in real-time. Rest easy knowing everyone is looking at t…”
   • [claimed-docs] “Our software makes it easy to customize the key terms of the legal paperwork you're working on.”

   proof ↗⚑ flag

   Docusign~partialclaimed6/10

   Docusign CLM and AI-Assisted Review offer redlining, playbook-based suggested edits, and MS Word integration for contract negotiation, moving beyond email attachments, and web forms/templates support structured drafting workflows. However, evidence is entirely vendor-sourced marketing copy with no independent hands-on account of a full negotiation/redline cycle, and community threads focus on unrelated integration/security complaints rather than corroborating the CLM/redlining workflow. Missing for 10: independent or hands-on verification of the redline/negotiation workflow in practice, detail on multi-party version control during negotiation, and confirmation that AI-Assisted Review's Word integration handles full negotiation cycles reliably.

   • [claimed-docs] “use AI to flag non-compliant clauses, suggest approved language, and draft new clauses on demand”
   • [claimed-docs] “Use a drag-and-drop editor to design contract processes”
   • [claimed-docs] “Review and analyze agreements, flag potentially risky language, suggest surgical edits, and draft new language from an intuitive AI-powered …”
   • [claimed-docs] “Review agreements against your playbooks and ready-to-deploy agents and get suggested redlines to align terms with your requirements.”
   • [claimed-docs] “Docusign AI-Assisted Review integrates into MS Word to analyze, redline, and draft language based on your playbooks.”
   • [claimed-docs] “Generate contracts in a click with dynamic templates and use AI to flag non-compliant clauses, suggest approved language, and draft new clau…”
   • [claimed-docs] “Leverage AI to easily create new contract review playbooks based on your standard templates or other reference documents.”

   proof ↗⚑ flag

Clm repository

1. legal-ops leadStore executed contracts in a searchable repository with key terms and metadata extracted

   weight 2 · round to Docusign
   Clerky—none0/10

   Clerky is a formation/document-generation tool; evidence covers document sets, activity logs, and collaboration but nothing about a searchable repository of executed contracts with extracted key terms/metadata—no full-text search, term extraction, or metadata tagging is described anywhere in the pack.

   ⚑ flag

   Docusign✓fullclaimed7/10

   Docusign's IAM/CLM platform explicitly markets a searchable agreement repository ('Securely store and access all your agreements in one place', 'Find, analyze, and act on agreements powered by AI') plus metadata/key-term extraction via AI-assisted review and MCP connector features ('Retrieve agreement context and metadata', AI flags clauses and suggests terms). This directly matches the legal-ops story of a searchable repository with extracted key terms and metadata. missing for 10: independent/hands-on corroboration of the repository search and metadata-extraction UX, and detail on extraction accuracy or breadth of metadata fields captured

   • [claimed-docs] “Securely store and access all your agreements in one place”
   • [claimed-docs] “Find, analyze, and act on agreements powered by AI”
   • [claimed-docs] “Analyze agreements with AI, sign documents electronically, and automate workflows with the Intelligent Agreement Management (IAM) platform.”
   • [claimed-docs] “Retrieve agreement context and metadata”
   • [claimed-docs] “use AI to flag non-compliant clauses, suggest approved language, and draft new clauses on demand”
   • [claimed-docs] “Review and analyze agreements, flag potentially risky language, suggest surgical edits, and draft new language from an intuitive AI-powered …”
   • [claimed-docs] “Leverage AI to easily create new contract review playbooks based on your standard templates or other reference documents.”

   proof ↗⚑ flag

Clm workflow

1. legal-ops leadRoute contracts through configurable approval workflows before signature

   weight 2 · round to Docusign
   Clerky—none0/10

   Clerky's evidence covers document generation, collaboration, task assignment, and attorney review invites, but nothing describes configurable approval workflows/routing before signature (e.g., multi-step approval chains, conditional routing rules, or sign-off gating). Collaboration/task features are not the same as an approval workflow engine.

   • [claimed-docs] “We've built features that let you easily assign tasks to co-founders and work on everything together.”
   • [claimed-docs] “you can easily loop in your attorney to have them review and comment on the information you're entering.”
   • [claimed-docs] “Our software makes it easy to invite other people to collaborate on a document set, in real-time.”
   • [claimed-docs] “Our software makes it easy to invite other people to collaborate on a document set, in real-time. Rest easy knowing everyone is looking at t…”

   proof ↗⚑ flag

   Docusign~partialclaimed6/10

   Docusign explicitly markets configurable workflows (docusign-docs-4), CLM drag-and-drop process design (docusign-docs-17), and delegated signing (docusign-docs-9), and integrates with systems like Salesforce for auto-populating agreements (docusign-docs-24), which together support pre-signature approval routing. However, the evidence lacks detail on how approval-specific routing (multi-stage sign-off before signature) is configured, no independent/hands-on validation of workflow configuration exists, and community evidence focuses on embedded signing/security issues rather than approval workflows. Missing for 10: concrete documentation or demo of approval-stage routing logic, independent corroboration of workflow configurability, and detail on approval conditions/rules engine.

   • [claimed-docs] “take advantage of configurable workflows to tackle your trickiest agreement challenges”
   • [claimed-docs] “Use a drag-and-drop editor to design contract processes”
   • [claimed-docs] “Avoid delays by enabling delegated signing”
   • [claimed-docs] “Auto-populate new agreements with data from systems like Salesforce”
   • [claimed-docs] “Generate contracts in a click with dynamic templates and use AI to flag non-compliant clauses, suggest approved language, and draft new clau…”

   proof ↗⚑ flag

Doc api

1. ai-native userHave an agent draft an NDA and route it for signature end-to-end via the product's API or MCP server

   weight 3 · round to Docusign
   Clerky—none0/10

   Clerky's Partner API and MCP server are real and documented, but the API explicitly states it 'currently supports Delaware C-Corporation formations' only, and the MCP server tools are scoped to Clerky's startup-formation document sets (cap tables, safes, stock plans) — there is no evidence of NDA drafting or NDA e-signature routing via either channel.

   • [claimed-docs] “# Introduction The Clerky Partner API lets partners bring a Clerky-powered formation workflow into their own product. It currently supports …”
   • [claimed-docs] “# Lifecycle A [document set][document-sets] moves through four partner-facing steps: create it, collect [form][forms] values, submit those v…”
   • [claimed-docs] “# Clerky MCP Server Clerky works with AI assistants that support remote [Model Context Protocol (MCP)](https://modelcontextprotocol.io/docs/…”
   • [probe] “PROBE remote MCP initialize (no token): {"error": "invalid_token", "error_description": "Authentication required"} HTTP 401 — live OAuth-gat…”

   proof ↗⚑ flag

   Docusign~partialprobed6/10

   Docusign provides real building blocks: a REST/eSign API to create envelopes and route documents for signature (docusign-docs-21, docusign-docs-40), an official MCP server connector for Claude that can retrieve agreement context and 'trigger workflow actions through IAM tools' (docusign-docs-47, docusign-probe-3), and AI-assisted drafting/redlining features (docusign-docs-16, docusign-docs-20, docusign-docs-44) that could draft NDA language. However, no single documented workflow shows an agent drafting an NDA and then routing it end-to-end for signature purely via the MCP server or API in one flow — drafting lives in CLM/AI-Assisted Review while signature routing lives in eSignature API/MCP triggers, and there's no first-party or independent example stitching these together for a document like an NDA. missing for 10: an explicit worked example (docs or hands-on) of drafting+signature routing combined via MCP/API, independent confirmation the MCP trigger actions actually send envelopes, and any real-world demo showing this specific NDA-drafting-to-signature pipeline.

   • [claimed-docs] “Request Signatures & Automate Forms | REST API | Docusign”
   • [claimed-docs] “The Official Docusign Node.js Client Library used to interact with the eSign REST API. Send, sign, and approve documents using this client.”
   • [claimed-docs] “Retrieve agreement context and metadata... Query agreement status and key dates... Trigger workflow actions through IAM tools”
   • [claimed-docs] “use AI to flag non-compliant clauses, suggest approved language, and draft new clauses on demand”
   • [claimed-docs] “Review and analyze agreements, flag potentially risky language, suggest surgical edits, and draft new language from an intuitive AI-powered …”
   • [probe] “official MCP server documented at https://developers.docusign.com/platform/mcp-server/”
   • [claimed-docs] “Build agreement workflows: Docusign MCP & Claude”

   proof ↗⚑ flag

2. developerGenerate, populate, and send legal documents programmatically through a documented API

   weight 3 · round to Clerky
   Clerky~partialprobed5/10

   Clerky publishes a documented Partner API with concrete lifecycle steps (create document set, GET forms with json_schema, POST values, poll state) covering document generation and population (clerky-docs-19, clerky-docs-20). However, the API currently only supports Delaware C-Corp formations, OAuth-based authentication is explicitly stated as 'coming soon' rather than live (clerky-docs-21), and 'sending' is really 'user signs on Clerky' rather than a programmatic send step, so the story is only partially realized in production. Missing for 10: live/production authentication for partners, broader document-type coverage beyond formations, and independent/hands-on evidence of a working end-to-end integration.

   • [claimed-docs] “# Introduction The Clerky Partner API lets partners bring a Clerky-powered formation workflow into their own product. It currently supports …”
   • [claimed-docs] “# Lifecycle A [document set][document-sets] moves through four partner-facing steps: create it, collect [form][forms] values, submit those v…”
   • [claimed-docs] “# Authentication The Clerky Partner API will use OAuth 2.0 bearer tokens. OAuth-based access is coming soon; client registration, URLs, scop…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developers.clerky.com/llms.txt - [Lifecycle](https://developers.clerky.com/getting-started/lifecycle/ind…”

   proof ↗⚑ flag

   Docusign!disputedcontradicted6/10

   Docusign ships a well-documented REST API, official OpenAPI specs, and client SDKs (e.g. Node.js) explicitly for generating, populating, and sending agreements programmatically, and some developers report smooth, well-documented integrations. However, other hands-on reports describe the API as an 'afterthought' compared to competitors, cite a security flaw in embedded signing flows, and describe failed/costly integration attempts, directly contradicting the polished vendor narrative. missing for 10: consistent independent confirmation without contradicting failure reports, and a working openapi.json/llms.txt discovery endpoint (both probes 404).

   • [claimed-docs] “Request Signatures & Automate Forms | REST API | Docusign”
   • [claimed-docs] “Docusign Developer Center | eSignature APIs & Resources | Docusign”
   • [github] “We use OpenAPI/Swagger files to build many of our developer tools including our client SDKs”
   • [claimed-docs] “Send, sign, and approve documents using this client.”
   • [community] “We did exactly this embedded signing integration and it was fairly seamless - built a POC in Postman in about an hour and a Jr dev built a p…”
   • [community] “We use the v2 REST API creating embedded envelope signing URLs without issues. Documentation is fantastic in its thoroughness - opposite exp…”
   • [community] “We wanted embedded flows with one API user, but discovered that on page refresh, users could break out of the signing page and view/click ar…”
   • [community] “If you're trying to wrap an e-sign provider within your application, I would recommend HelloSign 1000x. HelloSign's API is a first class cit…”
   • [community] “I once worked at a company that dealt with DocuSign integration; rumors were we paid more than double $20,000, and the integration never rea…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.docusign.com/openapi.json, https://developers.docusign.com/swagger.json, https://…”

   proof ↗⚑ flag

Governance

1. legal-ops leadPrepare board consents and resolutions and collect approvals online

   weight 2 · round to Docusign
   Clerky~partialcommunity5/10

   Clerky's docs describe document-set collaboration, inviting co-founders/attorneys to review and comment in real-time, and issuing stock/options (which typically requires board approval) — these features generally support drafting and collecting sign-off on corporate paperwork online. However, no evidence explicitly names 'board consents' or 'resolutions' as a document type or confirms an approval-workflow specifically for board actions. Missing for 10: explicit mention of board consent/resolution templates, a dedicated approval/e-signature workflow for board members, and independent confirmation that board-level approvals are collected through the platform.

   • [claimed-docs] “Issue safes or convertible notes. Hire employees, consultants, and advisors, and issue stock or stock options as equity compensation.”
   • [claimed-docs] “Our software makes it easy to invite other people to collaborate on a document set, in real-time.”
   • [claimed-docs] “Our software makes it easy to invite other people to collaborate on a document set, in real-time. Rest easy knowing everyone is looking at t…”
   • [claimed-docs] “you can easily loop in your attorney to have them review and comment on the information you're entering.”
   • [claimed-docs] “We've built features that let you easily assign tasks to co-founders and work on everything together.”
   • [community] “Clerky gives me management tools (including the post-incorporation package: Fundraising, Hiring and Maintenance) although this does not give…”

   proof ↗⚑ flag

   Docusign✓fullcommunity7/10

   Docusign's core eSignature product supports creating reusable templates, configurable workflows, and routing for multi-party sign-off, which covers preparing and circulating documents like board consents/resolutions and collecting approvals online. However, there is no evidence of legal-ops-specific board-resolution templates or governance-specific workflow features, and community feedback flags integration/security friction that could affect legal-ops implementations. Missing for 10: dedicated board-resolution/corporate-governance templates, evidence of legal-ops specific approval chains (e.g., quorum tracking), and independent validation of reliability for this exact use case.

   • [claimed-docs] “take advantage of configurable workflows to tackle your trickiest agreement challenges”
   • [claimed-docs] “Save hours of manual setup with reusable templates”
   • [claimed-docs] “Standardize agreements by sharing templates with your team”
   • [claimed-docs] “Avoid delays by enabling delegated signing”
   • [claimed-docs] “Securely store and access all your agreements in one place”
   • [community] “We use the v2 REST API creating embedded envelope signing URLs without issues. Documentation is fantastic in its thoroughness - opposite exp…”

   proof ↗⚑ flag

Hiring

1. legal-ops leadRun hiring and equity paperwork — offer letters, confidentiality/IP agreements, and option grants — through the platform

   weight 2 · round to Clerky
   Clerky✓fullcommunity8/10

   Clerky's own product docs explicitly cover hiring paperwork (offer/hiring workflows), confidentiality/IP agreements implied via founder/employee onboarding docs, and equity issuance (stock, stock options, safes, convertible notes) via a stock plan, plus attorney oversight/collaboration features for legal-ops review. Community reviews corroborate real-world use of the hiring/fundraising/maintenance packages. Missing for 10: explicit mention of confidentiality/IP agreement templates by name and independent case studies detailing legal-ops workflows specifically.

   • [claimed-docs] “Issue safes or convertible notes. Hire employees, consultants, and advisors, and issue stock or stock options as equity compensation.”
   • [claimed-docs] “Adopt a stock plan to easily issue restricted stock or stock options to employees, consultants, and advisors.”
   • [claimed-docs] “Forming a startup on Clerky enables access to a legal dashboard that makes it easy to do additional legal paperwork.”
   • [claimed-docs] “you can easily loop in your attorney to have them review and comment on the information you're entering.”
   • [community] “Clerky gives me management tools (including the post-incorporation package: Fundraising, Hiring and Maintenance) although this does not give…”

   proof ↗⚑ flag

   Docusign~partialclaimed5/10

   Docusign's generic eSignature and template/workflow features (reusable templates, configurable workflows, real-time collaboration, Salesforce integration) could be used to send and sign offer letters, IP agreements, or option grants, but there is no evidence of equity/HR-specific templates, cap-table or option-grant management integration, or hiring-specific workflow support. Missing for 10: dedicated offer-letter/option-grant templates, HR/equity system integrations (e.g., cap table tools like Carta), and any case study or docs specifically covering hiring/equity paperwork use cases.

   • [claimed-docs] “Save hours of manual setup with reusable templates”
   • [claimed-docs] “Standardize agreements by sharing templates with your team”
   • [claimed-docs] “take advantage of configurable workflows to tackle your trickiest agreement challenges”
   • [claimed-docs] “Easily integrate your agreements with your apps of choice, including Salesforce, Microsoft, Google, Zoom and more.”
   • [claimed-docs] “Send, sign, and succeed with the world’s #1 eSignature solution and the world’s #1 CRM, together.”

   proof ↗⚑ flag

Esign

1. founderSend a document for legally binding e-signature to multiple recipients with routing

   weight 3 · round to Docusign
   Clerky~partialclaimed4/10

   Clerky's document sets clearly involve multiple signers (collaborators, attorneys, co-founders) and a signing workflow (clerky-docs-13/17, clerky-docs-19/20), but this is signing within Clerky's own fixed legal document templates rather than a general-purpose 'send any document for signature with custom multi-recipient routing' capability. No evidence describes configurable signing order, roles, or routing logic for recipients. Missing for 10: explicit documentation of routing/sequencing controls, ability to send arbitrary documents (not just Clerky-generated ones) for signature, and independent confirmation of multi-recipient routing behavior.

   • [claimed-docs] “Our software makes it easy to invite other people to collaborate on a document set, in real-time.”
   • [claimed-docs] “Our software makes it easy to invite other people to collaborate on a document set, in real-time. Rest easy knowing everyone is looking at t…”
   • [claimed-docs] “# Introduction The Clerky Partner API lets partners bring a Clerky-powered formation workflow into their own product. It currently supports …”
   • [claimed-docs] “# Lifecycle A [document set][document-sets] moves through four partner-facing steps: create it, collect [form][forms] values, submit those v…”

   proof ↗⚑ flag

   Docusign✓fullcommunity8/10

   Docusign's core eSignature product explicitly supports configurable workflows, delegated signing, and sending to multiple recipients with routing, backed by extensive first-party docs and a mature REST API/SDKs for building signing flows. Community evidence (comm-4, comm-5) corroborates that embedded/API-based signing works smoothly in practice, though other community reports focus on unrelated integration/security complaints rather than the routing feature itself. Missing for 10: independent hands-on confirmation specifically of multi-recipient sequential/parallel routing behavior (most community evidence discusses embedded signing or security, not routing order).

   • [claimed-docs] “Send, sign and manage all your agreements for free.”
   • [claimed-docs] “take advantage of configurable workflows to tackle your trickiest agreement challenges”
   • [claimed-docs] “Avoid delays by enabling delegated signing”
   • [claimed-docs] “Request Signatures & Automate Forms | REST API | Docusign”
   • [community] “We did exactly this embedded signing integration and it was fairly seamless - built a POC in Postman in about an hour and a Jr dev built a p…”
   • [community] “We use the v2 REST API creating embedded envelope signing URLs without issues. Documentation is fantastic in its thoroughness - opposite exp…”

   proof ↗⚑ flag

Esign embed

1. developerEmbed the signing experience inside my own app or website

   weight 2 · round to Clerky
   Clerky~partialclaimed5/10

   Clerky's Partner API lets a developer create a document set, render forms, and collect data inside their own product, but the docs explicitly state 'Users enter formation information in your product and sign documents on Clerky' — meaning the actual signing step happens on Clerky's own platform rather than being embedded, and OAuth authentication for partners is still listed as 'coming soon' rather than live. missing for 10: evidence of an embeddable signing widget/iframe, live partner OAuth flow, and any third-party confirmation of a working embedded integration.

   • [claimed-docs] “# Introduction The Clerky Partner API lets partners bring a Clerky-powered formation workflow into their own product. It currently supports …”
   • [claimed-docs] “# Lifecycle A [document set][document-sets] moves through four partner-facing steps: create it, collect [form][forms] values, submit those v…”
   • [claimed-docs] “# Authentication The Clerky Partner API will use OAuth 2.0 bearer tokens. OAuth-based access is coming soon; client registration, URLs, scop…”

   proof ↗⚑ flag

   Docusign!disputedcontradicted6/10

   Docusign's docs and API support embedding signing/forms into apps (docusign-docs-43 embed forms, docusign-docs-21/22 REST API for building custom flows), and community reports confirm working embedded signing integrations built via the REST API (docusign-comm-4, docusign-comm-5). However, a separate hands-on account documents a concrete security flaw in the embedded signing flow — users could break out of the signing iframe and access the whole account, forcing a downgrade to a legacy API (docusign-comm-1) — a documented counter-example that contradicts the claim of a clean embed experience. Missing for 10: first-party embedded-signing quickstart/tutorial evidence, resolution confirmation of the reported security issue, and independent recent corroboration beyond a single old HN thread.

   • [claimed-docs] “Embed forms directly into your business applications, so your customers get the consistent user experience and look they expect from your br…”
   • [claimed-docs] “Request Signatures & Automate Forms | REST API | Docusign”
   • [community] “We wanted embedded flows with one API user, but discovered that on page refresh, users could break out of the signing page and view/click ar…”
   • [community] “We did exactly this embedded signing integration and it was fairly seamless - built a POC in Postman in about an hour and a Jr dev built a p…”
   • [community] “We use the v2 REST API creating embedded envelope signing URLs without issues. Documentation is fantastic in its thoroughness - opposite exp…”
   • [community] “If you're trying to wrap an e-sign provider within your application, I would recommend HelloSign 1000x. HelloSign's API is a first class cit…”

   proof ↗⚑ flag

Esign scale

1. legal-ops leadBulk-send the same document to many recipients at once

   weight 1 · round drawn
   Clerky—none0/10

   Clerky's evidence describes single document-set collaboration, invitations, and signature workflows for specific named parties (co-founders, employees, attorneys) but nothing about bulk-sending one document to many recipients at once, a feature typical of e-signature platforms like DocuSign.

   ⚑ flag

   Docusign—none0/10

   The evidence pack describes templates, workflows, branding, identity verification, and AI features but never mentions a bulk-send/mass-mail capability for sending one document to many recipients simultaneously. Missing for 10: any documentation of a 'bulk send' or mass-recipient distribution feature, recipient list upload, or per-recipient tracking at scale.

   ⚑ flag

2. legal-ops leadSet signing order, automatic reminders, and expirations on outstanding signature requests

   weight 1 · round to Docusign
   Clerky—none0/10

   No evidence describes signing order, automatic reminders, or expiration settings for signature requests; Clerky's evidence focuses on document collaboration, workspace access, and formation workflows, not e-signature controls of this kind.

   ⚑ flag

   Docusign~partialclaimed3/10

   Evidence only vaguely references 'configurable workflows' and 'delegated signing' for agreement flows, with no explicit documentation of signing order/routing, automatic reminder scheduling, or envelope expiration settings, which are the specific capabilities the story asks about. Missing for 10: explicit docs on setting signer routing order, reminder frequency/timing configuration, and expiration date settings for envelopes.

   • [claimed-docs] “take advantage of configurable workflows to tackle your trickiest agreement challenges”
   • [claimed-docs] “Avoid delays by enabling delegated signing”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Docusign
   Clerky~partialclaimed4/10

   Clerky has a Partner API but it explicitly 'currently supports Delaware C-Corporation formations' only, a narrow subset of the 40+ products, safes, stock plans, hiring, banking integrations, and legal dashboard features described in the UI docs. OAuth authentication is also still 'coming soon,' meaning the API isn't even fully live yet, and there's no evidence of API coverage for post-formation workflows (safes, convertible notes, hiring, stock issuance, IRS filing, banking apps) that are core UI capabilities. Missing for 10: API coverage for post-incorporation products (safes, hiring, equity issuance, IRS/bank filings), live OAuth access, and evidence of parity across the 40+ advanced products.

   • [claimed-docs] “# Introduction The Clerky Partner API lets partners bring a Clerky-powered formation workflow into their own product. It currently supports …”
   • [claimed-docs] “# Lifecycle A [document set][document-sets] moves through four partner-facing steps: create it, collect [form][forms] values, submit those v…”
   • [claimed-docs] “# Authentication The Clerky Partner API will use OAuth 2.0 bearer tokens. OAuth-based access is coming soon; client registration, URLs, scop…”
   • [claimed-docs] “Issue safes or convertible notes. Hire employees, consultants, and advisors, and issue stock or stock options as equity compensation.”
   • [claimed-docs] “Attorney accounts get access to over 40 advanced products that are not publicly available.”
   • [claimed-docs] “Apply for accounts with the most popular banks for startups. Pre-filled applications make it as easy as possible.”

   proof ↗⚑ flag

   Docusign~partialprobed5/10

   Docusign publishes a comprehensive eSignature REST API, SDKs, OpenAPI specs, and an MCP server enabling programmatic sending, signing, and workflow triggering (docusign-docs-21, docusign-gh-1, docusign-docs-47, docusign-probe-3), but several UI-only capabilities (CLM drag-and-drop process builder, web-forms drag-and-drop editor, AI-assisted review chat) are marketed as click/drag experiences without documented API equivalents. Community reports also describe real API limitations/security issues in embedded signing flows that forced a downgrade to a legacy API (docusign-comm-1), undercutting full UI/API parity. Missing for 10: explicit API endpoints for CLM workflow design, web-forms builder, and AI-review features, plus independent confirmation that all UI actions are API-reachable without workarounds.

   • [claimed-docs] “Request Signatures & Automate Forms | REST API | Docusign”
   • [github] “We use OpenAPI/Swagger files to build many of our developer tools including our client SDKs”
   • [claimed-docs] “Retrieve agreement context and metadata... Query agreement status and key dates... Trigger workflow actions through IAM tools”
   • [probe] “official MCP server documented at https://developers.docusign.com/platform/mcp-server/”
   • [community] “We wanted embedded flows with one API user, but discovered that on page refresh, users could break out of the signing page and view/click ar…”
   • [claimed-docs] “Use a drag-and-drop editor to design contract processes”
   • [claimed-docs] “Use drag-and-drop functionality and clicks, not code, to build your forms in minutes.”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round drawn
   Clerky—none0/10

   No evidence of any bulk data export in open/standard formats (e.g., document download bundles, JSON/CSV exports of legal data) for users to take their data and leave; the Partner API and MCP server are designed for partner integrations/AI assistants working within Clerky, not full data portability/exit. Probes also show no llms.txt/docs export or export-oriented endpoints beyond the legal-workflow API.

   • [claimed-docs] “# Introduction The Clerky Partner API lets partners bring a Clerky-powered formation workflow into their own product. It currently supports …”
   • [claimed-docs] “# Authentication The Clerky Partner API will use OAuth 2.0 bearer tokens. OAuth-based access is coming soon; client registration, URLs, scop…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://handbooks.clerky.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://handbooks.clerky.com/legal-concepts.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://handbooks.clerky.com/openapi.json, https://handbooks.clerky.com/swagger.json, https://handbo…”

   proof ↗⚑ flag

   Docusign—none0/10

   The evidence pack shows Docusign APIs for sending/retrieving individual agreements and metadata, but no documented bulk data-export tool, account-closure export, or open-format portability feature that would let a user extract all their data and leave the platform.

   ⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round drawn
   Clerky—none0/10

   Clerky is a closed-source legal SaaS product; there is no evidence of any open-source license or public source repository, and probes for open documentation/API artifacts returned 404s. Missing for 10: any open-source license, public code repository, or source availability statement.

   • [probe] “PROBE llms.txt: HTTP 404 at https://handbooks.clerky.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://handbooks.clerky.com/legal-concepts.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://handbooks.clerky.com/openapi.json, https://handbooks.clerky.com/swagger.json, https://handbo…”

   proof ↗⚑ flag

   Docusign—none0/10

   Docusign is a closed-source commercial SaaS platform; while it publishes SDKs, OpenAPI specs, and an MCP connector, none of the evidence indicates the core product source is released under an open license, and its client libraries/specs are auxiliary developer tools rather than the product's source.

   ⚑ flag

1. ai-native userPrevent my data from being used to train AI models

   weight 3 · round drawn
   Clerky—none0/10

   No evidence in the pack addresses AI training data usage, opt-out settings, or any privacy policy statement about model training; Clerky's materials focus on legal document workflows, MCP/API integration, and formation services with nothing on this axis.

   ⚑ flag

   Docusign—none0/10

   The evidence pack contains no mention of AI training data opt-out, data usage policies, or privacy controls specific to AI model training; only unrelated feature and integration descriptions plus community complaints about API issues and phishing. Missing for 10: any documented opt-out/consent mechanism for AI training, privacy policy language on data usage, or admin controls to restrict data use for model training.

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Clerky—none0/10

   No evidence in the pack addresses data retention policies, export, or deletion controls for user data within Clerky; the docs focus on formation, collaboration, and MCP/API features, none of which mention retention or deletion. Missing for 10: any documentation of data retention periods, deletion requests, or export/erasure controls.

   ⚑ flag

   Docusign—none0/10

   No evidence in the pack addresses data retention policies, deletion controls, or configurable data lifecycle management for AI/agent interactions; the evidence covers e-signature, CLM, identity verification, and MCP connector features but nothing about retention/deletion settings.

   ⚑ flag

3. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Clerky—none0/10

   No evidence in the pack addresses telemetry, usage tracking, or any opt-out mechanism for Clerky; the documentation focuses entirely on legal/document workflows with no privacy-controls content.

   ⚑ flag

   Docusign—none0/10

   No evidence in the pack addresses telemetry/usage-tracking opt-out settings for Docusign or its AI features; the pack covers product features, integrations, and unrelated community complaints. This axis applies to any AI-native product handling user data, but no documentation of an opt-out mechanism exists.

   ⚑ flag

Templates

1. founderStart from a library of vetted standard legal templates (NDAs, agreements, policies) instead of hiring counsel for routine documents

   weight 2 · round to Clerky
   Clerky~partialcommunity5/10

   Clerky documents show a template-driven system for startup-specific legal paperwork (formation, safes/convertible notes, stock plans, hiring/equity agreements, IRS forms) that lets founders self-serve rather than hire counsel for those documents. However, the evidence never mentions NDAs, general contract templates, or company policy documents, which are explicitly named in the story. Missing for 10: evidence of NDA templates, general business agreement templates, and policy document templates beyond incorporation/equity paperwork.

   • [claimed-docs] “Issue safes or convertible notes. Hire employees, consultants, and advisors, and issue stock or stock options as equity compensation.”
   • [claimed-docs] “Adopt a stock plan to easily issue restricted stock or stock options to employees, consultants, and advisors.”
   • [claimed-docs] “Use Clerky to complete IRS forms and submit them to the IRS, completely online. No need for a fax machine.”
   • [claimed-docs] “Our software makes it easy to customize the key terms of the legal paperwork you're working on.”
   • [community] “Clerky gives me management tools (including the post-incorporation package: Fundraising, Hiring and Maintenance) although this does not give…”

   proof ↗⚑ flag

   Docusign—none0/10

   Docusign's evidence describes reusable/custom templates that users build and share within their own workflows (e.g., docusign-docs-6, docusign-docs-7, docusign-docs-34), but there is no mention of a pre-built, vetted library of standard legal documents (NDAs, agreements, policies) that a founder could use in place of counsel. Docusign's template features are about reusing your own document setup, not sourcing vetted legal content.

   • [claimed-docs] “Save hours of manual setup with reusable templates”
   • [claimed-docs] “Standardize agreements by sharing templates with your team”
   • [claimed-docs] “Reduce prep time by standardizing your most-used agreements.”

   proof ↗⚑ flag