Skip to main content
Glama

signwell_document

SignWell documents sent for signature — create, follow, fetch the signed PDF. SENDING a draft and reminding signers is signwell_act, another tool.

There is NO "list documents" endpoint: keep the id returned by op="create". Reads return a compact view — per recipient ONE signing_link and an explicit emailed, plus notes on what the status hides; full=True returns SignWell's raw payload.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "signwell_document"
  }
}

Input Schema

NameRequiredDescriptionDefault
opNowhich action. · "get" — status and recipients of `document_id`. · "create" — `files` + `recipients`. ⚠️ Creates a DRAFT unless `draft=False` (SignWell's own default sends immediately). Place fields with `fields` or `text_tags=True` (tags written in the file, syntax: `oto_guide op=read slug="signwell-envoi"`). · "update_recipients" — [{id, name, email}] on a sent document. · "update_authentication" — [{id, passcode?, passcode_delivery?}]. · "completed_pdf" — link to the signed PDF (`audit_page`, `file_format`). The link is a bearer URL. · "nom151_certificate" — link to the Mexican NOM-151 certificate. · "delete" — delete `document_id`; cancels signing in progress.get
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
fullNoreturn SignWell's raw payload.
nameNo
draftNoop="create" only; default True here.
filesNo[{name, file_url | file_base64}]. `file_url` must be publicly fetchable — a project file's signed `download_url` (`oto_project_files op="list"`) works, and is itself a bearer URL.
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
fieldsNo
_run_idNoOBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
dry_runNovalidate and preview without writing or sending.
messageNo
optionsNorarer spec settings (copied_contacts, labels, metadata, redirect_url, allow_decline, language, custom_requester_name…); an unknown key is refused.
subjectNo
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
_instanceNoInstance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
remindersNo
test_modeNonon-binding document; invitations go to the ACCOUNT OWNER, never to the recipients.
text_tagsNo
audit_pageNo
expires_inNo
recipientsNo[{id, name, email, …}] — `id` is yours ("1", "2"…) and is the signer number of fields and text tags. Embedded signing only emails a recipient with `send_email: true`.
document_idNo
file_formatNo
embedded_signingNoreturn signing links instead of relying on SignWell's email; anyone holding a link can sign.
apply_signing_orderNo

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations present, the description still discloses real behavior: reads return a compact view with per-recipient `signing_link`, an explicit `emailed` flag, and `notes` explaining what status hides, while `full=True` yields the raw payload. It omits mutation-specific risks carried only in the schema, notably that `delete` cancels signing in progress and that the completed-PDF/certificate links are bearer URLs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short blocks, each front-loaded with the highest-value fact (scope, sibling routing, missing list endpoint, return shape). No filler, and the most consequential constraints come first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-operation, 25-parameter mutation tool with no annotations and no output schema, the description covers return shape and sibling routing well. It is not fully complete — destructive/write semantics, dry_run usage, and the bearer-URL nature of returned links are only in the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

At 56% schema coverage across 25 params, the description only meaningfully annotates `full=True` (already documented in the schema) and reinforces keeping `document_id`. Undocumented parameters such as `name`, `message`, `subject`, `reminders`, `expires_in`, and `apply_signing_order` are left to a bare schema with no description text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb set and resource: documents sent for signature — create, follow, fetch the signed PDF. It also explicitly names the sibling that handles sending/reminders (`signwell_act`), so an agent can tell the two apart without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit routing rule (sending a draft and reminding signers → `signwell_act`) and an important usage constraint: there is no list endpoint, so the `id` from op="create" must be retained. It stops short of covering when to pick the other ops (delete, update_recipients, certificates), though the op enum in the schema does that work.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources