fynk MCP

Create template from scratch

create-template-from-scratch

Create a new empty template with editable ProseMirror content.

Use this tool when:

The user wants to start building a new template from scratch (not from an existing PDF or template)

The new template is created empty and its content is authored in a later step. The body references parties, dynamic fields and signature blocks by ref_uuid, so those have to exist before the content can point at them. Build the template in this order:

create-template-party for each contracting party.
create-template-signature-block for each party that signs.
create-template-dynamic-field for every value that varies per document - dates, amounts, notice periods, payment terms. A party's name or address is never one of them: both live on the party record and the content renders them from there.
replace-template-content once, with a body that references all of them by their ref_uuids and wraps each clause in an ordered list node so fynk numbers it.

Authoring the content first and adding the parties, fields and signature blocks afterwards forces a second, destructive rewrite of the whole body to weave the references in, so plan them up front. This applies just as much when the content is derived from a source document such as a PDF: every filled-in blank in the source is a dynamic field unless it holds party identity, and its signature lines are signature blocks.

The locale defines the template's content language and default number formats. Never ask the user for it - a BCP 47 tag is not something they can be expected to know. Infer it from the conversation, e.g. the language the content is to be written in or a country or jurisdiction the user names, and otherwise omit it, which falls back to the account's locale.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "create-template-from-scratch"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes	The name of the new template
`locale`	No	BCP 47 locale tag defining the template content language and default number formats (e.g. "de-AT"). Never ask the user for this tag: infer it from the conversation, or omit it to use the account locale.

Output Schema

Name	Required	Description
`url`	No	URL to open the template in fynk. Only present when your user has template editing permission
`name`	No	Name of the template
`tags`	No	The tags on the template. 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. Only present when the 'tags' section is requested via the include parameter.
`uuid`	No	Unique identifier for the template. Do not show to the user unless they ask for it
`teams`	No	The teams the template is assigned to. Only present when the 'teams' section is requested via the include parameter.
`locale`	No	Locale code, e.g. en-GB, de-AT. Prefer describing the locale in natural language (e.g. 'British English') rather than showing the raw code.
`parties`	No	The contracting entities the template defines. Only present when the 'parties' section is requested via the include parameter.
`published`	No	Indicates if the template is published (true) or a draft (false). Only published templates can be used by users without template management permission
`conditions`	No	The template's conditions: rules over its dynamic fields deciding whether a passage of the template applies, and whether each currently holds. Use them to explain why a clause is or is not part of the template, and what would have to change to flip it. Only present when the 'conditions' section is requested via the include parameter.
`created_at`	No	When the template was created. Only present when the 'timestamps' section is requested via the include parameter.
`updated_at`	No	When the template was last updated. Only present when the 'timestamps' section is requested via the include parameter.
`archived_at`	No	When the template was archived. Absent when the template is not archived. Only present when the 'timestamps' section is requested via the include parameter.
`attachments`	No	The files attached to the template. Attachments are part of the template itself and visible to external parties. Absent when the requesting user may not view the template's files. Only present when the 'attachments' section is requested via the include parameter.
`description`	No	Description of the template. Absent when the template has none. Only present when the 'details' section is requested via the include parameter.
`signatories`	No	The individual people who sign documents created from this template. 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. Only present when the 'signatories' section is requested via the include parameter.
`_entity_type`	No	Only relevant for tooling. Do not show to the user
`stored_files`	No	The files in the template's internal file storage, as opposed to its attachments. The app shows these files as "Internal file storage": call them that when talking to the user, never "stored files". Absent when the requesting user may not view the template's files. Only present when the 'stored_files' section is requested via the include parameter.
`document_type`	No	If present, indicates what kind of document this template creates. Absent when the template has no type assigned
`dynamic_fields`	No	The template's dynamic fields and their values. Only present when the 'dynamic_fields' section is requested via the include parameter.
`signature_type`	No	The eIDAS assurance level that will be used when signing documents created from this template. Absent when none has been chosen. Only present when the 'signing_settings' section is requested via the include parameter.
`metadata_values`	No	The template's metadata fields and their values. Only present when the 'metadata_values' section is requested via the include parameter.
`signature_blocks`	No	The places in the template 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. Only present when the 'signature_blocks' section is requested via the include parameter.
`sequential_signing`	No	Whether signatories must sign in a specific order. Only present when the 'signing_settings' section is requested via the include parameter.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 6, 2026

