Skip to main content
Glama

Update template dynamic field

update-template-dynamic-field
DestructiveIdempotent

Update an existing dynamic field on a template.

Use this tool when:

  • The user wants to change a dynamic field's name, scope, options, default value, or other properties

Only send the fields you want to change. A field's type cannot be changed after creation; to change the type, delete the field and create a new one.

select and multi_select fields still require non-empty select_values.

The default value is set via value (for non-multi_select fields) or values (for multi_select fields), formatted according to the field's type (see create-template-dynamic-field for the per-type format). Setting a default value clears any autofill configured on the field. Use get-template-info with include=["dynamic_fields"] to discover the dynamic fields on a template and their UUIDs and types.

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": {
      "template_uuid": "<template_uuid>",
      "dynamic_field_uuid": "<dynamic_field_uuid>"
    },
    "name": "update-template-dynamic-field"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoDisplay name of the field (max 255 characters)
scopeNoWho fills in the field: "internal" (only your team) or "internal_and_external" (also counterparties)
valueNoDefault value for non-multi_select fields. Format depends on type (see create-template-dynamic-field). Clears any autofill on the field.
valuesNoDefault value for multi_select fields: an array of options from select_values
questionNoOptional question or prompt shown to the user filling in this field
is_mandatoryNoWhether the field must be filled in before the document can be signed
select_valuesNoFor "select" and "multi_select" types: the allowed options for the field
template_uuidYesUUID of the template the dynamic field belongs to
dynamic_field_uuidYesUUID of the dynamic field to update (use get-template-info with include=["dynamic_fields"] to find it)

Output Schema

NameRequiredDescriptionDefault
nameNoThe name of the field
typeNoControls the type of values that can be stored
uuidNoDo not show to the user unless they ask for it
scopeNoWho fills in the field: "internal" (only your team) or "internal_and_external" (also counterparties)
valueNoFor none-multi_select-type fields, the value of the field. Absent when the field has no value.
valuesNoFor multi_select-type fields, the value of the field. Absent when the field has no value.
questionNoThe question or prompt shown to the user for this field
ref_uuidNoA static reference identifier, allowing dynamic fields in documents to be matched their corresponding field in the document's source template. Do not show to the user unless they ask for it
currenciesNoFor currency or currency_duration fields, the allowed currency codes (e.g. ["EUR", "USD"]). Absent indicates no restriction
_entity_typeNoOnly relevant for tooling. Do not show to the user
is_mandatoryNoWhether this field must be filled in before the document can be signed
select_valuesNoWhen type is "select" or "multi_select", defines the allowed values for the field. For these types of field, ONLY these values are possible. Absent for every other type

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

The annotations already flag destructiveHint=true and idempotentHint=true, but the description adds real substance the annotations don't: partial-update semantics ('Only send the fields you want to change'), the type-immutability constraint, the non-empty select_values requirement, and the side effect that setting a default clears any configured autofill. It doesn't explain why the tool is marked destructive or whether removing an option from select_values affects existing documents, so it stops short of full disclosure.

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?

The purpose statement and the use-when bullet come first, followed by constraints, which is the right order for an agent. A few sentences restate what the schema already documents (select_values non-emptiness, value/values split), which costs some tightness.

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?

With an output schema present, return values need no explanation, and the description covers the mutation's constraints, prerequisites, and side effects for a 9-parameter partial-update tool. It leaves open whether omitted fields are preserved and what the destructiveHint implies for existing field data, which an agent would still want to know before calling.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning the schema cannot express: which of value vs values applies by field type, that the format depends on the field's type (delegated to create-template-dynamic-field), and the select_values constraint on select/multi_select. It does not clarify the optional/required asymmetry for template_uuid and dynamic_field_uuid beyond what the schema states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening line gives a specific verb and resource ('Update an existing dynamic field on a template'), and later sentences name create-template-dynamic-field and get-template-info as related tools. It doesn't explicitly distinguish itself from the similarly named update-document-dynamic-fields sibling, so the template-vs-document split is left to the tool name rather than stated.

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?

It provides an explicit when-to-use trigger ('The user wants to change a dynamic field's name, scope, options, default value, or other properties'), an explicit exclusion with an alternative path ('A field's type cannot be changed after creation; ... delete the field and create a new one'), and a prerequisite discovery step via get-template-info. Alternatives are named rather than inferred.

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