Skip to main content
The plugin re-exports a small public surface from @frontmcp/plugin-skilled-openapi. Everything else is plugin-private and may change without notice.

Default export

The plugin class itself. Call .init(options) to produce a registerable provider for the FrontMCP plugins: array. Same instance is also available as a named export:

Plugin options

See Configuration for the field-by-field breakdown.

Source option types

See Sources for the per-source semantics.

Signature & outbound options

SignatureKey is the entry shape for trustedKeys[]. OutboundOptions is the parsed outbound block — useful when you read it via SkilledOpenApiConfig.

DI tokens

SkilledOpenApiConfig

Singleton populated by the plugin’s dynamicProviders(). Inject in any plugin/tool:

SkilledOpenApiCredentialResolver

Abstract token. Override the provider with your own implementation to back the executor’s auth resolution with a libs/auth-vault, AWS Secrets Manager, GCP Secret Manager, etc. Default implementation is the in-memory MemoryCredentialResolver seeded by the credentials plugin option.
Override pattern:
Register MyVaultPlugin after SkilledOpenApiPlugin so the override wins.

Internal modules (do not depend on)

The following are exported for tests and the plan but are NOT part of the stable API:
  • BundleStore, HiddenOpRegistry, BundleSyncService — runtime registries
  • OperationDescriptor, BundledSkill, ResolvedBundle, AuthBinding, BundleIntegrity — wire types (use the JSON shape documented in Bundle Format instead)
  • executeOperation, OpenApiRuntimeDeps — runtime executor
  • BundlePushJwtVerifier, WebhookReplayGuard, AuthorityGuard — security helpers
  • verifyBundleSignature, bundleDigest, canonicalize — signature primitives
These are subject to change; pin to a specific minor version if you depend on them.

SDK additions used by the plugin

The plugin extends @frontmcp/sdk with three additive changes you can use directly:

SkillRegistry.registerSkillContent(content, opts?)

Register a skill at runtime from a fully-resolved SkillContent. Returns a handle with an unregister() method.
Registering again with the same id replaces the skill. A skill whose id is another skill’s <skill-path> (its name, for a skill without a skillPath), or whose path is another skill’s id, is refused with INVALID_PARAMS and nothing changes: skill://<id>/SKILL.md also addresses a skill by its id, so the two would share one URI. Skills declared at startup are held to the same rule and the server refuses to start (InvalidSkillError). opts.source labels the registration in logs. opts.supersedes lists the ids of skills registered this way that the same change replaces or removes: the collision check treats them as already gone, so a change whose end state has no collision is not refused over a skill it is about to drop. A superseded skill that the new one collides with is removed in the same step, so the two are never served together, and the handle’s removed lists it. The others stay registered until you register them again or unregister them. The bundle sync passes the previous bundle’s skills that it has not registered again yet, so a new skill can take the name of a skill the bundle drops or renames.

SkillContent.actions[] and bundleVersion

SkillContent carries optional actions[] (the per-skill executable operations) and bundleVersion (for change detection without notifications/skills/list_changed).

notifications/skills/list_changed

Added to McpNotificationMethod. The NotificationService subscribes to scope.skills and broadcasts on every global change event. These changes are documented in the skills feature page and are usable independently of this plugin.