WordPress AI Content Workflows: Read, Draft and Verify

Review content without changing it

“Use my Studio site. Call site_status, then wordpress_read /wp/v2/posts with status=draft, per_page=10 and page=1. Return the post IDs and titles. Make no changes.” Confirm the returned site identity before using the draft list.

Create a draft, then read it back

When changes are allowed, call wordpress_request with method POST, route /wp/v2/posts, and params containing title, content and status=draft. Read /wp/v2/posts/RETURNED_ID afterward. Publishing requires a separate explicit instruction and the user’s publish capability.

Inspect a plugin’s API

Use discover_routes and identify the plugin’s namespace and supported methods. Test a read endpoint first. Dashboard controls without REST routes need another supported integration; do not infer an API from the dashboard appearance.

Deletion stays deliberate

Specify the exact item and whether it should move to trash or be permanently deleted. Native endpoint permissions still apply. A tool’s destructive hint is information for the client, not a server-side approval dialog or automatic backup.

Workflow 1: Perform a read-only editorial inventory

Goal: Identify drafts, their owners and publication status without changing content. Suggested request: “List my connected sites. Confirm the intended site URL. Read the first 20 draft posts and report each ID, title, date and status. Do not modify anything.”

1. Run list_sites and select the correct site ID.
2. Run site_status and confirm the returned URL.
3. Call wordpress_read on /wp/v2/posts with status=draft, per_page=20, page=1 and an authenticated user authorized to see drafts.
4. Check the total-page headers before deciding whether pagination is needed. Summarize actual returned records, not assumptions about a missing page.

Evidence of completion: A table of real post IDs and titles with a note that no write request was made.

Workflow 2: Create a WordPress draft and verify the saved result

Goal: Save a reviewable draft without publishing. Writing must be enabled in the appropriate Studio and WordPress access controls and the connected user must be authorized to create posts.

1. Describe the article, intended audience, facts to preserve and desired draft title.
2. Call wordpress_write with POST on /wp/v2/posts and explicitly set status=draft.
3. Capture the returned WordPress post ID and link, then use wordpress_read on /wp/v2/posts/ID.
4. Compare saved title, content and status to the request. Review editorial accuracy before considering publication.

Evidence of completion: The saved post ID, draft status and successful read-back. Never interpret an HTTP 200 from an unrelated tool as proof that the WordPress draft was saved.

Workflow 3: Repair one existing page without overwriting its layout

Read the exact page first and retain its structural markup, links and any valid structured data. Make the smallest requested edit using the returned page ID, then read it back and inspect both content and status. If the page contains custom HTML, scripts or page-builder output, do not replace the entire body with a generic text-only draft. On production sites, keep a revision and test major changes on staging.

Suggested request: “On my specified site, inspect page ID 42. Improve the installation instructions only; keep the design and existing purchase links. Save and re-read the page, then report the changed section.” The example ID is illustrative; substitute the real ID returned by WordPress.

Workflow 4: Determine whether an installed plugin is manageable through AI

1. Discover the site’s current REST namespaces and methods.
2. Find the plugin’s documented endpoint and confirm its HTTP method and permission requirements.
3. Try a non-destructive GET request as the least-privileged user able to perform the task.
4. If the endpoint is missing or access is denied, record the actual error rather than announcing a successful integration.

WordPress offers both core and plugin-provided endpoints, but a plugin’s settings page does not necessarily have a matching route. Use the feature-by-feature compatibility checklist.

Common WordPress AI workflow questions

Can an AI assistant publish automatically?

Publishing is a real write operation. It requires explicit instruction, enabled writes and a WordPress user with publishing permission. Use draft review for higher-risk content.

Can I run workflows across several WordPress sites?

Yes, for the sites configured in an authorized hosted workspace. Confirm the site ID before each content-changing action; never assume the default site is the intended target.

What proves an operation succeeded?

A response from the intended WordPress site, the affected resource ID and a successful read-back showing the requested fields. For troubleshooting and access limitations, see the error guide and permissions overview.

See these verification steps applied to a real WordPress site

For a reproducible example of the workflow’s core checks, read the verified MCP connector demonstration. It records WordPress site-status and read operations, REST route discovery, the saved demonstration page and its revision record. An API read-back verifies stored WordPress data, not front-end rendering, SEO ranking or every possible plugin operation.

From a ChatGPT request to a verified WordPress tool result

The MCP tools reference lists the five observed Website Admin operations and the REST paths to use for site identity, draft inspection and permitted changes. It also explains why a successful read of /wp/v2/users/me cannot establish editing permission and how to read a saved draft back by ID after an approved update.

Detailed workflow examples

Work through 10 verifiable WordPress automation tasks and the SEO editorial workflow. For a large site, learn how to audit content in read-only mode with pagination before making changes.