HTML/CSS to Image API

Create a Templated image

create_templated_image

DestructiveIdempotent

Creates an image from a saved template using template_values for its variable substitutions. Use a known template_id directly, or call list_templates to find one by name. Omit version to use the latest version. Returns asset ID, URL, and format information in item; include_image_data requests an inline preview, and include_file returns the output as an embedded binary resource. Use create_template to save a new reusable design before rendering it.

Input Schema

Name	Required	Description
`version`	No	Template version to render. Pass item.template_version from create_template or update_template, or an entry's version from list_template_versions. Omit to use the latest version.
`template_id`	Yes	Exact template ID: use item.template_id from create_template or update_template, or an entry's id from list_templates. When only a name is known, resolve it with list_templates first.
`include_file`	No	Eagerly render and include up to 10 MiB of the original output, including PDFs, as an MCP embedded resource with uri, mimeType, and base64 blob fields. This takes longer; the asset URL remains available if the file cannot be included. Deferred renders cannot include file data. Enable only when file bytes are needed; combine with include_image_data only when both representations are needed.
`template_values`	Yes	JSON object keyed by template variable names without braces: for {{title}}, pass {"title":"Example"}. Supply every required value and preserve the variable names' casing.
`include_image_data`	No	Eagerly render and include up to 10 MiB of image data for an inline preview. This takes longer and reports progress when the client supports progress notifications. Successful stored renders also return a URL that can be opened or embedded outside the MCP context. Use only when the user requests or needs an inline preview.

Output Schema

Name	Required	Description
`item`	No	Operation result. Check success before using this value.
`error`	No	Error details when the operation failed; null on success.
`success`	No	Whether the operation succeeded. If false, inspect error before retrying.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 4, 2026

changedInput schema / properties / include_file / description

Previous value: -"Eagerly render and include up to 4 MiB of the original output, including PDFs, as an MCP embedded resource with uri, mimeType, and base64 blob fields. This takes longer; the asset URL remains available if the file cannot be included. Deferred renders cannot include file data. Enable only when file bytes are needed; combine with include_image_data only when both representations are needed."New value: +"Eagerly render and include up to 10 MiB of the original output, including PDFs, as an MCP embedded resource with uri, mimeType, and base64 blob fields. This takes longer; the asset URL remains available if the file cannot be included. Deferred renders cannot include file data. Enable only when file bytes are needed; combine with include_image_data only when both representations are needed."

changedInput schema / properties / include_image_data / description

Previous value: -"Eagerly render and include up to 4 MiB of image data for an inline preview. This takes longer and reports progress when the client supports progress notifications. Successful stored renders also return a URL that can be opened or embedded outside the MCP context. Use only when the user requests or needs an inline preview."New value: +"Eagerly render and include up to 10 MiB of image data for an inline preview. This takes longer and reports progress when the client supports progress notifications. Successful stored renders also return a URL that can be opened or embedded outside the MCP context. Use only when the user requests or needs an inline preview."

Changed1 schema field changedNov 4, 2026

addedInput schema / properties / include_file

Added value: +{
+  "default": false,
+  "description": "Eagerly render and include up to 4 MiB of the original output, including PDFs, as an MCP embedded resource with uri, mimeType, and base64 blob fields. This takes longer; the asset URL remains available if the file cannot be included. Deferred renders cannot include file data. Enable only when file bytes are needed; combine with include_image_data only when both representations are needed.",
+  "type": "boolean"
+}

Changed6 schema fields changedSep 15, 2026

changedInput schema / properties / template_id / description

Previous value: -"The exact template ID to render. When only a name is known, resolve it with list_templates first."New value: +"Exact template ID: use item.template_id from create_template or update_template, or an entry's id from list_templates. When only a name is known, resolve it with list_templates first."

changedInput schema / properties / template_values / description

Previous value: -"Values keyed by the template's {{VARIABLE}} placeholders. Supply every value required for the requested render."New value: +"JSON object keyed by template variable names without braces: for {{title}}, pass {\"title\":\"Example\"}. Supply every required value and preserve the variable names' casing."

changedInput schema / properties / version / description

Previous value: -"The version of the specified template, if not provided, it will default to the most recent version."New value: +"Template version to render. Pass item.template_version from create_template or update_template, or an entry's version from list_template_versions. Omit to use the latest version."

addedOutput schema / properties / error / description

Added value: +"Error details when the operation failed; null on success."

addedOutput schema / properties / item / description

Added value: +"Operation result. Check success before using this value."

addedOutput schema / properties / success / description

Added value: +"Whether the operation succeeded. If false, inspect error before retrying."

First observedSep 15, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already flag the write behavior (readOnlyHint=false, idempotentHint=true, destructiveHint=true), and the description adds genuine context beyond them: the response carries an asset ID, URL, and format in 'item', include_file embeds the binary as an MCP resource, and include_image_data triggers a slower eager render with progress notifications. It does not explain why destructiveHint is true for an image-creation call, which is the one behavioral note an agent might want.

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?

Four tight sentences, front-loaded with the core action and followed by dependency resolution, option behavior, and a sibling cross-reference. Minor redundancy where it echoes schema text on the 'omit version' default, but no wasted framing or filler.

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 5-parameter tool with nested template_values, full schema coverage, an output schema, and rich annotations, the description covers the action, the required inputs, the template-resolution path, and the two eager-render options. 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.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents every parameter in detail, including the 10 MiB cap, deferred-render caveat, and version resolution. The description mostly restates this ('Omit version to use the latest version') and adds only a light gloss on template_values. Baseline 3 applies when the schema does the heavy lifting.

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?

The first sentence names a specific verb and resource ('Creates an image from a saved template') and explains the variable mechanism ('template_values for its variable substitutions'). It separates itself from create_template ('save a new reusable design') and list_templates. It never distinguishes itself from the batch sibling create_batch_templated_images or create_image, which is the one residual ambiguity.

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 concrete routing advice: use a known template_id directly or call list_templates to resolve a name, and omit version to get the latest. It also tells the agent to use create_template first when the design doesn't exist yet and to enable include_image_data only when an inline preview is needed. No explicit guidance on when to prefer this over the batch variants.

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

All HTML/CSS to Image API tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.