The core FrontMCP server — start with the minimum and scale up with HTTP, sessions, logging, providers, and authentication.
FrontMCP servers are defined with a single decorator, @FrontMcp({ ... }). This page shows the minimal config and then every top-level option you can use. Deep dives live in the pages listed under Servers.
FrontMCP can host many apps. Choose how they’re exposed:
Multi-App (default): splitByApp: false
One server scope. You may configure server-level auth and all apps inherit it (apps can still override with app-level auth).
Split-By-App: splitByApp: true
Each app is isolated under its own scope/base path (for example /billing). Streamable HTTP, the /message SSE endpoint, and OAuth issuers reuse that scope automatically. Server-level auth is disallowed; configure auth per app. (See Authentication → Overview.)
If you’re offering multiple products or tenants, splitByApp: true gives clean separation and per-app auth.
http: { port?: number; // default 3001 entryPath?: string; // default ''; MUST match the PRM resourcePath in .well-known hostFactory?: FrontMcpServer | ((cfg) => FrontMcpServer);}
Field
Description
port
HTTP listening port (default: 3001)
entryPath
JSON-RPC entry path; must match .well-known discovery
hostFactory
Custom host implementation for advanced setups
Port: listening port for Streamable HTTP.
entryPath: your MCP JSON-RPC entry ('' or '/mcp'). Must align with discovery.
hostFactory: advanced — provide/construct a custom host implementation.
Split-by-app scopes: when splitByApp is enabled, clients hit <entryPath>/<appId> (for example /mcp/billing) and subscribe via <entryPath>/<appId>/message; FrontMCP handles the prefixing.
New in v0.6: Transport configuration has moved from auth.transport and session to a dedicated top-level transport property. This separates transport/session lifecycle concerns from authentication. See Migration below.
The transport config controls session lifecycle, protocol switches, and session persistence. Configure it at the server level or per-app when using splitByApp: true.
Choose which MCP transports to enable based on your deployment:
Option
Default
When to enable
Notes
enableStreamableHttp
true
Modern MCP clients (Claude Desktop, Cursor, Rendezvous)
Primary transport; streams JSON-RPC over HTTP.
enableStatefulHttp
false
Local previews, OAuth consent screens, Jest suites
JSON-only endpoint for requests without SSE—handy for testing and health checks.
enableStatelessHttp
false
Public mode or CI agents that cannot run initialize
Singleton transports that skip initialization handshake.
enableSseListener
true
Manual SSE subscribers or dashboards
Controls GET /message endpoint. Disable to reduce long-lived sockets.
enableLegacySSE
false
Supporting pre-Streamable clients temporarily
Legacy HTTP + SSE combo—plan to remove once clients upgrade.
requireSessionForStreamable
true
Public demos or scripted tests
Set false to let Streamable HTTP requests bootstrap themselves.
Leave enableStatelessHttp off in production unless you fully trust the client surface. Stateless transports reuse process-wide connections, which is perfect for CI but can bypass fine-grained session teardown.
Session persistence uses the top-level redis config. Configure redis once and reference it from both transport.persistence and auth.tokenStorage.
You can apply different transport policies per app when splitByApp: true. Sensitive apps stay stream-only with strict session IDs, while demo or health-check apps can enable stateful/stateless HTTP for easier automation.
Apps can also define their own auth (and mark themselves standalone) to expose an isolated auth surface — useful
when mixing public and private apps under one server.