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.

Input Schema

TableJSON 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

TableJSON 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.
`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
`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.

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 readOnlyHint=false, destructiveHint=false, openWorldHint=false. The description adds substantial context beyond that: the full list of what is copied (content, parties, signatories, signature blocks, dynamic fields, conditions, metadata, attachments, teams, tags, document type, locale, published state), the important non-destructive fact that existing documents stay linked to the source, and the published-state constraint on replace-template-content.

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 core action, then well-organized bullets and a compact paragraph on copy semantics followed by the post-duplication edit path. Dense but every sentence carries information; the last sentence on replace-template-content/unpublish is a slightly tangential prerequisite note but still actionable.

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?

Given an output schema exists, return values need not be explained. With annotations plus a full parameter schema plus this description covering copy scope, non-destructive linkage behavior, and the follow-up workflow, an agent has everything needed to invoke and sequence the call correctly.

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 both parameters (name, template_uuid) are already fully documented, including the ' (copy)' default for name and the list-templates pointer. The description adds no parameter-level detail beyond what the schema provides, so the baseline 3 applies.

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') and immediately scopes it against siblings like create-template-from-scratch ('rather than from scratch') and implicitly duplicate-document (templates vs documents). An agent can tell exactly what this produces.

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?

Explicit 'Use this tool when' bullets give the trigger conditions (duplicating/copying a template, building a jurisdiction or business-line variant, starting from an existing template). It goes further and routes the agent onward to a named alternative workflow — update-template-party, update-template-dynamic-field, replace-template-content — and flags the prerequisite/unpublish step.

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?