@frontmcp/skills 1.8.0 → 1.8.2

package/catalog/frontmcp-development/references/decorators-guide.md

@@ -85,6 +85,7 @@ FrontMCP uses a hierarchical decorator system. The nesting order is:
 | `jobs?`         | Background jobs/workflows system (`{ enabled, store? }`)                                                                                                                     |
 | `throttle?`     | Server-level guard config (see note below)                                                                                                                                   |
 | `pagination?`   | List operation pagination (`tools/list` endpoint)                                                                                                                            |
+| `fetch?`        | What `this.fetch()` adds upstream: `forwardCallerTokenTo` / `forwardCustomHeadersTo` origin allow-lists (default: none), `autoInjectTracingHeaders`, `requestTimeout`        |
 | `ui?`           | UI rendering config (CDN overrides for widget imports)                                                                                                                       |
 | `extApps?`      | Widget-to-host MCP Apps communication (host capabilities, session validation)                                                                                                |
 | `loader?`       | Default npm/ESM package loader for `App.esm()` / `App.remote()` apps                                                                                                         |
@@ -765,14 +766,14 @@ class AuditHooks {
 
 ## Troubleshooting
 
-| Problem                                            | Cause                                                                                                 | Solution                                                                                                                            |
-| -------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
-| Tool does not appear in `tools/list` MCP response  | Tool class is not registered in any `@App({ tools: [...] })` or `@FrontMcp({ tools: [...] })`         | Add the tool class to the `tools` array of the appropriate `@App` or `@FrontMcp` decorator                                          |
-| `this.get(Token)` throws `DependencyNotFoundError` | The provider for that token is not registered or is registered in a different app scope               | Add a `@Provider` for the token in the same `@App` or in `@FrontMcp({ providers: [...] })` for global access                        |
-| Resource returns 404 / `ResourceNotFoundError`     | The `uri` in `@Resource` does not match the requested URI, or `uriTemplate` parameters are misaligned | Verify the URI string exactly matches what the client requests; for templates, confirm `{param}` names match                        |
-| Hook never fires                                   | The `flow` string in `@Will`/`@Did`/`@Around`/`@Stage` does not match any registered flow             | Check the flow string against valid flows (e.g., `tools:call-tool`, `resources:read-resource`, `resources:list-resources`)          |
-| Plugin context extension is `undefined` at runtime | The plugin's `installContextExtension` function was not called, or module augmentation is missing     | Ensure the plugin is registered and its context extension function runs at startup; verify the `declare module` augmentation exists |
-| Agent `execute()` returns empty result             | LLM configuration is missing or invalid (wrong model name, missing API key)                           | Verify `llm.model` and `llm.provider` in `@Agent`, and ensure the provider API key is set in environment variables                  |
+| Problem                                              | Cause                                                                                                 | Solution                                                                                                                            |
+| ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
+| Tool does not appear in `tools/list` MCP response    | Tool class is not registered in any `@App({ tools: [...] })` or `@FrontMcp({ tools: [...] })`         | Add the tool class to the `tools` array of the appropriate `@App` or `@FrontMcp` decorator                                          |
+| `this.get(Token)` throws `ProviderNotAvailableError` | The provider for that token is not registered or is registered in a different app scope               | Add a `@Provider` for the token in the same `@App` or in `@FrontMcp({ providers: [...] })` for global access                        |
+| Resource returns 404 / `ResourceNotFoundError`       | The `uri` in `@Resource` does not match the requested URI, or `uriTemplate` parameters are misaligned | Verify the URI string exactly matches what the client requests; for templates, confirm `{param}` names match                        |
+| Hook never fires                                     | The `flow` string in `@Will`/`@Did`/`@Around`/`@Stage` does not match any registered flow             | Check the flow string against valid flows (e.g., `tools:call-tool`, `resources:read-resource`, `resources:list-resources`)          |
+| Plugin context extension is `undefined` at runtime   | The plugin's `installContextExtension` function was not called, or module augmentation is missing     | Ensure the plugin is registered and its context extension function runs at startup; verify the `declare module` augmentation exists |
+| Agent `execute()` returns empty result               | LLM configuration is missing or invalid (wrong model name, missing API key)                           | Verify `llm.model` and `llm.provider` in `@Agent`, and ensure the provider API key is set in environment variables                  |
 
 ---
 

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

@@ -153,6 +153,28 @@ class MyTool extends ToolContext {
 }
 ```
 
+### Tool Access Policy
+
+One policy decides every CodeCall surface: `codecall:search`, `codecall:describe`, `callTool`/`getTool` and the namespace bindings in `codecall:execute`, and `codecall:invoke`. A withheld tool is not indexed, is reported in describe's `notFound`, and is refused at execution.
+
+```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:'),
+  directCalls: {
+    enabled: true,
+    allowedTools: ['users:list', 'crm:users:get'], // bare name, or `<appId>:<name>` to pin one app
+  },
+});
+```
+
+- Always withheld: `enabledInCodeCall: false` tools, hidden tools (`visibility: 'hidden'` / `hideFromDiscovery`), `visibility: 'internal'` tools, `codecall:*`, and any tool whose name, qualified name or requested spelling starts with `system:`, `internal:` or `__`.
+- `tool.appId` names the owning app for the tools its adapters and plugins provide too, so `includeTools: (tool) => tool.appId !== 'admin'` withholds every tool of app `admin`.
+- `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.
+
 ### Power Features
 
 - **TF-IDF Search** -- Term frequency-inverse document frequency scoring indexes tool names, descriptions, and tags. No external embedding service required.
