Guide 00 · Developer docs

Core dna for site builders

Read this guide first. Core dna is hosted, so there is nothing to install; your repository holds only templates and front-end assets; and a new kind of page starts in the admin, with a layout. In half a day, from what the platform is to a page you built, deployed and rendered in Smarty or Twig.

L0
Unit 02 · From zero to a deployed change

Connecting your editor to the MCP server

From zero to a deployed change Page 14 of 28 Updated

Every site has an MCP server at /cdna-mcp, through which an AI assistant in your editor reads and changes the site's content and structure, acting as you. A .mcp.json with a development and a production entry, what the first connection does, and what to do if it fails.

Who this is for. A developer with a backend user on the site and an editor or assistant that speaks MCP. Doing this on the first day pays off in every later unit: from then on you can ask the site about its own layouts and content instead of clicking through the admin to find out.

What it is for

With the site connected, the assistant answers questions from the site itself: which layouts exist and which template each one names, which areas a layout has and their input types, what a page's areas hold, which menus and jobs there are. It can also make changes: create a page, fill an area, add a menu item. Every call it makes goes through the site's API as you, so it can do exactly what your backend user can do, and nothing more.

A .mcp.json for a site

One entry for the development environment and one for production, each pointing at /cdna-mcp on that environment's hostname:

JSON .mcp.json 
{
  "mcpServers": {
    "examplecom-dev": {
      "type": "http",
      "url": "https://examplecom-<developer>.au.coredna.dev/cdna-mcp"
    },
    "examplecom-production": {
      "type": "http",
      "url": "https://www.example.com/cdna-mcp"
    }
  }
}

This is the file editors such as Claude Code read from the project folder; other editors take the same two entries in their own MCP settings. There is no key or password in it: the editor gets a token by signing you in.

The first connection

  1. The editor calls /cdna-mcp without a token and is answered 401, with a header pointing at the site's OAuth details.
  2. The editor registers itself with the site and opens the site's sign-in page in your browser.
  3. You sign in with your backend user and agree to the access the editor asks for.
  4. From then on the editor sends a token with every call, and renews it when it expires.

Step 3 needs a backend user: the site refuses the MCP's access to members. If the connection fails at step 2, the site does not yet accept editors that register themselves. That is controlled in the OAuth module's settings, by DCR (Dynamic Client Registration, RFC 7591) › Enable or CIMD (Client ID Metadata Document) › Enable, both off unless a site turns them on. Ask an administrator of the site to enable the one your editor uses.

Development and production

  • Name the entries so they cannot be confused, and work in the development one. The production entry acts on the live site with your permissions. Use it to read, and change live content only when you mean to.
  • Keep your own .mcp.json out of the repository when it names your personal development hostname. Commit a .mcp.json.example with a placeholder instead, so the next developer starts from it.
Go deeper
GuideMCP, for editors and agents GuideAuthentication and authorisation How-toConnect an editor to a site's MCP server

Was this page helpful?

Your answer goes to the docs team.