@bettercms-ai/mcp 0.30.0 → 0.31.0

package/dist/index.js

@@ -2485,6 +2485,10 @@ function buildToolDefs(deps) {
     command: layoutCommand.describe("one canonical discriminated Layout command; authority is derived from type"),
     ifMatch: z.number().int().nonnegative().describe("revision returned by get_layout")
   });
+  const publishLayoutInput = z.object({
+    projectId: z.string().min(1).optional().describe("required only for a workspace-scoped grant"),
+    ifMatch: z.number().int().nonnegative().describe("revision returned by get_layout (scope global)")
+  });
   const componentCategory = z.enum([
     "navbar",
     "footer",
@@ -2833,8 +2837,8 @@ function buildToolDefs(deps) {
       def(
         "update_project",
         "Update the connected project",
-        "Update the connected project's settings \u2014 rename it, change its slug/description, SEO defaults, or visibility. Only the provided fields change.",
-        z.object({ name: z.string().optional(), slug: z.string().optional(), description: z.string().optional(), visibility: z.string().optional(), seoDefaults: z.record(z.string(), z.unknown()).optional() }).shape,
+        "Update the connected project's settings \u2014 rename it, change its slug/description, SEO defaults, visibility, or `presentation`. Only the provided fields change. `presentation` themes the platform's OWN renderer (the one serving a site built in the CMS with no deployed build, and previewing structural drafts everywhere) with the same closed knobs as bcms-presentation.json \u2014 DTCG { $type, $value } tokens keyed like 'page.maxWidth', 'nav.background'. Without it that renderer is a generic 768px document theme. An invalid manifest is 422 PRESENTATION_INVALID.",
+        z.object({ name: z.string().optional(), slug: z.string().optional(), description: z.string().optional(), visibility: z.string().optional(), seoDefaults: z.record(z.string(), z.unknown()).optional(), presentation: z.record(z.string(), z.unknown()).optional().describe("theme knobs for the platform renderer, keyed like bcms-presentation.json") }).shape,
         async (c, a) => ok("Updated project.", await data(c, "PATCH", `/management/projects/current`, a))
       ),
       def(
@@ -3565,7 +3569,7 @@ function buildToolDefs(deps) {
         })
       )
     },
-    // ── Project/page Layout (draft-only; publish remains dashboard-gated) ──
+    // ── Project/page Layout (draft commands + Global Layout publish; page overrides publish with the page) ──
     {
       name: "get_layout",
       config: {
@@ -3590,6 +3594,18 @@ function buildToolDefs(deps) {
         return ok(`Updated ${layout.scope === "global" ? "Global" : `Page ${layout.pageSlug}`} Layout draft to revision ${layout.revision}.`, layout);
       }))
     },
