@frontmcp/skills 0.0.1 → 1.0.0-beta.9

package/catalog/frontmcp-deployment/references/deploy-to-vercel-config.md

@@ -0,0 +1,60 @@
+{
+"$schema": "https://openapi.vercel.sh/vercel.json",
+"framework": null,
+"buildCommand": "frontmcp build --target vercel",
+"outputDirectory": "dist",
+"rewrites": [
+{
+"source": "/(.*)",
+"destination": "/api/frontmcp"
+}
+],
+"functions": {
+"api/frontmcp.js": {
+"memory": 512,
+"maxDuration": 30
+}
+},
+"regions": ["iad1"],
+"headers": [
+{
+"source": "/health",
+"headers": [
+{
+"key": "Cache-Control",
+"value": "no-store"
+}
+]
+},
+{
+"source": "/mcp",
+"headers": [
+{
+"key": "Cache-Control",
+"value": "no-store"
+},
+{
+"key": "X-Content-Type-Options",
+"value": "nosniff"
+}
+]
+},
+{
+"source": "/(.\*)",
+"headers": [
+{
+"key": "X-Frame-Options",
+"value": "DENY"
+},
+{
+"key": "X-Content-Type-Options",
+"value": "nosniff"
+},
+{
+"key": "Referrer-Policy",
+"value": "strict-origin-when-cross-origin"
+}
+]
+}
+]
+}

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

