Render PDFs and images from your Formfeed templates, check data against a template's schema, make ZUGFeRD / Factur-X e-invoices checked against EN 16931, and convert Office files to PDF. Sign in with your Formfeed account or use an API key.
Scored across 8 tools
Each tool targets a distinct step of the workflow (discover, inspect schema, validate, render, convert, poll, workspace context), and the descriptions explicitly route between the easy-to-confuse pairs (render vs convert_to_pdf, check_invoice vs validate_template). No tool appears to duplicate another's purpose.
Nearly all tools follow a verb_noun pattern (list_templates, get_render, get_template_schema, get_workspace, check_invoice, validate_template), with convert_to_pdf and the bare 'render' as the only deviations. The pattern remains easy to predict.
Eight tools map cleanly onto the document lifecycle: discovery (list_templates, get_template_schema, get_workspace), verification (validate_template, check_invoice), production (render, convert_to_pdf) and retrieval (get_render). Nothing feels padded or missing at this scope.
The core path from finding a template to producing and retrieving a document is fully covered, including pre-flight validation and e-invoice checking. Template authoring/publishing and a render listing or cancellation operation are absent, but agents can work around this since templates are authored in the Formfeed UI.
Checks the _invoice block of an e-invoice offline, as the API does before it renders one: the fields EN 16931 asks for, the totals to the cent, VAT categories and code lists, and France's rules for an invoice between two French businesses. Free, no units, nothing sent. Returns ok and problems, each with the field, the rule (BR-…) where one applies and a message. Nothing is computed for you: change the values a problem names, check again, then call render with einvoice and the block as data._invoice. The validator that runs during the render holds the file to the full rule set and to PDF/A-3b as well.
| Name | Required | Description | Default |
|---|---|---|---|
| invoice | Yes | The _invoice block as it goes into data._invoice: number, issue_date, currency, seller, buyer, lines, tax.breakdown, totals and payment, as https://docs.formfeed.dev/templates/e-invoices#invoice-block describes | |
| profile | No | The profile the render will ask for; en16931 when left out. basic cannot carry a rounding amount and is refused between two French businesses |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| problems | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past readOnlyHint/destructiveHint by disclosing cost ('free, no units'), that nothing is transmitted ('nothing sent'), that nothing is auto-fixed ('nothing is computed for you'), the return shape (ok plus problems carrying field, BR-… rule and message), and the stricter validation that awaits at render. These are exactly the traits an agent needs to plan a retry loop.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads what it validates, then the cost/offline guarantees, then the problem-then-render workflow, then the caveat about the render validator. Dense but every clause carries information an agent would otherwise have to infer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter validator with an output schema, the description covers purpose, cost, iteration loop, and the boundary against render-time validation. Nothing an agent needs in order to call it correctly and interpret the result is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the param details (block contents, profile enum, en16931 default, basic restrictions) are already carried by the schema. The description adds the tie that matters: the same block is what gets passed to render as data._invoice, which clarifies identity and reuse rather than restating the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (checks the _invoice block) plus the scope: offline, mirroring the API's pre-render validation, covering EN 16931 fields, totals, VAT categories, code lists and French domestic rules. It is clearly separable from the render sibling, which it names and contrasts with the stricter full rule set plus PDF/A-3b.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly positions the tool before render in a workflow: validate, change the values a problem names, check again, then call render with einvoice. It also names the condition that distinguishes its checks from the render-time validator, so the agent knows when this suffices and when it does not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Converts an existing Word, Excel, PowerPoint, OpenDocument, RTF or HTML document (up to 20 MB) to a PDF as it is, without filling in data, and returns the render with status and download_url. To make a document from a template and data, use render instead. Pass exactly one source: render_id, the render of a Word or PowerPoint template (output docx or pptx); or file_base64 with file_name, the document itself. Every call is a new render that counts units like a PDF; the Free plan cannot convert (Starter and above). The document is converted and not kept.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | No | Name of the PDF behind download_url, e.g. report.pdf | |
| file_name | No | Name of the document, e.g. report.xlsx; the type is read from the content | |
| landscape | No | Landscape for spreadsheets and documents without their own page setup | |
| render_id | No | rnd_ id of a render whose output is docx or pptx, to get that document as a PDF | |
| file_base64 | No | The document to convert, base64 encoded; needs file_name | |
| page_ranges | No | Pages to convert, e.g. 1-3,5; all pages when left out | |
| single_page_sheets | No | Each spreadsheet sheet on one page |
| Name | Required | Description |
|---|---|---|
| id | Yes | rnd_ id of the render |
| error | Yes | Why a failed render failed |
| units | Yes | Units the render counted |
| status | Yes | |
| einvoice | No | The e-invoice report, when the render made one |
| template | Yes | The template and version rendered; null for html and conversions |
| expires_at | Yes | When download_url stops working; get_render issues a fresh one |
| page_count | Yes | |
| environment | Yes | |
| download_url | Yes | Signed link to the file; null until the render succeeded |
| accessibility | No | The PDF/UA-1 verdict, when the template declares it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses cost behavior ('every call is a new render that counts units like a PDF'), plan gating, and data-retention ('the document is converted and not kept'), plus the return shape. These are consequential traits an agent cannot infer from readOnlyHint=false / idempotentHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and tightly packed with no filler, but the sentences are long semicolon-chained clauses that require careful parsing. Slightly more structure (e.g. separating inputs from constraints) would help.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a non-idempotent conversion tool with 7 optional params and an output schema, the description covers inputs, exclusivity rules, cost, plan limits, retention, and the return fields. Nothing an agent needs in order to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline would be 3, but the description adds the crucial mutual-exclusion semantics that the schema itself does not express (required params = 0): exactly one of render_id or file_base64+file_name, and that render_id must reference a docx/pptx render. Remaining params (landscape, page_ranges, single_page_sheets, filename) are left to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb (converts) plus the exact resource scope (Word, Excel, PowerPoint, OpenDocument, RTF, HTML, up to 20 MB) and explicitly distinguishes itself from render. An agent can tell what it produces (a PDF render with status and download_url) without reading the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Names the alternative explicitly ('To make a document from a template and data, use render instead') and gives the selection rule between the two input modes ('Pass exactly one source: render_id ... or file_base64 with file_name'). It also states a hard eligibility constraint (Free plan cannot convert; Starter and above).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the current state of a render: status (queued, rendering, succeeded or failed), download_url with expires_at, page_count, units and error, and the picture of a finished image render up to 2 MB. Use it to follow a render started with wait false, or to get a fresh link once the old one has expired; render and convert_to_pdf already return this for the render they just made. Read-only and free; an unknown id returns an error.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | rnd_ id of the render, as render or convert_to_pdf returned it |
| Name | Required | Description |
|---|---|---|
| id | Yes | rnd_ id of the render |
| error | Yes | Why a failed render failed |
| units | Yes | Units the render counted |
| status | Yes | |
| einvoice | No | The e-invoice report, when the render made one |
| template | Yes | The template and version rendered; null for html and conversions |
| expires_at | Yes | When download_url stops working; get_render issues a fresh one |
| page_count | Yes | |
| environment | Yes | |
| download_url | Yes | Signed link to the file; null until the render succeeded |
| accessibility | No | The PDF/UA-1 verdict, when the template declares it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish read-only and non-destructive behavior, and the description adds meaningful context beyond them: it is free, an unknown id returns an error, download links expire, and image payloads are capped at 2 MB. This is useful behavioral detail for an agent deciding whether and how to call it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the return shape, then usage guidance, then behavioral constraints. It is compact and every sentence adds distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the description covers the important states, link expiry, error behavior, and intended usage versus siblings. Nothing needed 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the sole id parameter is already documented as an 'rnd_ id of the render'. The description reinforces the id's meaning but adds no format or handling details beyond what the schema provides, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb and resource ('Returns the current state of a render') and enumerates the key state fields. It explicitly distinguishes itself from render and convert_to_pdf by noting those tools already return this state for their own output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use cases: following a render started with wait=false, or obtaining a fresh link after expiry. It also explicitly says when not to use it because render and convert_to_pdf already return the same data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the JSON Schema of the data object a template expects and the sample data it was designed with, from its published version, else its latest draft. Call it after list_templates and before render or validate_template, to build data that fits; ad-hoc html has no stored schema to read. When the template stores no schema, one is inferred from the sample data: treat that as a guide, not a contract. Read-only and free; an unknown slug returns an error.
| Name | Required | Description | Default |
|---|---|---|---|
| template | Yes | Slug (e.g. invoice) or tpl_ id, as list_templates returns them |
| Name | Required | Description |
|---|---|---|
| schema | Yes | JSON Schema of data; inferred from sample_data when none is stored |
| status | Yes | published, or draft when nothing is published yet |
| version | Yes | The version the schema comes from |
| template | Yes | |
| sample_data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly annotations it discloses the published-vs-draft fallback, that an inferred schema from sample data is a guide rather than a contract, that the call is free, and that an unknown slug errors. These are behaviors an agent cannot get from the 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: what is returned, when to call it, and the edge-case caveat. The return value is front-loaded and no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return shapes need not be spelled out, and the description covers the remaining ambiguities: version resolution, inference fallback quality, and error behavior. Nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the sole `template` parameter already documents slug-or-tpl_ id format. The description adds no parameter-level detail beyond naming the slug context implicitly, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: returns the JSON Schema of a template's `data` object plus its sample data. It also pins the resolution rule (published version, else latest draft), which no sibling tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit sequencing ('after list_templates and before render or validate_template') and a clear exclusion ('ad-hoc html has no stored schema to read'). The failure case for an unknown slug is also named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the workspace and organisation this server acts in, the plan, the environment (live or test) and the units of the current period: included, used and the balance of prepaid units. Call it when the user asks where a document will land or how many renders are left, or when list_templates returns nothing you expected. A signed-in agent works in the workspace chosen when it was connected, which the person changes in Formfeed under Account → Connected agents; an API key works in the workspace it was made for. Read-only and free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| plan | Yes | |
| units | Yes | |
| period | Yes | The current billing period |
| workspace | Yes | |
| environment | No | live renders count units; test renders are free |
| organization | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint=false, so 'Read-only and free' is partly redundant, but 'free' is new. The genuinely additive content is the scoping model: a signed-in agent sees the workspace chosen at connect time (changeable under Account → Connected agents) while an API key is pinned to the workspace it was created for. That explains why the answer might differ from user expectation, which annotations never convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The payload is front-loaded in the first sentence (what is returned), then triggers, then the scoping caveat. Four sentences with little waste, though 'Read-only and free' partly restates the annotations and could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 elaboration, yet the description still summarizes the fields an agent would reason about. With zero parameters and full annotation coverage, nothing an agent needs in order to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so the baseline of 4 applies. The description correctly offers no parameter guidance and instead spends its words on what the fixed result contains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete resource and enumerates exactly what comes back: workspace, organisation, plan, environment, and unit totals (included, used, prepaid balance). That is specific enough that an agent can distinguish it from every sibling in the list, none of which report account or workspace state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete triggers ('where a document will land', 'how many renders are left') and a diagnostic case tied to a named sibling: when list_templates returns unexpected results. It stops short of stating when not to call it or naming alternatives for the diagnostic case, so it is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the templates of the workspace this server works in (the one chosen at sign-in, or the API key's), most recently changed first: id, slug, name, kind (pdf, image, docx for Word, pptx for PowerPoint), engine, tags and published_version. Call it first to find the slug that get_template_schema, validate_template and render take; skip it when the user already named the template. Returns every match in one answer, without archived templates, and an empty list when nothing matches. A template whose published_version is null has never been published, so render cannot use it yet. Read-only and free.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Text to find in the name or slug, case-insensitive (e.g. invoice) | |
| tag | No | Only templates with this tag; exact match, tags are lowercase with dashes (e.g. billing) | |
| kind | No | Only templates that produce this kind of document | |
| engine | No | Only templates written in this template language |
| Name | Required | Description |
|---|---|---|
| templates | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/destructiveHint, but the description adds real behavioral facts: results are most-recently-changed first, archived templates are excluded, all matches come back in one answer (no pagination), an empty list signals no match, and a null published_version means render cannot use it. It also notes the call is free, which matters for an agent deciding whether to probe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and scope, and every clause carries information an agent would otherwise have to guess. The single dense block runs long and chains several ideas, but there is no filler sentence to cut.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present the description needn't enumerate return values, yet it still calls out ordering, archived exclusion, and the published_version null edge case that gates render. Combined with 100% schema coverage and clear annotations, an agent has everything needed to call this correctly or decide not to.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so q, tag, kind and engine are already fully documented, including case-insensitivity, exact-match tag format, and the kind/engine enums. The description's brief gloss of kind values repeats the enum rather than adding filtering semantics, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (Lists) plus resource (templates) plus scope (the workspace this server works in, chosen at sign-in or the API key's), ordering rule, and the returned field set. It also names the siblings that consume the slug (get_template_schema, validate_template, render), so an agent can place it precisely in the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when: "Call it first to find the slug that get_template_schema, validate_template and render take." Explicit when-not: "skip it when the user already named the template." Both the trigger and the exclusion are stated, not implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a document by filling a stored template, or ad-hoc html, with data: a PDF or image, or DOCX, PPTX or PDF from Word and PowerPoint templates. Returns the render with status and download_url; for an image (png, jpg or webp) up to 2 MB the result also carries the picture itself, so look at what you made before handing it on (a PDF comes as its link). Use it to make a document from data; to turn an existing office file into a PDF, use convert_to_pdf. Stored templates render their published version, so one whose published_version is null fails with template_not_found. Every call is a new render: a live key or a signed-in agent consumes units, a test key is free (watermarked on the Free plan). A render that fails returns status failed and an error with code and message; validate_template finds most causes beforehand. With einvoice the PDF becomes a ZUGFeRD / Factur-X e-invoice built from data._invoice (check the block with check_invoice first): the render then carries einvoice, the validator's report, and a refused invoice names the fields and rules to fix. The link expires at expires_at; get_render issues a fresh one.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Values for the template, shaped as get_template_schema describes; leave out when it needs none | |
| html | No | A complete HTML document to render instead of a stored template, up to 5 MB | |
| wait | No | Most renders are finished when the call returns; true also waits for one that continues in the background, false returns it as it is (queued or rendering) to check later with get_render | |
| engine | No | Template language of html, when it contains expressions to fill from data | |
| locale | No | BCP 47 tag for helpers and translations, e.g. de-DE | |
| output | No | Left out, the template decides: PDF for PDF templates and html, its image format for image templates, its default output for Word and PowerPoint templates. Word templates render docx or pdf, PowerPoint templates pptx or pdf | |
| einvoice | No | Makes the PDF a ZUGFeRD / Factur-X e-invoice whose XML is built from data._invoice: true for the defaults, an object to choose, false to switch off what the template declares. PDF only; live renders from the Starter plan, test keys on Free make 20 marked ones a day | |
| filename | No | Name of the file behind download_url, e.g. invoice-2026-0042.pdf | |
| template | No | Slug or tpl_ id of a stored template; pass this or html |
| Name | Required | Description |
|---|---|---|
| id | Yes | rnd_ id of the render |
| error | Yes | Why a failed render failed |
| units | Yes | Units the render counted |
| status | Yes | |
| einvoice | No | The e-invoice report, when the render made one |
| template | Yes | The template and version rendered; null for html and conversions |
| expires_at | Yes | When download_url stops working; get_render issues a fresh one |
| page_count | Yes | |
| environment | Yes | |
| download_url | Yes | Signed link to the file; null until the render succeeded |
| accessibility | No | The PDF/UA-1 verdict, when the template declares it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations: it discloses unit consumption for live/signed-in agents vs free watermarked test keys, that only the published template version renders (null published_version -> template_not_found), that failures return status failed with code and message, that the download link expires at expires_at, and that image renders under 2 MB inline the picture. 'Every call is a new render' is consistent with idempotentHint=false rather than a restatement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded and nearly every sentence carries distinct information (outputs, alternatives, billing, failures, e-invoice, link expiry). It is a single dense block, though, with several parenthetical asides packed together, which costs some scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a nine-parameter, nested-object, mutation-style tool with an output schema and annotations, the description covers outputs, defaults, billing, failure modes, pre-validation steps, e-invoice behavior and link lifetime. An agent has everything needed to invoke it correctly and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes data, html, wait, engine, locale, output, einvoice, filename and template thoroughly, including the enum semantics. The description reinforces the template-versus-html choice and the einvoice/data._invoice coupling but adds little parameter-level detail the schema doesn't already carry, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource — creates a document by filling a stored template or ad-hoc html — and immediately enumerates the concrete outputs (PDF, image, DOCX/PPTX from Word/PowerPoint templates). It actively differentiates itself from named siblings: convert_to_pdf for office conversions, validate_template for pre-checks, check_invoice for e-invoice validation, get_render for fresh links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing: 'Use it to make a document from data; to turn an existing office file into a PDF, use convert_to_pdf,' plus 'validate_template finds most causes beforehand' and 'check the block with check_invoice first.' The conditions that select each alternative are stated, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 | |
| template | No | Slug or tpl_ id of a stored template; pass this or html |
| Name | Required | Description |
|---|---|---|
| ok | Yes | false when a diagnostic is an error |
| template | No | The stored version checked; absent for html |
| diagnostics | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/non-destructive, but the description adds what the agent actually needs: it is free, consumes no units, stores nothing and produces no document. It also discloses the key behavioral nuance that warnings leave ok true and must be settled before rendering, plus the specificity of diagnostics (severity, code, path, line/column, part/paragraph).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The safety and cost profile is front-loaded in the first sentence, and nearly every clause carries information. It is a dense single paragraph with some run-on construction, which slightly hurts scannability, but nothing is truly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-required-parameter, dual-mode validation tool, the description covers mode selection, defaults, cost, side effects, and the meaning of a successful-but-warning result. With an output schema present it needn't enumerate return fields exhaustively, yet it does so anyway.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, and the description genuinely adds semantics on top: 'template' resolves to the published version, falling back to latest; 'data' defaults to the template's sample data; 'html'+'engine' compiles offline. These defaults and fallbacks are not stated in the schema itself, though the description doesn't detail the engine enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 the render sibling by its non-rendering nature. It then splits into the two distinct modes (stored template vs. html + engine), so an agent can recognize which path applies 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call it before render when you assembled the data yourself, or after writing ad-hoc html,' naming the sibling and the conditions that select each path. It also supplies the inverse condition for the html mode ('when there is no stored template'), leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_invoiceconvert_to_pdfget_renderget_template_schemaget_workspacelist_templatesrendervalidate_templatePDFs, images and e-invoices (XRechnung, ZUGFeRD) from templates and JSON, rendered in the EU.
Render PDFs from templates you design once: list templates, check the data shape, preview, render.
Automate production-ready PDF, Word, Excel and PowerPoint documents from templates and JSON data
Fill an HTML template with JSON and get a hosted PDF or image link. Free previews, no key.
Add one secure layer between your agents and this server.
