@frontmcp/skills 0.0.1 → 1.0.0-beta.11

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

@@ -0,0 +1,234 @@
+---
+name: configure-throttle
+description: Protect servers with rate limiting, concurrency control, execution timeouts, and IP filtering
+---
+
+# Configuring Throttle, Rate Limits, and IP Filtering
+
+Protect your FrontMCP server with rate limiting, concurrency control, execution timeouts, and IP filtering — at both server and per-tool levels.
+
+## When to Use This Skill
+
+### Must Use
+
+- Deploying a server to production where abuse protection and rate limiting are required
+- Exposing expensive or destructive tools that need concurrency caps and execution timeouts
+- Restricting access by IP address with allow/deny lists for compliance or security
+
+### Recommended
+
+- Enforcing per-session or per-IP request quotas to ensure fair resource distribution
+- Adding global concurrency limits to prevent server overload under burst traffic
+- Configuring distributed rate limiting across multiple server instances with Redis
+
+### Skip When
+
+- Running a local development server with stdio transport only -- throttle adds unnecessary overhead
+- Only need CORS or port configuration without rate limiting -- use `configure-http`
+- Need authentication or session management rather than rate limiting -- use `configure-session` or `configure-auth`
+
+> **Decision:** Use this skill when your server needs protection against abuse, rate limiting, concurrency control, IP filtering, or execution timeouts at either the server or per-tool level.
+
+## Server-Level Throttle (GuardConfig)
+
+```typescript
+@FrontMcp({
+  info: { name: 'my-server', version: '1.0.0' },
+  apps: [MyApp],
+  throttle: {
+    enabled: true,
+
+    // Global rate limit (all requests combined)
+    global: {
+      maxRequests: 1000,
+      windowMs: 60000, // 1 minute window
+      partitionBy: 'global', // shared across all clients
+    },
+
+    // Global concurrency limit
+    globalConcurrency: {
+      maxConcurrent: 50,
+      partitionBy: 'global',
+    },
+
+    // Default limits for individual tools (applied unless tool overrides)
+    defaultRateLimit: {
+      maxRequests: 100,
+      windowMs: 60000,
+    },
+    defaultConcurrency: {
+      maxConcurrent: 10,
+    },
+    defaultTimeout: {
+      executeMs: 30000, // 30 second timeout
+    },
+
+    // IP filtering
+    ipFilter: {
+      allowList: ['10.0.0.0/8', '172.16.0.0/12'], // CIDR ranges
+      denyList: ['192.168.1.100'],
+      defaultAction: 'allow', // 'allow' | 'deny'
+      trustProxy: true, // trust X-Forwarded-For
+      trustedProxyDepth: 1, // proxy depth to trust
+    },
+  },
+})
+class Server {}
+```
+
+## Per-Tool Rate Limiting
+
+Override server defaults on individual tools:
+
+```typescript
+@Tool({
+  name: 'expensive_query',
+  description: 'Run an expensive database query',
+  inputSchema: {
+    query: z.string(),
+  },
+  outputSchema: { rows: z.array(z.record(z.unknown())) },
+
+  // Per-tool limits
+  rateLimit: {
+    maxRequests: 10,
+    windowMs: 60000,
+    partitionBy: 'session', // per-session rate limit
+  },
+  concurrency: {
+    maxConcurrent: 3,
+    queueTimeoutMs: 5000, // wait up to 5s for a slot
+    partitionBy: 'session',
+  },
+  timeout: {
+    executeMs: 60000, // 60 second timeout for this tool
+  },
+})
+class ExpensiveQueryTool extends ToolContext {
+  async execute(input: { query: string }) {
+    const db = this.get(DB_TOKEN);
+    return { rows: await db.query(input.query) };
+  }
+}
+```
+
+## Configuration Types
+
+### RateLimitConfig
+
+| Field         | Type                            | Default    | Description               |
+| ------------- | ------------------------------- | ---------- | ------------------------- |
+| `maxRequests` | `number`                        | —          | Max requests per window   |
+| `windowMs`    | `number`                        | `60000`    | Window duration in ms     |
+| `partitionBy` | `'global' \| 'ip' \| 'session'` | `'global'` | How to partition counters |
+
+### ConcurrencyConfig
+
+| Field            | Type                            | Default    | Description                                        |
+| ---------------- | ------------------------------- | ---------- | -------------------------------------------------- |
+| `maxConcurrent`  | `number`                        | —          | Max simultaneous executions                        |
+| `queueTimeoutMs` | `number`                        | `0`        | How long to wait for a slot (0 = fail immediately) |
+| `partitionBy`    | `'global' \| 'ip' \| 'session'` | `'global'` | How to partition counters                          |
+
+### TimeoutConfig
+
+| Field       | Type     | Default | Description              |
+| ----------- | -------- | ------- | ------------------------ |
+| `executeMs` | `number` | —       | Max execution time in ms |
+
+### IpFilterConfig
+
+| Field               | Type                | Default   | Description                         |
+| ------------------- | ------------------- | --------- | ----------------------------------- |
+| `allowList`         | `string[]`          | —         | Allowed IPs or CIDR ranges          |
+| `denyList`          | `string[]`          | —         | Blocked IPs or CIDR ranges          |
+| `defaultAction`     | `'allow' \| 'deny'` | `'allow'` | Action when IP matches neither list |
+| `trustProxy`        | `boolean`           | `false`   | Trust X-Forwarded-For header        |
+| `trustedProxyDepth` | `number`            | `1`       | How many proxy hops to trust        |
+
+## Partition Strategies
+
+- **`'global'`** — Single shared counter for all clients. Use for global capacity limits.
+- **`'ip'`** — Separate counter per client IP. Use for per-client rate limiting.
+- **`'session'`** — Separate counter per MCP session. Use for per-session fairness.
+
+## Distributed Rate Limiting
+
+For multi-instance deployments, configure Redis storage in the guard:
+
+```typescript
+throttle: {
+  enabled: true,
+  storage: {
+    type: 'redis',
+    redis: { config: { host: 'redis.internal', port: 6379 } },
+  },
+  global: { maxRequests: 1000, windowMs: 60000 },
+}
+```
+
+## Verification
+
+```bash
+# Start server
+frontmcp dev
+
+# Test rate limiting (send 101 requests rapidly)
+for i in $(seq 1 101); do
+  curl -s -o /dev/null -w "%{http_code}\n" -X POST http://localhost:3001/ \
+    -H 'Content-Type: application/json' \
+    -d '{"jsonrpc":"2.0","method":"tools/list","id":1}'
+done
+# Should see 429 responses after limit is exceeded
+```
+
+## Common Patterns
+
+| Pattern                   | Correct                                                                                                                        | Incorrect                                                            | Why                                                                                                                                |
+| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
+| Per-tool override         | Set `rateLimit` on the `@Tool` decorator to override server defaults                                                           | Duplicating the full server-level `throttle` config inside each tool | Per-tool config merges with server defaults; only specify the fields you want to override                                          |
+| Partition strategy        | Use `partitionBy: 'session'` for per-user fairness on shared tools                                                             | Using `partitionBy: 'global'` for all limits                         | Global partitioning means one abusive client can exhaust the quota for everyone                                                    |
+| Distributed rate limiting | Configure `storage: { type: 'redis', redis: { config: { host, port } } }` in the throttle block for multi-instance deployments | Relying on in-memory counters with multiple server instances         | In-memory counters are per-process; each instance tracks limits independently, allowing N times the intended rate                  |
+| IP filter ordering        | Set `defaultAction: 'deny'` with an explicit `allowList` for strict environments                                               | Setting `defaultAction: 'allow'` with only a `denyList`              | A deny-by-default posture is safer; new unknown IPs are blocked until explicitly allowed                                           |
+| Concurrency queue timeout | Set `queueTimeoutMs` on concurrency config to queue excess requests briefly                                                    | Setting `queueTimeoutMs: 0` on expensive tools                       | Zero timeout immediately rejects excess requests instead of briefly queuing them, causing unnecessary failures during short bursts |
+
+## Verification Checklist
+
+### Configuration
+
+- [ ] `throttle.enabled` is set to `true` in the `@FrontMcp` decorator
+- [ ] `global.maxRequests` and `global.windowMs` are set to reasonable production values
+- [ ] `defaultTimeout.executeMs` is configured to prevent runaway tool executions
+- [ ] IP filter `defaultAction` matches your security posture (`allow` for open, `deny` for restricted)
+
+### Per-Tool
+
+- [ ] Expensive or destructive tools have explicit `rateLimit` and `concurrency` overrides
+- [ ] `partitionBy` is set to `'session'` or `'ip'` for tools that need per-client fairness
+- [ ] `queueTimeoutMs` is set on concurrency-limited tools to handle brief bursts
+
+### Distributed
+
+- [ ] Redis storage is configured in the throttle block for multi-instance deployments
+- [ ] Redis connection is verified before deploying (see `setup-redis`)
+
+### Runtime
+
+- [ ] Sending requests beyond the rate limit returns HTTP 429
+- [ ] Blocked IPs receive HTTP 403
+- [ ] Tool executions that exceed `executeMs` are terminated and return a timeout error
+
+## Troubleshooting
+
+| Problem                                         | Cause                                                                    | Solution                                                                        |
+| ----------------------------------------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------- |
+| Rate limits not enforced across instances       | In-memory storage used with multiple server replicas                     | Configure `storage: { type: 'redis' }` in the throttle block to share counters  |
+| All requests rejected with 403                  | `ipFilter.defaultAction` set to `'deny'` without any `allowList` entries | Add the allowed IP ranges to `allowList` or change `defaultAction` to `'allow'` |
+| Tools timing out unexpectedly                   | `defaultTimeout.executeMs` too low for the tool's normal execution time  | Increase the global default or set a per-tool `timeout.executeMs` override      |
+| `X-Forwarded-For` header ignored                | `ipFilter.trustProxy` not enabled or `trustedProxyDepth` too low         | Set `trustProxy: true` and adjust `trustedProxyDepth` to match your proxy chain |
+| Rate limit resets not aligned with expectations | `windowMs` misunderstood as a sliding window when it is a fixed window   | The window is fixed; all counters reset at the end of each `windowMs` interval  |
+
+## Reference
+
+- [Guard Configuration Docs](https://docs.agentfront.dev/frontmcp/servers/guard)
+- Related skills: `configure-http`, `configure-transport`, `setup-redis`, `configure-auth`

package/catalog/{config/configure-transport/references/protocol-presets.md → frontmcp-config/references/configure-transport-protocol-presets.md}

@@ -1,3 +1,8 @@
+---
+name: configure-transport-protocol-presets
+description: Reference for legacy, modern, stateless, and minimal transport protocol presets
+---
+
 # Transport Protocol Presets Reference
 
 ## Preset Configurations

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

@@ -0,0 +1,200 @@
+---
+name: configure-transport
+description: Configure client transport protocols including SSE, Streamable HTTP, and stateless API modes
+---
+
+# Configuring Transport
+
+Configure how clients connect to your FrontMCP server — SSE, Streamable HTTP, stateless API, or a combination.
+
+## When to Use This Skill
+
+### Must Use
+
+- Setting up a new FrontMCP server and need to decide on a transport protocol (SSE, Streamable HTTP, or stateless)
+- Deploying to serverless targets (Vercel, Lambda, Cloudflare) that require stateless transport mode
+- Running multiple server instances behind a load balancer that require distributed sessions via Redis
+
+### Recommended
+
+- Migrating an existing server from legacy SSE to modern Streamable HTTP
+- Enabling SSE event resumability so clients can reconnect after network interruptions
+- Fine-tuning protocol flags beyond what the built-in presets provide
+
+### Skip When
+
+- You are configuring authentication or session tokens (use `configure-auth` instead)
+- You need to set up plugin middleware without changing the transport layer (use `create-plugin` reference instead)
+
+> **Decision:** Use this skill whenever you need to choose, combine, or customize the protocol(s) your MCP server exposes to clients.
+
+## TransportOptionsInput
+
+```typescript
+@FrontMcp({
+  info: { name: 'my-server', version: '1.0.0' },
+  apps: [MyApp],
+  transport: {
+    sessionMode: 'stateful', // 'stateful' | 'stateless'
+    protocol: 'legacy', // preset or custom ProtocolConfig
+    persistence: {
+      // false to disable
+      redis: { provider: 'redis', host: 'localhost', port: 6379 },
+      defaultTtlMs: 3600000,
+    },
+    distributedMode: 'auto', // boolean | 'auto'
+    eventStore: {
+      enabled: true,
+      provider: 'redis', // 'memory' | 'redis'
+      maxEvents: 10000,
+      ttlMs: 300000,
+    },
+  },
+})
+class Server {}
+```
+
+## Protocol Presets
+
+Choose a preset that matches your deployment:
+
+| Preset               | SSE | Streamable HTTP | JSON | Stateless | Legacy SSE | Strict Session |
+| -------------------- | --- | --------------- | ---- | --------- | ---------- | -------------- |
+| `'legacy'` (default) | Yes | Yes             | No   | No        | Yes        | Yes            |
+| `'modern'`           | Yes | Yes             | No   | No        | No         | Yes            |
+| `'stateless-api'`    | No  | No              | No   | Yes       | No         | No             |
+| `'full'`             | Yes | Yes             | Yes  | Yes       | Yes        | No             |
+
+### When to Use Each
+
+- **`'legacy'`** — Default. Maximum compatibility with all MCP clients (Claude Desktop, etc.). Best for Node.js deployments.
+- **`'modern'`** — Drop legacy SSE support. Use when all clients support modern MCP protocol.
+- **`'stateless-api'`** — No sessions, pure request/response. Use for **Vercel**, **Lambda**, and other serverless targets.
+- **`'full'`** — All protocols enabled. Use for development or when you need every transport option.
+
+### Custom Protocol Config
+
+Override individual protocol flags:
+
+```typescript
+transport: {
+  protocol: {
+    sse: true,              // SSE listener endpoint
+    streamable: true,       // Streamable HTTP POST
+    json: false,            // JSON-only responses (no streaming)
+    stateless: false,       // Stateless HTTP (no sessions)
+    legacy: false,          // Legacy SSE transport
+    strictSession: true,    // Require session ID for streamable HTTP
+  },
+}
+```
+
+## Distributed Sessions
+
+For multi-instance deployments (load balanced), enable persistence with Redis:
+
+```typescript
+transport: {
+  distributedMode: true,
+  persistence: {
+    redis: { provider: 'redis', host: 'redis.internal', port: 6379 },
+    defaultTtlMs: 3600000,  // 1 hour session TTL
+  },
+}
+```
+
+- `distributedMode: 'auto'` — auto-detect based on whether Redis is configured
+- `distributedMode: true` — force distributed mode (requires Redis)
+- `distributedMode: false` — single-instance mode (in-memory sessions)
+
+## Event Store (SSE Resumability)
+
+Enable event store so clients can resume SSE connections after disconnects:
+
+```typescript
+transport: {
+  eventStore: {
+    enabled: true,
+    provider: 'redis',       // 'memory' for single instance, 'redis' for distributed
+    maxEvents: 10000,        // max events to store
+    ttlMs: 300000,           // 5 minute TTL
+    redis: { provider: 'redis', host: 'localhost' },
+  },
+}
+```
+
+## Target-Specific Recommendations
+
+| Target                   | Recommended Preset | Persistence | Event Store |
+| ------------------------ | ------------------ | ----------- | ----------- |
+| Node.js (single)         | `'legacy'`         | `false`     | Memory      |
+| Node.js (multi-instance) | `'modern'`         | Redis       | Redis       |
+| Vercel                   | `'stateless-api'`  | `false`     | Disabled    |
+| Lambda                   | `'stateless-api'`  | `false`     | Disabled    |
+| Cloudflare               | `'stateless-api'`  | `false`     | Disabled    |
+
+## Verification
+
+```bash
+# Start server and test SSE
+frontmcp dev
+
+# Test SSE endpoint
+curl -N http://localhost:3001/sse
+
+# Test streamable HTTP
+curl -X POST http://localhost:3001/ -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","method":"tools/list","id":1}'
+```
+
+## Common Patterns
+
+| Pattern              | Correct                                                                          | Incorrect                                                  | Why                                                                                |
+| -------------------- | -------------------------------------------------------------------------------- | ---------------------------------------------------------- | ---------------------------------------------------------------------------------- |
+| Choosing a preset    | `protocol: 'modern'`                                                             | `protocol: { sse: true, streamable: true, legacy: false }` | Use a preset when it matches your needs; custom config is for overrides only       |
+| Serverless transport | `protocol: 'stateless-api'` with `sessionMode: 'stateless'`                      | `protocol: 'legacy'` on Lambda                             | Legacy preset creates sessions that serverless cannot maintain between invocations |
+| Distributed sessions | `distributedMode: true` with Redis `persistence` configured                      | `distributedMode: true` without Redis                      | Distributed mode requires Redis; omitting it causes a startup error                |
+| Event store provider | `provider: 'redis'` for multi-instance, `provider: 'memory'` for single instance | `provider: 'memory'` behind a load balancer                | In-memory event store is not shared across instances, breaking SSE resumability    |
+| Session TTL          | Set `defaultTtlMs` to match your expected session duration                       | Omitting `defaultTtlMs` when using Redis persistence       | Missing TTL can cause sessions to accumulate indefinitely in Redis                 |
+
+## Verification Checklist
+
+### Transport Protocol
+
+- [ ] Correct preset is chosen for the deployment target (see Target-Specific Recommendations table)
+- [ ] Custom protocol flags, if used, do not conflict with the selected `sessionMode`
+- [ ] Legacy SSE is disabled when all clients support modern MCP protocol
+
+### Session and Persistence
+
+- [ ] `sessionMode` is `'stateless'` for serverless deployments
+- [ ] `distributedMode` is enabled and Redis is configured for multi-instance deployments
+- [ ] `defaultTtlMs` is set to a reasonable value when persistence is enabled
+
+### Event Store
+
+- [ ] Event store provider matches the deployment topology (memory for single, Redis for distributed)
+- [ ] `maxEvents` and `ttlMs` are tuned for expected traffic volume
+- [ ] Event store is disabled for stateless-api deployments
+
+### Runtime Validation
+
+- [ ] Server starts without transport-related errors
+- [ ] SSE endpoint (`/sse`) responds with `text/event-stream` when SSE is enabled
+- [ ] Streamable HTTP endpoint (`/`) accepts JSON-RPC POST requests when streamable is enabled
+- [ ] Clients can reconnect and resume SSE streams when event store is enabled
+
+## Troubleshooting
+
+| Problem                                | Cause                                                                      | Solution                                                                                   |
+| -------------------------------------- | -------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
+| Server rejects SSE connections         | SSE is disabled in the protocol config or preset                           | Switch to `'legacy'`, `'modern'`, or `'full'` preset, or set `sse: true` in custom config  |
+| `distributedMode` startup error        | Redis persistence is not configured                                        | Add a `persistence.redis` block with valid connection details                              |
+| Clients lose state after reconnect     | Event store is disabled or using in-memory provider behind a load balancer | Enable event store with `provider: 'redis'` for distributed deployments                    |
+| Serverless function times out on SSE   | Using a stateful preset on a serverless target                             | Switch to `'stateless-api'` preset and set `sessionMode: 'stateless'`                      |
+| Session not found after server restart | In-memory sessions do not survive restarts                                 | Enable Redis persistence with `distributedMode: true`                                      |
+| Streamable HTTP returns 404            | Streamable HTTP is not enabled in the current preset                       | Use `'modern'`, `'legacy'`, or `'full'` preset, or set `streamable: true` in custom config |
+
+## Reference
+
+- **Docs:** [Runtime Modes and Transport Configuration](https://docs.agentfront.dev/frontmcp/deployment/runtime-modes)
+- **Related skills:** `configure-auth`, `create-plugin`

package/catalog/frontmcp-config/references/setup-redis.md

@@ -0,0 +1,9 @@
+---
+name: setup-redis
+description: Cross-reference to the full Redis configuration guide in frontmcp-setup
+---
+
+# Redis Setup Reference
+
+> This reference is maintained in `frontmcp-setup/references/setup-redis.md`.
+> See that file for the full Redis configuration guide including connection options, Vercel KV setup, Docker Compose examples, and troubleshooting.

package/catalog/frontmcp-config/references/setup-sqlite.md

@@ -0,0 +1,9 @@
+---
+name: setup-sqlite
+description: Cross-reference to the full SQLite configuration guide in frontmcp-setup
+---
+
+# SQLite Setup Reference
+
+> This reference is maintained in `frontmcp-setup/references/setup-sqlite.md`.
+> See that file for the full SQLite configuration guide including WAL mode, encryption, daemon mode, and troubleshooting.

package/catalog/frontmcp-deployment/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: frontmcp-deployment
+description: 'Use when you need to deploy, build for production, containerize, or ship a FrontMCP server. Covers Vercel, Lambda, Cloudflare, Docker, edge runtime, serverless, bundle for CLI, and Node targets. Triggers: deploy, build for production, dockerize, serverless, go live.'
+tags: [router, deployment, node, vercel, lambda, cloudflare, cli, browser, sdk, guide]
+category: deployment
+targets: [all]
+bundle: [recommended, minimal, full]
+priority: 10
+visibility: both
+license: Apache-2.0
+metadata:
+  docs: https://docs.agentfront.dev/frontmcp/deployment/overview
+---
+
+# FrontMCP Deployment Router
+
+Entry point for deploying and building FrontMCP servers. This skill helps you choose the right deployment target or build format based on your infrastructure requirements.
+
+## When to Use This Skill
+
+### Must Use
+
+- Choosing between deployment targets (Node vs Vercel vs Lambda vs Cloudflare) for a new project
+- Deciding on a build format (server vs CLI vs browser vs SDK) for distribution
+- Planning infrastructure and need to understand trade-offs between deployment options
+
+### Recommended
+
+- Comparing serverless platforms for cost, cold-start, and feature support
+- Understanding which transport protocol and storage provider each target requires
+- Migrating from one deployment target to another
+
+### Skip When
+
+- You already know your deployment target (go directly to `deploy-to-node`, `deploy-to-vercel`, etc.)
+- You need to configure server settings, not deploy (see `frontmcp-config`)
+- You need to build components, not ship them (see `frontmcp-development`)
+
+> **Decision:** Use this skill when you need to figure out WHERE to deploy. Use the specific skill when you already know.
+
+## Prerequisites
+
+- A working FrontMCP server with at least one `@App` and one `@Tool` (see `frontmcp-development`)
+- Server configuration completed (see `frontmcp-config`)
+- Tests passing locally (see `frontmcp-testing`)
+
+## Steps
+
+1. Review the Scenario Routing Table and Target Comparison below to choose a deployment target
+2. Run `frontmcp build --target <target>` to produce the build output
+3. Follow the specific deployment skill (e.g., `deploy-to-node`, `deploy-to-vercel`) for platform instructions
+4. Verify with the Post-Deployment checklist at the end of this skill
+
+## Scenario Routing Table
+
+| Scenario                                          | Skill                       | Description                                                             |
+| ------------------------------------------------- | --------------------------- | ----------------------------------------------------------------------- |
+| Long-running server on VPS, Docker, or bare metal | `deploy-to-node`            | Node.js with stdio or HTTP transport, PM2/Docker for process management |
+| Serverless with zero config and Vercel KV         | `deploy-to-vercel`          | Vercel Functions with Streamable HTTP, Vercel KV for storage            |
+| AWS serverless with API Gateway                   | `deploy-to-lambda`          | Lambda + API Gateway with Streamable HTTP, DynamoDB or ElastiCache      |
+| Edge computing with global distribution           | `deploy-to-cloudflare`      | Cloudflare Workers with KV or Durable Objects for storage               |
+| Standalone executable binary for distribution     | `build-for-cli`             | Single-binary CLI with stdio transport, embedded storage                |
+| Run MCP in a web browser                          | `build-for-browser`         | Browser-compatible bundle with in-memory transport                      |
+| Embed MCP into an existing Node.js application    | `build-for-sdk`             | Library build for programmatic usage without standalone server          |
+| Write a Dockerfile for Node.js deployment         | `deploy-to-node-dockerfile` | Dockerfile configuration for Node.js deployment                         |
+| Configure Vercel-specific settings (vercel.json)  | `deploy-to-vercel-config`   | Vercel-specific configuration (vercel.json)                             |
+
+### CLI Commands for Deployment and Operations
+
+Beyond `frontmcp build`, the CLI provides commands for the full deployment lifecycle:
+
+| Command                      | Description                                                                         |
+| ---------------------------- | ----------------------------------------------------------------------------------- |
+| `frontmcp build -t <target>` | Build for target: `node`, `vercel`, `lambda`, `cloudflare`, `cli`, `browser`, `sdk` |
+| `frontmcp build -t cli --js` | Build CLI as JS bundle (instead of native binary via SEA)                           |
+| `frontmcp start <name>`      | Start a named MCP server with supervisor (process management)                       |
+| `frontmcp stop <name>`       | Stop managed server (`-f` for force kill)                                           |
+| `frontmcp restart <name>`    | Restart managed server                                                              |
+| `frontmcp status [name]`     | Show process status (detail if name given, table if omitted)                        |
+| `frontmcp list`              | List all managed processes                                                          |
+| `frontmcp logs <name>`       | Tail log output (`-F` follow, `-n` lines)                                           |
+| `frontmcp socket <entry>`    | Start Unix socket daemon for local MCP server                                       |
+| `frontmcp service <action>`  | Install/uninstall systemd (Linux) or launchd (macOS) service                        |
+| `frontmcp install <source>`  | Install MCP app from npm, local path, or git                                        |
+| `frontmcp uninstall <name>`  | Remove installed MCP app                                                            |
+| `frontmcp configure <name>`  | Re-run setup questionnaire for installed app                                        |
+| `frontmcp doctor`            | Check Node.js/npm versions and tsconfig requirements                                |
+| `frontmcp inspector`         | Launch MCP Inspector for debugging                                                  |
+| `frontmcp init`              | Create or fix tsconfig.json for FrontMCP                                            |
+
+## Target Comparison
+
+| Target     | Transport                   | Storage               | Cold Start | Stateful | Best For                         |
+| ---------- | --------------------------- | --------------------- | ---------- | -------- | -------------------------------- |
+| Node       | stdio, SSE, Streamable HTTP | Redis, SQLite, memory | None       | Yes      | Full-featured production servers |
+| Vercel     | Streamable HTTP (stateless) | Vercel KV             | ~250ms     | No       | Rapid deployment, hobby/startup  |
+| Lambda     | Streamable HTTP (stateless) | DynamoDB, ElastiCache | ~500ms     | No       | AWS ecosystem, event-driven      |
+| Cloudflare | Streamable HTTP (stateless) | KV, Durable Objects   | ~5ms       | Limited  | Edge-first, global latency       |
+| CLI        | stdio                       | SQLite, memory        | None       | Yes      | Desktop tools, local agents      |
+| Browser    | In-memory                   | memory                | None       | Yes      | Client-side AI, demos            |
+| SDK        | Programmatic                | Configurable          | None       | Yes      | Embedding in existing apps       |
+
+> **Note on storage:** The FrontMCP SDK's `StorageProvider` type supports `'redis'` and `'vercel-kv'` as built-in providers. References to DynamoDB, Cloudflare KV, D1, and Durable Objects in the table above refer to platform-native storage that you configure outside the SDK (e.g., via AWS SDK, Cloudflare bindings). The SDK does not provide a built-in adapter for these — use them directly in your tools/providers.
+
+## Cross-Cutting Patterns
+
+| Pattern               | Rule                                                                                                     |
+| --------------------- | -------------------------------------------------------------------------------------------------------- |
+| Transport selection   | Stateful servers (Node, CLI) can use stdio or SSE; serverless must use Streamable HTTP (stateless)       |
+| Storage mapping       | Node: Redis or SQLite; Vercel: Vercel KV; Lambda: DynamoDB; Cloudflare: KV; CLI: SQLite; Browser: memory |
+| Environment variables | Never hardcode secrets; use `.env` locally, platform secrets in production                               |
+| Build command         | All targets: `frontmcp build --target <target>` produces optimized output                                |
+| Entry point           | All targets require `export default` of the `@FrontMcp` class from `main.ts`                             |
+
+## Common Patterns
+
+| Pattern            | Correct                                                 | Incorrect                   | Why                                                                          |
+| ------------------ | ------------------------------------------------------- | --------------------------- | ---------------------------------------------------------------------------- |
+| Target selection   | Choose based on infrastructure constraints              | Choose based on familiarity | Each target has different transport, storage, and cold-start characteristics |
+| Serverless storage | Use platform-native storage (Vercel KV, DynamoDB)       | Use Redis on serverless     | Platform-native storage avoids VPC/connection overhead on cold starts        |
+| Environment config | Platform secrets (Vercel env, AWS SSM)                  | `.env` files in production  | Platform secrets are encrypted, rotatable, and not committed to git          |
+| Build verification | Run `frontmcp build --target <target>` before deploying | Deploy source code directly | Build step validates config, bundles dependencies, and optimizes output      |
+
+## Verification Checklist
+
+### Pre-Deployment
+
+- [ ] `frontmcp build --target <target>` completes without errors
+- [ ] Environment variables configured for the target platform
+- [ ] Storage provider configured and accessible (Redis, KV, DynamoDB, etc.)
+- [ ] Transport protocol matches target requirements (stateless for serverless)
+
+### Post-Deployment
+
+- [ ] Health check endpoint responds
+- [ ] `tools/list` returns expected tools
+- [ ] Tool execution works end-to-end
+- [ ] Storage persistence verified (create, read, restart, read again)
+
+## Troubleshooting
+
+| Problem                            | Cause                                        | Solution                                                                        |
+| ---------------------------------- | -------------------------------------------- | ------------------------------------------------------------------------------- |
+| Cold start timeout on serverless   | Bundle too large or heavy initialization     | Lazy-load providers; reduce bundle with tree shaking; increase function timeout |
+| Session lost between requests      | Using memory storage on stateless serverless | Switch to platform-native storage (Vercel KV, DynamoDB, etc.)                   |
+| CORS errors on browser/web clients | HTTP CORS not configured                     | Add CORS config via `configure-http` skill                                      |
+| Build fails with missing module    | Node-only module in browser/edge build       | Use conditional imports or `@frontmcp/utils` cross-platform utilities           |
+
+## Reference
+
+- [Deployment Overview](https://docs.agentfront.dev/frontmcp/deployment/overview)
+- Related skills: `deploy-to-node`, `deploy-to-vercel`, `deploy-to-lambda`, `deploy-to-cloudflare`, `build-for-cli`, `build-for-browser`, `build-for-sdk`, `configure-transport`