Build Pages With Your Favorite LLM: DesignSetGo Meets the WordPress Abilities API

The WordPress Abilities API is one of the most exciting additions to the platform in years. It gives WordPress a standardized way to expose capabilities — “things your site can do” — to AI agents and automation tools. Instead of every plugin inventing its own REST surface, abilities describe themselves with schemas, annotations, and permissions that any LLM can read and act on.

DesignSetGo 2.x ships with a focused set of abilities under the designsetgo/ namespace. That means you can point Claude, ChatGPT, Gemini, or any tool-calling LLM at your site and have it actually build pages — inserting sections, configuring grids, applying animations, wiring up accordions — using the same blocks you use in the editor.

Why this matters

Before the Abilities API, teaching an LLM to edit a WordPress site meant writing a custom MCP server, scraping REST docs, or pasting block markup into a chat window and hoping for the best. With abilities, the LLM can:

• Discover what your site can do by calling list-abilities.
• Read the input schema for each ability so it knows exactly what arguments are valid.
• Execute through a predictable REST endpoint with proper permission checks.
• Respect annotations like readonly and destructive so it knows which calls are safe to retry.

That last point matters. Abilities are self-describing, so a well-behaved agent will never call delete-block without asking you first.

What DesignSetGo exposes

DesignSetGo’s abilities fall into three buckets:

• Info — list-abilities, list-blocks, list-extensions, get-post-blocks, find-blocks. Read-only discovery endpoints the LLM should call first.
• Inserters — add-block, add-child-block, plus shortcuts like add-accordion-item, add-tab, and add-timeline-item for our interactive blocks.
• Configurators & Operations — update-block, batch-update, configure-custom-css, configure-shape-divider, delete-block.

Every DesignSetGo block and extension is reachable through these handful of abilities, because add-block and update-block are generic — they validate against the block registry at runtime. Want to apply our Animation extension to a core heading? Call list-extensions to learn the attribute names, then update-block with dsgAnimationEnabled, dsgEntranceAnimation, and friends.

Setting up authentication

The Abilities API piggybacks on WordPress’s existing authentication. The simplest path is an Application Password:

1. In your WordPress admin, go to Users → Profile.
2. Scroll to Application Passwords, give it a name like “Claude”, and click Add.
3. Copy the 24-character password — this is the only time you’ll see it.
4. Use your WordPress username and that password as HTTP Basic Auth credentials.

The user also needs edit_posts (or stronger) for the inserter and configurator abilities to run. Read-only info abilities work with any authenticated user.

The workflow with an LLM

Whether you’re using Claude Desktop with an MCP bridge, ChatGPT with custom tools, or a homegrown agent, the pattern is the same:

1. Discover. The agent calls GET /wp-abilities/v1/abilities to list everything, or list-abilities filtered by category.
2. Plan. The LLM reads the schemas and decides which abilities to chain. A “build me a landing page” prompt typically becomes: create draft post → add section → add grid → add feature blocks → apply animations → save.
3. Execute. Each ability runs at /wp-abilities/v1/{namespace}/{ability}/run. Method is determined by the annotation: readonly uses GET, destructive uses DELETE, everything else POST.
4. Verify. After inserting, the agent calls get-post-blocks to confirm the document shape, then iterates.

A practical example

Here’s what a real agent conversation looks like under the hood. You say: “Create a three-column feature section on post 123 with fade-in animations.” The LLM issues these calls in order:

# 1. Discover the Flex and Grid blocks and their attributes
GET /wp-abilities/v1/designsetgo/list-blocks/run
    ?input[category]=layout

# 2. Discover extension attribute names (animation, parallax, etc.)
GET /wp-abilities/v1/designsetgo/list-extensions/run

# 3. Insert a Grid container at the end of post 123
POST /wp-abilities/v1/designsetgo/add-block/run
{
  "input": {
    "post_id": 123,
    "block_name": "designsetgo/grid",
    "attributes": { "desktopColumns": 3, "gap": "24px" }
  }
}

# 4. Read back the document to get the new block's index
GET /wp-abilities/v1/designsetgo/get-post-blocks/run
    ?input[post_id]=123

# 5. Add three child feature cards (Stack blocks) into the grid
POST /wp-abilities/v1/designsetgo/add-child-block/run
{
  "input": {
    "post_id": 123,
    "parent_block_index": 4,
    "block_name": "designsetgo/stack",
    "attributes": { "gap": "12px" }
  }
}

# 6. Apply a fade-in-up animation to the grid
POST /wp-abilities/v1/designsetgo/update-block/run
{
  "input": {
    "post_id": 123,
    "block_index": 4,
    "block_name": "designsetgo/grid",
    "attributes": {
      "dsgAnimationEnabled": true,
      "dsgEntranceAnimation": "fadeInUp",
      "dsgAnimationTrigger": "scroll",
      "dsgAnimationDuration": 600
    }
  }
}

That’s six HTTP calls to produce a fully-styled, animated feature section — no block markup written by hand, no template files, no copy-paste gymnastics. The LLM reasons about intent; the abilities handle the plumbing.

Using Claude with MCP

If you’re on Claude Desktop, the cleanest setup is an MCP (Model Context Protocol) server that proxies the Abilities API. A minimal config wrapping curl calls — or a WordPress MCP server that auto-generates tools from list-abilities — both work. Once connected, you can literally type:

“Find all posts using the accordion block, add a new item titled ‘Refund policy’ with this text, and set the heading color to our brand blue.”

Claude chains find-blocks → add-accordion-item → update-block (once per post), and reports back with the posts it touched. It’s the closest thing WordPress has ever had to natural-language authoring.

The one caveat: validation warnings

Because block save functions live in JavaScript and the Abilities API executes in PHP, blocks inserted via REST won’t have their final rendered HTML until the post is opened and saved in the editor. You’ll see “Unexpected or invalid content” warnings with “Attempt Recovery” buttons — this is cosmetic. The frontend renders correctly, and saving the post once clears every warning at once. For fully automated workflows where no human ever opens the editor, the frontend remains perfectly valid.

Where this goes next

The Abilities API is early, but the direction is clear: WordPress is becoming an agent-operable CMS. Template abilities (save and load pre-designed layouts) and a dedicated DesignSetGo MCP server are both on the roadmap. In the meantime, everything you need to build pages with an LLM today is already live in DesignSetGo 2.x.

Pick an LLM you like, generate an Application Password, and start with list-abilities. The rest is just prompting.

Further reading

• WordPress Abilities API — Official Handbook
• REST API Endpoints Reference
• Model Context Protocol (MCP)