Skip to main content
Glama
formfeed-dev

formfeed

Official
by formfeed-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Validate a template with data

validate_template
Read-only

Validates a template and its data without rendering, catching syntax errors, missing variables, and schema violations before you produce a document.

Instructions

Checks a template and its data without rendering: free, no units, nothing stored, no document produced. Call it before render when you assembled the data yourself, or after writing ad-hoc html. With template, the API checks the published version (else the latest) as a render would: syntax, header and footer, errors only this data triggers, and the data against the stored JSON Schema (a wrong type or a missing required field is an error). With html and engine it compiles offline and reports syntax errors, unknown filters and variables missing from data. Returns ok and diagnostics (severity, code, message, plus path, line and column, or part and paragraph for Word and PowerPoint). Warnings leave ok true: settle each before rendering.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNoThe data the document will be rendered with, shaped as get_template_schema describes. Left out, a stored template is checked with its sample data
htmlNoTemplate source to check offline, when there is no stored template; pass this or template
engineNoTemplate language of html; required with html
templateNoSlug or tpl_ id of a stored template; pass this or html

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.3.10
    • addedInput schema / properties / data / description
      Added value: +"The data the document will be rendered with, shaped as get_template_schema describes. Left out, a stored template is checked with its sample data"
    • changedInput schema / properties / engine / description
      Previous value: -"Required with html"New value: +"Template language of html; required with html"
    • changedInput schema / properties / html / description
      Previous value: -"Template source when no slug is given"New value: +"Template source to check offline, when there is no stored template; pass this or template"
    • changedInput schema / properties / template / description
      Previous value: -"Template slug or tpl_ id"New value: +"Slug or tpl_ id of a stored template; pass this or html"
  2. First observedv0.3.7

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnlyHint/destructiveHint annotations, the description explains side effects (free, no units, nothing stored, no document), version selection (published else latest), what each mode checks, and the ok/diagnostics return contract including warnings leaving ok true. This is strong behavioral disclosure.

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?

The description is dense but every sentence earns its place and the main point is front-loaded. It is a single long paragraph that could be more scannable, but the length is justified by two distinct modes and a non-trivial return contract.

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?

For a tool with four optional params, two modes, no output schema, and no required fields, the description is complete: it explains return shape (ok and diagnostics with severity, code, message, location), mode-specific checks, and how to handle warnings. Nothing an agent needs to invoke 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 description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining how template is resolved (published/latest), that html is compiled offline, and that data is validated against a stored JSON Schema. This elevates the parameter guidance.

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?

The description opens with a specific verb and object: 'Checks a template and its data without rendering', and immediately distinguishes it from render by stating no document is produced. It also separates the stored-template and html modes, so an agent can tell this tool apart from render and convert_to_pdf.

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?

It gives explicit when-to-use guidance: 'Call it before render when you assembled the data yourself, or after writing ad-hoc html.' It names the render sibling as the follow-up operation, but it does not explicitly state when not to use the tool or name alternative validation paths.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools