Skip to main content
Glama
Sign In

APIVerve

by com.apiverve
OverviewDiscussionsAdmin

HTML to Image

HTMLtoImage
Read-only

HTML to Image: HTML to Image is an HTML to image API that renders HTML code into a high-quality PNG image. Paid plans add custom dimensions and JPEG or WebP output. (Cost: 20 credits)

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": {
      "html": "<html>"
    },
    "name": "HTMLtoImage"
  }
}

Input Schema

NameRequiredDescriptionDefault
htmlYesHTML code to convert
widthNoImage width in pixels
formatNoOutput image formatpng
heightNoImage height in pixels

Output Schema

NameRequiredDescriptionDefault
dataNo
errorNoError message, null on success
statusNo"ok" on success

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive, open-world), and the description adds genuinely new behavior: a 20-credit cost and the fact that custom dimensions and JPEG/WebP output are gated behind paid plans. It omits rendering behavior that matters for an open-world HTML renderer, such as whether external assets/scripts load or what invalid HTML does.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening 'HTML to Image: HTML to Image is an HTML to image API' is redundant with the name and title and wastes the most prominent position. The remaining two sentences are efficient, and the cost note is a useful front-loaded detail.

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

Completeness3/5

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

An output schema exists and the tool is structurally simple with a single required parameter, so the core is covered. For an open-world HTML renderer, though, an agent still lacks critical context: whether external resources, fonts, or scripts are fetched, and any size/time limits on the render.

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 coverage is 100%, so the schema already documents html, width, height, and format with defaults, making 3 the baseline. The description does not restate defaults or formats, and its 'paid plans add custom dimensions and JPEG or WebP output' line is ambiguous against a schema that exposes those parameters unconditionally, which could mislead rather than clarify.

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: it renders HTML code into a PNG image. An agent can tell this is HTML-string-to-image rather than a fetching/screenshot tool, though it never distinguishes itself from near-siblings such as MarkdowntoImage, WebsiteScreenshot, or HTMLtoPDF.

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?

Usage is only implied by the input type (you have raw HTML, you want a picture); there is no explicit when-to-use statement nor any exclusion pointing to the screenshot or PDF alternatives. The only real guidance is the plan/credit caveat, which is about cost rather than tool selection.

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

All APIVerve toolsInspect
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.

Resources