fynk MCP

Update document dynamic fields

update-document-dynamic-fields

Destructive

Update the value of one or more of a document's dynamic fields.

Use this tool when:

You want to fill in (or change) values for fields like text inputs, dates, numbers, or selects on a document
A user asks to set values that signing requires before it can begin (mandatory dynamic fields)

Each entry in dynamic_field_values identifies the field by its ref_uuid or name (use get-document-info with include=["dynamic_fields"] to discover them) — sending the wrong key will fail validation.

Take note of the field's type when constructing the value. These are the rules to use when constructing the value string:

number: the numeric value in a string, using '.' as the decimal separator -> "1234.56"
currency: concatenate the ISO currency code and the numeric value with a ';' -> "EUR;1000.10" (for one thousand Euro and ten cents)
currency_duration: same as currency, but append another ';' followed by either monthly or yearly -> "EUR;1000.10;monthly" / "USD;1000.10;yearly"
select: one of the options from the field's select_values list -> "red"
multi_select: an array of the selected values in the values field -> ["red", "blue"]
bool: either of the strings "true" (displayed to the user as "Yes") or "false" (displayed to the user as "No") -> "true" / "false"
duration: a PHP-compatible duration specification -> "P6D" (6 days), "P2W" (2 weeks), "PT12H" (12 hours)
date: the date in the format "YYYY-MM-DD" -> "2026-12-31"
email, text, textarea, or any type not listed above: a string -> "test@example.com"

To unset a dynamic field, send a null value.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`document_uuid`	Yes	UUID of the document whose dynamic fields are to be updated. If you don't already have the document's UUID, use the list-documents tool to find it.
`dynamic_field_values`	No	New values to apply (at most 10 per request). Signing can only start when all mandatory dynamic fields have values provided.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`dynamic_fields`	No	The fields that were updated

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 flag this as a destructive, non-read-only, closed-world mutation, and the description adds substantial behavioral context beyond that: wrong identifiers fail validation, null unsets a field, at most 10 entries apply per request, and mandatory fields gate signing. It also explains value-construction rules by field type, which materially reduces invocation errors.

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 description is long but front-loads purpose and usage before the necessary value-format rules. Every section earns its place because the dynamic field types have non-obvious string encodings that would otherwise cause validation failures. The bulleted formatting makes it scannable despite the length.

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 a destructive mutation tool with annotations, an output schema, and 100% schema description coverage, the description supplies everything else an agent needs: when to use it, how to discover identifiers, how to encode each field type, how to unset values, the 10-item limit, and the signing prerequisite. No important behavioral or parameter gap remains.

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

Parameters5/5

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

Schema coverage is already 100%, but the description goes far beyond the schema by explaining how to construct values for each dynamic field type, including number, currency, currency_duration, select, multi_select, bool, duration, date, email/text/textarea, and the null-unset convention. It also clarifies that each entry identifies the field by ref_uuid or name. This is rich semantic guidance that the schema alone does not provide.

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 description names a specific verb and resource: update the value of one or more of a document's dynamic fields. It clearly distinguishes this from document-level updates and template-field updates by scoping to a document's dynamic field values. An agent can identify the tool from the description alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage contexts: filling or changing text/date/number/select values, and satisfying mandatory dynamic fields required before signing. It also points to get-document-info for discovering field identifiers. However, it does not explicitly state when not to use this tool or name sibling alternatives such as update-template-dynamic-field.

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?