fynk MCP

Update document dynamic fields

update-document-dynamic-fields

DestructiveIdempotent

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.

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-dynamic-fields"
  }
}

Input 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

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?

The annotations already mark this as destructive and idempotent, and the description adds meaningful behavioral context: wrong identifiers fail validation, null unsets a field, and mandatory fields must be filled before signing. It also explains how to discover valid identifiers, which reduces failure risk.

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 purpose and usage conditions are front-loaded, followed by structured bullets for value construction. The length is justified because the type-specific formatting rules are necessary to avoid validation failures.

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?

The definition covers purpose, when to use it, identifier discovery, value formatting by field type, unsetting behavior, and signing prerequisites. An output schema exists and annotations already communicate safety traits, so the remaining description needs are met.

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?

Although schema coverage is already 100%, the description adds substantial meaning beyond the schema by specifying how to construct values for number, currency, currency_duration, select, multi_select, bool, duration, date, and other field types. It also clarifies that identifiers come from ref_uuid or name, and that null unsets a field.

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 states a specific verb and resource: updating one or more of a document's dynamic fields. It clearly distinguishes this from metadata or template-field siblings by naming dynamic fields and describing document-specific signing prerequisites.

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?

It gives explicit usage conditions: filling or changing field values, and setting mandatory values required before signing can begin. It also points to get-document-info for discovering field identifiers, though it does not explicitly state when to prefer update-document or update-template-dynamic-field instead.

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?