FrontMCP End-to-End Guides

Complete build walkthroughs and best practices for FrontMCP servers. Each example starts from an empty directory and ends with a deployed, tested server. Every pattern references the specific skill that teaches it.

When to Use This Skill

Must Use

• Starting a new FrontMCP project from scratch and want a complete walkthrough to follow
• Learning FrontMCP architecture by building progressively complex real examples
• Need to see how multiple skills work together in a complete application

Recommended

• Planning a new project and want to see how similar architectures are structured
• Onboarding a team member who learns best from complete working examples
• Reviewing best practices for file organization, naming, and code patterns

Skip When

• You need to learn one specific component type (use the specific reference, e.g., create-tool under frontmcp-development/references/)
• Looking for the right reference for a task (use domain routers: frontmcp-development, frontmcp-deployment, etc.)
• You need CLI/install instructions for the skills system (see frontmcp-skills-usage)

Decision: Use this skill when you want to see how everything fits together. Open individual references under each router's references/ directory when you need focused instruction.

Prerequisites

• Node.js 24+ and npm/yarn installed
• Familiarity with TypeScript and decorators
• frontmcp CLI available globally (npm install -g frontmcp)

Steps

1. Choose an example that matches your project's complexity level (Beginner, Intermediate, Advanced)
2. Work through the Planning Checklist to define your project's scope
3. Follow the example code and architecture, referencing individual skills for deeper guidance
4. Verify your implementation using the Verification Checklist at the end of this skill

Planning Checklist

Before writing any code, answer these questions:

1. What does the server do?

• What tools does it expose? (actions AI clients can call)
• What resources does it expose? (data AI clients can read)
• What prompts does it expose? (conversation templates)

2. How is it organized?

• Single app or multiple apps? (see multi-app-composition)
• Standalone project or Nx monorepo? (see project-structure-standalone, project-structure-nx)

3. How is it secured?

• Public (no auth), transparent (passthrough), local (self-contained), or remote (OAuth)? (see configure-auth)
• What session storage? Memory (dev), Redis (prod), Vercel KV (serverless)? (see configure-session)

4. Where does it deploy?

• Node, Vercel, Lambda, Cloudflare, CLI, browser, or SDK? (see frontmcp-deployment)
• What transport? stdio (local), SSE (streaming), Streamable HTTP (stateless)? (see configure-transport)

5. How is it tested?

• Unit tests for each component (see setup-testing)
• E2E tests for protocol-level flows
• Coverage target: 95%+

---

Example 1: Weather API (Beginner)

Skills used: setup-project, create-tool, create-resource, setup-testing, deploy-to-node

A simple MCP server that exposes a weather lookup tool and a resource for supported cities.

Architecture

weather-api/
├── src/
│   ├── main.ts              # @FrontMcp server (deploy-to-node)
│   ├── weather.app.ts       # @App with tools and resources
│   ├── tools/
│   │   └── get-weather.tool.ts    # @Tool: fetch weather by city (create-tool)
│   └── resources/
│       └── cities.resource.ts     # @Resource: list supported cities (create-resource)
├── test/
│   ├── get-weather.tool.spec.ts   # Unit tests (setup-testing)
│   └── weather.e2e.spec.ts        # E2E protocol test (setup-testing)
└── package.json

Key Code

Server entry point (setup-project):

import { FrontMcp } from '@frontmcp/sdk';

import { WeatherApp } from './weather.app';

@FrontMcp({
  info: { name: 'weather-api', version: '1.0.0' },
  apps: [WeatherApp],
})
export default class WeatherServer {}

Tool (create-tool):

import { Tool, ToolContext, z } from '@frontmcp/sdk';

@Tool({
  name: 'get_weather',
  description: 'Get current weather for a city',
  inputSchema: {
    city: z.string().min(1).describe('City name'),
  },
  outputSchema: {
    temperature: z.number(),
    condition: z.string(),
    humidity: z.number(),
  },
})
export class GetWeatherTool extends ToolContext {
  async execute(input: { city: string }) {
    const city = encodeURIComponent(input.city);
    const data = await this.fetch(`https://api.weather.example.com/v1?city=${city}`);
    const json = await data.json();
    return { temperature: json.temp, condition: json.condition, humidity: json.humidity };
  }
}

