Publish HTML, Markdown, or remote URLs as shareable, expiring links — in a single tool call.
Publish raw HTML — send any HTML string and receive a unique subdomain-based shareable link
Publish Markdown — submit Markdown content rendered into a clean, styled reader page
Fetch and republish a remote URL — provide a URL and htmldrop will fetch and re-host it
Publish raw content — supports text/html, text/markdown, text/plain, application/json, text/csv, application/pdf, and image/*
Set a custom title — used for metadata and auto-generated Open Graph social preview cards
Control expiration (TTL) — set a custom number of days before the artifact expires (anonymous default: 7 days)
Password-protect artifacts — optionally require a password to view the published page
Use an owner key for higher limits — unlock higher rate limits and a longer default TTL (30 days)
Integrate with agent platforms — works with Claude, Cursor, Codex, and others via its MCP server
htmldrop turns any HTML, Markdown, PDF, or image artifact into a shareable link in seconds. Reports, dashboards, charts, demos — anything an agent (or a human) creates. Markdown/text/JSON render into a clean reader page; PDFs and images are served as-is. No git, no build, no dashboard.
Try it now: htmldrop.link — drag & drop an HTML file, paste HTML source, or POST to the API.
curl -X POST https://htmldrop.link/publish \
-H "Content-Type: application/json" \
-d '{"html":"<h1>Hello agents</h1>","title":"Demo"}'{
"url": "https://happy-otter-42.htmldrop.link",
"id": "...",
"subdomain": "happy-otter-42",
"expires_at": "2026-07-17T00:00:00.000Z"
}Every link gets its own subdomain, an auto-generated Open Graph preview card, and a TTL — shared artifacts don't live forever.
Related MCP server: dochost
The hosted MCP server lives at https://htmldrop.link/mcp (Streamable HTTP) and exposes
one tool: publish_html.
claude mcp add --transport http htmldrop https://htmldrop.link/mcpClaude Desktop speaks stdio, so bridge to the hosted server with
mcp-remote. In
claude_desktop_config.json:
{
"mcpServers": {
"htmldrop": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://htmldrop.link/mcp"]
}
}
}Cursor connects to a remote MCP URL directly. In .cursor/mcp.json:
{
"mcpServers": {
"htmldrop": { "url": "https://htmldrop.link/mcp" }
}
}In ~/.codex/config.toml:
[mcp_servers.htmldrop]
command = "npx"
args = ["-y", "mcp-remote", "https://htmldrop.link/mcp"]Running your own htmldrop? The htmldrop-mcp
package is a local stdio MCP server that publishes to your storage and
domain:
{
"mcpServers": {
"htmldrop": {
"command": "npx",
"args": ["-y", "htmldrop-mcp"],
"env": {
"BASE_DOMAIN": "your-domain.example",
"CLOUDFLARE_R2_ENDPOINT": "...",
"CLOUDFLARE_R2_ACCESS_KEY_ID": "...",
"CLOUDFLARE_R2_SECRET_ACCESS_KEY": "...",
"CLOUDFLARE_R2_BUCKET_NAME": "..."
}
}
}
}publish_html toolArgument | Type | Description |
| string | HTML content to publish (or use |
| string | Markdown content — rendered into a styled reader page |
| string | Remote HTML page to fetch and publish |
| string | Optional title for metadata and social cards |
| number | Days until the artifact expires |
| string | Optional password protection |
| string | Optional key for higher limits and longer TTL |
Full agent-facing docs live in AGENTS.md, also served at htmldrop.link/agents.md.
Endpoint | Body | Notes |
| JSON | Primary endpoint |
| raw body: | Title via |
| JSON | Fetches and republishes a page |
Pass an owner key in the x-htmldrop-key header for higher rate limits and a
longer default TTL. (x-pin-key is still accepted for backwards compatibility.)
git clone https://github.com/vin-spiegel/htmldrop.git
cd htmldrop
pnpm install
cp .env.example .env # defaults work out of the box
pnpm dev # http://localhost:3000The only variable you need to set is BASE_DOMAIN. Everything else has a
working default. Storage falls back to the local filesystem (./data) when no
object store is configured — no database required.
Variable | Default | Description |
|
| Base domain for artifact subdomains. The one value most self-hosters must set. |
|
| HTTP port (usually set by your host) |
|
| Set to |
| — | S3-compatible endpoint. Set all four R2 vars to use object storage; leave all blank for filesystem |
| — | Object-storage access key |
| — | Object-storage secret key |
| — | Bucket name |
|
| TTL for anonymous publishes |
|
| TTL for keyed publishes |
|
| Upload cap (25 MiB) |
|
| Per-IP rate limit |
|
| Per-owner-key rate limit |
Any S3-compatible store works for the CLOUDFLARE_R2_* variables (Cloudflare
R2, AWS S3, MinIO, …). On ephemeral/container hosts, either use object storage
or mount a persistent volume at ./data, or artifacts are lost on redeploy.
Production needs a wildcard DNS record (*.your-domain) pointing at the
server so artifact subdomains resolve.
railway login
railway init --name htmldrop
railway upThen set BASE_DOMAIN and (optionally) the R2 variables in the Railway
dashboard, and attach your domain plus its wildcard.
Artifacts are served with X-Robots-Tag: noindex, nofollow, noarchive
New HTML artifacts use a versioned CSP sandbox: inline scripts work, while external network requests/assets, forms, popups, and top-level navigation are blocked
Per-IP and per-key rate limits
Everything expires via TTL
Optional password protection per artifact
See SECURITY.md for vulnerability and abuse reporting.
pnpm dev # run with tsx
pnpm test # vitest
pnpm run build # tsc -> dist/Publish an HTML or markdown artifact (or fetch a remote HTML page) and get a shareable URL. Markdown is rendered into a clean reader page. Useful for sharing reports, dashboards, visualizations, or any document produced by an agent.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL of an HTML page to fetch and publish. Provide one of html, markdown, or url. | |
| html | No | HTML content to publish. Provide one of html, markdown, or url. | |
| title | No | Optional page title for the published artifact. | |
| markdown | No | Markdown content to publish; rendered into a styled reader page. Provide one of html, markdown, or url. | |
| password | No | Optional password protection for the artifact. | |
| ttl_days | No | Optional custom TTL in days. Anonymous tier defaults to 7 days. | |
| owner_key | No | Optional owner key for higher limits and ownership. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions the output (shareable URL) and that markdown is rendered, but it does not cover authentication, rate limits, content visibility, or effects of publishing the same content again. The description adds some context but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the core action and output. No superfluous words, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 optional parameters with oneOf constraint) and no output schema, the description adequately explains the result (shareable URL) and common use cases. It could mention that password and TTL are supported, but the schema covers those. Overall, it is fairly complete for a publishing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds value by noting that markdown is rendered into a clean reader page, but it does not provide additional meaning for other parameters beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: publish HTML, markdown, or a remote URL and get a shareable URL. It uses a specific verb 'publish' and identifies the resource types, with examples of use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides general use cases (sharing reports, dashboards, etc.) but does not specify when to use this tool over alternatives or exclusions. No sibling tools are listed, so the guidance is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0publish_htmlWith only one tool, there is no possibility of ambiguity. The tool's purpose is clearly defined and distinct by default.
With a single tool, naming is trivially consistent. The verb_noun pattern (publish_html) is clear and appropriate.
One tool is on the borderline of being too thin. While it may suffice for a simple publishing server, it feels minimal and could benefit from additional tools (e.g., list, delete).
The tool covers basic publishing and fetching, but lacks management capabilities like listing, updating, or deleting published content, which are notable gaps for a complete service.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Publish and manage secure HTML links: PII/secret scanning, batch create, patch edits, analytics.
Publish HTML & Markdown to shareable links with versions, comments, and project organization.
Publish self-contained HTML/SVG pages to private, shareable URLs and control who can view them.
Publish Markdown or HTML to a shareable link from your AI assistant. OAuth, no API keys.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/vin-spiegel/htmldrop'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