+    {
+      name: "publish_layout",
+      config: {
+        title: "Publish the Global Layout draft",
+        description: "Publish the connected project's GLOBAL Layout draft (navigation, footer, every reserved section) so the live site builds from it. Until this is called the layout stays draft and get_layout copy:'published' answers PUBLISHED_LAYOUT_UNAVAILABLE \u2014 site chrome authored with update_layout is NOT live. Read get_layout first and pass its revision as ifMatch; a stale revision returns 409 \u2014 re-read, never retry blindly. A 422 lists validation issues to fix with update_layout first. Verify with get_layout copy:'published' and check the copy echo \u2014 this tool's own response is the write's echo, not a receipt. Page overrides go live with the page (update_page status:'published'). A 403 PUBLISH_NOT_GRANTED means this connection can author drafts but cannot publish \u2014 say so and let the user allow publishing or publish from the dashboard.",
+        inputSchema: publishLayoutInput.shape
+      },
+      handler: guard(async (args) => withClient(async (client) => {
+        const layout = await client.publishManagedLayout(args);
+        return ok(`Published the Global Layout at revision ${layout.revision} (copy: published). Verify with get_layout copy:'published'.`, layout);
+      }))
+    },
     // ── Components (discover + author reusable symbols) ──
     {
       name: "list_components",
@@ -3788,9 +3804,11 @@ Decide before your first call; converting later means rewriting content.
 
 ## 3. Anatomy of a real section component
 
-A component that is only headings and text renders as an unstyled stack. Every section the
-product ships looks like this \u2014 a \`section\` block carrying \`style\`, with content nested in
-\`props.children\`:
+A component that is only headings and text renders as an unstyled stack \u2014 plain text on white
+in a 768px column, on the live site AND in the visual editor. Every section the product ships
+looks like this \u2014 a \`section\` block carrying \`style\`, with content nested in
+\`props.children\`. \`create_component\` and \`update_component\` return a \`warnings\` entry when a
+Section's root section has no \`style\`; treat it as a defect, not a note:
 
     {
       type: "section", id: "root",
@@ -3845,8 +3863,8 @@ words (the page-builder model): each placement takes that group's current values
 kept and marked \`origin: "componentized"\` so the editor stops offering a second place to type
 them. Either way, running it again converts nothing and duplicates nothing. Then run \`npx @bettercms-ai/convert --componentize\` in the repo
 so its templates render those sections from \`pages[].blocks\`, and finish with the publishes:
-\`publish_component\` every new component and publish the pages, or the site renders the
-sections as empty strings.
+\`publish_component\` every new component, \`publish_layout\` if you touched site chrome (nav,
+footer), and publish the pages, or the site renders the sections as empty strings.
 
 ## 5. Blocks and modular fields
 
@@ -3911,6 +3929,7 @@ is interpolated per entry with \`{{fieldKey}}\` placeholders \u2014 \`{{title}}\
     5. pages        create_page with blockJson placing those components
     6. content      create_content_entry / set_page_content
     7. publish      update_page status:'published'
+    7b. layout      publish_layout  <- if you authored the Global Layout (nav/footer); page overrides publish with the page
     8. check        get_next_steps, and fix what it lists
 
 ## 8. Two ways to ship a blank site
@@ -3930,8 +3949,11 @@ in preview and is blank in production. Always pass the project's id.
 accepts it and ignores it**, silently. No error, no warning, wrong project.
 
 So call \`get_project\` (no arguments) first \u2014 it reports the project you are actually
-writing to. If that is not where the work belongs, stop and tell the user: only they can
-approve a grant for the other project, no tool can switch it.
+writing to. If that is not where the work belongs \u2014 or it answers that the grant covers the
+whole workspace \u2014 stop and tell the user the one-step fix: in the BetterCMS dashboard open
+**Settings \u2192 Connected AI clients** and use **Scope to project** on this connection. No tool
+can switch it, but the user does NOT need to re-authorize or re-add the server: the next call
+after that runs with the new scope. Then retry.
 
 If you must probe, probe with a \`create_content_model\` \u2014 models are deletable
 (\`delete_content_model\`, soft-delete) and **there is no \`delete_component\`**. A component
@@ -3957,6 +3979,7 @@ in this order:
 
     1. create_component      per section (they land as DRAFTS)
     2. publish_component     each one \u2014 unpublished renders as NOTHING, on a page that 200s
+    2b. publish_layout       if you authored site chrome \u2014 the layout is a separate publish
     3. set_page_content      place them as \`component\` blocks on the page
     4. list_extraction_candidates / extract_component
                              now that blocks exist, fold any section repeated 3+ times
@@ -3983,6 +4006,13 @@ type scale, nav position and background, footer surface \u2014 as DTCG \`{"$type
 entries. Redeclare it on every deploy; absent means "declared nothing" and previews fall back
 to platform defaults that will not look like this site.
 
+**A site built in the CMS with NO deployed build has only that renderer** \u2014 live and in the
+editor \u2014 so the generic theme IS the site until you theme it. Theme it without a deploy:
+\`update_project { presentation: { "page.maxWidth": { "$type": "dimension", "$value": 1200 },
+"nav.background": { "$type": "color", "$value": "#0b0b0b" }, ... } }\` takes the same knobs as
+bcms-presentation.json, and set \`style\` on every Section's root (\xA73). A later deploy that
+ships bcms-presentation.json replaces it wholesale.
+
 **Editing binds by VALUE.** The editor matches CMS field values against the text the site
 renders. Three consequences, each load-bearing:
 
@@ -3995,6 +4025,7 @@ renders. Three consequences, each load-bearing:
          c. set_page_content       values EXACTLY equal to the text the site renders \u2014
                                    binding matches by value, so a paraphrase binds nothing
          d. update_page            status 'published' \u2014 the canvas binds the PUBLISHED copy
+         e. publish_layout         if site chrome was authored \u2014 the canvas binds the PUBLISHED layout too
     2. A value that renders in more than one place is still ONE field: bind every element that
        renders it, and the editor keeps them in sync \u2014 an edit patches every copy at once.
        Binding only one copy leaves the others showing the old text until the next rebuild.
@@ -4050,7 +4081,8 @@ green on the wrong document. Three rules, none optional:
        the draft; a PUBLISH claim verifies ONLY via \`get_layout copy:'published'\` (or the
        entry/page's published copy) \u2014 and check the response's \`copy\` echo says
        'published'. A reader that ignores your copy selector hands you the draft and a
-       false green; the echo is how you catch it.
+       false green; the echo is how you catch it. \`publish_layout\`'s own response echoes
+       copy:'published' too \u2014 that is the WRITE's echo, not a receipt; still re-read.
     2. Publish and deploy are SEPARATE claims. "Published" means the published copy changed;
        the LIVE SITE changes only after its next deploy/rebuild. Never report "it's live"
        from a publish receipt \u2014 fetch the live URL (cache-busted) for that claim.
@@ -4287,9 +4319,10 @@ error-prone, so go slow and confirm. Never guess the layout.
 6. **\`publish_component\`.** It lands as a DRAFT, and a draft component renders as NOTHING on
    the live site \u2014 no error, no placeholder. This step is not optional.
 `;
-var LAYOUT_FLOW = `### Project/page Layout authoring \u2192 \`get_layout\` / \`update_layout\`
-Edit the project's draft Global Layout or one page's draft override. Layout publishing stays
-in the dashboard; these tools never change the live site.
+var LAYOUT_FLOW = `### Project/page Layout authoring \u2192 \`get_layout\` / \`update_layout\` / \`publish_layout\`
+Edit the project's draft Global Layout or one page's draft override. \`update_layout\` never
+changes the live site; \`publish_layout\` takes the Global Layout draft live (page overrides go
+live with their page). Until it is called, site chrome you authored is NOT on the live site.
 1. **Read first** \u2014 call \`get_layout\` with scope \`global\`, or scope \`page\` + pageId.
    Keep the returned \`revision\`; every write must pass it as \`ifMatch\`.
 2. **Choose one discriminated command type** \u2014 the server derives its authority family;