Formfeed

Validate a template with data

validate_template

Read-only

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, or the version you name) 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

Name	Required	Description
`data`	No	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
`html`	No	Template source to check offline, when there is no stored template; pass this or template
`engine`	No	Template language of html; required with html
`version`	No	With template: the version to check, such as latest for the newest draft or a number; left out, the published one, else the latest
`template`	No	Slug or tpl_ id of a stored template; pass this or html

Output Schema

Name	Required	Description
`ok`	Yes	false when a diagnostic is an error
`template`	No	The stored version checked; absent for html
`diagnostics`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 26, 2026

addedInput schema / properties / version

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 32,
+      "minLength": 1,
+      "type": "string"
+    },
+    {
+      "exclusiveMinimum": 0,
+      "maximum": 9007199254740991,
+      "type": "integer"
+    }
+  ],
+  "description": "With template: the version to check, such as latest for the newest draft or a number; left out, the published one, else the latest"
+}

First observedOct 26, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds substantial context beyond the readOnly/non-destructive annotations: the call is free, consumes no units, stores nothing, and produces no document. It also discloses result semantics — `ok` plus `diagnostics` with severity, code, message, path/line/column, or part/paragraph for Word and PowerPoint — and clarifies that warnings leave `ok` true but should be settled before rendering.

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?

Dense but front-loaded: cost and side-effect guarantees come first, then when to call, then per-mode behavior, then return semantics. A few clauses restate schema-documented defaults (version fallback, data omission), but the length is justified by the tool's two-mode complexity.

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?

Covers everything an agent needs for a 5-parameter, mode-switching validation tool: cost, side effects, mode selection, what each mode checks, and how to interpret warnings versus errors. An output schema exists, yet the description still summarizes the return contract helpfully rather than leaving a gap.

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 baseline is 3, but the description adds cross-parameter behavior the schema does not convey: the `template` path validates against the published version falling back to latest or a named version, whereas `html` + `engine` compiles offline and reports unknown filters and variables missing from `data`. It also explains what the data is checked against (the stored JSON Schema, with wrong types or missing required fields as errors).

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 ("Checks a template and its data without rendering") and immediately distinguishes itself from `render` by declaring no units are consumed and no document is produced. It further splits the tool's two operating modes (stored template vs. ad-hoc html) so an agent can tell exactly which capability it is invoking.

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?

Gives explicit triggering conditions: call it "before render when you assembled the data yourself, or after writing ad-hoc html," which effectively routes the agent away from `render` when validation is the goal. It does not state any when-not conditions (e.g., cases where validation is redundant), so it falls just short of a 5.

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

All Formfeed tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?