WordPress

Four doors, one key

Rank Math registers its AI Visibility features as WordPress Abilities, with two lines of metadata: show in REST, and expose over MCP. Those two lines are the whole story. They put the same functions on WordPress core's REST route and on the MCP Adapter plugin's MCP server, and both authenticate the way any REST caller does, which for us means an Application Password. So one login opens four surfaces on the same host, and that is why this is an integration of its own rather than a hidden field on a marketing source: more things are queuing up for that key.

• The ordinary REST API: posts, media, users, plugins
• WordPress 6.9's Abilities API, opt-in per ability
• The MCP server, where the MCP Adapter plugin is installed
• Rank Math's own AI Visibility route

A probe is evidence, never the gate

None of the six probes gates another, because in reality those states are independent: Rank Math is routinely absent from a site whose posts API is perfectly healthy, and MCP from a site where Rank Math works fine. A read that succeeds outranks a probe that refuses: a credential that reached the ordinary REST API is active even if the others failed, and only one refused by every probe is called refused. Unreachable and not-WordPress are separate from refused as well, because neither says anything about the password, and reporting them as auth failures sends somebody off to re-mint a credential that was never wrong. Every ✗ carries the site's own error text, because a ✗ with no explanation is the one state nobody can act on.

A newer surface is not automatically the right one

Rank Math has two ways to hand over the same figures, and only one of them measures anything. The ability reads a twelve-hour cache and cannot force an upstream fetch: its own refresh input is telemetry. The REST route can. Anyone who reached for the ability because it is the newer surface would have built a chart that moves only when a human opens the WordPress dashboard: a chart of when somebody last logged in, drawn as a chart of a client's AI visibility. So the nightly sync calls the REST route with refresh on, and a test pins it.

Five figures nobody already knew

The other marketing sources speak a vocabulary a marketeer already owns: everyone knows what a session is. These five are new to the agency and to the client alike, and the labels are as short as a tile allows. So "Citations 6" sat next to "Mentions 18" with nothing on the screen saying that the first is the subset of the second that carried a link. The agency could not explain the dashboard it had built and the client could not read the one it had been given. So every figure carries its own sentence: written out where there is room, as a tooltip where there is not, and in exactly the same component for the agency and for the portal, so no version exists that explains the numbers to one audience and not the other.

• AI visibility score: rank, mentions, citations and sentiment folded into one figure from 0 to 100
• Mentions: how often the brand was named in the answers to the tracked prompts
• Citations: the subset of those that also linked to the brand's site
• Average sentiment: how positively the brand is described, as a percentage
• Average rank: the brand's mean place among the brands an answer names, where 1 is best

The site is a parameter, never a tool

Forty clients each with their own WordPress, reachable by the team from schakl.'s MCP server, including sites that register no abilities of their own. A tool per site would be a list that differs per client, and a chat client puts every tool in the model's context on every turn. So these are ordinary routes on the WordPress connection with the site as a parameter, and the wordpress MCP section is the same set of tools whether you look after four sites or four hundred. What differs per site (which plugins, which post types, which abilities) is answered by that site's summary, never encoded in the tool list. Whatever no fixed route covers goes through a bounded passthrough to the site's whole REST API: WPML, LiteSpeed, FileBird and whatever arrives tomorrow.

• A summary per site: WordPress and PHP version, post types, plugin namespaces, forms, abilities and whether the site is multilingual
• Read and edit pages, posts and any custom post type, drafts, ACF fields and the WPML language included
• Read media, so an ACF image id means something
• Contact Form 7: the template, field names, both mails and the messages
• List and run abilities; an ability that does not mark itself read-only counts as a write
• The passthrough: GET for every member, writes for an admin only, users, plugins, themes and settings for nobody, and an answer that says what it left out at 256 KB

The audience decides the permission

WordPress has no staging: an edit to a published page is the broadcast. So the permissions are not split by which field you touch but by who sees the result. A member writes drafts and edits what is not yet live; editing anything a visitor can see, or setting a draft live, is a separate permission that sits with the admin by default. That is decided by reading the record before the write, and the refusal comes before the site is asked anything. Forms, menus, options pages and translated strings are live the moment they save and so fall under publish, and deleting is its own permission again, so a key held by an assistant can say: may edit, never delete. Every write is a line in the site's activity trail in schakl., because the client's WordPress records nothing about us.

schakl WordPress MCP Bridge: the site's own page builder

A page built as an ACF repeater of typed blocks, each block type showing a handful of fields out of thirty, cannot be edited through ACF's REST integration: its validation ignores conditional logic, a repeater has to go back whole and saves by position, a post type not shown in REST does not exist there, and uploading only takes multipart. None of that is fixable from the password's side, so a WordPress plugin does it on the site: the schakl WordPress MCP Bridge. It knows the field groups' schema including the conditions, reads per block only the fields the editor shows, validates a change the way the editor does and reports every problem with its full path, edits one block without touching the others, takes an image as a URL or base64, edits menus in place, gives Contact Form 7 what its own REST namespace never had, and handles WPML: languages, a linked translation with its references translated, String Translation, and both ways WPML translates a form. schakl. reaches the plugin through 33 bridge routes under the same login, the same 33 tools in the wordpress section however many sites there are. Where the plugin is not installed the call says so and names the plugin; the verify on the website page shows the installed version and whether the plugin can update itself.

• The schema: which fields exist, which choices they carry and when the editor hides them
• Read, create, edit by path and delete records, including post types not shown in REST
• A record, a term or an options page as readable text too, and the record list with that text in one call: every FAQ item with its answer
• Upload media as JSON, terms and ACF options pages
• Menus: create, rename, choose theme locations, edit items in place, move them and put them in order, and delete
• Contact Form 7: the fields parsed from the template, CF7's configuration errors, mails and messages merged on update, and a delete under its own permission
• WPML: languages, creating or connecting translations, String Translation, and a form per language or one form with translated strings
• A refusal from the plugin comes through unchanged, with the path to the field and the row