BricksMembers AI Abilities / MCP lets you connect BricksMembers to an external AI assistant that understands your membership site, your Bricks Builder setup, and the BricksMembers features that are active on the site.
That means you can ask an AI client to help with real setup work: finding the right BricksMembers page, explaining which module controls a feature, building a course outline, preparing pages, checking available Bricks elements, creating draft content, planning Bricks Builder changes, or reviewing what still needs to be configured.
The important part is that BricksMembers does not add another chat box inside wp-admin. The chat, model choice, memory, approvals, and tool interface stay in your AI client. BricksMembers provides the safe abilities, catalogs, settings, provider status, dry-run plans, commit step, and audit log that the AI client can use.
What MCP Means Here
MCP stands for Model Context Protocol. In normal language, it is a way for an AI assistant to see approved tools from your WordPress site instead of guessing from screenshots or outdated docs.
With BricksMembers AI Abilities enabled, your AI client can read structured catalogs from the site. Those catalogs tell it which modules are active, which admin pages exist, which BricksMembers Bricks elements are available, which form actions and dynamic tags can be used, which REST route families exist, and which provider is available for Bricks Builder changes.
If you enable write abilities, the AI can also prepare controlled dry-run plans. Nothing should be written just because the AI had an idea. The normal pattern is: read the catalogs, prepare a dry-run plan, review the changes, then commit the plan only after approval.
Which MCP Adapter Can I Use?
The MCP adapter is the bridge between your AI app and WordPress. It is separate from the Bricks provider that edits Bricks Builder content.
BricksMembers does not include a standalone MCP server. It registers safe WordPress abilities and gives you a setup prompt, but an MCP bridge still has to expose those abilities to your AI client.
There are four practical connection paths:
- WordPress MCP Adapter endpoint: the free, open-source WordPress adapter. This is the default path when you do not want a premium plugin just to expose BricksMembers abilities. It creates the WordPress MCP endpoint that your AI client can call when the client supports remote MCP connections.
- WordPress MCP Adapter through a local connector: the same free adapter on the WordPress site, plus a small local connector or proxy for desktop AI clients that need a local MCP process instead of connecting to the WordPress URL directly.
- Novamira integrated adapter: useful when Novamira is installed and registers its MCP and Bricks abilities. This gives the AI Novamira’s broader WordPress and Bricks tooling in the same workflow. BricksMembers still owns the BricksMembers ability contracts.
- Other compatible MCP bridges: possible only when they can discover and execute WordPress Abilities API records with the normal WordPress permission model. BricksMembers does not hard-code a separate third-party Bricks MCP provider today.
The built-in Bricks fallback is not an MCP adapter. It is BricksMembers’ conservative Bricks editing provider for cases where no richer Bricks provider is available. That means a user can use the free WordPress MCP Adapter for the AI connection and BricksMembers’ built-in fallback for Bricks page or template changes.
For the official adapter path, the WordPress site gets an MCP endpoint from the adapter plugin, for example /wp-json/mcp/mcp-adapter-default-server. Your AI app connects to that endpoint directly or through a small local connector such as Automattic’s remote WordPress MCP package. BricksMembers does not need to store model API keys for that connection.
The AI Abilities page also includes an agent bootstrap prompt. That prompt is not the connection itself. After the MCP bridge is connected, paste the prompt into your AI client so it reads provider status, site context, module status, setup catalogs, Bricks catalogs, and the Bricks construction contract before planning changes.
What You Can Ask The AI To Do
- Understand your site: list active BricksMembers modules, find the right admin page, explain what a setting does, or show which feature owns a workflow.
- Set up admin modules: read the admin-module setup catalog, enable module-gated features through a dry-run plan, and get the right admin URL, module gate, required ability list, and frontend Bricks resources for every BricksMembers admin surface.
- Work with Bricks Builder: read BricksMembers element catalogs, dynamic tags, conditions, query controls, form actions, template assistant entries, and fallback Bricks provider status.
- Create WordPress content: plan and commit posts, pages, custom post types, terms, featured images, media sideloads, ACF field updates when the related WordPress or ACF APIs are available, and Content Fields value updates when the Content Fields module is active.
- Plan course setup: prepare outlines, scaffold draft course/module/lesson pages, match real video assets, assign real video sources when allowed, prepare Bricks pages, and create automation workflow plans.
- Build Bricks pages safely: use Novamira when available, or the guarded fallback provider for targeted Bricks content patch, insert, remove, template, condition, class, variable, color, theme-style, and component changes.
- Check safety and provider status: see whether the WordPress Abilities API, WordPress MCP bridge, Connectors/AI Client, Novamira, and fallback Bricks provider are available.
- Review what happened: read the BricksMembers AI audit log from wp-admin and clear it when you no longer need the entries.
What It Does Not Do
- It does not store OpenAI, Anthropic, Google, or other AI provider API keys in BricksMembers.
- It does not add a full chat assistant inside the BricksMembers admin.
- It does not bypass WordPress permissions. MCP-public abilities still run their normal permission checks.
- It does not invent video provider IDs, checkout/session tokens, API secrets, or provider credentials.
- It does not replace Bricks Builder. Bricks tree changes still need a Bricks-capable provider such as Novamira or the guarded fallback provider.
Turning It On
- Open BricksMembers -> Modules.
- Enable AI Abilities / MCP.
- Install and activate the WordPress MCP Adapter, use the adapter through a local connector if your AI client needs one, use Novamira’s integrated bridge, or connect through another compatible WordPress-abilities MCP bridge.
- Open BricksMembers -> AI Abilities.
- Turn on the MCP access master switch.
- Enable Allow AI read access and Expose read tools through MCP first. This lets an AI client understand your site without writing anything.
- Copy the Agent bootstrap prompt from the AI Abilities page and paste it into your AI client after connecting the MCP bridge.
- If you want the catalogs to be visible to MCP clients, enable Show read-only tools to MCP clients.
- In developer terms, that read-only visibility is called MCP-public reads.
- Enable Planning and write tools only when you are ready to let the AI prepare dry-run plans.
- Enable Show write tools to MCP clients only for trusted MCP clients and only after you understand the dry-run and commit workflow.
- Keep the Dry-run switches in MCP Access on by default. Turn one off only when immediate AI writes are intentional.
- In developer terms, that write visibility is called MCP-public writes.
- Leave Allow destructive actions off unless you have a specific admin-only workflow that needs them.
All AI ability exposure is disabled by default. That is intentional. Start with read-only catalogs, confirm your AI client sees the right context, then enable writes only after you are comfortable with the approval flow.
The Dry-Run And Commit Workflow
Write abilities return a plan before changing the site. A plan includes a summary, affected objects, warnings, and a plan_id. The AI client should show that plan to you before committing it.
That review step depends partly on the AI client. If your AI app is configured to automatically approve tool calls, it can approve the planning call and the commit call in sequence. In that case, dry-run still gives BricksMembers a separate checkpoint and audit trail, but it is not the same as a guaranteed human approval pause.
For trusted workflows, you can turn off dry-run from the MCP Access list. BricksMembers then applies that choice to the related write abilities behind the scenes. When dry-run is skipped, the ability writes immediately through the same BricksMembers service path and returns a warning in the response.
When the AI creates or updates course content inside a BricksMembers content structure, BricksMembers also queues the background refresh work that keeps the site correct. That includes structure paths and navigation data, progress calculations, and drip unlock data where those modules are active. The AI receives a response that says which refreshes were queued, so it can avoid assuming that every derived value is finished the instant the content is saved.
- You ask the AI to prepare something, such as a draft course structure or Bricks page update.
- The AI reads the BricksMembers catalogs and provider status.
- The AI calls a planning ability and receives a dry-run plan.
- You review the summary, warnings, and affected objects.
- If the plan is correct, the AI commits it through
bricksmembers/setup-plan-commit. - BricksMembers records the action in the audit log without storing raw secrets.
The recommended setup is still simple: keep dry-run on while testing a new AI client or a new workflow, then disable it only for narrow repeatable actions where immediate writes are useful and intentional.
Working With Bricks Builder
For Bricks Builder work, the AI should first ask BricksMembers what exists. The Bricks catalog includes BRM elements, checkout rules, form actions, query types, query controls, filter sources, conditions, time conditions, dynamic tag families, and template assistant sources.
If Novamira Bricks abilities are registered, Novamira can own broader Bricks tree mutation work. If those abilities are not registered, the fallback provider can still read Bricks content and prepare guarded changes for targeted patch, insert, remove, and template-related work.
The fallback provider is intentionally conservative. Whole-content replacement is off by default. Targeted changes are preferred because they are easier to review and less likely to damage existing IDs, classes, dynamic tags, query settings, conditions, interactions, variables, components, and template references.
The fallback provider now also publishes a Bricks construction contract to the MCP client. That contract tells the AI to build real Bricks trees: sections for page areas, containers for section width, blocks for layout groups, native buttons instead of text links, native media/SVG-capable elements instead of SVG code inside text, and BricksMembers elements for membership features such as progress, video, checkout, downloads, quizzes, chat, events, and certificates.
For a course overview page, that means the AI can read the BricksMembers catalogs, see the available structure tags, query controls, filters, and elements, then prepare a dry-run Bricks plan that uses native query loops for modules and lessons instead of a static HTML dump. If the requested data source or dynamic tag does not exist, the AI should warn you instead of inventing a fake tag.
Working With Admin Modules
The admin-module setup catalog covers every BricksMembers admin surface. For each surface, the AI can see the admin URL, module gate, route type, required MCP abilities, setup blueprint, safety notes, and frontend Bricks resources. That means prompts such as “set up groups” or “set up the frontend course builder” can start with the right module, page, forms, dynamic data, and Bricks resources instead of guessing.
Module enablement is service-backed through dry-run and commit. Deeper settings still need the owning module service. When a deep write is not yet exposed as a dedicated ability, the AI should say that clearly and guide you to the correct admin page instead of writing arbitrary options or meta.
The catalog is also protected by developer tests. When a future BricksMembers admin page or Bricks resource is added, the MCP setup blueprint has to be updated too. That keeps the AI from falling behind the plugin as new modules, elements, forms, query controls, conditions, or dynamic tags are introduced.
Good First Prompts
- “Read the BricksMembers catalogs and tell me which modules and admin pages are available.”
- “Plan the module setup for groups and the frontend course builder, enable the required modules only after I approve, and tell me which Bricks forms and dynamic tags I should use.”
- “Show me which BricksMembers elements and dynamic tags I can use for a member dashboard.”
- “Plan a three-module course structure as drafts. Do not commit until I approve the plan.”
- “Check whether Novamira or the fallback Bricks provider is active before changing this Bricks page.”
- “Prepare a Bricks page using native BricksMembers elements, not raw HTML, and show me the dry-run result.”
- “Create a dry-run Bricks course overview page with module cards, nested lesson rows, progress, video image, access states, and BricksMembers dynamic tags from the catalog only.”
- “Find where I configure video tracking thresholds and explain which settings matter.”
Safety Settings Worth Knowing
- Allowed post types optionally limits which post types AI content abilities may create or update.
- Maximum items per plan limits bulk plans.
- Use WordPress native AI generation controls whether native WordPress Connectors/AI Client generation may be used when available. External AI clients can still write final copy without this.
- Allow real video assignments controls whether real video source assignment plans may be created from connected providers.
- Use built-in Bricks fallback when needed allows conservative Bricks reads and targeted changes when no richer Bricks provider is available.
- Allow full Bricks content replacement controls whether the built-in Bricks fallback may replace an entire Bricks content tree. Keep it off unless you have a clear reason.
- Audit retention controls how long BricksMembers keeps AI ability audit entries.
Common Questions
Do I need an AI API key in BricksMembers?
No. Your AI client owns model access. BricksMembers exposes abilities and settings, not model credentials.
Can the AI publish content immediately?
Generated or scaffolded content should be drafted by default unless you explicitly request another status and the write path allows it. Review content before publishing it on a live site.
Can the AI set up a full course?
It can read the active BricksMembers setup, plan course outlines, scaffold draft pages, prepare content updates, match and assign real video sources when allowed, plan Bricks pages, and prepare automations. The safest workflow is still to review each plan before committing it.
Can the AI edit Bricks pages?
Yes, when a Bricks-capable provider is available. Use Novamira for broader Bricks work when its Bricks abilities are registered. Use the fallback provider for conservative targeted changes, template updates, and global-style updates.
Can I leave writes disabled?
Yes. Many useful AI workflows need only read access: explaining settings, finding admin pages, listing elements, showing dynamic tags, checking provider status, and helping you plan manually.