fynk MCP

Update document

update-document

DestructiveIdempotent

Updates a document's name, locale, document type, signing settings and/or external signatory invitation message.

Use this tool when:

A document should be renamed
The document's content language (locale) or document type should change
The signature type or sequential signing setting should change before signing starts
The message included in the email inviting external signatories should be set or changed

All arguments except document_uuid are optional and only need to be sent if their value should change. signature_type and sequential_signing cannot be changed once signing has started, and signature_type cannot be changed if it was specified by the document's template. Use the list-account-document-types tool to discover valid document type UUIDs. This tool cannot change the document's stage (use the move-document-to-*-stage tools for that).

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": {
      "document_uuid": "<document_uuid>"
    },
    "name": "update-document"
  }
}

Input Schema

Name	Required	Description
`name`	No	New name for the document
`locale`	No	New locale code for the document content, e.g. en-GB, de-AT
`document_uuid`	Yes	UUID of the document to update. If you don't already have the document's UUID, use the list-documents tool to find it.
`signature_type`	No	eIDAS assurance level to use when signing the document. aes_eid is only accepted when the account has enabled AES (eID). Cannot be changed once signing has started or if the value was specified by the template
`document_type_uuid`	No	UUID of the document type to assign. Pass null to remove the current document type. Use the list-account-document-types tool to find valid UUIDs
`sequential_signing`	No	When true, signatories will sign one at a time, in ascending order of their signing_order. Cannot be changed once signing has started
`external_signatory_invitation_message`	No	Text to display in the email notification sent to external signatories when the document is ready for signing

Output Schema

Name	Required	Description
`url`	No	URL to open the document in fynk
`name`	No	Name of the document
`uuid`	No	Unique identifier for the document. Do not show to the user unless they ask for it
`stage`	No	What stage the document is in currently
`locale`	No	Locale 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.
`origin`	No	How the document was created.
`_entity_type`	No	Only relevant for tooling. Do not show to the user
`document_type`	No	If present, indicates what kind of document this is. Absent when the document has no type assigned
`signature_type`	No	eIDAS assurance level used when signing the document. Absent when none has been chosen.
`sequential_signing`	No	When true, signatories sign one at a time, in ascending order of their signing_order.
`source_template_uuid`	No	UUID of the template the document was created from. Absent when it was not created from a template.
`external_signatory_invitation_message`	No	Text shown in the email inviting external signatories to sign. Absent when no message is set.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 20, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, and the description adds the context those hints cannot: signature_type and sequential_signing are immutable once signing has started, and signature_type is immutable when set by the template. It also clarifies that all arguments except document_uuid are optional and only need to be sent when the value should change, which is the key behavioral contract for a partial-update tool.

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?

Front-loaded summary sentence, then a scannable when-to-use list, then constraints and sibling routing. Every sentence carries either a trigger, a constraint, or a pointer to another tool; nothing is padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Return values are covered by the output schema and safety by annotations, and the description closes the remaining gaps around mutability and stage transitions. The one omission is that destructiveHint=true is never explained in the description itself — notably that passing null for document_type_uuid removes the current document type, a data-losing action an agent should be warned about explicitly.

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

Parameters4/5

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

With 100% schema description coverage the baseline is 3, and the description earns above that by supplying cross-field constraints the per-parameter schema text only partly repeats (template-set signature_type, post-signing immutability) and by pointing to list-account-document-types. It stops short of explaining null semantics in the description (the schema itself says passing null to document_type_uuid removes the type), leaving that value-destroying behavior only in the schema.

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 names a specific verb plus the exact set of mutable fields (name, locale, document type, signing settings, invitation message), which pins down the tool precisely. It also explicitly disclaims stage changes and routes that concern to the move-document-to-*-stage siblings, so it is distinguishable from update-document-dynamic-fields, update-document-tags, and update-document-metadata-values without opening any 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 'Use this tool when' block gives four concrete triggering conditions, and the closing sentences give the negative cases (cannot change stage) with the alternative named. It even cites list-account-document-types as the prerequisite for obtaining valid document type UUIDs, leaving nothing to inference.

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?