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.Documentation Index
Fetch the complete documentation index at: https://docs.agentfront.dev/llms.txt
Use this file to discover all available pages before exploring further.
Why Apps?
In FrontMCP, apps provide domain boundaries and enable multi-tenant architectures:| Aspect | App | Server | Tool |
|---|---|---|---|
| Purpose | Group capabilities | Host apps | Execute actions |
| Scope | Feature/domain boundary | Process entry point | Single operation |
| Contains | Tools, resources, prompts | Apps, global providers | Input → Output logic |
- 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
App options
| Field | Description |
|---|---|
id | Unique identifier; used in URLs when splitByApp: true |
name | Human-readable display name |
description | Optional description for documentation |
providers | DI providers scoped to this app |
authProviders | Authentication providers for this app |
plugins | Plugins attached at app scope |
adapters | Adapters (e.g., OpenAPI) that generate tools/resources |
tools | Tool classes registered to this app |
resources | Resource classes registered to this app |
prompts | Prompt classes registered to this app |
auth | App-level auth config (overrides server auth) |
standalone | Isolation mode: true, false, or 'includeInParent' |
- If the server uses
splitByApp: true, each app is isolated and must configure its own auth (server-levelauthis disallowed). standalone: truemakes the app expose its own scope/entry;'includeInParent'lists it under the parent while keeping isolation.
- 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
Remote Apps
Connect to external MCP servers and proxy their tools, resources, and prompts through your gateway usingApp.remote():
Remote App Options
App.remote(url, options?) accepts the MCP server URL as the first argument and an optional options object:
| Option | Type | Description |
|---|---|---|
name | string | Override the auto-derived app name (defaults to hostname) |
namespace | string | Prefix for tool/resource/prompt names (e.g., mintlify:SearchMintlify) |
description | string | Human-readable description |
standalone | boolean | 'includeInParent' | Isolation mode (default: false) |
transportOptions | object | Connection settings (timeout, retry attempts) |
remoteAuth | RemoteAuthConfig | Authentication config for the remote server |
refreshInterval | number | Interval (ms) to refresh capabilities from the remote server |
cacheTTL | number | TTL (ms) for cached capabilities |
filter | AppFilterConfig | Include/exclude filter for selectively importing primitives |
Transport Options
Caching Remote Tools
Remote tools don’t have cache metadata, so use thetoolPatterns option in CachePlugin:
Use Cases for Remote Apps
MCP Gateway
Aggregate multiple MCP servers behind a single endpoint with unified authentication
Service Mesh
Connect to internal microservices running as separate MCP servers
Third-Party Integration
Proxy external MCP services like Mintlify, adding caching and rate limiting
Development
Test against local MCP servers running on different ports
ESM Package Apps
Load npm packages at runtime and register their tools, resources, and prompts in-process — no HTTP proxy needed — usingApp.esm():
Unlike Remote Apps which proxy requests to external MCP servers over HTTP, ESM packages are fetched from a CDN, cached locally, and executed in-process. They support two-tier caching, background version polling with hot-reload, and private registry authentication.
App.esm() API, caching, authentication, and auto-update configuration.
Per-Primitive Loading
In addition to loading entire apps, you can load individual primitives (tools, resources, prompts, agents, skills, jobs) from npm packages or remote servers using static methods on each decorator:Best Practices
Do:- Use descriptive
idvalues that work as URL segments - Group related tools, resources, and prompts in the same app
- Configure
standalone: truewhen apps need isolated auth - Use adapters to generate tools from OpenAPI specs
- Put unrelated functionality in the same app
- Mix authentication strategies within a single app
- Create apps with only one tool (use the server directly)
- Use
App.esm()for external MCP servers (useApp.remote()instead)
- Local
@App: First-party code you own and maintain App.esm(): Community or internal packages distributed via npmApp.remote(): External MCP servers running as separate processes