Skip to main content
Glama

Create template dynamic field

create-template-dynamic-field

Create a new dynamic field on a template.

Use this tool when:

  • The user wants to add a variable / fill-in field (e.g. text, number, date, select) to a template

  • You are building up a template and need a placeholder whose value is filled in per document

IMPORTANT: this is only the first of two steps. Creating the field does NOT place it in the template content, so on its own the fill-in placeholder will not appear in the document text. To make it show up, reference the returned ref_uuid in the template body (via replace-template-content) as:

<span data-dynamic-field data-ref-uuid="<dynamic field ref_uuid>"></span>

Until it is referenced in the content the field exists but is rendered nowhere. The same two-step pattern applies to signature blocks (create-template-signature-block, then <div data-signatures><span data-signature-block data-ref-uuid="..."></span></div>).

Dynamic fields define the variable data filled in when a template is used to create a document. Each field has a type controlling what values it accepts, and a scope controlling who fills it in.

A party's name or address is never a dynamic field. Both live on the party record: add the party with create-template-party and render its details in the content with , taking data-format="address" for the address as a block and data-format="address:inline" for it on one line, as a preamble reads it. A document made from the template then follows its own parties.

select and multi_select fields require select_values (the allowed options).

The optional default value is set via value (for non-multi_select fields) or values (for multi_select fields). Construct the value string according to the field type:

  • 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"

  • currency_duration: same as currency, but append another ';' followed by either monthly or yearly -> "EUR;1000.10;monthly"

  • select: one of the options from select_values -> "red"

  • multi_select: an array of the selected options in the values field -> ["red", "blue"]

  • bool: either of the strings "true" (shown as "Yes") or "false" (shown as "No")

  • duration: a PHP-compatible duration specification -> "P6D" (6 days)

  • 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"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesDisplay name of the field (max 255 characters)
typeYesControls the type of values the field accepts (e.g. "text", "number", "date", "select")
scopeNoWho fills in the field: "internal" (only your team) or "internal_and_external" (also counterparties). Defaults to "internal_and_external".
valueNoOptional default value for non-multi_select fields. Format depends on type (see tool description).
valuesNoOptional default 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. Defaults to false.
select_valuesNoRequired for "select" and "multi_select" types: the allowed options for the field
template_uuidYesUUID of the template to add the dynamic field to

Output Schema

TableJSON 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.9/5.0
Behavior5/5

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

Annotations only declare the generic write profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false). The description goes well beyond that by disclosing the critical non-obvious behavior: creating the field does not render it, and the returned ref_uuid must be referenced in the body before the placeholder appears. It also states the same two-step pattern applies to signature blocks.

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 description is long but well front-loaded (purpose first, then when-to-use, then the two-step warning, then type formatting). The signature-block and party-rendering asides are somewhat tangential to creating a dynamic field, but they do serve sibling routing, so they mostly earn their place.

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?

For a 9-parameter mutation tool with an output schema and full schema coverage, this description covers everything an agent needs: creation semantics, the rendering requirement, sibling boundaries, and per-type value formats. Return values are handled by the output schema and the reference to ref_uuid.

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 adds substantial semantics beyond the schema, notably the exact string construction for `value` per `type` (currency 'EUR;1000.10', currency_duration with monthly/yearly suffix, PHP duration 'P6D', date format), the `values` array for multi_select, and the fact that select/multi_select require select_values. This is meaning the schema alone does not convey.

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 opening sentence names a specific verb and resource ('Create a new dynamic field on a template'), and the body explicitly differentiates the tool from siblings such as create-template-party, create-template-signature-block, and update-template-dynamic-field. An agent can tell exactly which entity this tool creates 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 'Use this tool when' conditions (adding a variable/fill-in field while building a template) and explicitly routes agents away from it for party names/addresses, naming the correct alternatives instead. It also names replace-template-content as the required follow-up call, leaving no ambiguity about sequencing.

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