kinsta.sites.delete and kinsta.environments.delete are documented as unable to be undone, kinsta.sites.reset removes all existing data, and kinsta.backups.restore overwrites the environment it restores into — none of which is gated behind anything the server itself enforces. Against that, the slow operations are honest about being asynchronous: creation, cloning, pushes, cache clears and backups return an operation_id instead of pretending to have finished, and kinsta.operations.status is where the outcome actually arrives.
A management client for Kinsta's WordPress hosting, exposing 83 tools over company inventory and activity logs, DNS zones and records, sites and environments, SSH and SFTP access, WP-CLI, plugins and themes, custom domains, server, edge and CDN caches, analytics, backups and log files.
- Site and environment creation that hands you a ticket rather than blocking: kinsta.sites.create takes admin_user, admin_email, admin_password, region, wp_language and flags for woocommerce, wordpressseo and multisite, kinsta.sites.create-plain skips WordPress entirely, and kinsta.sites.clone and kinsta.environments.clone copy from a source_env_id — each returns an operation_id that kinsta.operations.status polls.
- A staging-to-live push you can narrow before running it: kinsta.environments.push takes push_db and push_files independently, a file_list governed by push_files_option, and run_search_and_replace, so a database-only or files-only promotion is a single call.
- SSH treated as a surface rather than a switch: kinsta.environments.ssh.toggle and kinsta.environments.ssh.password-access control access, kinsta.environments.ssh.generate-password and kinsta.environments.ssh.password-expiration rotate and age the password, kinsta.environments.ssh.ip-allowlist.update restricts where it answers from, and kinsta.environments.ssh.config returns the connection details to hand out.
- Caches addressed one layer at a time instead of behind a single button: kinsta.tools.clear-cache for the server cache, kinsta.edge-cache.clear and kinsta.edge-cache.toggle for the edge, kinsta.cdn.clear-cache for the CDN, with kinsta.cdn.image-optimization carrying an is_lossless flag.
- Plugin and theme maintenance at both scopes: kinsta.company.plugins and kinsta.company.themes search across every site in the company with status filters and paging, while kinsta.plugins.bulk-update and kinsta.themes.bulk-update take plugin_ids and theme_ids so one environment updates in a single operation.
- Analytics that keep measured and billable apart: kinsta.analytics.visits sits beside kinsta.analytics.visits-usage for billable visits, kinsta.analytics.bandwidth beside kinsta.analytics.bandwidth-usage, kinsta.analytics.cdn-bandwidth beside kinsta.analytics.cdn-bandwidth-usage, each over a timeframe_start to timeframe_end range, alongside kinsta.analytics.disk-space.
- Direct access to the machine when the API abstraction runs out: kinsta.environments.wp-cli runs any command beginning with 'wp ', kinsta.environments.phpmyadmin returns a phpMyAdmin login token for the database, kinsta.environments.files lists the filesystem, and kinsta.logs.get reads error.log and access.log for a given number of lines.
- DNS edited as a delta rather than a replacement: kinsta.dns.records.update takes new_resource_records and removed_resource_records as separate arguments, and kinsta.domains.verification returns the DNS records a custom domain is still waiting on.
A Kinsta API key in KINSTA_API_KEY and the company you are managing in KINSTA_COMPANY_ID — every list call, including DNS zones and activity logs, is scoped to that company. kinsta.auth.validate returns account information when the key is good, and kinsta.ping reports whether credentials are configured without calling Kinsta at all.
One command plus a key — npx -y kinsta-mcp, then supply credentials