MCP-for-hosting: the 9-tool checklist for AI-native deploys

MCP-for-hosting is the application of the Model Context Protocol to website deployment and editing. It gives the AI agent nine structured tools (ship, patch, rollback, get_current_site, read_file, write_file, delete_file, list_files, init) so it can deploy and edit a live site from the chat without driving a terminal or a git workflow. This is the vendor-agnostic checklist for evaluating any host that claims to be "AI-native."

If you are choosing a host for the AI workflow in 2026, these are the nine MCP tools it must expose. Anything less and the AI is doing manual work. Anything more and you are paying for surface area you do not need.

The 9-tool checklist

1. ship — Deploy a directory as a new version

What it does: Uploads a directory of files, runs the build if needed, and serves the result on the edge.

Required input: A directory path (local) or a list of files (remote).

Returns: deploy_id, live URL, build duration, files deployed.

Why it matters: This is the initial deploy. The AI cannot ship a site without it. The interesting question is whether it accepts a directory (the AI ships a built project) or a single call with a project ID (the AI is updating an existing project). Both shapes are valid; the first is more common for the first deploy, the second is more common for CI/CD.

2. patch — Update a single file in the live site

What it does: Replaces one file in the running production deployment. No full rebuild. Cache invalidation is automatic for affected URLs.

Required input: File path, new content (or find/replace), deploy_id to patch (defaults to live).

Returns: deploy_id, validation result, time-to-live in ms.

Why it matters: This is the iteration tool. The AI uses it 10-100x more than ship. Without patch, every AI edit is a full deploy and the workflow is broken. With patch, edits are 8 seconds and cost 0.1 deploys. The shape of this tool (whole-file replace vs find/replace vs both) is the single biggest UX differentiator between AI-native hosts.

3. rollback — Restore a previous deploy

What it does: Reverts the live site to a previous deploy_id. Atomic, instant, free.

Required input: deploy_id to roll back to.

Returns: New deploy_id for the rolled-back state, time-to-live in ms.

Why it matters: Every AI edit is a one-way door without rollback. With rollback, the AI can experiment freely because every change is reversible. The 4-second rollback time is what makes "revert that" a viable chat interaction. If rollback takes 30+ seconds, the user would rather commit to a change than revert it.

4. get_current_site — List all live files

What it does: Returns the list of files in the live deployment with their paths, sizes, and last-modified times.

Required input: None (or a path prefix to filter).

Returns: Array of { path, size, last_modified, deploy_id }.

Why it matters: The AI needs to know what is deployed before it can edit. Without this tool, the AI is working blind — it might overwrite a file that has been deleted, or try to patch a file that does not exist. The structured response is what lets the AI reason about the current state of the site.

5. read_file — Read a single live file

What it does: Returns the contents of one file in the live deployment.

Required input: File path.

Returns: File content (UTF-8 string or base64 for binary).

Why it matters: The AI needs to read the live version of a file, not a cached local copy. The live version is the source of truth — the local copy might be stale. The MCP tool gives the AI direct access to what users actually see, which is what it needs to make sensible edits.

6. write_file — Create or replace a file

What it does: Creates a new file or replaces an existing one in the live deployment.

Required input: File path, file content.

Returns: New deploy_id for the write, validation result.

Why it matters: The AI uses this when adding a new file (a new page, a new asset, a new script) without modifying existing ones. The semantic difference from patch is that write_file replaces the whole file and patch does a find/replace. Some hosts collapse these into one tool — fine — but the AI needs at least one path to add a new file.

7. delete_file — Remove a file

What it does: Removes a file from the live deployment. Cache invalidation for any URL that file affected.

Required input: File path.

Returns: Validation result.

Why it matters: Less common than write_file but still essential. The AI needs to be able to clean up — remove a page the user no longer wants, delete an unused asset, retire a redirect target. Without delete_file, the AI can only add to the site, never subtract.

8. list_files — List files in a directory

What it does: Returns the contents of one directory in the live deployment, recursively or shallow.

Required input: Directory path, optional recursive: bool.

Returns: Array of file paths (and directories, if not recursive).

Why it matters: The AI needs to navigate the site structure. get_current_site is the global view; list_files is the per-directory view. The recursive flag matters because the AI often wants to know the full file tree at once to understand the site shape.

9. init — Create a new project

What it does: Creates a new project, optionally with a starter template, and returns a project ID plus a default subdomain.

Required input: Project name, optional template (blank, blog, portfolio, landing).

Returns: project_id, default subdomain, framework hint.

Why it matters: The first step of any new site. The AI uses this when the user says "create a portfolio site for me." Without init, the AI is patching files in a project that does not exist yet. The starter templates matter for the first-deploy experience — a blank project means the AI has to scaffold everything from scratch.

Why this exact set

The nine tools cover the full lifecycle of a website: create (init), deploy (ship), iterate (patch, write_file, delete_file), inspect (get_current_site, list_files, read_file), and recover (rollback). Anything the AI needs to do to a website maps to one of these tools.

The set is intentionally minimal. Tools like set_env_var, add_domain, view_logs, manage_secrets are useful but not on the critical path for the AI workflow. They can be added without breaking compatibility, and they should be — but a host that claims to be AI-native must have these nine as the floor.

What the AI can do with all 9

Every AI interaction with a site maps to one or more of these tools. The flow feels like a real-time collaboration because the tools are fast (8s patches, 4s rollbacks) and structured (typed inputs/outputs, no shell escaping, no JSON-RPC plumbing).

How to evaluate a host's MCP story

Four questions to ask any host that claims to be AI-native:

1. How many of the 9 tools does it expose? Anything less than 7 is incomplete. Anything less than 9 means the AI is doing manual work somewhere.
2. Are the tools typed? Each tool should have a JSON schema for inputs and outputs. If the tool takes freeform strings, the AI cannot validate its calls and will make mistakes.
3. What is the time-to-live for patch and rollback? If patch takes more than 15 seconds or rollback takes more than 10, the chat interaction breaks.
4. What is the cost per patch? If patch costs the same as ship, the cost model is wrong and the AI will ration its iterations.

If the answer to all four is "9 tools, typed, 8s/4s, 0.1 deploy" — you have a real AI-native host. Anything less is a marketing claim.

How to build your own

If your host does not have a first-party MCP server, you can build one. The MCP spec is open and the SDKs are stable. A minimal wrapper for a host with an HTTP API is 200-500 lines:

1. Initialize an MCP server with the 9 tool definitions and their JSON schemas.
2. For each tool, write a handler that calls the host's HTTP API and returns the structured response.
3. Stdio transport is the simplest — the AI client spawns the server as a subprocess.
4. Authentication: read the host's API key from an env var and pass it in the HTTP request.

Most hosts that have an HTTP API can be wrapped in a day. The bigger question is whether the host's API supports patch (partial update) — if it does not, no MCP wrapper will give you 8-second patch deploys.

Try it

# Install the Krexel MCP server (has all 9 tools)
npm install -g krexel
krexel login
claude mcp add --transport stdio krexel -- krexel-mcp

# Verify the tools
claude mcp list
# Should show: krexel (9 tools)

Then in your AI:

"List the MCP tools you have for Krexel."

The response should list all 9. If it does, you have a real AI-native host.

Read more

• What is AI-native hosting? — the category
• Deploy from Claude Code in 60 seconds — the 9 tools in action
• How to let your AI edit a live site — the patch-deploy model
• Best static hosts for AI-built sites 2026 — host roundup