@bettercms-ai/mcp 0.68.0 → 0.68.1

package/dist/skills/bettercms/references/components.md

@@ -196,6 +196,20 @@ A code-built site ships only what its templates draw, whatever the page's `block
      the page: the anchor carries `data-bcms-button="<key>"` and `get_binding_report` lists no
      unmatched path for it. The button field is added by that build and starts from the pair's
      label and link.
+- **Read a published value where the app renders the page** (the fix a publish that fails with
+  "Published, but this page's code doesn't read this field yet: `<key>`" names). On a route the
+  site's app renders, a stamp (`data-bcms-field`, a `bcmsBindings` entry) only says where a field
+  IS; the page shows a publish only when its code READS the value. In code, on a branch:
+  1. Read through the helper the conversion wrote (`bcms`, `bcmsRows`, `bcmsImage`, `bcmsLayout`
+     from `src/bcms-content.ts`) or the SDK's `readPublishedContent` / `publishedEntry`. Never read
+     a row of `bcms-content.json` by hand, and never bundle the file (`import`, `import.meta.glob`).
+  2. An image the page imports and passes on (`src={heroImage}` beside
+     `bcmsBindings={{ image: "<key>" }}`): pass `src={bcmsImage(<page snapshot>, "<key>", heroImage)}`.
+     The import stays the fallback; a published image is served from the copy BetterCMS places
+     beside the app. `npx @bettercms-ai/convert` makes this edit for every such call site.
+  3. Keep the hard-coded copy as the fallback argument, so a build with no content renders as today.
+  4. Open a pull request. After it is merged and the site rebuilt, publish the field again: the
+     toast reads "Live".
 
 ## 6. Preview source
 

package/dist/skills/bettercms/references/frameworks.md

@@ -127,6 +127,13 @@ generated reader. A build that fetches the snapshot and never reads it still ren
 hard-coded copy, so every edit saves, publishes and changes nothing on the page. Grep the source
 for a reader before calling a site wired.
 
+Read it through one of those, the converted-site helper (`bcms`, `bcmsRows`, `bcmsImage`) or
+`publishedEntry(slug)`. Never hand-write a parser of the file: each row holds its field values
+under `data` (`row.data.title`), so code that reads `row.title` gets `undefined` and renders its
+fallback on every publish. An editable image is `bcmsImage(page, path, importedImage)`: the bare
+import with only a stamp never shows a published image on a route the app renders. An old
+`src/utils/bcms.ts` with `pageEntry()` is that parser: replace its reads with `publishedEntry`.
+
 Build with the repo's own `build` script (`pnpm build`, `bun run build`), never the framework CLI
 directly: a repo's script often adds a type check or a post-process step the CLI skips.
 

package/dist/skills/bettercms/references/next.md

@@ -82,6 +82,9 @@ Rules:
   a live fetch would turn pages into dynamic routes, and a static export silently leaves them out
   of `out/`.
 - A preview build that must read live sets `BETTERCMS_PREVIEW=1`.
+- On a BetterCMS build the platform's own `bcms-content.json` is already in the project root.
+  `bettercms-snapshot` keeps it and `getContent` reads it: one file feeds `getContent`, `readPages`,
+  `readForms` and `readComponents`.
 - Draft mode and the revalidation route need a server; a static export has neither. Content
   changes reach a static site only by rebuilding it.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bettercms-ai/mcp",
-  "version": "0.68.0",
+  "version": "0.68.1",
   "type": "module",
   "description": "BetterCMS MCP server — schema, content, forms + components authoring tools over the Management API, authed via OAuth device-code.",
   "bin": {
@@ -32,7 +32,7 @@
   },
   "dependencies": {
     "@bettercms-ai/device-auth": "^0.2.0",
-    "@bettercms-ai/sdk": "^1.26.2",
+    "@bettercms-ai/sdk": "^1.26.3",
     "@modelcontextprotocol/sdk": "^1.30.0",
     "zod": "^4.3.6"
   },