Skip to main content
Glama
Sign In
Tailprint

Tailprint

by coheroseb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

render_template

Renders Tailwind CSS document templates with optional variable substitution to generate invoices, receipts, contracts, certificates, or reports as PDF/PNG/JPEG without managing raw HTML.

Instructions

Renders a pre-designed Tailwind CSS document template directly with optional variable data substitution. Ideal for generating invoices, receipts, contracts, and certificates without managing raw HTML markup.

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_id": "<template_id>"
    },
    "name": "render_template"
  }
}

Input Schema

NameRequiredDescriptionDefault
passwordNoOptional AES-256 password to encrypt the PDF document
landscapeNoOrientation override (landscape: true or false)
variablesNoKey-value pairs to replace in template HTML. Replaces {{key}} tags or exact text matches.
template_idYesTemplate identifier to render
output_formatNoOutput format: "pdf" for documents (default: pdf)pdf

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.4.0

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It says nothing about what a call returns (file path, base64 payload, download URL), whether output files persist, what happens when a {{key}} has no matching variable, or how password encryption affects the response — all material for a generation tool with five parameters including a nested object.

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?

Two tight sentences with the core action front-loaded and the use-case examples following. Nothing is redundant, though it is too brief for the tool's actual complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a five-parameter tool with a nested variables object, no annotations, and no output schema, the description should at minimum describe the returned artifact and any templating/encryption caveats. Instead it covers only purpose and example document types, leaving the agent uninformed about results and failure modes.

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?

Schema description coverage is 100%, with enum values and a default documented inline, so the schema already carries parameter meaning. The description only echoes "optional variable data substitution" and adds no syntax, format, or interaction detail beyond it, which matches the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Renders a pre-designed Tailwind CSS document template") plus the optional variable substitution, which is enough for an agent to tell it apart from get_template_source or list_templates. It does not explicitly contrast itself with render_pdf or render_presentation, so it falls short of 5.

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

Usage Guidelines3/5

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

"Ideal for generating invoices, receipts, contracts, and certificates without managing raw HTML markup" gives positive usage context, so an agent knows roughly when to reach for it. There is no when-not guidance and no named alternative (e.g. render_pdf for arbitrary HTML), leaving the choice among the render_* siblings to inference.

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