Documentation
¶
Overview ¶
Package adapters contains MaterializationAdapter implementations for each MCP client that supports plugins.
Index ¶
- type ClaudeCodeAdapter
- func (a *ClaudeCodeAdapter) Dematerialize(_ context.Context, req plugins.DematerializeRequest) error
- func (a *ClaudeCodeAdapter) Materialize(_ context.Context, req plugins.MaterializeRequest) (*plugins.MaterializeResult, error)
- func (*ClaudeCodeAdapter) ScopeSupport() plugins.ScopeSupport
- func (*ClaudeCodeAdapter) SupportedComponents() []plugins.ComponentType
- type CodexAdapter
- func (a *CodexAdapter) Dematerialize(_ context.Context, req plugins.DematerializeRequest) error
- func (a *CodexAdapter) Materialize(_ context.Context, req plugins.MaterializeRequest) (*plugins.MaterializeResult, error)
- func (*CodexAdapter) ScopeSupport() plugins.ScopeSupport
- func (*CodexAdapter) SupportedComponents() []plugins.ComponentType
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type ClaudeCodeAdapter ¶
type ClaudeCodeAdapter struct {
// contains filtered or unexported fields
}
ClaudeCodeAdapter materializes plugins into Claude Code's ~/.claude/plugins/<name> directory and registers them in Claude Code's settings.json so the plugin is actually loaded. Claude Code loads a plugin via a marketplace: a single shared marketplace.json at the plugins root (~/.claude/plugins/.claude-plugin/marketplace.json) lists every ToolHive plugin, and settings.json carries an extraKnownMarketplaces entry (a "directory" source pointing at that root) plus an enabledPlugins entry.
The marketplace manifest and settings source type follow the Claude Code plugin marketplace schema: the manifest has top-level name/owner/plugins, each plugin's source is a "./<name>" relative path resolved against the marketplace root, and the extraKnownMarketplaces source type is "directory". See https://code.claude.com/docs/en/plugin-marketplaces.
func NewClaudeCodeAdapter ¶
func NewClaudeCodeAdapter(cm *client.ClientManager) *ClaudeCodeAdapter
NewClaudeCodeAdapter returns a ClaudeCodeAdapter backed by the given ClientManager and a production skills.Installer.
func (*ClaudeCodeAdapter) Dematerialize ¶
func (a *ClaudeCodeAdapter) Dematerialize(_ context.Context, req plugins.DematerializeRequest) error
Dematerialize removes the plugin directory, cleans up empty parents, and reverts the settings.json mutations made during Materialize.
func (*ClaudeCodeAdapter) Materialize ¶
func (a *ClaudeCodeAdapter) Materialize(_ context.Context, req plugins.MaterializeRequest) (*plugins.MaterializeResult, error)
Materialize extracts the plugin layer into the Claude Code plugins directory and registers it in settings.json so Claude Code loads the plugin.
func (*ClaudeCodeAdapter) ScopeSupport ¶
func (*ClaudeCodeAdapter) ScopeSupport() plugins.ScopeSupport
ScopeSupport returns false for Claude Code: it supports both user and project plugin directories, so a project-scoped install lands in the project directory without degradation.
func (*ClaudeCodeAdapter) SupportedComponents ¶
func (*ClaudeCodeAdapter) SupportedComponents() []plugins.ComponentType
SupportedComponents returns the component types Claude Code loads.
type CodexAdapter ¶
type CodexAdapter struct {
// contains filtered or unexported fields
}
CodexAdapter materializes plugins for the OpenAI Codex CLI.
Codex discovers marketplaces at a fixed set of paths, including the personal ~/.agents/plugins/marketplace.json and the per-repo $REPO_ROOT/.agents/plugins/marketplace.json. ToolHive extracts each plugin's source under that marketplace root (namespaced by the "toolhive" marketplace name, i.e. <root>/toolhive/<name>) and maintains the marketplace.json so Codex can discover it, with a relative "./toolhive/<name>" source per the docs.
Loading the plugin is then a one-time manual step the user runs with the Codex CLI (`codex plugin install <name>@toolhive`). ToolHive deliberately does NOT shell out to the `codex` binary or write speculative `~/.codex/config.toml` enable state: enabling an un-installed plugin doesn't load it, and writing to the user's shared config has blast radius for no benefit. The manual step is documented in docs/arch/14-plugins-system.md.
See https://developers.openai.com/codex/plugins/build.
func NewCodexAdapter ¶
func NewCodexAdapter(cm *client.ClientManager) *CodexAdapter
NewCodexAdapter returns a CodexAdapter backed by the given ClientManager and a production skills.Installer.
func (*CodexAdapter) Dematerialize ¶
func (a *CodexAdapter) Dematerialize(_ context.Context, req plugins.DematerializeRequest) error
Dematerialize removes the plugin's source directory and its marketplace.json entry (deleting the manifest when no plugins remain).
func (*CodexAdapter) Materialize ¶
func (a *CodexAdapter) Materialize(_ context.Context, req plugins.MaterializeRequest) (*plugins.MaterializeResult, error)
Materialize extracts the plugin's source under the Codex marketplace root and registers it in the shared marketplace.json. It does not touch config.toml or invoke the Codex CLI; the user completes loading with a one-time `codex plugin install` (see the package doc).
func (*CodexAdapter) ScopeSupport ¶
func (*CodexAdapter) ScopeSupport() plugins.ScopeSupport
ScopeSupport returns no degradation for Codex: user scope uses the personal ~/.agents/plugins marketplace and project scope uses the per-repo <root>/.agents/plugins marketplace, both of which Codex discovers.
func (*CodexAdapter) SupportedComponents ¶
func (*CodexAdapter) SupportedComponents() []plugins.ComponentType
SupportedComponents returns the component types the Codex CLI loads.
Source Files