Yes, you can create a working WordPress site on your own server by describing what you want to an AI assistant connected to Panelica over MCP: it creates the domain, provisions the database, installs WordPress and issues the SSL certificate, using the panel's real API rather than a script that just pretends to. Below is an actual sequence of requests and the real actions each one triggers.
The setup
This walkthrough assumes Claude Code is already connected to a Panelica panel via the MCP server, as described in How to Manage a Web Server with Claude Code. The API key used for the session has write access to domains, databases and application deployment — enough to complete the task, nothing more.
The conversation
You: I need a WordPress site for a new client. Domain is example-client.com, already pointed at this server. Set it up with a fresh database and get SSL working.
The assistant does not guess at a plan out loud and stop — it starts calling tools. First, it checks whether the domain is already provisioned:
tool: domains.list
args: { search: "example-client.com" }
result: no matching domain foundThen it creates the domain under the appropriate hosting account:
tool: domains.create
args: { domain: "example-client.com", account_id: 41, php_version: "8.3" }
result: { id: 118, status: "active", document_root: "/home/client41/public_html" }Assistant: Domain example-client.com is provisioned on account 41 with PHP 8.3. Creating a MySQL database for WordPress now.
tool: databases.mysql.create
args: { account_id: 41, name: "example_client_wp" }
result: { database: "example_client_wp", user: "example_client_wp_usr", host: "localhost" }With the domain and database in place, it moves to the actual WordPress installation:
tool: apps.wordpress.install
args: {
domain_id: 118,
database: "example_client_wp",
db_user: "example_client_wp_usr",
site_title: "Example Client",
admin_user: "admin",
admin_email: "[email protected]"
}
result: { status: "installed", admin_password: "" } Assistant: WordPress is installed on example-client.com. Admin login is admin / [generated password shown once in this session — store it now]. Requesting an SSL certificate next.
tool: ssl.issue
args: { domain_id: 118, provider: "letsencrypt", force_https: true }
result: { status: "issued", expires: "2026-11-24", force_https: true }Assistant: Certificate issued and HTTPS is enforced. example-client.com is live with WordPress installed, a dedicated database, and a valid certificate that will auto-renew. Anything else — a specific theme, a staging copy, or a backup schedule?
What actually happened, step by step
| Step | MCP tool family | Real effect on the server |
|---|---|---|
| 1 | domains | Runs the panel's 9-step domain provisioning, creating vhost, DNS entries and the document root |
| 2 | databases | Creates a real MySQL database and a scoped database user |
| 3 | apps.wordpress | Installs WordPress core, wires up wp-config.php with the new database, and creates the first admin account |
| 4 | ssl | Requests a Let's Encrypt certificate through the panel's ACME integration and enables forced HTTPS |
Nothing here is simulated. Each tool call maps to a real endpoint in the panel's 406-endpoint External API — the same calls the dashboard itself makes when you click through the equivalent forms manually.
Why this is different from a shell script
A script that runs wp-cli commands over SSH can do part of this, but it has no concept of the panel's own account boundaries, quotas, RBAC or SSL state — it either has full root access or it does not work. The MCP-connected assistant instead operates through the panel's own authenticated, scoped API, so the same session that installed WordPress here could not, for example, touch a different customer's account unless the API key it is using was explicitly granted that scope. That distinction matters more the more of this kind of work you delegate to AI — see Is It Safe to Give an AI Access to Your Server? for how scoping is enforced.
What could have gone differently
If the API key used for this session had not included write access to SSL, the last step would have failed cleanly with a permission error instead of silently skipping the certificate — the assistant would have reported that domain provisioning, the database and WordPress succeeded, but that SSL issuance requires a broader key. That behavior is intentional: a scoped key fails loudly on what it cannot do, rather than quietly doing less than what was asked. It is also why scoping the key correctly before a session like this matters more than trusting the assistant to stay within bounds on its own.
Beyond WordPress
The same pattern applies to any of the panel's other application types — a Node.js API, a Python service, or a container from the Docker template catalog covered in Docker App Hosting for Resellers. The assistant is not running a WordPress-specific script; it is composing general-purpose tools — domain, database, application, SSL — toward whatever the request actually needs.
Try it yourself
If you already have Claude Code or another MCP client connected to a Panelica panel, this exact sequence of requests will work against a real domain today. If not, connecting takes one command — see How to Manage a Web Server with Claude Code.
Provision your next site by describing it. Connect an MCP client to your Panelica panel and try this walkthrough on a real domain. Source: github.com/Panelica/panelica-mcp. See features and pricing.