Skip to main content
The Fluid MCP server, at https://mcp.fluid.app/mcp, has tools that read, create, deploy and roll back company Sites. An AI client such as Claude Code builds the Site on your machine, then deploys the build through these tools, with no Fluid CLI.
The Site write tools are for Fluid root admins only today, and they reach the production MCP server in a later release. Everyone else, and anyone who needs logs, traffic, env vars or the source saved in git, deploys with the Fluid CLI: fluid deploy.

​
Connect

Add the server to your client and sign in with your Fluid account when it asks. In Claude Code:
The sign-in screen says what the client may do. To let it use the write tools, tick Let this app make changes. The box is off by default. For how agents connect to Fluid, see Connect AI tools.

​
The tools

Every tool takes the company’s company_id. companies_list lists the companies you can reach.

​
Who can use them

  • Reads need an admin of the company whose role grants application_themes.view, or a Fluid root admin.
  • Writes need all of these:
    • you’re a Fluid root admin, in the pilot that gives root access through MCP;
    • the client is Claude Code or claude.ai;
    • you ticked Let this app make changes when you signed in, less than 7 days ago. After 7 days the client asks you to sign in again;
    • application_themes.update in the company. Root admins hold it.
Every tool needs Sites turned on for the company. Without them, a call answers sites_not_enabled. A client that may not use the write tools doesn’t see them in its tool list. Each write is logged with who made it, the client and the Site.

​
Create a Site

site_create makes a company Site that’s private and has nothing published. Always pass a handle: lowercase letters, digits and single hyphens, at most 40 characters. If the call times out, it may still have made the Site. Calling again with the same handle answers that the handle is taken, where a call with no handle would make a second Site. The tools only create company Sites. A member’s own Site is made with fluid sites create.

​
Deploy a built folder

The client builds the Site first, such as with npm run build, then deploys the build folder in two calls. 1. Send the manifest. Call site_deploy with site_id and files: each file’s path in the build, such as /index.html, mapped to its sha256 (hex), size in bytes and contentType. You can also send routes, and the Site’s schema, access and meta: the contents of db/schema.json, config/access.json and config/meta.json.
The answer has a bundle_id and uploads. 2. Upload the files. PUT each file listed in uploads to its URL, with exactly the headers it lists. Files Fluid already stores aren’t listed. 3. Publish. Call site_deploy again with the same site_id and the bundle_id, and no files. The answer has the Site’s live url. Publishing replaces what’s live. Limits:
  • At most 500 files a deploy, each up to 25 MiB. Deploy a larger build with fluid deploy.
  • An upload URL expires after 60 minutes. After that, start again from the first call.
  • A file the checks refuse comes back as refused, with a code, a message and the file’s path. Fix it and start again.

​
Schema changes that delete data

When the Site’s schema drops or rewrites a table or column, the publish call comes back refused with the code destructive_change_unconfirmed. It lists each migration id and, in words, what it would lose. Nothing is published. Show that to the person, and only after they say yes, call again with confirm_migrations set to those ids. See Change the schema.

​
What the client needs

The MCP tools don’t build anything or move file bytes. The client needs a shell, or another way to run the build, hash each file and send PUT requests to the upload URLs. Claude Code can. A chat client with no way to run commands or make HTTP requests can create a Site and change its visibility, but can’t deploy one. A deploy through MCP doesn’t save the Site’s source in git. fluid deploy and fluid sites publish do. See Source and branches.

​
Make it public

site_visibility_set with public lets anyone with the address open the Site. private leaves it to company admins and the members its shares admit. A new Site is private. See Who can open a Site.

​
Roll back

Call site_get to list the latest deployments, then site_rollback with the bundle_id of the one to bring back. It’s live at once, with no upload.

​
Plain HTML

A Site doesn’t need a framework. A published Site serves the Sites SDK at /_fluid/sdk/v1/sites.js, so a page with no build step can import it:
See Plain HTML.

​
Example in Claude Code

After connecting the server, ask in a project folder:
Claude Code scaffolds and builds the project, calls site_create, hashes the files in dist/, calls site_deploy with the manifest, uploads the listed files, and calls site_deploy again to publish. It answers with the Site’s address. To make it public, ask it to, and it calls site_visibility_set.