Your agent needs to send contracts for signature. It has to create a document from a template, watch for the counterparty to sign, chase the ones who go quiet, and file the completed PDF somewhere.
SignWell publishes an official MCP server and a REST API that has been in production for years. Both paths reach the same platform. They diverge sharply on what your agent can actually do, on where the credential lives, and on whether a background job can run at all. Here is how to pick.
Most comparisons in this series contrast an OAuth-based MCP server against an API with several auth options. SignWell inverts that. The two paths differ on capability and transport, not on credential type, and that changes which questions matter.
The SignWell MCP server is first-party, MIT licensed, and published to npm as @signwell/mcp. SignWell links it from its own developer resources alongside the CLI and the language SDKs, so this is not a community port.
It runs as a local process over stdio. You install it with npx @signwell/mcp setup, or in Claude Code with claude mcp add signwell -- npx @signwell/mcp. There is also a one-click listing in the Anthropic Connectors directory, which installs a desktop extension that runs the same local process. There is no hosted URL to point a server-side agent at.
Auth is a single SIGNWELL_API_KEY environment variable. The setup wizard writes it to a per-platform env file with 0600 permissions and patches your MCP client configs in place.
The SignWell REST API is versioned at v1 and rooted at a single base path. Its published OpenAPI document defines 26 operations across seven resource groups: Document, Template, Bulk Send, Webhooks, API Application, Me, and Regional.
Authentication is one scheme. You send X-Api-Key as a request header. The OpenAPI securitySchemes block declares exactly one entry, of type apiKey, and there is no authorization endpoint, no token endpoint, and no scope model anywhere in the contract.
Official SDKs exist for Ruby, Node, Python, and PHP, plus a CLI. API access requires a paid SignWell plan.
With GitHub or Salesforce, choosing MCP over the API changes your credential type and therefore your entire token lifecycle design. With SignWell it does not. Both paths use the same static key.
That sounds like a simplification. For a single-user desktop assistant it is. For a multi-tenant B2B agent it is the harder problem, and the rest of this article works through why.
The gap between the two paths is not subtle, and it is not evenly distributed. The MCP server covers the interactive drafting loop well and covers the automation surface not at all.
Tool names below are from the shipped @signwell/mcp v0.3.2 bundle. Endpoint coverage is from SignWell's published OpenAPI document.
The missing pieces are not obscure. Webhooks are how an agent learns that a document was signed without polling, and the MCP server cannot register one. Bulk send is how you issue 500 contractor agreements from a CSV, and it is absent entirely.
Deletion is missing too, which matters more than it sounds. SignWell's delete endpoint also cancels signing in progress, so an agent running purely on MCP has no way to retract a signature request it sent by mistake.
Recipient correction is missing as well. If your agent sends an offer letter to a stale email address, the REST API lets you patch the recipient before they start signing. The MCP server offers no path back.
The gap runs both ways, and this is where the MCP server earns its place. Two of its 14 tools have no REST equivalent because they solve problems that only exist when a language model is driving.
file_store accepts a file the user attached in their client, holds the bytes in memory with a 60-minute TTL, and returns a token the document tools can reference. When a client supplies a resource_uri instead, the server calls resources/read itself and forwards the bytes. That plumbing is genuinely useful and you would otherwise write it.
file_validate_text_tags parses a PDF and checks the {{signature:1:y}} style tags before you create anything. Catching a malformed tag before a contract goes out is worth a tool call.
SignWell's MCP documentation leans on a safety promise: nothing is emailed until you confirm. The repository README states that document_create and template_create_document both always set draft: true.
In the shipped v0.3.2 bundle, only the first is true. document_create overrides the payload with draft: true unconditionally. template_create_document declares draft with a default of false, and its own tool description instructs the model to send immediately unless the user explicitly asks for a draft.
For a human in a chat window that is a reasonable default. For an autonomous agent it means the template path can dispatch a legally binding signature request with no human gate. If you build on the MCP server, pass draft: true explicitly and treat sending as a separate, guarded step.
Neither path offers a choice of credential. Understanding what that single credential is, and what it is not, decides whether your architecture survives a second customer.
The SignWell API key is account-wide. It is not scoped to a user, not scoped to a workspace, and it does not expire on a schedule. The /me endpoint returns the account, workspace, plan tier, and the full list of active users behind that key.
There is no refresh flow because there is nothing to refresh. There is no consent screen because there is no delegation. A key either works or has been revoked. This is exactly the kind of static credential pattern that breaks in production AI systems as soon as you add a second tenant.
Consider a contract agent serving 30 customer organizations. Each has its own SignWell account and its own key. Your agent holds 30 static, long-lived, account-wide secrets.
Scope is the first problem. Every call made with a customer's key acts as that account, with whatever the account can do. There is no mechanism to say this agent run may only read documents, or may only act for one user inside that org. What the key can do, the agent can do.
Revocation is the second. Rotating a key invalidates it for everything using it, including the customer's other integrations. There is no per-agent credential to kill.
Because the MCP server is stdio-only, the credential has to sit on whatever machine runs the process. For a developer using Claude Code that is a laptop. For a hosted multi-tenant agent it means either one container per tenant with that tenant's key injected, or a shared process that can only ever hold one key.
Neither is a per-user isolation model. The MCP path was not designed to be one. Understanding credential ownership across agent tool-calling patterns helps clarify why the transport model matters as much as the auth model.
Both paths leave you holding real operational work. The specific work differs, and the rate limits catch teams off guard on either one.
SignWell documents three limits per token: 100 requests per 60 seconds for most calls, 30 per minute for calls that create documents or templates, and 20 per minute in test mode.
The creation limit is the binding one for agents. Thirty documents per minute is comfortable for an interactive assistant and tight for a batch job, which is exactly the case bulk send exists to handle, and exactly the case the MCP server cannot reach.
Agentic workflows also multiply calls per user action. Creating from a template, polling status, and fetching the PDF is three calls for one contract. Budget accordingly and handle 429 explicitly.
The REST API is explicitly versioned. SignWell commits to v1 behaving consistently and bumping the path for breaking changes, and it publishes an OpenAPI document you can generate clients from and diff between releases.
The MCP server carries no such contract. Tool names, input schemas, and defaults move with npm releases; the draft behavior described earlier is a live example of documentation and shipped code disagreeing within one version.
There is a subtler point on document_list and template_list. Both call list endpoints that do not appear in the published OpenAPI document, so they carry no versioning or deprecation commitment even though they work today.
On the MCP path the key sits in a plaintext env file on the host, at a per-platform path with 0600 permissions. That is a reasonable local-developer posture and not an acceptable one for a system holding 30 customers' keys.
On the direct API path the key lives wherever you put it, which usually means an environment variable, a secrets manager, or a database column someone meant to encrypt later.
Neither path gives you a vault, an audit trail, or per-tenant isolation. That is infrastructure you build or adopt. The patterns that emerge here map closely to what the tool calling agent auth production problems and anti-patterns article covers in depth.
The split here is cleaner than in most tools in this series, because the MCP server's scope is narrow and deliberate rather than incomplete.
The comparison above is a capability argument. Underneath it sits a problem the choice of path does not touch, and it is more acute for SignWell than for tools with an OAuth story.
Both paths hand your agent a static API key. Neither stores it, isolates it per tenant, keeps it out of the agent runtime, or tells you which agent used it for what.
An OAuth-based connector at least produces a token bound to one user, with scopes and an expiry that limit the blast radius of a leak. SignWell gives you a long-lived credential with full account authority and no scope model, so the isolation has to come from somewhere else entirely.
For an agent that sends legally binding documents, the audit question is not optional. When a contract goes out to the wrong counterparty, you need to answer which user authorized the run and which tool call sent it. The audit trails for agent auth in B2B SaaS problem is not solved by either native path.
The Scalekit SignWell connector treats the API key as a connected account rather than an environment variable. You register the connection once per environment, then attach each customer's key to an identifier in your system.
Credentials never touch the agent runtime. Your code passes an identifier and a tool name; Scalekit injects the right key server-side and returns the result. The connector marketing page covers the capability surface, and the connector ships all 26 REST operations as prebuilt tools with schemas written for models rather than API documentation repurposed for agents.
The flow is the same on either language: attach the credential to a user, retrieve the tools that user is authorized to call, then execute. Discovery comes before execution for a reason worth stating explicitly.
A connected account links one of your user identifiers to one SignWell key. In production you create these programmatically as customers onboard; for testing you can add them from the dashboard under the connection's Connected Accounts tab.
SignWell is an API-key connector, so the credential is attached as static auth rather than an OAuth grant.
The connection_name must match the connection name shown in the Scalekit dashboard. The identifier is any stable string for the user, and you reuse the same value on every later call.
Before the agent runs, you load the tools this specific user's connected account is authorized to call. This is not a flat catalog of everything SignWell can do; it is the surface that this identity has credentials for.
That distinction is the whole point of the connected-account model. A user who has not connected SignWell gets nothing back, and the agent never sees a tool it cannot successfully call.
The LangChain adapter wraps the same scoped surface as StructuredTool objects. Filtering by tool_names narrows 26 tools to the four this agent actually needs, which is both an accuracy decision and a token decision. For a deeper look at how LangChain tool calling works and where it stops, the pattern here extends naturally into that architecture.
When the flow is a deterministic pipeline rather than a reasoning loop, skip the framework and call execute_tool yourself. A nightly job that chases unsigned contracts does not need a model in the middle.
The Node SDK mirrors the Python surface with camelCase naming. This example uses the Anthropic SDK directly so the agent loop is visible rather than hidden behind a framework abstraction.
The loop constructs the message list, passes the scoped tools, checks stop_reason, executes the requested tool through Scalekit, appends the result, and calls again until the model stops requesting tools.
Nothing in that loop touches a SignWell key. The agent process holds an identifier and a tool name, and the credential stays in the vault.
If you want an MCP endpoint rather than direct tool calls, Scalekit's Virtual MCP servers give you one without the constraints of a local stdio process. The problem they solve is sharper for e-signature agents than for most connectors.
Hand an agent the full SignWell connector and it sees 26 tools, including delete document, delete template, and delete API application. A reminder agent needs three of them.
Tool bloat is an accuracy problem and a cost problem at once. Twenty-six tools at roughly 200 tokens each is over 5,000 tokens of context before the agent does any work, and a model choosing from a 26-way decision space picks wrong more often than one choosing from three. The fix is not better prompting. It is surface reduction.
Blast radius is the sharper version of the same point. A destructive tool the agent can never see is a destructive tool it can never call by mistake. This connects directly to how tool calling auth changes when you move from single-tenant to multi-tenant — the surface you expose to the agent is as important as the credential it holds.
You create the server once, not once per user. The response includes a static mcp_server_url that every user and every session reuses.
The endpoint is static; the identity is not. Before each run you confirm the user's connections are still active, then mint a short-lived token scoped to that user's connected accounts.
One server definition serves every tenant. No credential sharing between users, and no MCP server to deploy, host, or patch. The setup guide covers the full lifecycle including updates and deletion.
Capability and auth get the attention. For an agent that sends contracts, the question that actually comes up in a security review is who authorized a specific signature request, and neither SignWell path answers it.
SignWell logs the API key. Every call from your agent, for every customer, appears as the same account. The signed document's audit trail records the signer, which is what it is for, and says nothing about which agent run dispatched it.
The MCP server logs nothing at all. Its privacy policy is explicit that it collects no telemetry, which is correct for a local developer tool and unhelpful for production accountability.
Because every Scalekit tool call carries an identifier, the log line has an actor. You get attribution on each downstream call: which user authorized it, which agent ran it, which tool executed, and what came back, with failures separated by source and exportable to your SIEM.
That is the difference between knowing a contract was sent and knowing who caused it to be sent. For agents acting on legally binding documents, that distinction is the compliance story. Agent tool observability — knowing whether your agent is actually working and who authorized each action — is the production requirement that neither native path satisfies.
The question that settles it is not capability. It is whether a person is present when the document goes out, and whose credential the agent is holding.
Use the official SignWell MCP server. It is well built for that job, the file handling and text-tag validation are real advantages, and SignWell maintains it. Pass draft: true on the template path and gate the send.
Use the REST API. That covers scheduled runs, multiple customers, webhooks instead of polling against a 100 request per minute budget, bulk send, recipient correction, and cancellation. None of those are coming to a stdio server, and the transport model rules out per-tenant isolation regardless.
An interactive assistant serves the people drafting; a headless pipeline handles everything after the send. The static account-wide API key is the same problem on both paths, and that is the part that needs production-grade infrastructure rather than an environment variable.
Start with the SignWell connector docs, or browse all connectors if your agent spans more than one tool. The pricing page covers the free tier, which includes 5,000 tool calls with no credit card.
If you are building a document workflow, these patterns are close neighbours: the offer letter routing agent, the new hire provisioning agent, the deal room sync agent, and the PTO and leave request agent.
Building something with SignWell and want another pair of eyes on the architecture? Talk to an engineer if you need an immediate answer to any agent development question.
