@frontmcp/skills 1.8.7 → 1.9.0

package/catalog/frontmcp-config/examples/configure-transport/stateless-serverless.md

@@ -5,7 +5,7 @@ level: basic
 description: 'Configure stateless transport for Vercel, Lambda, or Cloudflare deployments.'
 tags: [config, vercel, lambda, cloudflare, session, transport]
 features:
-  - "Using `sessionMode: 'stateless'` to disable session management"
+  - 'Serving without sessions: whether the server keeps sessions follows `transport.protocol` (`sessionMode` has no effect)'
   - "Using the `'stateless-api'` preset: no SSE, no streaming, pure request/response"
   - 'Each request is standalone with no server-side state between invocations'
   - 'Required for serverless targets (Vercel, Lambda, Cloudflare Workers)'
@@ -48,7 +48,6 @@ class CurrencyApp {}
   info: { name: 'serverless-server', version: '1.0.0' },
   apps: [CurrencyApp],
   transport: {
-    sessionMode: 'stateless',
     protocol: 'stateless-api',
   },
 })
@@ -57,7 +56,7 @@ class Server {}
 
 ## What This Demonstrates
 
-- Using `sessionMode: 'stateless'` to disable session management
+- Serving without sessions: whether the server keeps sessions follows `transport.protocol` (`sessionMode` has no effect)
 - Using the `'stateless-api'` preset: no SSE, no streaming, pure request/response
 - Each request is standalone with no server-side state between invocations
 - Required for serverless targets (Vercel, Lambda, Cloudflare Workers)

package/catalog/frontmcp-config/examples/configure-transport-protocol-presets/stateless-api-serverless.md

@@ -7,7 +7,7 @@ tags: [config, vercel, lambda, cloudflare, session, transport]
 features:
   - "The `'stateless-api'` preset disables SSE, streaming, and sessions entirely"
   - 'Each request is standalone with no server-side state'
-  - "Pair with `sessionMode: 'stateless'` for serverless execution"
+  - 'No `sessionMode` needed: sessions follow the protocol preset'
   - 'Required for Vercel, Lambda, Cloudflare Workers where persistent connections are not allowed'
 ---
 
@@ -46,7 +46,6 @@ class TranslateApp {}
   info: { name: 'serverless-translate', version: '1.0.0' },
   apps: [TranslateApp],
   transport: {
-    sessionMode: 'stateless',
     protocol: 'stateless-api',
   },
 })
@@ -59,7 +58,7 @@ class Server {}
 
 - The `'stateless-api'` preset disables SSE, streaming, and sessions entirely
 - Each request is standalone with no server-side state
-- Pair with `sessionMode: 'stateless'` for serverless execution
+- No `sessionMode` needed: sessions follow the protocol preset
 - Required for Vercel, Lambda, Cloudflare Workers where persistent connections are not allowed
 
 ## Related

package/catalog/frontmcp-config/references/configure-auth.md

@@ -105,7 +105,7 @@ Key local-mode options:
 
 - `tokenStorage` -- where authorization codes / refresh tokens / federated sessions persist. Defaults to `'memory'` (lost on restart). Use `{ sqlite: { path } }` for single-node persistence or `{ redis: { ... } }` for multi-instance. This is honored in local mode.
 - `requireEmail` (default `true`) -- when `false`, the login callback mints a code without prompting for an email, deriving a stable `sub` from `anonymousSubject` (default `'local-operator'`). Use for single-operator setups (e.g. Claude Code).
-- `consent` -- enables an **interactive tool-selection screen** during login AND **call-time enforcement**. When `consent.enabled` is `true`, `/oauth/callback` renders a consent screen (after authentication) listing the available tools; the user's checked tools are GET-submitted back to `/oauth/callback`, embedded in the token's `consent` claim, and enforced on every `tools/call` — a call to an unselected tool is rejected with `TOOL_NOT_CONSENTED` (JSON-RPC `-32003`). Honored flags: `groupByApp` (default `true`), `showDescriptions` (default `true`), `allowSelectAll` (default `true`), `requireSelection` (default `true` — rejects an empty submit), `customMessage`, `rememberConsent` (default `true`), `excludedTools` (never offered, always available), `defaultSelectedTools` (pre-checked). Federated logins show the screen after the last provider links. Tokens minted without consent (disabled, or via the test factory) carry no claim and stay all-tools-allowed. `rememberConsent` persists each user's per-client selection (keyed by `consent:{userSub}:{clientId}`, sharing the configured `tokenStorage` backend) and reuses it on the next login: the screen is skipped when no new tool appeared, or re-shown pre-filled when a NEW tool was added (a newly-added tool is never silently granted). Set `rememberConsent: false` to always re-show the screen.
+- `consent` -- enables an **interactive tool-selection screen** during login AND **call-time enforcement**. When `consent.enabled` is `true`, `/oauth/callback` renders a consent screen (after authentication) listing the available tools; the user's checked tools are GET-submitted back to `/oauth/callback`, embedded in the token's `consent` claim, and enforced on every `tools/call` — a call to an unselected tool is rejected with `TOOL_NOT_CONSENTED` (JSON-RPC `-32003`). Honored flags: `groupByApp` (default `true`), `showDescriptions` (default `true`), `allowSelectAll` (default `true`), `requireSelection` (default `true` — rejects an empty submit), `customMessage`, `rememberConsent` (default `true`), `excludedTools` (never offered, always available), `defaultSelectedTools` (pre-checked). Federated logins show the screen after the last provider links. Tokens minted without consent (disabled, or via the test factory) carry no claim and stay all-tools-allowed. `rememberConsent` persists each user's per-client selection (keyed by `consent:{userSub}:{clientId}`, sharing the configured `tokenStorage` backend) and reuses it on the next login: the screen is skipped when no new tool appeared, or re-shown pre-filled when a NEW tool was added (a newly-added tool is never silently granted). Set `rememberConsent: false` to always re-show the screen. An agent is offered as its `invoke_<agent>` tool. The tools declared inside an `@Agent` and its nested agents are never offered, and the consent given to the agent covers them; the other agents and server tools an agent calls (`swarm`, `execution.inheritParentTools`) are offered and need their own consent.
 - `login` -- customize the built-in login page: `title` / `subtitle` / `logoUri`, declarative `fields` (each `{ type: 'text'|'password'|'email'|'select'|'hidden'; label?; required?; placeholder?; options? }`), a full HTML `render(ctx)` override, and a `subject` strategy (`{ fromField, strategy: 'per-session'|'per-account' }`). Omitting `login` keeps the default email/name page.
 - `authenticate(input, ctx)` -- custom verification run at the login callback **before** a token is minted. `input.fields` carries the submitted login fields (reserved OAuth params excluded); `ctx` is `{ get, fetch, logger, clientId?, clientName? }`. Return `{ ok: true, sub?, claims? }` to mint a token (custom `claims` are embedded in the JWT; reserved claims like `sub`/`iss`/`exp`/`scope` are stripped) or `{ ok: false, message, retryField? }` to re-render the login page with the error (no code issued). When set, the email requirement no longer applies.
 - `providers` -- declarative upstream OAuth providers (GitHub, Slack, Jira, …) to orchestrate. When set, FrontMCP federates them at `/oauth/authorize`, stores each provider's tokens **encrypted server-side**, and exposes them to tools via `this.orchestration.getToken(id)`. See [Multi-provider orchestration](#multi-provider-orchestration-providers--federatedauth) below.

