Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Signable MCP server Show me envelopes still awaiting signatures and who hasn't signed yet."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that lets Claude, ChatGPT and other MCP clients work with a Signable e-signature account: envelopes, templates, contacts and users, and (when enabled) sending, reminding, cancelling and expiring envelopes. It is built from Signable's public API documentation and its published OpenAPI spec.
Once it's connected, someone on the account can ask things like:
"Which envelopes are still waiting for a signature, and who hasn't signed?"
"Show me the history of the 17 John Street tenancy contract."
"What does the Tenancy Contract template need before I can send it?"
"Find Sam Evans and list every document we've sent him."
With writes enabled: "Send the Mutual NDA template to Priya Shah at Acme, and remind the John Street signers."
Tool | What it does | API calls |
| Envelopes with status, timestamps and party names. Filters by one status and/or a title keyword, pages by offset. |
|
| One envelope: parties with signing status and role, documents with fields and 24-hour download links, audit history, metadata. |
|
| Templates with their parties and merge fields. |
|
| One template, so an assistant knows the |
|
| Search contacts by part of a name or email. The API has no search parameter, so this pages through the list (50 per call). Emails are hidden by default, but a query that matches an email fragment still confirms such an address exists on the account. |
|
| A contact's document history. The API answers 404 for a contact that exists but has never been sent an envelope (error code 10060); the tool fetches the contact first and turns that case into an empty list. |
|
| Team members with their role (User, Admin, Super-Admin). |
|
| Creates an envelope from one template and queues it for sending, or saves it as a draft. Fetches the template first and refuses locally if a template party has no signer, a signer's |
|
| Emails a reminder to every party that has not signed. Writes only. |
|
| Cancels a sent envelope (signers are emailed). Writes only. |
|
| Expires a sent envelope (no email). Writes only. |
|
Not covered on purpose: companies, usage, webhooks, branding, settings, embed sessions, party updates, and every delete endpoint.
Related MCP server: DocuSign MCP Server (patched)
Requires Node 18 or later.
npm install
npm run buildYou need an API key for your Signable account. The API authenticates with HTTP Basic: the key is the username; the password can be anything, Signable recommends x, and that is what this server sends.
Claude Desktop: add this to claude_desktop_config.json:
{
"mcpServers": {
"signable": {
"command": "node",
"args": ["/absolute/path/to/signable-mcp/dist/index.js"],
"env": { "SIGNABLE_API_KEY": "your-key" }
}
}
}Claude Code:
claude mcp add signable -e SIGNABLE_API_KEY=your-key -- node /absolute/path/to/signable-mcp/dist/index.jsVariable | Required | Meaning |
| yes | Your API key, sent as the HTTP Basic username with password |
| no |
|
| no | Defaults to |
Read-only unless SIGNABLE_ALLOW_WRITES=true. Read tools carry the MCP readOnlyHint annotation; cancel_envelope and expire_envelope are marked destructive.
Email addresses of signers, contacts and users, the last four digits of signers' mobile numbers, envelope passwords, the IP addresses and user agents in the audit history, and the download link of a file a signer uploaded into an upload field (the spec's example is a passport copy) are only returned when the assistant explicitly asks (include_contact_details). In free text (history lines, field values, field and merge-field labels, envelope and document titles, envelope metadata, redirect URLs, and signer, contact and user names) email addresses are replaced with [email redacted] and phone-number-like sequences with [phone redacted] by default. The phone match is a heuristic: it covers international numbers written with + or 00 (including the +44 (0)7700 … form), UK numbers written with a bracketed area code such as (020) 7946 0958, and UK-style 0… numbers of 9 to 11 digits with spaces, dots or hyphens between groups. Other digit strings that happen to start with 0 (an order number, say) are redacted too, while hex fingerprints, numeric IDs, timestamps and hyphenated references such as PO-0001-000123 are left alone; the raw text is available with include_contact_details. Envelope metadata nested more than 20 levels deep is replaced by a placeholder rather than returned unredacted. Template titles, template party labels and merge-field labels are always redacted (the template tools have no include_contact_details switch); names are always returned, minus any email or phone typed into them. The same redaction is applied to Signable's own error messages before they are passed on.
Document download links (pdf_url, signed_pdf_url and the envelope's signed PDF) are returned by default: the spec documents them as direct links that give access to the whole document for 24 hours after generation. They are passed through as stored so they keep working; the redaction is not applied to them.
IDs are checked before any call is made: contact IDs must be numeric (the spec types them as integers); fingerprints and party/field IDs must be short strings of letters, digits, _ and - (up to 64 characters, no slashes or spaces), because the spec does not document their format (all but one fingerprint example are 32 lowercase hex characters, one is 33; every party and field ID example is a number).
send_envelope_from_template compares the request with the template before posting anything. Its auto_expire_hours and auto_remind_hours have a minimum of 12: the spec documents that minimum for direct-document sends only, and it is assumed here for template sends.
Signable does not document a rate limit. Requests are spaced 250 ms apart (about four per second). A 429 is retried at most twice for any method, including POST /envelopes, on the assumption that a rate-limited request was not processed (see Status). The retry waits for Retry-After (whole or fractional seconds, or an HTTP-date; 2 s then 4 s when the header is absent or unreadable). Each wait is capped at 10 seconds so a tool call stays under the MCP client's default 60-second request timeout: if Signable asks for a longer wait the call gives up at once and the message says how long to wait.
502, 503 and 504 are retried the same way for GET only; when all three attempts fail the error says the service may be unavailable and to try again in a few minutes, without the gateway's HTML. A POST /envelopes or a PUT …/remind|cancel|expire is never retried after a gateway error, because the request may already have been processed and a retry could send an envelope or a reminder twice; the error tells the assistant to check with list_envelopes or get_envelope before repeating it.
A 200 whose body is not JSON (a proxy or a login page in the way) is reported as an error naming SIGNABLE_BASE_URL, never as an empty list or an empty envelope.
A rejected API key produces a message that says which variable to fix; a 400 from the API (for example cancelling an envelope that is not sent) is passed on with Signable's own message and error code.
npm testThe test suite:
Validates every fixture record against the component schemas in Signable's published OpenAPI spec (EnvelopeSignedSummary, EnvelopeDetailResponse, TemplateSummary, Contact, ContactEnvelopeSummary, User). The spec is downloaded from developers.signable.app/_bundle/openapi.yaml to spec.yaml on the first run.
Starts a local mock of the API under /v1 that serves those fixtures with the documented offset/limit pagination, returns Basic-auth 401s, 404s (including the spec's two contact cases: unknown contact, code 10053, and contact with no envelopes, code 10060) and 400s in the documented error shapes (the POST /envelopes 400 uses the spec's example code 10250), and answers the first GET /templates with a 429. The mock's list, detail, action and error responses are validated against the spec's response schemas, and the documented keys of each list and get response are asserted explicitly (see the note below).
Starts the built server and drives it over stdio with the official MCP client: 29 checks covering every tool, tool annotations, offset pagination stopping at the documented total and continuing across pages that come back shorter than requested, the envelope_status and q filters, redaction of emails and phone numbers by default (parties, contacts, users, history, fields and merge-field labels, template titles and party labels, metadata including a 24-level nested value, redirect URL, names; the +44 (0)…, bracketed, 00-prefixed, extra-spaced and dot-separated phone forms), the upload-field link withheld by default, and their return on request, the 429 retry waiting for Retry-After in the seconds, fractional-seconds and HTTP-date forms, giving up after three attempts on a persistent 429 and at once on a Retry-After above the cap, a 429 on POST /envelopes retried once, a 502 retried for GET and never for POST /envelopes or a PUT action, a GET failing three times with 503 reported with advice and without the gateway HTML, a 200 with a non-JSON body reported as an error, the write gate with the variable unset and set to false, the POST /envelopes body validated against the spec's "Send Template Request" schema, the local refusal of mismatched parties and fields and of a copy recipient with a mobile number, the three PUT actions, the empty-list handling of the contact-with-no-envelopes 404 only on the first page at offset 0, ID validation before any call, the 401 and 404 messages, and that every request used Basic base64(key:x) and a documented method and path.
Note that the spec marks no fields as required on TemplateSummary, Contact, ContactEnvelopeSummary, User, TemplateGetResponse, ContactGetResponse, TemplatesListResponse, ContactsListResponse, ContactEnvelopesListResponse and UsersListResponse, so schema validation of those only proves the types of fields that are present. Step 2 therefore also asserts that the documented keys are present in the mock's list and get responses; the fixture records themselves are only type-checked.
This is a working prototype. It has not yet been run against the live API, because it was built without a Signable account. Everything below is taken from the published spec and should be confirmed on a real account:
The format of envelope and template fingerprints and of party and field IDs. The spec types them as strings; the validation here is deliberately loose.
The sort order of GET /envelopes. The spec does not document one; its example lists newest first, and the server returns whatever order the API uses.
GET /envelopes/{fingerprint} on a draft or processing envelope, and whether envelope_history and document_fields are present for every status.
GET /contacts/{id}/envelopes for a contact with no envelopes. The spec documents a 404 with code 10060 and the message "This contact hasn't been sent any envelopes.", but the example's summary says "Unknown or wrong-account contact", so the server fetches the contact first and only treats the 404 as "no envelopes" when that succeeded and the request was for the first page at offset 0. What the API answers for an offset past the end of a list is not documented; the mock answers 200 with an empty list, and a 404 at a non-zero offset is passed on as an error rather than read as "no envelopes".
The wording of Signable's error messages and whether any of them echo request data such as a party's email address; the texts here are the spec's examples, and the server redacts contact details from them regardless.
Whether the 12-hour minimum on envelope_auto_expire_hours and envelope_auto_remind_hours applies to template sends; the spec documents it only for direct-document sends.
The end of pagination. The server stops at an empty page or when offset + returned reaches the documented total_* string; when no total is present a short page is taken as the end. A short page on its own is not, because LimitParam says a request for more than 50 gets 10 back: the next page is then requested from offset + returned. ContactsListResponse also documents a next URL, which is honoured when present. The list responses' limit field is ambiguous in the spec (the schema describes it as the number of items returned, the examples echo the requested limit) and the server ignores it.
A 429 on POST /envelopes is retried on the assumption that a rate-limited request was not processed. The spec documents no 429 at all; confirm on a live account that Signable never creates the envelope before answering 429.
The POST /envelopes body for a template send, in particular what party_id a copy recipient should carry (the spec marks party_id as required for every party, copy recipients included, without saying which ID a copy recipient should use) and whether document_title may differ from the template title.
Whether PUT .../remind, .../cancel and .../expire accept an empty body, as documented (no request body is defined for them).
The wording of the 400 returned when reminding, cancelling or expiring an envelope that is not sent; the messages here are the spec's examples.
role_id to role-name mapping (1 User, 2 Admin, 3 Super-Admin) comes from the spec's user-creation schema.
How many requests per second the API tolerates; the spec says nothing, so the throttle here is a guess on the polite side.
find_contacts pages through the contact list because GET /contacts has only offset and limit parameters. On large accounts, a search parameter on that endpoint would make this much cheaper.
This version runs locally over stdio, with the account holder's own API key. For customers to connect from claude.ai or ChatGPT without handling keys, the next step is a remote server (Streamable HTTP) behind OAuth, hosted by Signable, and then a listing in the Claude and ChatGPT connector directories.
MIT. Built by Alexandru Dragoș (alexandru.dragos96@gmail.com) with an AI agent (Claude) working under his direction.
Search contacts (signers and recipients) by part of their name or email. The API has no server-side search, so this pages through the contact list (50 per call) up to max_pages. Emails are only returned with include_contact_details; note that a match on an email fragment still confirms that such an address exists on the account.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Name or email fragment | |
| max_pages | No | Pages of 50 contacts to scan | |
| max_results | No | ||
| include_contact_details | No | Include contact email addresses |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the API has no server-side search and that the tool pages through the contact list (50 per call) up to max_pages. It also warns that email matches only confirm address existence when include_contact_details is true. This adds meaningful behavioral context beyond the readOnlyHint and openWorldHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it states the purpose in the first sentence, then adds behavioral caveats in the second. Every sentence adds value, and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with no output schema, the description covers the key behaviors: pagination, email visibility, and match semantics. The only missing piece is what the return format looks like, but the description's caveats are sufficient for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, and the description adds important semantics for query (name or email fragment), max_pages (pages of 50), and include_contact_details (emails only returned with it). The max_results parameter lacks a description in the schema and is not explained in the description, which is a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches contacts (signers and recipients) by name or email fragment, distinguishing it from sibling tools like list_envelopes or list_users. The verb 'Search' plus the resource 'contacts' and the matching criteria make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the pagination behavior and the max_pages parameter, and notes the include_contact_details requirement for emails. It doesn't explicitly name alternative tools for contact-related operations, but the context signals show siblings are mostly envelope/template/user tools, so the usage context is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A contact's document history: every envelope they are a recipient of, with status, timestamps and signed PDF link where available. A contact that exists but has never been sent an envelope gives an empty list.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | ||
| contact_id | Yes | Contact ID (numeric) | |
| max_results | No | ||
| include_contact_details | No | Include the contact's email address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint, so the description doesn't need to restate those. It adds value by specifying the output content (status, timestamps, PDF link 'where available') and the empty-list behavior for contacts never sent an envelope. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the resource and output, then add a useful edge case. No fluff or repetition; every sentence earns its place. The description is well-structured and quickly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with no output schema, the description conveys the essential return structure (list of envelopes with fields) and handles the empty-list scenario. It doesn't mention pagination, but that is standard and covered by parameters. The description is sufficiently complete for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%: contact_id and include_contact_details have descriptions, but offset and max_results do not. The tool description does not mention any parameters, leaving offset and max_results unexplained. Since coverage is moderate, the description should compensate for the undocumented parameters but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a contact's document history (envelopes they are a recipient of) with specific fields: status, timestamps, and signed PDF link where available. It distinguishes from siblings like list_envelopes (general list) and get_envelope (single envelope) by focusing on per-contact history. The edge case of an empty list for a contact with no envelopes adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a specific contact's history, making it clear when to use this tool versus a general list. However, it does not explicitly name alternatives or state when not to use it (e.g., for all envelopes use list_envelopes). The context is strong enough that an agent can infer the intended use, but explicit sibling routing is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full detail for one envelope: each party with its signing status and role, the documents with their fields and download links (valid 24 hours), the audit history and any metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| envelope_fingerprint | Yes | Envelope fingerprint | |
| include_contact_details | No | Include party email addresses, mobile digits, passwords, and IP addresses and user agents in the history |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds useful behavior such as download links being valid for only 24 hours. It also discloses the scope of the returned data without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that packs the key result fields and link expiration into a compact form. There is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides a thorough inventory of what the response contains, including link validity. It could mention the sensitive nature of include_contact_details, but that is already documented in the schema and is an enhancement rather than a required gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both envelope_fingerprint and include_contact_details. The description does not add extra parameter-level guidance, which is acceptable baseline because the schema carries the full parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Full detail for one envelope'. It enumerates exactly what is returned (parties, roles, signing status, documents, fields, download links, audit history, metadata), which clearly distinguishes it from sibling tools like list_envelopes or get_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for one envelope' clearly frames this as the single-envelope detail lookup, in contrast to list_envelopes. However, it does not explicitly name alternatives or state exclusions, so the guidance is clear context but not fully explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One template with its parties (party_id, name) and the merge fields (field_id, label) each party can have pre-filled. Use this before send_envelope_from_template.
| Name | Required | Description | Default |
|---|---|---|---|
| template_fingerprint | Yes | Template fingerprint |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=true and openWorldHint=true, so the safety profile is covered without needing repetition. The description adds useful response-content context but doesn't disclose other behavioral details such as error behavior, empty results, or output wrapping. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first gives the result shape, the second gives usage. No filler, and the most important scoping information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool with annotations and no output schema, the description covers what is returned and when to use it. An agent has enough to select and call the tool correctly without missing critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter template_fingerprint is fully documented in the schema with type, pattern, and description, giving 100% schema description coverage. The description references the template conceptually but adds no parameter-level meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool returns a single template and itemizes its payload: parties with party_id/name and merge fields with field_id/label. 'One template' plus the title conveys retrieval, and the detail level distinguishes it from list_templates, though it never uses an explicit verb like 'gets' or 'retrieves'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete placement in a workflow: 'Use this before send_envelope_from_template.' This tells an agent when to call it. It doesn't explicitly contrast it with siblings like list_templates or state when not to use it, so it stops short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List envelopes on this Signable account in the order the API returns them (the spec does not document the sort order; its example lists newest first), with status, timestamps and the parties' names. Filter by one status and/or a keyword in the title.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Case-insensitive keyword filter on the envelope title (partial words match) | |
| offset | No | Index of the first envelope to return (for continuing a previous call) | |
| status | No | Only envelopes with this status | |
| max_results | No | Maximum number of envelopes to return | |
| include_contact_details | No | Include the last four digits of signers' mobile numbers and envelope passwords, and stop redacting email addresses and phone numbers from envelope titles, party names and the redirect URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description's main behavioral contribution is the honest caveat that the API does not document sort order and its example lists newest first. It also discloses what fields are included in results. This adds useful context beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler, and the key action and scope are front-loaded. The sort-order parenthetical is slightly convoluted but earns its place because it prevents an incorrect assumption about ordering.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with fully documented parameters, the description covers the main return fields, filter behavior, and ordering caveat. No output schema exists, so it could enumerate more fields, but an agent has enough to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented. The description adds only the combined filter logic ('one status and/or a keyword in the title'), which is mildly useful but not a significant extension over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('List envelopes on this Signable account') and adds the returned fields (status, timestamps, parties' names). This clearly distinguishes it from single-envelope or template/contact siblings, even though it does not name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this is an account-level envelope listing with optional filtering by status and/or title keyword. It does not explicitly state when to prefer get_contact_envelopes or get_envelope, but the scope and filters imply the intended use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Templates on this account with their parties and merge fields, so you know what a send from each template needs.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Index of the first template to return | |
| max_results | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and open-world behavior, so the description only needs to add context beyond that. It adds useful output content (parties and merge fields), but it does not mention pagination behavior, how results are ordered, or what openWorldHint might mean for completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact sentence that conveys scope, response contents, and purpose with no unnecessary words. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with optional pagination parameters and no output schema, the description gives enough context: what is returned and why it matters. Explicit pagination details are absent, but the schema's offset and max_results parameters make that gap minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes offset but not max_results, and the description does not explain either parameter. The parameter names and defaults are reasonably self-explanatory, so this is usable, but the description adds no parameter-level meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies that this tool lists templates on the account and what they contain: parties and merge fields. It also gives the practical purpose of knowing what a send from each template requires. It does not explicitly distinguish itself from get_template or other siblings, but the plural 'templates' and account scope make the resource type clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'so you know what a send from each template needs' gives a concrete context for when to call this tool. There is no explicit guidance about when not to use it or which sibling to choose instead, though the use case is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Team members on this Signable account with their role (User, Admin or Super-Admin). Emails are only returned with include_contact_details.
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | ||
| include_contact_details | No | Include user email addresses |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds a useful behavioral condition: emails are returned only when include_contact_details is set. It does not describe pagination or result composition, so it adds some but not rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences put the primary purpose first and contain no filler. The conditional email behavior is efficiently stated in the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition is adequate for a simple read-only list call with two optional parameters, and annotations cover the read-only/open-world behavior. However, there is no output schema and the description does not clarify the return shape beyond role/email condition, nor the intended meaning of max_results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one of two parameters has a schema description (include_contact_details), and the tool description mainly restates that parameter's effect ('emails are only returned with include_contact_details'). max_results is left with no semantic explanation in either schema or description, so the low coverage is not fully compensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description identifies the resource (team members on the Signable account) and the role categories returned, which distinguishes it from sibling tools for contacts, envelopes, and templates. It lacks an explicit verb like 'Lists', but the title and content make the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over find_contacts, list_envelopes, or list_templates, and no exclusions or alternatives are named. The description implies it is for account users, but leaves the comparison to sibling tools implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0find_contactsget_contact_envelopesget_envelopeget_templatelist_envelopeslist_templateslist_usersScored across 7 tools
Each tool targets a distinct resource and scope: contacts, contact envelope history, account envelopes, envelope details, template lists, template details, and users. There is no meaningful overlap that would cause an agent to select the wrong tool.
The naming mostly follows a predictable list_/get_ pattern, with list_ for collections and get_ for single items. The only minor deviation is find_contacts instead of list_contacts, but the convention is otherwise clear and consistent.
Seven tools is well-scoped for a Signable server focused on searching and retrieving account data. Each tool covers a meaningful part of the domain without unnecessary redundancy.
The server covers listing and retrieving contacts, envelopes, templates, and users, but entirely lacks write/send operations. This is especially notable since get_template mentions using it before send_envelope_from_template, yet no send tool exists, leaving a clear workflow dead-end.
E-signature API for AI agents: send contracts, sign PDF documents, track and download signed files.
Send documents for e-signature, track signing status, and download signed PDFs. No API key required.
Create signing requests, check status, send reminders, and manage Aoexl templates.
Automate eSignature workflows and signing tasks via natural language commands.
