Skip to main content
Glama
g-digital-by-Garrigues

EAD Factory MCP Server

Official
by g-digital-by-Garrigues
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

signature_request_full

Creates a signature request, adds one or more documents (each with its own signatories), and activates it — the full flagship signature flow in one call instead of create_signature_request + N x (add_document_to_signature_request +…

Instructions

Creates a signature request, adds one or more documents (each with its own signatories), and activates it — the full flagship signature flow in one call instead of create_signature_request + N x (add_document_to_signature_request + add_signatory_to_document) + activate_signature_request. Each document's file uses the shared FileInput contract (local path, base64, https URL, or n8n binary item) — never a bespoke file field. Set activate: false to leave the request in draft so you can add validators/observers (add_validator_to_signatory, add_observer_to_document) before activating it yourself. On success returns the request id, each document's id, and each signatory's id. Use the atomic tools instead when you need to inspect or react to each intermediate step, or need validators/observers before activation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesMANDATORY. Signature request name.
activateNoActivate the request immediately after adding all documents/signatories.
createdByYesMANDATORY. Identifier of the requester.
documentsYesOne or more documents, each with its own signatories, added to the request.
descriptionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.4.0
    • changedInput schema / properties / documents / items / properties / signatories / items / properties / email / pattern
      Previous value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"
  2. First observedv1.3.1

TDQS

A4.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and largely delivers: it discloses activation behavior, the draft-mode path via activate: false, follow-up validator/observer tools, and the returned IDs on success. It could mention side effects of activation (e.g., notifications to signatories), but the disclosed behavior is solid for a complex write operation.

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?

The description is dense but well-organized: a front-loaded summary of the composite flow, then targeted guidance on the file contract, activate behavior, return values, and when to choose alternatives. Every sentence carries distinctive information; no filler or repetition of schema fields.

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

Completeness5/5

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

For a complex composite tool with no output schema, the description covers invocation shape, file input variants, draft behavior, follow-up pathways, alternatives, and return values. This is sufficient for an agent to select and call the tool correctly without external documentation.

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

Parameters4/5

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

Schema coverage is 80%, so the baseline is 3. The description adds real value on top: it explains the shared FileInput contract (local path, base64, https URL, or n8n binary item), clarifies the activate flag's drafting behavior, and calls out that coordinates mirror signature_coordinate_set to avoid follow-up calls. These are meaningful clarifications beyond the bare schema.

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?

The description opens with a specific verb-resource pair: 'Creates a signature request, adds one or more documents, and activates it.' It names the exact composite flow and contrasts it with atomic siblings, making the tool's unique role unmistakable among similar signature tools.

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

Usage Guidelines5/5

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

Explicitly states when to use this tool versus the atomic alternative: use it as the full flagship flow, and use atomic tools when you need to inspect or react to each intermediate step or need validators/observers before activation. It also names sibling tools for those follow-ups, leaving no ambiguity.

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

Deploy Server

Other Tools