The interesting part is not just the connection itself. Bricks also gives you control over the abilities exposed to the AI agent, along with a set of optional skills designed to help it understand how Bricks works.
A Dedicated AI Area Inside Bricks
Bricks 2.4 adds a new AI section to the Bricks settings.
This is where the MCP connection is handled, along with Bricks abilities and skills.
Before doing anything else, the Bricks abilities need to be enabled and saved. That last part is worth noting because the setting does not currently auto-save, which can cause some confusion if you enable it and then move straight on.
I would like to see that become a little more streamlined, but it is a small issue in an otherwise straightforward setup.
Connecting Codex, Claude or Cursor
In the video, I use the Codex desktop app, but the principle is basically the same whether you are working with Codex, Claude, Cursor or using a terminal-based workflow.
Bricks gives you two main ways to configure the connection.
You can copy the raw configuration and add it to your AI client’s config file manually, or copy a prepared prompt and let the AI tool handle the setup for you.
The manual route is quicker if you already know where the config file lives and are comfortable editing it.
The prompt-based route is simpler if you would rather stay inside the AI tool and let it take care of the configuration, although it will take a little longer and use some tokens in the process.
Bricks Skills Add More Context
Once the MCP connection is working, Bricks also provides an optional set of skills.
These can be installed into your AI environment and are designed to give the agent a better understanding of Bricks and the way it works.
For me, this makes a lot of sense.
A raw MCP connection gives the AI access to Bricks, but the skills help provide more context around how it should interact with the builder.
That should improve consistency and reduce the amount of repeated instruction needed when working with layouts, content, design systems and other Bricks-specific tasks.
After installing the skills, the AI client needs to be restarted so everything is refreshed properly.
Fine-Grained Control Over AI Abilities
One of the more interesting parts of the implementation is the Abilities section.
Bricks exposes a large number of actions that the connected AI agent can use, covering areas such as:
- Breakpoints
- CMS structure
- Content lifecycle
- Design systems
- Colours
- Typography
- Layouts
- Other Bricks-specific functions
In the version shown in the video, there were 145 available abilities, with 141 enabled by default.
The useful part is that you are not forced to expose everything.
If there are areas you do not want the AI touching, you can disable them.
For example, if you use an external framework such as Core Framework for colours, spacing and typography, you may not want the AI working with Bricks’ native design-system controls.
You can simply turn those abilities off.
Likewise, if there are specific abilities you do want and they are disabled, you can enable them manually.
My Thoughts on the Bricks MCP Integration
This feels like a sensible direction for Bricks.
Rather than trying to bolt AI directly into the builder in a limited way, the MCP approach lets you work with the AI tool you already prefer while giving that agent controlled access to Bricks.
The addition of skills and granular abilities is especially useful because it gives you more control over how much access the AI has and how well it understands the platform.
The foundations are there for a much more flexible AI-assisted Bricks workflow.
For me, the more interesting question now is what comes next.
Once the connection is in place, the real value will come from how well Codex, Claude and other AI tools can work with Bricks in real projects, especially around design systems, dynamic content, templating and more repetitive site-building tasks.
That is where this could become genuinely useful rather than simply being another AI checkbox feature.
