A public site assistant can run a calculator, search the site's content, posts and pages, read basic site information, and submit a contact request by email on the visitor's behalf once they have explicitly confirmed they want it sent.
Needs WordPress 7.0 or later. None of the tools check a WordPress capability; the permission callback only checks that the individual tool is enabled and the plugin's agent-ready setting is on, so any connected user, including a logged-out visitor, can call an enabled tool.
Ids resolved through get_name() methods on six hardcoded tool classes; not dynamic. These ability names are put together by the plugin's code when it registers them, so we worked them out from that code. Check the exact names on your site's Bridge screen.
Grouped by what each one can change. Every one starts off until you enable it.
Evaluates a calculation for the visitor.
Searches the site's content generally.
Searches published posts.
Searches published pages.
Returns basic information about the site.
Submits a contact request by email after the visitor explicitly confirms sending it.
Four steps from two active plugins to a governed connection.
Both plugins need to be active on the same WordPress site. Aivexa registers its own abilities; this plugin discovers and governs them.
In Agent Abilities for MCP, open the Bridge tab (labeled "Other plugins" in the admin). Abilities from every registered plugin appear there, grouped by the plugin that registered them.
Every ability from Aivexa starts off. Turn on only the ones you want an agent to reach, or enable the whole set in one click.
Approve the connection as a WordPress account scoped to what you actually want the agent to do. Each call still re-checks that account’s capability before it runs.
Read more in how bridging works or the full documentation.
Yes. All six tools register unconditionally into the core Abilities API with a real execute and permission callback, so the Bridge can wrap and expose any of them; whether a call actually does anything still depends on the plugin's own settings.
Yes, unconditionally, once Aivexa is active. Nothing else has to be configured for the Bridge to discover them.
Needs WordPress 7.0 or later. None of the tools check a WordPress capability; the permission callback only checks that the individual tool is enabled and the plugin's agent-ready setting is on, so any connected user, including a logged-out visitor, can call an enabled tool.
An agent can read OttoKit's SaaS connection status, access-control settings, system health (cron jobs, database table, webhook log counts), configured automation triggers, which supported integrations are active, and paginated webhook execution logs.
Once an operator turns on the relevant feature toggles, an agent can read a site's exposed settings, users, and post content and terms, and can ask the plugin's AI experiments to draft or suggest excerpts, titles, slugs, meta descriptions, editorial notes and updates, summaries, translations, classifications, type-ahead text, image alt text, generated images, and comment moderation or reply suggestions, though running the content-generation ones also needs an AI connector configured.
An AI agent can create a new AutomatorWP automation, add triggers or actions to an existing one, and run or execute an automation's actions immediately, using AutomatorWP's own no-code automation builder.
Verified from Aivexa's own free wordpress.org code on 28 September 2026, not from its marketing claims. Not every ability listed here has been run end to end against a live site. Plugin authors change their code, so a name, a capability, or a condition can be different in a later release. This site is not affiliated with, or endorsed by, Vivek Kethu or Aivexa. Back to the full directory.
Every ability starts off, is scoped to the user you connect, and is written to the same audit log as core. Turn on only what you need.
Off by default. Capability checked on every call.