fynk MCP

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.

Input Schema

TableJSON Schema

Name	Required	Description
`scale`	No	Scale percentage of the signature block (50–150). Defaults to 100.
`style`	No	Visual style of the signature block. Defaults to "regular".
`party_uuid`	No	UUID 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_uuid`	Yes	UUID of the template to add the signature block to
`document_user_uuid`	No	UUID 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

TableJSON Schema

Name	Required	Description
`uuid`	No	Do not show to the user unless they ask for it
`scale`	No	Scale percentage of the signature block (50–150)
`style`	No	Visual style of the signature block
`ref_uuid`	No	A 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_uuid`	No	UUID of the party this signature block belongs to. Do not show to the user unless they ask for it
`_entity_type`	No	Only relevant for tooling. Do not show to the user
`document_user_uuid`	No	UUID 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.

First observedOct 20, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations declare a non-read-only, non-destructive, non-open-world mutation, and the description adds real context beyond that: the block is created but not rendered until referenced in template content, exactly one of party_uuid/document_user_uuid must be supplied, and a user-bound block requires a signatory that belongs to a party. It does not mention auth/permission requirements or idempotency, but the two-step lifecycle disclosure is unusually valuable.

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-loads the core action, then structures usage, constraints, and the two-step requirement clearly, with the HTML snippet earning its place. It is long and the dynamic-field analogy is arguably extra, but no sentence is filler and the ordering is logical.

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, and annotations cover the safety profile. The description still supplies everything an agent needs to call this correctly: prerequisites, parameter exclusivity, discovery path, and the mandatory follow-up step.

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 schema already documents each parameter; the baseline would be 3. The description adds meaning beyond it by contrasting party-bound (signed by every signatory of that party, whoever they turn out to be) with user-bound (signed only by the named signatory), plus the mutual-exclusion rule and the default values for style/scale.

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 distinguishes the two binding modes, which is the key differentiator from siblings like create-template-party and create-template-dynamic-field. An agent can identify this tool 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?

Provides an explicit 'Use this tool when' list with three concrete scenarios, names the discovery alternative (get-template-info with include=["parties", "signatories"]), and points to replace-template-content as the required follow-up step. Both when-to-use and the downstream alternative are spelled out.

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?