@@ -271,7 +293,9 @@ user. If the data really is shared, use `scope: 'global'`.
 `tool` included, derive their encryption key from that secret plus the scope identity. A
 session id is not a secret -- the client knows it and it travels in the `mcp-session-id`
 header -- so it cannot be the key material on its own. Instances with different secrets cannot
-read each other's entries.
+read each other's entries. With none of `REMEMBER_SECRET`, `MCP_MEMORY_SECRET` or
+`MCP_SESSION_SECRET` set in production, the plugin falls back to a random in-memory secret and
+logs a warning once; its encrypted memory is then lost on restart.
 
 **Upgrading past that change moves existing `session`, `tool` and `user` entries.** The key
 derivation change orphans `session` and `tool` ciphertext, and the namespace now percent-encodes
@@ -353,6 +377,11 @@ class AuditedServer {}
 class WebhookServer {}
 ```
 
+**`ApprovalPlugin.init()` registers the approval check itself.** Do not add `ApprovalCheckPlugin`
+to `plugins`; listing it as well is harmless and the check still runs once per call. Require
+1.8.1 or later: in 1.8.0 and earlier `ApprovalPlugin.init()` registered no check at all, so
+tools marked `approval` ran unapproved.
+
 ### Modes
 
 - `recheck` -- Re-evaluates approval status on every tool call. Approval can be granted programmatically via `this.approval.grantSessionApproval()`. Good for interactive approval flows where the user confirms in-band.
@@ -373,6 +402,39 @@ name the context that lets it skip the gate. Set the context when you authentica
 authInfo.extra.approvalContext = { type: 'project', identifier: resolvedProjectId };
 ```
 
+### 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.
+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.
+6. Otherwise refused with state `pending` (or `expired`).
+
+A refused call throws `ApprovalRequiredError`; the client receives an error result.
+
+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 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 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.
+`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
 
 ```typescript
@@ -405,11 +467,13 @@ class DangerousActionTool extends ToolContext {
 ### Per-Tool Approval Metadata
 
 ```typescript
+import { ApprovalScope } from '@frontmcp/plugin-approval';
+
 @Tool({
   name: 'file_write',
   approval: {
     required: true,
-    defaultScope: 'session', // 'session' | 'user' | 'time-limited'
+    defaultScope: ApprovalScope.SESSION, // SESSION | USER | TIME_LIMITED | TOOL_SPECIFIC | CONTEXT_SPECIFIC
     category: 'write',
     riskLevel: 'medium', // 'low' | 'medium' | 'high' | 'critical'
     approvalMessage: 'Allow file writing for this session?',
@@ -435,9 +499,13 @@ asking -- a profile, a balance, a tenant's records, anything filtered by the cal
 permissions -- and a key built only from the tool and its arguments serves the first caller's
 response to everyone else.
 
-The identity is the authenticated subject (`sub` / `userId`), then the client id, then the
-session. A call with no identity at all gets a key of its own rather than one shared with
-every other identity-less caller.
+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. 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.
@@ -688,7 +756,21 @@ class ExperimentalTool extends ToolContext {
 }
 ```
 
-The plugin hooks into listing and execution flows for tools, resources, prompts, and skills. When a flag evaluates to `false`, the corresponding entry is filtered from list results and direct invocation returns an error.
+The plugin hooks into listing and execution flows for tools, resources, resource templates, prompts, and skills. When a flag evaluates to `false`, the corresponding entry is filtered from list results and direct access is refused:
+
+| Capability        | Hidden from                                                                                                                                                                                                    | Refused on                                                                                                      |
+| ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
+| 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) |
+
+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 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.
 
 ---
 

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

@@ -318,7 +318,8 @@ FrontMCP's secure defaults:
 
 The rules above cover _loading the spec_. **Calling** a generated tool is a different fetch,
 and it never follows redirects either (**GHSA-qh67-4345-cw2q**): the adapter sets
