Skip to main content
Glama

Create document from template

create-document-from-template
Destructive

Create a new document from a template, optionally pre-filling parties, signatories, and dynamic fields, and optionally starting the signing process immediately.

Use this tool when:

  • The user wants to generate a document based on an existing template

It is usually helpful to call get-template-info with include=["parties", "signatories", "dynamic_fields"] first to discover the template's parties, signatories, and dynamic fields so that the parties, signatories, and dynamic_field_values arguments can be populated correctly.

When completing dynamic fields, take note of the field's type when constructing the value. These are the rules to use when constructing the value string:

  • number: the numeric value in a string, using '.' as the decimal separator -> "1234.56"

  • currency: concatenate the ISO currency code and the numeric value with a ';' -> "EUR;1000.10" (for one thousand Euro and ten cents)

  • currency_duration: same as currency, but append another ';' followed by either monthly or yearly -> "EUR;1000.10;monthly" / "USD;1000.10;yearly"

  • select: one of the options from the field's select_values list -> "red"

  • multi_select: an array of the selected values in the values field -> ["red", "blue"]

  • bool: either of the strings "true" (displayed to the user as "Yes") or "false" (displayed to the user as "No") -> "true" / "false"

  • duration: a PHP-compatible duration specification -> "P6D" (6 days), "P2W" (2 weeks), "PT12H" (12 hours)

  • date: the date in the format "YYYY-MM-DD" -> "2026-12-31"

  • email, text, textarea, or any type not listed above: a string -> "test@example.com"

Setting start_signing=true will move the new document straight into the signing stage and invite the signatories to sign it; this fails if any required information (party data, mandatory dynamic field values, signature blocks) is missing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
partiesNoSpecifics of the parties involved in the document, additional to any information from the template.
signatoriesNoThe specific people who will sign the document
document_nameNoThe name of the new document. If omitted, the name of the template will be used
start_signingNoWhether to immediately start the signing process and invite the signatories to sign the document. This may fail if not all party or signatory data is completed, or mandatory dynamic fields do not have values
template_uuidYesUUID of the template to create the document from. Must be one of the template UUIDs returned by list-templates
dynamic_field_valuesNoValues for the template's dynamic fields. Signing can only start when all mandatory dynamic fields from the template have values provided.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoURL to open the document in fynk
nameNoName of the document
tagsNoThe tags on the document. Tags are the account's own classification labels (e.g. relationship type, commercial significance, region), so they show which categories this account uses and can be filtered on with filter_tags.
uuidNoUnique identifier for the document. Do not show to the user unless they ask for it
stageNoWhat stage the document is in currently
teamsNoThe teams the document is assigned to.
localeNoLocale code, e.g. en-GB, de-AT. Absent when the document has none set. Prefer describing the locale in natural language (e.g. 'British English') rather than showing the raw code.
originNoHow the document was created.
partiesNoThe contracting entities on the document.
conditionsNoThe document's conditions: rules over its dynamic fields deciding whether a passage of the document applies, and whether each currently holds. Use them to explain why a clause is or is not part of the document, and what would have to change to flip it.
created_atNoWhen the document was created.
updated_atNoWhen the document was last updated.
archived_atNoWhen the document was archived. Absent when the document is not archived.
signatoriesNoThe individual people who sign the document. Distinct from parties: a signatory often signs on behalf of a party (e.g. a business), so a person may be a signatory without appearing as a party.
_entity_typeNoOnly relevant for tooling. Do not show to the user
summary_textNoA summary of the document content. Absent when the document has no summary.
document_typeNoIf present, indicates what kind of document this is. Absent when the document has no type assigned
dynamic_fieldsNoThe document's dynamic fields and their values.
signature_typeNoeIDAS assurance level used when signing the document. Absent when none has been chosen.
workflow_stateNoGives an indication of which stage transitions, etc are possible to perform on this document. This object is technical state, not display content: when relaying it to the user, always render it as natural-language prose and never echo raw field names or snake_case values (e.g. say 'signing cannot be started yet because not every signature block has been assigned to a signatory' instead of mentioning 'can_start_signing' or 'signature_block_signatory').
metadata_valuesNoThe document's metadata fields and their values.
signature_blocksNoThe places in the document that are signed. A block is bound either to a single signatory or to a party, in which case every signatory of that party signs it. Every signatory needs a block covering them before signing can be started.
sequential_signingNoWhen true, signatories sign one at a time, in ascending order of their signing_order.
source_template_uuidNoUUID of the template the document was created from. Absent when it was not created from a template.
external_signatory_invitation_messageNoText shown in the email inviting external signatories to sign. Absent when no message is set.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and openWorldHint=true, but the description adds material context beyond them: start_signing=true moves the document into the signing stage and invites signatories, and the call 'fails if any required information (party data, mandatory dynamic field values, signature blocks) is missing.' This is exactly the kind of side-effect and failure-mode disclosure an agent needs before invoking.

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

Conciseness4/5

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

Front-loaded with the purpose, then usage, then the field-value rules, then the start_signing caveat - a sensible ordering with no filler sentences. The type-by-type rule list is long, but it is dense, referenceable content rather than padding, so only mild deduction for overall length.

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 6-parameter mutation tool with a nested-heavy schema, annotations, and an output schema present, the description covers purpose, usage, prerequisite discovery, value encoding, and failure conditions. Return values need not be explained because an output schema exists, and nothing an agent needs to call it correctly is missing.

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

Parameters5/5

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

Schema coverage is already 100%, so the baseline would be 3, but the description goes well beyond the schema by prescribing the exact value-construction rules per dynamic field type (currency -> "EUR;1000.10", currency_duration -> "EUR;1000.10;monthly", bool -> "true"/"false", duration -> "P6D", multi_select -> values array). That is meaning the schema does not carry.

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

Purpose4/5

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

The opening sentence gives a specific verb and resource ('Create a new document from a template') plus the optional pre-fill scope, which implicitly separates it from create-document-from-scratch and create-document-from-pdf-upload. It never names those siblings explicitly, so differentiation is by inference rather than by explicit contrast.

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?

Provides an explicit 'Use this tool when' condition ('The user wants to generate a document based on an existing template') and a concrete prerequisite workflow: call get-template-info with include=["parties", "signatories", "dynamic_fields"] before populating the arguments. Nothing about when to reach for this tool is left to inference.

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