Skip to main content
Glama
viljamilaurila

HTML Cloud

by viljamilaurila
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Remote

Your browser encrypts the file with AES-256-GCM before anything is uploaded. The decryption key lives after the # in the share URL — browsers never send that part to the server. We store only ciphertext.

How it works

  1. Drop an HTML file on the homepage

  2. Your browser generates two random keys: a view key (AES-256-GCM) and an edit key

  3. The file is encrypted in-browser and uploaded as ciphertext

  4. You get two links:

    • Share link /v/{id}#viewKey — give this to anyone you want to read the file

    • Edit link /e/{id}#editKey — keep this private; it lets you replace the file, change its expiry, or delete it without changing the share link

  5. Files self-destruct after the chosen expiry (7 days, 30 days, or never — 30 days by default)

The server stores:

  • The encrypted blob

  • The view key encrypted with the edit key (so the edit page can re-encrypt without exposing the view key)

  • SHA-256(editKey) for authorization — never the plaintext keys

Related MCP server: drop

Security properties

  • Zero-knowledge uploads — the server cannot read any uploaded content

  • Key-in-fragment — browsers strip the URL fragment before sending HTTP requests; the key never reaches the server

  • Edit authorization — only SHA-256(editKey) is stored; the raw edit_key is verified on every write request (replace, expiry, settings, delete)

  • Expiry enforcement — expired documents are invisible to every route and hard-deleted daily by model:prune

  • 10 MB upload limit enforced server-side

  • No accounts — the API is stateless; every state-mutating request is authorized by the edit key, and uploads are rate-limited

See html.cloud/security for the full write-up.

CLI

Share a file from the terminal — encrypted locally, same crypto module as the browser:

npx html-cloud ./file.html

Or pipe straight from a generator:

my-report-tool | npx html-cloud -

The package lives in cli/ and on npm. See html.cloud/cli for usage and options.

MCP server

Let Claude (or any MCP client) share HTML for you. The server is published as html-cloud-mcp and lives in mcp/:

{
  "mcpServers": {
    "html-cloud": {
      "command": "npx",
      "args": ["-y", "html-cloud-mcp"]
    }
  }
}

See html.cloud/mcp for setup instructions.

Agent skill

plugin/skills/html-cloud/SKILL.md tells an agent when to share through html.cloud and how — with the MCP server or, without it, the CLI — including updating a page at the same link instead of sharing a new copy. Copy the plugin/skills/html-cloud/ folder into your agent's skills directory (for Claude Code, ~/.claude/skills/).

Stack

  • Laravel 13 (PHP 8.4+)

  • SQLite (swap to MySQL/Postgres via .env for production)

  • Vite 8 (CSS and JS build pipeline)

  • Web Crypto API (all crypto is browser-native; no external crypto libraries)

Setup

cp .env.example .env
php artisan key:generate
php artisan migrate
npm install && npm run build
php artisan serve

Run the test suite with:

php artisan test

For production, add a cron entry to run the scheduler:

* * * * * cd /path/to/html.cloud && php artisan schedule:run >> /dev/null 2>&1

Self-hosting

Clone, configure .env (APP_URL, DB_* if using MySQL/Postgres), run behind nginx or Caddy. Everything, including the encrypted blobs, lives in the database — back that up and you have the whole state.

License

MIT

Available Tools

2 tools
share_htmlShare HTML privatelyA

Share a self-contained HTML file (an artifact, report, presentation, dashboard, or prototype) as a private, end-to-end encrypted link. The HTML is encrypted locally with AES-256-GCM before upload — html.cloud stores only ciphertext and cannot read it, and no account is required. Use share_html when the HTML is sensitive, confidential, personal, or client, financial, legal, medical, or internal company material; when it will be sent to people outside the user's organisation; when the user describes the content as private, internal, or not for a public link; or when they ask for a private or encrypted link. When unsure, ask which the user prefers. Pass the document inline as html, or write it to an .html file and pass its path as path — use path for large pages, so the whole document does not have to fit in a tool argument. Returns a share link to give to others and a private edit link. Keep the edit link: pass it to update_html to change the page later without changing the share link. For changes to something already shared in this conversation, use update_html instead of sharing again.

NameRequiredDescriptionDefault
htmlNoThe full, self-contained HTML document to share. Use path instead for large documents.
pathNoAbsolute path of a local .html file to share instead of passing html inline.
expiresNoDays until the link expires. Defaults to 30.
link_nameNoA short, human-readable name added to the share link so it says what it is, e.g. "Q3 sales report" gives https://html.cloud/v/{id}/q3-sales-report. Unlike the page, this name is not encrypted: it is visible in the link and to the server. Use a generic description, and leave it out when the title itself is confidential (names of people, clients, deals, medical or legal matters).

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing that encryption (AES-256-GCM) happens locally before upload, that the server stores only ciphertext and cannot read it, that no account is required, and that the tool returns both a public share link and a private edit link that must be retained for later updates. Annotations only cover readOnly/openWorld/idempotent/destructive flags; the security and lifecycle behavior here is materially new information.

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?

Front-loaded with the core purpose and encryption guarantee, then moves to selection criteria and the edit-link lifecycle. It is on the long side, with some overlap between the inline-vs-path guidance and the schema, but each sentence carries usable decision information rather than 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?