@@ -0,0 +1,224 @@
+# Deploy a FrontMCP Server to Vercel
+
+This skill guides you through deploying a FrontMCP server to Vercel serverless functions with Vercel KV for persistent storage.
+
+## When to Use This Skill
+
+### Must Use
+
+- Deploying a FrontMCP server to Vercel serverless functions
+- Configuring Vercel KV as the persistence layer for sessions and skill cache
+- Setting up a serverless MCP endpoint with automatic TLS and global CDN
+
+### Recommended
+
+- You already use Vercel for your frontend and want a unified deployment pipeline
+- You need zero-ops scaling without managing Docker containers or servers
+- Deploying preview environments per pull request for MCP server testing
+
+### Skip When
+
+- You need persistent connections, WebSockets, or long-running processes -- use `deploy-to-node` instead
+- Deploying to AWS infrastructure or need AWS-specific services -- use `deploy-to-lambda` instead
+- Your MCP operations routinely exceed the Vercel function timeout for your plan
+
+> **Decision:** Choose this skill when you want serverless deployment on Vercel with minimal infrastructure management; choose a different target when you need persistent processes or AWS-native services.
+
+## Prerequisites
+
+- A Vercel account (https://vercel.com)
+- Vercel CLI installed: `npm install -g vercel`
+- A built FrontMCP project
+
+## Step 1: Build for Vercel
+
+```bash
+frontmcp build --target vercel
+```
+
+This produces a Vercel-compatible output structure with an `api/` directory containing the serverless function entry points, optimized bundles for cold-start performance, and a `vercel.json` configuration file.
+
+## Step 2: Configure vercel.json
+
+Create or update `vercel.json` in your project root:
+
+```json
+{
+  "rewrites": [{ "source": "/(.*)", "destination": "/api/frontmcp" }],
+  "functions": {
+    "api/frontmcp.ts": {
+      "memory": 1024,
+      "maxDuration": 60
+    }
+  },
+  "regions": ["iad1"],
+  "headers": [
+    {
+      "source": "/(.*)",
+      "headers": [
+        { "key": "X-Content-Type-Options", "value": "nosniff" },
+        { "key": "X-Frame-Options", "value": "DENY" }
+      ]
+    }
+  ]
+}
+```
+
+The rewrite rule sends all requests to the single FrontMCP API handler, which internally routes MCP and HTTP requests.
+
+## Step 3: Configure Vercel KV Storage
+
+Use the `vercel-kv` provider so FrontMCP stores sessions, skill cache, and plugin state in Vercel KV (powered by Upstash Redis):
+
+```typescript
+import { FrontMcp, App } from '@frontmcp/sdk';
+
+@App({ name: 'MyApp' })
+class MyApp {}
+
+@FrontMcp({
+  info: { name: 'my-server', version: '1.0.0' },
+  apps: [MyApp],
+  redis: { provider: 'vercel-kv' },
+  skillsConfig: {
+    enabled: true,
+    cache: {
+      enabled: true,
+      redis: { provider: 'vercel-kv' },
+      ttlMs: 60000,
+    },
+  },
+})
+class MyServer {}
+```
+
+Provision the KV store in the Vercel dashboard under **Storage > Create Database > KV (Redis)**, then link it to your project. Vercel automatically injects the required environment variables.
+
+## Step 4: Environment Variables
+
+Vercel KV variables are injected automatically when the store is linked. For manual setup or additional configuration, set them in the Vercel dashboard (**Settings > Environment Variables**) or via the CLI:
+
+```bash
+vercel env add KV_REST_API_URL "https://your-kv-store.kv.vercel-storage.com"
+vercel env add KV_REST_API_TOKEN "your-token"
+vercel env add NODE_ENV production
+vercel env add LOG_LEVEL info
+```
+
+| Variable            | Description                    | Required    |
+| ------------------- | ------------------------------ | ----------- |
+| `KV_REST_API_URL`   | Vercel KV REST endpoint        | If using KV |
+| `KV_REST_API_TOKEN` | Vercel KV authentication token | If using KV |
+| `NODE_ENV`          | Runtime environment            | Yes         |
+| `LOG_LEVEL`         | Logging verbosity              | No          |
+
+## Step 5: Deploy
+
+### Preview Deployment
+
+```bash
+vercel
+```
+
+Creates a preview deployment with a unique URL for validation.
+
+### Production Deployment
+
+```bash
+vercel --prod
+```
+
+Deploys to your production domain.
+
+### Custom Domain
+
+```bash
+vercel domains add mcp.example.com
+```
+
+Configure your DNS provider to point the domain to Vercel. TLS certificates are provisioned automatically.
+
+## Step 6: Verify
+
+```bash
+# Health check
+curl https://your-project.vercel.app/health
+
+# Test MCP endpoint
+curl -X POST https://your-project.vercel.app/mcp \
+  -H "Content-Type: application/json" \
+  -d '{"jsonrpc":"2.0","method":"tools/list","id":1}'
+```
+
+## Cold Start Notes
+
+Vercel serverless functions experience cold starts after periods of inactivity. To minimize impact:
+
+- The `frontmcp build --target vercel` output is optimized for bundle size. Avoid adding unnecessary dependencies.
+- Consider Vercel's **Fluid Compute** for latency-sensitive workloads.
+- Keep function memory at 1024 MB for faster initialization.
+
+### Execution Limits
+
+| Plan       | Max Duration |
+| ---------- | ------------ |
+| Hobby      | 10 seconds   |
+| Pro        | 60 seconds   |
+| Enterprise | 900 seconds  |
+
+Long-running MCP operations should complete within these limits or use streaming responses.
+
+### Statelessness
+
+Serverless functions are stateless between invocations. All persistent state must go through Vercel KV. FrontMCP handles this automatically when `{ provider: 'vercel-kv' }` is configured.
+
+## Common Patterns
+
+| Pattern               | Correct                                    | Incorrect                            | Why                                                                             |
+| --------------------- | ------------------------------------------ | ------------------------------------ | ------------------------------------------------------------------------------- |
+| Build command         | `frontmcp build --target vercel`           | `tsc` or generic `npm run build`     | The Vercel target produces optimized bundles and the `api/` directory structure |
+| KV provider config    | `{ provider: 'vercel-kv' }`                | `{ provider: 'redis', host: '...' }` | Vercel KV uses its own REST API; a raw Redis provider will not connect          |
+| Rewrite rule          | `"source": "/(.*)"` to `/api/frontmcp`     | No rewrite or per-route entries      | A single catch-all rewrite lets FrontMCP's internal router handle all paths     |
+| Environment variables | Link KV store in dashboard (auto-injected) | Hardcode `KV_REST_API_URL` in source | Linked stores inject vars automatically and rotate tokens safely                |
+| Function memory       | 1024 MB for faster cold starts             | 128 MB default                       | CPU scales with memory on Vercel; higher memory reduces initialization time     |
+
+## Verification Checklist
+
+**Build**
+
+- [ ] `frontmcp build --target vercel` completes without errors
+- [ ] `api/frontmcp.ts` (or `.js`) exists in the build output
+
+**Deployment**
+
+- [ ] `vercel` creates a preview deployment without errors
+- [ ] `vercel --prod` deploys to the production domain
+- [ ] `curl https://your-project.vercel.app/health` returns `{"status":"ok"}`
+
+**Storage and Configuration**
+
+- [ ] Vercel KV store is created and linked to the project
+- [ ] `KV_REST_API_URL` and `KV_REST_API_TOKEN` are present in environment variables
+- [ ] `NODE_ENV` is set to `production`
+- [ ] `vercel.json` has correct rewrite, function config, and region settings
+
+**Production Readiness**
+
+- [ ] Custom domain is configured with DNS pointing to Vercel
+- [ ] TLS certificate is provisioned (automatic on Vercel)
+- [ ] `maxDuration` in `vercel.json` matches your Vercel plan limits
+
+## Troubleshooting
+
+| Problem              | Cause                                         | Solution                                                                                       |
+| -------------------- | --------------------------------------------- | ---------------------------------------------------------------------------------------------- |
+| Function timeout     | Operation exceeds `maxDuration` or plan limit | Increase `maxDuration` in `vercel.json`; check plan limits (Hobby: 10s, Pro: 60s)              |
+| KV connection errors | KV store not linked or env vars missing       | Re-link the KV store in the Vercel dashboard; verify `KV_REST_API_URL` and `KV_REST_API_TOKEN` |
+| 404 on API routes    | Rewrite rule missing or misconfigured         | Confirm `vercel.json` has `"source": "/(.*)"` rewriting to `/api/frontmcp`                     |
+| Bundle too large     | Unnecessary dependencies included             | Review dependencies and remove unused packages to reduce bundle size                           |
+| Cold starts too slow | Low function memory or large bundle           | Increase memory to 1024 MB; audit dependencies; consider Vercel Fluid Compute                  |
+
+## Reference
+
+- **Docs:** https://docs.agentfront.dev/frontmcp/deployment/serverless
+- **Related skills:** `deploy-to-node`, `deploy-to-lambda`

package/catalog/frontmcp-development/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: frontmcp-development
+description: "Domain router for building MCP components \u2014 tools, resources, prompts, agents, providers, jobs, workflows, and skills. Use when starting any FrontMCP development task and need to find the right skill."
+tags: [router, development, tools, resources, prompts, agents, skills, guide]
+priority: 10
+visibility: both
+license: Apache-2.0
+metadata:
+  docs: https://docs.agentfront.dev/frontmcp/servers/overview
+---
+
+# FrontMCP Development Router
+
+Entry point for building MCP server components. This skill helps you find the right development skill based on what you want to build. It does not teach implementation details itself — it routes you to the specific skill that does.
+
+## When to Use This Skill
+
+### Must Use
+
+- Starting a FrontMCP development task and unsure which component type to build (tool vs resource vs prompt vs agent)
+- Onboarding to the FrontMCP development model and need an overview of all building blocks
+- Planning a feature that may require multiple component types working together
+
+### Recommended
+
+- Looking up the canonical name of a development skill to install or search
+- Comparing component types to decide which fits your use case
+- Understanding how tools, resources, prompts, agents, and skills relate to each other
+
+### Skip When
+
+- You already know which component to build (go directly to `create-tool`, `create-resource`, etc.)
+- You need to configure server settings, not build components (see `frontmcp-config`)
+- You need to deploy or build, not develop (see `frontmcp-deployment`)
+
+> **Decision:** Use this skill when you need to figure out WHAT to build. Use the specific skill when you already know.
+
+## Scenario Routing Table
+
+| Scenario                                                 | Skill                     | Description                                                                          |
+| -------------------------------------------------------- | ------------------------- | ------------------------------------------------------------------------------------ |
+| Expose an executable action that AI clients can call     | `create-tool`             | Class-based or function-style tools with Zod input/output validation                 |
+| Expose read-only data via a URI                          | `create-resource`         | Static resources or URI template resources for dynamic data                          |
+| Create a reusable conversation template or system prompt | `create-prompt`           | Prompt entries with arguments and multi-turn message sequences                       |
+| Build an autonomous AI loop that orchestrates tools      | `create-agent`            | Agent entries with LLM config, inner tools, and swarm handoff                        |
+| Register shared services or configuration via DI         | `create-provider`         | Dependency injection tokens, lifecycle hooks, factory providers                      |
+| Run a background task with progress and retries          | `create-job`              | Job entries with attempt tracking, retry config, and progress                        |
+| Chain multiple jobs into a sequential pipeline           | `create-workflow`         | Workflow entries that compose jobs with data passing                                 |
+| Write instruction-only AI guidance (no code execution)   | `create-skill`            | Skill entries with markdown instructions from files, strings, or URLs                |
+| Write AI guidance that also orchestrates tools           | `create-skill-with-tools` | Skill entries that combine instructions with registered tools                        |
+| Look up any decorator signature or option                | `decorators-guide`        | Complete reference for @Tool, @Resource, @Prompt, @Agent, @App, @FrontMcp, and more  |
+| Integrate an external API via OpenAPI spec               | `official-adapters`       | OpenApiAdapter with auth, polling, inline specs, and multiple API composition        |
+| Use official plugins (caching, remember, feature flags)  | `official-plugins`        | Built-in plugins for caching, session memory, approval, feature flags, and dashboard |
+
+## Recommended Reading Order
+
+1. **`decorators-guide`** — Start here to understand the full decorator landscape
+2. **`create-tool`** — The most common building block; learn tools first
+3. **`create-resource`** — Expose data alongside tools
+4. **`create-prompt`** — Add reusable conversation templates
+5. **`create-provider`** — Share services across tools and resources via DI
+6. **`create-agent`** — Build autonomous AI loops (advanced)
+7. **`create-job`** / **`create-workflow`** — Background processing (advanced)
+8. **`create-skill`** / **`create-skill-with-tools`** — Author your own skills (meta)
+9. **`official-adapters`** — Integrate external APIs via OpenAPI specs
+10. **`official-plugins`** — Add caching, session memory, feature flags, and more
+
+## Cross-Cutting Patterns
+
+| Pattern           | Applies To                        | Rule                                                                                   |
+| ----------------- | --------------------------------- | -------------------------------------------------------------------------------------- |
+| Naming convention | Tools                             | Use `snake_case` for tool names (`get_weather`, not `getWeather`)                      |
+| Naming convention | Skills, resources                 | Use `kebab-case` for skill and resource names                                          |
+| File naming       | All components                    | Use `<name>.<type>.ts` pattern (e.g., `fetch-weather.tool.ts`)                         |
+| DI access         | Tools, resources, prompts, agents | Use `this.get(TOKEN)` (throws) or `this.tryGet(TOKEN)` (returns undefined)             |
+| Error handling    | All components                    | Use `this.fail(err)` with MCP error classes, not raw `throw`                           |
+| Input validation  | Tools                             | Always use Zod raw shapes (not `z.object()`) for `inputSchema`                         |
+| Output validation | Tools                             | Always define `outputSchema` to prevent data leaks                                     |
+| Registration      | All components                    | Add to `tools`, `resources`, `prompts`, `agents`, etc. arrays in `@App` or `@FrontMcp` |
+| Test files        | All components                    | Use `.spec.ts` extension, never `.test.ts`                                             |
+
+## Common Patterns
+
+| Pattern                 | Correct                                                   | Incorrect                                                | Why                                                                   |
+| ----------------------- | --------------------------------------------------------- | -------------------------------------------------------- | --------------------------------------------------------------------- |
+| Choosing component type | Tool for actions, Resource for data, Prompt for templates | Using a tool to return static data                       | Each type has protocol-level semantics; misuse confuses AI clients    |
+| Component registration  | Register in `@App` arrays, compose apps in `@FrontMcp`    | Register tools directly in `@FrontMcp` without an `@App` | Apps provide modularity; direct registration bypasses app-level hooks |
+| Shared logic            | Extract to a `@Provider` and inject via DI                | Duplicate code across multiple tools                     | Providers are testable, lifecycle-managed, and scoped                 |
+| Complex orchestration   | Use `@Agent` with inner tools                             | Chain tool calls manually in a single tool               | Agents handle LLM loops, retries, and tool selection automatically    |
+| Background work         | Use `@Job` with retry config                              | Run long tasks inside a tool's `execute()`               | Jobs have progress tracking, attempt awareness, and timeout handling  |
+
+## Verification Checklist
+
+### Architecture
+
+- [ ] Each component type matches its semantic purpose (action=tool, data=resource, template=prompt)
+- [ ] Shared services use `@Provider` with DI tokens, not module-level singletons
+- [ ] Components are registered in `@App` arrays, apps composed in `@FrontMcp`
+
+### Development Workflow
+
+- [ ] Files follow `<name>.<type>.ts` naming convention
+- [ ] Each component has a corresponding `.spec.ts` test file
+- [ ] `decorators-guide` consulted for unfamiliar decorator options
+
+## Troubleshooting
+
+| Problem                                  | Cause                                          | Solution                                                                                                                    |
+| ---------------------------------------- | ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
+| Unsure which component type to use       | Requirements are ambiguous                     | Check the Scenario Routing Table above; if the action modifies state, use a tool; if it returns data by URI, use a resource |
+| Component not discovered at runtime      | Not registered in `@App` or `@FrontMcp` arrays | Add to the appropriate array (`tools`, `resources`, `prompts`, etc.)                                                        |
+| DI token not resolving                   | Provider not registered in scope               | Register the provider in the `providers` array of the same `@App`                                                           |
+| Need both AI guidance and tool execution | Used `create-skill` but need tools too         | Switch to `create-skill-with-tools` which combines instructions with registered tools                                       |
+
+## Reference
+
+- [Server Overview](https://docs.agentfront.dev/frontmcp/servers/overview)
+- Related skills: `create-tool`, `create-resource`, `create-prompt`, `create-agent`, `create-provider`, `create-job`, `create-workflow`, `create-skill`, `create-skill-with-tools`, `decorators-guide`, `official-adapters`, `official-plugins`

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

@@ -0,0 +1,165 @@
+# Creating Custom Adapters
+
+Build adapters that automatically generate MCP tools, resources, and prompts from external sources — databases, GraphQL schemas, proprietary APIs, or any definition format.
+
+## When to Use This Skill
+
+### Must Use
+
+- Integrating a non-OpenAPI source (GraphQL, gRPC, database schema) that should generate MCP tools automatically
+- Building a reusable adapter that converts external definitions into tools, resources, or prompts at startup
+- Creating tools dynamically at runtime based on external state or configuration
+
+### Recommended
+
+- Wrapping a proprietary internal API that has its own schema format
+- Auto-generating tools from a database schema or config file on server start
+- Building an adapter that polls an external source and refreshes tool definitions periodically
+
+### Skip When
+
+- The external API has an OpenAPI/Swagger spec (see `official-adapters`)
+- You need cross-cutting middleware behavior like logging or caching (see `create-plugin`)
+- You are building a single static tool manually (see `create-tool`)
+
+> **Decision:** Use this skill when you need to auto-generate MCP tools, resources, or prompts from a non-OpenAPI external source by extending `DynamicAdapter`.
+
+## Step 1: Extend DynamicAdapter
+
+```typescript
+import { DynamicAdapter, type FrontMcpAdapterResponse } from '@frontmcp/sdk';
+
+interface MyAdapterOptions {
+  endpoint: string;
+  apiKey: string;
+}
+
+class MyApiAdapter extends DynamicAdapter<MyAdapterOptions> {
+  declare __options_brand: MyAdapterOptions;
+
+  async fetch(): Promise<FrontMcpAdapterResponse> {
+    // Fetch definitions from external source
+    const res = await globalThis.fetch(this.options.endpoint, {
+      headers: { Authorization: `Bearer ${this.options.apiKey}` },
+    });
+    const schema = await res.json();
+
+    // Convert to MCP tool definitions
+    return {
+      tools: schema.operations.map((op: { name: string; description: string; params: Record<string, unknown> }) => ({
+        name: op.name,
+        description: op.description,
+        inputSchema: this.convertParams(op.params),
+        execute: async (input: Record<string, unknown>) => {
+          return this.callApi(op.name, input);
+        },
+      })),
+      resources: [],
+      prompts: [],
+    };
+  }
+
+  private convertParams(params: Record<string, unknown>) {
+    // Convert external param definitions to Zod schemas
+    // ...
+  }
+
+  private async callApi(operation: string, input: Record<string, unknown>) {
+    // Call the external API
+    // ...
+  }
+}
+```
+
+## Step 2: Register
+
+```typescript
+@App({
+  name: 'MyApp',
+  adapters: [
+    MyApiAdapter.init({
+      name: 'my-api',
+      endpoint: 'https://api.example.com/schema',
+      apiKey: process.env.API_KEY!,
+    }),
+  ],
+})
+class MyApp {}
+```
+
+## FrontMcpAdapterResponse
+
+The `fetch()` method returns tools, resources, and prompts to register:
+
+```typescript
+interface FrontMcpAdapterResponse {
+  tools?: AdapterToolDefinition[];
+  resources?: AdapterResourceDefinition[];
+  prompts?: AdapterPromptDefinition[];
+}
+```
+
+## Static init()
+
+`DynamicAdapter` provides a static `init()` method inherited by all subclasses:
+
+```typescript
+// Usage — no manual instantiation needed
+const adapter = MyApiAdapter.init({
+  name: 'my-api',        // Required: adapter name (used for tool namespacing)
+  endpoint: '...',
+  apiKey: '...',
+});
+
+// Register in @App
+@App({ adapters: [adapter] })
+```
+
+## Nx Generator
+
+```bash
+nx generate @frontmcp/nx:adapter my-adapter --project=my-app
+```
+
+Creates a `DynamicAdapter` subclass in `src/adapters/my-adapter.adapter.ts`.
+
+## Common Patterns
+
+| Pattern                 | Correct                                                       | Incorrect                                              | Why                                                                             |
+| ----------------------- | ------------------------------------------------------------- | ------------------------------------------------------ | ------------------------------------------------------------------------------- |
+| Adapter registration    | `MyAdapter.init({ name: 'my-api', ... })` in `adapters` array | `new MyAdapter({ ... })` directly                      | `init()` returns the proper provider entry for DI wiring                        |
+| Options branding        | `declare __options_brand: MyAdapterOptions;` in adapter class | Omitting the brand declaration                         | Brand ensures TypeScript infers the correct options type for `init()`           |
+| Fetch return type       | Return `{ tools: [...], resources: [...], prompts: [...] }`   | Returning raw API response without conversion          | `fetch()` must return `FrontMcpAdapterResponse` with MCP-compatible definitions |
+| Tool naming             | Namespace tools: `name: 'my-api:operation-name'`              | Flat names without namespace: `name: 'operation-name'` | Namespacing prevents collisions when multiple adapters are registered           |
+| Error handling in fetch | Throw descriptive errors with endpoint info                   | Silently returning empty arrays on failure             | Adapter errors should surface at startup so misconfigurations are caught early  |
+
+## Verification Checklist
+
+### Configuration
+
+- [ ] Adapter class extends `DynamicAdapter<TOptions>`
+- [ ] `__options_brand` is declared with the correct options type
+- [ ] `fetch()` method is implemented and returns `FrontMcpAdapterResponse`
+- [ ] Adapter is registered via `.init()` in the `adapters` array of `@App`
+
+### Runtime
+
+- [ ] Generated tools appear in `tools/list` MCP response
+- [ ] Tool names are namespaced with the adapter name (e.g., `my-api:operationId`)
+- [ ] Generated tools accept valid input and return expected output
+- [ ] Adapter fetch errors produce clear startup error messages
+
+## Troubleshooting
+
+| Problem                                    | Cause                                                       | Solution                                                                         |
+| ------------------------------------------ | ----------------------------------------------------------- | -------------------------------------------------------------------------------- |
+| No tools appear after adapter registration | `fetch()` returns empty `tools` array                       | Verify external source is reachable and response is parsed correctly             |
+| TypeScript error on `.init()` options      | Missing `__options_brand` declaration                       | Add `declare __options_brand: MyAdapterOptions;` to the adapter class            |
+| Tool input validation fails                | `inputSchema` conversion does not produce valid Zod schemas | Verify `convertParams` produces `z.object()` shapes matching the external schema |
+| Duplicate tool name error                  | Multiple adapters produce tools with the same name          | Use unique `name` parameter in `init()` to namespace tools                       |
+| Adapter not found at runtime               | Registered in wrong `@App` or not in `adapters` array       | Ensure `.init()` result is in the `adapters` array of the correct `@App`         |
+
+## Reference
+
+- [Adapter Documentation](https://docs.agentfront.dev/frontmcp/adapters/overview)
+- Related skills: `official-adapters`, `create-plugin`, `create-tool`

package/catalog/{development/create-agent/references/llm-config.md → frontmcp-development/references/create-agent-llm-config.md}

@@ -1,13 +1,13 @@
 # Agent LLM Configuration Reference
 
-## Supported Adapters
+## Supported Providers
 
 ### Anthropic
 
 ```typescript
 llm: {
-  adapter: 'anthropic',
-  model: 'claude-sonnet-4-20250514',
+  provider: 'anthropic', // Any supported provider — 'anthropic', 'openai', etc.
+  model: 'claude-sonnet-4-20250514', // Any supported model for the chosen provider
   apiKey: { env: 'ANTHROPIC_API_KEY' },
   maxTokens: 4096,
 }
@@ -17,8 +17,8 @@ llm: {
 
 ```typescript
 llm: {
-  adapter: 'openai',
-  model: 'gpt-4o',
+  provider: 'openai',
+  model: 'gpt-4o', // Any supported model for the chosen provider
   apiKey: { env: 'OPENAI_API_KEY' },
   maxTokens: 4096,
 }