Skip to main content
Glama

Duplicate document

duplicate-document

Create a new draft document as a copy of an existing document.

Use this tool when:

  • The user wants to duplicate or copy a document, e.g. to reuse a previous contract as the starting point for a new one with a different counterparty

  • A new agreement should start from an existing document rather than from a template

The copy takes over the source document's content, parties, signatories, dynamic field values, metadata values, attachments, teams, tags, document type and template link. The new document always starts in the draft stage, whatever stage the source document is in, and a source document that is in signing or done is copied with its content as it was before signing started.

Change what differs in the new document afterwards with the update-* tools, e.g. update-document-party for the counterparty or update-document-dynamic-fields for amounts and dates.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoThe name of the new document. If omitted, the source document's name followed by " (copy)" is used
document_uuidYesUUID of the document to duplicate. If you don't already have the document's UUID, use the list-documents tool to find it.

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 only declare the non-destructive, non-read-only, non-open-world profile. The description adds substantial context beyond that: it enumerates exactly what is inherited (content, parties, signatories, dynamic field values, metadata, attachments, teams, tags, document type, template link) and discloses the non-obvious stage behavior (always starts in draft; signing/done sources copy pre-signing content). This is the kind of behavioral detail an agent cannot infer from structured fields.

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 core action is front-loaded in the opening sentence, followed by usage triggers, then the inheritance/stage semantics, then remediation pointers. Every sentence earns its place with no redundancy or filler.

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, return values need no explanation, and the description covers the remaining gaps: when to use it, what gets copied, and the resulting stage. Nothing an agent needs to invoke it correctly is missing.

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 (including the name fallback to ' (copy)') are already documented in the schema. The description adds no parameter syntax or format information 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?

The first sentence states a specific verb ('Create') and resource ('a new draft document as a copy of an existing document'), and the intent is immediately distinguishable from sibling creation tools like create-document-from-scratch or create-document-from-template. An agent knows exactly what operation this performs without opening the schema.

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?

The description gives explicit when-to-use scenarios ('reuse a previous contract as the starting point', 'start from an existing document rather than from a template') and names the follow-up alternative tools (update-document-party, update-document-dynamic-fields). It even draws the boundary against template-based creation, which is the closest sibling ambiguity.

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