WordPress MCP vs REST API for AI Agents: Start Read-Only

Choose the narrowest WordPress connection that completes the job. Use the REST API for a bounded content inventory, WordPress.com MCP when an agent needs broader discoverable account or site tools, and the WordPress Abilities API plus an MCP adapter when a self-hosted site must expose plugin-defined capabilities. Start with reads, a dedicated low-privilege identity, and explicit fields. Add write access only when a reviewed workflow actually needs it.

That answer matters because "connect my agent to WordPress" can describe three very different jobs: reading published posts, discovering site-specific capabilities, or changing production content. Treating them as one permission decision gives the agent a larger failure surface than the task requires.

REST, MCP, or Abilities: Which WordPress Connection Fits?

The protocol is not the security boundary by itself. A REST client with an administrator credential is broad. An MCP server with only read tools can be narrow. The useful comparison is the exact operation, resource scope, identity, approval rule, and evidence returned after execution.

What WordPress Exposes Today

The WordPress REST API is distributed across WordPress sites and uses resource-oriented JSON endpoints. Published posts are available through the posts endpoint, including bounded queries for pagination, dates, search terms, sorting, and response context.

Remote authenticated calls can use WordPress Application Passwords over HTTPS. Use a dedicated WordPress user with only the capabilities the job requires. Do not reuse an owner's everyday administrator credential merely because an integration form accepts it.

WordPress.com MCP serves a different job. It uses OAuth 2.1, exposes discoverable tools to supported clients, enables read-only tools by default, and leaves write tools disabled until the account owner turns them on. It can also restrict individual sites. Those defaults make it a good fit when an agent needs a broader WordPress.com surface than one REST resource.

For self-hosted WordPress, the Abilities API in WordPress 6.9 and later lets plugins register named operations with input and output schemas plus permission callbacks. The WordPress MCP Adapter can translate eligible abilities into MCP tools or resources. That route is useful when the job is genuinely site-specific, but every exposed ability still needs a deliberate permission and data contract.

Use a Read-Only WordPress Inventory as the First Test

A first connection test should answer a question without changing the site. A published-post inventory is a strong test because its inputs and receipt are easy to inspect.

Define the request before connecting anything:

{
  "job": "inventory published posts for a content refresh",
  "site": "https://example.com",
  "resource": "/wp-json/wp/v2/posts",
  "search": "agent integrations",
  "after": "2026-01-01T00:00:00Z",
  "pageSize": 5,
  "fields": ["id", "date", "slug", "link", "title", "excerpt"],
  "writesAllowed": false
}

The acceptance rule is not "the agent found WordPress." It is: at most five published post records came from the approved site, every record contains only the requested fields, no mutation was attempted, and the response includes enough identity to open and verify each post.

Inspect the Current Aident WordPress Action

Give your coding agent the canonical Aident setup instruction exactly as written:

Follow https://aident.ai/SETUP.md

Then have it verify authentication and Vault state with the installed public CLI:

aident account auth status
aident vault vault --action status

Search by job instead of copying a capability identifier from an old article:

aident capabilities search \
  --targetEnv staging \
  --query "find and list published WordPress posts" \
  --types '["action"]'

On August 11, 2026, the live Aident catalog exposed one WordPress API Action for finding and listing published posts. Its input supported page and page-size controls, search, before and after dates, sorting, and an explicit field list. The default page size was five, the maximum was 100, and the default fields were ID, date, slug, link, title, and excerpt. The Action was classified as read-only and exposed no create, update, or delete operation.

Treat that as dated evidence. Inspect the current Action again before every workflow because an integration can add fields, operations, authentication modes, pricing, or risk metadata.

Preflight the Exact Read Before Calling WordPress

Build the smallest payload that satisfies the inventory contract:

{
  "per_page": 5,
  "search": "agent integrations",
  "after": "2026-01-01T00:00:00Z",
  "order": "desc",
  "orderby": "date",
  "_fields": "id,date,slug,link,title,excerpt"
}

Ask the agent to inspect the current schema, copy the exact current Action name from discovery, and preflight that payload. Check four things before execution:

1. Input validation passes without silently dropping a filter.

2. The integration still exposes a read operation only.

3. The site and credential belong to the intended WordPress environment.

