AI tools now finish their work as a file. A report, a dashboard, a one-pager, a build — written in seconds, and then sitting on a disk where the person who needs it can't reach it. MCP closes that last gap: connect miinideck once as an MCP server and the tool that wrote the HTML can publish it itself, returning a private, unguessable, no-indexed link in the same breath. The part worth setting up for is what happens on the second revision — the agent replaces the contents of the page it already published rather than minting a new address, so the link you sent an hour ago is still the link, and it's showing the current version.
Try it now
Drop a file — get a private link in seconds. No sign-up.
Drop an HTML file or ZIP bundle, or click to choose.
Single file or ZIP. Max 3 MB.
Up to 3 MB, link self-destructs after 7 days. Sign up free to keep links forever, password-protect them, and store more.
Connect it once, in any client that speaks MCP. Authentication is your sign-in, not a key pasted into a config file — which means the tools can only ever reach pages on your own account, and there's no anonymous token that could let someone else publish under your name. Nothing to configure per project after that.
Ask for a link in plain language. The agent calls the create tool with the finished HTML and hands back an unguessable URL that carries a noindex meta tag and an X-Robots-Tag header, so it stays out of search results by default. The same call can set a password a viewer has to enter, set when the link expires, and file the page under one of your projects by name — the access controls are set at publish time rather than being something you go and add afterwards.
Then iterate. The update tool replaces the contents at the same URL, keeping the password, expiry, title, and project as you set them, and storing each replacement as a numbered version rather than overwriting history. Two limits worth knowing up front: HTML travels through MCP as text, which caps it around 100 KB in practice, and updating replaces content rather than changing a password or an expiry. For a larger file or a multi-file build, send the bytes with the CLI (npx miinideck deploy ./dist) or the web uploader — the address is unchanged either way.
MCP is a standard way for an AI tool to call an external service, so 'an MCP server for publishing HTML' just means the AI can hand a finished page to a host and get a URL back without you doing the upload yourself. Connect it once and publishing becomes something you ask for in the conversation — publish this, share this, get me a link for this — rather than a separate trip to a browser tab. The practical value isn't saving the upload; it's that the tool which knows the work changed is also the tool that can update the link.
Anything that speaks MCP. Claude Code is the most common place people hit this problem, because it produces finished files locally and then leaves you holding them, but the same connector works from any MCP-capable client. If your tool doesn't do MCP yet, the CLI and the web uploader reach exactly the same private link — you just trigger the publish yourself instead of asking for it.
It can set both when it publishes. The create call takes an optional password and an expiry alongside the HTML, plus a project name to file the page under, so a link can arrive already restricted rather than being open until you remember to lock it. One honest limit: the update call preserves the password and expiry you already set but doesn't change them — to rotate a password or move an expiry date, that's a dashboard action rather than something to ask the agent for.
Roughly 100 KB, because the HTML travels as a text argument through MCP rather than as an uploaded file. That's comfortably enough for a self-contained page, report, or dashboard, which is what agents usually produce. Past that — a heavy build, inlined images, a multi-file bundle — push the bytes with the CLI (npx miinideck deploy ./dist) or the web uploader instead, neither of which has that ceiling. If the page already exists, publishing the bigger version doesn't change its address.
The design assumption is that it isn't automatically safe, so the scope is deliberately narrow. Identity comes from your sign-in rather than from a shared key, the tools act as you and only on your own pages, and what they can do is publish, replace content on a page you own, and list your pages and projects. There's no delete verb, no access to anything you didn't publish through it, and no token to leak. If you'd rather see what's out there before trusting the loop, the list tool and your dashboard show the same set of pages.
You can, and for something meant to be public that's often the better answer. The difference shows up when the page is a deliverable rather than a publication: a deploy usually optimises for reach and a fresh URL per build, while a delivery needs the opposite — one address that stays put, no search presence, and controls aimed at the person opening it. The account layer is the other half of it: pages filed under projects, an access log for who opened what, and on Studio a custom domain with the branding removed.
No card to try, no sign-up to get a link. Sign up free to keep links forever, password-protect them, and store more.