-`redirect: 'manual'` and refuses any 3xx with `OPENAPI_REDIRECT_NOT_FOLLOWED`.
+`redirect: 'manual'` and refuses any 3xx -- and the status-0 `opaqueredirect` response browser
+runtimes return instead -- with `OPENAPI_REDIRECT_NOT_FOLLOWED`.
 
 Following one would send the request to a destination the _upstream_ chose. Only `baseUrl` is
 validated, and only for its scheme, so a 3xx is an unvalidated hop -- including to an internal

package/catalog/frontmcp-observability/references/metrics-endpoint.md

@@ -27,7 +27,7 @@ import { FrontMcp } from '@frontmcp/sdk';
 class Server {}
 ```
 
-Then scrape: `curl http://localhost:3001/metrics` — Content-Type is the canonical Prometheus `text/plain; version=0.0.4; charset=utf-8`.
+Then scrape: `curl http://localhost:3000/metrics` (the default port is `PORT`, else 3000) — Content-Type is the canonical Prometheus `text/plain; version=0.0.4; charset=utf-8`.
 
 ## Configuration
 

package/catalog/frontmcp-observability/references/structured-logging.md

@@ -99,6 +99,41 @@ logging: {
 
 Redaction is recursive (handles nested objects) and case-insensitive.
 
+## CodeCall Audit Events
+
+If `CodeCallPlugin` is installed, it emits a structured audit event at every meaningful point in a
+script execution. The plugin registers the bridge itself, so the events reach your normal log
+output at `info` under the `codecall:audit` prefix with no wiring.
+
+Event families, all carrying `executionId` for correlation:
+
+- `codecall:execution:start` / `:success` / `:failure` / `:timeout`
+- `codecall:tool:call:start` / `:success` / `:failure`
+- `codecall:security:self-reference` / `:access-denied` / `:ast-blocked`
+- `codecall:search:performed` / `codecall:describe:performed` / `codecall:invoke:performed`
+
+No event carries script source, tool arguments, tool results, or query text — a script is reduced
+to `scriptHash` + `scriptLength`, a query to `queryLength`. Do not add those fields when building
+on this; the omission is what makes the events safe to emit at `info`.
+
+To route events elsewhere, subscribe rather than parsing logs:
+
+```typescript
+import { AUDIT_EVENT_TYPES, AuditLoggerService, type AuditEvent } from '@frontmcp/plugin-codecall';
+
+const audit = scope.providers.get(AuditLoggerService);
+const unsubscribe = audit.subscribe((event: AuditEvent) => myShipper.send(event));
+```
+
+Fan-out is synchronous and on the execution hot path — hand off to a queue, never do network I/O
+inside the listener. Note the file transport writes only the message, so structured fields are
+dropped there; use the structured transport or subscribe directly.
+
+**Over stdio:** stdout carries the MCP JSON-RPC frames, so nothing else may be written there.
+`runStdio()` redirects the stdout-bound `console` methods to stderr, and the NDJSON `stdout` sink
+defaults to stderr when `FRONTMCP_STDIO` is set. Never configure a sink with an explicit
+`stream: process.stdout` on a stdio server — an explicit stream overrides the guard.
+
 ## Examples
 
 | Example                                                                        | Level        | Description                                                                                                                    |

package/catalog/frontmcp-testing/examples/test-e2e-handler/tool-call-and-error-e2e.md

@@ -8,6 +8,7 @@ features:
   - 'Calling tools via `client.tools.call(name, args)` and asserting success with `toBeSuccessful()`'
   - 'Asserting text content with the `toHaveTextContent()` matcher'
   - 'Asserting error results with `toBeError()` for invalid input and unknown tools'
+  - 'Matching the tool error code: invalid input is an `isError` result with `_meta.code: "INVALID_INPUT"`, so `toBeError(''INVALID_INPUT'')` matches it (a numeric code matches JSON-RPC errors only)'
   - 'Testing edge cases like zero values'
 ---
 
@@ -53,7 +54,7 @@ describe('Tool Call E2E', () => {
 
   it('returns an error for invalid input', async () => {
     const result = await client.tools.call('add_numbers', { a: 'bad' });
-    expect(result).toBeError();
+    expect(result).toBeError('INVALID_INPUT');
   });
 
   it('returns an error for a nonexistent tool', async () => {
@@ -74,6 +75,7 @@ describe('Tool Call E2E', () => {
 - Calling tools via `client.tools.call(name, args)` and asserting success with `toBeSuccessful()`
 - Asserting text content with the `toHaveTextContent()` matcher
 - Asserting error results with `toBeError()` for invalid input and unknown tools
+- Matching the tool error code: invalid input is an `isError` result with `_meta.code: "INVALID_INPUT"`, so `toBeError('INVALID_INPUT')` matches it (a numeric code matches JSON-RPC errors only)
 - Testing edge cases like zero values
 
 ## Related

package/catalog/frontmcp-testing/references/setup-testing.md

@@ -421,15 +421,15 @@ A nested `test.describe` inherits an outer skip. The `(name, fn)` form still ski
 import { expect } from '@frontmcp/testing';
 ```
 
-| Matcher                   | Asserts                                               |
-| ------------------------- | ----------------------------------------------------- |
-| `toContainTool(name)`     | Tools list includes a tool with the given name        |
-| `toContainResource(uri)`  | Resources list includes a resource with the given URI |
-| `toContainPrompt(name)`   | Prompts list includes a prompt with the given name    |
-| `toBeSuccessful()`        | Tool call result is not an error                      |
-| `toBeError()`             | Tool call result is an MCP error                      |
-| `toHaveTextContent(text)` | Result contains text content matching the string      |
-| `toHaveMimeType(mime)`    | Resource content has the expected MIME type           |
+| Matcher                   | Asserts                                                                                                            |
+| ------------------------- | ------------------------------------------------------------------------------------------------------------------ |
+| `toContainTool(name)`     | Tools list includes a tool with the given name                                                                     |
+| `toContainResource(uri)`  | Resources list includes a resource with the given URI                                                              |
+| `toContainPrompt(name)`   | Prompts list includes a prompt with the given name                                                                 |
+| `toBeSuccessful()`        | Tool call result is not an error                                                                                   |
+| `toBeError(code?)`        | Result is an error; a string code matches `_meta.code` (`'INVALID_INPUT'`), a number matches a JSON-RPC error code |
+| `toHaveTextContent(text)` | Result contains text content matching the string                                                                   |
+| `toHaveMimeType(mime)`    | Resource content has the expected MIME type                                                                        |
 
 ## Running Tests with Nx
 

package/catalog/frontmcp-testing/references/test-e2e-handler.md

@@ -67,6 +67,41 @@ describe('Server E2E', () => {
 });
 ```
 
+## Error Codes
+
+Errors raised while a tool runs, including invalid input, come back as a tool result with `isError: true` and a string `_meta.code`, not as a JSON-RPC error. Match them with the string form, and keep the numeric form for JSON-RPC errors:
+
+```typescript
+expect(await client.tools.call('add_numbers', { a: 5 })).toBeError('INVALID_INPUT');
+expect(await client.tools.call('nonexistent_tool', {})).toBeError('TOOL_NOT_FOUND');
+expect(await client.prompts.get('nonexistent_prompt')).toBeError(-32602);
+```
+
+A tool without an `outputSchema` that returns a plain number sends `{ value: 8 }`, so assert `expect(result.json()).toEqual({ value: 8 })`.
+
+## Notifications and Progress
+
+After `initialize`, `McpTestClient` opens the session's notification stream (a `GET` on the MCP endpoint) and records what the server sends there and on each request's own response:
+
+```typescript
+it('records progress and log messages', async () => {
+  const progress = client.notifications.collectProgress(); // tools.call now sends a _meta.progressToken
+  const notifications = client.notifications.collect();
+  await client.raw.request({ jsonrpc: '2.0', id: 1, method: 'logging/setLevel', params: { level: 'info' } });
+
+  await client.tools.call('import_files', {});
+
+  await progress.waitForComplete(5000);
+  expect(progress.all.length).toBeGreaterThan(0);
+  await notifications.waitFor('notifications/message', 5000);
+});
+```
+
+- Pass `{ progressToken }` as the third argument of `tools.call()` to choose the token yourself.
+- The server sends `notifications/message` (from `this.notify()`) only after `logging/setLevel`.
+- Session-stream notifications can arrive after the call's result, so wait with `waitFor()` / `waitForComplete()` before asserting.
+- `McpTestClient` speaks `2025-06-18` by default. `2026-07-28` has no `initialize` handshake, so `withProtocolVersion('2026-07-28')` makes `build()` throw.
+
 ## Examples
 
 | Example                                                                                        | Level        | Description                                                                                                          |

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 `</script>`)",
+            "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,7 +1070,8 @@
                 "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",
-                "Catalog summary is bounded at 16 KB with a truncation footer pointing at skill://catalog"
+                "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"
               ]
             },
             {
@@ -3449,6 +3451,7 @@
                 "Calling tools via `client.tools.call(name, args)` and asserting success with `toBeSuccessful()`",
                 "Asserting text content with the `toHaveTextContent()` matcher",
                 "Asserting error results with `toBeError()` for invalid input and unknown tools",
+                "Matching the tool error code: invalid input is an `isError` result with `_meta.code: \"INVALID_INPUT\"`, so `toBeError('INVALID_INPUT')` matches it (a numeric code matches JSON-RPC errors only)",
                 "Testing edge cases like zero values"
               ]
             }

package/package.json

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