You can build your PlatformDTC store’s theme with the coding agent you already use — Claude Code, Codex, Cursor, or any client that speaks the Model Context Protocol — not only with the built-in PlatformDTC agent. Your agent reads and writes the same theme workspace the dashboard theme editor opens and the publish pipeline deploys. There is no export, no sync step and no copy that can drift: a change your agent writes is what the editor shows on its next load, and what a publish puts live.

Claude Code

One claude mcp add command, then sign in from /mcp.

Codex

codex mcp add and codex mcp login.

Cursor

One entry in .cursor/mcp.json.

How it fits together

There are two ways in, and they meet at the same API:
  • Remote MCP serverhttps://api.platformdtc.com/mcp/theme. Your agent connects, you sign in to PlatformDTC in the browser and choose the store and permissions, and the agent gets 15 theme tools. Nothing to install.
  • CLI and local dev MCP@platformdtc/cli pulls a theme to a folder, runs the same theme check locally, and pushes changes back. @platformdtc/dev-mcp gives a local agent the docs, the section schemas and the validators over stdio, without touching your store.
Every remote call goes through the Agent Gateway /themes endpoints, so scopes, audit logging, idempotency and rate limits apply exactly once, in one place.

Why templates are data and sections are React

PlatformDTC themes are Builder2 themes, the same model Shopify’s Online Store 2.0 uses: A page is data, not source code. A template that references registered sections cannot fail to compile, every setting in it has a schema, and the dashboard editor can edit it without rewriting code. That is what makes it safe for an agent and a merchant to work on the same theme: the agent edits JSON the editor understands, and the editor edits JSON the agent can read back. When a store needs something no platform section does, your agent writes a custom React section. It becomes a section type like any other: it shows in the editor’s section picker, templates reference it by type, and the same component renders the editor preview and the live store.

What your agent may edit

Every file in a theme workspace has exactly one owner. The theme manifest (GET /themes/{id}/manifest, or the get_theme_manifest tool) lists every file with its owner and whether it is editable. Platform-owned files are refused at write time, with an error your agent sees and can act on. They are never accepted and then silently overwritten when you publish. data/ is generated from your catalog on every publish, so writing to it would be lost.

Development themes

Your agent should not edit the live theme directly. The usual loop is:
1

Create a development theme

create_dev_theme copies your live theme (or another theme you name) into a new theme with role development. Your live store does not change.
2

Read the manifest, then the files

get_theme_manifest shows what exists, who owns it and the available section types with their schemas. read_theme_files returns file contents and a checksum for each.
3

Write

write_theme_files writes up to 50 files per call. Each successful batch is recorded as one version you can roll back to.
4

Check and preview

check_theme runs the theme check rules. preview_theme returns a temporary preview URL you can open in a browser.
5

Publish

publish_theme runs the check again and publishes through the same pipeline the dashboard uses. By default it waits for your approval.
Development themes that are not changed for 7 days are deleted automatically, together with their workspace. Live (main) and unpublished themes are never deleted this way.

Next