Resource (create-resource):

import { ReadResourceResult, Resource, ResourceContext } from '@frontmcp/sdk';

@Resource({
  uri: 'weather://cities',
  name: 'Supported Cities',
  description: 'List of cities with weather data',
  mimeType: 'application/json',
})
export class CitiesResource extends ResourceContext {
  async execute(uri: string): Promise<ReadResourceResult> {
    return {
      contents: [
        {
          uri,
          mimeType: 'application/json',
          text: JSON.stringify(['London', 'Tokyo', 'New York', 'Paris', 'Sydney']),
        },
      ],
    };
  }
}

Full working code: See references/example-weather-api.md

---

Example 2: Task Manager (Intermediate)

Skills used: setup-project, create-tool, create-provider, configure-auth, configure-session, setup-redis, setup-testing, deploy-to-vercel

An authenticated task management server with CRUD tools, Redis storage, and OAuth.

Architecture

task-manager/
├── src/
│   ├── main.ts                    # @FrontMcp with auth: { mode: 'remote' }
│   ├── tasks.app.ts               # @App with CRUD tools + provider
│   ├── providers/
│   │   └── task-store.provider.ts # @Provider: Redis-backed task storage (create-provider)
│   ├── tools/
│   │   ├── create-task.tool.ts    # @Tool: create a task (create-tool)
│   │   ├── list-tasks.tool.ts     # @Tool: list tasks (create-tool)
│   │   ├── update-task.tool.ts    # @Tool: update task status (create-tool)
│   │   └── delete-task.tool.ts    # @Tool: delete a task (create-tool)
│   └── types/
│       └── task.ts                # Shared task interface
├── test/
│   ├── *.spec.ts                  # Unit tests per tool
│   └── tasks.e2e.spec.ts          # E2E with auth flow
├── vercel.json                    # Vercel config (deploy-to-vercel)
└── package.json

Key Code

Server with auth (configure-auth, configure-session, setup-redis):

@FrontMcp({
  info: { name: 'task-manager', version: '1.0.0' },
  apps: [TasksApp],
  auth: { mode: 'remote', provider: 'https://auth.example.com', clientId: 'my-client-id' },
  redis: { provider: 'redis', host: process.env.REDIS_URL ?? 'localhost' },
})
export default class TaskManagerServer {}

Provider for shared storage (create-provider):

import { Provider, ProviderScope } from '@frontmcp/sdk';

@Provider({ name: 'task-store', scope: ProviderScope.GLOBAL })
export class TaskStoreProvider {
  async create(task: Task): Promise<Task> {
    /* Redis-backed implementation */
  }
  async list(userId: string): Promise<Task[]> {
    /* ... */
  }
  async update(id: string, data: Partial<Task>): Promise<Task> {
    /* ... */
  }
  async delete(id: string): Promise<void> {
    /* ... */
  }
}

Use the class itself as the DI token (this.get(TaskStoreProvider)). For factory-built singletons (e.g. when you need async setup before the class is constructed), use AsyncProvider({ provide, name, scope, useFactory }) instead.

Tool with DI (create-tool + create-provider):

import { Tool, ToolContext, UnauthorizedError, z } from '@frontmcp/sdk';

@Tool({
  name: 'create_task',
  description: 'Create a new task',
  inputSchema: {
    title: z.string().min(1).describe('Task title'),
    priority: z.enum(['low', 'medium', 'high']).default('medium'),
  },
  outputSchema: { id: z.string(), title: z.string(), priority: z.string(), status: z.string() },
})
export class CreateTaskTool extends ToolContext {
  async execute(input: { title: string; priority: string }) {
    const store = this.get(TaskStoreProvider);
    const userId = this.auth?.user.sub;
    if (!userId) this.fail(new UnauthorizedError('Authentication required'));
    return store.create({ title: input.title, priority: input.priority, status: 'pending', userId });
  }
}

Full working code: See references/example-task-manager.md

---

Example 3: Knowledge Base (Advanced)

Skills used: setup-project, multi-app-composition, create-tool, create-resource, create-agent, create-skill-with-tools, create-plugin, official-plugins, configure-auth, deploy-to-vercel

