@typeroll/mcp-server 0.17.0 → 0.18.0

package/AGENTS.md

@@ -140,9 +140,22 @@ 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
     accepted under your API key's authority — the same trust level that
     already lets the key write `scripts_head`/`custom_css`. Every

package/package.json

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