4. The page size and field list match the reviewed request.

This exact shape validated and preflighted at zero Aident credits on August 11, 2026. No WordPress request was executed in that test because the Vault connection still required user setup. That is a scope and schema result, not an end-to-end provider success claim.

After the site owner completes the connection, execute one page and verify the receipt against the WordPress site. Stop if the response comes from the wrong host, includes private or draft content, omits stable links, returns more rows than requested, or shows that a plugin changed the endpoint contract.

When WordPress.com MCP Is the Better Choice

Use WordPress.com MCP when the agent needs a family of account or site tools rather than one post resource. Examples include listing sites, inspecting analytics, reviewing comments, or discovering which account operations are available.

Keep the first session read-only. WordPress.com documents read tools as enabled by default and write tools as disabled by default. Preserve that boundary until you can name the exact write, explain its effect, require confirmation, and verify the resulting item.

Do not add a parallel REST credential just because an MCP client also supports custom headers. Two overlapping paths make it harder to know which identity, permission rule, or receipt authorized a call.

When the Abilities API Is Worth the Extra Work

Use the Abilities API when a generic post endpoint cannot express the job. A plugin might expose "calculate renewal risk," "prepare a product feed," or "return approved campaign assets" as a typed ability. WordPress documents an input schema, output schema, execution callback, and optional permission callback for each ability.

The adapter should expose only the abilities the agent needs. A broad PHP, database, filesystem, or plugin-management tool is not a shortcut to a good ability contract. Prefer a narrow business operation with validated inputs and a bounded result.

For more on choosing integration surfaces, read Agent Skills vs MCP vs CLI. For the protocol-level comparison, see MCP vs API. For the credential boundary, use How to Give AI Agents API Access Without Exposing Keys.

Common Failure Modes

The agent receives drafts or private content

Stop and inspect the credential, WordPress user capabilities, endpoint context, status filters, and plugins that modify REST behavior. Do not solve overexposure by asking the model to ignore sensitive rows after retrieval.

Search returns zero posts

Verify the exact site base URL, REST namespace, search wording, date range, status, and pagination. A zero-row response is valid only after those filters are confirmed against the same site.

WordPress returns 401 or 403

Confirm HTTPS, the dedicated username, the Application Password, the user's capabilities, and any host or security plugin that restricts REST access. Do not replace a low-privilege identity with an administrator merely to make the error disappear.

MCP lists more tools than the job needs

Disable unnecessary tools or use the narrower REST Action. Tool discovery is useful, but unused write operations still expand the approval and review surface.

A write appears in the same run

Stop. Reading an inventory does not authorize editing titles, changing status, uploading media, or publishing. Create a separate reviewed write contract with a dry run, explicit confirmation, stable item IDs, and rollback behavior.

Reusable Agent Prompt

Follow https://aident.ai/SETUP.md

Prepare a read-only WordPress content inventory.

1. Verify Aident authentication and Vault status.
2. Discover the current Action for finding and listing published WordPress posts in staging.
3. Inspect its schema, operation type, authentication readiness, and pricing.
4. Confirm the exact WordPress host, dedicated low-privilege user, search term, date range, page size, and response fields.
5. Preflight one page with at most five rows and show me the validated payload.
6. If the WordPress connection needs setup, stop and give me the Aident connection URL. Never ask me to paste a credential into chat.
7. After the connection is ready, execute only the reviewed read.
8. Return the stable post ID, date, slug, link, title, and excerpt for each row.
9. Verify the links point to the approved host.
10. Do not create, update, delete, upload, publish, or change any WordPress resource

Success is not broad access. Success is a small, verifiable content inventory produced through one understood identity and one bounded read.

Preflight one read-only WordPress inventory with Aident Loadout before expanding the agent's access.

Refresh Triggers

Refresh this guide when the Aident WordPress API Action adds operations or authentication modes, WordPress changes its REST, Abilities, or MCP contracts, WordPress.com changes its default tool permissions, or complete owned query data shows that a different canonical better matches the reader's job.

Sources

• WordPress REST API reference

• WordPress posts endpoint

• WordPress REST API authentication

• WordPress Abilities API

• WordPress MCP Adapter

• WordPress.com MCP documentation

• Live Aident Loadout catalog and preflight, inspected August 11, 2026