package/catalog/frontmcp-config/references/configure-deployment-targets.md

@@ -122,14 +122,44 @@ frontmcp build --target vercel
 | `sdk`         | Direct           | Configurable          | Library embedding       |
 | `mcpb`        | stdio            | SQLite, memory        | `.mcpb` MCP bundles     |
 
+### How the settings reach the server
+
+`frontmcp build` writes each target's `server` block (and `env`) into the artifact as environment
+defaults the server reads at start-up — only where the variable is not already set (an operator's env var
+wins), and an explicit `@FrontMcp()` value wins over both:
+
+| Setting                         | Variable                                                        | Applies to                                          |
+| ------------------------------- | --------------------------------------------------------------- | --------------------------------------------------- |
+| `server.http.port`              | `PORT`                                                          | `node`, `distributed` (serverless: ignored, warns)  |
+| `server.http.socketPath`        | `FRONTMCP_DAEMON_SOCKET`                                        | `node`, `distributed`                               |
+| `server.http.entryPath`         | `FRONTMCP_HTTP_ENTRY_PATH` (wins over `transport.http.path`)    | every server target                                 |
+| `server.http.cors`              | `FRONTMCP_CORS_ORIGINS` (JSON list), `_CREDENTIALS`, `_MAX_AGE` | every server target                                 |
+| `server.cookies`                | `FRONTMCP_AFFINITY_COOKIE`, `_DOMAIN`, `_SAMESITE`              | `distributed` (sets the LB affinity cookie)         |
+| `server.csp` / `server.headers` | `FRONTMCP_CSP_*`, `FRONTMCP_HSTS`, …                            | every server target                                 |
+| `deployments[].env`             | each key as is                                                  | every target except the `browser` / `sdk` libraries |
+
+`node` / `cli` / `mcpb` bundles set them in a preamble when run as the program; `vercel` / `lambda` /
+`cloudflare` / `distributed` in the generated setup module. Every artifact also sets
+`globalThis.FRONTMCP_BUILD_TARGET` for `availableWhen: { target }` (first one to run wins).
+
 ### Server HTTP Options
 
-| Field          | Type     | Default | Description                  |
-| -------------- | -------- | ------- | ---------------------------- |
-| `port`         | number   | 3000    | Listen port                  |
-| `socketPath`   | string   | ---     | Unix socket (overrides port) |
-| `entryPath`    | string   | `/`     | Base path                    |
-| `cors.origins` | string[] | ---     | CORS allowed origins         |
+| Field          | Type     | Default | Description                                                                       |
+| -------------- | -------- | ------- | --------------------------------------------------------------------------------- |
+| `port`         | number   | 3000    | Listen port (node / distributed)                                                  |
+| `socketPath`   | string   | ---     | Unix socket (overrides port; node / distributed)                                  |
+| `entryPath`    | string   | `/`     | Base path; wins over `transport.http.path` for this deployment                    |
+| `cors.origins` | string[] | ---     | CORS allowed origins (`['*']` = any); none = no CORS headers (the server default) |
+
+`bodyLimit` / `urlencodedLimit` are not `frontmcp.config` fields — set them in `@FrontMcp({ http })`.
+
+### Cookie Options (distributed LB affinity cookie)
+
+| Field      | Default           | Description        |
+| ---------- | ----------------- | ------------------ |
+| `affinity` | `__frontmcp_node` | Cookie name        |
+| `domain`   | ---               | `Domain` attribute |
+| `sameSite` | `'Strict'`        | `SameSite`         |
 
 ### CSP Options
 
@@ -157,6 +187,8 @@ frontmcp build --target vercel
 | `takeoverGracePeriodMs` | number | 5000      | Grace period before takeover |
 | `redisKeyPrefix`        | string | `mcp:ha:` | Redis key prefix             |
 
+The build writes these to `FRONTMCP_HA_HEARTBEAT_INTERVAL_MS`, `FRONTMCP_HA_HEARTBEAT_TTL_MS`, `FRONTMCP_HA_TAKEOVER_GRACE_MS` and `FRONTMCP_HA_KEY_PREFIX` in the generated setup file (only where the platform has not set them), which every pod reads at startup.
+
 ### Project-Defined CLI Commands (`cli.commands`)
 
 Register project-specific verbs that ship alongside the built-in
