Run Your Hosting From Your AI Tools: The Zinn Digital MCP Server

What an MCP server actually is

MCP — the Model Context Protocol — is the open standard for connecting AI agents to real systems. It is what turns a chat window into something that can act. Instead of us building a bespoke plugin for every AI app that exists and every one that appears next year, we support the protocol once and every compliant agent can use it.

An MCP server exposes three things. Tools are actions the agent can invoke — in our case, our full action catalogue: the exact same operations the dashboard and public API use, not a cut-down side channel. Resources are read-only context the agent can fetch before it acts: live site health, configuration, recent logs, metrics, uptime, account usage. Prompts are reusable workflow templates we publish, such as "diagnose this site" or "prepare a migration". Because the agent can read real state first and then act, it reasons about your actual sites, not a guess.

Workflow one — provision sites at scale

Provisioning is where the time goes, and where an agent earns its keep. The Sites tools cover the whole lifecycle: create from a blueprint, migrate an existing site in, restore from a Wayback snapshot, clone to staging, push to live, restart, purge cache, take a static snapshot, delete. Blueprints are the multiplier — a saved template of plugins, theme and configuration — so "add these forty domains, each from my affiliate blueprint, WordPress with these plugins, PHP 8.3" is one instruction, not forty sessions.

Because the platform runs long operations as durable, idempotent workflows underneath, a bulk provision that the agent kicks off will finish and self-heal on retry even if a step wobbles — it will not half-build a site and leave you guessing. The same catalogue lets an agent rebuild a lost site from an archived copy via /features/wayback-restore, or branch a live site into a safe copy through /features/staging before it changes anything. For our footprint-free line the agent also handles the network-specific setup — distinct IPs, CDN pool placement — that makes /hosting/footprint-free work at PBN scale.

Guardrails — an agent acting on live infrastructure

Handing an AI the keys to production is only sane with real controls, so they are built in, not bolted on. Every MCP action is bounded by the connected identity's scopes — the agent can only do what you can do. Destructive or costly operations — delete, suspend, billing changes, large spend — require explicit confirmation or a human-approval policy; the agent cannot quietly wipe a site or buy an add-on. Rate limits and spend caps constrain AI-triggered paid actions specifically, and retries are idempotent so a hiccup never double-charges or double-provisions.

Everything is logged. Every MCP call records the identity, the tool, the arguments and the result, feeding the same audit trail we keep for every privileged action. You can see exactly what your agent did, and revoke its token in one click if you change your mind. Staff use a separate internal MCP surface bounded by their own department role — the customer server never exposes ops tooling. Resellers get the same agent control across their client accounts via /hosting/agency, scoped by the tenancy hierarchy.

Frequently asked questions