Skip to content
mason

AI Assistant Support

Mason can describe itself to an AI assistant — Claude Code, Claude Desktop, Cursor, Codex, or anything else that speaks the Model Context Protocol (MCP).

This matters because of where Mason keeps things.

Your bricks are defined in the database, not in files. An assistant reading your templates therefore has no way to know that:

{brick:heading}

is valid for one brick and meaningless for another.

Without that information, it will guess — and guesses can look plausible.

With Mason's MCP tools, the assistant reads your actual brick library instead.

Setting It Up

  1. Install ExpressionEngine's MCP Server add-on.
  2. Mason's tools are discovered automatically once it's present. There is nothing to configure in Mason.
  3. Start the server:
php system/ee/eecli.php mcp:serve
  1. Point your assistant at it. The MCP add-on's mcp:install command writes the configuration for common editors.

Mason works exactly as normal without the MCP Server installed. These tools are simply unavailable.

Note: ExpressionEngine's MCP Server is currently in beta. Mason's tools are read-only and cannot change your content, but the server itself is young.

What the Assistant Can Do

Tool What It Answers
mason_list_bricks Which bricks exist, their fields and kinds
mason_get_brick One brick in full — every field, including those from a bound binder, and the exact tokens each produces
mason_validate_template Whether markup matches a brick's real schema
mason_list_fields Which channel fields use Mason, their editor mode, toolbar and assigned bricks
mason_render_preview The HTML an entry's field actually outputs

Mason also exposes its documentation at:

mason://docs

It also provides a:

mason_write_brick_partial

prompt that drafts a partial from a brick's real fields.

Everything is read-only. Nothing here can edit content, bricks, or settings.

Where It Helps Most

A Brick Renders as Nothing

Mason fails quietly by design.

A token naming a field that doesn't exist renders as empty, and an unclosed loop swallows the rest of the partial.

Neither produces an error anywhere, so the symptom is usually:

"Part of my template just isn't there."

Ask the assistant to run mason_validate_template on the brick. It will identify the exact token causing the problem.

Writing a New Partial

mason_get_brick provides the real token list up front, including sub-variables such as:

{brick:image:url}

It also provides the row variables available inside Grid and Listing loops.

This means the markup is written against the actual schema rather than a guess.

A Brick Is Missing From a Page

mason_list_fields shows which bricks each field offers and flags assignments pointing at bricks that no longer exist.

Those assignments resolve to nothing with no visible indication on the page.

Telling a Template Bug From a Data Problem

mason_render_preview renders one entry's field without loading a page.

If the partial looks right but the output is empty, the content is the cause.

Example

"Why is the testimonials brick not showing quotes on entry 1084?"

A capable assistant will:

  1. Call mason_get_brick to retrieve the field names.
  2. Run mason_validate_template to check the partial's tokens against the actual schema.
  3. Run mason_render_preview to see what that entry actually produces.
  4. Tell you which of the three is wrong.