Built-in Plugins and Adapters

Using an official plugin

Each is its own npm package. The plugins are registered like the one you wrote, with SomePlugin.init({ ... }) in the plugins of an @App, for that app's tools, or of @FrontMcp, for every app's, and each adds something your code opts in to. What a plugin adds to this, like this.remember, reaches only the tools of the apps it's registered for:

A few rules hold for all of them:

• Register a plugin with init(). With no argument it's the same as init({}), the defaults, for the plugins whose options all have defaults. Feature flags need an adapter: FeatureFlagPlugin.init() throws a FeatureFlagConfigurationError without it. The bare class, plugins: [SomePlugin], is the same as init() with no argument, so plugins: [FeatureFlagPlugin] stops the server with that error. Before 1.9.4 the bare class worked for the cache plugin only.
• approval and featureFlag need their plugin. A server with a tool that declares one of them, and no plugin to enforce it, refuses to start, so a gate can't be left off by accident. cache and codecall without their plugin do nothing.
• Adapters go in adapters, not in plugins: an app's, for that app, or @FrontMcp's, whose adapter tools every app serves.
• Every package loads in CommonJS and ES module projects alike. Before 1.9, an ES module project ("type": "module") couldn't import the cache and CodeCall plugins: see ES module projects.

Caching results

A lookup the model repeats, like a customer's account from a slow CRM, doesn't need to run twice. With the cache plugin on the app and cache: { ttl } on the tool, the next call with the same arguments is answered from a store, without running execute():

import { App, Tool, ToolContext, z } from "@frontmcp/sdk";
import { CachePlugin } from "@frontmcp/plugin-cache";
import { crm } from "./crm";

@Tool({
  name: "get_customer",
  description: "Get a customer account by its id. May be up to 5 minutes old.",
  inputSchema: { id: z.string().describe("Customer id, like C-1") },
  annotations: { readOnlyHint: true },
  cache: { ttl: 300 }, // seconds
})
export class GetCustomer extends ToolContext {
  async execute({ id }: { id: string }) {
    return crm.getCustomer(id);
  }
}

@App({
  id: "help-desk",
  name: "Help Desk",
  tools: [GetCustomer],
  plugins: [CachePlugin.init({ type: "memory", keyByIdentity: false })], // the same answer for every caller
})
export class HelpDeskApp {}

By default each caller has entries of their own. That keeps one user's answer from reaching another, and it also means an anonymous caller under MCP 2026-07-28, who is new on every request, is never answered from the cache. keyByIdentity: false shares entries, and is only safe for answers that are the same for everyone.

Remembering across calls

A tool forgets everything when its call ends. The Remember plugin gives every tool this.remember, a key-value memory whose scope decides who reads a value back. user scope keeps a value for the caller. The tests call the server in-process with createDirect() as two signed-in agents, and as the Playground's anonymous client, which user scope refuses:

import { App, Tool, ToolContext, z } from "@frontmcp/sdk";
import { RememberPlugin } from "@frontmcp/plugin-remember";

@Tool({ name: "set_signature", description: "Set the signature your replies end with.", inputSchema: { signature: z.string() } })
export class SetSignature extends ToolContext {
  async execute({ signature }: { signature: string }) {
    await this.remember.set("signature", signature, { scope: "user" });
    return { signature };
  }
}

@Tool({ name: "draft_reply", description: "Draft a reply, signed with your signature.", inputSchema: { ticketId: z.string(), text: z.string() } })
export class DraftReply extends ToolContext {
  async execute({ ticketId, text }: { ticketId: string; text: string }) {
    const signature = await this.remember.get("signature", { scope: "user", defaultValue: "The Help Desk" });
    return { ticketId, reply: `${text}\n\n${signature}` };
  }
}

@App({ id: "help-desk", name: "Help Desk", tools: [SetSignature, DraftReply], plugins: [RememberPlugin.init({ type: "memory" })] })
export class HelpDeskApp {}

The other scopes matter as much: global is shared by everyone, and session, the default, doesn't mean a conversation under MCP 2026-07-28. It lasts for the signed-in caller. An anonymous caller can't use user or session: Remember refuses it with REMEMBER_IDENTITY_REQUIRED, and only global works for it.

Asking for approval

destructiveHint tells a client a tool can't be undone, and the client may still run it without asking anyone. The approval plugin refuses every call to a tool with approval until an approval of it is recorded for the caller:

import { App, Tool, ToolContext, z } from "@frontmcp/sdk";
import { ApprovalPlugin } from "@frontmcp/plugin-approval";

export const tickets = new Map([
  ["T-1", { id: "T-1", title: "Cannot log in" }],
  ["T-2", { id: "T-2", title: "Invoice total is wrong" }],
]);

