fynk MCP

Duplicate template

duplicate-template

Create a new template as a copy of an existing template.

Use this tool when:

The user wants to duplicate or copy a template, e.g. to build a variant of an existing contract for another jurisdiction or business line
A new template should start from an existing one rather than from scratch

The copy takes over the source template's content, parties, signatories, signature blocks, dynamic fields, conditions, metadata values, attachments, teams, tags, document type, locale and published state. Documents already created from the source template stay linked to the source.

Change what differs in the new template afterwards with the template tools, e.g. update-template-party, update-template-dynamic-field or replace-template-content. replace-template-content only writes a draft, so a copy of a published template has to be unpublished with set-template-published-state before its body can be rewritten.

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": {
      "template_uuid": "<template_uuid>"
    },
    "name": "duplicate-template"
  }
}

Input Schema

Name	Required	Description	Default
`name`	No	The name of the new template. If omitted, the source template's name followed by " (copy)" is used
`template_uuid`	Yes	UUID of the template to duplicate. Use list-templates to find it.

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.
`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.
`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.
`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.
`created_at`	No	When the template was created.
`updated_at`	No	When the template was last updated.
`archived_at`	No	When the template was archived. Absent when the template is not archived.
`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.
`description`	No	Description of the template. Absent when the template has none.
`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.
`_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.
`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.
`signature_type`	No	The eIDAS assurance level that will be used when signing documents created from this template. Absent when none has been chosen.
`metadata_values`	No	The template's metadata fields and their values.
`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.
`sequential_signing`	No	Whether signatories must sign in a specific order.

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.",
+  "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.",
+  "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 that this is a non-read-only, non-destructive, non-idempotent write. The description goes well beyond that by enumerating exactly what is inherited (content, parties, signatories, dynamic fields, metadata, attachments, teams, tags, document type, locale, published state) and by clarifying that documents already created from the source remain linked to the source. The caveat that replace-template-content only writes a draft is a genuine behavioral constraint an agent would otherwise miss.

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 a one-line purpose, then a scannable bulleted when-to-use list, then the inheritance scope. The final paragraph about replace-template-content and set-template-published-state is useful but drifts into cross-tool workflow detail that lengthens the definition beyond its core job.

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?

An output schema exists, so return values needn't be restated. For a mutation tool that clones a complex entity, the description covers inheritance, linkage side effects, and the publish-state interaction needed to actually modify the copy afterward — everything an agent needs to invoke it correctly and plan the next step.

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 schema already documents both template_uuid (with a pointer to list-templates) and the name default ('(copy)' suffix). The description adds no parameter-level detail beyond implying that template_uuid identifies the source, so the schema carries the load.

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 and resource ('Create a new template as a copy of an existing template'), which immediately separates it from create-template-from-scratch and duplicate-document. The scope of the copy ('takes over the source template's content, parties, signatories...') makes the operation unambiguous.

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:' list with two concrete scenarios (building a variant for another jurisdiction/business line, starting from an existing template rather than scratch). It also names the follow-up alternatives (update-template-party, update-template-dynamic-field, replace-template-content) and the prerequisite step (set-template-published-state) needed to rewrite a published copy.

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?