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
The MCP tool catalogue: everything your agent can do
Connect an AI agent to Zinn Digital® and it gets a real hosting toolkit — eleven 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.
- 11tool categories in the catalogue
- 3MCP primitives: tools, resources, prompts
- OAuth 2.1scoped, per-tool, revocable access
- 100,000+PBN sites hosted across every niche
One catalogue, not a plugin surface
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.
New capability arrives automatically
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.
Versioned, with capability discovery
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.
The same identity, the same audit trail
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.
The eleven categories
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.
Sites
List and create sites from a blueprint, by migration, or by Wayback Machine restore. Clone to staging, push to live, restart, purge cache, take a static snapshot, delete.
Code and files
Read and write files, run wp-cli, connect a git repository, deploy and roll back through the CD pipeline. This is the path that makes "the agent builds, pushes, and the platform deploys" a single conversation.
Domains, DNS and SSL
Search for a domain, register it, edit DNS records, and issue or renew certificates — the full domain lifecycle without leaving the agent.
Database
Guarded queries, optimisation, backup and restore. Database access through MCP is deliberately guarded rather than open — the agent works within bounds, not with a raw console.
Configuration
PHP version and extensions, environment variables, cron jobs and worker settings. "Bump PHP to 8.3 on staging and re-run the test suite" is one instruction.
Backups
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.
SEO
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.
Observability
Metrics, logs, uptime and errors. This is what turns "the site feels slow" into a diagnosis, because the agent reads the real signals before it proposes a fix.
Billing and commerce
Read plan, usage and invoices; buy add-ons and Extras as guarded actions. Anything that spends money requires confirmation — see the guardrails below.
Support
Create a ticket, search the knowledge base, and run pre-ticket triage and self-heal — the same live diagnostic our own assistant runs before a human is ever involved.
Resources and Prompts: context before action
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.
Resources — read-only context
Site health and configuration, recent logs, metrics, uptime, knowledge-base articles, account and usage data. The agent fetches real state with no side effects, so it diagnoses from evidence rather than from your description of the symptom.
Prompts — published workflows
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.
Triage that ties the two together
Our pre-ticket triage flow — check uptime, HTTP and PHP errors, SSL and DNS state, resource limits, malware flags, plugin conflicts, database health and cache — is available to your agent through the same surface, so it can run the diagnosis before it opens a ticket.
Guardrails, because this is live infrastructure
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.
Scopes and RBAC
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.
Per-tool, revocable tokens
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.
Destructive-action confirmation
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, spend caps and idempotency
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.
Full audit log
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.
Your models, your keys
The catalogue is model-agnostic. MCP is the connector; which model drives it is your decision, and so is who pays for the tokens.
- Bring your own keys — your Anthropic, Google, OpenAI or image-generation credentials live in our Vault credential store, and you pay your own AI costs directly to the provider.
- The model registry is data, not code. Providers, models and capabilities are an admin-editable, auto-synced list, so a new model becomes selectable without waiting for us to ship a release.
- All inference and embedding calls ride the AI gateway, which handles caching, provider fallbacks, rate limits and cost analytics on the way through.
- The same foundation drives AI automations — scheduled recipes such as auto-blog, image generation, alt-text and SEO rewrites — with optional human approval before anything publishes.
- Nothing here is exclusive to our own assistant. The in-dashboard AI, the web code editor, the CLI and your external agent all ride the identical API and action catalogue.
Built to be driven hard
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. Direct file editing and deployment work the same way.
FAQ
What can an agent actually do — is this a read-only integration?
It is a full action catalogue, not a viewer. Eleven categories are exposed: sites, code and files, domains/DNS/SSL, database, configuration, backups, email, SEO, observability, billing and commerce, and support. That includes creating sites, cloning to staging, pushing to live, running wp-cli, deploying and rolling back, registering domains, editing DNS, issuing certificates, restoring backups and opening tickets — all subject to the connected identity's permissions.
Can an AI agent do something destructive by accident?
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.
Do I need a separate integration for each AI tool?
No. We implement the protocol rather than individual apps, so any MCP-capable client connects to the same server. We publish one-click and paste-in configuration snippets for Claude Code, Cursor, ChatGPT and Claude Desktop, and clients that adopt MCP later work without changes on our side.
How do tokens and permissions work?
Your AI client authorises over OAuth 2.1 against your organisation. 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.
Which model does it use, and who pays for it?
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.
Does the agent see real data before it acts?
Yes — that is what MCP Resources are for. It can read site health and configuration, recent logs, metrics, uptime, knowledge-base articles and account usage with no side effects, then run our pre-ticket triage checks across uptime, HTTP and PHP errors, SSL and DNS state, resource limits, malware flags, plugin conflicts, database health and cache before proposing a change.
Can I try it without paying?
You can start on a card-free 7-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.
Related
Point your agent at the whole catalogue
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 7-day trial — no payment details required.
Start free