Skip to main content
Glama

Get template HTML

get-template-html
Read-onlyIdempotent

Returns the content of a template serialised as HTML.

Use this tool when:

  • You want to read or navigate the content of a template

  • You want to understand the structure of a template before editing it

The HTML uses semantic data-* attributes to represent fynk-specific nodes such as dynamic fields, party references, and signature blocks. Addressable nodes (paragraphs, headings, etc.) carry a data-uuid attribute that can be used to target individual nodes in subsequent operations.

Clause numbering is dynamic. Numbered clauses are ordered list nodes — <div data-list data-kind="ordered"> — that contain the clause text and, when nested, sub-clauses. Their computed number is shown read-only via a data-number attribute (e.g. data-number="1.1."). Numbers are never part of the text; do not treat them as editable content.

A cross-reference to a clause appears as <span data-section-ref data-uuid="...">, where data-uuid is the data-uuid of the list node it points at. It is empty: what it renders is that clause's computed number, so it follows the clause rather than stating a number of its own.

Dynamic fields (fill-in placeholders) appear inline as <span data-dynamic-field data-ref-uuid="...">, where data-ref-uuid is the field's ref_uuid (see get-template-info include=["dynamic_fields"]). Signature blocks are grouped in a signature container — <div data-signatures data-align="..."><span data-signature-block data-ref-uuid="..."></span></div> — where each <span data-signature-block> points at one block by its ref_uuid (see get-template-info include=["signature_blocks"]). Legacy content may still show a block outside any container, as <div data-signature-block data-ref-uuid="...">; writing it back turns it into a container holding that one block. Party references appear as <span data-party data-ref-uuid="..." data-format="name|reference|address|address:inline">, where data-format selects what is rendered (name = the party's entity_name, reference = its reference name).

Images (<img data-image>), dynamic tables (<div data-dynamic-table>) and signing vote blocks (<span data-signing-vote-block>) appear as empty reference tags. Their contents are held outside the HTML and cannot be created or edited through it, so copy these tags over unchanged when rewriting the template; dropping one removes the image or table from the template.

Text formatting - bold, colour, font, size, highlight - is stated inline, as the style of the tag carrying it. A block's layout is not: the margins, indent and line height a paragraph or heading is laid out with stay on the block itself, so the HTML says nothing about them.

A block's alignment is stated, as data-text-align on the paragraph, heading or list node carrying it - left, center, right or justify - with a matching text-align style alongside it. A block carrying neither is aligned left.

Only available for templates with a prosemirror_data content type. Returns an error for PDF templates.

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": "get-template-html"
  }
}

Input Schema

NameRequiredDescriptionDefault
template_uuidYesUUID of the template to render as HTML

Output Schema

NameRequiredDescriptionDefault
htmlNoThe template content serialised as HTML. Fynk-specific nodes use data-* attributes (e.g. data-dynamic-field, data-party, data-signatures). Addressable nodes carry a data-uuid attribute.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds substantial context: it errors on PDF templates (only prosemirror_data supported), warns that dropping empty reference tags removes images/tables, that clause numbers are read-only computed values, and that layout properties are not represented. This is rich disclosure beyond structured fields.

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 purpose and when-to-use before the detailed format reference. The body is long but structured and each section documents a distinct node type; density is justified by the format complexity, though it is verbose.

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. For a complex HTML-format tool the description thoroughly covers node semantics, content-type restriction, and editability constraints, leaving nothing an agent needs to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Single parameter with 100% schema coverage, so the schema already documents template_uuid fully. The description adds no further parameter-specific detail, making baseline 3 appropriate.

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: returns template content serialised as HTML. It implicitly distinguishes itself from get-template-info by pointing there for ref_uuid lookups, letting an agent tell the two apart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit 'Use this tool when' bullets cover reading/navigating content and understanding structure before editing. It routes to get-template-info for related metadata, though it does not explicitly name replace-template-content as the write alternative or state when not to use it.

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