AgentPress

The permission-aware WebMCP control layer for WordPress.

Comment

Inspiration

WordPress already has a strong human collaboration model: authenticated sessions, roles, capabilities, drafts, review, and publishing. Most agent integrations bypass that model by asking for a separate API key or by giving an automation service broad access.

AgentPress asks a different question: what if the agent could join the workspace the human is already using, while WordPress remained the source of authority?

What it does

AgentPress is an open-source WordPress plugin that exposes a permission-filtered set of site tools to compatible agents through WebMCP.

It divides operations into three visible classes:

  • automatic operations that are safe within the current user's authority;
  • approval-required operations that should stop for an explicit human decision; and
  • unavailable areas that are never exposed as tools, including users, plugins, themes, code, credentials, and settings.

In the recorded live workflow, ChatGPT used AgentPress tools from its built-in browser to inspect the current WordPress context and structure, create one useful service-page draft, and read the result back.

WordPress showed the item as a draft. The visible page count changed from 15 to 16, the one new page was identified, and all 15 pre-existing page metadata records remained unchanged. Nothing was published.

Why WebMCP is a strong fit

The browser already holds the most important context: the page the human chose, their authenticated WordPress session, and their real WordPress permissions.

WebMCP lets that page offer structured tools directly to the agent. The user does not have to copy content into chat, hand over a permanent API key, or teach the model where buttons live.

That makes a multi-step WordPress task possible in one request: inspect the site, understand the allowed operations, create a draft, and verify the result.

The outcome remains native WordPress content that a human can preview, edit, review, or publish through the normal workflow.

How we built it

AgentPress defines a fixed catalog of typed WordPress Abilities and adapts the permitted surface to WebMCP using document.modelContext.registerTool.

Calls travel through a private same-origin REST transport using the signed-in WordPress cookie session and REST nonce.

The server does not trust discovery alone. It revalidates the current user's WordPress capabilities, object-level access, operation policy, origin, nonce, request size, and closed input schema at execution time.

Draft writes are forced to draft status and pass through an idempotent Change Set coordinator. Attempts and outcomes produce bounded, sanitized audit records.

The wp-admin Overview makes the boundary legible: connection health, the connected site, operations available automatically, operations classified as approval-required, and areas that are always blocked.

Challenges

The hardest problem was not generating WordPress content. It was preserving WordPress authority across browser discovery, agent execution, REST transport, object-level permissions, retries, and a human-readable admin interface.

We treated every layer as a boundary and kept a dated experiment ledger containing failures as well as successful results.

Accomplishments

  • A real ChatGPT built-in-browser WebMCP run created and verified one WordPress page draft.
  • The write was idempotent and represented as Change Set AP-1.
  • The result remained unpublished and existing page metadata remained unchanged.
  • The plugin uses the human's current WordPress session instead of a copied API key.
  • The public repository contains implementation tests and an auditable experiment trail.

What we learned

Agent capability should be narrower than user capability, and the distinction must be visible to both the human and the model.

Tool discovery is useful, but enforcement must happen again on the server.

We also learned that an honest, bounded demonstration—with request identifiers, WordPress state verification, and explicit untested limits—is more valuable than a broad automation claim.

What's next

The recorded challenge build proves the core read-and-draft workflow.

The next milestones are the visible approval and classic-navigation flows, the canonical Administrator-versus-Author permission test, and five consecutive clean reliability runs.

Those are deliberately described as next steps, not as completed features.

Built With

  • javascript-modules
  • node.js
  • php-8+
  • phpcs
  • phpunit
  • webmcp
  • wordpress-6.9+-/-7.1
  • wordpress-abilities-api
  • wordpress-rest-api
  • wp-env
Share this project:

Updates

Submission history