Requirements and responsibilities
Name the team, server, hostname, owner and affected users for the WordPress site. Record the current version and the actual business flow that must survive the change. Confirm the current dashboard form, plan eligibility, and server capacity before committing a resource change. A one-click catalog listing is discovery, not permission or proof that the connected MCP profile can install it.
xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · Manage WordPress core, themes and plugins · Site backups in xCloud · WordPress security hardening · WordPress roles and capabilities · Create WordPress pages · Manage WordPress plugins
Prepare a non-sensitive test input and an acceptance record. Keep access to the app administrator and an independent observer where possible; omit secrets from AI prompts and client reports.
xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · Manage WordPress core, themes and plugins · Site backups in xCloud · WordPress security hardening · WordPress roles and capabilities · Create WordPress pages · Manage WordPress plugins
For WordPress, verify the file and database backup scope and a safe target for recovery. Native scheduling, destination settings, staging synchronization and restore remain dashboard actions. Agree a maintenance window and owner before any action that interrupts the service or overwrites data.
xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · Manage WordPress core, themes and plugins · Site backups in xCloud · WordPress security hardening · WordPress roles and capabilities · Create WordPress pages · Manage WordPress plugins
Illustrative situation
A services firm has a new domain and a draft About page. Its owner wants a fresh WordPress site with a working administrator login and HTTPS before anyone adds forms or customer data.
Choose the approach
Use a production hostname only when DNS ownership and launch timing are agreed; a demo hostname is suitable for the first smoke test.
xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · Manage WordPress core, themes and plugins · Site backups in xCloud · WordPress security hardening · WordPress roles and capabilities · Create WordPress pages · Manage WordPress plugins
Choose a compatible NGINX or OpenLiteSpeed WordPress server. A Docker-only or single-site agentic server cannot take the WordPress creation operation.
xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · Manage WordPress core, themes and plugins · Site backups in xCloud · WordPress security hardening · WordPress roles and capabilities · Create WordPress pages · Manage WordPress plugins
Dashboard and application procedure
Follow these steps yourself, or use the scoped AI handoff below for supported hosting operations.
Step 1 of 5
Pin the site target
- Where
- xCloud Teams and Servers
- Permissions
- Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
- Inputs
- Team ID, target hostname, server stack, capacity
- Action
- Confirm the intended team and server in xCloud, record the stack and resource headroom, and check whether the domain is already attached to another site.
- Expected result
- An unambiguous eligible server and unused target hostname.
- Verify
- Reopen the server view and compare its ID with the change request.
- If it fails
- If the server is Docker-only or the hostname is in use, choose a different target before creation.
Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries
Step 2 of 5
Prepare first-run inputs
- Where
- DNS provider and xCloud Add Site
- Permissions
- Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
- Inputs
- DNS owner, site title, admin email, initial credential handoff
- Action
- Read the existing A or AAAA record and draft the required change for the DNS owner; choose a site title and credential recipient. Keep the password in a secret manager.
- Expected result
- A reviewed create-site form and DNS change request with an accountable administrator.
- Verify
- Check current public DNS and confirm the mailbox can receive the invitation or credential message.
- If it fails
- If DNS or mail ownership is unresolved, use a safe demo route and postpone production-domain claims.
Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries
Step 3 of 5
Create WordPress
- Where
- xCloud Add Site → WordPress or documented MCP create operation
- Permissions
- Authorized xCloud team/site operator with the discovered write scope for this exact operation and owner approval for its target and interruption.
- Inputs
- Approved team, server, domain and WordPress create inputs
- Action
- Create exactly one WordPress site using the displayed dashboard form or discovered MCP operation. Wait for the installation job to reach its terminal state and note the site ID.
- Expected result
- A reachable WordPress installation tied to the chosen host.
- Verify
- Check the site in xCloud and open wp-admin in a fresh browser session.
- If it fails
- If the job fails, inspect the phase and logs; do not submit a duplicate create request blindly.
Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries
Step 4 of 5
Publish and read the first page
- Where
- WordPress Pages editor and public browser
- Permissions
- Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
- Inputs
- Draft text, page slug, limited editor account
- Action
- Create a harmless page with a unique title, preview it, publish it, and open its permalink while signed out. Test an editor account without administrator rights.
- Expected result
- The public page and its media render at the expected permalink.
- Verify
- Compare the editor preview and signed-out page, and confirm no draft-only content leaked.
- If it fails
- If the page is missing, check permalink, cache and publishing state before changing DNS.
Sources: WordPress roles and capabilities
Step 5 of 5
Check HTTPS and recovery
- Where
- External browser and xCloud Site Backup
- Permissions
- Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
- Inputs
- Canonical hostname, certificate state, backup destination
- Action
- Open the page and admin login through HTTPS, inspect certificate name and redirects, then confirm a completed file-and-database backup or configure the first native backup in the dashboard.
- Expected result
- A first-run acceptance record and recovery point for future edits.
- Verify
- Record the final URL, certificate result, admin login result and completed backup timestamp.
- If it fails
- If SSL is pending, treat the page as a pilot until DNS and certificate checks pass; never label a queued backup complete.
Sources: Site backups in xCloud · xCloud agent capability boundaries
Maintenance
Review this task after app or template updates and at the cadence agreed with the owner. Record failures as dated observations rather than assuming host health proves service health.
xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · Manage WordPress core, themes and plugins · Site backups in xCloud · WordPress security hardening · WordPress roles and capabilities · Create WordPress pages · Manage WordPress plugins
Watch access changes, backup completion, free storage and external providers. Recheck integrations after credential, DNS, mail or source-data changes.
xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · Manage WordPress core, themes and plugins · Site backups in xCloud · WordPress security hardening · WordPress roles and capabilities · Create WordPress pages · Manage WordPress plugins
Recovery decisions
Before data recovery, identify incident time, completed backup, target and records created after the snapshot. Preserve current evidence and live data before replacement.
xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · Manage WordPress core, themes and plugins · Site backups in xCloud · WordPress security hardening · WordPress roles and capabilities · Create WordPress pages · Manage WordPress plugins
Use the documented dashboard or application recovery procedure with the authorized owner. Repeat the task-specific limited-user check; reconcile newer records before reopening writes.
xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · Manage WordPress core, themes and plugins · Site backups in xCloud · WordPress security hardening · WordPress roles and capabilities · Create WordPress pages · Manage WordPress plugins
AI handoff
Connect an authorized xCloud MCP profile and discover its exact tools and team scope. The packaged REST wrapper is GET-only; use dashboard or app controls for undocumented writes.
Supported scope
- Confirm requirements and inspect resources mcp · read
Discover the connected profile and operation schema first; only teams granted to the connection are visible.
Checkpoint: Confirm exact team, server and site identity. Use dashboard_url returned by the resource; do not invent a dashboard link.
Operation identifiers and scopes to discover
teams.index, servers.show, sites.show
Scopes: read:servers, read:sites
xCloud MCP documentation and connection profiles · xCloud agent capability boundaries
Copyable agent brief
Manual checkpoints
- Approve exact site, target, cost and any write or maintenance window after inspecting the proposed plan.
- An authorized WordPress administrator must configure and test app users, content, integrations and business rules in the app.
- Native WordPress staging, backup schedule/settings, push/pull and all restores are dashboard-only; Docker restore is dashboard-only and replaces state.
- Reconcile data created after the chosen recovery point before any destructive restore.
Feature coverage
- first-run decision, evidence and task action (covered): The procedure identifies the authorized task boundary and observable result. Pin the site target Prepare first-run inputs Create WordPress Publish and read the first page
- backup, ongoing operation and recovery (covered): Recovery and maintenance are checked in the task procedure. Publish and read the first page Check HTTPS and recovery