Skip to main content
Glama

Create template signature block

create-template-signature-block

Add a signature block to a template, bound either to one of its parties or to a single signatory.

Use this tool when:

  • The user wants a party to have a place to sign on documents created from the template

  • The user wants one specific signatory to have their own place to sign

  • You are building up a template and need to add signing slots

Pass exactly one of party_uuid or document_user_uuid. A party-bound block is signed by every signatory of that party, whoever they turn out to be on a document created from the template; a user-bound block is signed only by the signatory it names. Use get-template-info with include=["parties", "signatories"] to discover the available parties and signatories and their UUIDs.

A user-bound block requires a signatory that belongs to a party, because the block records that party alongside the signatory.

IMPORTANT: this is only the first of two steps. Creating the signature block does NOT place it in the template content, so on its own it will not appear on any document. To make it show up, reference the returned ref_uuid in the template body (via replace-template-content) from a signature container, which houses one or more blocks:

<div data-signatures data-align="left"><span data-signature-block data-ref-uuid="<signature block ref_uuid>"></span></div>

A block is always placed inside such a container, even when it is the only one.

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

style (regular or minimal) and scale (50–150, percent) are optional and default to "regular" and 100.

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>"
    },
    "name": "create-template-signature-block"
  }
}

Input Schema

NameRequiredDescriptionDefault
scaleNoScale percentage of the signature block (50–150). Defaults to 100.
styleNoVisual style of the signature block. Defaults to "regular".
party_uuidNoUUID of the party this signature block belongs to, so that every signatory of that party signs it. Must be a party already on the template (use get-template-info to find it). Provide either this or document_user_uuid, not both.
template_uuidYesUUID of the template to add the signature block to
document_user_uuidNoUUID of the single signatory this signature block is bound to. Must be a signatory already on the template and belonging to a party (use get-template-info with include=["signatories"] to find it). Provide either this or party_uuid, not both.

Output Schema

NameRequiredDescriptionDefault
uuidNoDo not show to the user unless they ask for it
scaleNoScale percentage of the signature block (50–150)
styleNoVisual style of the signature block
ref_uuidNoA static reference identifier, allowing signature blocks in documents to be matched to their corresponding block in the source template. Do not show to the user unless they ask for it
party_uuidNoUUID of the party this signature block belongs to. Do not show to the user unless they ask for it
_entity_typeNoOnly relevant for tooling. Do not show to the user
document_user_uuidNoUUID of the single signatory this signature block is bound to. Absent when the block is bound to its party instead, in which case every signatory of that party signs it. Do not show to the user unless they ask for it

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say this is a non-idempotent, non-destructive write. The description adds the crucial behavioral fact the annotations cannot convey: the created block is inert until its ref_uuid is referenced from a signature container in the template body, and a user-bound block requires a signatory that already belongs to a party. That is exactly the hidden-state disclosure an agent needs.

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: purpose, then when-to-use, then the two-step warning, then parameter notes. Every block is purposeful, though the point that an unreferenced block 'is rendered nowhere' is stated twice, and the HTML example plus the dynamic-field analogy add length beyond the minimum.

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?

Output schema exists so return values need no explanation, yet the description still explains the one output detail that matters (use the returned ref_uuid). For a 5-parameter tool in a multi-step template-authoring workflow, nothing an agent needs before calling it correctly is missing.

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 field-level documentation already exists. The description still adds real semantics beyond the schema: the mutual exclusivity rule ('pass exactly one') and what each binding means in practice (every signatory of a party vs. only the named signatory). Style/scale defaults are only restated from the schema, so not a full 5.

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?

States a specific verb and resource (add a signature block to a template) and immediately narrows the binding model to either a party or a single signatory. This cleanly separates it from sibling create-template-dynamic-field and from update-template-signature-block.

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?

Gives an explicit 'use this tool when' list covering the three concrete user intents, plus the prerequisite discovery tool (get-template-info with include=["parties", "signatories"]). It also names the follow-up tool (replace-template-content) needed to finish the job, so the agent knows the tool is not a complete action on its own.

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