Proposal: Structured content context abilities for WordPress AI

[antunjurkovic-collab]

Summary

WordPress AI tools need a small, authenticated, read-only way to retrieve current post/page context without relying on scraping, stale model knowledge, custom MCP-only integrations, or mutation-capable APIs.

I’m proposing a narrow pattern:

Structured Content Context Abilities: authenticated REST endpoints plus optional WordPress Abilities API registrations for read-only post/page context.

This is REST/Application Password first, with Abilities API discovery when available.

Why

For AI tools and agents, the common need is simple:

• list content the authenticated user can work with;
• fetch a current structured representation of a post/page;
• fetch a Markdown projection;
• discover changed content;
• revalidate cached context using ETag / If-None-Match.

This should be possible through normal WordPress authentication and permissions, without inventing write routes or requiring MCP as the first integration path.

This is intended to complement existing post/context helpers and AI experiments, not replace REST or existing Core AI building blocks.

Reference implementation

I created a small reference plugin:

https://github.com/antunjurkovic-collab/wp-context-abilities

Proposal draft:

https://github.com/antunjurkovic-collab/wp-context-abilities/blob/main/docs/WORDPRESS-AI-CONTEXT-ABILITIES-PROPOSAL.md

Current v0 scope:

• authenticated REST routes under /wp-json/wp-context/v1;
• post/page structured JSON Machine Representation (MR);
• Markdown projection;
• catalog / changed-content discovery;
• strong ETag validators and Content-Digest integrity headers;
• optional WordPress Abilities API registration when available;
• read-only only.

Live validator currently passes 27 checks with 0 failures.

Changed-content discovery currently uses high-water cursor semantics. Clients should page through all results for a fixed since value, then store the returned cursor for the next sync. Feedback on whether WordPress AI tooling would prefer high-water cursors, next-page cursors, or both is welcome.

Non-goals

This is not:

• an MCP-first proposal;
• an agent runtime;
• a write/update API;
• a replacement for REST;
• a request for immediate core merge;
• a broad plugin compatibility layer.

Discussion question

Would a small read-only Structured Content Context Ability surface be useful for WordPress AI tooling, especially as a REST/Application Password-first pattern with optional Abilities API discovery?

Specific feedback I’d value:

• Is post/page context the right first surface?
• Is Markdown projection useful as part of the same surface?
• Which fields should belong in a stable Machine Representation?
• Should changed-content discovery use high-water cursor semantics, next-page cursor semantics, or both?
• What eval would prove this improves agent behavior compared with docs or skills alone?