@frontmcp/skills 1.1.2 → 1.2.0

package/catalog/frontmcp-development/examples/create-agent/nested-agents-with-swarm.md

@@ -2,18 +2,23 @@
 name: nested-agents-with-swarm
 reference: create-agent
 level: advanced
-description: 'Composing specialized sub-agents and configuring swarm-based handoff between agents.'
-tags: [development, agent, nested, agents, swarm]
+description: Composing specialized agents into a swarm where an orchestrator can discover and call peers at runtime as `use-agent:<id>` tools. Routing is driven by the orchestrator's LLM, not a declarative handoff table.
+tags:
+  - development
+  - agent
+  - nested
+  - agents
+  - swarm
 features:
-  - "Configuring `swarm` with `role: 'coordinator'` for the triage agent and `role: 'specialist'` for domain agents"
-  - 'Defining `handoff` rules with `agent` name and `condition` for declarative LLM-driven routing'
-  - 'Specialist agents can hand back to the triage agent when a request falls outside their scope'
-  - 'Each agent has its own `llm` config, `tools`, and `systemInstructions` for specialization'
+  - 'Setting `swarm: { canSeeOtherAgents: true, visibleAgents: [...] }` on the orchestrator so peers appear as `use-agent:*` tools'
+  - 'Setting `swarm: { isVisible: true }` (the default) on specialist peers so they can be called'
+  - Routing is driven by the orchestrator LLM choosing among `use-agent:<peer>` tools, not by a declarative handoff table
+  - Each agent has its own `llm` config, `tools`, and `systemInstructions` for specialization
 ---
 
-# Nested Sub-Agents and Swarm Handoff
+# Multi-Agent Swarm Visibility
 
-Composing specialized sub-agents and configuring swarm-based handoff between agents.
+Composing specialized agents into a swarm where an orchestrator can discover and call peers at runtime as `use-agent:<id>` tools. Routing is driven by the orchestrator's LLM, not a declarative handoff table.
 
 ## Code
 
@@ -33,14 +38,13 @@ class LookupInvoiceTool extends ToolContext {
 }
 
 @Agent({
+  id: 'billing_agent',
   name: 'billing_agent',
   description: 'Handles billing and payment inquiries',
   llm: { provider: 'anthropic', model: 'claude-sonnet-4-20250514', apiKey: { env: 'ANTHROPIC_API_KEY' } },
   tools: [LookupInvoiceTool],
-  swarm: {
-    role: 'specialist',
-    handoff: [{ agent: 'triage_agent', condition: 'Request is outside billing scope' }],
-  },
+  // isVisible defaults to true; specialists do not need swarm config to be callable.
+  swarm: { isVisible: true },
 })
 class BillingAgent extends AgentContext {}
 ```
@@ -50,14 +54,12 @@ class BillingAgent extends AgentContext {}
 import { Agent, AgentContext } from '@frontmcp/sdk';
 
 @Agent({
+  id: 'technical_agent',
   name: 'technical_agent',
   description: 'Handles technical support issues',
   llm: { provider: 'anthropic', model: 'claude-sonnet-4-20250514', apiKey: { env: 'ANTHROPIC_API_KEY' } },
   systemInstructions: 'You are a technical support specialist. Diagnose issues and provide solutions.',
-  swarm: {
-    role: 'specialist',
-    handoff: [{ agent: 'triage_agent', condition: 'Request is outside technical scope' }],
-  },
+  swarm: { isVisible: true },
 })
 class TechnicalAgent extends AgentContext {}
 ```
