htmlkin.io

Publish a site

htmlkin_publish

Publishes a site on htmlkin.io and returns its public URL. Takes exactly one source: a ready HTML document (html_content) or the text files of a static site (files). For binary assets use a ZIP via the REST API or the browser. You can set a preferred subdomain, PIN protection and visibility.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "htmlkin_publish"
  }
}

Input Schema

Name	Required	Description
`pin`	No	4-digit PIN (0000–9999) that protects viewing the site. Optional.
`files`	No	Up to 20 text files and 2 MB of UTF-8 in total; a root index.html is required.
`comments`	No	Who can comment on selected text on the site: off — nobody; everyone — anyone signed in to htmlkin; team — the owner and the team, on the Business plan. Defaults to off.
`subdomain`	No	Preferred subdomain ({subdomain}.htmlkin.io): 3–63 characters a-z, 0-9, "-" (not at the edges). Not a URL or a file name. If taken, the error is subdomain_taken.
`visibility`	No	Who can open the site: public — anyone, search engines index it; link — anyone with the link, not indexed; team — the account's team members after signing in, on the Business plan; private — only the account owner after signing in. Defaults to public.
`html_content`	No	Full HTML document of the site (inline HTML, up to 30 MB; larger — ZIP via the REST API). Exactly one of html_content and files.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A3.9/5.0

Behavior3/5

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

No annotations exist, so the description carries the full burden; it does disclose the return value (public URL) and the main side-effect options (subdomain, PIN, visibility). It does not state authentication requirements, whether publishing overwrites or creates a new site when one already exists, or any rate/size constraints — meaningful gaps for a mutation tool with zero annotation coverage.

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

Conciseness5/5

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

Four short sentences: purpose and return value first, then the input-mode rule, then the workaround, then the optional settings. Nothing is repeated and nothing is padding.

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?

With six all-optional parameters, no annotations and no output schema, the description covers the essential input choice and the error/limit escape hatch but leaves the mutation profile underspecified — no auth requirement, no overwrite/idempotency behavior, no mention of what the URL response looks like beyond 'public URL'.

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 explains pin, files, comments, subdomain, visibility and html_content in detail; the description only summarizes that subdomain/PIN/visibility can be set. The one added nuance — the mutually exclusive html_content vs. files choice — is already stated in the schema, so this is baseline-level contribution.

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 specific verb and resource ('Publishes a site on htmlkin.io') plus the outcome ('returns its public URL'), and the two accepted input modes are named. This is clearly distinct from the sibling tools (get/update/delete/comments), so an agent can pick it 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 an explicit decision rule for the two source parameters ('Takes exactly one source') and an explicit exclusion with an alternative path for binary assets (ZIP via REST API or the browser). It does not say when to use this versus a follow-up update, or what prerequisites (account/auth) publishing requires, so it stops short of full routing guidance.

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

All htmlkin.io tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?