Skip to main content
Glama
viljamilaurila

HTML Cloud

by viljamilaurila
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Remote

Share HTML privately

share_html

Publish a self-contained HTML file as a private, end-to-end encrypted link. The file is encrypted locally before upload, so sensitive reports, dashboards, or prototypes stay confidential.

Instructions

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.

Input Schema

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).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.1
    • 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"
+}
  2. First observedv0.1.0

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.

Deploy Server

Other Tools