@typeroll/mcp-server 0.33.3 → 0.35.0

package/AGENTS.md

@@ -256,7 +256,7 @@ maps to one HTTP endpoint; the actual logic runs in the customer's portal
   - **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,
+    checkbox_group, toggle, slider, date, URL, 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
@@ -264,9 +264,9 @@ maps to one HTTP endpoint; the actual logic runs in the customer's portal
     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.
+    styles (form-scoped CSS), kind and partial_ttl_days. On HTML-mode
+    pages, `<x-form id="…" />` is expanded server-side through the same
+    renderer and supports the same initial state and multi-step runtime.
   - **`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
@@ -959,7 +959,7 @@ preview.
 | **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` |
 | **Redirects** | `list_redirects`, `create_redirect`, `delete_redirect`. `from_path` may be a PATTERN: a trailing `*` (with `:splat` in the target) or `:name` for one segment — one rule retires a whole family of dead URLs (`/category/*` → `/blogg/:splat`). Mid-path splats and query strings are refused, as is any rule that would hide a live page. |
 | **Migration inventory** | `get_migration_readiness` (preflight — CALL FIRST on any import), `list_migration_urls`, `add_migration_urls`, `update_migration_url`, `delete_migration_url`, `verify_migration_urls`. The legacy site's URL list with LIVE coverage status (`migrated` / `redirected` / `excluded` / `unhandled`, recomputed on every read from current pages + redirects). `verify_migration_urls` is the pre-cutover check that REQUESTS every URL against the deployed site — see "Don't lose URLs in a migration" below. |
-| **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). **Steps (form/* block trees) are the ONLY stored model** (0.29.0+, `forms_steps_only` capability): pass `steps` for funnels, or `fields` for simple forms — the server converts a flat field list to a single static step (read_form shows the resulting steps). **Placing a form: prefer a `core/form` block with `data.form_id`** — it renders every form with validation + signed token handled. The raw `<form method="POST">` embed with hidden `_token` + honeypot `_hp` (from read/create's `submit_token`/`submit_url`) is the HTML-mode fallback, single-step forms only; no client JS (the sanitizer strips inline `<script>`) |
+| **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). **Steps (form/* block trees) are the ONLY stored model**: pass `steps` for funnels, or `fields` for simple forms — the server converts a flat field list to a single static step. Place with a `core/form` block on block-mode pages or `<x-form id="…" />` in HTML mode. Both expand server-side to the same complete signed shell and initial state. Email/webhook actions are admin-only in the portal and excluded from agent reads/writes. |
 | **Settings** | `update_site_settings` (whitelist) |
 | **Apps** | `list_apps`, `read_app`, `update_app` (admin; schema-driven config, masked secrets, redeploy when `affects_build` is true) |
 | **Analytics attribution** | `read_funnel_attribution`, `update_funnel_attribution` (specialized Analytics module tools; admin; redeploy after changes) |

package/README.md

@@ -86,6 +86,23 @@ client using it stops working immediately.
 | `TYPEROLL_API_KEY`  | yes      | A `typeroll_live_…` bearer token. |
 | `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. |
 
+## Extension developer CLI
+
+The package also installs `typeroll`. With an organization-scoped API key,
+an external Extension repository can use the same developer and installation
+APIs as the portal:
+
+```sh
+typeroll extension validate
+typeroll extension push --draft
+typeroll extension install --site test-site --config local-extension-config.json
+typeroll extension promote 1.0.0
+```
+
+The manifest defaults to `typeroll-extension.json`; use `--manifest` to select
+another file. Local validation is a fast preflight. The portal always performs
+the complete schema, compatibility, origin and asset-hash validation.
+
 ## What the agent should read first
 
 The package ships [AGENTS.md](./AGENTS.md), a self-contained briefing
@@ -141,10 +158,10 @@ the full reference + concrete operation recipes.
   vision model).
 - **Redirects** — list, create, delete. Plus automatic 301 on slug change.
 - **Forms** — list, read, create, update, delete, list submissions.
-  Read/create responses include `submit_token` + `submit_url` — a plain
-  `<form method="POST">` with a hidden `_token` input is a fully working
-  no-JS embed (the endpoint answers form posts with an HTML
-  confirmation page).
+  Place forms with `core/form` blocks or an HTML-mode `<x-form id="…" />`
+  reference; preview/build expands both server-side to the same complete,
+  signed form shell. Admins configure email and allowlisted, signed webhooks
+  in the portal; action configuration stays off agent surfaces.
 - **Settings** — read + patch, including `scripts_head` /
   `scripts_body_end` / `custom_css` (trusted because the caller holds an
   API key; the in-portal chat AI does NOT get these).