Why we built MCP-first hosting

A year ago the loop looked like this.

Build fails. You open the hosting dashboard in a new tab. You scroll to the right deploy. You find the log. You copy a chunk of it. You paste it into Claude Code. You wait for a suggestion. You apply it. You redeploy. You wait. If it fails again, you start over.

The assistant was helpful. But it never actually saw the platform. It saw the scraps you carried back to it.

What MCP-first means here

MCP, the Model Context Protocol, lets an assistant call external tools. For a hosting platform, that means deploys, logs, env vars, domains, rollbacks, and account state can be exposed as structured tool calls instead of dashboard screens.

Plenty of hosts now have MCP servers. That is good for the ecosystem, but it makes "has MCP" a thin signal. The questions that matter are different:

• Can the assistant publish without leaving the coding loop?
• Can it inspect the actual failure, not a screenshot of it?
• Can it recover without the user playing courier?
• Does the tool surface cover operations, or just deployment lookups?

For Percher, MCP is not bolted onto a dashboard. It is the main interface. The dashboard exists, and people use it, but the platform is designed so an assistant can run the day-to-day loop end to end. Publish. Inspect. Set env vars. Roll back. Connect GitHub. Add a domain. Run doctor. The current surface is more than 60 tools.

The number is not the point. The point is that each tool returns a structured result, including a recovery.nextAction when the operation needs a follow-up.

The loop we wanted

A deploy fails. The assistant calls percher_doctor.

Doctor reads the build log or the runtime signal, classifies the failure, and returns the next step. Missing env var? It returns the exact keys. Bad config? It returns the config problem. Health check timeout? It points at the web port or the health path. Crash loop? It pulls the runtime log tail.

The user should not have to translate a platform error into a prompt. The platform already knows enough to say what should happen next, so it does.

This changes the product in a few concrete ways.

Fewer platform chores

On a dashboard-first host, you have to know where everything lives. Env vars are under one tab. Rollbacks are behind another. Logs are filtered through a search box that does not quite work the way you want. Custom domains are a four-step wizard you have done six times and still need to look up.

On an MCP-first host, you say "set the Stripe key", or "roll back the last deploy", or "redeploy without cache", and the assistant picks the right tool call. You never see the form.

This does not remove the need for a dashboard. It removes the dashboard from the hot path.

Smaller platform model

We also kept the infrastructure deliberately small. Percher runs in one region, behind one Caddy instance, with one route table and one place to look for logs. Multi-region routing and edge functions are real features for real use cases, but they make the recovery model harder to reason about.

For this product, a small operational model is a feature. The assistant can hold the whole system in its head: one app, one container, one deploy, one health check, one rollback chain.

Typed failures instead of prose

Every API error carries a code. REQUIRED_ENV_MISSING. DEPLOY_RATE_LIMITED. DAILY_QUOTA_EXCEEDED. BUILD_FAILED. Those codes map to a small set of recovery actions: set_env_vars, wait_deploy, run_doctor, retry, fix_config, fix_problems, ask_user, and a handful of others.

That means the assistant does not need to parse "please set OPENAI_API_KEY and try again" out of a sentence. It gets this instead:

``json { "nextAction": "set_env_vars", "args": { "keys": ["OPENAI_API_KEY"] } } ``

That is the core design choice. Error messages are for humans. Recovery payloads are for tools.

What we are not trying to be

Percher does not have multi-region deploys, edge functions, built-in cron jobs, serverless scale-to-zero, SOC 2, or an uptime SLA. Those are valid requirements, and if you have them, you should use a platform built for them.

Percher is for the other category. Personal apps. Side projects. Internal tools. The things you build for yourself or for people close to you. The trade is simple infrastructure, flat pricing, and an operations loop your assistant can actually drive.

That is the reason for MCP-first hosting. Not because MCP is the current shiny thing, but because it lets the platform tell the assistant what to do next, instead of making the user shuttle screenshots between tabs.