Skip to main content
Apps are the organizational units for capabilities in FrontMCP. Each app groups related tools, resources, and prompts into a cohesive domain, along with providers, adapters, and plugins that support them.

​
Why Apps?

In FrontMCP, apps provide domain boundaries and enable multi-tenant architectures:
AspectAppServerTool
PurposeGroup capabilitiesHost appsExecute actions
ScopeFeature/domain boundaryProcess entry pointSingle operation
ContainsTools, resources, promptsApps, global providersInput → Output logic
Apps are ideal for:
  • Feature domains — billing, users, analytics as separate concerns
  • Team boundaries — each team owns their app
  • Multi-tenant — isolate per customer with splitByApp: true
  • Third-party integrations — wrap OpenAPI adapters per service

​
Minimal App

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

@App({
  id: 'hello',
  name: 'Hello App',
  tools: [],
})
export default class HelloApp {}
Add it to your server: 
@FrontMcp({ info: { name: 'Demo', version: '0.1.0' }, apps: [HelloApp] })
export default class Server {}

​
App options

@App({
  id?: string,
  name: string,
  description?: string,
  providers?: ProviderType[],
  authProviders?: AuthProviderType[],
  plugins?: PluginType[],
  adapters?: AdapterType[],
  tools?: ToolType[],
  resources?: ResourceType[],
  prompts?: PromptType[],
  auth?: AuthOptions,                 // app‑default auth (overrides server auth)
  standalone?: 'includeInParent' | boolean, // isolate scope / expose separately
})
Field descriptions:
FieldDescription
idUnique identifier; used in URLs when splitByApp: true
nameHuman-readable display name
descriptionOptional description for documentation
providersDI providers scoped to this app
authProvidersAuthentication providers for this app
pluginsPlugins attached at app scope
adaptersAdapters (e.g., OpenAPI) that generate tools/resources
toolsTool classes registered to this app
resourcesResource classes registered to this app
promptsPrompt classes registered to this app
authApp-level auth config (overrides server auth)
standaloneIsolation mode: true, false, or 'includeInParent'
Scoping & auth
  • If the server uses splitByApp: true, each app is isolated and must configure its own auth (server-level auth is disallowed).
  • standalone: true makes the app expose its own scope/entry; 'includeInParent' lists it under the parent while keeping isolation.
Dependency resolution
  • Providers resolve tool → app → server.
  • Plugins/adapters attach at app scope; generated items inherit the app’s policies and provenance.

​
Example: app with adapter + providers

@App({
  id: 'billing',
  name: 'Billing',
  providers: [DbProvider, CacheProvider],
  adapters: [
    // e.g. OpenAPI adapter that generates tools/resources from a spec
    BillingOpenApiAdapter,
  ],
})
export default class BillingApp {}

​
Remote Apps (Roadmap)

Coming soon: Connect to remote MCP servers and register them as @App({ remote: true }). This will allow you to encapsulate external MCP servers and forward traffic with authentication, treating them as first-class apps in your FrontMCP server.

​
Best Practices

Do:
  • Use descriptive id values that work as URL segments
  • Group related tools, resources, and prompts in the same app
  • Configure standalone: true when apps need isolated auth
  • Use adapters to generate tools from OpenAPI specs
Don’t:
  • Put unrelated functionality in the same app
  • Mix authentication strategies within a single app
  • Create apps with only one tool (use the server directly)