npm - @typeroll/mcp-server - Versions diffs - 0.24.0 → 0.25.0 - Mend

@typeroll/mcp-server 0.24.0 → 0.25.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (7) hide show

package/AGENTS.md CHANGED Viewed

@@ -106,6 +106,14 @@ maps to one HTTP endpoint; the actual logic runs in the customer's portal
   working with blocks — never hardcode block ids or field names, the
   available set is per-site.
+  **The core library is larger than you'd guess (~30+ blocks): `core/image`,
+  `core/media_card`, `core/gallery`, `core/hero`, `core/feature_grid`,
+  `core/icon_box`, `core/cta`, `core/testimonial`, `core/accordion`, …** Before
+  you report a block as "missing" or reach for a `core/html` workaround, call
+  `list_block_types` and check — a real build once hand-built every illustration
+  in `core/html` and filed a false "no image block" gap because the library was
+  never enumerated. Prefer a native block; `core/html` is the last resort.
   Block-library specifics worth knowing (template_capabilities_version
   0.15.0):
   - **`core/media_card`** — image + text side by side (image left/right,
@@ -579,6 +587,20 @@ After any non-trivial change, call `get_preview_link` and ask the user
 (or your own browser tool) to confirm the result before moving on. One
 HTTP call vs. shipping a broken redesign — always worth it.
+**To UNDERSTAND a page, render it to one HTML file — don't reconstruct it
+from the block tree in your head.** A page is assembled at render time from the
+block tree + each block type's template/styles + the header/footer partials +
+the settings CSS variables + the global shell + page-scoped styles. `get_page_blocks`
+gives you the editable *structure*; `get_page_preview` gives you the rendered
+*result* — the WHOLE page as one self-contained HTML document (header + body +
+footer, with all of that CSS inlined), exactly as deployed. Read that when you
+need to see what the page actually looks like or why its CSS cascades the way it
+does (write it to a local file + serve+screenshot it to review visually). Pass
+`annotate:true` to tag every element with `data-block-id` + `data-block-type`,
+so you can map a spot in the rendered HTML straight back to the block to edit:
+read preview to understand → find the element → its `data-block-id` is the block
+to mutate → edit → re-render to verify.
 **A design review covers appearance AND readability — not just structure.**
 If you have a browser tool, screenshot at desktop (~1440px) and mobile (~390px)
 and actually judge the visuals before telling the user it's done: logo fully

package/dist/bundled-content.js CHANGED Viewed

@@ -23,6 +23,6 @@ export const BUNDLED_SKILLS = {
     "tr-seo": "---\nname: tr-seo\ndescription: Use when the user asks to improve SEO, fix meta tags, add structured data, check page titles, or audit the site's search visibility. Triggers on \"SEO\", \"meta descriptions\", \"Google ranking\", \"structured data\", \"JSON-LD\", \"sitemap\", \"sökoptimering\", or \"hjälp mig synas på Google\".\n---\n\n# SEO audit and improvements for a Typeroll site\n\n## What Typeroll handles automatically\n\n- `<html lang>` from site `language` setting (per-page override via `language` field)\n- `<title>` = `page.seo_title || page.title + settings.default_seo_suffix`\n- `<meta name=\"description\">` from `page.seo_description`\n- `<meta name=\"robots\">` from `page.noindex`\n- `<meta property=\"og:*\">` Open Graph tags from seo_title, seo_description, og_image\n- `<link rel=\"canonical\">` from `page.canonical_url` (falls back to the page's own URL)\n- Article schema from `kind: \"article\"` + `author` + `date_published`\n- Page schema from `kind: \"page\"` (default)\n- `robots.txt` from `settings.robots_txt`\n- Sanitized HTML that preserves semantic structure\n\n## Recipe\n\n### 1. Audit current state\n\n```\nlist_pages status=\"all\"\nread_site_settings\n```\n\nFor each page, check:\n- Is `seo_title` set? (if not, Google uses `title` + suffix — often fine)\n- Is `seo_description` set? (150–160 chars, unique per page, includes keywords)\n- Is `og_image` set for the homepage and key landing pages?\n- Does the page have exactly one `<h1>`?\n\n### 2. Fix missing meta descriptions\n\n```\nbatch_update_pages updates=[\n  {page_id: \"home\",     patch: {seo_description: \"Acme designar rum...\"}},\n  {page_id: \"om-oss\",   patch: {seo_description: \"Vi är ett...\"}},\n  {page_id: \"tjanster\", patch: {seo_description: \"Våra tjänster...\"}}\n]\n```\n\nGuidelines:\n- 150–160 characters\n- Include the most important keyword naturally\n- Make it a compelling reason to click, not a summary of the page's nav\n\n### 3. Fix page titles\n\nSEO title = what Google shows in search results.\n\nIf `settings.default_seo_suffix` is set (e.g. \" — Acme Studio\"), every\npage whose `seo_title` is empty will show `title + suffix`. That's usually\nfine for inner pages; set an explicit `seo_title` only when you want\nsomething different.\n\n```\nupdate_site_settings {\"default_seo_suffix\": \" — Acme Studio\"}\n\nupdate_page page_id=\"home\" patch={\n  \"seo_title\": \"Acme Studio — Inredningsdesign i Stockholm\"\n}\n```\n\n### 4. Add Open Graph images\n\nSet `og_image` on pages that get shared on social media. If the site has\na branded hero image, upload it:\n\n```\nupload_media_from_url url=\"https://...\" alt=\"Acme Studio — Inredningsdesign\"\n# → returns cdn_url\n\nbatch_update_pages updates=[\n  {page_id: \"home\",     patch: {og_image: \"<cdn_url>\"}},\n  {page_id: \"om-oss\",   patch: {og_image: \"<cdn_url>\"}}\n]\n```\n\nOG image dimensions: 1200×630px ideal. The platform doesn't resize —\nuse a correctly-sized source image.\n\n### 5. Add structured data (JSON-LD)\n\nTyperoll auto-generates Article and Page schema, but you can override or\nextend with custom JSON-LD per page. Example: LocalBusiness on the homepage.\n\n```\nupdate_page page_id=\"home\" patch={\n  \"json_ld\": \"{\\\"@context\\\":\\\"https://schema.org\\\",\\\"@type\\\":\\\"LocalBusiness\\\",\\\"name\\\":\\\"Acme Studio\\\",\\\"url\\\":\\\"https://acme.se\\\",\\\"telephone\\\":\\\"+46812345\\\",\\\"address\\\":{\\\"@type\\\":\\\"PostalAddress\\\",\\\"streetAddress\\\":\\\"Drottninggatan 1\\\",\\\"addressLocality\\\":\\\"Stockholm\\\",\\\"postalCode\\\":\\\"111 51\\\",\\\"addressCountry\\\":\\\"SE\\\"}}\"\n}\n```\n\n**Important:** JSON-LD goes in the `json_ld` field as a JSON *string*\n(not a nested object). The renderer injects it inside\n`<script type=\"application/ld+json\">`.\n\nCommon schemas worth adding:\n- Homepage: `LocalBusiness` or `Organization`\n- About: `AboutPage`\n- Contact: `ContactPage`\n- Blog articles: auto-generated from `kind:\"article\"` + `author`\n- Events: `Event` with `startDate`, `location`\n- Products: `Product` with `offers`\n\n### 6. robots.txt\n\nThe default robots.txt allows all crawlers. Update if needed:\n\n```\nupdate_site_settings {\n  \"robots_txt\": \"User-agent: *\\nAllow: /\\nSitemap: https://acme.se/sitemap.xml\"\n}\n```\n\nTyperoll doesn't generate a sitemap automatically in phase 1. If the\ncustomer needs one, create a `/sitemap` page with HTML that lists all\npublished pages, or write a static `sitemap.xml` as a page with\n`slug: \"sitemap.xml\"` and HTML-encoded XML (not recommended for large sites).\n\n### 7. Canonical URLs\n\nSet `canonical_url` when a page has a duplicate (e.g. the same content\naccessible via two slugs after a migration):\n\n```\nupdate_page page_id=\"tjansterna\" patch={\n  \"canonical_url\": \"https://acme.se/tjanster\",\n  \"noindex\": true\n}\n```\n\n### 8. Language settings\n\n```\nupdate_site_settings {\"language\": \"sv\"}\n```\n\nPer-page override for multilingual content:\n```\nupdate_page page_id=\"about-en\" patch={\"language\": \"en\"}\n```\n\n### 9. Heading audit\n\nUse `search_pages` to find structural problems:\n\n```\nsearch_pages contains=\"<h1\"      # pages that have at least one H1\n```\n\nThen `read_page` on pages that seem to have none or multiple. Fix via\n`update_page patch={html_content: \"<corrected HTML>\"}`.\n\n### 10. Deploy\n\n```\ntrigger_deploy\nget_deploy_status job_id=<id>\n```\n\n## Pitfalls\n\n- **Don't stuff keywords.** Write descriptions for humans. Google ignores\n  `<meta name=\"keywords\">` (not a field in Typeroll anyway).\n- **JSON-LD is a string, not a nested field.** Pass the entire schema as\n  a JSON-encoded string in `json_ld`. The server escapes `</script` before\n  injection.\n- **OG images need absolute URLs.** The `cdn.typeroll.com` URLs are always\n  absolute — use those.\n- **`canonical_url` + `noindex` together.** If you noindex a page AND set\n  canonical, the canonical is redundant (noindexed pages don't pass equity).\n  Use one or the other.\n- **Default suffix on homepage looks odd.** \"Acme Studio — Acme Studio\"\n  happens when title=\"Acme Studio\" and suffix=\" — Acme Studio\". Set an\n  explicit `seo_title` for the homepage.\n"
 };
 export const BUNDLED_DOCS = {
-    "agents": "# AGENTS.md — Working on a Typeroll site\n\nYou are connected to a Typeroll site through `@typeroll/mcp-server`.\nThis file is your briefing: what the system is, what conventions matter,\nwhat tools to reach for first.\n\nIf anything below conflicts with what you observe in the tools, trust the\ntools — the platform may have moved since this was written.\n\n**Start here for site-shaped tasks.** When the user wants to build,\nmigrate, redesign, or brand a site, call `list_skills` first — the server\nadvertises its own step-by-step playbook (`tr-new-site`, `tr-migrate-wp`,\n`tr-brand`, …). Then `read_skill name=…` loads the full recipe. These are\nlocal reads; no API key or site context required.\n\n**Branch first for anything larger than a small edit.** Before a redesign,\na multi-page change, or trying out a new design direction, run\n`create_branch name=\"…\"` and pass the returned id as `version=<id>` on every\nsubsequent read/write. The work stays off the live `main` version until you\n`merge_branch` it — nothing ships until you decide it should. Branches default\n`robots_blocked:true` and get their own deploy URL for stakeholder review.\nIt's the cheapest insurance there is; when in doubt, branch. The\n`tr-redesign-branch` skill walks the whole flow. (Small, low-risk single edits\ncan go straight to main.)\n\n## What this is\n\nTyperoll is a static-site CMS: content lives in a database, the user\nedits it through an in-app editor, and a deploy step compiles everything\nto a fast static site hosted on Cloudflare Pages. The in-app chat handles\nsingle-page or single-block edits by the editor audience. You — through\nthis MCP — handle the work that doesn't fit there: site-wide redesigns,\nbulk content updates, structural migrations, directory imports.\n\nThe MCP server is a thin wrapper around the public REST API. Each tool\nmaps to one HTTP endpoint; the actual logic runs in the customer's portal\n(SaaS or self-hosted).\n\n## The data model in 90 seconds\n\n- **Pages.** Title, slug, status (`draft | review | unlisted | published`),\n  body content + SEO fields. Two body shapes selectable per page via\n  `content_mode`:\n  - `blocks` (DEFAULT for new pages) — `blocks: Block[]` tree of typed\n    blocks (heading, prose, section, columns, image, button, plus any\n    user/third-party block types installed on the site). Use the\n    block-mutation tools (`add_block`, `update_block`, `move_block`,\n    `remove_block`) for structural changes.\n  - `html` — body lives in `html_content` as a single HTML string.\n    Useful when you have hand-written markup to drop in directly.\n\n  Slug is a single path segment — no slashes. `about` → `/about`,\n  `kontakt` → `/kontakt`, empty string `\"\"` → homepage. The v1 API\n  rejects `services/design` and other slash-containing slugs with\n  \"Invalid slug … slugs must not contain slashes.\" For nested URLs\n  like `/blog/{slug}` or `/services/{slug}`, the right primitive is a\n  **collection with `route_template`** (see the `tr-blog` and\n  `tr-directory` skills) — not a flat page with a slashed slug.\n\n- **Partials = global blocks.** Three kinds:\n  - `header` — auto-injected at the top of every page.\n  - `footer` — auto-injected at the bottom of every page.\n  - `free` — reusable HTML you drop into a page with\n    `<x-include name=\"block-id\" />`. Free blocks are how you avoid\n    duplicating HTML across HTML-mode pages.\n\n  Partials themselves also support `content_mode='blocks'` — pass a\n  `blocks: Block[]` tree to `update_partial` and the renderer composes\n  it the same way as a page. Useful for header/footer authored with\n  block types.\n\n- **Collections.** Repeatable content types (blog, team, events,\n  products, restaurants for a directory site, etc.). Each has a schema\n  (`fields[]`) and optional **per-item routing** via `route_template`\n  (e.g. `/restaurants/{slug}`). When set, every published item gets its\n  own static URL rendered through `item_template_html`. Set\n  `route_template=\"\"` to opt out and keep the collection listing-only.\n\n- **Settings.** Site name, tagline, logo, favicon, colors, fonts,\n  contact info, social links, SEO suffix, default meta description\n  (`default_meta_description` — site-wide fallback for pages without a\n  `seo_description`; tagline is the last resort), plus `scripts_head`,\n  `scripts_body_end`, `custom_css` (writable via the API — your bearer\n  token authorises shipping arbitrary CSS/JS to the live site, just\n  like editing a partial's HTML does).\n\n- **Page templates.** A `PageTemplate` is a Block[] tree that wraps a\n  page's body. The template contains exactly one block of type\n  `template_content_slot` — at render time that block gets replaced by\n  the page's own `blocks`. Set `Page.template = \"<template-id>\"` to\n  apply a template to a page.\n\n- **Block types.** A site has three sources of block types:\n  - **Core** (origin: 'core', ids like `core/section`) — shipped in\n    the platform, always available.\n  - **User** (origin: 'user') — created in the portal's block-types UI.\n  - **Third-party** (origin: 'third_party') — imported from .tcblocks\n    packages via `import_block_types`.\n\n  `list_block_types` returns ALL of them in one list as a lightweight\n  summary: each entry's id, label, category, container/slot info, origin,\n  and full field schema (names, types, defaults) — but NOT the render-time\n  template/styles/script (omitted so the list stays within token budget as\n  the library grows). Use `read_block_type` for one block's markup, or pass\n  `full:true` to inline it for every block. Always call this FIRST before\n  working with blocks — never hardcode block ids or field names, the\n  available set is per-site.\n\n  Block-library specifics worth knowing (template_capabilities_version\n  0.15.0):\n  - **`core/media_card`** — image + text side by side (image left/right,\n    width third/two-fifths/half, heading + richtext + button, optional\n    card background/radius; stacks image-on-top below 720px). Use it for\n    the classic \"photo next to copy\" layout instead of hand-building\n    section+grid+html.\n  - **`core/hero` and `core/cta` render their buttons server-side** via\n    `primary_label`/`primary_url` + `secondary_label`/`secondary_url`.\n    (The old `buttons` array relied on client hydration that never\n    existed — if you see `data-buttons` in stored content it renders\n    nothing; rebuild with the explicit fields.)\n  - **`core/image` gets responsive `<picture>` automatically at build\n    time** — the deploy pipeline's SEO transform converts CDN `<img>`\n    into `<picture>` with AVIF/WebP srcset variants. You do NOT need\n    `core/html` for responsive images; just point `src` at an uploaded\n    media URL (run `generate_image_variants` first) and optionally set\n    `radius`. Note: the in-portal preview shows the plain `<img>` — the\n    `<picture>` upgrade appears on the deployed site.\n  - **Icons render inline SVG** (since template_capabilities_version\n    0.16.0). Every `type: 'icon'` schema field — on `core/icon`,\n    `core/icon_box`, `core/step_card`, and custom block types — renders\n    a stroke-based inline SVG when the value is a name from\n    `get_site_capabilities → core_icon_names` (a curated Lucide subset:\n    `check`, `star`, `shield-check`, `mail`, `arrow-right`, `zap`,\n    `truck`, `chart-line`, …). Any other value (emoji, plain text) is\n    rendered as escaped text, so emoji stand-ins keep working. Icons\n    size with `font-size` (the SVG is 1em) and paint with\n    `currentColor`. Custom block templates opt in by placing the derived\n    raw token `{{{<field>_svg}}}` where the icon should appear. On\n    pre-0.16.0 portals icons don't render — use emoji or CSS markers.\n    `core/tabs` label icons are the remaining gap (tab strip is built\n    client-side).\n  - **Grids with a partial last row: set `last_row: 'center'`** (since\n    template_capabilities_version 0.16.5). Five equal cards in a 3-col\n    `core/grid` (or 7 in 4, ...) left-align the orphans by default; with\n    `last_row: 'center'` the last row auto-centers. THE DESIGN RULE: when\n    N peer cards don't divide by the column count, center the last row or\n    change the column count — NEVER invent a \"wide\"/full-width variant of\n    one peer card just to fill the hole. Special treatment is a content\n    decision, not a layout patch.\n  - **`core/section` is natively full-bleed on block pages** (since\n    template_capabilities_version 0.14.0): the section's background runs\n    edge-to-edge and meets the header with zero gap; content inside is\n    constrained by the section's own inner container (`width` field:\n    narrow/normal/wide/full). Never use 100vw negative-margin hacks.\n    Top-level blocks that are NOT sections still get a classic centered\n    container as fallback. Anchor ids and custom classes via\n    `style_overrides` are safe on full-bleed sections since 0.15.3 —\n    they merge into the `<section>` element itself. On 0.14.x–0.15.2\n    they wrapped the section in a `<div>`, which silently disabled\n    full-bleed for that section.\n  - **Shaped section transitions** (since template_capabilities_version\n    0.24.0): `core/section` takes `divider_top` / `divider_bottom`\n    (`none | wave | curve | tilt`). The platform paints the divider in the\n    section's OWN `background` and overlaps the neighbour by 1px, so a\n    cream↔colour transition renders seam-free. **Use this for waves/curves —\n    never hand-roll a divider band in `core/html`** (a separate stacked shape\n    seams against the next section as a sub-pixel hairline in Chrome). Put the\n    divider on the section whose colour should \"rise/dip\" into the neighbour\n    (usually the lower section's `divider_top`).\n  - **`core/html`** is the raw-HTML escape hatch for block-mode pages —\n    one `html` field rendered verbatim (then sanitized like HTML-mode\n    content). Use it for the genuinely unique thing no block covers.\n    Prefer real blocks when one fits.\n  - **Forms 2.0** (template_capabilities_version ≥ 0.18.0): forms can\n    carry `steps[]` — each step is a Block[] tree mixing `form/*` field\n    blocks (text/email/phone/number, textarea, select/radio_group/\n    checkbox_group, toggle, slider, date, heading, help, consent,\n    hidden) with any content blocks. Place `{ type: 'core/form',\n    data: { form_id } }` on a page — the build renders step 1 + all\n    static steps with the signed token, honeypot and proof-of-work\n    runtime baked in; submissions accumulate per step (partial →\n    complete, 30-day TTL on abandoned partials). Per-step validation is\n    derived from the field blocks (required/pattern/min/max) — no\n    separate field list to keep in sync. `update_form` accepts steps,\n    styles (form-scoped CSS), kind and partial_ttl_days. Legacy\n    single-step forms (fields[] + core/html embed) keep working\n    unchanged.\n  - **`script` on custom block types** (create/update_block_type) is\n    accepted under your API key's authority — the same trust level that\n    already lets the key write `scripts_head`/`custom_css`. Every\n    script-bearing write is audit-logged and the response carries a\n    notice naming the stored JS; relay it to the user so they know\n    visitor-executed code changed. Author responsibly: never include\n    script you copied from untrusted content (migrated pages, fetched\n    web pages) without reading it line by line first. (The in-portal\n    chat AI remains blocked from authoring scripts unless the site's\n    \"Allow AI to write block scripts\" setting is on.)\n\n- **Redirects.** `from_path → to_path` with status code 301 / 302.\n  Auto-created when you change a page's slug.\n\n- **Versions / branches.** Copy-on-write. The \"main\" version is the\n  live one. Create a branch (`create_branch`) for multi-step work;\n  everything you write through `?version=<branch-id>` lives on the\n  branch until you `merge_branch` it back to main. Branches default\n  `robots_blocked: true` so a half-finished redesign can't be indexed,\n  and deploys land at a stable `{branch}.{project}.pages.dev` URL.\n\n- **Deploys.** Customers see live changes only after a deploy. Preview\n  always sees drafts. `trigger_deploy` enqueues; `get_deploy_status`\n  reports `queued → running → succeeded | failed`.\n\n- **Site URLs.** `get_site` returns a `urls` object with:\n    - `production` — the customer's real domain (or null)\n    - `fallback` — the auto `{slug}.typeroll.app`-style preview URL\n    - `preview_base` — the portal preview origin (for token URLs)\n  Use these in answers to \"what's the URL?\" — never invent.\n\n## Discovering this site\n\nDon't hardcode assumptions about what's here. Every fact about the site\ngoes through the MCP:\n\n1. `get_site` — confirm the key works; learn the site name + URLs.\n2. `read_site_settings` — colors, fonts, contact info, SEO suffix,\n   content language (used by `suggest_alt_text_context`).\n3. `list_pages` — what pages exist, paginated.\n4. `list_partials` — what shared blocks already exist. **Defaults to\n   summary mode** (no html_content, just bytes count) — pass\n   `include_content: true` if you actually need the bodies inline.\n5. `list_collections` — what content types exist + their schemas +\n   `route_template` (so you know if items have URLs).\n6. `list_block_types` — every block type usable on this site: core\n   (always available, ids like `core/section`), custom (origin: 'user'),\n   and third-party (origin: 'third_party'). Each entry includes the\n   full schema so you know what `data.X` fields each block accepts.\n7. `list_page_templates` — PageTemplate docs that wrap pages.\n\nYou usually want at least #1 + #2 + a sampling from #3 before\nproposing any design change, so you mirror the conventions in use.\n\n**Source of truth = the live site (the API), by default.** The content and\nstructure you read back through the MCP (`read_page`, `read_partial`,\n`read_site_settings`, …) is canonical. Local files in the project folder —\n`sources/*.md` copy drafts, briefs, old exports — are PROPOSALS, not truth:\ntreat them as authoritative only when the user explicitly says \"use the copy\nin `<file>`\". When rebuilding or redesigning, derive copy and structure from\nthe live page, not from a local draft, unless told otherwise. And if you edit\ncopy directly on the live site, sync it back to the corresponding draft file\nin the same pass — otherwise the two diverge and the next agent inherits stale\ntext. (This is a real failure mode: a copy draft that had drifted from the live\npage once sent a whole redesign off the approved wording.)\n\n**Don't have a site yet?** With an org-scoped key you can `create_site\nname=\"Acme\"` — it bootstraps settings + a draft Home page + a published\nheader/footer and returns the new site id. Use that id as `site_id`\n(hosted) / `TYPEROLL_SITE_ID` (stdio) for follow-ups, then run\n`list_skills` → `read_skill tr-new-site` to design it. A site-scoped key\ncan't create sites (it's bound to one) and gets a 403.\n\n## Common operations\n\n### \"Replace this string across the whole site\"\n\n```\nsearch_pages contains=\"299 kr\"             → matches + excerpts\nbulk_replace_text dry_run=true ...          → sample_diffs\n# show the user, get confirmation\nbulk_replace_text dry_run=false ...         → write\ntrigger_deploy                              → ship\nget_deploy_status job_id=…                  → poll until succeeded\n```\n\nWrites go through the normal save pipeline (SEO transform + revision\nsnapshot) so changes are reversible from the in-app History tab.\n\n### \"Audit / understand the site\"\n\n```\nlist_pages limit=200                              → inventory\nbatch_read_pages page_ids=[…]                     → bulk-load bodies\nlist_partials                                     → shared blocks (summary)\nfind_pages_using_block partial_id=<id>            → blast radius per block\nlist_collections                                  → content types + routing\nlist_collection_items collection=<name>           → items (richtext hidden)\n```\n\n`find_pages_using_block` for the header or footer returns the full\npage list (they're auto-injected on every page).\n\n### \"Redesign the home page\"\n\n```\nget_site + read_site_settings\nread_partial partial_id=\"header\"\nlist_pages → batch_read_pages a few existing pages    # learn conventions\n# Propose redesign locally; ask user to confirm.\ncreate_branch name=\"Home redesign\"                    # ID is, say, \"home-redesign\"\nupdate_page page_id=home patch={ html_content: \"…\" } version=home-redesign\nget_preview_link page_id=home version=home-redesign   # signed clickable URL\n# Iterate. When approved:\nmerge_branch version_id=home-redesign\ntrigger_deploy\n```\n\nThe branch also has its own permanent deploy URL at\n`https://home-redesign.<project>.pages.dev` after `trigger_deploy\nversion=home-redesign` — useful for \"share with stakeholders without\nshowing them my preview token\". `read_version version_id=home-redesign`\nreturns it as `deploy_url`.\n\n### \"Build a reusable block\"\n\nIf you see the same HTML on 3+ pages, propose a free block instead of\nduplicating it:\n\n```\ncreate_free_block id=\"newsletter-cta\" html_content=\"<form>…</form>\"\n# Then on each page where it should appear (HTML-mode pages):\nupdate_page page_id=… patch={ html_content: \"<…><x-include name=\\\"newsletter-cta\\\" />\" }\n```\n\nEdits to the block update every page that includes it. Use\n`find_pages_using_block` before changing it.\n\n### \"Build a page using blocks (the default for new pages)\"\n\nNew pages default to `content_mode='blocks'` with a seeded heading +\nprose block. Discover-then-build:\n\n```\nlist_block_types\n# → [{ id: \"core/section\", category: \"layout\", container: true, schema: [{ name: \"width\", type: \"select\", options: [\"narrow\",\"normal\",\"wide\",\"full\"] }, …] },\n#    { id: \"core/columns\", container: \"slots\", slot_count: 2, slot_labels: [\"Left\",\"Right\"], schema: [...] },\n#    { id: \"hero_bold\", origin: \"user\", schema: [...] },   ← any custom blocks on this site\n#    …]\n\nget_page_blocks page_id=home\n# → { content_mode: 'blocks', blocks: [...] }\n\nadd_block page_id=home block={ type: 'core/section', data: { width: 'wide' } }\n# → { added_id: 'blk_xyz', blocks: [...] }\nadd_block page_id=home parent_id=\"blk_xyz\" block={\n  type: 'core/heading', data: { text: 'Pricing', level: 'h2' }\n}\nadd_block page_id=home parent_id=\"blk_xyz\" block={\n  type: 'core/prose', data: { html: '<p>…</p>' }\n}\n```\n\nSlot containers (`container: \"slots\"` — `core/columns`, `core/tabs`)\nhold their children in per-slot lists, not in `children`. Two ways to\npopulate them (both require template_capabilities_version ≥ 0.15.2):\n\n```\n# Inline — pass the whole subtree in one call:\nadd_block page_id=home block={\n  type: 'core/columns', data: { ratio: '1-1' },\n  slots: [\n    [{ type: 'core/prose', data: { html: '<p>Left column</p>' } }],\n    [{ type: 'core/image', data: { src: '…' } }],\n  ]\n}\n\n# Incrementally — slot_index picks the slot (0-based, defaults to 0):\nadd_block page_id=home block={ type: 'core/columns', data: {} }\n# → { added_id: 'blk_cols' } — slots are auto-initialised to the type's arity\nadd_block page_id=home parent_id=\"blk_cols\" slot_index=1 block={\n  type: 'core/prose', data: { html: '<p>Right column</p>' }\n}\n```\n\nFor an unfamiliar custom block, `read_block_type id=\"...\"` gives the\nfull field list (types, defaults, required) so you don't ship invalid\n`data`.\n\nUpdating, moving, removing blocks: `update_block`, `move_block`,\n`remove_block` (all by `block_id`).\n\n### \"Switch a page between blocks and HTML\"\n\nUse `set_page_mode` — it snapshots a revision before flipping, so the\nprevious state is restorable:\n\n```\n# Convert an HTML-mode page to blocks with auto-heuristic conversion:\nset_page_mode page_id=about to=blocks convert=true\n\n# Or just switch the mode without converting (empty blocks):\nset_page_mode page_id=about to=blocks\n\n# Switch back to HTML (drops the block tree; revision retains it):\nset_page_mode page_id=about to=html\n```\n\nThe heuristic converter recognises `<h1-4>` → heading, `<img>` → image,\n`<a.btn>` → button, `grid-cols-2` → two-column, `<section>` / hero divs\n→ section. Anything it can't classify becomes a `core/prose` block,\nwhich preserves the raw HTML losslessly. Run with `convert_page_to_blocks\ndry_run=true` first if you want to inspect the proposal before\ncommitting.\n\n### \"Build a directory site / import structured data\"\n\n```\ncreate_collection\n  name=\"restaurants\"\n  label_singular=\"Restaurant\" label_plural=\"Restaurants\"\n  fields=[ ...title, slug, address, phone, cuisine, body... ]\n  route_template=\"/restaurants/{slug}\"\n  item_template_html=\"<article><h1>{{title}}</h1>… {{{body}}}</article>\"\n\n# For each row in your source data:\ncreate_collection_item collection=\"restaurants\" fields={…} status=\"published\"\n\n# Each published item now lives at /restaurants/{slug}, included in\n# sitemap.xml. Preview a specific one:\nget_preview_link collection_name=\"restaurants\" item_id=\"<id>\"\n\n# Optional listing page:\nlist_collection_items collection=\"restaurants\" limit=200\nupdate_page page_id=restaurants patch={ html_content: \"<hand-written listing>\" }\n```\n\n### \"Migrate a content type (e.g. WP custom post type)\"\n\n```\nlist_collections                                     # what exists today?\nread_collection name=blog                            # what fields are writable?\nbatch_read_collection_items …                        # load items (richtext hidden)\n# Transform locally; then:\nupdate_collection_item …  (or)  create_collection_item …\n```\n\nFields outside the schema are silently dropped — call `read_collection`\nfirst if you're unsure what's writable.\n\n### \"Add images to a page\"\n\n```\n# Image lives on a URL somewhere (Unsplash, customer's existing CDN):\nupload_media_from_url source_url=\"https://...\" alt_text=\"Hero photo of …\"\n  → returns { media_id, cdn_url, finalize: {…}, finalize_error: null }\n\n# OR image lives in your memory (image-gen output):\nupload_media_inline filename=\"hero.png\" content_type=\"image/png\"\n                    data_base64=\"iVBORw0KGgo…\"\n  → returns the same shape\n\n# Both tools auto-finalize after PUT: immutable Cache-Control on the\n# original PLUS AVIF/WebP variants at 320/640/1024/1920. No manual\n# generate_image_variants call needed. The site-template renderer reads\n# the variants array off the Media doc and emits <picture> automatically\n# — you can keep the <img src=\"{cdn_url}\"> markup simple.\n\n# Then embed in a page:\nread_page page_id=...\nupdate_page page_id=... patch={ html_content: \"<...><img src='{cdn_url}' alt='…' /></...>\" }\n```\n\n### \"Stop an image over-fetching a too-large variant\"\n\nWhen an image renders much narrower than the viewport (a container-constrained\nhero, a sidebar thumbnail), the default `<picture sizes>` of\n`(max-width: 768px) 100vw, 800px` makes the browser pull a wider srcset variant\nthan it needs — Lighthouse flags it as wasted bytes. Three levers, narrowest\nwins:\n\n```\n# 1. Per-image: put a real `sizes` on the <img>. Survives the transform verbatim.\nupdate_page page_id=... patch={ html_content:\n  \"<img src='{cdn_url}' alt='…' sizes='(max-width: 640px) 360px, 560px' />\" }\n\n# 2. Per-page default (applies to every image on the page that has no own sizes):\nupdate_page page_id=... patch={ image_sizes_default: \"(max-width: 640px) 360px, 560px\" }\n\n# 3. Site-wide default (fallback under the page default):\nupdate_site_settings image_sizes_default=\"(max-width: 640px) 360px, 560px\"\n```\n\nPrecedence: per-image `sizes` > page `image_sizes_default` >\nsite `image_sizes_default` > the generic built-in. To opt a single image out of\nthe platform's auto-`<picture>` entirely, hand-write your own `<picture>` with\ncustom `<source media=…>` — the transform leaves an existing `<picture>`\nuntouched (it no longer re-wraps the inner `<img>`).\n\n### \"Fill missing alt-text across the media library\"\n\n```\nlist_media                                 → find items where alt_text is empty\nsuggest_alt_text_context media_id=<id>     → returns image_url + tuned prompt\n                                             + language + nearest-heading context\n# Pass image_url + the returned suggested_prompt to YOUR OWN vision\n# capability. The platform does NOT run vision for you.\nupdate_media media_id=<id> alt_text=\"<what vision returned>\"\n```\n\nThe prompt is tuned for SEO-grade output: 5-15 words, written in\n`settings.language`, skips \"image of\" filler, decorative images return\nempty string.\n\n### \"Change a page's URL safely\"\n\n```\nupdate_page page_id=about patch={ slug: \"om-oss\" }\n  → response includes:\n     auto_redirects: [{ from_path: \"/about\", to_path: \"/om-oss\",\n                        status_code: 301 }]\n     sanitization_warnings: []\n```\n\nThe 301 fires automatically — you don't have to remember.\n\nRedirect hygiene is automatic in both directions (since 0.16.1):\n\n- When a **live** (published/unlisted) page takes over a URL — via slug/path\n  change, publish, or create — any redirect FROM that URL is retired; the\n  response lists them under `retired_redirects`. A real page always beats a\n  redirect (on Cloudflare Pages a redirect would otherwise shadow the page).\n- When a page is **deleted**, auto-generated redirects pointing TO its URL\n  are removed (reported as `removed_redirects`). Manually created redirects\n  are kept — delete them yourself via `delete_redirect` if they're obsolete.\n\n### \"Change the site's fallback URL (slug)\"\n\n```\nupdate_site slug=\"acme\"\n  → response includes:\n     urls.fallback: \"https://acme.sites.typeroll.com\"\n     dns_note: \"New fallback URL … attached to CF Pages. SSL provisioning\n                takes 1–10 minutes after DNS propagates. …\"\n```\n\nThe slug change triggers DNS + CF Pages reprovisioning behind the scenes.\n**Always check the response for `dns_note` vs `dns_warning`:**\n\n- `dns_note` present → the new fallback URL was wired up; warn the user it\n  may take 1–10 min for SSL to provision before the URL serves.\n- `dns_warning` present → the slug was saved but DNS / CF attach failed.\n  The `urls.fallback` field is still returned (it's just `{slug}.{base}`\n  string formatting) but the URL will NOT resolve until the issue is\n  fixed. Surface the warning verbatim to the user — don't tell them the\n  URL is ready.\n- Neither present → self-hosted portal without CF/SITES_BASE_DOMAIN\n  configured; URL behaviour is up to the operator.\n\nThe old fallback URL keeps working (bookmarks + SEO survive). Customer\ncan manually deprovision the old one via the portal.\n\n## Safety boundaries\n\n- **HTML is sanitized at save.** No `<script>`, no `onclick`, no\n  `javascript:` URLs in page or partial bodies. `<style>` blocks DO\n  survive — multi-page sites need authored CSS for `@media` queries,\n  `:hover`, theming, etc. Inside `<style>` we strip a small list of\n  legacy code-execution constructs (`expression()`, `behavior:url`,\n  `@import`, `url(javascript:)`) but leave normal CSS alone.\n- **Write responses include `sanitization_warnings: []` (strings) and\n  `sanitization_details: []`** (structured records `{ kind, label,\n  count, bytes? }`). Use the structured form to programmatically retry\n  with a fixed input.\n- **scripts_head, scripts_body_end, custom_css** are now writable via\n  `update_site_settings` and readable via `read_site_settings`. Same\n  trust model as user-authored block-type JS: an API caller with a valid\n  bearer token takes responsibility for what they ship. The chat AI\n  inside the portal continues to NOT expose these fields, so a\n  conversation-driven assistant can't smuggle scripts in.\n- **The API key is site-scoped.** Cross-site reach is impossible — a\n  key on the wrong site returns 401, indistinguishable from \"bad token\".\n- **Audit log.** Every state-changing call (POST / PATCH / PUT /\n  DELETE) is logged. Reads aren't. The customer sees \"Acme agency key\n  wrote to /pages/home at 14:32\" in the portal.\n- **Rate limits.** 600 reads/min, 60 writes/min per key. On 429 the\n  response carries `Retry-After`.\n\n## Preview-driven workflow\n\nAfter any non-trivial change, call `get_preview_link` and ask the user\n(or your own browser tool) to confirm the result before moving on. One\nHTTP call vs. shipping a broken redesign — always worth it.\n\n**A design review covers appearance AND readability — not just structure.**\nIf you have a browser tool, screenshot at desktop (~1440px) and mobile (~390px)\nand actually judge the visuals before telling the user it's done: logo fully\nvisible (not cut off by a header's overflow:hidden + overlap margin) + legible +\nbrand-compliant against its real background — screenshot the header in page\ncontext, NOT the logo element in isolation (an element shot renders the full SVG\nand hides layout clipping); a light/yellow wordmark must not sit bare on a light\nsurface without its plate. Text contrast on every\nband, no horizontal scroll (`scrollWidth === clientWidth` at 360–390px), no\nmid-word breaks, all images rendered, mobile layout actually collapsed. \"Copy\npresent + no overflow + images 200\" is a structural check, NOT a design review —\nnever report a design as perfect/approved off structural metrics alone.\n\nPreview shows DB state (drafts included). Live (`get_site → urls.production`)\nshows the most recent deploy. Branch deploys live at\n`get_version → deploy_url` (`{branch}.{project}.pages.dev`).\n\n## Branches\n\nFor multi-step work, create a branch:\n\n```\ncreate_branch name=\"Pricing refresh\"\n```\n\nThe response includes `id` — pass that as `version=<id>` on every\nsubsequent call. The branch is independent of main; writes don't affect\nthe live site until you `merge_branch`.\n\nBranches default `robots_blocked: true`. Deploys to a branch land at a\nstable, share-able URL (`{branch}.{project}.pages.dev`); use that for\nstakeholder review.\n\n## When in doubt\n\n- **Read before you write.** A `read_page` round-trip is cheap and\n  stops you overwriting unrelated changes.\n- **Dry-run bulk operations.** `bulk_replace_text` accepts `dry_run:\n  true` and returns 3 sample diffs. Show them to the user before the\n  real run.\n- **Watch the sanitization_warnings array.** If it's non-empty, the\n  stored HTML differs from what you sent. Read it back to confirm.\n- **One small confirmation > one large undo.** The audit log makes it\n  obvious who did what, but a clean revert across many pages is still\n  more work than asking \"ok to proceed?\" first.\n- **Match the site's design.** Read a partial or two before designing\n  new components. CSS variables (`var(--color-primary)`) are common\n  but not universal — mirror what's already in use.\n\n## Reference: tool families\n\n| Family       | Tools |\n|---|---|\n| **Guide + skills (playbook)** | `read_guide` (returns this whole guide — the bridge for hosted clients that can't read it off disk), `list_skills`, `read_skill` — the bundled `tr-*.md` recipes (incl. `tr-responsive` for per-breakpoint layout). Call `list_skills` first when a task looks like \"build / migrate / redesign a site\", then `read_skill name=…`. No API key or site context needed. |\n| **Discovery** | `get_site`, `create_site` (org-scoped key only — see below), `update_site`, `list_versions`, `read_site_settings` |\n| **Pages — reads** | `list_pages`, `read_page`, `batch_read_pages` |\n| **Pages — writes** | `create_page`, `update_page`, `replace_page`, `batch_update_pages`, `delete_page`, `clone_page` |\n| **Pages — blocks** | `get_page_blocks`, `add_block`, `update_block`, `move_block`, `remove_block`, `set_page_mode`, `convert_page_to_blocks` |\n| **Pages — meta** | `get_page_preview` |\n| **Global blocks (partials)** | `list_partials` (summary by default), `read_partial`, `create_free_block`, `update_partial`, `replace_partial`, `delete_partial`, `find_pages_using_block`, `list_blocks_with_usage` |\n| **Block types** | `list_block_types`, `read_block_type`, `find_pages_using_block_type`, `export_block_types`, `import_block_types` |\n| **Collections** | `create_collection`, `update_collection_schema`, `delete_collection`, `list_collections`, `read_collection`, `list_collection_items` (richtext hidden by default), `read_collection_item`, `batch_read_collection_items`, `create_collection_item`, `update_collection_item`, `delete_collection_item`, `regenerate_collection_listing` |\n| **Media** | `list_media`, `read_media`, `create_upload_url`, `upload_media_from_url`, `upload_media_inline`, `update_media`, `delete_media`, `finalize_media`, `finalize_all_media`, `generate_image_variants`, `suggest_alt_text_context` |\n| **Redirects** | `list_redirects`, `create_redirect`, `delete_redirect` |\n| **Forms** | `list_forms`, `read_form`, `create_form`, `update_form`, `delete_form`, `list_form_submissions`, `delete_form_submission` (removes one submission — e.g. cleaning up a test entry; `delete_form` with `delete_submissions` is the bulk path). read/create return `submit_token` + `submit_url` — embed as a plain `<form method=\"POST\">` with a hidden `_token` input + empty honeypot `_hp`; no client JS (the sanitizer strips inline `<script>`; the endpoint answers form posts with an HTML confirmation page) |\n| **Settings** | `update_site_settings` (whitelist) |\n| **Search + bulk** | `search_pages`, `bulk_replace_text` |\n| **Branches** | `create_branch`, `read_version`, `delete_branch`, `merge_branch` |\n| **Deploy** | `trigger_deploy`, `list_deploys`, `get_deploy_status` |\n| **Preview** | `get_preview_link`, `get_page_preview` |\n\nEvery tool's input is validated server-side; the MCP server only does\nauth + shape. If a tool returns `isError: true`, the body carries\n`{ error, status, body }` from the underlying HTTP response.\n",
+    "agents": "# AGENTS.md — Working on a Typeroll site\n\nYou are connected to a Typeroll site through `@typeroll/mcp-server`.\nThis file is your briefing: what the system is, what conventions matter,\nwhat tools to reach for first.\n\nIf anything below conflicts with what you observe in the tools, trust the\ntools — the platform may have moved since this was written.\n\n**Start here for site-shaped tasks.** When the user wants to build,\nmigrate, redesign, or brand a site, call `list_skills` first — the server\nadvertises its own step-by-step playbook (`tr-new-site`, `tr-migrate-wp`,\n`tr-brand`, …). Then `read_skill name=…` loads the full recipe. These are\nlocal reads; no API key or site context required.\n\n**Branch first for anything larger than a small edit.** Before a redesign,\na multi-page change, or trying out a new design direction, run\n`create_branch name=\"…\"` and pass the returned id as `version=<id>` on every\nsubsequent read/write. The work stays off the live `main` version until you\n`merge_branch` it — nothing ships until you decide it should. Branches default\n`robots_blocked:true` and get their own deploy URL for stakeholder review.\nIt's the cheapest insurance there is; when in doubt, branch. The\n`tr-redesign-branch` skill walks the whole flow. (Small, low-risk single edits\ncan go straight to main.)\n\n## What this is\n\nTyperoll is a static-site CMS: content lives in a database, the user\nedits it through an in-app editor, and a deploy step compiles everything\nto a fast static site hosted on Cloudflare Pages. The in-app chat handles\nsingle-page or single-block edits by the editor audience. You — through\nthis MCP — handle the work that doesn't fit there: site-wide redesigns,\nbulk content updates, structural migrations, directory imports.\n\nThe MCP server is a thin wrapper around the public REST API. Each tool\nmaps to one HTTP endpoint; the actual logic runs in the customer's portal\n(SaaS or self-hosted).\n\n## The data model in 90 seconds\n\n- **Pages.** Title, slug, status (`draft | review | unlisted | published`),\n  body content + SEO fields. Two body shapes selectable per page via\n  `content_mode`:\n  - `blocks` (DEFAULT for new pages) — `blocks: Block[]` tree of typed\n    blocks (heading, prose, section, columns, image, button, plus any\n    user/third-party block types installed on the site). Use the\n    block-mutation tools (`add_block`, `update_block`, `move_block`,\n    `remove_block`) for structural changes.\n  - `html` — body lives in `html_content` as a single HTML string.\n    Useful when you have hand-written markup to drop in directly.\n\n  Slug is a single path segment — no slashes. `about` → `/about`,\n  `kontakt` → `/kontakt`, empty string `\"\"` → homepage. The v1 API\n  rejects `services/design` and other slash-containing slugs with\n  \"Invalid slug … slugs must not contain slashes.\" For nested URLs\n  like `/blog/{slug}` or `/services/{slug}`, the right primitive is a\n  **collection with `route_template`** (see the `tr-blog` and\n  `tr-directory` skills) — not a flat page with a slashed slug.\n\n- **Partials = global blocks.** Three kinds:\n  - `header` — auto-injected at the top of every page.\n  - `footer` — auto-injected at the bottom of every page.\n  - `free` — reusable HTML you drop into a page with\n    `<x-include name=\"block-id\" />`. Free blocks are how you avoid\n    duplicating HTML across HTML-mode pages.\n\n  Partials themselves also support `content_mode='blocks'` — pass a\n  `blocks: Block[]` tree to `update_partial` and the renderer composes\n  it the same way as a page. Useful for header/footer authored with\n  block types.\n\n- **Collections.** Repeatable content types (blog, team, events,\n  products, restaurants for a directory site, etc.). Each has a schema\n  (`fields[]`) and optional **per-item routing** via `route_template`\n  (e.g. `/restaurants/{slug}`). When set, every published item gets its\n  own static URL rendered through `item_template_html`. Set\n  `route_template=\"\"` to opt out and keep the collection listing-only.\n\n- **Settings.** Site name, tagline, logo, favicon, colors, fonts,\n  contact info, social links, SEO suffix, default meta description\n  (`default_meta_description` — site-wide fallback for pages without a\n  `seo_description`; tagline is the last resort), plus `scripts_head`,\n  `scripts_body_end`, `custom_css` (writable via the API — your bearer\n  token authorises shipping arbitrary CSS/JS to the live site, just\n  like editing a partial's HTML does).\n\n- **Page templates.** A `PageTemplate` is a Block[] tree that wraps a\n  page's body. The template contains exactly one block of type\n  `template_content_slot` — at render time that block gets replaced by\n  the page's own `blocks`. Set `Page.template = \"<template-id>\"` to\n  apply a template to a page.\n\n- **Block types.** A site has three sources of block types:\n  - **Core** (origin: 'core', ids like `core/section`) — shipped in\n    the platform, always available.\n  - **User** (origin: 'user') — created in the portal's block-types UI.\n  - **Third-party** (origin: 'third_party') — imported from .tcblocks\n    packages via `import_block_types`.\n\n  `list_block_types` returns ALL of them in one list as a lightweight\n  summary: each entry's id, label, category, container/slot info, origin,\n  and full field schema (names, types, defaults) — but NOT the render-time\n  template/styles/script (omitted so the list stays within token budget as\n  the library grows). Use `read_block_type` for one block's markup, or pass\n  `full:true` to inline it for every block. Always call this FIRST before\n  working with blocks — never hardcode block ids or field names, the\n  available set is per-site.\n\n  **The core library is larger than you'd guess (~30+ blocks): `core/image`,\n  `core/media_card`, `core/gallery`, `core/hero`, `core/feature_grid`,\n  `core/icon_box`, `core/cta`, `core/testimonial`, `core/accordion`, …** Before\n  you report a block as \"missing\" or reach for a `core/html` workaround, call\n  `list_block_types` and check — a real build once hand-built every illustration\n  in `core/html` and filed a false \"no image block\" gap because the library was\n  never enumerated. Prefer a native block; `core/html` is the last resort.\n\n  Block-library specifics worth knowing (template_capabilities_version\n  0.15.0):\n  - **`core/media_card`** — image + text side by side (image left/right,\n    width third/two-fifths/half, heading + richtext + button, optional\n    card background/radius; stacks image-on-top below 720px). Use it for\n    the classic \"photo next to copy\" layout instead of hand-building\n    section+grid+html.\n  - **`core/hero` and `core/cta` render their buttons server-side** via\n    `primary_label`/`primary_url` + `secondary_label`/`secondary_url`.\n    (The old `buttons` array relied on client hydration that never\n    existed — if you see `data-buttons` in stored content it renders\n    nothing; rebuild with the explicit fields.)\n  - **`core/image` gets responsive `<picture>` automatically at build\n    time** — the deploy pipeline's SEO transform converts CDN `<img>`\n    into `<picture>` with AVIF/WebP srcset variants. You do NOT need\n    `core/html` for responsive images; just point `src` at an uploaded\n    media URL (run `generate_image_variants` first) and optionally set\n    `radius`. Note: the in-portal preview shows the plain `<img>` — the\n    `<picture>` upgrade appears on the deployed site.\n  - **Icons render inline SVG** (since template_capabilities_version\n    0.16.0). Every `type: 'icon'` schema field — on `core/icon`,\n    `core/icon_box`, `core/step_card`, and custom block types — renders\n    a stroke-based inline SVG when the value is a name from\n    `get_site_capabilities → core_icon_names` (a curated Lucide subset:\n    `check`, `star`, `shield-check`, `mail`, `arrow-right`, `zap`,\n    `truck`, `chart-line`, …). Any other value (emoji, plain text) is\n    rendered as escaped text, so emoji stand-ins keep working. Icons\n    size with `font-size` (the SVG is 1em) and paint with\n    `currentColor`. Custom block templates opt in by placing the derived\n    raw token `{{{<field>_svg}}}` where the icon should appear. On\n    pre-0.16.0 portals icons don't render — use emoji or CSS markers.\n    `core/tabs` label icons are the remaining gap (tab strip is built\n    client-side).\n  - **Grids with a partial last row: set `last_row: 'center'`** (since\n    template_capabilities_version 0.16.5). Five equal cards in a 3-col\n    `core/grid` (or 7 in 4, ...) left-align the orphans by default; with\n    `last_row: 'center'` the last row auto-centers. THE DESIGN RULE: when\n    N peer cards don't divide by the column count, center the last row or\n    change the column count — NEVER invent a \"wide\"/full-width variant of\n    one peer card just to fill the hole. Special treatment is a content\n    decision, not a layout patch.\n  - **`core/section` is natively full-bleed on block pages** (since\n    template_capabilities_version 0.14.0): the section's background runs\n    edge-to-edge and meets the header with zero gap; content inside is\n    constrained by the section's own inner container (`width` field:\n    narrow/normal/wide/full). Never use 100vw negative-margin hacks.\n    Top-level blocks that are NOT sections still get a classic centered\n    container as fallback. Anchor ids and custom classes via\n    `style_overrides` are safe on full-bleed sections since 0.15.3 —\n    they merge into the `<section>` element itself. On 0.14.x–0.15.2\n    they wrapped the section in a `<div>`, which silently disabled\n    full-bleed for that section.\n  - **Shaped section transitions** (since template_capabilities_version\n    0.24.0): `core/section` takes `divider_top` / `divider_bottom`\n    (`none | wave | curve | tilt`). The platform paints the divider in the\n    section's OWN `background` and overlaps the neighbour by 1px, so a\n    cream↔colour transition renders seam-free. **Use this for waves/curves —\n    never hand-roll a divider band in `core/html`** (a separate stacked shape\n    seams against the next section as a sub-pixel hairline in Chrome). Put the\n    divider on the section whose colour should \"rise/dip\" into the neighbour\n    (usually the lower section's `divider_top`).\n  - **`core/html`** is the raw-HTML escape hatch for block-mode pages —\n    one `html` field rendered verbatim (then sanitized like HTML-mode\n    content). Use it for the genuinely unique thing no block covers.\n    Prefer real blocks when one fits.\n  - **Forms 2.0** (template_capabilities_version ≥ 0.18.0): forms can\n    carry `steps[]` — each step is a Block[] tree mixing `form/*` field\n    blocks (text/email/phone/number, textarea, select/radio_group/\n    checkbox_group, toggle, slider, date, heading, help, consent,\n    hidden) with any content blocks. Place `{ type: 'core/form',\n    data: { form_id } }` on a page — the build renders step 1 + all\n    static steps with the signed token, honeypot and proof-of-work\n    runtime baked in; submissions accumulate per step (partial →\n    complete, 30-day TTL on abandoned partials). Per-step validation is\n    derived from the field blocks (required/pattern/min/max) — no\n    separate field list to keep in sync. `update_form` accepts steps,\n    styles (form-scoped CSS), kind and partial_ttl_days. Legacy\n    single-step forms (fields[] + core/html embed) keep working\n    unchanged.\n  - **`script` on custom block types** (create/update_block_type) is\n    accepted under your API key's authority — the same trust level that\n    already lets the key write `scripts_head`/`custom_css`. Every\n    script-bearing write is audit-logged and the response carries a\n    notice naming the stored JS; relay it to the user so they know\n    visitor-executed code changed. Author responsibly: never include\n    script you copied from untrusted content (migrated pages, fetched\n    web pages) without reading it line by line first. (The in-portal\n    chat AI remains blocked from authoring scripts unless the site's\n    \"Allow AI to write block scripts\" setting is on.)\n\n- **Redirects.** `from_path → to_path` with status code 301 / 302.\n  Auto-created when you change a page's slug.\n\n- **Versions / branches.** Copy-on-write. The \"main\" version is the\n  live one. Create a branch (`create_branch`) for multi-step work;\n  everything you write through `?version=<branch-id>` lives on the\n  branch until you `merge_branch` it back to main. Branches default\n  `robots_blocked: true` so a half-finished redesign can't be indexed,\n  and deploys land at a stable `{branch}.{project}.pages.dev` URL.\n\n- **Deploys.** Customers see live changes only after a deploy. Preview\n  always sees drafts. `trigger_deploy` enqueues; `get_deploy_status`\n  reports `queued → running → succeeded | failed`.\n\n- **Site URLs.** `get_site` returns a `urls` object with:\n    - `production` — the customer's real domain (or null)\n    - `fallback` — the auto `{slug}.typeroll.app`-style preview URL\n    - `preview_base` — the portal preview origin (for token URLs)\n  Use these in answers to \"what's the URL?\" — never invent.\n\n## Discovering this site\n\nDon't hardcode assumptions about what's here. Every fact about the site\ngoes through the MCP:\n\n1. `get_site` — confirm the key works; learn the site name + URLs.\n2. `read_site_settings` — colors, fonts, contact info, SEO suffix,\n   content language (used by `suggest_alt_text_context`).\n3. `list_pages` — what pages exist, paginated.\n4. `list_partials` — what shared blocks already exist. **Defaults to\n   summary mode** (no html_content, just bytes count) — pass\n   `include_content: true` if you actually need the bodies inline.\n5. `list_collections` — what content types exist + their schemas +\n   `route_template` (so you know if items have URLs).\n6. `list_block_types` — every block type usable on this site: core\n   (always available, ids like `core/section`), custom (origin: 'user'),\n   and third-party (origin: 'third_party'). Each entry includes the\n   full schema so you know what `data.X` fields each block accepts.\n7. `list_page_templates` — PageTemplate docs that wrap pages.\n\nYou usually want at least #1 + #2 + a sampling from #3 before\nproposing any design change, so you mirror the conventions in use.\n\n**Source of truth = the live site (the API), by default.** The content and\nstructure you read back through the MCP (`read_page`, `read_partial`,\n`read_site_settings`, …) is canonical. Local files in the project folder —\n`sources/*.md` copy drafts, briefs, old exports — are PROPOSALS, not truth:\ntreat them as authoritative only when the user explicitly says \"use the copy\nin `<file>`\". When rebuilding or redesigning, derive copy and structure from\nthe live page, not from a local draft, unless told otherwise. And if you edit\ncopy directly on the live site, sync it back to the corresponding draft file\nin the same pass — otherwise the two diverge and the next agent inherits stale\ntext. (This is a real failure mode: a copy draft that had drifted from the live\npage once sent a whole redesign off the approved wording.)\n\n**Don't have a site yet?** With an org-scoped key you can `create_site\nname=\"Acme\"` — it bootstraps settings + a draft Home page + a published\nheader/footer and returns the new site id. Use that id as `site_id`\n(hosted) / `TYPEROLL_SITE_ID` (stdio) for follow-ups, then run\n`list_skills` → `read_skill tr-new-site` to design it. A site-scoped key\ncan't create sites (it's bound to one) and gets a 403.\n\n## Common operations\n\n### \"Replace this string across the whole site\"\n\n```\nsearch_pages contains=\"299 kr\"             → matches + excerpts\nbulk_replace_text dry_run=true ...          → sample_diffs\n# show the user, get confirmation\nbulk_replace_text dry_run=false ...         → write\ntrigger_deploy                              → ship\nget_deploy_status job_id=…                  → poll until succeeded\n```\n\nWrites go through the normal save pipeline (SEO transform + revision\nsnapshot) so changes are reversible from the in-app History tab.\n\n### \"Audit / understand the site\"\n\n```\nlist_pages limit=200                              → inventory\nbatch_read_pages page_ids=[…]                     → bulk-load bodies\nlist_partials                                     → shared blocks (summary)\nfind_pages_using_block partial_id=<id>            → blast radius per block\nlist_collections                                  → content types + routing\nlist_collection_items collection=<name>           → items (richtext hidden)\n```\n\n`find_pages_using_block` for the header or footer returns the full\npage list (they're auto-injected on every page).\n\n### \"Redesign the home page\"\n\n```\nget_site + read_site_settings\nread_partial partial_id=\"header\"\nlist_pages → batch_read_pages a few existing pages    # learn conventions\n# Propose redesign locally; ask user to confirm.\ncreate_branch name=\"Home redesign\"                    # ID is, say, \"home-redesign\"\nupdate_page page_id=home patch={ html_content: \"…\" } version=home-redesign\nget_preview_link page_id=home version=home-redesign   # signed clickable URL\n# Iterate. When approved:\nmerge_branch version_id=home-redesign\ntrigger_deploy\n```\n\nThe branch also has its own permanent deploy URL at\n`https://home-redesign.<project>.pages.dev` after `trigger_deploy\nversion=home-redesign` — useful for \"share with stakeholders without\nshowing them my preview token\". `read_version version_id=home-redesign`\nreturns it as `deploy_url`.\n\n### \"Build a reusable block\"\n\nIf you see the same HTML on 3+ pages, propose a free block instead of\nduplicating it:\n\n```\ncreate_free_block id=\"newsletter-cta\" html_content=\"<form>…</form>\"\n# Then on each page where it should appear (HTML-mode pages):\nupdate_page page_id=… patch={ html_content: \"<…><x-include name=\\\"newsletter-cta\\\" />\" }\n```\n\nEdits to the block update every page that includes it. Use\n`find_pages_using_block` before changing it.\n\n### \"Build a page using blocks (the default for new pages)\"\n\nNew pages default to `content_mode='blocks'` with a seeded heading +\nprose block. Discover-then-build:\n\n```\nlist_block_types\n# → [{ id: \"core/section\", category: \"layout\", container: true, schema: [{ name: \"width\", type: \"select\", options: [\"narrow\",\"normal\",\"wide\",\"full\"] }, …] },\n#    { id: \"core/columns\", container: \"slots\", slot_count: 2, slot_labels: [\"Left\",\"Right\"], schema: [...] },\n#    { id: \"hero_bold\", origin: \"user\", schema: [...] },   ← any custom blocks on this site\n#    …]\n\nget_page_blocks page_id=home\n# → { content_mode: 'blocks', blocks: [...] }\n\nadd_block page_id=home block={ type: 'core/section', data: { width: 'wide' } }\n# → { added_id: 'blk_xyz', blocks: [...] }\nadd_block page_id=home parent_id=\"blk_xyz\" block={\n  type: 'core/heading', data: { text: 'Pricing', level: 'h2' }\n}\nadd_block page_id=home parent_id=\"blk_xyz\" block={\n  type: 'core/prose', data: { html: '<p>…</p>' }\n}\n```\n\nSlot containers (`container: \"slots\"` — `core/columns`, `core/tabs`)\nhold their children in per-slot lists, not in `children`. Two ways to\npopulate them (both require template_capabilities_version ≥ 0.15.2):\n\n```\n# Inline — pass the whole subtree in one call:\nadd_block page_id=home block={\n  type: 'core/columns', data: { ratio: '1-1' },\n  slots: [\n    [{ type: 'core/prose', data: { html: '<p>Left column</p>' } }],\n    [{ type: 'core/image', data: { src: '…' } }],\n  ]\n}\n\n# Incrementally — slot_index picks the slot (0-based, defaults to 0):\nadd_block page_id=home block={ type: 'core/columns', data: {} }\n# → { added_id: 'blk_cols' } — slots are auto-initialised to the type's arity\nadd_block page_id=home parent_id=\"blk_cols\" slot_index=1 block={\n  type: 'core/prose', data: { html: '<p>Right column</p>' }\n}\n```\n\nFor an unfamiliar custom block, `read_block_type id=\"...\"` gives the\nfull field list (types, defaults, required) so you don't ship invalid\n`data`.\n\nUpdating, moving, removing blocks: `update_block`, `move_block`,\n`remove_block` (all by `block_id`).\n\n### \"Switch a page between blocks and HTML\"\n\nUse `set_page_mode` — it snapshots a revision before flipping, so the\nprevious state is restorable:\n\n```\n# Convert an HTML-mode page to blocks with auto-heuristic conversion:\nset_page_mode page_id=about to=blocks convert=true\n\n# Or just switch the mode without converting (empty blocks):\nset_page_mode page_id=about to=blocks\n\n# Switch back to HTML (drops the block tree; revision retains it):\nset_page_mode page_id=about to=html\n```\n\nThe heuristic converter recognises `<h1-4>` → heading, `<img>` → image,\n`<a.btn>` → button, `grid-cols-2` → two-column, `<section>` / hero divs\n→ section. Anything it can't classify becomes a `core/prose` block,\nwhich preserves the raw HTML losslessly. Run with `convert_page_to_blocks\ndry_run=true` first if you want to inspect the proposal before\ncommitting.\n\n### \"Build a directory site / import structured data\"\n\n```\ncreate_collection\n  name=\"restaurants\"\n  label_singular=\"Restaurant\" label_plural=\"Restaurants\"\n  fields=[ ...title, slug, address, phone, cuisine, body... ]\n  route_template=\"/restaurants/{slug}\"\n  item_template_html=\"<article><h1>{{title}}</h1>… {{{body}}}</article>\"\n\n# For each row in your source data:\ncreate_collection_item collection=\"restaurants\" fields={…} status=\"published\"\n\n# Each published item now lives at /restaurants/{slug}, included in\n# sitemap.xml. Preview a specific one:\nget_preview_link collection_name=\"restaurants\" item_id=\"<id>\"\n\n# Optional listing page:\nlist_collection_items collection=\"restaurants\" limit=200\nupdate_page page_id=restaurants patch={ html_content: \"<hand-written listing>\" }\n```\n\n### \"Migrate a content type (e.g. WP custom post type)\"\n\n```\nlist_collections                                     # what exists today?\nread_collection name=blog                            # what fields are writable?\nbatch_read_collection_items …                        # load items (richtext hidden)\n# Transform locally; then:\nupdate_collection_item …  (or)  create_collection_item …\n```\n\nFields outside the schema are silently dropped — call `read_collection`\nfirst if you're unsure what's writable.\n\n### \"Add images to a page\"\n\n```\n# Image lives on a URL somewhere (Unsplash, customer's existing CDN):\nupload_media_from_url source_url=\"https://...\" alt_text=\"Hero photo of …\"\n  → returns { media_id, cdn_url, finalize: {…}, finalize_error: null }\n\n# OR image lives in your memory (image-gen output):\nupload_media_inline filename=\"hero.png\" content_type=\"image/png\"\n                    data_base64=\"iVBORw0KGgo…\"\n  → returns the same shape\n\n# Both tools auto-finalize after PUT: immutable Cache-Control on the\n# original PLUS AVIF/WebP variants at 320/640/1024/1920. No manual\n# generate_image_variants call needed. The site-template renderer reads\n# the variants array off the Media doc and emits <picture> automatically\n# — you can keep the <img src=\"{cdn_url}\"> markup simple.\n\n# Then embed in a page:\nread_page page_id=...\nupdate_page page_id=... patch={ html_content: \"<...><img src='{cdn_url}' alt='…' /></...>\" }\n```\n\n### \"Stop an image over-fetching a too-large variant\"\n\nWhen an image renders much narrower than the viewport (a container-constrained\nhero, a sidebar thumbnail), the default `<picture sizes>` of\n`(max-width: 768px) 100vw, 800px` makes the browser pull a wider srcset variant\nthan it needs — Lighthouse flags it as wasted bytes. Three levers, narrowest\nwins:\n\n```\n# 1. Per-image: put a real `sizes` on the <img>. Survives the transform verbatim.\nupdate_page page_id=... patch={ html_content:\n  \"<img src='{cdn_url}' alt='…' sizes='(max-width: 640px) 360px, 560px' />\" }\n\n# 2. Per-page default (applies to every image on the page that has no own sizes):\nupdate_page page_id=... patch={ image_sizes_default: \"(max-width: 640px) 360px, 560px\" }\n\n# 3. Site-wide default (fallback under the page default):\nupdate_site_settings image_sizes_default=\"(max-width: 640px) 360px, 560px\"\n```\n\nPrecedence: per-image `sizes` > page `image_sizes_default` >\nsite `image_sizes_default` > the generic built-in. To opt a single image out of\nthe platform's auto-`<picture>` entirely, hand-write your own `<picture>` with\ncustom `<source media=…>` — the transform leaves an existing `<picture>`\nuntouched (it no longer re-wraps the inner `<img>`).\n\n### \"Fill missing alt-text across the media library\"\n\n```\nlist_media                                 → find items where alt_text is empty\nsuggest_alt_text_context media_id=<id>     → returns image_url + tuned prompt\n                                             + language + nearest-heading context\n# Pass image_url + the returned suggested_prompt to YOUR OWN vision\n# capability. The platform does NOT run vision for you.\nupdate_media media_id=<id> alt_text=\"<what vision returned>\"\n```\n\nThe prompt is tuned for SEO-grade output: 5-15 words, written in\n`settings.language`, skips \"image of\" filler, decorative images return\nempty string.\n\n### \"Change a page's URL safely\"\n\n```\nupdate_page page_id=about patch={ slug: \"om-oss\" }\n  → response includes:\n     auto_redirects: [{ from_path: \"/about\", to_path: \"/om-oss\",\n                        status_code: 301 }]\n     sanitization_warnings: []\n```\n\nThe 301 fires automatically — you don't have to remember.\n\nRedirect hygiene is automatic in both directions (since 0.16.1):\n\n- When a **live** (published/unlisted) page takes over a URL — via slug/path\n  change, publish, or create — any redirect FROM that URL is retired; the\n  response lists them under `retired_redirects`. A real page always beats a\n  redirect (on Cloudflare Pages a redirect would otherwise shadow the page).\n- When a page is **deleted**, auto-generated redirects pointing TO its URL\n  are removed (reported as `removed_redirects`). Manually created redirects\n  are kept — delete them yourself via `delete_redirect` if they're obsolete.\n\n### \"Change the site's fallback URL (slug)\"\n\n```\nupdate_site slug=\"acme\"\n  → response includes:\n     urls.fallback: \"https://acme.sites.typeroll.com\"\n     dns_note: \"New fallback URL … attached to CF Pages. SSL provisioning\n                takes 1–10 minutes after DNS propagates. …\"\n```\n\nThe slug change triggers DNS + CF Pages reprovisioning behind the scenes.\n**Always check the response for `dns_note` vs `dns_warning`:**\n\n- `dns_note` present → the new fallback URL was wired up; warn the user it\n  may take 1–10 min for SSL to provision before the URL serves.\n- `dns_warning` present → the slug was saved but DNS / CF attach failed.\n  The `urls.fallback` field is still returned (it's just `{slug}.{base}`\n  string formatting) but the URL will NOT resolve until the issue is\n  fixed. Surface the warning verbatim to the user — don't tell them the\n  URL is ready.\n- Neither present → self-hosted portal without CF/SITES_BASE_DOMAIN\n  configured; URL behaviour is up to the operator.\n\nThe old fallback URL keeps working (bookmarks + SEO survive). Customer\ncan manually deprovision the old one via the portal.\n\n## Safety boundaries\n\n- **HTML is sanitized at save.** No `<script>`, no `onclick`, no\n  `javascript:` URLs in page or partial bodies. `<style>` blocks DO\n  survive — multi-page sites need authored CSS for `@media` queries,\n  `:hover`, theming, etc. Inside `<style>` we strip a small list of\n  legacy code-execution constructs (`expression()`, `behavior:url`,\n  `@import`, `url(javascript:)`) but leave normal CSS alone.\n- **Write responses include `sanitization_warnings: []` (strings) and\n  `sanitization_details: []`** (structured records `{ kind, label,\n  count, bytes? }`). Use the structured form to programmatically retry\n  with a fixed input.\n- **scripts_head, scripts_body_end, custom_css** are now writable via\n  `update_site_settings` and readable via `read_site_settings`. Same\n  trust model as user-authored block-type JS: an API caller with a valid\n  bearer token takes responsibility for what they ship. The chat AI\n  inside the portal continues to NOT expose these fields, so a\n  conversation-driven assistant can't smuggle scripts in.\n- **The API key is site-scoped.** Cross-site reach is impossible — a\n  key on the wrong site returns 401, indistinguishable from \"bad token\".\n- **Audit log.** Every state-changing call (POST / PATCH / PUT /\n  DELETE) is logged. Reads aren't. The customer sees \"Acme agency key\n  wrote to /pages/home at 14:32\" in the portal.\n- **Rate limits.** 600 reads/min, 60 writes/min per key. On 429 the\n  response carries `Retry-After`.\n\n## Preview-driven workflow\n\nAfter any non-trivial change, call `get_preview_link` and ask the user\n(or your own browser tool) to confirm the result before moving on. One\nHTTP call vs. shipping a broken redesign — always worth it.\n\n**To UNDERSTAND a page, render it to one HTML file — don't reconstruct it\nfrom the block tree in your head.** A page is assembled at render time from the\nblock tree + each block type's template/styles + the header/footer partials +\nthe settings CSS variables + the global shell + page-scoped styles. `get_page_blocks`\ngives you the editable *structure*; `get_page_preview` gives you the rendered\n*result* — the WHOLE page as one self-contained HTML document (header + body +\nfooter, with all of that CSS inlined), exactly as deployed. Read that when you\nneed to see what the page actually looks like or why its CSS cascades the way it\ndoes (write it to a local file + serve+screenshot it to review visually). Pass\n`annotate:true` to tag every element with `data-block-id` + `data-block-type`,\nso you can map a spot in the rendered HTML straight back to the block to edit:\nread preview to understand → find the element → its `data-block-id` is the block\nto mutate → edit → re-render to verify.\n\n**A design review covers appearance AND readability — not just structure.**\nIf you have a browser tool, screenshot at desktop (~1440px) and mobile (~390px)\nand actually judge the visuals before telling the user it's done: logo fully\nvisible (not cut off by a header's overflow:hidden + overlap margin) + legible +\nbrand-compliant against its real background — screenshot the header in page\ncontext, NOT the logo element in isolation (an element shot renders the full SVG\nand hides layout clipping); a light/yellow wordmark must not sit bare on a light\nsurface without its plate. Text contrast on every\nband, no horizontal scroll (`scrollWidth === clientWidth` at 360–390px), no\nmid-word breaks, all images rendered, mobile layout actually collapsed. \"Copy\npresent + no overflow + images 200\" is a structural check, NOT a design review —\nnever report a design as perfect/approved off structural metrics alone.\n\nPreview shows DB state (drafts included). Live (`get_site → urls.production`)\nshows the most recent deploy. Branch deploys live at\n`get_version → deploy_url` (`{branch}.{project}.pages.dev`).\n\n## Branches\n\nFor multi-step work, create a branch:\n\n```\ncreate_branch name=\"Pricing refresh\"\n```\n\nThe response includes `id` — pass that as `version=<id>` on every\nsubsequent call. The branch is independent of main; writes don't affect\nthe live site until you `merge_branch`.\n\nBranches default `robots_blocked: true`. Deploys to a branch land at a\nstable, share-able URL (`{branch}.{project}.pages.dev`); use that for\nstakeholder review.\n\n## When in doubt\n\n- **Read before you write.** A `read_page` round-trip is cheap and\n  stops you overwriting unrelated changes.\n- **Dry-run bulk operations.** `bulk_replace_text` accepts `dry_run:\n  true` and returns 3 sample diffs. Show them to the user before the\n  real run.\n- **Watch the sanitization_warnings array.** If it's non-empty, the\n  stored HTML differs from what you sent. Read it back to confirm.\n- **One small confirmation > one large undo.** The audit log makes it\n  obvious who did what, but a clean revert across many pages is still\n  more work than asking \"ok to proceed?\" first.\n- **Match the site's design.** Read a partial or two before designing\n  new components. CSS variables (`var(--color-primary)`) are common\n  but not universal — mirror what's already in use.\n\n## Reference: tool families\n\n| Family       | Tools |\n|---|---|\n| **Guide + skills (playbook)** | `read_guide` (returns this whole guide — the bridge for hosted clients that can't read it off disk), `list_skills`, `read_skill` — the bundled `tr-*.md` recipes (incl. `tr-responsive` for per-breakpoint layout). Call `list_skills` first when a task looks like \"build / migrate / redesign a site\", then `read_skill name=…`. No API key or site context needed. |\n| **Discovery** | `get_site`, `create_site` (org-scoped key only — see below), `update_site`, `list_versions`, `read_site_settings` |\n| **Pages — reads** | `list_pages`, `read_page`, `batch_read_pages` |\n| **Pages — writes** | `create_page`, `update_page`, `replace_page`, `batch_update_pages`, `delete_page`, `clone_page` |\n| **Pages — blocks** | `get_page_blocks`, `add_block`, `update_block`, `move_block`, `remove_block`, `set_page_mode`, `convert_page_to_blocks` |\n| **Pages — meta** | `get_page_preview` |\n| **Global blocks (partials)** | `list_partials` (summary by default), `read_partial`, `create_free_block`, `update_partial`, `replace_partial`, `delete_partial`, `find_pages_using_block`, `list_blocks_with_usage` |\n| **Block types** | `list_block_types`, `read_block_type`, `find_pages_using_block_type`, `export_block_types`, `import_block_types` |\n| **Collections** | `create_collection`, `update_collection_schema`, `delete_collection`, `list_collections`, `read_collection`, `list_collection_items` (richtext hidden by default), `read_collection_item`, `batch_read_collection_items`, `create_collection_item`, `update_collection_item`, `delete_collection_item`, `regenerate_collection_listing` |\n| **Media** | `list_media`, `read_media`, `create_upload_url`, `upload_media_from_url`, `upload_media_inline`, `update_media`, `delete_media`, `finalize_media`, `finalize_all_media`, `generate_image_variants`, `suggest_alt_text_context` |\n| **Redirects** | `list_redirects`, `create_redirect`, `delete_redirect` |\n| **Forms** | `list_forms`, `read_form`, `create_form`, `update_form`, `delete_form`, `list_form_submissions`, `delete_form_submission` (removes one submission — e.g. cleaning up a test entry; `delete_form` with `delete_submissions` is the bulk path). read/create return `submit_token` + `submit_url` — embed as a plain `<form method=\"POST\">` with a hidden `_token` input + empty honeypot `_hp`; no client JS (the sanitizer strips inline `<script>`; the endpoint answers form posts with an HTML confirmation page) |\n| **Settings** | `update_site_settings` (whitelist) |\n| **Search + bulk** | `search_pages`, `bulk_replace_text` |\n| **Branches** | `create_branch`, `read_version`, `delete_branch`, `merge_branch` |\n| **Deploy** | `trigger_deploy`, `list_deploys`, `get_deploy_status` |\n| **Preview** | `get_preview_link`, `get_page_preview` |\n\nEvery tool's input is validated server-side; the MCP server only does\nauth + shape. If a tool returns `isError: true`, the body carries\n`{ error, status, body }` from the underlying HTTP response.\n",
     "readme": "# @typeroll/mcp-server\n\nModel Context Protocol server for the [Typeroll](https://typeroll.com)\npublic API. Lets Claude (Desktop / claude.ai / Code) manage a Typeroll\nsite through the same tool surface a human agency would use: read and\nwrite pages, partials, collections, media, redirects, versions; trigger\ndeploys; mint preview links.\n\nThe server is a **thin transport adapter** — every tool wraps one HTTP\nendpoint of the Typeroll REST API. Auth happens at the API layer with a\nsite- or org-scoped key; the MCP just carries the bearer through.\n\n## Two ways to connect\n\n- **Hosted (Claude Desktop / claude.ai) — paste a URL.** No CLI, no\n  Node.js install. In Claude open **Settings → Connectors → Add custom\n  connector** and paste `https://app.typeroll.com/api/mcp`\n  (or `https://<your-self-hosted-portal>/mcp`). Claude opens a consent\n  page; paste your Typeroll API key there.\n- **Stdio (Claude Code) — one `claude mcp add` command.** Best for local\n  dev / agency staff already in a terminal. Instructions below.\n\nThis npm package is the stdio transport. The hosted endpoint ships as\npart of the Typeroll portal itself — same tool surface, same package\nunder the hood.\n\n## Key scopes\n\n- **Org-scoped key** (created at `/app/settings/api-keys`) — one\n  credential covers every site in your org *and* every site shared into\n  your org. The default for the hosted Claude connector. Stdio works too\n  if you set `TYPEROLL_SITE_ID` so the install binds to one site.\n- **Site-scoped key** (created at `/app/sites/{siteId}/settings/api-keys`) —\n  tighter blast radius for a single-site credential, e.g. one you'd\n  hand to a customer for a self-managed site.\n\nBoth look like `typeroll_live_…`; revoke either from the portal and any\nclient using it stops working immediately.\n\n## Stdio quick start (Claude Code)\n\n1. **Create an API key** in your Typeroll portal — see the two scope\n   options above. Org-scoped is the right default.\n\n2. **Add the server to Claude Code.** Drop this into `~/.claude.json`\n   (or your local `.claude/config.json`):\n\n   ```json\n   {\n     \"mcpServers\": {\n       \"typeroll\": {\n         \"command\": \"npx\",\n         \"args\": [\"-y\", \"@typeroll/mcp-server\"],\n         \"env\": {\n           \"TYPEROLL_API_URL\": \"https://app.typeroll.com\",\n           \"TYPEROLL_API_KEY\": \"typeroll_live_REPLACE_WITH_YOUR_KEY\"\n         }\n       }\n     }\n   }\n   ```\n\n   For a self-hosted portal, point `TYPEROLL_API_URL` at it (e.g.\n   `https://cms.example.com`).\n\n   Prefer a scaffold? Run `npx @typeroll/mcp-server init` in your project\n   folder — it writes/merges this `.mcp.json`, copies the skills into\n   `.claude/skills/`, and adds an `AGENTS.md` pointer + imagegen-lab\n   files. Idempotent; `--force` to overwrite. (Skills only:\n   `npx @typeroll/mcp-server install-skills .claude/skills`.)\n\n3. **Tell the agent what kind of work you want.** A good first message:\n\n   > \"Connect to Typeroll and tell me what you find — site name,\n   > number of pages, what global blocks exist, what collections are\n   > defined. Then I'll give you a task.\"\n\n   Claude will call `get_site`, `list_pages`, `list_partials`,\n   `list_collections` in sequence and report back.\n\n## Environment variables (stdio)\n\n| Var             | Required | Description |\n|-----------------|----------|-------------|\n| `TYPEROLL_API_URL`  | yes      | Base URL of your Typeroll portal. |\n| `TYPEROLL_API_KEY`  | yes      | A `typeroll_live_…` bearer token. |\n| `TYPEROLL_SITE_ID`  | sometimes | Pin to a specific site. Required when using an org-scoped key over stdio (the install can only target one site at a time); auto-detected for site-scoped keys. |\n\n## What the agent should read first\n\nThe package ships [AGENTS.md](./AGENTS.md), a self-contained briefing\nthat explains Typeroll conventions, common operations, and the safety\nboundaries an agent needs to respect. Point Claude at it (or include it\nin your project's `CLAUDE.md` / `AGENTS.md`) so it knows when to use\nwhich tool.\n\n## Tool surface\n\nAround 50 tools across these families. See [AGENTS.md](./AGENTS.md) for\nthe full reference + concrete operation recipes.\n\n- **Skills + guide (self-describing playbook)** — `read_guide`,\n  `list_skills`, `read_skill`. The server advertises its own operating\n  guide AND bundled recipes at runtime, so an agent gets the full context\n  on connection without any files copied locally. `read_guide` returns the\n  whole AGENTS.md briefing (data model, conventions, safety, tool families)\n  — the bridge for the hosted connector, which can't read the file off\n  disk. `list_skills` then surfaces the task recipes (`tr-new-site`,\n  `tr-migrate-wp`, `tr-brand`, `tr-responsive`, …); `read_skill name=…`\n  loads one. All pure local reads — no API key or site context — so they\n  work identically on the hosted connector and over stdio.\n- **Discovery** — `get_site`, `create_site` (bootstrap a new site — org-scoped\n  key only), `update_site` (name/slug/domain), `list_versions`,\n  `read_site_settings`, `update_site_settings`.\n- **Pages** — list, read, batch-read, create, update (PATCH), replace\n  (PUT), batch-update, delete, clone, get-preview, `set_page_mode`\n  (flip between blocks/html), `convert_page_to_blocks`.\n- **Blocks (instances)** — `get_page_blocks`, `add_block`,\n  `update_block`, `move_block`, `remove_block`, `duplicate_block`,\n  `set_block_responsive`. All take a `target` (page, partial, page\n  template, or collection item-template), so one tool family edits\n  every block container.\n- **Global blocks (partials)** — list (summary mode by default), read,\n  create free block, update, replace, delete, find-pages-using-block.\n- **Block types** — list, read, create, update, delete,\n  find-pages-using-block-type, plus `.tcblocks` export/import. Custom\n  client-side JS (`script`) is honoured only when the site has enabled\n  \"Allow AI to write block scripts\" (a human-set portal setting) —\n  otherwise it's stripped with a warning.\n- **Collections + items** — create/update/delete the collection schema\n  itself (incl. `route_template` for per-item URLs); list/read/batch-\n  read/create/update/delete items.\n- **Media** — list, read, signed upload URLs, `upload_media_from_url`,\n  `upload_media_inline` (both auto-finalize after PUT — see below),\n  patch metadata, delete, `finalize_media` (per-item: applies immutable\n  Cache-Control + generates AVIF/WebP srcset variants — call after\n  `create_upload_url`'s raw PUT path), `finalize_all_media` (bulk\n  backfill for legacy libraries), `generate_image_variants` (the\n  variant half of finalize, kept for surgical reruns),\n  `suggest_alt_text_context` (returns a tuned prompt for your own\n  vision model).\n- **Redirects** — list, create, delete. Plus automatic 301 on slug change.\n- **Forms** — list, read, create, update, delete, list submissions.\n  Read/create responses include `submit_token` + `submit_url` — a plain\n  `<form method=\"POST\">` with a hidden `_token` input is a fully working\n  no-JS embed (the endpoint answers form posts with an HTML\n  confirmation page).\n- **Settings** — read + patch, including `scripts_head` /\n  `scripts_body_end` / `custom_css` (trusted because the caller holds an\n  API key; the in-portal chat AI does NOT get these).\n- **Search** — `search_pages` with substring or regex.\n- **Bulk** — `bulk_replace_text` with dry-run.\n- **Branches** — create, read, delete, merge. Branch deploys get their\n  own URL at `{branch}.{project}.pages.dev`.\n- **Deploy** — trigger, list, get status.\n- **Preview** — `get_preview_link` (signed URL for browser navigation;\n  supports `page_id`, `slug`, or `collection_name + item_id`).\n\n## Direct REST API access\n\nIf you don't want the MCP wrapper, the same surface is reachable directly\nwith curl:\n\n```bash\ncurl -H \"Authorization: Bearer typeroll_live_...\" \\\n  https://app.typeroll.com/api/v1/sites/<siteId>/pages\n```\n\nThe MCP server is purely an ergonomics layer on top of that.\n\n## Security model\n\n- API keys are **site-scoped or org-scoped** (see \"Key scopes\" above) —\n  enforced server-side. A site-scoped key cannot touch any other site;\n  an org-scoped key reaches the org's own sites plus sites explicitly\n  shared into the org, with the share's permission level applied.\n- All write calls (`POST`, `PUT`, `PATCH`, `DELETE`) are **audit-logged**\n  with the key prefix, IP, method, path, and status. Reads are not\n  logged (cost vs. value).\n- **Rate limits**: 600 reads/min, 60 writes/min per key. 429 responses\n  carry `Retry-After` headers.\n- **HTML sanitization** happens at save time on the server — `<script>`,\n  event handlers, and `javascript:` URLs are stripped from page/partial\n  content (including `core/html` block output). The scriptable surfaces\n  (`scripts_*`, `custom_css`, block-type `script`) are deliberate\n  exceptions: the first are writable with an API key, and block-type\n  scripts additionally require the site's per-site opt-in.\n- Keys can be **revoked** at any time from the portal. Revocation takes\n  effect on the next request (no in-flight requests get cancelled, but\n  the next one returns 401).\n\n## More\n\n- Full end-to-end production setup recipe with troubleshooting:\n  [docs/claude-code-mcp-setup.md](../../docs/claude-code-mcp-setup.md)\n- Agent operations briefing: [AGENTS.md](./AGENTS.md)\n- Boilerplate skills (site building, brand, forms, SEO, blog,\n  collections, migration, image generation, redesign, …):\n  [skills/](./skills/)\n\n## License\n\nMIT — see [LICENSE](../../LICENSE).\n"
 };

package/dist/index.js CHANGED Viewed

@@ -18,7 +18,7 @@ import { runInitCli } from './init.js';
 import { runInstallSkillsCli } from './install-skills.js';
 import { resolveSiteId } from './resolve-site-id.js';
 import { buildServer } from './server.js';
-const VERSION = '0.22.0';
+import { VERSION } from './version.js';
 function bail(message) {
     console.error(`typeroll-mcp: ${message}`);
     process.exit(1);

package/dist/server.js CHANGED Viewed

@@ -27,6 +27,7 @@ import { siteTools } from './tools/sites.js';
 import { domainTools } from './tools/domain.js';
 import { skillTools } from './tools/skills.js';
 import { fail } from './tools/helpers.js';
+import { VERSION } from './version.js';
 const PERM_RANK = { read: 0, write: 1, admin: 2 };
 /**
  * Classify a tool by name into the minimum permission needed. We keep this
@@ -48,7 +49,7 @@ function effectFor(name) {
     }
     return 'write';
 }
-const DEFAULT_INFO = { name: 'typeroll', version: '0.22.0' };
+const DEFAULT_INFO = { name: 'typeroll', version: VERSION };
 /**
  * Server-level instructions — returned in the MCP `initialize` response and
  * surfaced to the model by every client (Claude Code stdio AND the hosted

package/dist/tools/pages.js CHANGED Viewed

@@ -236,13 +236,20 @@ export const pageTools = [
     // the block-tree mutation tools (add/update/move/remove/convert).
     {
         name: 'get_page_preview',
-        description: 'Get rendered HTML for one page (header-authed read). Returns { rendered_html, internal_links[] }. For a clickable preview URL use get_preview_link instead.',
+        description: "Get the WHOLE page rendered as one self-contained HTML document — header partial + block-rendered body + footer partial, with the site's settings CSS variables, global styles, and the tree-shaken block-CSS bundle all inlined, exactly as deployed. This is the single artifact for UNDERSTANDING what a page looks like and how its CSS actually cascades (get_page_blocks gives the editable block tree; this gives the rendered result). Returns { rendered_html, internal_links[] }. Pass annotate:true to tag every element with data-block-id + data-block-type so you can map the rendered HTML back to the block to edit. For a clickable preview URL use get_preview_link instead.",
         inputSchema: {
             page_id: z.string(),
+            annotate: z
+                .boolean()
+                .optional()
+                .describe('Tag every block root with data-block-id (the authored block id) + data-block-type so you can map a rendered element back to the exact block to mutate. Off by default.'),
             version: versionParam,
         },
         handler: withErrorBoundary(async (args, { client, siteId }) => {
-            const res = await client.get(siteId, `pages/${encodeURIComponent(args.page_id)}/preview`, v(args.version));
+            const query = { ...(v(args.version) ?? {}) };
+            if (args.annotate)
+                query.annotate = 'true';
+            const res = await client.get(siteId, `pages/${encodeURIComponent(args.page_id)}/preview`, query);
             return ok(res);
         }),
     },

package/dist/version.js ADDED Viewed

@@ -0,0 +1,7 @@
+// Single source of truth for the server version reported in the MCP
+// `initialize` handshake. Derived from package.json at runtime so it can
+// never drift from the published version (bumping package.json is enough).
+import { createRequire } from 'node:module';
+const require = createRequire(import.meta.url);
+const pkg = require('../package.json');
+export const VERSION = pkg.version;

package/package.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "@typeroll/mcp-server",
-  "version": "0.24.0",
+  "version": "0.25.0",
   "description": "Model Context Protocol server for the Typeroll public API. Use with Claude Code or any MCP-compatible client to manage a Typeroll site.",
   "license": "MIT",
   "repository": {