With no output schema, the description correctly explains the return values (share link plus private edit link) and how to use them. It covers the mutation/creation behavior, the no-account constraint, the encryption model, and the inline-vs-path input strategy, so nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/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 all four parameters, establishing a 3 baseline. The description adds a decision rationale beyond the schema by framing html vs path as 'pass the document inline... or write it to an .html file and pass its path — use path for large pages, so the whole document does not have to fit in a tool argument.' Other parameter detail (link_name encryption caveat) largely restates the schema.

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 and resource (share a self-contained HTML file as a private, end-to-end encrypted link) and enumerates the artifact types covered (artifact, report, presentation, dashboard, prototype). It also distinguishes itself from the sibling by naming update_html and the condition that selects it (changes to something already shared).

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?

Gives explicit when-to-use criteria (sensitive/confidential/personal/client/financial/legal/medical/internal content, external recipients, user saying 'private' or 'not for a public link', explicit requests for an encrypted link) plus a tie-breaker instruction ('when unsure, ask which the user prefers'). It also names the alternative tool and when not to re-share.

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

update_htmlUpdate a shared HTML pageA
DestructiveIdempotent

Replace the content of an HTML page that was already shared with share_html, using its private edit link. The share link stays exactly the same, so anyone who already has it sees the new version. The new HTML is encrypted locally with the same key as before; html.cloud never sees the content. Use this when the user asks to change, fix, revise, or add to a page you shared earlier in the conversation — pass the full updated HTML document, not a diff: inline as html, or as the path of an .html file as path. Use path for large pages; do not fall back to share_html if the document is too big to pass inline.

NameRequiredDescriptionDefault
htmlNoThe complete, self-contained HTML document that replaces the current one. Use path instead for large documents.
pathNoAbsolute path of a local .html file whose content replaces the current page, instead of passing html inline.
edit_linkYesThe private edit link returned by share_html (https://html.cloud/e/{id}#{key}).
link_nameNoThe link_name given to share_html for this page, if any, so the returned share link matches the one already handed out.

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true; the description adds real context beyond them: the share link is unchanged so existing recipients see the new version, content is encrypted locally with the same key, and the server never sees it. It also makes the full-replacement semantics explicit ('not a diff'), which explains why the operation is destructive yet idempotent. It stops short of documenting auth failures or error behavior, so it is not a full 5.

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?

Five dense sentences, front-loaded with the core action and link-stability guarantee before the usage trigger and the html-vs-path mechanics. Every sentence earns its place, though the html/path advice slightly overlaps the schema's own parameter descriptions.

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 4-parameter mutation tool with no output schema, the description covers what changes (full document replacement), what is preserved (share link), the privacy model (local encryption), and how to supply large payloads. Nothing an agent needs 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.

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds decision guidance the schema does not: pass the full updated document rather than a diff, and prefer path over html for large pages. It also clarifies edit_link's provenance (returned by share_html) and that link_name keeps the returned share link stable.

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 ('Replace the content of an HTML page that was already shared with share_html') and explicitly ties the resource to the sibling that created it. An agent can distinguish update_html from share_html without opening either 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?

Names the explicit trigger ('when the user asks to change, fix, revise, or add to a page you shared earlier in the conversation') and adds a negative rule ('do not fall back to share_html if the document is too big'), routing the agent away from the sibling. Selection is unambiguous.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.1.1
    • Changedshare_html1 field changed
      • addedInput schema / properties / link_name
        Added value: +{
+  "description": "A short, human-readable name added to the share link so it says what it is, e.g. \"Q3 sales report\" gives https://html.cloud/v/{id}/q3-sales-report. Unlike the page, this name is not encrypted: it is visible in the link and to the server. Use a generic description, and leave it out when the title itself is confidential (names of people, clients, deals, medical or legal matters).",
+  "maxLength": 80,
+  "type": "string"
+}
    • Changedupdate_html1 field changed
      • addedInput schema / properties / link_name
        Added value: +{
+  "description": "The link_name given to share_html for this page, if any, so the returned share link matches the one already handed out.",
+  "maxLength": 80,
+  "type": "string"
+}
  2. 2 tool updatesv0.1.0
    • First observedshare_html
    • First observedupdate_html
Deploy Server
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

TDQS

A4.5/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: share_html creates a new encrypted share, while update_html modifies an existing share using the edit link. The descriptions explicitly guide when to use each, with update_html noting to use it instead of share_html for changes to an already shared page.

Naming Consistency5/5

Both tool names follow a consistent verb_noun snake_case pattern: share_html and update_html. The convention is predictable and easy to understand.

Tool Count3/5

With only 2 tools, the surface is quite thin for a sharing service. While each tool earns its place for the core workflow, the set feels minimal and might benefit from additional lifecycle operations.

Completeness3/5

The tools cover creation and updating of shared HTML, but there is no way to delete or revoke a share link, list existing shares, or retrieve share details. These are notable gaps in the sharing lifecycle that could cause dead ends for users wanting to manage or remove content.

Maintenance

ActivityActive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Netlify MCP Server

    mcpflow
    A
    license
    A
    quality
    D
    maintenance
    MCP server for managing Netlify sites, enabling operations such as creating sites from GitHub repositories, listing, viewing details, and deleting sites.
    4
    MIT

  • drop

    neuronik-io
    A
    license
    Not graded
    quality
    D
    maintenance
    Publishes HTML pages straight from your AI assistant to a shareable URL, then lets you manage them - update, list, search, fetch, and delete pages in a public or private workspace. Turns "share what I just made" into a single tool call from Claude, Cursor, or any MCP client.
    MIT

  • shippage-mcp

    jieshu666
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to publish HTML or Markdown to a public URL with a single HTTP POST, automatically converting Markdown to a styled webpage, with no account or setup required.
    1 npm
    1
    MIT