This is not the kind of thing most people need to think about yet. That is okay. Some tools are better when they grow slowly, with the right people finding them first.

So this is a small update on what we have been building, why it matters, and why we are not trying to shout about it.

First, what is MCP?

Imagine WordPress is a big workshop.

There are tools everywhere: pages, posts, images, menus, plugins, settings, forms, SEO fields, cache buttons, and security screens.

An AI assistant can be useful in that workshop, but only if it is given the right tools in the right way.

That is where MCP comes in. It lets software describe clear actions an assistant is allowed to use. Not “do anything you want.” More like “you may read this page,” “you may update this setting,” or “you may check this plugin.”

That difference matters.

What we have been doing

We have been turning our WordPress work into small, named MCP abilities.

The core plugin handles normal WordPress things. The add-ons handle specific tools, like GeneratePress, Elementor, Rank Math, Wordfence, Cloudflare, Formidable, WPML, and others.

Recently we cleaned up the public plugin list and added more of the add-ons that were already useful in our own work:

• Broken Link Checker
• Content Demand
• Database maintenance
• Plugin Check

We also made the plugin names link to their GitHub pages, updated the totals, and fixed an install problem we found while testing the releases.

None of that is flashy. It is the kind of work that makes the whole thing easier to trust later.

Why not make a lot of noise?

Because this is not for everyone yet.

Most WordPress users do not wake up thinking, “I need an MCP ability layer for controlled AI operations.” That is normal.

This is for people who already feel the problem:

• they manage real WordPress sites
• they use AI assistants for actual work
• they want automation without giving away the whole admin panel
• they care about seeing exactly what an assistant can do

That is a smaller group. But it is the right group.

Small signals are enough for now

We checked GitHub, and there are already signs that people are finding the work.

The core plugin has stars, forks, release downloads, and traffic. Some of the add-ons, especially Elementor, Rank Math, and GeneratePress, are getting views from search.

That does not prove that lots of people are using everything in production. GitHub cannot tell us that by itself.

But it does show something useful: the right people are starting to bump into it.

Let it grow at the right speed

Some projects should not be pushed too hard too early.

This feels like one of them.

For now, the job is simple:

• keep the code clean
• keep the docs clear
• keep the plugin pages honest
• publish useful releases when something improves
• let people discover it naturally

That is not the loudest strategy. It is just the one that fits this kind of tool.

If you want to see the current stack, start here: MCP Expose Abilities.

Useful? Yes. Exciting? Not exactly fireworks.

Version 2.3.0 changes that. It gives AI a box of proper Elementor building bricks.

From looking at pages to building pages

Think of Elementor like a giant LEGO board for websites. A page is not just one blob of text. It is made from containers, headings, images, buttons, text blocks, and other pieces.

Before this update, AI could help inspect those pieces and change some of them. With this release, it can start putting new pieces on the board in a safer, more predictable way.

What changed in 2.3.0?

We added the first set of Elementor page-authoring abilities. These are small, reusable actions that let an AI assistant build and rearrange page structure without pretending to be a browser.

• elementor/create-page creates a new Elementor-ready page or post.
• elementor/add-container adds a container, either at the top level or inside another container.
• elementor/add-widget adds any Elementor widget type with raw Elementor settings.
• elementor/add-heading, elementor/add-text-editor, elementor/add-image, and elementor/add-button add common page pieces quickly.
• elementor/move-element moves a piece to a new position.
• elementor/remove-element removes a piece with guardrails.
• elementor/duplicate-element copies a whole element tree with fresh IDs.
• elementor/reorder-elements changes the order of children under a parent.

Why this matters

There is a big difference between “AI, please tell me what is on this page” and “AI, please create a draft landing page with a hero section, a few text blocks, an image, and a button.”

The second one needs building tools. Not magic. Not guessing. Tools.

