@xpert-ai/plugin-sdk.
Capability model
A capability key is a frozen object containing a stable ID, a description, and a TypeScript-only API type:get() and require(), while the stable ID lets the host and dynamically loaded plugins agree on the same contract.
The registry exposes four operations:
Resolve a capability in Agent middleware
Agent middleware receives the scoped registry oncontext.runtime.capabilities:
get() when the feature can be hidden or degraded. Use require() only after the plugin has established that the capability is mandatory for the current operation:
Resolve a capability in a NestJS provider
Server-side plugin providers can inject the platform registry. Keep the dependency optional when the plugin can load on a host version that does not provide the capability:Capabilities in the runtime package
Continue with the detailed references:
Define and test capability consumers
createRuntimeCapability<T>() creates a typed key for a host or plugin subsystem. Do not reuse a platform.* ID for a different contract. RuntimeCapabilityResolver is the read-only get() view to use when a consumer must not register implementations.
DefaultRuntimeCapabilityRegistry:
Compatibility rules
- Import keys and API types from
@xpert-ai/plugin-sdk; do not copy the interfaces into a plugin. - Treat capability availability as a runtime condition. Package installation alone does not prove that a host service, provider, binding, or registered Sandbox Action is ready.
- Keep portable references and structured DTOs at async boundaries. Do not pass raw file bytes, bearer tokens, host paths, or implementation instances through queues or persisted chat metadata.
- Keep capability results within the current authorized scope and re-resolve them for later jobs or callbacks.