@@ -217,6 +249,8 @@ Per-invocation precedence (issue #400):
 3. Upward walk from `cwd` to the nearest ancestor containing a `frontmcp.config.*` (caps at 10 levels — monorepo nested apps work without `cd <repo-root>`).
 4. Fallback: `package.json` (derives name, default node target).
 
+When the upward walk finds the file in a **parent** folder, `frontmcp build` and `frontmcp dev` run from that folder (the project root): `entry`, `deployments[].outDir`, `tsconfig.json`, `package.json` and `.env` resolve there, so building from `src/` writes `dist/` next to the config. Paths passed as flags (`--entry`, `--out-dir`, `--icon`, `--merge-from`, `--log-file`) still resolve from the folder the command ran in. An explicit `--config` / `FRONTMCP_CONFIG` does not change the working folder.
+
 Within a directory:
 
 1. `frontmcp.config.ts`
@@ -239,15 +273,15 @@ There are no per-field `FRONTMCP_<NAME>` environment overrides. The only environ
 
 The config is consumed by every `frontmcp` command, not just `build`:
 
-| Command                           | Config fields consumed                                                                              |
-| --------------------------------- | --------------------------------------------------------------------------------------------------- |
-| `build`                           | `name`, `version`, `entry`, `deployments`, `build`, `nodeVersion`                                   |
-| `dev`                             | `entry`, `transport.http.port`, `env.shared` ⊕ `env.dev`                                            |
-| `test`                            | `test.timeoutMs` / `test.runInBand` / `test.coverage` / `test.testMatch`, `env.shared` ⊕ `env.test` |
-| `inspector`                       | `transport.default`, `transport.http.port`, `transport.stdio`                                       |
-| `pm start` / `socket` / `service` | `name`, `entry`, `transport.http.port`, `transport.http.socketPath`, `env.shared` ⊕ `env.ship`      |
-| `skills install` / `export`       | `skills.provider`, `skills.bundle`, `skills.install`, `skills.exportTarget`                         |
-| `eject-mcp-config <client>`       | `clients.<client>`, `name`, `transport`, `env.ship`                                                 |
+| Command                           | Config fields consumed                                                                                              |
+| --------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
+| `build`                           | `name`, `version`, `entry`, `deployments` (incl. `server`, `env`), `build`, `nodeVersion`, `transport.http.path`    |
+| `dev`                             | `entry`, `transport.http.port`, `env.shared` ⊕ `env.dev`, first deployment's `server.csp` / `headers` / `http.cors` |
+| `test`                            | `test.timeoutMs` / `test.runInBand` / `test.coverage` / `test.testMatch`, `env.shared` ⊕ `env.test`                 |
+| `inspector`                       | `transport.default`, `transport.http.port`, `transport.stdio`                                                       |
+| `pm start` / `socket` / `service` | `env.shared` ⊕ `env.ship` (config found from the entry's folder upwards; the real env wins)                         |
+| `skills install` / `export`       | `skills.provider`, `skills.install` (else `skills.bundle`; `'none'` = nothing), `skills.exportTarget` — flags win   |
+| `eject-mcp-config <client>`       | `clients.<client>`, `name`, `transport`, `env.shared` ⊕ `env.ship` (stdio `env`, under the client's own `env`)      |
 
 See `transport`, `env`, `clients`, `test`, `skills` field reference in [docs/frontmcp/deployment/frontmcp-config](https://docs.agentfront.dev/frontmcp/deployment/frontmcp-config).
 
@@ -255,11 +289,11 @@ See `transport`, `env`, `clients`, `test`, `skills` field reference in [docs/fro
 
 `transport.http.path` is the mount path of the MCP endpoint for **every** build target, not only `frontmcp dev`:
 
-| Target                            | How the path reaches the server                                                                    |
-| --------------------------------- | -------------------------------------------------------------------------------------------------- |
-| `node` (and its SEA binary)       | the generated runner script exports `FRONTMCP_HTTP_ENTRY_PATH` (default only; a real env var wins) |
-| `vercel`, `lambda`, `distributed` | the generated setup file assigns `process.env.FRONTMCP_HTTP_ENTRY_PATH` before the server loads    |
-| `cloudflare`                      | the generated worker setup assigns it the same way                                                 |
+| Target                            | How the path reaches the server                                                                                                                                                                                |
+| --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `node` (and its SEA binary)       | the runner script exports `FRONTMCP_HTTP_ENTRY_PATH`, and the bundle sets the same default itself when run directly (`node dist/node/<name>.bundle.js`, the generated Dockerfile's `CMD`); a real env var wins |
+| `vercel`, `lambda`, `distributed` | the generated setup file assigns `process.env.FRONTMCP_HTTP_ENTRY_PATH` before the server loads                                                                                                                |
+| `cloudflare`                      | the generated worker setup assigns it the same way                                                                                                                                                             |
 
 A `@FrontMcp({ http: { entryPath } })` value still wins over the config. When the two differ, `frontmcp build` warns.
 

package/catalog/frontmcp-config/references/configure-http.md

@@ -137,7 +137,8 @@ until you name the public host, and the bound NIC address then joins the list al
 **Deployments behind a proxy need one line of config.** A routable bind (`0.0.0.0`, `::`, a specific
 NIC) is reached under a hostname the process cannot know, so a derived list is not enforced there —
 FrontMCP logs a warning and leaves host checking off rather than 403-ing a proxied deployment on a
-patch upgrade. Name the public host to turn it on:
+patch upgrade (the production security audit reports it as `DNS_REBINDING_NOT_ENFORCED`, and only says
+`DNS_REBINDING_PROTECTED` once a list is actually checked). Name the public host to turn it on:
 
 ```typescript
 http: {
@@ -163,7 +164,9 @@ there and needs no configuration. A rebound browser cannot reach a unix socket a
 **explicit** `allowedHosts` / `allowedOrigins` still applies to a socket server, and because the
 client's `Host` is a placeholder it will reject every request — leave it unset.
 
-To turn it off entirely: `dnsRebindingProtection: { enabled: false }`.
+To turn it off entirely: `dnsRebindingProtection: { enabled: false }`. It wins over any `allowedHosts` /
+`allowedOrigins` (and `FRONTMCP_ALLOWED_HOSTS`): no header is checked while it is set, so remove it to
+turn protection back on.
 
 A request with **no** `Origin` header is allowed through — non-browser clients never send one, and a
 rebound page always does. Rejecting the absent case breaks every CLI client and adds nothing.

package/catalog/frontmcp-config/references/configure-throttle-guard-config.md

@@ -69,7 +69,7 @@ interface IpFilterConfig {
 
 ## Storage Failure and Key Format
 
-- **Fails closed.** When `storage` cannot be reached at startup, the server does not start: startup rejects with `GuardStorageUnavailableError` (code `GUARD_STORAGE_UNAVAILABLE`), whose message names `throttle.storage`. That is the default in production. If the backend goes away while the server runs, a limited call is refused with the same error (a readable 503, not `Internal FrontMCP error`). Set `storage.fallback: 'memory'` to use per-instance counters instead; a mid-run outage then logs one warning and the backend is retried every 30 seconds. (The top-level `redis` and `transport.persistence` differ: they fall back to memory with an error log.)
+- **Fails closed.** When `storage` cannot be reached at startup, the server does not start: startup rejects with `GuardStorageUnavailableError` (code `GUARD_STORAGE_UNAVAILABLE`), whose message names `throttle.storage`. That is the default in production. If the backend goes away while the server runs, a limited call is refused with the same error, not `Internal FrontMCP error`: the `global` check answers HTTP 503 (`Retry-After: 1`, JSON-RPC `data.code: 'GUARD_STORAGE_UNAVAILABLE'`); a per-tool limit inside `tools/call` answers an `isError` result (HTTP 200, as MCP returns tool-level failures) with `_meta.code: 'GUARD_STORAGE_UNAVAILABLE'`. The client reads a generic "temporarily unavailable" message; the store address stays in the server log. Set `storage.fallback: 'memory'` to use per-instance counters instead; a mid-run outage then logs one warning and the backend is retried every 30 seconds. (The top-level `redis` and `transport.persistence` differ: they fall back to memory with an error log.)
 - **Keys.** `<keyPrefix><entity>:<partition>:<kind>:...`, e.g. `mcp:guard:export_tickets:global:rl:1790722980000`. Before 1.8.6 the default prefix wrote `mcp:guard::export_tickets:...`; old and new instances do not read each other's counters, so limits briefly split during a rolling deploy. A custom `keyPrefix` without a trailing `:` keeps its keys.
 
 ## Partition Strategies

package/catalog/frontmcp-config/references/configure-throttle.md

@@ -45,7 +45,7 @@ Protect your FrontMCP server with rate limiting, concurrency control, execution
       partitionBy: 'global', // shared across all clients
     },
 
-    // Global concurrency limit (a tool called with this.callTool() runs inside its caller's slot)
+    // Global concurrency limit (a tool called with this.callTool(), or by an agent during its run, runs inside its caller's slot)
     globalConcurrency: {
       maxConcurrent: 50,
       partitionBy: 'global',
@@ -112,6 +112,8 @@ class ExpensiveQueryTool extends ToolContext {
 }
 ```
 
+A tool's own `rateLimit` and `concurrency` are enforced without a `throttle` option, as are those of an agent, of the tools declared inside an `@Agent` and of its nested agents. `throttle.enabled: false` turns every guard off, including these.
+
 ## `ipFilter` is enforced on every HTTP route
 
 `allowList`, `denyList` and `defaultAction` are checked by the `checkIpFilter` stage that starts
@@ -246,7 +248,7 @@ throttle: {
 
 `storage` is a `StorageConfig` from `@frontmcp/utils` -- `type` picks the backend, and its options go under the matching key (`redis: { config }` or `redis: { url }`, `vercelKv: { url, token }`, `upstash: { url, token }`). It is NOT the top-level `redis` shape: `{ provider: 'redis', host, port }` has no `type`, so it is auto-detected from `REDIS_URL` / `REDIS_HOST` and otherwise runs in memory.
 
-**Rate limits fail closed.** If the store is unreachable at startup, the server does not start: startup rejects with `GuardStorageUnavailableError` (`throttle.storage (redis) is unavailable: ...`), the default in production. If the store goes away while the server is running, a limited call is refused with the same error rather than `Internal FrontMCP error`. To use per-instance counters instead (at startup and during a mid-run outage, going back to the store once it answers), opt in:
+**Rate limits fail closed.** If the store is unreachable at startup, the server does not start: startup rejects with `GuardStorageUnavailableError` (`throttle.storage (redis) is unavailable: ...`), the default in production. If the store goes away while the server is running, a limited call is refused with the same error rather than `Internal FrontMCP error` (HTTP 503 from the `global` check; an `isError` result with `_meta.code: 'GUARD_STORAGE_UNAVAILABLE'` from a per-tool limit inside `tools/call`). To use per-instance counters instead (at startup and during a mid-run outage, going back to the store once it answers), opt in:
 
 ```typescript
 storage: {

package/catalog/frontmcp-config/references/configure-transport.md

@@ -35,7 +35,6 @@ Configure how clients connect to your FrontMCP server — SSE, Streamable HTTP,
   info: { name: 'my-server', version: '1.0.0' },
   apps: [MyApp],
   transport: {
-    sessionMode: 'stateful', // 'stateful' | 'stateless'
     protocol: 'legacy', // preset or custom ProtocolConfig
     persistence: {
       // false to disable
@@ -157,7 +156,7 @@ curl -X POST http://localhost:3000/ -H 'Content-Type: application/json' -d '{"js
 | Pattern              | Correct                                                                          | Incorrect                                                  | Why                                                                                |
 | -------------------- | -------------------------------------------------------------------------------- | ---------------------------------------------------------- | ---------------------------------------------------------------------------------- |
 | Choosing a preset    | `protocol: 'modern'`                                                             | `protocol: { sse: true, streamable: true, legacy: false }` | Use a preset when it matches your needs; custom config is for overrides only       |
-| Serverless transport | `protocol: 'stateless-api'` with `sessionMode: 'stateless'`                      | `protocol: 'legacy'` on Lambda                             | Legacy preset creates sessions that serverless cannot maintain between invocations |
+| Serverless transport | `protocol: 'stateless-api'`                                                      | `protocol: 'legacy'` on Lambda                             | Legacy preset creates sessions that serverless cannot maintain between invocations |
 | Distributed sessions | `distributedMode: true` with Redis `persistence` configured                      | `distributedMode: true` without Redis                      | Distributed mode requires Redis; omitting it causes a startup error                |
 | Event store provider | `provider: 'redis'` for multi-instance, `provider: 'memory'` for single instance | `provider: 'memory'` behind a load balancer                | In-memory event store is not shared across instances, breaking SSE resumability    |
 | Session TTL          | Set `defaultTtlMs` to match your expected session duration                       | Omitting `defaultTtlMs` when using Redis persistence       | Missing TTL can cause sessions to accumulate indefinitely in Redis                 |
@@ -167,12 +166,12 @@ curl -X POST http://localhost:3000/ -H 'Content-Type: application/json' -d '{"js
 ### Transport Protocol
 
 - [ ] Correct preset is chosen for the deployment target (see Target-Specific Recommendations table)
-- [ ] Custom protocol flags, if used, do not conflict with the selected `sessionMode`
+- [ ] Custom protocol flags, if used, match whether the server should keep sessions (`stateless: true` serves without them)
 - [ ] Legacy SSE is disabled when all clients support modern MCP protocol
 
 ### Session and Persistence
 
-- [ ] `sessionMode` is `'stateless'` for serverless deployments
+- [ ] `protocol` is `'stateless-api'` for serverless deployments (sessions follow `protocol`; `sessionMode` has no effect and logs a startup warning when set to anything but `'stateful'`)
 - [ ] `distributedMode` is enabled and Redis is configured for multi-instance deployments
 - [ ] `defaultTtlMs` is set to a reasonable value when persistence is enabled
 
@@ -196,7 +195,7 @@ curl -X POST http://localhost:3000/ -H 'Content-Type: application/json' -d '{"js
 | Server rejects SSE connections         | SSE is disabled in the protocol config or preset                           | Switch to `'legacy'`, `'modern'`, or `'full'` preset, or set `sse: true` in custom config  |
 | `distributedMode` startup error        | Redis persistence is not configured                                        | Add a `persistence.redis` block with valid connection details                              |
 | Clients lose state after reconnect     | Event store is disabled or using in-memory provider behind a load balancer | Enable event store with `provider: 'redis'` for distributed deployments                    |
-| Serverless function times out on SSE   | Using a stateful preset on a serverless target                             | Switch to `'stateless-api'` preset and set `sessionMode: 'stateless'`                      |
+| Serverless function times out on SSE   | Using a stateful preset on a serverless target                             | Switch to the `'stateless-api'` preset                                                     |
 | Session not found after server restart | In-memory sessions do not survive restarts                                 | Enable Redis persistence with `distributedMode: true`                                      |
 | Streamable HTTP returns 404            | Streamable HTTP is not enabled in the current preset                       | Use `'modern'`, `'legacy'`, or `'full'` preset, or set `streamable: true` in custom config |
 

package/catalog/frontmcp-deployment/SKILL.md

@@ -73,25 +73,25 @@ Entry point for deploying and building FrontMCP servers. This skill helps you ch
 
 Beyond `frontmcp build`, the CLI provides commands for the full deployment lifecycle:
 
-| Command                      | Description                                                                                                                                                                     |
-| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `frontmcp build -t <target>` | Build for target: `node`, `vercel`, `lambda`, `cloudflare`, `cli`, `browser`, `sdk`                                                                                             |
-| `frontmcp build -t cli --js` | Build CLI as JS bundle (instead of native binary via SEA)                                                                                                                       |
-| `frontmcp build --no-clean`  | Keep existing output instead of clearing the target's output directory first                                                                                                    |
-| `frontmcp start <name>`      | Start a named MCP server with supervisor (process management)                                                                                                                   |
-| `frontmcp stop <name>`       | Stop managed server (`-f` for force kill)                                                                                                                                       |
-| `frontmcp restart <name>`    | Restart managed server                                                                                                                                                          |
-| `frontmcp status [name]`     | Show process status (detail if name given, table if omitted)                                                                                                                    |
-| `frontmcp list`              | List all managed processes                                                                                                                                                      |
-| `frontmcp logs <name>`       | Tail log output (`-F` follow, `-n` lines)                                                                                                                                       |
-| `frontmcp socket <entry>`    | Start Unix socket daemon for local MCP server                                                                                                                                   |
-| `frontmcp service <action>`  | Install/uninstall systemd (Linux) or launchd (macOS) service                                                                                                                    |
-| `frontmcp install <source>`  | Install MCP app from npm, local path, git, or a project's `dist/` / `dist/node` (installs external runtime packages; `frontmcp start <name>` then runs it from its install dir) |
-| `frontmcp uninstall <name>`  | Remove installed MCP app                                                                                                                                                        |
-| `frontmcp configure <name>`  | Re-run setup questionnaire for installed app                                                                                                                                    |
-| `frontmcp doctor`            | Check Node.js/npm versions and tsconfig requirements                                                                                                                            |
-| `frontmcp inspector`         | Launch MCP Inspector for debugging                                                                                                                                              |
-| `frontmcp init`              | Create or fix tsconfig.json for FrontMCP                                                                                                                                        |
+| Command                      | Description                                                                                                                                                                                                                                                                                                                                 |
+| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `frontmcp build -t <target>` | Build for target: `node`, `vercel`, `lambda`, `cloudflare`, `cli`, `browser`, `sdk`                                                                                                                                                                                                                                                         |
+| `frontmcp build -t cli --js` | Build CLI as JS bundle (instead of native binary via SEA)                                                                                                                                                                                                                                                                                   |
+| `frontmcp build --no-clean`  | Keep existing output instead of clearing the target's output directory first                                                                                                                                                                                                                                                                |
+| `frontmcp start <name>`      | Start a named MCP server with supervisor (process management)                                                                                                                                                                                                                                                                               |
+| `frontmcp stop <name>`       | Stop managed server (`-f` for force kill)                                                                                                                                                                                                                                                                                                   |
+| `frontmcp restart <name>`    | Restart managed server                                                                                                                                                                                                                                                                                                                      |
+| `frontmcp status [name]`     | Show process status (detail if name given, table if omitted)                                                                                                                                                                                                                                                                                |
+| `frontmcp list`              | List all managed processes                                                                                                                                                                                                                                                                                                                  |
+| `frontmcp logs <name>`       | Tail log output (`-F` follow, `-n` lines)                                                                                                                                                                                                                                                                                                   |
+| `frontmcp socket <entry>`    | Start Unix socket daemon for local MCP server                                                                                                                                                                                                                                                                                               |
+| `frontmcp service <action>`  | Install/uninstall systemd (Linux) or launchd (macOS) service                                                                                                                                                                                                                                                                                |
+| `frontmcp install <source>`  | Install MCP app from npm, local path, git, or a project's `dist/` / `dist/node` (`dist/node` wins over other targets; installs the external runtime packages plus `vectoriadb`/`tslib` and optional SDK peers the project declares, those in `optionalDependencies` as optional; `frontmcp start <name>` then runs it from its install dir) |
+| `frontmcp uninstall <name>`  | Remove installed MCP app                                                                                                                                                                                                                                                                                                                    |
+| `frontmcp configure <name>`  | Re-run setup questionnaire for installed app                                                                                                                                                                                                                                                                                                |
+| `frontmcp doctor`            | Check Node.js/npm versions and tsconfig requirements                                                                                                                                                                                                                                                                                        |
+| `frontmcp inspector`         | Launch MCP Inspector for debugging                                                                                                                                                                                                                                                                                                          |
+| `frontmcp init`              | Create or fix tsconfig.json for FrontMCP (edits in place, keeps comments; never overwrites a file it cannot parse or that declares a required option twice)                                                                                                                                                                                 |
 
 ## Target Comparison
 

package/catalog/frontmcp-deployment/examples/deploy-to-node/docker-compose-with-redis.md

@@ -79,7 +79,7 @@ RUN yarn install --frozen-lockfile --production && yarn cache clean
 EXPOSE 3000
 HEALTHCHECK --interval=30s --timeout=5s --retries=3 --start-period=10s \
   CMD wget -qO- http://localhost:3000/healthz || exit 1
-CMD ["node", "dist/main.js"]
+CMD ["node", "dist/node/my-server.bundle.js"]
 ```
 
 ```bash

package/catalog/frontmcp-deployment/examples/deploy-to-node/pm2-with-nginx.md

@@ -24,7 +24,7 @@ frontmcp build --target node
 npm install -g pm2
 
 # Start with cluster mode (one instance per CPU core)
-pm2 start dist/main.js --name frontmcp-server -i max
+pm2 start dist/node/my-server.bundle.js --name frontmcp-server -i max
 
 # Save the process list for auto-restart on reboot
 pm2 save

package/catalog/frontmcp-deployment/references/build-for-browser.md

@@ -119,6 +119,12 @@ function ToolUI() {
 
 Things that trip people up with `@frontmcp/react`:
 
+- A plain Vite app (7 or 8, build and dev server) bundles `@frontmcp/sdk` + `@frontmcp/react` from npm with no Node polyfills, no `process` define and no `express` alias: the bundler resolves the SDK's `browser` export condition to its browser build, for an `import` and for a CommonJS `require()` alike. Don't add `vite-plugin-node-polyfills` for FrontMCP.
+- With Vite 7 (Rollup), don't `await create()` at the top level of the entry module — call it from a function or `.then()`. Rollup can put modules the SDK imports lazily in a chunk that imports the entry back, and the top-level `await` then waits on itself.
+- Hook options may be written inline. `useStoreResource` / `useReduxResource` / `useValtioResource` and `useApiClient` register again only when the store name, the server, the set of selector / action names (not their order), or what an API operation declares changes; functions are read from the latest render.
+- `useApiClient` sends the arguments an operation declares `in: 'query'` as the query string and `in: 'header'` as headers. `parseOpenApiSpec` fills `operation.parameters`; a hand-written operation lists them itself (`parameters: [{ name: 'limit', in: 'query' }]`), or its non-path, non-`body` arguments are not sent. Arrays and objects follow the parameter's OpenAPI `style` / `explode` (which `parseOpenApiSpec` keeps): a query array repeats the key and a query object sends each property as its own parameter by default (`spaceDelimited`, `pipeDelimited` and `deepObject` are honored); a header array or object is comma-separated.
+- `ToolForm` shows an optional enum without a default as unset (an empty choice), and leaves it out of the arguments until the user picks a value.
+
 - `useCallTool`'s `data` is the whole MCP `CallToolResult` (`content`, `structuredContent`, `isError`), not the tool's return value. Render `data.structuredContent ?? data.content`, never `String(data)`. A tool-side failure resolves with `data.isError === true`; `error` is only set when the call throws (for example when the client is not connected).
 - `z` is re-exported from `@frontmcp/react`, but `zod` remains a required peer dependency of `@frontmcp/lazy-zod` and must be installed in the consuming project.
 - `create({ resources })` takes `@Resource` classes or `resource(...)(handler)` / `resourceTemplate(...)(handler)` values. A plain `{ uri, name, read }` object is rejected with "Expected a class or a resource function".
@@ -127,6 +133,28 @@ Things that trip people up with `@frontmcp/react`:
 
 For connecting to a remote MCP server (HTTP), create a server-bound `DirectMcpServer` via `connect()` from `@frontmcp/sdk` and pass that instance to the provider.
 
+- `useDynamicTool` registers a **real server tool** (through `server.registerTool()`), so it runs through the server's flows (plugin hooks, authorities, `availableWhen`) and every client sees it. A name a server tool already has is refused and reported through the provider's `onError` (or `console.warn`) — it no longer shadows the server tool; registering it again (a remount) retries it. The provider's tool listing follows the server's `notifications/tools/list_changed`. On a server with several local apps (`FrontMcpInstance.createDirect({ apps: [...] })`) every dynamic tool must say which app it joins: once per server with `<FrontMcpProvider dynamicToolApps={{ default: 'browser' }}>` (keyed by server name; covers `useDynamicTool`, `mcpComponent`, store actions and `useApiClient`), or per tool with `useDynamicTool({ app })`. A `create()` server has one app, so neither is needed.
+- Page code can add tools to the running server: `const unregister = await server.registerTool({ name, description, inputSchema, execute })`. The tool joins the server's app, so it is listed and run through the server's flows (plugin hooks, authorities, `availableWhen`). Arguments are not validated against `inputSchema` — validate in `execute`. `execute` runs outside the request's turn, so it may call the server back. A taken name rejects with `ToolNameConflictError`; names are 1–64 characters.
+- `registerTool()` checks the definition before adding it: `inputSchema` must be an object schema (`type: 'object'`), and a non-string `title`/`description` or malformed `annotations`/`availableWhen` rejects with `EntryValidationError` instead of breaking `tools/list` for every tool. Registering on a disposed server (or one disposed before the registration completes) rejects with `InternalMcpError`.
+
+## Exposing Tools to Browser Agents (WebMCP)
+
+Install `@frontmcp/plugin-webmcp` to register the page server's tools with WebMCP (`document.modelContext`), the API Gemini in Chrome and other in-browser agents use:
+
+```typescript
+import { WebMcpPlugin } from '@frontmcp/plugin-webmcp';
+
+const server = await create({
+  info: { name: 'shop', version: '1.0.0' },
+  tools: [SearchProducts, AddToCart],
+  plugins: [WebMcpPlugin.init({ prefix: 'shop.' })],
+});
+```
+
+- Every agent call runs `tools:call-tool` on the `'webmcp'` surface; use `availableWhen: { surface: ['webmcp'] }` for agent-only tools and `['mcp']` to keep a tool away from browser agents.
+- Tools added later (`server.registerTool()`, `useDynamicTool`) are registered automatically; `server.dispose()` unregisters everything.
+- WebMCP is in origin trial (Chrome/Edge 149–162). Develop with `chrome://flags/#enable-webmcp-testing` and inspect with DevTools → Application → WebMCP. Without `document.modelContext` the plugin does nothing; load a polyfill such as `@mcp-b/global` for other browsers.
+
 ## Browser vs Node vs SDK Target
 
 | Aspect      | `--target browser` | `--target node`   | `--target sdk`      |
@@ -179,15 +207,16 @@ ls dist/browser/
 
 ## Troubleshooting
 
-| Problem                     | Cause                                     | Solution                                                         |
-| --------------------------- | ----------------------------------------- | ---------------------------------------------------------------- |
-| `Module not found: fs`      | Node.js module imported in browser bundle | Use a separate browser entry point that avoids Node-only imports |
-| `crypto is not defined`     | Using `node:crypto` instead of WebCrypto  | Switch to `@frontmcp/utils` crypto functions                     |
-| CORS errors on tool calls   | MCP server missing CORS headers           | Configure CORS middleware on the MCP server                      |
-| Bundle too large            | All server-side code included             | Use `--target browser` and a dedicated client entry file         |
-| `@frontmcp/utils` fs throws | File system ops called in browser         | Remove fs calls; use API endpoints or in-memory alternatives     |
-| `AsyncContextOverlapError`  | Concurrent tool calls inside one request  | Await the calls one after another (no `AsyncContext` in browser) |
-| A call never returns        | A tool calls its own server via a client  | Call other tools through `this.scope` flows                      |
+| Problem                           | Cause                                          | Solution                                                         |
+| --------------------------------- | ---------------------------------------------- | ---------------------------------------------------------------- |
+| `Module not found: fs`            | Node.js module imported in browser bundle      | Use a separate browser entry point that avoids Node-only imports |
+| `crypto is not defined`           | Using `node:crypto` instead of WebCrypto       | Switch to `@frontmcp/utils` crypto functions                     |
+| CORS errors on tool calls         | MCP server missing CORS headers                | Configure CORS middleware on the MCP server                      |
+| Bundle too large                  | All server-side code included                  | Use `--target browser` and a dedicated client entry file         |
+| `@frontmcp/utils` fs throws       | File system ops called in browser              | Remove fs calls; use API endpoints or in-memory alternatives     |
+| `AsyncContextOverlapError`        | Concurrent tool calls inside one request       | Await the calls one after another (no `AsyncContext` in browser) |
+| A call never returns              | A tool calls its own server via a client       | Call other tools through `this.scope` flows                      |
+| `create()` never settles (Vite 7) | Top-level `await create()` in the entry module | Call `create()` from a function or `.then()`                     |
 
 ## Examples
 

package/catalog/frontmcp-deployment/references/build-for-mcpb.md

@@ -65,6 +65,11 @@ frontmcp mcpb validate dist/mcpb/my-server-1.0.0.mcpb
 - `@frontmcp/sdk` must be installed and reachable at the path used by the
   build (never exclude it from bundling).
 - For `--sea` builds, Node.js ≥ 24 is required (FrontMCP targets the current SEA API).
+- The SEA binary is self-contained like `server/index.js` (FrontMCP runtime and
+  `reflect-metadata` inlined): an SEA binary resolves a bare `require()` against
+  Node's built-ins only. Smoke-test it from the extracted archive with
+  `FRONTMCP_STDIO=1 ./bin/<platform>/<name>`; `frontmcp mcpb validate` flags a
+  binary that still `require()`s a runtime package.
 
 ## What the Archive Contains
 
@@ -174,15 +179,16 @@ bundled JS, so a partial matrix is fine.
 
 ## Troubleshooting
 
-| Problem                                                          | Cause                                                          | Solution                                                                                                                             |
-| ---------------------------------------------------------------- | -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
-| `@frontmcp/sdk is required for schema extraction`                | SDK missing or externalized from bundle                        | Ensure `@frontmcp/sdk` is installed                                                                                                  |
-| `… requires "@frontmcp/sdk" but the archive has no node_modules` | Server entry still `require()`s a runtime package              | Rebuild with `frontmcp build --target mcpb` so runtime packages are bundled; `validate` reports archives that are not self-contained |
-| Archive > 100 MB                                                 | node_modules bundled or node runtime bloated                   | Tune `build.esbuild.external`, drop `--sea`, or disable `includeNodeModules`                                                         |
-| `Unknown substitution variable` on validate                      | Typo in `mcp_config.args` / `env`                              | Only `__dirname`, `HOME`, `DESKTOP`, `DOCUMENTS`, `DOWNLOADS`, `pathSeparator`, and declared `user_config` keys are allowed          |
-| `entry_point is not present in archive`                          | Custom `--entry` flag or bundler moved the file                | Re-run without the override, or update the config's `entry`                                                                          |
-| Two builds produce different SHA-256                             | `--no-deterministic` set, or inputs embed a changing timestamp | Restore deterministic mode; scan your sources for live date/time values                                                              |
-| `platform_overrides.{platform}.command` missing binary           | `--merge-from` folders don't match MCPB platform keys          | See the expected layout below                                                                                                        |
+| Problem                                                                           | Cause                                                                                 | Solution                                                                                                                             |
+| --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `@frontmcp/sdk is required for schema extraction`                                 | SDK missing or externalized from bundle                                               | Ensure `@frontmcp/sdk` is installed                                                                                                  |
+| `… requires "@frontmcp/sdk" but the archive has no node_modules`                  | Server entry still `require()`s a runtime package                                     | Rebuild with `frontmcp build --target mcpb` so runtime packages are bundled; `validate` reports archives that are not self-contained |
+| `bin/… requires "reflect-metadata", which a single-executable binary cannot load` | SEA binary built with the runtime left external (dies with `No such built-in module`) | Rebuild with `frontmcp build --target mcpb --sea`                                                                                    |
+| Archive > 100 MB                                                                  | node_modules bundled or node runtime bloated                                          | Tune `build.esbuild.external`, drop `--sea`, or disable `includeNodeModules`                                                         |
+| `Unknown substitution variable` on validate                                       | Typo in `mcp_config.args` / `env`                                                     | Only `__dirname`, `HOME`, `DESKTOP`, `DOCUMENTS`, `DOWNLOADS`, `pathSeparator`, and declared `user_config` keys are allowed          |
+| `entry_point is not present in archive`                                           | Custom `--entry` flag or bundler moved the file                                       | Re-run without the override, or update the config's `entry`                                                                          |
+| Two builds produce different SHA-256                                              | `--no-deterministic` set, or inputs embed a changing timestamp                        | Restore deterministic mode; scan your sources for live date/time values                                                              |
+| `platform_overrides.{platform}.command` missing binary                            | `--merge-from` folders don't match MCPB platform keys                                 | See the expected layout below                                                                                                        |
 
 Expected `--merge-from` layout (platform dirs must match MCPB platform keys):
 

package/catalog/frontmcp-deployment/references/build-for-sdk.md

@@ -98,7 +98,8 @@ const server = await create({
 // Call tools directly
 const result = await server.callTool('calculate', { a: 2, b: 2, operation: 'add' });
 
-// List available tools
+// List available tools: every page is read, so this is the whole list (no `nextCursor`).
+// To page yourself: `listTools({ paginate: true })`, then `listTools({ cursor: page.nextCursor })`.
 const { tools } = await server.listTools();
 
 // Clean up

package/catalog/frontmcp-deployment/references/deploy-to-cloudflare.md

@@ -125,6 +125,8 @@ Copy the returned `id` into your `wrangler.toml`.
 
 Cloudflare storage: `redis: { provider: 'vercel-kv' }` (the HTTP-based Upstash/Vercel KV client) is accepted by `--target cloudflare`; only TCP `redis` and `sqlite` configs are rejected at build time, since Workers cannot open raw sockets or load native modules.
 
+To use it for sessions, install `@vercel/kv` in the project (the build bundles it into the worker), set `KV_REST_API_URL` / `KV_REST_API_TOKEN` as `[vars]` or secrets, and set `compatibility_date` to `2024-11-11` or later: the Upstash client sends `cache: 'no-store'` on every request, which Workers reject before that date (`The 'cache' field on 'RequestInitializerDict' is not implemented`). The build accepts the provider when it can read it, either from the evaluated config or written literally as `redis: { provider: 'vercel-kv' }` in `@FrontMcp({...})`; a `redis` whose provider it can read neither way is refused, and the error says so.
+
 ## Step 4: Configure the Server
 
 ```typescript
@@ -151,7 +153,7 @@ For session storage, use Upstash Redis (HTTP) via `redis: { provider: 'vercel-kv
 
 ### Secrets, vars and `process.env`
 
-Worker bindings arrive as an argument to `fetch`, not as environment variables. The generated entry copies every **string** binding into `process.env` on the first request (existing values are never overwritten), so ordinary `process.env.MY_API_KEY` reads behave the same on Workers as under `frontmcp dev`. Non-string bindings (KV, D1, R2, Durable Objects) stay on `env`, which the entry forwards to the handler along with `ctx`. Inside a tool, resource, prompt or agent, read them with `this.workerEnv` (e.g. `this.workerEnv?.MY_KV as KVNamespace | undefined`) — it is the request's Worker `env`, read-only, and `undefined` outside a Worker request. `NODE_ENV = "production"` set in `wrangler.toml` `[vars]` is read live by the runtime context, so production mode takes effect even though the value reaches `process.env` only on the first request.
+Worker bindings arrive as an argument to `fetch`, not as environment variables. The generated entry copies every **string** binding into `process.env` on the first request (existing values are never overwritten), so ordinary `process.env.MY_API_KEY` reads behave the same on Workers as under `frontmcp dev`. Non-string bindings (KV, D1, R2, Durable Objects) stay on `env`, which the entry forwards to the handler along with `ctx`. Inside a tool, resource, prompt, agent or job, read them with `this.workerEnv` (e.g. `this.workerEnv?.MY_KV as KVNamespace | undefined`) — it is the request's Worker `env` (string bindings included), read-only, and `undefined` where the request carries no `env` (Node/Express, stdio, `create()`/`connect()` direct servers); a job run by `execute_job` reads the `env` of the request that ran it. The `process.env` copy is the generated entry's doing: the SDK never writes `process.env`, so a hand-written entry around `createWebFetchHandler` / `getServerlessHandlerAsync()` does not get it. `NODE_ENV = "production"` set in `wrangler.toml` `[vars]` is read live by the runtime context, so production mode takes effect even though the value reaches `process.env` only on the first request. Wrangler inlines the literal `process.env.NODE_ENV` at build time (`"development"` under `wrangler dev`, `"production"` under `wrangler deploy`, unless the shell sets `NODE_ENV`); FrontMCP reads the `[vars]` value past that, so `this.runtimeContext.env` / `this.isEnv('production')` follow `[vars]` under `wrangler dev` too. A `process.env.NODE_ENV` in your own tool code is still wrangler's constant — read `this.runtimeContext.env`, or run `NODE_ENV=production npx wrangler dev`.
 
 A value read at module-eval time — inside the `@FrontMcp({...})` argument itself — is still `undefined`, because the copy happens on the first request. Read configuration inside `execute()` / `read()`, or rely on `nodejs_compat_populate_process_env` (emitted by default), which populates `process.env` before your module evaluates.
 

package/catalog/frontmcp-deployment/references/deploy-to-lambda.md

@@ -36,13 +36,13 @@ This skill walks you through deploying a FrontMCP server to AWS Lambda with API
 - SAM CLI installed: `brew install aws-sam-cli` (macOS) or see AWS docs
 - Node.js 24 or later
 - A FrontMCP project ready to build
-- **Peer dependency:** `@codegenie/serverless-express` installed in your project. The Lambda adapter externalizes it at bundle time and validates its presence at build time:
+- **Peer dependency:** `@codegenie/serverless-express` installed in your project. The Lambda adapter validates its presence at build time and bundles it into `handler.cjs`, so `dist/lambda/` deploys on its own (`CodeUri: dist/lambda/`, no `node_modules` or Layer needed):
 
   ```bash
   npm install @codegenie/serverless-express
   ```
 
-  If it isn't installed, `frontmcp build --target lambda` fails with a clear error before producing artifacts.
+  If it isn't installed, `frontmcp build --target lambda` fails with a clear error before producing artifacts. `frontmcp create --target lambda` adds it to `dependencies` for you.
 
 ## Step 1: Build for Lambda