iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To connect an AI agent to a WordPress site hosted by Kinsta, use WordPress’s Abilities API to define permitted actions and the MCP Adapter to expose selected abilities to an MCP client. The Abilities API path requires WordPress 6.9 or later. For local development, the official guide documents a WP-CLI STDIO setup; for a publicly reachable site or when STDIO is unsuitable, it documents HTTP through Automattic’s remote proxy. Kinsta provides the hosting, SSH access, and WP-CLI environment—not the WordPress MCP server.
How the WordPress MCP integration fits together
The integration has three distinct parts:
- Abilities API: WordPress’s way to register capabilities, including their input and output schemas and permission logic. The API is available in WordPress 6.9 and later, according to the WordPress Abilities API handbook.
- MCP Adapter: A WordPress plugin that makes eligible abilities available to MCP clients. Abilities are generally exposed as tools; read-only information may be represented as resources where appropriate. The WordPress Developer Blog’s MCP Adapter guide describes the adapter’s default server and its discovery, information, and execution abilities.
- Kinsta hosting: The environment where the WordPress site runs. Kinsta documents SSH and WP-CLI access for its Managed WordPress Hosting plans, but its hosting API is a separate platform-management interface, not the site’s MCP server.
For a default MCP server, an ability must be explicitly exposed by setting meta.mcp.public to true in its registration. That flag determines MCP visibility; it does not replace the ability’s own permission checks.
Check WordPress and Kinsta access first
Confirm the WordPress version
Check the version of the specific Kinsta environment you intend to connect. The Abilities API approach requires WordPress 6.9 or later, a prerequisite also stated in Kinsta’s WordPress MCP integration walkthrough. If the site is on an earlier version, do not assume the official Abilities API integration path is available.
Get the right SSH and WP-CLI context
Kinsta’s SSH documentation describes SSH access for Managed WordPress Hosting and says WP-CLI is installed by default. Its WP-CLI guide documents connecting over SSH and changing to the WordPress document root, shown as public, before running commands. Confirm the correct environment and actual document-root path for your site rather than copying a path blindly.
#1 Best Overall
SSH and WP-CLI access do not automatically connect a developer’s local MCP client to a remote WordPress installation. Decide where the MCP server process will run and how that process reaches the intended site before choosing STDIO.
Install the MCP Adapter and expose only intended abilities
Use the plugin route for the default server
The WordPress Developer Blog guide documents downloading and activating the MCP Adapter plugin from its releases. This registers a default server, along with discovery, information, and execution abilities. For a straightforward integration, start with this route and the default server rather than adding a custom server without a specific need.
Use Composer when a plugin needs a custom server
If your own plugin needs more control over which abilities it exposes, the guide describes installing wordpress/mcp-adapter with Composer, loading Composer’s autoloader, checking that the adapter class is available, and initializing the adapter. The same guide recommends Jetpack Autoloader where several plugins may depend on the adapter or Abilities API, to help avoid version conflicts.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Register capabilities with appropriate schemas and permissions
Register each intended task with the Abilities API, defining inputs, outputs, and permission logic appropriate to that task. To make an ability discoverable through the default MCP server, include meta.mcp.public set to true in that ability’s registration. The WordPress first-plugin tutorial demonstrates this setting as part of its MCP integration steps.
Expose only the abilities the integration is meant to provide. Do not make every site capability public for convenience. A custom server is an alternative when a plugin needs tighter control over which abilities are available; it is not mandatory for every site.
Choose STDIO or HTTP for the agent connection
The official adapter guide documents both routes. Their practical differences are where the connection runs, what must be reachable, and how credentials are supplied.
| Consideration | WP-CLI STDIO | HTTP with remote proxy |
|---|---|---|
| Documented use | Local development | Publicly accessible WordPress sites or cases where STDIO is not desired |
| Connection | A client starts a WP-CLI MCP server process and communicates over STDIO. | A remote proxy connects to the site’s MCP endpoint over HTTP. |
| Site access | The process needs a working WP-CLI installation and access to the correct WordPress installation and path. | The site endpoint must be reachable by the proxy. |
| Authentication in the documented setup | Select a WordPress user for the WP-CLI server command. | Use a WordPress username and Application Password in environment variables; the guide also names custom OAuth as an alternative. |
Route A: WP-CLI STDIO for local development
The WordPress guide’s example starts the MCP Adapter with wp ... mcp-adapter serve, selecting a server and WordPress user. The exact client configuration depends on the MCP client, so follow that client’s current instructions for launching an STDIO server.
Recommended Free Tools
- Confirm where the command will run. The official example assumes a local WP-CLI installation and a WordPress installation path. If WordPress is on Kinsta, establish how the process will access that remote installation; a local path by itself does not point to the files on the Kinsta environment.
- Connect to the intended site context. Kinsta documents SSH-based WP-CLI access and navigation to the site document root. Verify the environment, user, and path before running commands.
- Configure the client’s STDIO server entry. Use the client’s supported configuration format and the adapter’s documented serve command, with the intended server and WordPress user.
- Start with a harmless discovery or read request. Confirm that the client starts the server and sees only the abilities you intend to expose.
STDIO is a natural starting point for local development, but remote file access and process placement are implementation details you must resolve for your own Kinsta setup.
Route B: HTTP through Automattic’s remote proxy
The official guide configures @automattic/mcp-wordpress-remote with the site endpoint /wp-json/mcp/mcp-adapter-default-server, plus a WordPress username and Application Password supplied through environment variables. Use the complete endpoint on your own site’s base URL. The guide also identifies custom OAuth as an authentication alternative.
- Make the WordPress endpoint reachable from the environment running the remote proxy.
- Configure the proxy using the guide’s current instructions and the endpoint for the intended site.
- Supply credentials outside committed configuration. Use a dedicated WordPress account with only the capabilities needed for the integration, where the site’s permission model allows it. Keep secrets out of source control, logs, and screenshots.
- Connect the MCP client to the proxy using the client’s current HTTP configuration and verify discovery before permitting actions that change content or settings.
Application Passwords for the HTTP integration are WordPress credentials. They are distinct from Kinsta SSH credentials; one does not substitute for the other.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Verify the integration before enabling writes
The WordPress guide recommends beginning with a few non-destructive, read-only abilities and local MCP clients, then expanding access after gaining confidence. A practical rollout sequence is:
- Confirm the MCP client reports the server as running.
- Discover the server’s available abilities and check that the list matches your intended scope.
- Request a harmless read and confirm the returned information is appropriate for the selected user.
- If the use case needs writes, test one narrowly scoped write in a non-production environment before enabling it in production.
- Review ability schemas and permission checks whenever you add or change an exposed capability.
This is a cautious implementation sequence, not a claim that the integration has been tested on your site. Treat Kinsta SSH commands carefully: Kinsta warns that incorrect commands can break a site and advises consulting a developer or support if you are unfamiliar with SSH.
Keep Kinsta’s REST API separate from WordPress MCP
Kinsta documents a REST API for hosting-platform operations such as listing sites, inspecting site and environment details, and creating, cloning, or deleting sites. Kinsta’s documentation describes that API as public beta; check its current API reference and terms before relying on it in production.
Those account- and platform-level operations are separate from the MCP endpoint inside a WordPress site. The documentation does not establish an out-of-the-box bridge between Kinsta’s API and the WordPress MCP Adapter. A custom integration could combine both surfaces if a workflow genuinely needs site-management actions as well as WordPress abilities, but each would need its own connection and permissions.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
