@typeroll/mcp-server 0.17.0 → 0.19.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/dist/tools/forms.js

@@ -46,7 +46,6 @@ export const formTools = [
             fields: z.array(fieldSchema).min(1),
             submit_text: z.string().optional(),
             success_message: z.string().optional(),
-            actions: z.array(z.object({ type: z.string(), config: z.record(z.unknown()) })).optional(),
         },
         handler: withErrorBoundary(async (args, { client, siteId }) => {
             const res = await client.post(siteId, 'forms', args);
@@ -63,7 +62,6 @@ export const formTools = [
                 fields: z.array(fieldSchema).optional(),
                 submit_text: z.string().optional(),
                 success_message: z.string().optional(),
-                actions: z.array(z.object({ type: z.string(), config: z.record(z.unknown()) })).optional(),
             }),
         },
         handler: withErrorBoundary(async (args, { client, siteId }) => {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@typeroll/mcp-server",
-  "version": "0.17.0",
+  "version": "0.19.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
@@ -266,6 +291,11 @@ portal at `/app/sites/{siteId}/forms/kontakt/submissions`.
   unique per site — use descriptive names: `kontakt`, `boka`, `nyhetsbrev`.
 - **Honeypot must be invisible.** `_hp` field must have `display:none`.
   If it's visible and a real user fills it, their submission is rejected.
-- **No email notifications yet.** Submissions are stored and visible in
-  the portal's Submissions inbox; the email action handler isn't wired
-  platform-side. Confirm with the customer that they'll check the inbox.
+- **Email notifications are admin-only — not settable via MCP.** Submissions
+  are stored and visible in the portal's Forms → Submissions inbox. A site
+  admin can also configure post-submission emails (admin notification +
+  autoresponder) under **Forms → <form> → Email**, after setting up an email
+  connector under **Settings → Email & notifications**. These carry recipient
+  addresses + templates over submission data, so they're deliberately off the
+  agent surface (`create_form`/`update_form` ignore `actions`). Point the
+  customer at those screens; you can't set them up for them.