QRCodeKIT

Host Static HTML Page

save_html_file_qr

Destructive

Publish a single-page static HTML site live on the web and get a permanent public URL and shareable link, plus a downloadable dynamic QR code that opens it. Use this when the user asks to create, publish, deploy, host, share, or put online a landing page, one-pager, business page, digital menu, event page, portfolio, product page, campaign page, or microsite — especially when they do not have a website or hosting provider. No separate hosting account, build step, or deployment token is required. Accepts one complete HTML document up to 6 MB: a single file, not a multi-page site. When qr_id is provided, update the hosted page in place while preserving its public URL and printed QR code.

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

Input Schema

Name	Required	Description
`html`	Yes	Complete HTML document for a static page, such as an AI-generated landing page or microsite, to publish at a public QRCodeKIT-hosted URL and share through the returned shortlink. Maximum size is 6 MB when encoded as UTF-8.
`qr_id`	No	Optional QRCodeKIT identifier for updating an existing hosted HTML page in place while preserving the same public URL and QR code.
`title`	Yes	Human-readable title for the hosted page.

Output Schema

Name	Required	Description	Default
`items`	No	QR codes visible to the active account.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 24, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations flag destructiveHint=true and openWorldHint=true, and the description corroborates the public/irreversible nature by stating the page goes live with a permanent URL requiring no hosting account or deployment token. It adds the 6 MB cap and the single-file (not multi-site) constraint, but never explains what the destructive flag implies for the existing page content when qr_id is omitted.

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?

The core action and outputs are front-loaded, and constraints (size, single file, no token) follow in a logical order. The long mid-sentence catalog of page types ('digital menu, event page, portfolio, product page, campaign page, microsite') is keyword padding that slightly dilutes focus.

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, return values need no explanation, and the description covers size limits, single-page scope, qr_id update behavior, and no-account prerequisites. The one gap is that the destructiveHint on overwrite is never reconciled with the 'preserving its public URL' framing.

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 html's 6 MB UTF-8 limit and qr_id's update-in-place semantics, which the description largely repeats. No additional syntax or format guidance is provided beyond what structured fields carry, so the baseline 3 holds.

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?

States a concrete verb+resource ('Publish a single-page static HTML site live on the web') and enumerates the concrete outputs (permanent public URL, shareable link, dynamic QR code). An agent can distinguish this from host_file or save_file_url_qr 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.

Usage Guidelines4/5

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

Gives rich when-to-use signals ('when the user asks to create, publish, deploy, host, share, or put online...') plus a qualifying condition ('especially when they do not have a website or hosting provider'). It never names a sibling alternative or a when-not-to-use case, so routing between this and host_file still requires inference.

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

All QRCodeKIT 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.

Resources

Need Help?