@@ -67,20 +69,21 @@ class TechnicalAgent extends AgentContext {}
 import { Agent, AgentContext, z } from '@frontmcp/sdk';
 
 @Agent({
+  id: 'triage_agent',
   name: 'triage_agent',
-  description: 'Triages incoming requests and hands off to specialists',
+  description: 'Triages incoming requests and delegates to specialists',
   llm: { provider: 'anthropic', model: 'claude-sonnet-4-20250514', apiKey: { env: 'ANTHROPIC_API_KEY' } },
   inputSchema: {
     request: z.string().describe('The incoming user request'),
   },
+  // Orchestrator: opts in to seeing peers and (optionally) restricts to a whitelist.
   swarm: {
-    role: 'coordinator',
-    handoff: [
-      { agent: 'billing_agent', condition: 'Request is about billing or payments' },
-      { agent: 'technical_agent', condition: 'Request is about technical issues' },
-    ],
+    canSeeOtherAgents: true,
+    visibleAgents: ['billing_agent', 'technical_agent'],
+    maxCallDepth: 3,
   },
-  systemInstructions: 'Analyze the request and hand off to the appropriate specialist agent.',
+  systemInstructions:
+    'Analyze the request and delegate by calling either use-agent:billing_agent (for billing/payments) or use-agent:technical_agent (for technical issues).',
 })
 class TriageAgent extends AgentContext {}
 ```
@@ -98,12 +101,12 @@ class SupportApp {}
 
 ## What This Demonstrates
 
-- Configuring `swarm` with `role: 'coordinator'` for the triage agent and `role: 'specialist'` for domain agents
-- Defining `handoff` rules with `agent` name and `condition` for declarative LLM-driven routing
-- Specialist agents can hand back to the triage agent when a request falls outside their scope
+- Setting `swarm: { canSeeOtherAgents: true, visibleAgents: [...] }` on the orchestrator so peers appear as `use-agent:*` tools
+- Setting `swarm: { isVisible: true }` (the default) on specialist peers so they can be called
+- Routing is driven by the orchestrator LLM choosing among `use-agent:<peer>` tools, not by a declarative handoff table
 - Each agent has its own `llm` config, `tools`, and `systemInstructions` for specialization
 
 ## Related
 
-- See `create-agent` for exported tools, function-style builder, providers, and rate limiting
+- See `create-agent` for the full swarm field reference and inner-tool composition
 - See `create-agent-llm-config` for using different LLM providers per agent

package/catalog/frontmcp-development/examples/create-job/job-with-permissions.md

@@ -5,7 +5,7 @@ level: advanced
 description: 'A data export job with declarative permission controls, plus a function-style job for simple tasks.'
 tags: [development, redis, job, permissions]
 features:
-  - 'Declarative `permissions` with `actions`, `roles`, `scopes`, and a custom `predicate`'
+  - 'Declarative `permissions` as an array of `{ action, roles, scopes, custom }` rules'
   - 'Using `tags` and `labels` for categorization and filtering'
   - 'The `job()` function builder for simple jobs that need no class'
   - 'Full server registration with `jobs.enabled: true` and a Redis store'
@@ -34,12 +34,17 @@ import { Job, job, JobContext, z } from '@frontmcp/sdk';
   },
   tags: ['export', 'data'],
   labels: { team: 'data-engineering', priority: 'high' },
-  permissions: {
-    actions: ['create', 'read', 'execute', 'list'],
-    roles: ['admin', 'data-engineer'],
-    scopes: ['jobs:write', 'data:export'],
-    predicate: (ctx) => ctx.user?.department === 'engineering',
-  },
+  permissions: [
+    {
+      action: 'execute',
+      roles: ['admin', 'data-engineer'],
+      scopes: ['jobs:write', 'data:export'],
+      custom: (authInfo) => (authInfo as { department?: string }).department === 'engineering',
+    },
+    { action: 'create', roles: ['admin', 'data-engineer'] },
+    { action: 'read', roles: ['admin', 'data-engineer', 'auditor'] },
+    { action: 'list', roles: ['admin', 'data-engineer', 'auditor'] },
+  ],
 })
 class DataExportJob extends JobContext {
   async execute(input: { dataset: string; destination: string }) {
@@ -106,7 +111,7 @@ class DataServer {}
 
 ## What This Demonstrates
 
-- Declarative `permissions` with `actions`, `roles`, `scopes`, and a custom `predicate`
+- Declarative `permissions` as an array of `{ action, roles, scopes, custom }` rules
 - Using `tags` and `labels` for categorization and filtering
 - The `job()` function builder for simple jobs that need no class
 - Full server registration with `jobs.enabled: true` and a Redis store

package/catalog/frontmcp-development/examples/create-provider/basic-database-provider.md

@@ -2,18 +2,18 @@
 name: basic-database-provider
 reference: create-provider
 level: basic
-description: 'A provider that manages a database connection pool with `onInit()` and `onDestroy()` lifecycle hooks.'
+description: A provider that manages a database connection pool, bound through `AsyncProvider({ useFactory })` so the pool is opened before any tool runs.
 tags: [development, database, provider]
 features:
   - 'Defining a typed token with `Token<T>` using a `Symbol` for DI identification'
-  - 'Using `@Provider` decorator with `onInit()` for async startup and `onDestroy()` for cleanup'
+  - 'Using `AsyncProvider({ provide, name, scope, useFactory })` so async setup completes before tool execution'
   - 'Consuming the provider in a tool via `this.get(DB_TOKEN)` with full type safety'
-  - 'Registering the provider in the `providers` array so tools can resolve it'
+  - 'Registering the factory in the `providers` array so tools can resolve it'
 ---
 
-# Basic Database Provider with Lifecycle
+# Basic Database Provider with Async Setup
 
-A provider that manages a database connection pool with `onInit()` and `onDestroy()` lifecycle hooks.
+A provider that manages a database connection pool, bound through `AsyncProvider({ useFactory })` so the pool is opened before any tool runs.
 
 ## Code
 
@@ -31,20 +31,14 @@ export const DB_TOKEN: Token<DatabaseService> = Symbol('DatabaseService');
 
 ```typescript
 // src/apps/main/providers/database.provider.ts
