AI tools are now pretty good at making complete HTML artifacts:
- a small portfolio page
- a product one-pager
- a pitch deck in HTML
- a resume
- a visual prototype
- a client preview
But after the model gives you the HTML, there is still an awkward last step:
How do I turn this into a real URL I can send to someone?
For developers, the normal answer is GitHub Pages, Netlify, Vercel, Cloudflare Pages, or an object-store flow. Those are good tools. But they are also a lot of ceremony when the artifact is just one finished HTML file.
For non-developers, the gap is even worse. They can ask ChatGPT to create a nice HTML page, but the result often stays trapped in a chat window or a local file.
The narrow problem
The use case I wanted to solve was not "deploy a website."
It was:
Publish one complete AI-generated HTML document as a shareable link.
That means:
- no repo required
- no build step
- no ZIP project
- no framework deployment
- no DNS setup
- optional access-key sharing for private previews
So I built FolioDrop around that narrow contract.
What FolioDrop does
FolioDrop accepts one complete single-file HTML document and returns a real URL.
It is intentionally smaller than a static host:
- Paste or upload one HTML work manually.
- Publish from an AI tool through MCP or OpenAPI.
- Save public works into a lightweight personal folio.
- Keep access-key protected works unlisted.
- Keep individual shared work routes out of search indexing.
The important boundary: FolioDrop is not a replacement for Vercel, Netlify, GitHub Pages, or Cloudflare Pages. If your project needs multiple files, a framework, a custom domain, or long-term production hosting, those tools are a better fit.
The comparison is here: FolioDrop vs static hosting.
Why MCP/OpenAPI matters here
The manual flow is useful, but the more interesting flow is agent-native publishing.
If an AI host can call a publish tool, the user can ask for:
Make this into a single-file HTML page and publish it.
The agent can then:
- generate the HTML
- validate that it is a complete document
- call the publishing endpoint
- return a URL
FolioDrop exposes:
- MCP endpoint:
https://foliodrop.app/mcp - public MCP config:
https://foliodrop.app/api/ai/mcp-config.json - OpenAPI description:
https://foliodrop.app/api/ai/openapi.json
I also packaged the publishing workflow as an open GitHub skill:
github.com/jaxxchen003/foliodrop-publisher-skill
That repo includes a single-file HTML validator and templates for decks, resumes, product one-pagers, emails, and portfolio case studies.
The publishing contract
The current contract is deliberately strict:
- include
<!doctype html> - include
<html>,<head>, and<body> - inline CSS in
<style> - inline JavaScript only when needed
- use public HTTPS URLs for external images or fonts
- do not include tokens, secrets, passwords, or local file paths
This constraint keeps the product predictable. It also makes the output easier for AI agents to reason about.
What I learned
The hard part was not generating HTML. The hard part was making the last mile boring:
- return a stable URL
- avoid leaking access keys
- avoid indexing private previews
- make deletion and expiry clear
- keep the product boundary honest
- give agents a structured way to publish without putting secrets into prompts
I wrote up two answer pages for the common questions:
The product is small on purpose. If the work is a real website, use a real static host. If the work is one complete AI-made HTML artifact and you just need a link, that is the gap FolioDrop is trying to close.