Your agent wrote the site. Let it publish the site.
harvis.dev is a remote MCP server. Connect it once and your AI client gains a deploy_site tool that puts a folder of files online and hands back a live address — no account, no API key, nothing to install.
A standard plug between an AI client and a service
Model Context Protocol is an open standard for handing an assistant a set of actions it can take. Your agent already has the files and knows what you asked for; what it lacks is a way to act outside the chat. An MCP server supplies that — a named list of tools, each described well enough that the model knows when to reach for one. harvis.dev publishes exactly one tool, and it publishes websites.
Connect the server once
A URL in your client's config file, or one command in the terminal. It stays connected across every conversation after that.
The model sees a tool, not an API
No endpoint to remember, no curl to assemble, no key to paste. It reads what deploy_site does and calls it when publishing is what you asked for.
You never leave the conversation
Ask for a landing page and get a live address back in the same reply. No export, no upload step, no build pipeline in between.
One URL, any MCP client
Streamable HTTP, no authentication. Clients with remote MCP support take the address as it is; stdio-only clients like Claude Desktop bridge through mcp-remote. Pick yours and copy the block.
https://harvis.dev/api/mcp
$ claude mcp add --transport http harvis https://harvis.dev/api/mcpOne tool, and it does one thing
deploy_site takes every file the site needs and publishes it. Paths are relative to the site root and use forward slashes; include an index.html. Text goes as it is, images and other binaries as base64.
| field | type | what it is |
|---|---|---|
| files | array · required | Every file of the site: a path, its content, and an encoding of text or base64. Up to 500 files and 50 MB in total. |
| name | string | A readable name for the site, shown in the dashboard. The web address is generated either way. |
| deployToken | string | A site's private token, returned by the deploy that created it. Passing it updates that site in place instead of creating a new one. |
| subdomain | string | The address of the site being updated. Optional, and only accepted alongside its deployToken — on its own it proves nothing, so it cannot authorize an update. |
A public link, and a private one
The tool returns text the model reads back to you. The live URL is public and ready to share. The claim link is private: open it, sign in free, and the site is attached to your account, where you can edit or delete it. Until then the site is anonymous, and an unclaimed site is reclaimed 24 hours after its last deploy — so open the claim link the same day, because it cannot be recovered if lost.
Site deployed successfully. Live site: https://happy-panda-482.harvis.dev Claim link (private): https://harvis.dev/claim/xxxxxxxx-... Subdomain: happy-panda-482 Deploy token (private): xxxxxxxx-xxxx-... Files hosted: 7
Deploy again to change the same site
Every deploy also returns a private deployToken. Hand it back on a later call and the same site is replaced in place, keeping its address — this works before and after you claim it. Leave it out and you get a new site at a new address, which is what you want for a second draft you'd rather compare than overwrite.
Questions
What people ask before they paste the config in.
Do I need an account?
No. The MCP server takes no credentials at all, and a deploy through it is anonymous — which is why it comes back with a claim link. Sign-up is free and only needed if you want to keep the site past 24 hours or manage it later.
Is my agent allowed to do anything else with this?
No. deploy_site is the only tool the server exposes, and it does nothing but publish files you gave it. It cannot read your account, list anyone's sites, or delete anything. Everything else on harvis.dev lives behind an account key on the HTTP API, which this server does not touch.
My client doesn't support remote MCP servers.
Then it speaks stdio, and mcp-remote bridges the two — the Claude Desktop and Zed blocks above are exactly that. It needs Node.js on your machine and nothing else; npx fetches the bridge on first run.
What can it host?
Static files: HTML, CSS, JavaScript, images, fonts, anything a browser can fetch. Server-side code is not executed. Forms are the exception — add the harvis-form attribute to a form and the submissions land in your dashboard with no backend of your own.
Can I use this without an MCP client?
Yes. An agent that can run commands publishes with npx harvis, and one that can only make HTTP requests can POST the files to /api/upload with no key. Both paths are written out at /llms.txt, which is the page to hand an assistant that has no tool for this.
No agent in the room?
The same deploy happens from your terminal, from a browser, or from a script — the MCP server is one door into it, not the only one.