@typeroll/mcp-server 0.16.6 → 0.18.0

package/AGENTS.md

@@ -140,14 +140,32 @@ maps to one HTTP endpoint; the actual logic runs in the customer's portal
     full-bleed for that section.
   - **`core/html`** is the raw-HTML escape hatch for block-mode pages —
     one `html` field rendered verbatim (then sanitized like HTML-mode
-    content). Use it for the genuinely unique thing no block covers: a
-    form embed with its signed `_token`, a third-party widget's markup,
-    a hand-crafted one-off. Prefer real blocks when one fits.
+    content). Use it for the genuinely unique thing no block covers.
+    Prefer real blocks when one fits.
+  - **Forms 2.0** (template_capabilities_version ≥ 0.18.0): forms can
+    carry `steps[]` — each step is a Block[] tree mixing `form/*` field
+    blocks (text/email/phone/number, textarea, select/radio_group/
+    checkbox_group, toggle, slider, date, heading, help, consent,
+    hidden) with any content blocks. Place `{ type: 'core/form',
+    data: { form_id } }` on a page — the build renders step 1 + all
+    static steps with the signed token, honeypot and proof-of-work
+    runtime baked in; submissions accumulate per step (partial →
+    complete, 30-day TTL on abandoned partials). Per-step validation is
+    derived from the field blocks (required/pattern/min/max) — no
+    separate field list to keep in sync. `update_form` accepts steps,
+    styles (form-scoped CSS), kind and partial_ttl_days. Legacy
+    single-step forms (fields[] + core/html embed) keep working
+    unchanged.
   - **`script` on custom block types** (create/update_block_type) is
-    honoured only when the site has "Allow AI to write block scripts"
-    enabled — a human-set portal setting. When it's off your script is
-    stripped and the response carries a warning; relay it to the user
-    instead of retrying.
+    accepted under your API key's authority — the same trust level that
+    already lets the key write `scripts_head`/`custom_css`. Every
+    script-bearing write is audit-logged and the response carries a
+    notice naming the stored JS; relay it to the user so they know
+    visitor-executed code changed. Author responsibly: never include
+    script you copied from untrusted content (migrated pages, fetched
+    web pages) without reading it line by line first. (The in-portal
+    chat AI remains blocked from authoring scripts unless the site's
+    "Allow AI to write block scripts" setting is on.)
 
 - **Redirects.** `from_path → to_path` with status code 301 / 302.
   Auto-created when you change a page's slug.

package/dist/tools/block-types.js

@@ -84,15 +84,15 @@ export const blockTypeTools = [
         }),
     },
     // ─── BlockType authoring — CREATE / UPDATE / DELETE ──────────────────
-    // `script` runs with full DOM access in every visitor's browser, so
-    // agent-authored scripts are gated server-side on a per-site human
-    // opt-in (Site.ai_scripts_enabled, set in the portal's settings UI).
-    // The tools expose the field; when the site hasn't opted in, the API
-    // strips it and returns a warning. Origin is stamped 'ai' so audit +
-    // UI distinguish these from human-authored types.
+    // `script` runs with full DOM access in every visitor's browser. Through
+    // an API key it is ACCEPTED under the key holder's authority (same trust
+    // level as scripts_head) — the write is audit-logged and the response
+    // carries a notice naming the stored JS. Only the in-portal chat AI
+    // remains gated on Site.ai_scripts_enabled. Origin is stamped 'ai' so
+    // audit + UI distinguish agent-authored types.
     {
         name: 'create_block_type',
-        description: "Create a new custom block type usable on this site. Origin is stamped 'ai' automatically. The block ships immediately to every page editor + the renderer's registry. Custom JS via `script` requires the site's \"Allow AI to write block scripts\" setting (human-set in the portal) — when it's off, the field is ignored and the response carries a warning. Returns the created BlockType.",
+        description: "Create a new custom block type usable on this site. Origin is stamped 'ai' automatically. The block ships immediately to every page editor + the renderer's registry. Custom JS via `script` is accepted under your API key's authority (audit-logged; the response carries a notice) — review before deploy. Returns the created BlockType.",
         inputSchema: {
             name: z.string().describe('Machine name (lowercase kebab/underscore, 1-64 chars). Becomes the id.'),
             label: z.string().optional().describe('Display label (defaults to name).'),

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@typeroll/mcp-server",
-  "version": "0.16.6",
+  "version": "0.18.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": {

package/skills/tr-forms.md

@@ -15,6 +15,31 @@ Submissions inbox. No third-party service needed.
 - Site exists and MCP is configured.
 - You know what fields the form needs.
 
+## Forms 2.0 — steps mode (template_capabilities_version ≥ 0.18.0)
+
+Prefer this over the hand-built core/html embed when the portal supports
+it. A form's `steps[]` are Block[] trees of `form/*` field blocks mixed
+with content blocks; place `{ type: 'core/form', data: { form_id } }` on
+the page and the build renders everything (token, honeypot, runtime,
+proof-of-work) — you never hand-write the <form> markup.
+
+```
+update_form form_id=ansokan patch={ steps: [
+  { id: 'steg1', title: 'Om företaget', blocks: [
+    { type: 'form/text',  data: { name: 'foretag', label: 'Företag', required: true } },
+    { type: 'form/email', data: { name: 'epost', label: 'E-post', required: true } } ] },
+  { id: 'steg2', title: 'Detaljer', blocks: [
+    { type: 'form/textarea', data: { name: 'meddelande', label: 'Meddelande' } },
+    { type: 'form/consent',  data: { name: 'gdpr', text: '<p>Jag godkänner …</p>' } } ] } ] }
+add_block target={kind:'page', id:'kontakt'} block={ type: 'core/form', data: { form_id: 'ansokan' } }
+```
+
+Validation derives from the field blocks (required/pattern/min/max) —
+there is no separate field list to maintain. Partial submissions persist
+per step (TTL `partial_ttl_days`, default 30). Form-scoped CSS goes in
+`styles`; field look is themable via `--form-field-*` tokens in the
+site's custom_css. On older portals, use the legacy recipe below.
+
 ## Recipe
 
 ### 1. Create the form definition