A multi-app knowledge base with AI-powered search, document ingestion, and an autonomous research agent.

Architecture

knowledge-base/
├── src/
│   ├── main.ts                          # @FrontMcp composing 3 apps
│   ├── ingestion/
│   │   ├── ingestion.app.ts             # @App: document ingestion
│   │   ├── tools/ingest-document.tool.ts
│   │   └── providers/vector-store.provider.ts
│   ├── search/
│   │   ├── search.app.ts               # @App: search and retrieval
│   │   ├── tools/search-docs.tool.ts
│   │   └── resources/doc.resource.ts
│   ├── research/
│   │   ├── research.app.ts             # @App: AI research agent
│   │   └── agents/researcher.agent.ts  # @Agent: autonomous research loop
│   └── plugins/
│       └── audit-log.plugin.ts         # @Plugin: audit logging
├── test/
│   └── *.spec.ts
├── vercel.json
└── package.json

Key Code

Multi-app composition (multi-app-composition):

@FrontMcp({
  info: { name: 'knowledge-base', version: '1.0.0' },
  apps: [IngestionApp, SearchApp, ResearchApp],
  plugins: [AuditLogPlugin],
  auth: { mode: 'remote', provider: 'https://auth.example.com', clientId: 'my-client-id' },
  redis: { provider: 'redis', host: process.env.REDIS_URL ?? 'localhost' },
})
export default class KnowledgeBaseServer {}

AI Research Agent (create-agent):

@Agent({
  name: 'research_topic',
  description: 'Research a topic across the knowledge base and synthesize findings',
  inputSchema: {
    topic: z.string().describe('Research topic'),
    depth: z.enum(['shallow', 'deep']).default('shallow'),
  },
  llm: {
    provider: 'anthropic',
    model: 'claude-sonnet-4-6',
    apiKey: { env: 'ANTHROPIC_API_KEY' },
    maxTokens: 4096,
  }, // provider and model are client-configurable
  execution: { maxIterations: 5 },
  systemInstructions:
    'Search for relevant documents using search_docs, synthesize findings, and produce a structured summary with source attribution.',
  tools: [SearchDocsTool, IngestDocumentTool],
})
export class ResearcherAgent extends AgentContext {}

The framework drives the LLM tool-use loop via the agents:call-agent flow — you don't override execute(). Configure iteration limits and other runtime knobs through the @Agent({ execution: { maxIterations } }) block.

Full working code: See references/example-knowledge-base.md

---

Best Practices

Planning

Practice	Why	Reference
Start with the @App boundaries, not individual tools	Apps define module boundaries; tools are implementation details	multi-app-composition
Choose auth mode and storage before writing tools	Auth affects session handling, which affects storage requirements	configure-auth, configure-session
Pick your deployment target early	Target determines transport, storage, and build constraints	frontmcp-deployment

Organizing Code

Practice	Why	Reference
One class per file with <name>.<type>.ts naming	Consistency, generator compatibility, clear imports	project-structure-standalone
Group by feature, not by type, for 10+ components	Feature folders scale better than flat tools/ directories	project-structure-standalone
Extract shared logic into @Provider classes	Testable, lifecycle-managed, injected via DI	create-provider

Writing Code

Practice	Why	Reference
Always define outputSchema on tools	Prevents data leaks, enables CodeCall chaining	create-tool
Use this.fail() with MCP error classes	Proper error codes in protocol responses	create-tool
Use this.get(TOKEN) not this.tryGet(TOKEN)!	Clear error on missing dependency vs silent null	create-provider
Use Zod raw shapes, not z.object()	Framework wraps internally; double-wrapping breaks validation	create-tool

Common Patterns

Pattern	Correct	Incorrect	Why
Project start	Plan apps and auth first, then build tools	Jump straight into writing tools	Architecture decisions are expensive to change later
Code organization	Feature folders with <name>.<type>.ts	Flat directory with generic names	Scales to large projects and matches generator output
Shared state	@Provider with DI token	Module-level singleton or global variable	DI is testable, lifecycle-managed, and scoped per request
Error handling	this.fail(new ResourceNotFoundError(...))	throw new Error('not found')	MCP error codes enable proper client error handling
Testing	Unit tests per component + E2E for protocol	Only E2E tests or only unit tests	Both layers catch different types of bugs

