No second implementation to drift
An MCP tool is an API endpoint. There is no parallel logic path that can fall behind the product, and no behaviour an agent can reach that the dashboard cannot.
AI & MCP
Connect an AI agent to Zinn Digital® and it gets a real hosting toolkit — twelve categories of actions covering sites, code, domains, DNS, SSL, databases, configuration, backups, email, SEO, observability, billing and support. Every tool is the same API endpoint the dashboard calls, gated by the same RBAC, written to the same audit log. Availability, updated 12 September 2026: sites (list, create, deploy, roll back), two-way sync with a git repository, site error and access logs and build logs, domains, DNS, email, cache, crawler policy, PHP version, WordPress core and plugins, backups, SEO and index status, metrics and usage, billing documents, the knowledge base and tickets, and reseller operations (your client services, holds, price list and client wallets) are LIVE over MCP today, together with Resources and Prompts. Still in active development and not yet reachable over MCP: domain registration and SSL issue/renew, guarded database queries, raw wp-cli and direct file editing, and — on the reseller surface — adjusting a client wallet, connecting a payment gateway, issuing a client sign-in link and publishing a dunning run. Each needs a priced, irreversible or credential-bearing action handled properly before an agent is given it. Everything else described here is live today.
The MCP server is a thin protocol adapter over the engine API. It does not reimplement anything — it exposes the action catalogue that already powers the dashboard, the CLI and our own AI assistant. Three consequences follow, and they are the whole design.
An MCP tool is an API endpoint. There is no parallel logic path that can fall behind the product, and no behaviour an agent can reach that the dashboard cannot.
The server is kept in sync with the API from the same OpenAPI and action-catalogue source. Everything we add to the platform becomes available over MCP without a per-tool integration on your side.
The server is versioned and publishes capability discovery with a deprecation policy, so an agent can ask what it is allowed to do rather than guess and fail.
Sessions are bound to org, user and scopes, with Postgres row-level security enforced underneath. An agent is not a special class of caller — it is your account, acting through a protocol.
This is the catalogue as specified. Every tool in it is gated by the connected identity's scopes — an agent can only reach what that identity may already do.
List sites, read one in detail, and create a site from a blueprint. Deploy it, follow the deploy, and roll back to an earlier release.
Sync a site's files with its connected git repository in both directions — commit what changed on the site, or deploy what was pushed — and settle a held sync by choosing which side wins. This is the path that makes "the agent builds, pushes, and the platform deploys" a single conversation. Raw wp-cli and direct file editing are not exposed to an agent yet.
List your domains, check whether a domain is indexed, and create, update and delete its DNS records. Registering a domain and issuing certificates are not exposed to an agent yet.
A site's backups include its database, and the agent can list them, take one and restore one. Direct database access — guarded queries and optimisation — is deliberately not exposed to an agent yet: there is no database tool on the server, and we would rather say so here than have you discover it from your agent.
Read and change a site's PHP version, and see and update WordPress core and its plugins. "Move this site to PHP 8.4 and update its plugins" is one instruction.
List, create and restore backups. An agent about to attempt something risky can take its own restore point first, then roll back to it if the change misbehaves.
Create and manage mailboxes and forwarders, provisioned through our mail driver — so the contact addresses on a site are handled in the same flow as the site itself.
Index status, rank data and audits, drawn from our SEO data layer. The agent can check whether a change actually landed in the index rather than assuming it did.
A site's error and access logs, its build logs, metrics and usage. This is what turns "the site feels slow" into a diagnosis, because the agent reads the real signals before it proposes a fix.
Read plan, usage and invoices; buy add-ons and Extras as guarded actions. Anything that spends money requires confirmation — see the guardrails below.
Create and list tickets and search the knowledge base, with a published triage prompt that walks the agent through checking a site before a ticket is ever opened.
If you resell our hosting, your own client estate is on the same surface: see every service you have provisioned, place and release a non-payment hold, read your price list with your wholesale cost beside it, and reconcile the client wallet balances you hold. Your clients' sites, driven from your agent — not ours.
Tools are only one of the three MCP primitives. The other two are what stop an agent acting blind, and they matter as much as the catalogue itself.
The practical effect is that a good agent session looks like an engineer's: read the logs, read the config, check the metrics, form a hypothesis, then act on one thing and re-check. The catalogue makes that possible in a single connection.
Your account, each site's summary and its health. The agent fetches real state with no side effects, so it diagnoses from evidence rather than from your description of the symptom.
Reusable templates we publish for the jobs people repeat: "diagnose this site", "prepare a migration". A common piece of work becomes one instruction instead of a remembered sequence of steps.
Our published triage prompt — the site's status, its traffic and error rate, the last deploy, its WordPress state and a knowledge-base search — is available to your agent through the same surface, so it runs the checks before it opens a ticket.
An agent with production access needs limits that are structural rather than advisory. Ours sit in the engine, underneath the protocol — an agent cannot negotiate its way past them.
The agent inherits the connected identity's permissions exactly. If your role cannot deploy, neither can your agent. Role permissions are enforced at the API, not filtered in the client.
Tokens are scoped and revocable per tool, with sandbox and test tokens kept separate from production. You grant one agent what it needs and revoke it without disturbing the others.
Delete, suspend, billing and large-spend actions require explicit confirmation or a human-approval policy before they execute. The agent proposes; a human — or a policy you set — decides.
Rate limits and per-customer spend caps bound AI-triggered paid actions, and operations are idempotent on retry, so an agent that repeats a request after a timeout does not repeat the effect.
Every MCP action is recorded with identity, tool, arguments and result. You can reconstruct exactly what the agent did, in what order, and on whose authority.
The catalogue is model-agnostic. MCP is the connector; which model drives it is your decision, and so is who pays for the tokens.
An agent catalogue is only useful if it responds at conversational speed while other people are hammering it. The MCP server is engineered for that from the start.
The server is stateless and horizontally scaled behind a load balancer, autoscaling on load, so many customers driving agents simultaneously does not create a serial bottleneck. Actions stream and are never parked behind a job queue — MCP is an interactive path, not a background one, and there are no artificial response caps.
Async I/O and connection pooling run throughout, and the AI gateway load-balances across provider keys with backoff and failover when a provider throttles. Long-running platform work still runs as durable, retryable workflows underneath, but your agent is never left waiting on a queue to hear back.
The deploy path is first-class rather than an afterthought: connect a GitHub or GitLab repository, push, deploy and roll back, all drivable by the agent on top of the same CD pipeline the dashboard uses. Two-way sync between the site and its repository works the same way.
It is a full action catalogue, not a viewer. Twelve categories are exposed: sites, code and files, domains/DNS/SSL, database, configuration, backups, email, SEO, observability, billing and commerce, support, and reseller operations. That includes creating sites, deploying and rolling back, syncing a site with its repository in both directions, reading logs, editing DNS, restoring backups, buying upgrades with confirmation and opening tickets — all subject to the connected identity's permissions.
The design is layered to make that hard rather than to promise it is impossible. An agent can only invoke what the connected identity is permitted to do; delete, suspend, billing and large-spend actions require explicit confirmation or a human-approval policy; rate limits and spend caps bound paid actions; retries are idempotent; and every action is audit-logged with identity, tool, arguments and result. We would still recommend a scoped, sandbox token while you learn how an agent behaves on your estate.
No. We implement the protocol rather than individual apps, so any MCP-capable client connects to the same server. The dashboard gives you the exact configuration for Claude Code, Claude Desktop and Cursor, and clients that adopt MCP later work without changes on our side. ChatGPT is the exception for now: it connects only by OAuth sign-in, so it cannot use a token.
Your AI client connects with a scoped connection token you mint in the dashboard, and the server publishes OAuth 2.1 protected-resource discovery (RFC 9728) pointing at our Keycloak identity provider. Every session is bound to org, user and scopes, with Postgres row-level security enforced at the database. Tokens are scoped, per-tool and revocable, and sandbox or test tokens are kept separate from production. A headless API-key option exists for automation that has no interactive user; API keys are issued per organisation with their own scopes.
Whichever you choose. You bring your own Anthropic, Google or OpenAI keys, stored in our Vault credential store, and you pay your AI provider directly. The model registry is admin-editable and auto-synced data rather than a hardcoded list, so new models become selectable as they appear.
Yes. It can read a site's error and access logs, its build logs, metrics, usage, health and configuration with no side effects, and our published triage prompt walks it through checking a site — status, traffic and errors, the last deploy, WordPress state and the knowledge base — before it proposes a change or opens a ticket.
You can start on a card-free 14-day trial of Footprint-Free Hosting, which covers up to five sites and needs no payment details. Paid plans carry a 30-day no-quibble money-back guarantee and free migrations of existing PBN sites.
Connect the AI tool you already use, scope it to exactly what it should touch, and let it work on real hosting with a full audit trail behind it. Start on a card-free 14-day trial — no payment details required.
Start freeEach of these plugins makes your WordPress site an MCP server, so Claude, Cursor, VS Code and other AI assistants can do real work on it, signed in as you and limited to what you are allowed to do.