@Tool({
  name: "delete_ticket",
  description: "Delete a support ticket for good. Needs the user's approval: call approve_delete first.",
  inputSchema: { id: z.string().describe("Ticket id, like T-1") },
  annotations: { destructiveHint: true },
  approval: { approvalMessage: "delete_ticket needs the user's approval. Call approve_delete first." },
})
export class DeleteTicket extends ToolContext {
  async execute({ id }: { id: string }) {
    return { id, deleted: tickets.delete(id) };
  }
}

@App({ id: "help-desk", name: "Help Desk", tools: [DeleteTicket], plugins: [ApprovalPlugin.init({ storage: { type: "memory" } })] })
export class HelpDeskApp {}

The plugin doesn't ask anyone itself. Your code records an approval, with this.approval, once the user says yes in a form from this.elicit(), which under MCP 2026-07-28 the model can't answer. An approval belongs to a signed-in caller, so an anonymous caller can never keep one.

Turning features on and off

A feature flag ships a tool to some users before the rest, or turns one off without a deploy. With the feature flags plugin, featureFlag: "bulk-export" on a tool hides it from every list while the flag is off for the caller, and refuses it if it's called anyway. Flags come from an adapter: fixed values, as here, or LaunchDarkly, Split, Unleash or your own. Open the Capabilities tab to see which tools are listed:

import { App, Tool, ToolContext } from "@frontmcp/sdk";
import { FeatureFlagPlugin } from "@frontmcp/plugin-feature-flags";

@Tool({ name: "search_tickets", description: "Search support tickets.", inputSchema: {} })
export class SearchTickets extends ToolContext {
  async execute() {
    return { tickets: ["T-1", "T-3"] };
  }
}

@Tool({ name: "bulk_export", description: "Export every ticket as CSV.", inputSchema: {}, featureFlag: "bulk-export" })
export class BulkExport extends ToolContext {
  async execute() {
    return { csv: "id,title\nT-1,Cannot log in" };
  }
}

@App({
  id: "help-desk",
  name: "Help Desk",
  tools: [SearchTickets, BulkExport],
  plugins: [FeatureFlagPlugin.init({ adapter: "static", flags: { "bulk-export": false } })],
})
export class HelpDeskApp {}

Change "bulk-export": false to true, and bulk_export appears. Each caller's flags are evaluated for them, from their token, so a flag can be on for some users and off for the rest; under MCP 2026-07-28 every anonymous caller gets the same answer.

Letting the model write code with CodeCall

A server with dozens of tools sends every tool's schema to the model before it can pick one. CodeCall puts them behind six meta-tools instead: the model searches with codecall:search, reads the schemas of the tools it picked with codecall:describe, and calls them one at a time with codecall:invoke, or several at once from a short script with codecall:execute:

import { App } from "@frontmcp/sdk";
import { CodeCallPlugin } from "@frontmcp/plugin-codecall";
import { CloseTicket, GetCustomer, GetTicket, SearchTickets } from "./tools";

@App({
  id: "help-desk",
  name: "Help Desk",
  tools: [SearchTickets, GetTicket, CloseTicket, GetCustomer],
  plugins: [CodeCallPlugin.init({ mode: "codecall_only" })],
})
export class HelpDeskApp {}

A script runs on the server, in a sandbox, and can loop over results and join them, so only the answer goes back to the model. This one lists the urgent open tickets with their customers, in one request:

const { tickets } = await callTool("search_tickets", { status: "open" });
const urgent = tickets.filter((t) => t.priority === "high");
const out = [];
for (const t of urgent) {
  const customer = await callTool("get_customer", { id: t.customerId });
  out.push({ ticket: t.id, customer: customer.name });
}
return out;

Here are the tools above again, with codecall:execute called with that script. The Playground runs it in a browser sandbox, where a server uses one built on Node's vm; the answer is the same:

codecall:execute returns { "status": "ok", "result": [{ "ticket": "T-1", "customer": "Acme Corp" }, { "ticket": "T-3", "customer": "Globex" }] }.

Wrapping an OpenAPI service

When what the model needs already exists as a REST API with an OpenAPI description, OpenapiAdapter from @frontmcp/adapters makes a tool of each operation, named by its operationId, which sends the request the spec describes and hands back the API's answer. The Playground can't reach a real API, so desk.example.ts plays it, in-process:

import "./desk.example";
import { App } from "@frontmcp/sdk";
import { OpenapiAdapter } from "@frontmcp/adapters";
import { spec } from "./spec";

@App({
  id: "desk",
  name: "Desk",
  adapters: [OpenapiAdapter.init({ name: "desk", baseUrl: "https://desk.example/v1", spec })],
})
export class DeskApp {}

The model gets the API's answer as it is, and every operation in the spec as a tool, which is a lot of tools for a large API. The adapter's options choose which operations become tools, rename and describe them, send the API's credentials, and reshape what comes back. The adapter goes in an app's adapters, and each one needs a name of its own.

Plugin, adapter or your own code?

Every option of each one is in the plugins and adapters reference.

What's next?

Start the chapter with Caching Results. After it, Testing and Shipping covers proving your server works and getting it into production.