Verification Checklist

Architecture

• Apps define clear module boundaries with no circular imports
• Shared logic extracted into providers, not duplicated across tools
• Auth mode and storage chosen before writing tools

Code Quality

• All tools have outputSchema defined
• All files follow <name>.<type>.ts naming convention
• All test files use .spec.ts extension
• Coverage at 95%+ across all metrics

Production Readiness

• Secrets stored in environment variables, not source code
• Session storage uses Redis/KV in production (not memory)
• Rate limiting configured for public-facing tools
• E2E tests exercise the full protocol flow

Troubleshooting

Problem	Cause	Solution
Unsure where to start	No project plan	Run through the Planning Checklist above before writing code
Architecture feels wrong	Wrong app boundaries or component types	Review the Scenario Routing Table in frontmcp-development
Feature works locally but fails deployed	Environment-specific config (storage, auth, transport)	Check the Target Comparison in frontmcp-deployment
Tests pass but coverage below 95%	Missing error path or branch tests	Run jest --coverage and add tests for uncovered lines
Provider state leaking between requests	Using module-level state instead of DI	Move state into a @Provider scoped per request

Examples

Each reference has matching examples under examples/<reference>/:

example-knowledge-base

Example	Level	Description
agent-and-plugin	Advanced	Shows an autonomous research agent with inner tools and configurable depth, and a plugin that hooks into tool execution for audit logging.
multi-app-composition	Basic	Shows how to compose multiple apps (Ingestion, Search, Research) into a single server with shared providers, plugins, and agent registration.
vector-search-and-resources	Intermediate	Shows a semantic search tool with embedding generation and a resource template for retrieving documents by ID using URI parameters.

example-task-manager

Example	Level	Description
auth-and-crud-tools	Basic	Shows how to create CRUD tools with authentication, using this.context.session for user isolation and this.get() for dependency injection.
authenticated-e2e-tests	Advanced	Shows how to write E2E tests with authentication using TestTokenFactory, and unit tests for tools that require session context.
redis-provider-with-di	Intermediate	Shows how to create a Redis-backed provider with a DI token, lifecycle hooks (onInit/onDestroy), and how tools inject it.

example-weather-api

Example	Level	Description
server-and-app-setup	Basic	Shows the server entry point, app registration, and static resource for a beginner FrontMCP weather API server.
unit-and-e2e-tests	Intermediate	Shows how to write unit tests for tools by mocking context methods, and E2E tests using McpTestClient and TestServer.
weather-tool-with-schemas	Basic	Shows how to create a tool with Zod input and output schemas, use this.fetch() for HTTP calls, and handle errors with this.fail().

Accessing This Skill

Skills are distributed as plain SKILL.md files plus a sibling references/ and examples/ tree, so consumers can pick whichever access mode fits:

Mode	How it works
Filesystem	Read libs/skills/catalog/frontmcp-guides/ directly from a clone of the catalog repo, or from a published @frontmcp/skills install. SKILL.md is the entry point.
frontmcp CLI	frontmcp skills list, frontmcp skills read frontmcp-guides, frontmcp skills read frontmcp-guides:references/<file>.md, frontmcp skills install frontmcp-guides — no server required.
MCP skill://	When a developer mounts this skill into their own FrontMCP server (@FrontMcp({ skills: [...] })), the SDK exposes it via SEP-2640 resources: skill://frontmcp-guides/SKILL.md, skill://frontmcp-guides/references/{file}.md, etc. The server’s skill://index.json returns the SEP-2640 discovery document for everything mounted on it.

The catalog itself is not an MCP server. The skill:// URIs only resolve when a server has been configured to host this skill.

Reference

• Your First Tool
• Domain routers: frontmcp-development, frontmcp-deployment, frontmcp-testing, frontmcp-config
• Core references: setup-project, create-tool, create-resource, create-provider, create-agent, configure-auth, setup-testing (each lives under its parent router's references/ directory, e.g. frontmcp-development/references/create-tool.md)
• Mandatory boundaries: import MCP protocol types and McpError from @frontmcp/protocol (never directly from @modelcontextprotocol/sdk); use @frontmcp/utils for crypto and file-system operations.