HTML/CSS to Image API

Create an Image

create_image

Destructive

Creates an image from supplied HTML and CSS. Use this for a single graphic, card, or document; use create_url_image to capture an existing web page, or create_template to save a reusable design. Set content.selector to crop to a specific element. Returns asset ID, URL, and format information in item. Set include_image_data only when an inline preview is needed, or include_file to return the output as an embedded binary resource.

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": {
      "content": "<content>"
    },
    "name": "create_image"
  }
}

Input Schema

Name	Required	Description
`content`	Yes	Self-contained image content and render options. For fixed-size artwork, use selector and give the selected element explicit dimensions.
`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.
`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"
+}

Changed1 schema field changedSep 29, 2026

addedInput schema / properties / content / properties / request_overrides

Added value: +{
+  "description": "An array of request rules. Use `action: \"block\"` with a `url` wildcard pattern (using `*`) and/or `resource_types` as an array of resource names, such as `image`, `script`, or `xhr`. Both matchers must match when supplied together; any matching block rule blocks the request. Omitted, `null`, or `[]` adds no overrides. Requires a paid plan. Accepts a JSON array in JSON requests or a JSON-encoded array string in form requests. Maximum 100 rules and 512 characters per URL pattern. Each block rule requires a nonempty URL pattern or at least one resource type; supplied matchers cannot be empty. Not supported in query strings.",
+  "items": {
+    "anyOf": [
+      {
+        "properties": {
+          "action": {
+            "const": "block"
+          },
+          "resource_types": {
+            "description": "Resource types to match, supplied as an array of names, such as image, script, xhr, or fetch. Any listed type may match. When url is also supplied, it must match too.",
+            "items": {
+              "enum": [
+                "beacon",
+                "document",
+                "stylesheet",
+                "image",
+                "image_set",
+                "media",
+                "font",
+                "script",
+                "text_track",
+                "xhr",
+                "fetch",
+                "event_source",
+                "manifest",
+                "ping",
+                "img",
+                "other"
+              ],
+              "type": "string"
+            },
+            "type": [
+              "array",
+              "null"
+            ]
+          },
+          "url": {
+            "description": "URL wildcard pattern to match, using * for any sequence of characters. When resource_types is also supplied, both matchers must match.",
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        }
+      }
+    ],
+    "description": "A browser request override. The action discriminator selects the rule type; currently only block is supported.",
+    "required": [
+      "action"
+    ],
+    "type": "object"
+  },
+  "type": [
+    "array",
+    "null"
+  ]
+}

Changed1 schema field changedSep 22, 2026

changedInput schema / properties / content / properties / disable_twemoji / description

Previous value: -"Use native Linux emoji rendering instead of HCTI's consistent Twemoji images. Leave `disable_twemoji` unset unless native emoji rendering is specifically needed."New value: +"Twemoji is enabled by default. Set `disable_twemoji: true` to disable automatic emoji replacement and use the supplied fonts or native emoji fonts instead. Omitted, `null`, or `false` keeps Twemoji enabled."

Changed3 schema fields changedSep 15, 2026

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.3/5.0

Behavior4/5

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

Annotations already declare the write/side-effect profile (readOnlyHint=false, destructiveHint=true, openWorldHint=true), so the description only needs to add context — and it does, disclosing that include_image_data/include_file take longer and that the asset URL remains available if embedded file data fails. It does not explain the destructive/overwrite implications or deduplication behavior, which is the main remaining gap.

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 sentences, front-loaded with the purpose/alternative routing before the parameter hints, so an agent gets the selection decision first. Minor redundancy with schema text on the selector and preview flags keeps it from a 5.

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

Completeness4/5

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 need not explain return values, yet it still names asset ID, URL, and format — leaving little ambiguity for a 3-parameter tool with nested content. The absence of any note on destructive/overwrite semantics is the one meaningful omission.

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 content.selector, include_image_data, and include_file in comparable detail. The description largely restates those descriptions ('Set content.selector to crop to a specific element') rather than adding new semantics, which is the expected baseline 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.

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 resource ('Creates an image from supplied HTML and CSS') and immediately distinguishes this tool from two named siblings, create_url_image and create_template. An agent can select it without opening any schema.

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

Usage Guidelines5/5

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

It gives explicit routing rules: use this for a single graphic/card/document, use create_url_image for an existing page, use create_template to save a reusable design. It also states the conditions for the optional preview flags ('only when an inline preview is needed').

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.