addedOutput schema / properties / attachments

Added value: +{
+  "description": "The files attached to the template. Attachments are part of the template itself and visible to external parties. Absent when the requesting user may not view the template's files. Only present when the 'attachments' section is requested via the include parameter.",
+  "items": {
+    "properties": {
+      "_entity_type": {
+        "description": "Only relevant for tooling. Do not show to the user",
+        "enum": [
+          "attachment"
+        ],
+        "type": "string"
+      },
+      "file_size": {
+        "description": "Size of the file in bytes. Use file_size_display when telling the user the size",
+        "type": "integer"
+      },
+      "file_size_display": {
+        "description": "Size of the file formatted for display, e.g. \"2.4 MB\"",
+        "type": "string"
+      },
+      "filename": {
+        "description": "Name of the file",
+        "type": "string"
+      },
+      "sha256": {
+        "description": "SHA-256 digest of the file's bytes, as lowercase hex. Equal digests mean byte-identical files. Do not show to the user unless they ask for it",
+        "type": "string"
+      },
+      "uuid": {
+        "description": "Identifier for the attachment. Do not show to the user unless they ask for it",
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / stored_files

Added value: +{
+  "description": "The files in the template's internal file storage, as opposed to its attachments. The app shows these files as \"Internal file storage\": call them that when talking to the user, never \"stored files\". Absent when the requesting user may not view the template's files. Only present when the 'stored_files' section is requested via the include parameter.",
+  "items": {
+    "properties": {
+      "_entity_type": {
+        "description": "Only relevant for tooling. Do not show to the user",
+        "enum": [
+          "stored_file"
+        ],
+        "type": "string"
+      },
+      "file_size": {
+        "description": "Size of the file in bytes. Use file_size_display when telling the user the size",
+        "type": "integer"
+      },
+      "file_size_display": {
+        "description": "Size of the file formatted for display, e.g. \"2.4 MB\"",
+        "type": "string"
+      },
+      "filename": {
+        "description": "Name of the file",
+        "type": "string"
+      },
+      "sha256": {
+        "description": "SHA-256 digest of the file's bytes, as lowercase hex. Equal digests mean byte-identical files. Do not show to the user unless they ask for it",
+        "type": "string"
+      },
+      "uuid": {
+        "description": "Identifier for the stored file. Do not show to the user unless they ask for it",
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}

First observedOct 20, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the description carries the rest and does: the template is created empty, content is authored in a later step, and body references resolve by ref_uuid, which means the referenced records must exist first. It also covers the locale inference policy and fallback to the account locale, which annotations cannot express.

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?

The purpose and trigger are front-loaded, and the numbered build order is easy to scan. However, several sentences are really instructions for sibling tools and for a later replace-template-content call, which stretches the definition beyond what is needed to invoke this two-parameter tool.

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?

With an output schema present, the description needn't document return values, and it supplies the surrounding workflow, the ref_uuid dependency, and the locale policy, so nothing an agent needs in order to call this correctly is missing. The complexity of the surrounding template-authoring flow is fully accounted for.

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 coverage is 100% and the locale property description already states BCP 47, content language, number formats, and the 'never ask, infer or omit' rule, so the description largely repeats the schema rather than extending it. The `name` parameter gets no added semantics at all. Baseline 3 applies when the schema does the heavy lifting.

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 opening sentence gives a specific verb, resource and scope: "Create a new empty template with editable ProseMirror content." The 'Use this tool when' clause explicitly excludes starting from an existing PDF or template, which separates it from siblings like duplicate-template and create-document-from-template.

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?

It states the positive trigger (building a new template from scratch), the negative case (not from an existing PDF or template), and a numbered ordering against named sibling tools (create-template-party, create-template-signature-block, create-template-dynamic-field, replace-template-content). It even explains the cost of the alternative order: a second, destructive rewrite of the body.

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

All fynk MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?