Keep one source of truth
Work with the locator, not around it
A locator becomes harder to maintain when store records are copied into page content. WP Store Locator already owns the records and metadata that its frontend uses.
MCP Abilities – Store Locator gives an authenticated AI client a WordPress way to inspect and maintain that native surface. The locator can keep presenting its own store data while the client works with the records and settings that belong to it.
What an AI client can maintain
Use the operation that matches the change
The authenticated WordPress abilities cover the locator’s current state, presentation settings, native records, categories, and transient maintenance.
Start with the current state
Read Store Locator availability, settings, installed templates, and published store count before changing anything. This gives the reader a current view of the locator and the state that the next decision must use.
Set the locator presentation
Update supported settings with Store Locator validation. Configure translated permalink bases and language-specific frontend labels, choose which source-language navigation links and labels appear in selected languages, and set the active search template from the installed templates.
Maintain native store records
List stores, inspect one native record’s address, contact, and location metadata, create a supported store record, or update supported store fields and categories. Store Locator remains the system that owns those records.
Use the categories that exist
List the native Store Locator category terms before reviewing or assigning categories to store records. Organization stays tied to the terms already available in the locator.
Clear Store Locator autoload transients
After a supported data, settings, or template change, invoke the add-on’s maintenance operation to clear Store Locator autoload transients when cache maintenance is needed.
The ownership decision
One locator, not a second directory
The add-on reaches the data Store Locator already owns while the native frontend remains the place where visitors use it.
Store Locator owns the records
Store content remains in Store Locator posts and metadata, including address, contact, location, and category information.
The native frontend stays in charge
Maintained locator templates preserve the native shortcode, map, search form, AJAX result list, labels, and cache behavior.
Page content stays out of the data path
The add-on does not create Elementor cards, static location listings, or duplicate store records in page content. One authoritative record remains available for the locator to read and present.
Before you use it
What the setup needs
These named dependencies provide the runtime, authenticated ability transport, and native locator that owns the data.
Required: 6.9 or later
WordPress 6.9+Provides the WordPress runtime and native Abilities API used by the add-on.
Required: 8.0 or later
PHP 8.0+Provides the PHP runtime for the plugin.
Required
WordPress Abilities APIRegisters the typed WordPress abilities that expose Store Locator operations.
Required
WordPress MCP AdapterTransports registered WordPress abilities to an authenticated MCP client.
Required
MCP Expose AbilitiesMakes the registered abilities available through the Devenia MCP surface.
Required
WP Store LocatorOwns the store records, metadata, categories, settings, templates, map, search, and AJAX result state used by these operations.
Take the next step
Give an AI assistant a native locator control surface
Download MCP Abilities – Store Locator to give an AI assistant an authenticated WordPress path to the native locator. After it is available in WordPress, the client can inspect the current locator state and maintain the records or settings the site needs.