That is what this release starts to provide. It does not try to copy a full MCP server into the plugin. It keeps the existing abilities-only design and adds the first useful authoring primitives inside the normal elementor/* namespace.

A small example

With these abilities, an AI assistant can now follow a sequence like this:

• Create a draft Elementor page.
• Add a container.
• Add a heading.
• Add a paragraph.
• Add an image.
• Add a button.
• Move the button above or below another element.
• Duplicate a section if the page needs another similar block.

That is boring if you read it like a changelog. It is much less boring when you realize it is the start of AI building actual Elementor drafts with real page parts.

What we did not add yet

This is not the “everything and the kitchen sink” release. We started with the basics because basics are what everything else sits on.

Possible next steps include higher-level page-building flows, template apply/save helpers, dynamic tags, stock image helpers, SVG or icon helpers, and prompt or blueprint support. But those should be built on top of solid primitives, not duct tape.

Already tested and rolled out

The release passed the WordPress Plugin Check gate with no errors. We also smoke-tested the new authoring flow on an Elementor site by creating a draft page, adding elements, duplicating, reordering, moving, and removing them, then deleting the test page afterwards.

After release, we deployed it to the sites we manage that are actively running Elementor.

So, short version: MCP Abilities – Elementor can now do more than inspect the LEGO pile. It can start building with it.

When there is one plugin, life is simple. When there is a core plugin, a stack of add-ons, a GitHub page, a website page, and a few setup steps in the right order, suddenly “just install it” stops being very helpful.

So this round of work was not really about polishing for the sake of polishing. It was about making the ecosystem easier to understand for normal people.

The problem was not the plugins

The plugins themselves were fine. The confusing part was everything around them.

• How many add-ons are there, actually?
• Which ones do you need?
• What should you install first?
• Which page has the current information?
• Why does one page sound newer than another?

That kind of friction is small, but it adds up fast. People do not want to solve a puzzle before they even get to the useful part.

What we changed

• We cleaned up the plugin pages on Devenia so they stop contradicting each other.
• We fixed stale counts, stale links, and stale release references.
• We rewrote the MCP Expose Abilities page in proper Gutenberg blocks so it will be easier to keep updated.
• We improved the GitHub README so the setup path is more obvious.
• We made the “start here” path much clearer: core first, then only the add-ons you actually need.

That may sound like housekeeping, but it changes the feeling of the whole ecosystem. Instead of “here is a pile of powerful stuff, good luck,” it starts to feel more like “here is the shortest path to getting something useful working.”

The real goal: less guessing

We want people to spend less time wondering which plugin does what, and more time actually using them.

If somebody lands on the page and can quickly figure out:

• what the core plugin does
• what is optional
• what order to install things in
• whether the ecosystem is maintained

then we have done our job properly.

Why this matters even if you are not technical

Because “user friendly” is not just about pretty buttons. It is also about whether something makes sense the first time you meet it.

Good tools can still feel unfriendly if the surrounding docs are messy, the pages drift out of date, or the setup path is harder than it needs to be.

That is the part we are trying to improve now.

What comes next

Probably more of this, honestly.

Not because we enjoy moving commas around on plugin pages, but because a friendly ecosystem is built from lots of small choices:

• clearer onboarding
• better install order
• fewer outdated details
• less “which of these do I need?” energy

The goal is simple: make the powerful stuff feel easier to approach.

If you want to see the result, start here: MCP Expose Abilities.

Still nerdy. Just less needlessly confusing.

That is what we just did at Devenia.

We cleaned up releases, fixed plugin docs, pushed missing updates, made sure ZIP files were packed properly, and then went back to our public plugin pages on devenia.com/plugins to make sure they finally matched reality.

In plain English: we took a bunch of plugin shelves that had the right boxes but the wrong labels, and we fixed the labels too.

What We Actually Did

• Published missing releases for our own MCP plugins
• Verified that release ZIP files matched the staged copies
• Cleaned up readme.txt files so the WordPress packages looked proper
• Normalized GitHub README.md files so the repos looked proper too
• Created the missing GitHub repo for mcp-abilities-formidable
• Fixed branch tracking and repo hygiene for a few lagging plugin repos
• Updated the public Devenia plugin pages so they stopped saying old wrong things

The Fun Part: Making the Plugin Pages Tell the Truth Again

This part was especially satisfying.

Our public plugin pages were not completely broken. They were worse in a sneaky way: they were old.

That means visitors could read something that sounded nice, but was no longer fully true. Old plugin counts. Old claims. Old download links. Old descriptions.

So we fixed that.

• The main Plugins page now uses current descriptions for MCP Expose Abilities and URL Change Lockdown.
• The MCP Expose Abilities page now reflects the real release state: core 3.0.28, 13 released add-ons, and the current plugin matrix.
• The URL Change Lockdown page now explains the real scope of the plugin: slug protection, not the older wider lock-everything story.
• Old release links were replaced so people do not get sent to stale ZIPs.

Why This Matters

If a plugin page says the wrong thing, people make bad decisions.

Maybe they install the wrong version. Maybe they expect features that changed months ago. Maybe they think a plugin is smaller, weaker, or more confusing than it really is.

That is boring damage, but it is still damage.

We would rather have plain, correct pages than shiny pages with dusty facts.

The Plugin Stack Is Bigger Now

The MCP plugin ecosystem has grown a lot. The core plugin handles WordPress-native tasks, and the add-ons now cover things like Elementor, Rank Math, Wordfence, Cloudflare, Brevo, Formidable, WPML, filesystem work, Google Workspace, and more.

So part of this cleanup was simply making our public pages catch up with the actual work already sitting in GitHub releases.

Tiny Nerdy Victories We Also Enjoyed

• Watching version numbers line up correctly
• Seeing release assets match staged ZIP files exactly
• Removing stale claims from plugin pages
• Fixing a download link that still pointed at an ancient release
• Turning messy repo state into clean repo state

What You Can Look At Now

• Devenia Plugins
• MCP Expose Abilities
• URL Change Lockdown
• MCP Expose Abilities releases

The Short Version

We fixed the plugin boxes. Then we fixed the signs on the shelves. Now both parts match.

That is not the flashiest kind of work. But it is the kind that makes everything else less annoying.

And honestly, that is one of our favorite kinds of cleanup.

What Triggered This

• A user report in GitHub issue #2 showed add-ons failing activation with: Requires: abilities-api, even when Abilities API was installed.
• Toolset coverage was missing in several public places (repo docs, Devenia plugin page, repo About metadata).
• The GitHub release badge on mcp-expose-abilities showed release: invalid, which was confusing.

What We Fixed

• Activation blocker removed: We removed hard plugin header dependency checks (Requires Plugins: abilities-api) from add-ons and kept runtime dependency checks instead. This avoids false negatives from folder/slug mismatches.
• Release sync: We bumped versions, pushed commits, and published releases across affected add-ons so ZIP users get the fix immediately.
• Toolset added everywhere: We created and published mcp-abilities-toolset, released v1.0.1, and added Toolset references to docs and plugin pages.
• mcp-expose-abilities release metadata fixed: We published v3.0.17 and removed an old draft release to avoid confusion.
• Badge fix: The release badge now uses a semver-sorted Shields URL, which resolves the previous release: invalid display.
• Docs consistency: We updated counts and links in README content so public docs better reflect current plugin state.

Where to Start

• Main plugin page: MCP Expose Abilities on Devenia
• Main repository: github.com/bjornfix/mcp-expose-abilities
• Toolset add-on: github.com/bjornfix/mcp-abilities-toolset

If you reported bugs or confusing behavior: thank you. These fixes were driven by real usage reports, and they made the plugins better for everyone.

This update reduces publish-time friction, improves failure recovery, and hardens posting behavior for busy sites.

What’s New in 1.5.13

• Background queue for LinkedIn posting
  Post sharing now runs asynchronously, so publishing in WordPress stays fast even if external API calls are slow.
• Retry/backoff for transient API failures
  Temporary failures (including common rate-limit and upstream issues) are retried automatically with controlled backoff.
• Duplicate/race protection locks
  Added locking around share processing to reduce duplicate posting risk in concurrent publish scenarios.
• Safer gallery rotation behavior
  Rotation updates are now lock-protected to avoid collisions when multiple posts are published close together.
• Faster image upload path
  When media is local, the plugin reads from local files directly instead of always re-fetching over HTTP.
• Cleanup of legacy packaged files
  Removed old bundled package artifacts from distribution to keep the plugin lean and avoid false positives in checks.

Why This Matters

If your content workflow depends on LinkedIn automation, these improvements make the plugin more resilient under real-world conditions: spikes in publishing volume, transient network/API issues, and concurrent editorial activity.

You can get the latest version from WordPress.org and update as usual from your dashboard.

Devenia Autoposter for LinkedIn on WordPress.org

This release fixes a real production issue where LinkedIn posting could stop when an API version is retired.

What Happened

LinkedIn retired the previously used REST version (202501). When that happened, requests began returning 426 NONEXISTENT_VERSION, so autoposting failed even though the plugin was active and the token was still valid.

What’s Fixed in 1.5.12

• Added automatic LinkedIn API version fallback when a requested version is retired
• Persisted the first known-working API version in WordPress options (dlap_linkedin_api_version)
• Updated organization admin lookup compatibility by removing an unsupported projection parameter
• Applied the resilient request path to post publishing, image upload initialization, and organization ACL lookup

Why This Matters

With this change, the plugin no longer depends on a single hardcoded LinkedIn version. If LinkedIn sunsets one version, the plugin can recover by trying supported versions and continuing to post.

Upgrade Note

Update to v1.5.12 to get the fallback behavior. If you had missed posts during the version sunset window, publishing new posts after upgrade should resume normal LinkedIn sharing.

Plugin page

This release focuses on compatibility in MCP proxy stacks and confirms testing with the latest WordPress core release.

What’s New in v1.0.6

• Fixed: wordfence/get-status now accepts null input from proxy adapters
• Fixed: no-input abilities now accept null where adapters drop empty objects
• Fixed: added optional no-op input key (_) for adapters that require non-empty objects
• Fixed: improved compatibility where empty objects may be passed as arrays
• Improved: clearer inactive-plugin error message (Wordfence plugin is not active.)

Compatibility

• Tested with WordPress 6.9.1
• Works with Wordfence 8.x
• Extends MCP with 8 security abilities for Wordfence operations

Get It

Download v1.0.6 (GitHub Release) | View Source on GitHub | See all MCP add-ons

• Fixed: Replace File button injection in Media Library grid/details view on newer WordPress admin markup
• Improved: More robust attachment ID detection across WP media frames and DOM
• Fixed: Media Library grid view details modal now detects attachment ID via ?item=<ID>
• Improved: Cache busting now also applies to responsive image srcset and works across repeated replacements
• Improved: After replacement, Media Library refresh behavior is more reliable
• Improved: Safer file replacement flow (staged write + rollback) and stricter permissions check

Download: WordPress.org plugin directory

Source: GitHub release v1.7.5

What’s Fixed

This release fixes an issue where duplicate anchor tags appeared on query loops when using themes that already wrap featured images in links (like Twenty Twenty-Four).

The plugin now detects existing anchor tags and skips adding its own, preventing malformed HTML and layout issues.

About the Plugin

Clickable Featured Image makes your post featured images clickable:

• Opens full-size image in a lightbox on single post pages
• Links to the post on archive pages
• Zero configuration required
• Works with most themes and lightbox plugins

Get It

Download from WordPress.org | View on GitHub