Skip to main content
Glama

Get template HTML

get-template-html
Read-only

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
template_uuidYesUUID of the template to render as HTML

Output Schema

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

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

Annotations already declare it as a safe, read-only, closed-world operation, and the description adds substantial context beyond them: the data-* attribute vocabulary, read-only clause numbering, empty reference tags (images, dynamic tables, vote blocks) whose contents live outside the HTML and are lost if dropped, legacy signature-block normalization on write-back, and the PDF-template failure mode.

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?

Purpose and when-to-use are front-loaded, then the node-encoding details follow in a logical order. It is long, but nearly every sentence describes a parsing or write-back rule the agent needs; only the per-node examples edge toward redundancy.

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, yet the description still supplies the interpretive rules an agent needs to manipulate the returned HTML safely (which attributes target nodes, which tags must be copied verbatim, alignment defaults). Nothing required to call it correctly or use its result 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% for the single template_uuid parameter, so the baseline is 3. The description adds meaningful qualifying semantics for that parameter — the template must have a prosemirror_data content type or the call errors — which the schema does not express.

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 a template's content serialised as HTML. It is clearly distinguishable from sibling get-template-info (metadata) and replace-template-content (write), and even cross-references get-template-info for ref_uuid lookups, so an agent can route without opening other schemas.

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?

Provides an explicit 'use this tool when' list (read/navigate content, understand structure before editing) plus a hard eligibility rule: only prosemirror_data templates, errors for PDF templates. It lacks an explicit 'do not use this when...' exclusion list and does not name replace-template-content as the write counterpart, but the context is clear.

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