FrontMcpInstance is the main entry point for creating and managing FrontMCP servers. It provides multiple factory methods for different deployment scenarios.
import { FrontMcpInstance } from '@frontmcp/sdk';import config from './server';await FrontMcpInstance.bootstrap(config);// Server running on configured port
Best for: Claude Desktop, Claude Code, Cursor, and other stdio MCP clients.Accepts either a @FrontMcp-decorated class or the same config object you pass to @FrontMcp().
// stdio.ts — config kept in its own module (no @FrontMcp decorator imported here)import { FrontMcpInstance } from '@frontmcp/sdk';import { serverConfig } from './server-config';await FrontMcpInstance.runStdio(serverConfig);// Never returns until the connection closes
Importing a @FrontMcp-decorated class starts an HTTP server at import time
unless FRONTMCP_STDIO=1 is set before the import. For a hand-written stdio
entry, keep the config object in its own module (as above) so no decorated class
is evaluated. For built servers, use the --stdio runner (./dist/node/<name> --stdio) or a --target cli binary (<bin> --stdio) — both set the flag for
you, so the decorated server connects over stdio and binds no port.
// src/server-config.ts — a plain object; do NOT add @FrontMcp hereexport const serverConfig = { info: { name: 'my-server', version: '1.0.0' }, apps: [MyApp],};
// src/stdio.ts — imports only the config, so nothing auto-starts an HTTP serverimport { FrontMcpInstance } from '@frontmcp/sdk';import { serverConfig } from './server-config';await FrontMcpInstance.runStdio(serverConfig);
Keep serverConfig separate from your @FrontMcp-decorated main.ts. The
decorator starts an HTTP server when its module is imported, so a stdio entry
that imports the decorated class would bind a port alongside stdio. Importing
just the config object avoids that.