@frontmcp/skills 1.8.1 → 1.8.3

package/catalog/create-tool/SKILL.md

@@ -199,7 +199,7 @@ If a request seems to conflict with an inherited default (e.g., "wrap `inputSche
 
 11. Should the result render as a widget in the host UI?
     YES → ui: { template, … }
-          ├── Quick HTML            → ui: { template: (ctx) => '<div>…</div>' }
+          ├── Quick HTML            → ui: { template: (ctx) => ctx.helpers.html`<div>…</div>` }
           │                            See: examples/22-tool-with-ui-html-template.md
           ├── React widget (file)   → ui: { template: { file: widgetPath } }
           │                            See: examples/23-tool-with-ui-filesource-tsx.md

package/catalog/create-tool/examples/22-tool-with-ui-html-template.md

@@ -2,11 +2,12 @@
 name: 22-tool-with-ui-html-template
 level: intermediate
 description: "Tool with an inline HTML function template — `ui: { template: (ctx) => '<div>…</div>' }` — for a quick widget that doesn't need a separate `.tsx` file."
-tags: [ui, ui-widgets, html-template, escapeHtml, TemplateContext]
+tags: [ui, ui-widgets, html-template, html-tag, escapeStringResults, TemplateContext]
 features:
-  - 'Adding a `ui:` block with a function template `(ctx: TemplateContext<In, Out>) => string`'
+  - 'Adding a `ui:` block with a function template that returns markup built with the `ctx.helpers.html` tagged template'
   - 'Annotating `ctx` explicitly to dodge the TS7006 inference gap on the union `ui.template` type'
-  - "Always escaping user-controlled output with `ctx.helpers.escapeHtml(...)` so the widget can't XSS itself"
+  - "Letting `ctx.helpers.html` escape every interpolated value so tool output can't inject markup into the widget"
+  - 'Opting in to `escapeStringResults: true` so a plain string result is escaped — the default from FrontMCP 1.9'
   - 'Reading from `ctx.output` and `ctx.helpers` — the typed runtime context the template renderer hands you'
 ---
 
@@ -14,7 +15,7 @@ features:
 
 Tool with an inline HTML function template — `ui: { template: (ctx) => '<div>…</div>' }` — for a quick widget that doesn't need a separate `.tsx` file.
 
-For widgets that don't need React / state / interactivity, an inline function template is the simplest form. Read `ctx.output`, escape user-controlled fields, return an HTML string.
+For widgets that don't need React / state / interactivity, an inline function template is the simplest form. Read `ctx.output` and return markup built with the `ctx.helpers.html` tagged template — it escapes every value you interpolate.
 
 ## Code
 
@@ -38,13 +39,16 @@ type Out = { city: string; temperatureF: number; conditions: string };
   outputSchema,
   ui: {
     widgetDescription: 'Current weather card',
-    template: (ctx: TemplateContext<In, Out>) => `
+    // `html` escapes interpolated values — no manual escapeHtml needed
+    template: (ctx: TemplateContext<In, Out>) => ctx.helpers.html`
       <div style="padding:16px;font-family:system-ui;border-radius:12px;background:#f5f7fa">
-        <h2 style="margin:0 0 8px">${ctx.helpers.escapeHtml(ctx.output.city)}</h2>
+        <h2 style="margin:0 0 8px">${ctx.output.city}</h2>
         <p style="font-size:48px;margin:0">${ctx.output.temperatureF}°F</p>
-        <p style="margin:8px 0 0">${ctx.helpers.escapeHtml(ctx.output.conditions)}</p>
+        <p style="margin:8px 0 0">${ctx.output.conditions}</p>
       </div>
     `,
+    // Escape any plain string result; `html` results stay markup (the default from FrontMCP 1.9)
+    escapeStringResults: true,
   },
 })
 export class ShowWeatherCardTool extends ToolContext {
@@ -56,11 +60,16 @@ export class ShowWeatherCardTool extends ToolContext {
 
 ## What This Demonstrates
 
-- Adding a `ui:` block with a function template `(ctx: TemplateContext<In, Out>) => string`
+- Adding a `ui:` block with a function template that returns markup built with the `ctx.helpers.html` tagged template
 - Annotating `ctx` explicitly to dodge the TS7006 inference gap on the union `ui.template` type
-- Always escaping user-controlled output with `ctx.helpers.escapeHtml(...)` so the widget can't XSS itself
+- Letting `ctx.helpers.html` escape every interpolated value so tool output can't inject markup into the widget
+- Opting in to `escapeStringResults: true` so a plain string result is escaped — the default from FrontMCP 1.9
 - Reading from `ctx.output` and `ctx.helpers` — the typed runtime context the template renderer hands you
 
+## Why `html` instead of a plain template literal
+
+A plain string a template returns is rendered as markup when it looks like HTML, so `` `<p>${ctx.output.note}</p>` `` lets tool output inject tags unless you remember `escapeHtml` on every field. `ctx.helpers.html` escapes each interpolated value for you (nested `html` values and `ctx.helpers.trustedHtml(markup)` pass through as markup), and its result renders as markup whether or not `escapeStringResults` is on. Don't also call `escapeHtml` inside `html` — the value would be escaped twice. See [`ui-widgets.md`](../references/ui-widgets.md#trusted-markup-and-escaping-template-results).
+
 ## Why annotate `ctx` explicitly
 
 `ui.template` is a union of multiple callable shapes (`TemplateBuilderFn | string | ((props: any) => any) | FileSource`). TypeScript can't pick a single contextual type for the arrow's parameter, so `template: (ctx) => …` fails under `strict` / `noImplicitAny` with TS7006:
@@ -78,7 +87,7 @@ Two ways out:
 
 - Tiny widget — a card, a table row, a status badge
 - No state / interactivity
-- No external CSS / fonts / scripts beyond what `escapeHtml` can produce
+- No external CSS / fonts / scripts beyond static markup
 
 Move to a `.tsx` FileSource widget the moment you reach for React, useState, event handlers, or anything beyond static markup.
 
@@ -86,6 +95,8 @@ Move to a `.tsx` FileSource widget the moment you reach for React, useState, eve
 
 | Helper                         | Purpose                                                       |
 | ------------------------------ | ------------------------------------------------------------- |
+| `` html`…` ``                  | Build trusted markup; interpolated values are escaped         |
+| `trustedHtml(markup)`          | Mark markup you produced or sanitized yourself as trusted     |
 | `escapeHtml(str)`              | Escape HTML entities; returns `''` for null/undefined         |
 | `formatDate(date, format?)`    | Locale-formatted date                                         |
 | `formatCurrency(amount, ccy?)` | ISO-4217 currency formatting                                  |

package/catalog/create-tool/examples/24-tool-with-ui-csp-and-bridge.md

@@ -6,7 +6,7 @@ tags: [ui, csp, widgetAccessible, FrontMcpBridge, interactive-widget]
 features:
   - "Restricting the widget's outbound `fetch` via `ui.csp.connectDomains` (emitted on the resource per #455)"
   - 'Opting the widget into cross-tool calls with `widgetAccessible: true` and using `window.FrontMcpBridge.callTool(name, args)` instead of host-specific APIs'
-  - "Embedding initial data into the widget's inline `<script>` safely via `ctx.helpers.jsonEmbed(...)` (escapes `<`, `>` and `&`)"
+  - 'Building the markup with `ctx.helpers.html` and embedding initial data into the inline `<script>` via `trustedHtml(jsonEmbed(...))` (`jsonEmbed` escapes `<`, `>` and `&`)'
   - 'Surfacing in-flight status via `invocationStatus.invoking` / `invoked` so the host UI shows feedback'
 ---
 
@@ -67,12 +67,14 @@ type Out = { symbol: string; priceUsd: number; asOf: string };
       connectDomains: ['https://api.market.example'],
     },
     template: (ctx: TemplateContext<In, Out>) => {
-      const initial = ctx.helpers.jsonEmbed(ctx.output);
-      return `
+      const { html, trustedHtml, jsonEmbed } = ctx.helpers;
+      // jsonEmbed output is script-safe; trustedHtml keeps `html` from HTML-escaping its quotes
+      const initial = trustedHtml(jsonEmbed(ctx.output));
+      return html`
         <div style="padding:16px;font-family:system-ui">
-          <h2 style="margin:0">${ctx.helpers.escapeHtml(ctx.output.symbol)}</h2>
+          <h2 style="margin:0">${ctx.output.symbol}</h2>
           <p id="price" style="font-size:36px;margin:8px 0">$${ctx.output.priceUsd.toFixed(2)}</p>
-          <p id="asof" style="color:#666;margin:0">As of ${ctx.helpers.escapeHtml(ctx.output.asOf)}</p>
+          <p id="asof" style="color:#666;margin:0">As of ${ctx.output.asOf}</p>
           <button id="refresh" style="margin-top:12px;padding:8px 16px">Refresh</button>
           <script>
             (function () {
@@ -116,7 +118,7 @@ export class ShowQuoteTool extends ToolContext {
 
 - Restricting the widget's outbound `fetch` via `ui.csp.connectDomains` (emitted on the resource per #455)
 - Opting the widget into cross-tool calls with `widgetAccessible: true` and using `window.FrontMcpBridge.callTool(name, args)` instead of host-specific APIs
-- Embedding initial data into the widget's inline `<script>` safely via `ctx.helpers.jsonEmbed(...)` (escapes `<`, `>` and `&`)
+- Building the markup with `ctx.helpers.html` and embedding initial data into the inline `<script>` via `trustedHtml(jsonEmbed(...))` (`jsonEmbed` escapes `<`, `>` and `&`)
 - Surfacing in-flight status via `invocationStatus.invoking` / `invoked` so the host UI shows feedback
 
 ## Why these choices
@@ -125,3 +127,4 @@ export class ShowQuoteTool extends ToolContext {
 - **`csp.connectDomains`** — limits what the widget can `fetch` to. Without a CSP, the host's default applies (which may block everything in Claude). With `connectDomains: ['https://api.market.example']`, only that origin is reachable.
 - **`window.FrontMcpBridge.callTool` not `window.openai.callTool`** — the bridge handles host detection. `window.openai.*` works on OpenAI Apps SDK but breaks everywhere else.
 - **`jsonEmbed` not `JSON.stringify`** — `JSON.stringify` doesn't escape `</script>` or `<!--` and can break out of the inline script tag. `jsonEmbed` writes `<`, `>` and `&` as `\u003c`, `\u003e`, `\u0026`.
+- **`html` with `trustedHtml(jsonEmbed(...))`** — `ctx.helpers.html` escapes the symbol and timestamp for you, so tool output can't inject markup. Inside the `<script>` the JSON must stay as-is: `html` would HTML-escape its quotes, so the script-safe `jsonEmbed` output is wrapped with `trustedHtml`. The result renders the same with `escapeStringResults: true`, which FrontMCP 1.9 makes the default.

package/catalog/create-tool/references/availability.md

@@ -26,15 +26,15 @@ On Linux / Windows servers, this tool simply doesn't exist — it's not in `tool
 
 ## Axes
 
-| Axis         | Values                                                                                                                          | Source                                                      |
-| ------------ | ------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- |
-| `os`         | `'darwin'`, `'linux'`, `'win32'`                                                                                                | `process.platform` (since #417 — was previously `platform`) |
-| `runtime`    | `'node'`, `'browser'`, `'edge'`, `'bun'`, `'deno'`                                                                              | Detected at boot                                            |
-| `deployment` | `'serverless'`, `'standalone'`, `'distributed'`, `'browser'`                                                                    | Detected from `frontmcp.config` / env                       |
-| `provider`   | `'bare'`, `'docker'`, `'vercel'`, `'lambda'`, `'cloudflare'`, `'netlify'`, `'azure'`, `'gcp'`, `'fly'`, `'render'`, `'railway'` | Auto-detected; override with `FRONTMCP_PROVIDER=<name>`     |
-| `target`     | `'cli'`, `'node'`, `'vercel'`, `'lambda'`, `'cloudflare'`, `'browser'`, `'sdk'`, `'mcpb'`, `'distributed'`                      | Set by `frontmcp build --target <x>`; `'unknown'` in dev    |
-| `surface`    | `'mcp'`, `'cli'`, `'agent'`, `'job'`, `'http-trigger'`                                                                          | Per-call axis — which entry point is invoking the tool      |
-| `env`        | `'production'`, `'development'`, `'test'`                                                                                       | `process.env.NODE_ENV`                                      |
+| Axis         | Values                                                                                                                          | Source                                                                                             |
+| ------------ | ------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
+| `os`         | `'darwin'`, `'linux'`, `'win32'`                                                                                                | `process.platform` (since #417 — was previously `platform`)                                        |
+| `runtime`    | `'node'`, `'browser'`, `'edge'`, `'bun'`, `'deno'`                                                                              | Detected at boot                                                                                   |
+| `deployment` | `'serverless'`, `'standalone'`, `'distributed'`, `'browser'`                                                                    | Detected from `frontmcp.config` / env                                                              |
+| `provider`   | `'bare'`, `'docker'`, `'vercel'`, `'lambda'`, `'cloudflare'`, `'netlify'`, `'azure'`, `'gcp'`, `'fly'`, `'render'`, `'railway'` | Auto-detected; override with `FRONTMCP_PROVIDER=<name>`                                            |
+| `target`     | `'cli'`, `'node'`, `'vercel'`, `'lambda'`, `'cloudflare'`, `'browser'`, `'sdk'`, `'mcpb'`, `'distributed'`                      | Set by `frontmcp build --target <x>`; `'unknown'` in dev                                           |
+| `surface`    | `'mcp'`, `'cli'`, `'agent'`, `'job'`, `'http-trigger'`                                                                          | Per-call axis — which entry point is invoking the tool (only `'mcp'` and `'cli'` are tagged today) |
+| `env`        | `'production'`, `'development'`, `'test'`                                                                                       | `process.env.NODE_ENV`                                                                             |
 
 ## Semantics
 
@@ -100,6 +100,8 @@ These are fine for ergonomic branching. For tools that **shouldn't exist at all*
 
 This is the safest way to expose internal-only tools that you want an agent / job to call but don't want a user to invoke from a chat UI.
 
+An MCP client (and the in-process client of a CLI build, surface `'cli'`) never sees such a tool: it is absent from `tools/list`, and `tools/call` answers `Tool "rotate_secrets" not found`, exactly as for a tool that doesn't exist. Resources, resource templates, prompts, agents and skills (including the skills HTTP endpoints, which count as `'mcp'`) follow the same rule, and CodeCall applies its caller's surface to the tools it reaches. In-process dispatch (`this.callTool()`, an agent's own tools) carries no surface and is not restricted. `'agent'`, `'job'` and `'http-trigger'` are reserved: nothing tags them yet, so agents, jobs and HTTP triggers (all in-process) pass every `surface` check. The process-wide axes (`os`, `runtime`, ...) answer `EntryUnavailableError` instead.
+
 ## See also
 
 - [`21-tool-with-availability-constraints`](../examples/21-tool-with-availability-constraints.md)

package/catalog/create-tool/references/execution-context.md

@@ -38,15 +38,16 @@ description: What ToolContext provides at runtime — this.get, this.fetch, this
 
 ## `this.context` (FrontMcpContext)
 
-| Property       | Type              | Description                                                                                                                                                                                              |
-| -------------- | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `requestId`    | `string`          | Unique ID for this request                                                                                                                                                                               |
-| `sessionId`    | `string`          | Session identifier (for stateful transports)                                                                                                                                                             |
-| `scopeId`      | `string`          | Scope identifier (for multi-app servers)                                                                                                                                                                 |
-| `authInfo`     | `AuthInfo`        | Raw validated access token — `token`, `clientId`, `scopes`, `expiresAt?`, `resource?`, `extra?`. For user identity / JWT claims use `this.auth` (`this.auth.user.sub`, `this.auth.claims['…']`) instead. |
-| `traceContext` | `TraceContext`    | Distributed-tracing context (propagated to `this.fetch` automatically)                                                                                                                                   |
-| `timestamp`    | `number`          | Request start timestamp                                                                                                                                                                                  |
-| `metadata`     | `RequestMetadata` | Request headers, client IP, MCP client name/version                                                                                                                                                      |
+| Property            | Type                  | Description                                                                                                                                                                                                                                         |
+| ------------------- | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `requestId`         | `string`              | Unique ID for this request                                                                                                                                                                                                                          |
+| `sessionId`         | `string`              | Session identifier (for stateful transports)                                                                                                                                                                                                        |
+| `verifiedSessionId` | `string \| undefined` | `sessionId` when the server verified that session; `undefined` for a stateless request (shared stateless id, or the per-request id of a request without `mcp-session-id`). Key per-session state on it and fall back to the authenticated principal |
+| `scopeId`           | `string`              | Scope identifier (for multi-app servers)                                                                                                                                                                                                            |
+| `authInfo`          | `AuthInfo`            | Raw validated access token — `token`, `clientId`, `scopes`, `expiresAt?`, `resource?`, `extra?`. For user identity / JWT claims use `this.auth` (`this.auth.user.sub`, `this.auth.claims['…']`) instead.                                            |
+| `traceContext`      | `TraceContext`        | Distributed-tracing context (propagated to `this.fetch` automatically)                                                                                                                                                                              |
+| `timestamp`         | `number`              | Request start timestamp                                                                                                                                                                                                                             |
+| `metadata`          | `RequestMetadata`     | Request headers, client IP, MCP client name/version                                                                                                                                                                                                 |
 
 ## DI: `this.get` vs `this.tryGet`
 

package/catalog/create-tool/references/function-style-builder.md

@@ -104,7 +104,7 @@ const ShowCard = tool({
   inputSchema: { text: z.string() },
   outputSchema: { text: z.string() },
   ui: {
-    template: (ctx) => `<div>${ctx.helpers.escapeHtml(ctx.output.text)}</div>`,
+    template: (ctx) => ctx.helpers.html`<div>${ctx.output.text}</div>`,
   },
 })((input) => ({ text: input.text }));
 ```

package/catalog/create-tool/references/ui-widgets.md

@@ -1,6 +1,6 @@
 ---
 name: ui-widgets
-description: @Tool({ ui }) — template formats, servingMode, host-detect resourceMode, CSP, widgetAccessible, MCP Apps spec.
+description: @Tool({ ui }) — template formats, trusted markup (html / escapeStringResults), servingMode, host-detect resourceMode, CSP, widgetAccessible, MCP Apps spec.
 ---
 
 # Tool UI widgets
@@ -42,7 +42,7 @@ That's it. The framework:
 | Format                       | Shape                                     | When                                                                                                      |
 | ---------------------------- | ----------------------------------------- | --------------------------------------------------------------------------------------------------------- |
 | **FileSource (recommended)** | `{ file: widgetPath }`                    | `.tsx` / `.jsx` / `.html` source files. Anchor with `import.meta.url`.                                    |
-| **Function**                 | `(ctx) => string`                         | Quick demo / one-liner HTML. Annotate `ctx: TemplateContext<In, Out>` ([why](#typescript-gotcha-ts7006)). |
+| **Function**                 | `` (ctx) => ctx.helpers.html`…` ``        | Quick demo / one-liner HTML. Annotate `ctx: TemplateContext<In, Out>` ([why](#typescript-gotcha-ts7006)). |
 | **HTML / MDX string**        | `'<div>…</div>'` or `'# Title\n<Card />'` | Static markup; pair with `mdxComponents` for MDX.                                                         |
 | **React component**          | `MyWidget`                                | SSR React. Set `hydrate: false` (default) for Claude/ChatGPT.                                             |
 
@@ -56,8 +56,7 @@ Inline `template: (ctx) => …` under `strict` fails with `Parameter 'ctx' impli
 import { type TemplateContext } from '@frontmcp/sdk';
 
 ui: {
-  template: (ctx: TemplateContext<MyInput, MyOutput>) =>
-    `<div>${ctx.helpers.escapeHtml(ctx.output.label)}</div>`,
+  template: (ctx: TemplateContext<MyInput, MyOutput>) => ctx.helpers.html`<div>${ctx.output.label}</div>`,
 }
 ```
 
@@ -77,6 +76,7 @@ Or use the FileSource form — it sidesteps the issue.
 | `autoResize`                                                                                                    | `true`      | Auto-report content height to the host via a debounced `ResizeObserver` on `#root`. Set `false` to opt out (CSS still applies). |
 | `csp`                                                                                                           | —           | `{ connectDomains?, resourceDomains? }` — emitted on the resource content's `_meta.ui.csp` (#455). Claude honors CSP only here. |
 | `contentSecurity`                                                                                               | strict      | `{ allowUnsafeLinks?, allowInlineScripts?, bypassSanitization? }` — keep defaults.                                              |
+| `escapeStringResults`                                                                                           | unset       | `true` escapes plain string results of a template function; `html` / `trustedHtml` stay markup. Default in 1.9.                 |
 | `widgetAccessible`                                                                                              | `false`     | `true` exposes `window.FrontMcpBridge.callTool` in the widget.                                                                  |
 | `resourceUri`                                                                                                   | auto        | Override the `ui://widget/{toolName}.html` URI.                                                                                 |
 | `uiType`                                                                                                        | `'auto'`    | Force `'html'` / `'react'` / `'mdx'` / `'markdown'`.                                                                            |
@@ -92,11 +92,36 @@ Or use the FileSource form — it sidesteps the issue.
 - Hosts that load the widget via `resources/read` (MCP Apps hosts such as Claude) need `servingMode: 'static'` and a template that reads data from `window.FrontMcpBridge`; set `resourceMode: 'inline'` explicitly for Claude in static mode.
 - The advertised URI percent-encodes the tool name (`app:tool` → `ui://widget/app%3Atool.html`). Encoded and raw forms both read back; a name that decodes to anything outside `A-Z a-z 0-9 _ - . / : @` is rejected.
 
-## Escaping template results
+## Trusted markup and escaping template results
 
-- A string the template returns is inserted as markup when it looks like HTML — `template: (ctx) => ctx.output` renders any tags in the output. Escape untrusted fields with `ctx.helpers.escapeHtml`.
-- Everything else is escaped: plain text as text, objects as JSON inside `<pre>`, chart configs and base64 PDFs (`JVBERi…`) as script data. A value that starts with `JVBERi` but isn't base64 is shown as text.
-- `ctx.helpers.jsonEmbed(data)` writes `<`, `>`, `&`, U+2028 and U+2029 as `\uXXXX`, so it is safe inside an inline `<script>`.
+Build function-template markup with the `ctx.helpers.html` tagged template. Literal parts stay markup; every interpolated value is HTML-escaped unless it is itself trusted markup:
+
+```typescript
+template: (ctx: TemplateContext<In, Out>) => {
+  const { html } = ctx.helpers;
+  return html`
+    <h2>${ctx.output.title}</h2>
+    <ul>${ctx.output.items.map((item) => html`<li>${item.name}</li>`)}</ul>
+  `;
+},
+```
+
+- Nested `html` values are never escaped twice; arrays are joined without a separator; `null` / `undefined` / `false` render nothing. Don't pre-escape with `escapeHtml` inside `html` (double escaping). Quote attribute values; escaping doesn't validate `href` / `src` URLs.
+- `ctx.helpers.trustedHtml(markup)` marks markup you produced or sanitized yourself as trusted. Never wrap raw tool output or user input.
+- In an inline `<script>`, embed data with `${trustedHtml(jsonEmbed(data))}` — `jsonEmbed` writes `<`, `>`, `&`, U+2028 and U+2029 as `\uXXXX`, so it is safe in a script, and `html` would otherwise HTML-escape its quotes.
+- `html`, `trustedHtml`, `isTrustedHtml` and `TrustedHtml` are also exported from `@frontmcp/uipack`; `TrustedHtml` is re-exported from `@frontmcp/sdk`.
+
+A **plain string** a template function returns is rendered as markup when it looks like HTML — `template: (ctx) => ctx.output` renders any tags in the output. `escapeStringResults` opts in to escaping it:
+
+| `escapeStringResults` | Plain string result                                 | `html` / `trustedHtml` result |
+| --------------------- | --------------------------------------------------- | ----------------------------- |
+| unset (1.8 default)   | Rendered as markup; one-time notice logged per tool | Markup                        |
+| `true`                | Escaped, shown as text                              | Markup                        |
+| `false`               | Rendered as markup, no notice                       | Markup                        |
+
+Set it per tool (`ui: { escapeStringResults: true }`) or server-wide (`@FrontMcp({ ui: { escapeStringResults: true } })`; the tool setting wins). **FrontMCP 1.9 escapes plain string results by default** — return `html` / `trustedHtml` from every template function and set `escapeStringResults: true` to migrate now.
+
+Everything else is always escaped: plain text as text, objects as JSON inside `<pre>`, chart configs and base64 PDFs (`JVBERi…`) as script data. A value that starts with `JVBERi` but isn't base64 is shown as text. A static string template (`template: '<div>…</div>'`) is author markup and is never escaped.
 
 ## Path resolution gotcha (#444)
 
@@ -132,7 +157,7 @@ When the widget needs to read tool data or invoke other tools, the bridge IIFE i
 
 ```typescript
 ui: {
-  template: (ctx) => `
+  template: (ctx) => ctx.helpers.html`
     <button id="refresh">Refresh</button>
     <script>
       document.getElementById('refresh').onclick = async () => {

package/catalog/frontmcp-auth-ui/references/custom-auth-ui.md

@@ -108,7 +108,7 @@ npm install @frontmcp/ui react react-dom
 
 ### React hooks + wrapper + client mount
 
-- **`useAuthFlow()`** — the flow-state fields above plus a `submitFinish` handler. `<form onSubmit={submitFinish}>` `preventDefault`s, serializes the form, attaches `pending_auth_id` + `csrf` + the slot marker, posts to the callback, and follows the OAuth redirect.
+- **`useAuthFlow()`** — the flow-state fields above plus a `submitFinish` handler. `<form onSubmit={submitFinish}>` `preventDefault`s, serializes the form, attaches `pending_auth_id` + `csrf` + the slot marker, and submits it to the callback as a real form navigation, so the browser follows the OAuth redirect.
 - **`useExtraField(name)`** — `{ onSubmit, result, pending }` for an `auth.extras` form. On success it merges the returned `addedItems` back into context.
 - **`useAddedItems(name)`** — the server-side accumulator for a named extra, reactively.
 - **`<AuthPageWrapper>`** — outer chrome that reads the injected state once, provides it via context, and (by default) renders the enclosing `<form>` with the `pending_auth_id` + `csrf` hidden fields so a no-JS submit still works. Pass `renderForm={false}` to supply your own forms.
@@ -131,7 +131,7 @@ There is **no `/oauth/ui/:slot.js` route** — the component is transpiled serve
 ## Security — the framework owns it
 
 - **CSRF**: the server mints a per-pending-authorization token, stores it (echoed into `csrfToken`), and verifies it on the finish submit and every `auth.extras` POST with a constant-time compare. Your component never generates or checks it.
-- **CSP + anti-clickjacking**: the auth-UI HTML ships with a strict CSP — `default-src 'self'; script-src 'self' 'unsafe-inline' https://esm.sh; connect-src 'self' https://esm.sh; style-src 'self' 'unsafe-inline' https://esm.sh; img-src 'self' data: https:; frame-ancestors 'none'; base-uri 'self'; form-action 'self'` — plus `X-Frame-Options: DENY`, `X-Content-Type-Options: nosniff`, `Referrer-Policy: no-referrer`. It allows `https://esm.sh` (deps) + `'unsafe-inline'` (the JSON-escaped state script) but **NOT `'unsafe-eval'`** — the transform is server-side, never in the browser.
+- **CSP + anti-clickjacking**: the auth-UI HTML ships with a strict CSP — `default-src 'self'; script-src 'self' 'unsafe-inline' https://esm.sh; connect-src 'self' https://esm.sh; style-src 'self' 'unsafe-inline' https://esm.sh; img-src 'self' data: https:; frame-ancestors 'none'; base-uri 'self'; form-action 'self' <redirect origin>` (the validated `redirect_uri`'s origin, plus the upstream authorization endpoints on the provider-selection page) — plus `X-Frame-Options: DENY`, `X-Content-Type-Options: nosniff`, `Referrer-Policy: same-origin` (a POST of the form carries its `Origin`, which the callback checks), `Cache-Control: no-store`. The finish submit is a POST (`submitMethod: 'POST'`). It allows `https://esm.sh` (deps) + `'unsafe-inline'` (the JSON-escaped state script) but **NOT `'unsafe-eval'`** — the transform is server-side, never in the browser.
 - **No PII**: the injected state carries OAuth client identifiers + control fields only.
 - **Fail-safe**: a component that can't be transpiled (missing / invalid `.tsx`) is logged (error cached so a broken file isn't retried each request) and **falls back to the built-in page** — a broken custom page can't take the server down.
 

package/catalog/frontmcp-authorities/SKILL.md

@@ -208,8 +208,9 @@ export default class SensitiveActionTool extends ToolContext { ... }
 
 For dynamic, async authorization that does not warrant a reusable custom evaluator, use the
 `guards` field. Each guard receives the same `AuthoritiesEvaluationContext` and returns
-`true` on grant, or `false`/a denial string on deny. Guards run in sequence and combine with
-other policy fields via `operator` (default AND).
+`true` on grant, or `false`/a denial string on deny. Only `true` grants: anything else
+(`undefined` from a guard that forgot to `return`, `null`, `0`, an object) denies. Guards run
+in sequence and combine with other policy fields via `operator` (default AND).
 
 ```typescript
 import type { AuthorityGuardFn } from '@frontmcp/auth';
@@ -293,8 +294,9 @@ authorities: {
 
 - **Deny on load/read** — loading a gated skill the caller can't access throws
   `AuthorityDeniedError` (MCP code `-32003`), the same as a denied `tools/call`.
-  Covers `skills/load` (MCP), `skill://<path>/SKILL.md` and `skill://<path>/<file>`
-  reads (SEP-2640), and `GET /skills/{id}` (HTTP).
+  Covers `skills/load` (MCP) and `skill://<path>/SKILL.md` and `skill://<path>/<file>`
+  reads (SEP-2640). Over HTTP, `GET /skills/{id}` answers 404 for such a skill, as
+  for an unknown one.
 - **Filter on discovery** — gated skills the caller can't access are removed from
   `skills/search` / `skills/list` (MCP), the `skill://index.json` discovery index and
   skill-path autocomplete (SEP-2640), and `GET /skills` (HTTP).
@@ -312,14 +314,34 @@ Two limitations to design around:
   filtering and will hide the skill from discovery. Use role/permission/claims
   authorities for discoverable skills; input-dependent policies still enforce at
   load time. (Same limitation applies to tools/resources/prompts.)
-- **HTTP skills discovery is fail-closed.** The Skills HTTP API uses a binary
-  api-key/bearer gate with no claims, so gated skills are hidden from `GET /skills`
-  and denied on `GET /skills/{id}` regardless of the bearer. Serve gated skills over
-  an MCP transport for claims-based access. Ungated skills are unaffected.
+- **HTTP skills discovery follows `skillsConfig.auth`.** With `'inherit'` (the default),
+  `GET /skills`, `/llm.txt` and `/llm_full.txt` run the server's own auth, and gated
+  skills are evaluated against the caller it verified. `'api-key'`, `'bearer'` and
+  `'public'` surface no claims, so there gated skills are left out of every listing and
+  `GET /skills/{id}` answers 404 for them. Ungated skills are unaffected.
 
 Boot-time fail-fast covers skills too: a `@Skill` with `authorities` but no configured
 authorities engine fails server startup with `AuthConfigurationError`, exactly like a
-tool/resource/prompt/agent.
+tool, resource, resource template, prompt, agent, or a tool declared inside an agent
+(hidden entries included).
+
+### Rules that check nothing are refused
+
+Startup fails with `AuthConfigurationError: Invalid authorities rule: …` when an entry's or a
+profile's rule checks nothing or isn't what it looks like, and `AuthoritiesEngine.evaluate()`
+denies such a rule if it runs anyway (even under `not`):
+
+- `{}`, `{ roles: {} }`, `{ roles: { all: [] } }`, `allOf: []`, `guards: []`
+- a misspelled field (`role:`), a profile name inside `allOf`/`anyOf`, an `operator` other than `'AND'`/`'OR'`
+- an ABAC condition with no `value`, or one the operator can't use: `exists` needs `true`/`false`;
+  `in`/`notIn` a non-empty list; `gt`/`gte`/`lt`/`lte` a number; `startsWith`/`endsWith`/`matches`
+  a string (a `{ fromInput }` / `{ fromClaims }` reference works for all but `exists`)
+
+To leave an entry open, remove its `authorities`. There is no opt-out.
+
+`@Agent({ authorities })` gates the agent's `invoke_<id>` tool like any tool (hidden from
+`tools/list`, refused on `tools/call`), and tools declared inside an agent are checked against
+the caller the agent runs for, also with `execution.useToolFlow: false`.
 
 ## Scenario Routing Table
 

package/catalog/frontmcp-authorities/references/authority-profiles.md

@@ -253,7 +253,7 @@ The authorities system does not only enforce on execution. The built-in `filterB
 - `tools/list` only returns tools the current user is authorized to call
 - `resources/list` only returns resources the current user can read
 - `prompts/list` only returns prompts the current user can get
-- Skills are filtered on every discovery surface: `skills/search` / `skills/list`, the SEP-2640 `skill://index.json` index + skill-path autocomplete, and `GET /skills`. Loading a gated skill the caller can't access (via `skills/load`, a `skill://…` read, or `GET /skills/{id}`) is denied with `AuthorityDeniedError` (`-32003`).
+- Skills are filtered on every discovery surface: `skills/search` / `skills/list`, the SEP-2640 `skill://index.json` index + skill-path autocomplete, and `GET /skills`. Loading a gated skill the caller can't access via `skills/load` or a `skill://…` read is denied with `AuthorityDeniedError` (`-32003`); over HTTP, `GET /skills/{id}` answers 404, as for an unknown skill.
 
 This filtering happens automatically. No additional configuration is needed. Entries without an `authorities` field are always visible.
 
@@ -265,11 +265,17 @@ time, where input is available). For entries (especially **skills**) that must r
 discoverable, gate them with role/permission/claims-based authorities such as
 `authorities: 'admin'` or `{ roles: { any: ['admin'] } }`.
 
-**HTTP skills discovery is fail-closed.** The Skills HTTP API authenticates with a
-binary api-key/bearer gate that surfaces no JWT claims, so authority-gated skills are
-hidden from `GET /skills` and denied on `GET /skills/{id}` regardless of the bearer.
-Serve gated skills over an MCP transport (full claims context) for claims-based access;
-skills without `authorities` are served over HTTP unchanged.
+**HTTP skills discovery follows `skillsConfig.auth`.** With `'inherit'` (the default),
+`GET /skills`, `/llm.txt` and `/llm_full.txt` run the server's own auth, and gated skills
+are evaluated against the caller it verified. `'api-key'`, `'bearer'` and `'public'`
+surface no claims, so there authority-gated skills are left out of every listing and
+`GET /skills/{id}` answers 404 for them; skills without `authorities` are served over
+HTTP unchanged.
+
+**A profile must check something.** A profile whose rule checks nothing (`{}`,
+`{ roles: { all: [] } }`, a misspelled field, a profile name inside `anyOf`, an ABAC
+condition without a usable `value`) fails startup with `Invalid authorities rule: profile
+"<name>": …`, and the engine denies it.
 
 ## Profile Design Guidelines
 

package/catalog/frontmcp-authorities/references/rbac-abac-rebac.md

@@ -163,6 +163,8 @@ interface AbacCondition {
 
 An anonymous caller (public mode, `allowAnonymous`, or an `anon:` session) has no `user.sub`, even when `claimsMapping.userId` points at another claim, and a subject that is not a string counts as anonymous too, so `{ path: 'user.sub', op: 'exists', value: true }` admits signed-in callers only. A caller whose identity carries no `sub` at all gets the string `claimsMapping.userId` resolves to as its `user.sub`, when there is one, and so passes `exists`. When `claimsMapping.userId` resolves to something other than a string, a signed-in caller keeps its own `sub`. An expected value that resolves to nothing (for example a missing `fromInput` field) never satisfies `eq` or `match`, even when the actual value is missing too. A denied `tools/call` returns an error result with `_meta.code: 'AUTHORITY_DENIED'`.
 
+Every condition needs a `value` the operator can use: `exists` takes `true` or `false`, `in`/`notIn` a non-empty list, `gt`/`gte`/`lt`/`lte` a number, and `startsWith`/`endsWith`/`matches` a string; a `{ fromInput }` / `{ fromClaims }` reference works for all but `exists`. A condition without one (for example `{ path: 'user.sub', op: 'exists' }`, which would admit every caller without a `sub`) fails startup with `Invalid authorities rule`, and the engine denies it.
+
 ### Dynamic Value References
 
 Instead of hardcoding values, reference runtime data from tool input or JWT claims.

package/catalog/frontmcp-config/examples/configure-skills-http/inject-instructions.md

@@ -8,6 +8,7 @@ features:
   - 'Top-level `instructions` on `@FrontMcp` exposes a global system prompt to MCP clients'
   - "`skillsConfig.injectInstructions: 'append'` adds the skill catalog summary after the user prompt"
   - 'Dynamic skills are picked up because the composer runs on every initialize request'
+  - 'The catalog only names skills the initializing caller may see (skill authorities and the `skills:filter` flow, e.g. feature flags)'
   - 'Catalog summary is bounded at 16 KB with a truncation footer pointing at skill://index.json'
 ---
 
@@ -51,6 +52,7 @@ export default class FlightBotServer {}
 - Top-level `instructions` on `@FrontMcp` exposes a global system prompt to MCP clients
 - `skillsConfig.injectInstructions: 'append'` adds the skill catalog summary after the user prompt
 - Dynamic skills are picked up because the composer runs on every initialize request
+- The catalog only names skills the initializing caller may see (skill authorities and the `skills:filter` flow, e.g. feature flags)
 - Catalog summary is bounded at 16 KB with a truncation footer pointing at skill://index.json
 
 ## Related

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

@@ -86,7 +86,7 @@ Signing is **HS256 with a symmetric `JWT_SECRET`** (no key pair). Set a stable `
 
 Local mode also accepts `allowDefaultPublic` (default `false` — set `true` to admit tokenless requests as anonymous instead of returning 401), `anonymousScopes` (default `['anonymous']` — scopes for those anonymous sessions), and `expectedAudience` (reject tokens minted for a different `aud`).
 
-> **Client registration (security):** by default an unregistered `client_id` is accepted with whatever `redirect_uri` it presents. Set `requireRegisteredClients: true` (local/remote) to require every client to be registered (DCR / `dcr.clients`) or a CIMD client-id URL, so `redirect_uri` is exact-matched (OAuth 2.1) — this prevents auth-code interception via an attacker-chosen redirect. Confidential clients (`token_endpoint_auth_method: client_secret_basic`/`client_secret_post`) are authenticated with a constant-time `client_secret` check on both the code-exchange and refresh grants (Basic header or body param).
+> **Client registration (security):** `requireRegisteredClients` defaults to `true` (local/remote): every client must be registered (DCR / `dcr.clients`) or a CIMD client-id URL, so `redirect_uri` is exact-matched (OAuth 2.1) — this prevents auth-code interception via an attacker-chosen redirect. Set it to `false` only for local development. The server grants only the scopes in `allowedScopes` (default: the OpenID scopes). Confidential clients (`token_endpoint_auth_method: client_secret_basic`/`client_secret_post`) are authenticated with a constant-time `client_secret` check on both the code-exchange and refresh grants (Basic header or body param).
 
 > **Public origin (security):** pin `FRONTMCP_PUBLIC_URL` in production. The issuer / resource / OAuth-discovery URLs and the transparent expected audience derive from it rather than from request headers; `X-Forwarded-Host`/`X-Forwarded-Proto` are ignored unless `FRONTMCP_TRUST_PROXY=1` (a trusted proxy that strips client-supplied forwarded headers).
 
@@ -141,6 +141,8 @@ Endpoints are derived from `provider` using standard OIDC paths
 non-standard IdPs, override them with
 `providerConfig.{authEndpoint,tokenEndpoint,userInfoEndpoint,jwksUri}`.
 
+> **MCP client registration (upgrade note):** `requireRegisteredClients` defaults to `true` in remote mode too (it was `false` in 1.8.2 and earlier). Remote mode has no `dcr` block (no pre-registered clients) and FrontMCP's own `/oauth/register` is off in production, so a production remote server with the defaults admits only MCP clients that use a CIMD client-id URL; an unregistered plain `client_id` gets a 400 `Unknown client_id` page. Migrate clients to CIMD, or set `requireRegisteredClients: false` for local development only (an unregistered client's `redirect_uri` can't be checked). FrontMCP grants only the scopes in `allowedScopes` (default: the OpenID scopes), unrelated to `scopes` (what it asks the IdP for).
+
 **Deferred (not yet wired):** upstream **Dynamic Client Registration**
 (`providerConfig.dcrEnabled` / `registrationEndpoint`) — a pre-registered
 `clientId` is required; and upstream **token auto-refresh** — once the upstream

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

@@ -140,7 +140,9 @@ Declare upstream providers to make multi-provider orchestration a turnkey local
 class Server {}
 ```
 
-`UpstreamProviderOptions` fields: `id` (required; used in `getToken(id)`), `authorizationEndpoint`/`authorizeUrl` (required), `tokenEndpoint`/`tokenUrl` (required), `clientId` (required), `clientSecret?`, `scopes?`, `name?`, `userInfoEndpoint?`, `jwksUri?`. The per-provider callback URL is auto-computed as `${issuer}/oauth/provider/${id}/callback` — register that URL with each provider.
+`UpstreamProviderOptions` fields: `id` (required; used in `getToken(id)`), `authorizationEndpoint`/`authorizeUrl` (required), `tokenEndpoint`/`tokenUrl` (required), `clientId` (required), `clientSecret?`, `scopes?`, `name?`, `userInfoEndpoint?`, `jwksUri?`, `issuer?`, `additionalIssuers?`. The per-provider callback URL is auto-computed as `${issuer}/oauth/provider/${id}/callback` — register that URL with each provider.
+
+The provider's identity comes from its `id_token` only when it verifies against `jwksUri` with `iss` = the provider's `issuer` (or `additionalIssuers`), `aud` containing `clientId`, and a valid `exp`. A provider with no `issuer` never has its `id_token` used (one IdP key set can sign many tenants' tokens); FrontMCP asks `userInfoEndpoint` instead, and with neither the sign-in fails. With `issuer` set, a callback whose RFC 9207 `iss` names another server gets a 400. Set `issuer` for OIDC providers.
 
 Tools read downstream tokens through the `this.orchestration` context extension (available in `local`/`remote` mode):
 
@@ -474,13 +476,14 @@ If the vault is not configured, accessing `this.authProviders` throws (`AuthProv
 
 ## Troubleshooting
 
-| Problem                                 | Cause                                                                          | Solution                                                                                                           |
-| --------------------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------ |
-| `JWKS fetch failed` error on startup    | The `provider` URL is unreachable or does not serve `/.well-known/jwks.json`   | Verify the provider URL is correct and accessible from the server; check network/firewall rules                    |
-| Tokens rejected with `invalid audience` | The `expectedAudience` value does not match the `aud` claim in the token       | Align the `expectedAudience` config with the audience value your identity provider sets in tokens                  |
-| Sessions lost after server restart      | Using the default in-memory session store in production                        | Switch to Redis or Vercel KV session store via `configure-session` reference                                       |
-| Local-mode tokens invalid after restart | `JWT_SECRET` unset (random per-process secret) and/or `tokenStorage: 'memory'` | Set a stable `JWT_SECRET`; use `tokenStorage: { sqlite: { path } }` or `{ redis }` to persist codes/refresh tokens |
-| OAuth redirect fails in local dev       | `remote` mode requires HTTPS and reachable callback URLs                       | Set `NODE_ENV=development` to relax HTTPS requirements, or use a local OAuth mock server                           |
+| Problem                                       | Cause                                                                                                                                                                            | Solution                                                                                                                                                                      |
+| --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `JWKS fetch failed` error on startup          | The `provider` URL is unreachable or does not serve `/.well-known/jwks.json`                                                                                                     | Verify the provider URL is correct and accessible from the server; check network/firewall rules                                                                               |
+| Tokens rejected with `invalid audience`       | The `expectedAudience` value does not match the `aud` claim in the token                                                                                                         | Align the `expectedAudience` config with the audience value your identity provider sets in tokens                                                                             |
+| Sessions lost after server restart            | Using the default in-memory session store in production                                                                                                                          | Switch to Redis or Vercel KV session store via `configure-session` reference                                                                                                  |
+| Local-mode tokens invalid after restart       | `JWT_SECRET` unset (random per-process secret) and/or `tokenStorage: 'memory'`                                                                                                   | Set a stable `JWT_SECRET`; use `tokenStorage: { sqlite: { path } }` or `{ redis }` to persist codes/refresh tokens                                                            |
+| OAuth redirect fails in local dev             | `remote` mode requires HTTPS and reachable callback URLs                                                                                                                         | Set `NODE_ENV=development` to relax HTTPS requirements, or use a local OAuth mock server                                                                                      |
+| Sign-in refused: "started in another browser" | The sign-in binding cookie is missing: `frontmcp_signin_<id>`, or `__Host-frontmcp_signin_<id>` over https (only that name counts there, so a sibling subdomain cannot plant it) | Start and finish the sign-in in one browser with cookies on, at the issuer's host; behind a proxy, pin `FRONTMCP_PUBLIC_URL` and forward `x-forwarded-proto` on every request |
 
 ## Examples
 

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

@@ -68,6 +68,8 @@ The catalog summary is built by `composeInitializeInstructions(...)` and `buildS
 
 > **Dynamic skills:** because the composer recomputes the summary on every `initialize` request, skills registered after server boot **are** picked up automatically.
 
+> **Per caller:** the summary (and the SEP-2640 `skill://` hints under `sep2640InInstructions`) is composed for the client that initializes, like `skills/list`: it only names skills whose `authorities` that caller satisfies and that the hookable `skills:filter` flow keeps, so a flag-disabled skill's name and description are left out. With nothing gating a skill the instructions are unchanged. Transports use `composeCallerInstructions(scope, { ctx })`, exported from `@frontmcp/sdk` for custom transports.
+
 ## Skills HTTP Authentication
 
 ```typescript
@@ -96,6 +98,19 @@ explicitly to opt out of authentication; use `'api-key'` or `'bearer'` to
 override the inherited policy with a Skills-specific one. **In production,
 set `auth` explicitly so the policy is visible at the call site.**
 
+With `'inherit'`, `/skills`, `/llm.txt` and `/llm_full.txt` need the same credential
+as the MCP endpoint (401/403 otherwise; only a public-mode server lets everyone in),
+and skills with `authorities` are listed only for a caller whose verified claims
+satisfy them. The other modes surface no claims, so gated skills are never served
+over HTTP there, and `GET /skills/<gated id>` answers 404.
+
+Custom routes that guard skills content should call `authorizeSkillHttpRequest(scope,
+skillsConfig, request)` from `@frontmcp/sdk`, which covers every mode.
+`createSkillHttpAuthValidator()` is only for an explicit `'api-key'` or `'bearer'`
+(it returns `null` only for `'public'`); its validator only sees headers, so it
+refuses every request under `'inherit'` or an unset `auth`, and code that treated
+`null` as "no auth needed" must switch to `authorizeSkillHttpRequest`.
+
 ## Skills HTTP Caching
 
 ```typescript

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

@@ -27,6 +27,13 @@ short AgentScript program in the Worker isolate, where each `callTool(actionId,
 input)` invokes a loaded skill's operation. The bundle is pulled from a SaaS
 endpoint, cached in KV, and refreshed on a Cron Trigger.
 
+The meta-tools only show what the caller may use: a skill whose
+`requiredAuthorities` the caller doesn't satisfy is left out of `search_skill`
+(and its catalog) and is `SKILL_NOT_FOUND` for `load_skill`, and `load_skill`
+leaves out actions the caller can never run. When the server configures
+`authorities`, bundle rules are evaluated with the server's engine (its
+`claimsMapping`, resolvers and custom evaluators).
+
 For the conceptual picture, see [Skills-Only Deployment](https://docs.agentfront.dev/frontmcp/features/skills-only-deployment).
 For the production-ready decorator build, see [`deploy-to-cloudflare.md`](./deploy-to-cloudflare.md).
 
@@ -53,6 +60,8 @@ For the production-ready decorator build, see [`deploy-to-cloudflare.md`](./depl
 
 ```ts
 // worker.ts — the real API is createEdgeMcp (not createWorker)
+import { env } from 'cloudflare:workers';
+
 import { createEdgeMcp, kvBundleCacheFromEnv } from '@frontmcp/edge';
 
 export default createEdgeMcp({
@@ -61,7 +70,10 @@ export default createEdgeMcp({
   tasks: { enabled: false },
   managed: {
     endpoint: 'https://cloud.example.com/v1/bundles/acme',
-    authToken: 'pinned-pull-token',
+    // The pull JWT the SaaS issued for this server (iss = expectedIssuer, aud includes
+    // expectedAudience, with exp), kept in a Worker secret:
+    //   npx wrangler secret put FRONTMCP_PULL_TOKEN
+    authToken: env.FRONTMCP_PULL_TOKEN,
     expectedAudience: 'acme-mcp',
     jwksUrl: 'https://cloud.example.com/.well-known/jwks.json',
     expectedIssuer: 'https://cloud.example.com',
@@ -79,6 +91,15 @@ The pull sends `authToken` as a bearer token and never follows a redirect, so
 `endpoint` must serve the bundle directly; a 3xx (or a status-0
 `opaqueredirect`) fails the pull.
 
+Before every pull, `authToken` itself is verified: it must be a JWT signed by a
+key served at `jwksUrl` (fetched without the token, redirects refused), with
+`iss` equal to `expectedIssuer`, an `aud` that includes `expectedAudience` (and
+a `resource` claim that does too, when it has one), and not expired. A token
+that fails is refused with `[saas-source] pull token rejected: …`: nothing is
+pulled, and the KV cache is **not** used in its place. An unreachable JWKS, or
+one with no usable signing key (no RSA, EC or OKP public key for signatures),
+counts as an ordinary pull failure, so the cache fallback still applies.
+
 This path is bundled by **wrangler** (not `frontmcp build`), so you maintain
 `wrangler.toml` yourself — it needs a `[[kv_namespaces]] binding = "BUNDLE_CACHE"`
 and a `[triggers] crontabs = [...]` (the `managed.pollIntervalMs` option is

package/catalog/frontmcp-development/examples/openapi-adapter/authenticated-adapter-with-polling.md

@@ -20,8 +20,11 @@ Demonstrates configuring authentication (API key and bearer token) and automatic
 
 ```typescript
 // src/server.ts
-import { FrontMcp, App } from '@frontmcp/sdk';
 import { OpenapiAdapter } from '@frontmcp/adapters';
+import { App, FrontMcp } from '@frontmcp/sdk';
+
+// Your code: returns a token issued for the upstream API (secrets manager, token exchange, ...)
+declare function getEvolvingApiToken(ctx: unknown): Promise<string>;
 
 @App({
   name: 'integrations',
@@ -51,8 +54,9 @@ import { OpenapiAdapter } from '@frontmcp/adapters';
       name: 'evolving-api',
       url: 'https://api.example.com/openapi.json',
       baseUrl: 'https://api.example.com',
-      securityResolver: (tool, ctx) => {
-        return { jwt: ctx.authInfo?.token };
+      securityResolver: async (tool, ctx) => {
+        // A credential issued for this API (never the caller's own ctx.authInfo.token)
+        return { jwt: await getEvolvingApiToken(ctx) };
       },
       polling: {
         intervalMs: 300000, // Re-fetch spec every 5 minutes

package/catalog/frontmcp-development/references/create-plugin-hooks.md

@@ -190,11 +190,13 @@ Both `@Will` and `@Did` (and `@Around`) accept an optional options object:
 @Will('execute', {
   priority: 10,                          // Lower runs first (default: 0)
   filter: (ctx) => ctx.toolName !== 'health_check',  // Predicate to skip
+  appliesTo: 'own-app',                  // Reach of an app plugin's hook (default: 'own-app')
 })
 ```
 
 - **priority** (`number`) - Execution order when multiple hooks target the same stage. Lower values run first, for `@Will`, `@Did` and `@Around` alike. Default: `0`.
 - **filter** (`(ctx) => boolean`) - A predicate that receives the flow context. Return `false` to skip this hook for the current invocation.
+- **appliesTo** (`'own-app' | 'uncovered-apps'`) - A hook of a plugin installed on an app runs, in `tools/call`, `resources/read`, `prompts/get` and `completion/complete`, only for that app's entries (`'own-app'`). With `'uncovered-apps'` it also runs for the entries of any app that has no instance of the same hook (same class and method) of its own or from a server-level plugin. Use it for gates an entry's metadata asks for (approval, feature flags), so the entry is not left ungated when the plugin sits on another app. Server-level plugins' hooks, and list-flow hooks, already run for every app.
 
 ## Examples
 

package/catalog/frontmcp-development/references/create-plugin.md

@@ -307,6 +307,39 @@ Register with `init()`:
 class MyServer {}
 ```
 
+### Option-derived providers are registered before nested plugins
+
+`dynamicProviders(options)` and `init({ providers })` are registered **before** the plugin's nested `plugins` are built, for both `init(options)` and `init({ inject, useFactory })` (the factory runs first). A nested plugin can inject them:
+
+```typescript
+@Plugin({
+  name: 'my-plugin',
+  plugins: [
+    AuditPlugin.init({
+      inject: () => [MyServiceToken],
+      useFactory: (service: MyService) => ({ channel: service.auditChannel }),
+    }),
+  ],
+})
+export default class MyPlugin extends DynamicPlugin<MyPluginOptions, MyPluginOptionsInput> {
+  /* dynamicProviders() returns MyServiceToken as above */
+}
+```
+
+The reverse does not work: an option-derived provider cannot inject a provider that a nested plugin exports.
+
+### Installing the same plugin in several apps
+
+Each app that installs a plugin gets its own copy of the plugin's providers, including CONTEXT-scoped ones. Tools, resources and prompts resolve the nearest definition in their own hierarchy (plugin, then app, then server). So `this.myService` in app A uses A's options even when app B installs `MyPlugin.init()` with different options:
+
+```typescript
+@App({ id: 'billing', plugins: [MyPlugin.init({ endpoint: 'https://billing.example.com' })], tools: [RefundTool] })
+class BillingApp {}
+
+@App({ id: 'ops', plugins: [MyPlugin.init({ endpoint: 'https://ops.example.com' })], tools: [DeployTool] })
+class OpsApp {}
+```
+
 ## Step 5: Extend Metadata and Execution Context
 
 FrontMCP provides two extension mechanisms for plugins: **metadata augmentation** (add fields to decorators) and **context extensions** (add properties to `this` in tools/resources/prompts).
@@ -458,13 +491,14 @@ plugins/
 
 ## Common Patterns
 
-| Pattern                        | Correct                                                                                        | Incorrect                                                             | Why                                                                          |
-| ------------------------------ | ---------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
-| Context extension registration | `contextExtensions: [{ property: 'auditLog', token: AuditLoggerToken }]` in metadata           | `Object.defineProperty(ExecutionContextBase.prototype, ...)` manually | SDK handles runtime installation; manual modification causes ordering issues |
-| Type augmentation              | `declare module '@frontmcp/sdk' { interface ExecutionContextBase { ... } }` in a separate file | Skipping the augmentation and casting `this` in tools                 | Without augmentation, TypeScript cannot type-check `this.auditLog`           |
-| Provider types                 | `Token<AuditLogger> = Symbol('AuditLogger')` with typed token                                  | `provide: Symbol('AuditLogger')` without type annotation              | Typed tokens enable compile-time DI resolution checking                      |
-| Plugin scope                   | `scope: 'app'` (default) for app-scoped behavior                                               | `scope: 'server'` when hooks should only apply to one app             | Server scope fires hooks for all apps in a gateway; default to app           |
-| Dynamic options                | Extend `DynamicPlugin<TOptions, TInput>` with `static dynamicProviders()`                      | Constructing providers in the constructor body                        | `dynamicProviders` runs before instantiation, enabling proper DI wiring      |
+| Pattern                        | Correct                                                                                              | Incorrect                                                             | Why                                                                          |
+| ------------------------------ | ---------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
+| Context extension registration | `contextExtensions: [{ property: 'auditLog', token: AuditLoggerToken }]` in metadata                 | `Object.defineProperty(ExecutionContextBase.prototype, ...)` manually | SDK handles runtime installation; manual modification causes ordering issues |
+| Type augmentation              | `declare module '@frontmcp/sdk' { interface ExecutionContextBase { ... } }` in a separate file       | Skipping the augmentation and casting `this` in tools                 | Without augmentation, TypeScript cannot type-check `this.auditLog`           |
+| Provider types                 | `Token<AuditLogger> = Symbol('AuditLogger')` with typed token                                        | `provide: Symbol('AuditLogger')` without type annotation              | Typed tokens enable compile-time DI resolution checking                      |
+| Plugin scope                   | `scope: 'app'` (default) for app-scoped behavior                                                     | `scope: 'server'` when hooks should only apply to one app             | Server scope fires hooks for all apps in a gateway; default to app           |
+| Dynamic options                | Extend `DynamicPlugin<TOptions, TInput>` with `static dynamicProviders()`                            | Constructing providers in the constructor body                        | `dynamicProviders` runs before instantiation, enabling proper DI wiring      |
+| Nested plugin needs options    | Nested `Plugin.init({ inject: () => [HostToken], useFactory })` injecting a `dynamicProviders` token | Resolving the host's option-derived provider by reading global state  | Option-derived providers are registered before nested plugins are built      |
 
 ## Verification Checklist
 

package/catalog/frontmcp-development/references/create-provider.md

@@ -104,6 +104,13 @@ export const databaseProvider = AsyncProvider({
 });
 ```
 
+`scope` is `ProviderScope.GLOBAL` (the default: one instance per process/worker, right for
+pools and clients) or `ProviderScope.CONTEXT` (one instance per request). A client that opens a
+session (MCP before 2026-07-28) keeps one CONTEXT instance for the session the server verified;
+any other caller, such as one with a token under 2026-07-28, gets new instances on every request,
+never another caller's. State that must outlive a request belongs in a GLOBAL provider or in
+storage keyed by the caller's identity.
+
 ## Step 3: Register in @App or @FrontMcp
 
 ```typescript

package/catalog/frontmcp-development/references/official-plugins.md

@@ -160,8 +160,9 @@ One policy decides every CodeCall surface: `codecall:search`, `codecall:describe
 ```typescript
 CodeCallPlugin.init({
   mode: 'codecall_only',
-  // `tool` is { name, appId, source, description, tags }; `name` is the tool's own name, never `<appId>:<name>`
-  includeTools: (tool) => !tool.name.startsWith('admin:'),
+  // `tool` is { name, fullName, appId, source, description, tags, annotations, metadata }, read-only;
+  // `name` is the tool's own name, never `<appId>:<name>`
+  includeTools: (tool) => !tool.name.startsWith('admin:') && !tool.annotations?.destructiveHint,
   directCalls: {
     enabled: true,
     allowedTools: ['users:list', 'crm:users:get'], // bare name, or `<appId>:<name>` to pin one app
@@ -174,6 +175,9 @@ CodeCallPlugin.init({
 - `codecall:searchSkills` and `codecall:searchKnowledge` run the SDK's `skills:filter` flow, so a skill a plugin withholds there (a flag-disabled skill, for one) is absent from both.
 - `directCalls.allowedTools` and `directCalls.filter` only narrow the base policy; listing a withheld tool does not make it callable. Unlisted tools are refused.
 - Hiding a tool from search is not the control; the refusal at execution is. Do not rely on `visibleInListTools` or search ranking to protect a tool.
+- `includeTools` and `directCalls.filter` receive the same object, with the tool's `annotations` and declared `metadata` (`tool.metadata?.annotations` is the same object as `tool.annotations`). It is a deep read-only copy, so a filter cannot change what the next decision reads.
+- Namespace bindings (`mail.send({...})` for a tool named `mail.send`) are AgentScript wrappers over `callTool()` inside the sandbox: they count toward `vm.maxSteps` and pass the rate limit and suspicious-sequence checks exactly like `callTool('mail.send', {...})`. A binding with no argument sends `{}`.
+- `codecall:execute` results never include a `stack`, in any environment. In `runtime_error`, `syntax_error` and `tool_error` messages, stack frames are dropped and absolute paths (POSIX, Windows, UNC, `file:` URLs, quoted paths) become `[path]`; other URLs are kept.
 
 ### Power Features
 
@@ -277,17 +281,21 @@ class MyTool extends ToolContext {
 
 ### Memory Scopes
 
-- `session` -- Valid only for the current session. Default scope. Cleared when the session ends.
+- `session` -- Default scope. With a verified session, valid only for that session and cleared
+  when it ends. Without one (stateless transport, MCP 2026-07-28), it belongs to the authenticated
+  principal and lasts across that principal's requests until its TTL, not per request.
 - `user` -- Persists for the user across sessions. Tied to user identity.
-- `tool` -- Scoped to a specific tool + session combination. Isolated per tool.
+- `tool` -- Scoped to a specific tool plus the same identity as `session` (the verified session,
+  else the authenticated principal). Isolated per tool.
 - `global` -- Shared across all sessions and users. Use carefully.
 
-**`session`, `tool`, and `user` scopes require a per-client identity.** A stateless HTTP
-transport injects the same session id (`__stateless__`) into every request, so it carries no
-session identity. `session` and `tool` scope fall back to the authenticated principal, and an
-unauthenticated stateless request is refused with a `RememberIdentityError` rather than given
-a namespace shared with every other client. `user` scope is refused with no authenticated
-user. If the data really is shared, use `scope: 'global'`.
+**`session`, `tool`, and `user` scopes require a per-client identity.** `session` and `tool`
+memory belong to the session the server verified, never to an `mcp-session-id` the client merely
+sends. A stateless HTTP transport (shared `__stateless__` id), MCP 2026-07-28 (no sessions) and an
+unverified `mcp-session-id` carry no session identity: `session` and `tool` scope fall back to the
+authenticated principal, and an unauthenticated request without a verified session is refused
+with a `RememberIdentityError` rather than given a namespace shared with other clients. `user`
+scope is refused with no authenticated user. If the data really is shared, use `scope: 'global'`.
 
 **Set `REMEMBER_SECRET` on every instance that shares a store.** All scopes, `session` and
 `tool` included, derive their encryption key from that secret plus the scope identity. A
@@ -405,11 +413,14 @@ authInfo.extra.approvalContext = { type: 'project', identifier: resolvedProjectI
 ### How the check decides
 
 1. `skipApproval: true`, or approval not required: the tool runs.
-2. A recorded **denial** for the caller (session or user scope): refused with state `denied`. A
-   denial outranks pre-approved contexts and any session approval.
+2. A recorded **denial** for the caller (session, user, time-limited or context scope): refused
+   with state `denied`. A denial outranks pre-approved contexts and any approval.
 3. The session context is one of `preApprovedContexts`: the tool runs.
 4. `alwaysPrompt: true`: refused with state `pending`.
-5. A valid approval for the caller: the tool runs.
+5. An approval for the caller that the tool's policy accepts: the tool runs. The caller's session,
+   user, time-limited and context approvals all count (a context approval only when the session
+   carries that context); its scope must be in `allowedScopes`, and it must be younger than
+   `maxTtlMs`, however it was stored.
 6. Otherwise refused with state `pending` (or `expired`).
 
 A refused call throws `ApprovalRequiredError`; the client receives an error result.
@@ -417,18 +428,26 @@ A refused call throws `ApprovalRequiredError`; the client receives an error resu
 Approvals are looked up by the tool's full name, `<owner id>:<tool name>`, so pass that name to
 `this.approval` grant and check methods. The owner is the app that declares the tool, or the
 adapter or plugin that provides it (`my-app:file_write` for a tool declared on app `my-app`,
-`github-api:create_issue` for one its `github-api` adapter provides). Session approvals belong to the
-caller's session; on the stateless HTTP transport, where every request shares one session id,
-they are keyed by the authenticated principal (`authInfo.extra.userId`, then `authInfo.extra.sub`,
-then `authInfo.clientId`). A stateless call with no
-principal cannot hold a session approval.
-
-Installed on an app, `ApprovalPlugin` gates only that app's tools (including those its adapters
-and plugins provide) against its own store, so two apps can each install it with separate stores.
-Installed on the server, it gates every tool; a tool both gate must pass each store's check. With
-two apps each installing it, `this.approval` currently resolves the store of the app registered
-last ([#600](https://github.com/agentfront/frontmcp/issues/600)) -- grant through each app's
-store directly, or install `ApprovalPlugin` once on the server.
+`github-api:create_issue` for one its `github-api` adapter provides). Session approvals belong to a
+session the server verified (`FrontMcpContext.verifiedSessionId`). A stateless request has none -- it
+carries the shared stateless session id, or sends no `mcp-session-id` and runs under a fresh
+per-request id -- so it is keyed by the authenticated principal (`authInfo.extra.userId`, then
+`authInfo.extra.sub`, then `authInfo.clientId`): a grant made in one stateless request is found by
+the same principal's next request and by no other principal. A stateless call with no principal
+cannot hold a session approval. Releases up to 1.8.1 keyed a request without `mcp-session-id` by
+its per-request id, so the grant was never found again
+([#597](https://github.com/agentfront/frontmcp/issues/597)).
+
+Installed on an app, `ApprovalPlugin` gates that app's tools (including those its adapters and
+plugins provide) against its own store, so two apps can each install it with separate stores. It
+also gates, against its store, the `approval` tools of apps with no approval plugin of their own,
+so such a tool never runs ungated because the plugin sits on another app (releases up to 1.8.2 ran
+them for anyone). Installed on the server, it gates every tool; a tool several plugins gate must
+pass each store's check, and a denial in any of them refuses the call.
+`this.approval` resolves the `ApprovalService` of the nearest `ApprovalPlugin` -- the one the
+tool's own app installed, otherwise the server's -- so with two apps each installing it, a grant
+or check in one app's tool uses that app's store. Releases up to 1.8.1 resolved the store of the
+app registered last ([#600](https://github.com/agentfront/frontmcp/issues/600)).
 
 ### Using `this.approval` in Tools
 
@@ -451,8 +470,11 @@ class DangerousActionTool extends ToolContext {
     // await this.approval.getSessionApprovals()            -- List session approvals
     // await this.approval.getUserApprovals()                -- List user approvals
     // await this.approval.grantUserApproval('tool-id')     -- Persist across sessions
-    // await this.approval.grantTimeLimitedApproval('tool-id', 60000)  -- Auto-expire
-    // await this.approval.revokeApproval('tool-id')        -- Revoke any approval
+    // await this.approval.grantTimeLimitedApproval('tool-id', 60000)  -- Auto-expire (ttlMs > 0)
+    // await this.approval.revokeApproval('tool-id')        -- Revoke the caller's session, user,
+    //                                                         time-limited and context approvals;
+    //                                                         returns whether any was revoked
+    //                                                         (recorded denials are kept)
 
     return { content: [{ type: 'text', text: 'Action completed' }] };
   }
@@ -472,6 +494,8 @@ import { ApprovalScope } from '@frontmcp/plugin-approval';
     category: 'write',
     riskLevel: 'medium', // 'low' | 'medium' | 'high' | 'critical'
     approvalMessage: 'Allow file writing for this session?',
+    allowedScopes: [ApprovalScope.SESSION, ApprovalScope.TIME_LIMITED],
+    maxTtlMs: 60 * 60 * 1000,
   },
 })
 class FileWriteTool extends ToolContext {
@@ -479,6 +503,12 @@ class FileWriteTool extends ToolContext {
 }
 ```
 
+- `allowedScopes` is enforced: granting another scope through `this.approval` throws
+  `ApprovalScopeNotAllowedError`, and a stored approval of another scope does not open the gate.
+- `maxTtlMs` is enforced: a longer `grantTimeLimitedApproval()` throws `ApprovalOperationError`,
+  grants without a TTL get `maxTtlMs`, and no approval counts beyond `grantedAt + maxTtlMs`.
+- A `ttlMs` of 0, a negative number, `NaN` or `Infinity` throws, and a time-limited grant needs one.
+
 When `approval.required` is `true`, the plugin automatically intercepts tool execution and checks approval status before allowing the tool to run.
 
 ---
@@ -496,9 +526,11 @@ response to everyone else.
 
 The identity is the subject your auth layer puts in `authInfo.extra` (`sub` / `userId`), then
 the client id, then the session. For a request the SDK verified, the client id is the token's
-`sub`, or `anon:<id>` for an anonymous session. The session id the stateless HTTP transport
-gives every request is not an identity. A call with no identity at all gets a key of its own
-rather than one shared with every other identity-less caller.
+`sub`, or `anon:<id>` for an anonymous session. Only a session the server verified
+(`FrontMcpContext.verifiedSessionId`) is an identity: the session id the stateless HTTP transport
+gives every request, the fresh per-request id of a request without `mcp-session-id`, and an
+`mcp-session-id` the server did not accept are not. A call with no identity at all gets a key of
+its own rather than one shared with every other identity-less caller.
 
 Set `keyByIdentity: false` **only** when every caller would get byte-identical output: public
 reference data, a currency table, a static document.
@@ -753,13 +785,17 @@ The plugin hooks into listing and execution flows for tools, resources, resource
 
 | Capability        | Hidden from                                                                                                                                                                                                    | Refused on                                                                                                      |
 | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
-| Tool              | `tools/list`                                                                                                                                                                                                   | `tools/call`                                                                                                    |
+| Tool              | `tools/list`, and the `toolName` completion of `ui://widget/{toolName}.html`                                                                                                                                   | `tools/call`                                                                                                    |
 | Resource          | `resources/list`                                                                                                                                                                                               | `resources/read`, `completion/complete`                                                                         |
 | Resource template | `resources/templates/list`                                                                                                                                                                                     | `resources/read` of any URI it matches, `completion/complete`                                                   |
 | Prompt            | `prompts/list`                                                                                                                                                                                                 | `prompts/get`, `completion/complete`                                                                            |
 | Skill             | `skills/search`, `skills/list`, `skill://index.json`, its `skill://<path>/SKILL.md` entry in `resources/list`, `GET /skills`, `/llm.txt`, `/llm_full.txt`, `codecall:searchSkills`, `codecall:searchKnowledge` | `skills/load`, `skill://<path>/SKILL.md` and its files, `GET /skills/{id}` (same answer as a nonexistent skill) |
 
-Installed on an `@App`, the gates cover every capability that app provides, including tools, resources and prompts contributed by its adapters (e.g. an OpenAPI adapter) and plugins. Its tool, resource, prompt and completion gates do not run for other apps' capabilities -- install it in `@FrontMcp({ plugins })` to gate every app. Resources and prompts served outside every app (the SEP-2640 `skill://` resources) are gated by every installed copy. Skills are gated through the `skills:filter` flow, which every skill surface runs -- as the calling user on every transport, stdio and in-memory included; custom plugins can hook `Did('filterSkills')` on it the same way, and reuse `filterServableSkills(scope, skills)` from `@frontmcp/sdk` to serve skills from a surface of their own.
+The `toolName` completion of `ui://widget/{toolName}.html` runs the caller's `tools:list-tools` flow, so it offers only the UI tools `tools/list` shows that caller -- a flagged-off tool is left out there too ([#596](https://github.com/agentfront/frontmcp/issues/596)).
+
+The skill catalog in the `initialize` instructions (and the SEP-2640 `skill://` hints under `skillsConfig.sep2640InInstructions`) is filtered for the initializing client too, so a flag-disabled skill's name and description never appear there ([#603](https://github.com/agentfront/frontmcp/issues/603)). A skill's `skill://<path>/SKILL.md` entry in `resources/list` is gated by the skill that path serves now -- replace a skill at the same path and the entry takes the new skill's flag ([#606](https://github.com/agentfront/frontmcp/issues/606)).
+
+Installed on an `@App`, the gates cover every capability that app provides, including tools, resources and prompts contributed by its adapters (e.g. an OpenAPI adapter) and plugins. Its tool, resource, prompt and completion gates also cover the flagged capabilities of apps with no feature-flag plugin of their own (as its list filters already did), but not those of an app that installs its own -- install it in `@FrontMcp({ plugins })` to gate every app with one adapter. Releases up to 1.8.2 hid another app's flagged-off tool from `tools/list` but still ran it when called by name. Resources and prompts served outside every app (the SEP-2640 `skill://` resources) are gated by every installed copy. Skills are gated through the `skills:filter` flow, which every skill surface runs -- as the calling user on every transport, stdio and in-memory included; custom plugins can hook `Did('filterSkills')` on it the same way, and reuse `filterServableSkills(scope, skills)` from `@frontmcp/sdk` to serve skills from a surface of their own.
 
 ---
 
@@ -808,7 +844,7 @@ interface DashboardPluginOptionsInput {
   basePath?: string; // Default: '/dashboard'
   auth?: {
     enabled?: boolean; // Default: false
-    token?: string; // Query param auth (?token=xxx)
+    token?: string; // Bearer / x-frontmcp-dashboard-token; ?token=xxx for the page only
   };
   cdn?: {
     entrypoint?: string; // Custom UI bundle URL
@@ -820,9 +856,9 @@ interface DashboardPluginOptionsInput {
 }
 ```
 
-- `enabled` -- When omitted, the dashboard is automatically enabled in development (`NODE_ENV !== 'production'`) and disabled in production.
-- `basePath` -- URL path where the dashboard is served. Default: `'/dashboard'`.
-- `auth.enabled` / `auth.token` -- Gate the dashboard page on a shared secret. Present it as `Authorization: Bearer <token>` (preferred) or `?token=<value>`. `enabled: true` without a `token` is a **startup error** — the server refuses to boot rather than serve an "authenticated" dashboard with nothing to check. The token is compared in constant time and is never embedded in the served page.
+- `enabled` -- When omitted, the dashboard is automatically enabled in development (`NODE_ENV !== 'production'`) and disabled in production. Disabled means disabled everywhere: the page and the dashboard's MCP endpoint answer 404, and its tools refuse with `DASHBOARD_DISABLED` on every transport (`createDirect` and stdio included). To keep the dashboard in production, set `enabled: true` with `auth`.
+- `basePath` -- URL path where the dashboard page is served. Default: `'/dashboard'`. The page's MCP client talks to the dashboard app's own route (`/dashboard`, after the server's `entryPath`), which `basePath` does not move.
+- `auth.enabled` / `auth.token` -- Gate the dashboard on a shared secret: the page, its MCP endpoint and its tools. The page takes `Authorization: Bearer <token>` (preferred) or `?token=<value>`, and sets an HttpOnly `SameSite=Strict` cookie (an HMAC of the token, never the token) that its own MCP client uses. MCP clients send `Authorization: Bearer <token>`, or `x-frontmcp-dashboard-token: <token>` when the server's own auth uses `Authorization`; `?token=` is refused there. Without the token the MCP endpoint answers 401 (`WWW-Authenticate: Bearer realm="frontmcp-dashboard"`). `enabled: true` without a `token` is a **startup error** — the server refuses to boot rather than serve an "authenticated" dashboard with nothing to check. The token is compared in constant time and is never embedded in the served page.
 - `cdn` -- Override default CDN URLs for the dashboard UI bundle and its dependencies. Useful for air-gapped environments.
 
 ### Security
@@ -832,12 +868,12 @@ interface DashboardPluginOptionsInput {
 The dashboard's MCP scope **inherits the server's authentication**. Its introspection tools (`dashboard:graph`, `dashboard:list-tools`, `dashboard:list-resources`) reach the root scope and enumerate every app, tool, resource and prompt on the server — including names, descriptions and (on request) schemas. Two consequences:
 
 - On an authenticated server (`local`, `remote`, `transparent`, `orchestrated`), the dashboard requires the same credential as everything else.
-- On a **public** server the dashboard is public too, because the server is. `auth.token` gates the dashboard _page_, not the MCP scope or the SSE stream. If the inventory is sensitive, authenticate the server — do not rely on the dashboard token alone.
+- On a **public** server, `auth.token` is what keeps the inventory private: it gates the page, the dashboard's MCP endpoint (SSE stream and POSTs included) and the tools. Releases up to 1.8.2 gated only the page, answered MCP with the dashboard disabled, and pointed the page at `<basePath>/sse`.
 
 Three further limitations worth knowing:
 
-- **The bundled page cannot authenticate itself against a non-public server.** The browser client opens `EventSource(sseUrl)` and POSTs with no `Authorization` header, and the SDK reads the credential from that header only. So on a server with `local`/`remote`/`transparent`/`orchestrated` auth the page loads (its own token gates that) but the in-page graph, tool list and SSE stream get `401`. Run the dashboard on a public/development server, or put it behind a proxy that injects a credential — scoped to the dashboard's own routes (`<basePath>/sse` and `<basePath>/message`) and holding no grant beyond the dashboard scope, since injecting a server credential across the MCP endpoint would let any page on that origin issue arbitrary authenticated JSON-RPC. Failing closed here is deliberate — the alternative is the `mode: 'public'` scope that GHSA-rgxj-434m-vxh3 was about.
-- The token is accepted as `Authorization: Bearer <token>` (scheme matched case-insensitively) or `?token=`. Prefer the header: a URL token lands in browser history, `Referer` headers and access logs. There is no cookie/session option yet.
+- **The bundled page cannot authenticate itself against a non-public server.** Its cookie carries the dashboard token only; the browser client opens `EventSource(sseUrl)` and POSTs with no `Authorization` header, and the server's own authentication reads its credential from that header. So on a server with `local`/`remote`/`transparent`/`orchestrated` auth the page loads but the in-page graph, tool list and SSE stream get `401`. Run the dashboard on a public/development server, or put it behind a proxy that injects a credential — scoped to the dashboard's own MCP routes (`/dashboard/sse` and `/dashboard/message`, after the server's `entryPath`) and holding no grant beyond the dashboard scope, since injecting a server credential across the MCP endpoint would let any page on that origin issue arbitrary authenticated JSON-RPC. Failing closed here is deliberate — the alternative is the `mode: 'public'` scope that GHSA-rgxj-434m-vxh3 was about.
+- The token is accepted as `Authorization: Bearer <token>` (scheme matched case-insensitively), as `x-frontmcp-dashboard-token` on the MCP endpoint, through the page's cookie, and as `?token=` for the page only. Prefer a header: a URL token lands in browser history, `Referer` headers and access logs.
 - Dashboard options are **process-wide**. Two `@FrontMcp` servers built in one process that configure the dashboard with CONFLICTING auth now throw at registration rather than silently sharing the last token; a differing `basePath` or `cdn` logs a warning. Run one dashboard per process, or call `resetDashboardOptions()` between serial constructions.
 
 ---

package/catalog/frontmcp-development/references/openapi-adapter.md

@@ -89,8 +89,9 @@ OpenapiAdapter.init({
   name: 'my-api',
   url: 'https://api.example.com/openapi.json',
   baseUrl: 'https://api.example.com',
-  securityResolver: (tool, ctx) => {
-    return { jwt: ctx.authInfo?.token };
+  securityResolver: async (tool, ctx) => {
+    // A credential issued for the API, never the caller's own ctx.authInfo.token
+    return { jwt: await getApiToken(ctx) };
   },
 });
 
@@ -110,17 +111,33 @@ OpenapiAdapter.init({
   url: 'https://api.example.com/openapi.json',
   baseUrl: 'https://api.example.com',
   headersMapper: (ctx, headers) => {
-    headers.set('Authorization', `Bearer ${ctx.authInfo?.token}`);
+    const tenantId = ctx.authInfo.user?.tenantId;
+    if (tenantId) headers.set('x-tenant-id', tenantId);
     return headers;
   },
 });
+
+// Opt-in token passthrough (High Risk) — only when the API accepts tokens issued for this MCP server
+OpenapiAdapter.init({
+  name: 'same-issuer-api',
+  url: 'https://api.example.com/openapi.json',
+  baseUrl: 'https://api.example.com',
+  passthroughCallerToken: true,
+});
 ```
 
+With no `authProviderMapper`, `securityResolver` or `staticAuth`, the adapter sends **no** credentials: operations that require auth fail with `Authentication required for tool '…'` and a `SECURITY WARNING` is logged at startup. The caller's MCP token (`ctx.authInfo.token`) is never forwarded implicitly — not by default, and not when an `authProviderMapper` function returns `undefined` — because passing it to another API is token passthrough, which the MCP specification forbids. `passthroughCallerToken: true` is the explicit opt-in, used only after every other credential source came up empty.
+
 | Risk Level | Strategy                                   | Description                                          |
 | ---------- | ------------------------------------------ | ---------------------------------------------------- |
 | LOW        | `authProviderMapper` or `securityResolver` | Auth from user context, not exposed to clients       |
-| MEDIUM     | `staticAuth`, `additionalHeaders`          | Static credentials                                   |
+| MEDIUM     | `staticAuth`, `additionalHeaders`, or none | Static credentials, or no credentials at all         |
 | HIGH       | `includeSecurityInInput: true`             | Auth fields exposed to MCP clients (not recommended) |
+| HIGH       | `passthroughCallerToken: true`             | The MCP client's own token is sent to the API        |
+
+`passthroughCallerToken: true` scores HIGH alongside an `authProviderMapper` too (the token is sent when no mapper function returns a credential); only a `securityResolver` or a non-empty `staticAuth` leaves it unused.
+
+Resolution order: `securityResolver` → `authProviderMapper` → `staticAuth` (fills every credential no mapper function returned; a mapped value wins) → `passthroughCallerToken`. A security scheme with no `authProviderMapper` entry is refused at startup unless `staticAuth` or `passthroughCallerToken` covers it (the latter sends the caller's token for it and logs a `SECURITY WARNING`).
 
 ## Spec Polling
 

package/catalog/frontmcp-production-readiness/references/common-checklist.md

@@ -19,7 +19,8 @@ These checks apply to ALL deployment targets. Run them first, then proceed to yo
 - [ ] Tool-level authorization is enforced where needed (ApprovalPlugin or custom)
 - [ ] OAuth redirect URIs are restricted to known domains
 - [ ] `FRONTMCP_PUBLIC_URL` is pinned to the canonical origin — issuer / resource / OAuth-discovery URLs and the transparent-mode expected audience derive from it, not from request headers. `X-Forwarded-Host`/`X-Forwarded-Proto` are ignored by default; only set `FRONTMCP_TRUST_PROXY=1` behind a proxy that strips client-supplied forwarded headers
-- [ ] `auth.requireRegisteredClients: true` (local/remote) so unknown clients can't present an attacker-chosen `redirect_uri` (auth-code interception). Clients register via DCR / `dcr.clients` / CIMD
+- [ ] `auth.requireRegisteredClients` left at its default `true` (local/remote) so unknown clients can't present an attacker-chosen `redirect_uri` (auth-code interception). Clients register via DCR / `dcr.clients` / CIMD; a production remote-mode server has neither DCR nor `dcr.clients`, so its MCP clients must use CIMD
+- [ ] `auth.allowedScopes` lists the scopes the server may grant (local/remote); anything else a client asks for is dropped
 - [ ] Transparent mode sets `auth.expectedAudience` (bind tokens to this resource) and validates issuer (`providerConfig.verifyIssuer`, default on)
 
 ### CORS Configuration

package/catalog/skills-manifest.json

@@ -74,7 +74,7 @@
         },
         {
           "name": "ui-widgets",
-          "description": "@Tool({ ui }) \u2014 template formats, servingMode, host-detect resourceMode, CSP, widgetAccessible, MCP Apps spec."
+          "description": "@Tool({ ui }) \u2014 template formats, trusted markup (html / escapeStringResults), servingMode, host-detect resourceMode, CSP, widgetAccessible, MCP Apps spec."
         },
         {
           "name": "annotations",
@@ -337,11 +337,12 @@
           "name": "22-tool-with-ui-html-template",
           "level": "intermediate",
           "description": "Tool with an inline HTML function template \u2014 `ui: { template: (ctx) => '<div>\u2026</div>' }` \u2014 for a quick widget that doesn't need a separate `.tsx` file.",
-          "tags": ["ui", "ui-widgets", "html-template", "escapeHtml", "TemplateContext"],
+          "tags": ["ui", "ui-widgets", "html-template", "html-tag", "escapeStringResults", "TemplateContext"],
           "features": [
-            "Adding a `ui:` block with a function template `(ctx: TemplateContext<In, Out>) => string`",
+            "Adding a `ui:` block with a function template that returns markup built with the `ctx.helpers.html` tagged template",
             "Annotating `ctx` explicitly to dodge the TS7006 inference gap on the union `ui.template` type",
-            "Always escaping user-controlled output with `ctx.helpers.escapeHtml(...)` so the widget can't XSS itself",
+            "Letting `ctx.helpers.html` escape every interpolated value so tool output can't inject markup into the widget",
+            "Opting in to `escapeStringResults: true` so a plain string result is escaped \u2014 the default from FrontMCP 1.9",
             "Reading from `ctx.output` and `ctx.helpers` \u2014 the typed runtime context the template renderer hands you"
           ]
         },
@@ -365,7 +366,7 @@
           "features": [
             "Restricting the widget's outbound `fetch` via `ui.csp.connectDomains` (emitted on the resource per #455)",
             "Opting the widget into cross-tool calls with `widgetAccessible: true` and using `window.FrontMcpBridge.callTool(name, args)` instead of host-specific APIs",
-            "Embedding initial data into the widget's inline `<script>` safely via `ctx.helpers.jsonEmbed(...)` (escapes `<`, `>` and `&`)",
+            "Building the markup with `ctx.helpers.html` and embedding initial data into the inline `<script>` via `trustedHtml(jsonEmbed(...))` (`jsonEmbed` escapes `<`, `>` and `&`)",
             "Surfacing in-flight status via `invocationStatus.invoking` / `invoked` so the host UI shows feedback"
           ]
         },
@@ -1069,6 +1070,7 @@
                 "Top-level `instructions` on `@FrontMcp` exposes a global system prompt to MCP clients",
                 "`skillsConfig.injectInstructions: 'append'` adds the skill catalog summary after the user prompt",
                 "Dynamic skills are picked up because the composer runs on every initialize request",
+                "The catalog only names skills the initializing caller may see (skill authorities and the `skills:filter` flow, e.g. feature flags)",
                 "Catalog summary is bounded at 16 KB with a truncation footer pointing at skill://index.json"
               ]
             },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@frontmcp/skills",
-  "version": "1.8.1",
+  "version": "1.8.3",
   "description": "Curated skills catalog for FrontMCP projects",
   "author": "AgentFront <info@agentfront.dev>",
   "homepage": "https://docs.agentfront.dev",