-import { createPool, Pool } from 'your-db-driver';
+import { createPool, type Pool } from 'your-db-driver';
 
-import { Provider } from '@frontmcp/sdk';
+import { AsyncProvider, ProviderScope } from '@frontmcp/sdk';
 
-@Provider({ name: 'DatabaseProvider' })
-class DatabaseProvider implements DatabaseService {
-  private pool!: Pool;
+import { DB_TOKEN, type DatabaseService } from '../tokens';
 
-  async onInit() {
-    this.pool = await createPool({
-      connectionString: process.env.DATABASE_URL,
-      max: 20,
-    });
-  }
+class DatabasePool implements DatabaseService {
+  constructor(private readonly pool: Pool) {}
 
   async query(sql: string, params?: unknown[]) {
     return this.pool.query(sql, params);
@@ -53,11 +47,24 @@ class DatabaseProvider implements DatabaseService {
   async close() {
     await this.pool.end();
   }
-
-  async onDestroy() {
-    await this.pool.end();
-  }
 }
+
+// `@Provider` does NOT support `onInit`/`onDestroy` lifecycle hooks. For async
+// setup, register the dependency via `AsyncProvider({ useFactory })` — the
+// framework awaits `useFactory` before any tool can resolve the token.
+export const databaseProvider = AsyncProvider({
+  provide: DB_TOKEN,
+  name: 'DatabaseProvider',
+  scope: ProviderScope.GLOBAL,
+  inject: () => [] as const,
+  useFactory: async (): Promise<DatabaseService> => {
+    const pool = await createPool({
+      connectionString: process.env.DATABASE_URL,
+      max: 20,
+    });
+    return new DatabasePool(pool);
+  },
+});
 ```
 
 ```typescript
@@ -93,9 +100,12 @@ class QueryUsersTool extends ToolContext {
 // src/apps/main/index.ts
 import { App } from '@frontmcp/sdk';
 
+import { databaseProvider } from './providers/database.provider';
+import QueryUsersTool from './tools/query-users.tool';
+
 @App({
   name: 'main',
-  providers: [DatabaseProvider],
+  providers: [databaseProvider],
   tools: [QueryUsersTool],
 })
 class MainApp {}
@@ -104,9 +114,9 @@ class MainApp {}
 ## What This Demonstrates
 
 - Defining a typed token with `Token<T>` using a `Symbol` for DI identification
-- Using `@Provider` decorator with `onInit()` for async startup and `onDestroy()` for cleanup
+- Using `AsyncProvider({ provide, name, scope, useFactory })` so async setup completes before tool execution
 - Consuming the provider in a tool via `this.get(DB_TOKEN)` with full type safety
-- Registering the provider in the `providers` array so tools can resolve it
+- Registering the factory in the `providers` array so tools can resolve it
 
 ## Related
 

package/catalog/frontmcp-development/examples/create-provider/config-and-api-providers.md

@@ -5,8 +5,8 @@ level: intermediate
 description: 'A configuration provider with readonly environment settings and an HTTP API client provider.'
 tags: [development, provider, config, api, providers]
 features:
-  - 'A configuration provider using `readonly` properties from environment variables (no lifecycle needed)'
-  - 'An API client provider using `onInit()` for async setup of credentials'
+  - 'A configuration provider using `readonly` properties from environment variables (sync construction)'
+  - 'An API client provider that reads credentials in the constructor (no `onInit` — `@Provider` has no lifecycle hooks)'
   - 'Registering providers at `@FrontMcp` level for server-wide sharing across all apps'
   - 'Separating token definitions from provider implementations for clean dependency boundaries'
 ---
@@ -40,6 +40,7 @@ export const API_TOKEN: Token<ApiClient> = Symbol('ApiClient');
 ```typescript
 // src/apps/main/providers/config.provider.ts
 import { Provider } from '@frontmcp/sdk';
+
 import type { AppConfig } from '../tokens';
 
 @Provider({ name: 'ConfigProvider' })
@@ -53,16 +54,24 @@ class ConfigProvider implements AppConfig {
 ```typescript
 // src/apps/main/providers/api-client.provider.ts
 import { Provider } from '@frontmcp/sdk';
+
 import type { ApiClient } from '../tokens';
 
 @Provider({ name: 'ApiClientProvider' })
 class ApiClientProvider implements ApiClient {
-  private baseUrl!: string;
-  private apiKey!: string;
-
-  async onInit() {
-    this.baseUrl = process.env.API_URL!;
-    this.apiKey = process.env.API_KEY!;
+  // `@Provider` has no `onInit` lifecycle hook — read env in the constructor.
+  // First instantiation throws synchronously on missing config (fail fast).
+  private readonly baseUrl: string;
+  private readonly apiKey: string;
+
+  constructor() {
+    const baseUrl = process.env.API_URL;
+    const apiKey = process.env.API_KEY;
+    if (!baseUrl || !apiKey) {
+      throw new Error('ApiClientProvider: API_URL and API_KEY must be set');
+    }
+    this.baseUrl = baseUrl;
+    this.apiKey = apiKey;
   }
 
   async get(path: string) {
@@ -97,8 +106,8 @@ class MyServer {}
 
 ## What This Demonstrates
 
-- A configuration provider using `readonly` properties from environment variables (no lifecycle needed)
-- An API client provider using `onInit()` for async setup of credentials
+- A configuration provider using `readonly` properties from environment variables (sync construction)
+- An API client provider that reads credentials in the constructor (no `onInit` — `@Provider` has no lifecycle hooks)
 - Registering providers at `@FrontMcp` level for server-wide sharing across all apps
 - Separating token definitions from provider implementations for clean dependency boundaries
 

package/catalog/frontmcp-development/examples/create-tool/tool-with-rate-limiting-and-progress.md

@@ -6,7 +6,7 @@ description: 'A batch processing tool that uses rate limiting, concurrency contr
 tags: [development, throttle, tool, rate, limiting, progress]
 features:
   - 'Configuring `rateLimit`, `concurrency`, and `timeout` for throttling protection'
-  - 'Sending progress updates to the client with `this.respondProgress(value, total)`'
+  - 'Sending progress updates to the client with `this.progress(progress, total, message?)`'
   - 'Using `this.mark(stage)` for execution stage tracking and debugging'
   - 'Sending log-level notifications with `this.notify(message, level)`'
   - 'Setting tool `annotations` to communicate behavioral hints to clients'
@@ -52,7 +52,7 @@ class BatchProcessTool extends ToolContext {
     this.mark('processing');
     const results: string[] = [];
     for (let i = 0; i < input.items.length; i++) {
-      await this.respondProgress(i + 1, input.items.length);
+      await this.progress(i + 1, input.items.length, `Processing item ${i + 1}`);
       const result = await this.processItem(input.items[i]);
       results.push(result);
     }
@@ -82,7 +82,7 @@ class MainApp {}
 ## What This Demonstrates
 
 - Configuring `rateLimit`, `concurrency`, and `timeout` for throttling protection
-- Sending progress updates to the client with `this.respondProgress(value, total)`
+- Sending progress updates to the client with `this.progress(progress, total, message?)`
 - Using `this.mark(stage)` for execution stage tracking and debugging
 - Sending log-level notifications with `this.notify(message, level)`
 - Setting tool `annotations` to communicate behavioral hints to clients

package/catalog/frontmcp-development/examples/create-workflow/webhook-triggered-workflow.md

@@ -33,10 +33,12 @@ import { Workflow } from '@frontmcp/sdk';
   },
   timeout: 900000, // 15 minutes
   maxConcurrency: 3,
-  permissions: {
-    actions: ['create', 'read', 'execute', 'list'],
-    roles: ['admin', 'ci-bot'],
-  },
+  permissions: [
+    { action: 'execute', roles: ['admin', 'ci-bot'] },
+    { action: 'create', roles: ['admin', 'ci-bot'] },
+    { action: 'read', roles: ['admin', 'ci-bot'] },
+    { action: 'list', roles: ['admin', 'ci-bot'] },
+  ],
   steps: [
     {
       id: 'build',

package/catalog/frontmcp-development/examples/decorators-guide/agent-skill-job-workflow.md

@@ -86,7 +86,7 @@ import { Workflow } from '@frontmcp/sdk';
   name: 'deploy_pipeline',
   description: 'Full deployment pipeline',
   trigger: 'webhook',
-  webhookConfig: {
+  webhook: {
     path: '/hooks/deploy',
     secret: process.env.WEBHOOK_SECRET!,
     methods: ['POST'],

package/catalog/frontmcp-development/examples/decorators-guide/basic-server-with-app-and-tools.md

@@ -7,8 +7,8 @@ tags: [development, decorators, app, tools]
 features:
   - 'The `@FrontMcp` -> `@App` -> `@Tool`/`@Resource`/`@Prompt` nesting hierarchy'
   - 'Tool classes extend `ToolContext` and implement `execute()`'
-  - 'Resource classes extend `ResourceContext` and implement `read()`'
-  - 'Prompt classes extend `PromptContext` and implement `execute()`'
+  - 'Resource classes extend `ResourceContext` and implement `execute(uri, params)`'
+  - 'Prompt classes extend `PromptContext` and implement `execute(args: Record<string, string>)`'
   - 'Apps group related tools, resources, and prompts into logical modules'
 ---
 
@@ -49,9 +49,9 @@ import { Resource, ResourceContext } from '@frontmcp/sdk';
   mimeType: 'application/json',
 })
 class AppConfigResource extends ResourceContext {
-  async read() {
+  async execute(uri: string, _params: Record<string, string>) {
     const config = await this.get(ConfigService).getAll();
-    return { contents: [{ uri: this.uri, text: JSON.stringify(config) }] };
+    return { contents: [{ uri, text: JSON.stringify(config) }] };
   }
 }
 ```
@@ -69,14 +69,19 @@ import { Prompt, PromptContext } from '@frontmcp/sdk';
   ],
 })
 class CodeReviewPrompt extends PromptContext {
-  async execute(args: { code: string; language?: string }) {
+  // Prompt arguments arrive as Record<string, string> — coerce to other types as needed.
+  // Required-arg validation is performed before `execute()` is called, so `args.code`
+  // is guaranteed present here. The `language` fallback handles the optional arg.
+  async execute(args: Record<string, string>) {
+    const code = args.code;
+    const language = args.language ?? 'unknown';
     return {
       messages: [
         {
           role: 'user' as const,
           content: {
             type: 'text' as const,
-            text: `Review this ${args.language ?? ''} code:\n\n${args.code}`,
+            text: `Review this ${language} code:\n\n${code}`,
           },
         },
       ],
@@ -114,8 +119,8 @@ class MyServer {}
 
 - The `@FrontMcp` -> `@App` -> `@Tool`/`@Resource`/`@Prompt` nesting hierarchy
 - Tool classes extend `ToolContext` and implement `execute()`
-- Resource classes extend `ResourceContext` and implement `read()`
-- Prompt classes extend `PromptContext` and implement `execute()`
+- Resource classes extend `ResourceContext` and implement `execute(uri, params)`
+- Prompt classes extend `PromptContext` and implement `execute(args: Record<string, string>)`
 - Apps group related tools, resources, and prompts into logical modules
 
 ## Related

package/catalog/frontmcp-development/examples/decorators-guide/multi-app-with-plugins-and-providers.md

@@ -2,15 +2,21 @@
 name: multi-app-with-plugins-and-providers
 reference: decorators-guide
 level: intermediate
-description: 'Demonstrates a server with multiple `@App` modules, a `@Provider` for dependency injection, and a `@Plugin` for cross-cutting concerns.'
-tags: [development, database, multi-app, decorators, multi, app]
+description: Demonstrates a server with multiple `@App` modules, a `@Provider` for dependency injection, and a `@Plugin` for cross-cutting concerns.
+tags:
+  - development
+  - database
+  - multi-app
+  - decorators
+  - multi
+  - app
 features:
-  - 'Organizing a server into multiple `@App` modules (`analytics` and `admin`)'
-  - 'Using `@Provider` with `useFactory` to register a database client for dependency injection'
-  - 'Accessing injected dependencies via `this.get(DatabaseToken)` in tools and resources'
-  - 'Using `@ResourceTemplate` with URI parameters (`{dashboardId}`) for dynamic resources'
-  - 'Registering a `@Plugin` at the server level so it applies across all apps'
-  - 'Global plugins go in `@FrontMcp({ plugins })`, app-scoped providers go in `@App({ providers })`'
+  - Organizing a server into multiple `@App` modules (`analytics` and `admin`)
+  - Decorating a service class with `@Provider({ name, scope })` so it acts as its own DI token (the strict schema rejects `useFactory`/`useClass`/`provide` — use `AsyncProvider` for those)
+  - Accessing injected dependencies via `this.get(DatabaseClient)` in tools and resources
+  - Using `@ResourceTemplate` with URI parameters (`{dashboardId}`) for dynamic resources
+  - Registering a `@Plugin` at the server level so it applies across all apps
+  - Global plugins go in `@FrontMcp({ plugins })`, app-scoped providers go in `@App({ providers })`
 ---
 
 # Multi-App Server with Plugins and Providers
@@ -21,18 +27,39 @@ Demonstrates a server with multiple `@App` modules, a `@Provider` for dependency
 
 ```typescript
 // src/providers/database.provider.ts
-import { Provider } from '@frontmcp/sdk';
-
-export const DatabaseToken = Symbol('Database');
+import { Provider, ProviderScope } from '@frontmcp/sdk';
 
+// The @Provider decorator schema is strict: it accepts only `id|name|description|scope`.
+// `provide`/`useClass`/`useValue`/`useFactory` are NOT supported.
+// For simple cases, decorate the class itself — it becomes its own DI token.
 @Provider({
-  name: 'database',
-  provide: DatabaseToken,
-  useFactory: () => new DatabaseClient(process.env.DB_URL),
+  name: 'DatabaseClient',
+  scope: ProviderScope.GLOBAL,
 })
-class DatabaseProvider {}
+export class DatabaseClient {
+  constructor(private readonly url = process.env.DB_URL) {}
+
+  async query(sql: string): Promise<unknown[]> {
+    /* ... */
+    return [];
+  }
+
+  async getDataset(id: string): Promise<unknown[]> {
+    /* ... */
+    return [];
+  }
+
+  async getDashboard(id: string): Promise<unknown> {
+    /* ... */
+    return {};
+  }
+}
 ```
 
+> If you need an async factory or want to bind to a separate token, use the
+> `AsyncProvider({ provide, name, scope, inject, useFactory })` helper instead of
+> the `@Provider` decorator.
+
 ```typescript
 // src/plugins/audit.plugin.ts
 import { Plugin } from '@frontmcp/sdk';
@@ -58,7 +85,7 @@ import { Tool, ToolContext, z } from '@frontmcp/sdk';
 })
 class QueryTool extends ToolContext {
   async execute(input: { sql: string }) {
-    const db = this.get(DatabaseToken);
+    const db = this.get(DatabaseClient);
     const results = await db.query(input.sql);
     return { rows: results };
   }
@@ -79,7 +106,7 @@ import { Tool, ToolContext, z } from '@frontmcp/sdk';
 })
 class ReportTool extends ToolContext {
   async execute(input: { datasetId: string; format: string }) {
-    const db = this.get(DatabaseToken);
+    const db = this.get(DatabaseClient);
     const data = await db.getDataset(input.datasetId);
     return { report: `Report in ${input.format} format`, rows: data.length };
   }
@@ -96,9 +123,9 @@ import { ResourceContext, ResourceTemplate } from '@frontmcp/sdk';
   description: 'Dashboard data by ID',
   mimeType: 'application/json',
 })
-class DashboardResource extends ResourceContext {
-  async read(uri: string, params: { dashboardId: string }) {
-    const db = this.get(DatabaseToken);
+class DashboardResource extends ResourceContext<{ dashboardId: string }> {
+  async execute(uri: string, params: { dashboardId: string }) {
+    const db = this.get(DatabaseClient);
     const data = await db.getDashboard(params.dashboardId);
     return { contents: [{ uri, text: JSON.stringify(data) }] };
   }
@@ -113,7 +140,7 @@ import { App, FrontMcp } from '@frontmcp/sdk';
   name: 'analytics',
   tools: [QueryTool, ReportTool],
   resources: [DashboardResource],
-  providers: [DatabaseProvider],
+  providers: [DatabaseClient],
 })
 class AnalyticsApp {}
 
@@ -135,8 +162,8 @@ class MyServer {}
 ## What This Demonstrates
 
 - Organizing a server into multiple `@App` modules (`analytics` and `admin`)
-- Using `@Provider` with `useFactory` to register a database client for dependency injection
-- Accessing injected dependencies via `this.get(DatabaseToken)` in tools and resources
+- Decorating a service class with `@Provider({ name, scope })` so it acts as its own DI token (the strict schema rejects `useFactory`/`useClass`/`provide` — use `AsyncProvider` for those)
+- Accessing injected dependencies via `this.get(DatabaseClient)` in tools and resources
 - Using `@ResourceTemplate` with URI parameters (`{dashboardId}`) for dynamic resources
 - Registering a `@Plugin` at the server level so it applies across all apps
 - Global plugins go in `@FrontMcp({ plugins })`, app-scoped providers go in `@App({ providers })`