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"

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>",
      "type": "<type>",
      "name": "<name>"
    },
    "name": "create-template-dynamic-field"
  }
}

Input 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

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. Changed1 schema field changed
    • changedInput schema / properties / type / enum
      Previous value: -[
      -  "id",
      -  "uuid",
      -  "bool",
      -  "date",
      -  "duration",
      -  "email",
      -  "list",
      -  "number",
      -  "currency",
      -  "currency_duration",
      -  "clause",
      -  "select",
      -  "multi_select",
      -  "text",
      -  "textarea",
      -  "timestamp",
      -  "array",
      -  "enum"
      -]New value: +[
      +  "text",
      +  "textarea",
      +  "email",
      +  "number",
      +  "currency",
      +  "currency_duration",
      +  "select",
      +  "multi_select",
      +  "date",
      +  "bool",
      +  "duration"
      +]
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already flag non-readonly, non-destructive, non-idempotent, but the description adds the non-obvious behavioral fact that this is step one of two and that the created field renders nowhere until its `ref_uuid` is referenced in template content via the given span markup. That is exactly the kind of context annotations cannot convey and prevents a silent no-op.

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?

Front-loaded with the core action, then the critical two-step warning in caps, then reference material. Every block is useful, but the party-rendering aside (data-format variants) is lengthy for a tool that does not create parties, making it slightly sprawling.

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?

An output schema exists, so return values need no explanation, yet the description still identifies the one output that matters (`ref_uuid`) and how to consume it. Combined with the type-encoding table and scope/mandatory notes, an agent has everything needed to invoke this correctly on its own.

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 100%, the schema defers on the key detail ('Format depends on type (see tool description)') and the description supplies the full per-type encoding for `value`/`values` (currency 'EUR;1000.10', currency_duration with monthly/yearly, bool strings, duration, date format). It also restates the select_values requirement and the scope semantics, adding meaning the schema alone does not carry.

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?

Opens with a specific verb+resource ('Create a new dynamic field on a template') and immediately distinguishes the concept from adjacent ones by explaining what a dynamic field is (variable data filled in per document) versus parties and signature blocks. An agent can tell this apart from create-template-party and create-template-signature-block without reading schemas.

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?

Explicit 'Use this tool when' bullets give the triggering conditions, and the description names the required follow-up (replace-template-content) plus the sibling tools for the same pattern. It also states an exclusion: a party's name/address is never a dynamic field and belongs to create-template-party.

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