Basic Usage
providers are private to the plugin: its own tools, hooks and nested plugins resolve them. List a provider in exports as well so the tools of the app that installs the plugin can call this.get(CacheService). A decorated class is its own DI token.
Signature
Configuration Options
Required Properties
Optional Properties
Components
Extensions
Context Extensions
Extend all context classes with custom properties:this.memory resolves MemoryAccessorToken from the calling tool’s providers, so the plugin exports the provider that binds it. The token can also be the provider class itself (token: MemoryAccessor, with exports: [MemoryAccessor]).
Now in tools:
The official RememberPlugin already declares
this.remember. A plugin of your own needs a property name no other installed plugin uses.Plugin Scopes
App Scope (Default)
Installed on an@App, the plugin’s hooks run only for the entries of that app. Installed on @FrontMcp({ plugins }), they run for every app’s entries whatever its scope:
Server Scope
The plugin’s hooks register at the gateway/server level and run for every app’s entries, even when the plugin is installed on one@App. Its providers and context extensions stay with the app that installs it:
Nested Plugins
Plugins can include other plugins:DynamicPlugin derives from its options (dynamicProviders(options) and init({ providers })) are registered before its nested plugins are built. A nested plugin can inject them, for example with NestedPlugin.init({ inject: () => [ConfigToken], useFactory }). This holds for both init(options) and init({ inject, useFactory }).
Using Plugins
In Apps
In Server
Plugin with Tools
Full Example
Official Plugins
FrontMCP provides several official plugins:RememberPlugin
Session memory for tools
CachePlugin
Response caching
CodeCallPlugin
Dynamic code execution
Related
PluginRegistry
Plugin registry API
@Provider
Dependency providers
Creating Plugins
Plugin development guide
@App
Application modules