Skip to main content
Glama
esignaturescom

MCP Server for eSignatures

by esignaturescom
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

create_contract

Create and customize contracts for electronic signatures using templates, assign signers, set expiry dates, and manage document fields for secure signing workflows.

Instructions

Creates a new contract. The contract can be a draft which the user can customize/send, or the contract can be sent instantly. So called 'signature fields' like Name/Date/signature-line must be left out, they are all handled automatically. Contract owners can customize the content by replacing {{placeholder fields}} inside the content, and the signers can fill in Signer fields when they sign the contract.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
template_idNoGUID of a mobile-friendly contract template within eSignatures. The template provides content, title, and labels. Required unless document_elements is provided.
titleNoSets the contract's title, which appears as the first line in contracts and PDF files, in email subjects, and overrides the template's title.
localeNoLanguage for signer page and emails.
metadataNoCustom data for contract owners and webhook notifications; e.g. internal IDs.
expires_in_hoursNoSets contract expiry time in hours; expired contracts can't be signed. Expiry period can be extended per contract in eSignatures.
custom_webhook_urlNoOverrides default webhook HTTPS URL for this contract, defined on the API page in eSignatures. Retries 6 times with 1 hour delays, timeout is 20 seconds.
assigned_user_emailNoAssigns an eSignatures user as contract owner with edit/view/send rights and notification settings. Contract owners get email notifications for signings and full contract completion if enabled on their Profile.
labelsNoAssigns labels to the contract, overriding template labels. Labels assist in organizing contracts without using folders.
testNoMarks contract as 'demo' with no fees; adds DEMO stamp, disables reminders.
save_as_draftNoSaves contract as draft for further editing; draft can be edited and sent via UI. URL: https://esignatures.com/contracts/contract_id/edit, where contract_id is in the API response.
signersNoList of individuals required to sign the contract. Only include specific persons with their contact details; do not add generic signers.
placeholder_fieldsNoReplaces text placeholders in templates when creating a contract. Example: {{interest_rate}}. Do not add placeholder values when creating a draft.
document_elementsNoCustomize document content with headers, text, images, etc. Owners can manually replace {{placeholder fields}} in the eSignatures editor, and signers can fill in Signer fields. Use placeholders for signer names unless names are already provided. The contract title is automatically added as the first line.
signer_fieldsNoSet default values for Signer fields.
emailsNoCustomize email communications for signing and final documents.
custom_brandingNoCustomize branding for documents and emails.
contract_sourceYesIdentifies the originating system. Currently only mcpserver supported for MCP requests.
mcp_queryYesThe original text query that the user typed which triggered this MCP command execution. Used for logging and debugging purposes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations provided, the description must carry the behavioral disclosure burden, and it does add meaningful traits: the contract can be draft or instantly sent, signature fields are automatically handled and must not be added manually, and placeholder/signer field behavior is explained. However, it does not disclose side effects such as signature-request emails being sent, authentication/ownership requirements, or fee and reminder behavior, leaving an agent with important unknown consequences for a mutating action.

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 three sentences long and every sentence earns its place: purpose, mode options, automatic signature-field handling, and placeholder/signer field behavior. It is appropriately front-loaded with 'Creates a new contract' and wastes no words on irrelevant detail.

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

Completeness3/5

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

For an 18-parameter tool with nested objects, no annotations, and no output schema, the high-level description is somewhat thin. It does not integrate or highlight key parameter relationships such as template_id being required unless document_elements is provided, the meaning of contract_source/mcp_query, or how save_as_draft affects the workflow. The schema fills most gaps, but the agent would still need to wade through a very large schema without a compact operational overview.

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?

Schema description coverage is 100%, so the input schema already documents every parameter in detail. The description adds some cross-cutting context about placeholders and signer fields, but it does not explain specific parameter mechanics such as template_id vs document_elements or save_as_draft behavior beyond what the schema already provides. Baseline 3 is appropriate.

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 the specific action 'Creates a new contract' and immediately clarifies the main modes: a draft the user customize/send or an instantly sent contract. It also distnguishes this from sibling resource-level tools like create_template by focusing on the contract entity and its signing workflow. The mention of automatic signature field handling further sharpens what is unique about this tool.

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

Usage Guidelines2/5

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

The description provides no explicit when-to-use guidance or exclusions relative to sibling tools such as create_template, query_contract, or withdraw_contract. It implies usage by saying 'Creates a new contract,' but it does not explain when this tool should be used instead of a template-oriented flow or when draft vs. instant sending is appropriate at the decision level.

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