@frontmcp/sdk reference

import { App, FrontMcp, Tool, ToolContext, z } from "@frontmcp/sdk";

Decorators

Decorators declare what your server exposes.

Context

Inside execute(), this is the call's context. Context classes lists what this is in a tool, resource, prompt, agent, job, channel or skill, and every member each one has. The members used most have pages of their own:

Running a server

Importing a class decorated with @FrontMcp starts FrontMCP's HTTP server. These run the same configuration in other ways:

Limits, errors and the scope

z, eagerZ and lazyZ

Every example on this site imports z from @frontmcp/sdk, not from zod. It's Zod 4's z with one change: z.object(), z.strictObject(), z.looseObject(), z.union(), z.discriminatedUnion(), z.intersection(), z.record() and z.tuple() return a stand-in, and the real Zod schema is built the first time the schema is used, by a parse or by reading it, like .shape. Methods you chain on a stand-in, like .optional() and .describe(), return stand-ins too. So loading and starting a server doesn't build the objects in its tools' inputSchema: they're built when a client first lists the tools or calls one. The other factories, like z.string() and z.enum(), are Zod's own.

A stand-in behaves like the schema it stands for: it parses, instanceof ZodObject is true, and z.infer gives the same type. The SDK exports Zod's classes, like ZodObject and ZodError, and its types, so a FrontMCP server needs no import from zod. Two things to know:

• Zod's own toJSONSchema() fails on some z schemas. z.toJSONSchema(), or the function imported from zod, throws TypeError: Cannot set properties of undefined (setting 'ref') when an object or a union in the schema is .optional() or has a .default(), like the optional customer below. Convert with toJSONSchema from @frontmcp/sdk, or build that schema with eagerZ.
• Schemas from zod work in a tool's inputSchema like the SDK's, as long as they're Zod 4: frontmcp create adds zod ^4.0.0 to a new project. Schemas from Zod 3, zod@3 or zod/v3, aren't recognized: the tool is listed with no properties, and every call fails with INVALID_INPUT and Unknown error occurred when trying to parse input.

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

export const TicketInput = {
  title: z.string().min(5).describe("One-line summary of the problem"),
  customer: z.object({ email: z.string().email() }).optional().describe("Who reported it, if known"),
};

@Tool({ name: "create_ticket", description: "Open a new support ticket", inputSchema: TicketInput })
export class CreateTicket extends ToolContext {
  async execute(input: { title: string; customer?: { email: string } }) {
    return { id: "T-4", status: "open", ...input };
  }
}

Which page for which task

The three groups in one server

A decorator for each part of the server, context members inside the tool, and the Tests tab running the same app through a second entry point, createDirect(), in-process and as a named user:

import { App, Provider, PublicMcpError, Tool, ToolContext, z } from "@frontmcp/sdk";

@Provider({ name: "TicketStore" })
export class TicketStore {
  private tickets = [
    { id: "T-1", title: "Cannot log in", status: "open" },
    { id: "T-2", title: "Invoice total is wrong", status: "closed" },
  ];
  find(id: string) {
    return this.tickets.find((t) => t.id === id);
  }
}

@Tool({
  name: "get_ticket",
  description: "Get one support ticket by its id",
  inputSchema: { id: z.string().describe("Ticket id, like T-1") },
})
export class GetTicket extends ToolContext {
  async execute({ id }: { id: string }) {
    const ticket = this.get(TicketStore).find(id); // a provider
    if (!ticket) this.fail(new PublicMcpError(`There's no ticket ${id}.`, "NOT_FOUND")); // an error the model reads
    return { ticket, caller: this.auth.user.sub }; // who is calling
  }
}

@App({ id: "help-desk", name: "Help Desk", tools: [GetTicket], providers: [TicketStore] })
export class HelpDeskApp {}

Related pages

• Server configuration: apps, configuration files, logging, observability and flows, across decorators.
• Authentication and authorization: the auth and authorities options, and what fills in this.auth.
• Plugins and adapters: the official plugins and the OpenAPI adapter.
• @frontmcp/testing: end-to-end tests that call a server like a client.
• Learn: Describing Capabilities, Structuring a Server and Running FrontMCP Anywhere.