Skip to main content

ToolEnricher

Trait ToolEnricher 

Source
pub trait ToolEnricher: Send + Sync {
    // Required methods
    fn supported_categories(&self) -> &[ToolCategory];
    fn enrich_schema(&self, tool_name: &str, schema: &mut ToolSchema);
    fn transform_args(&self, tool_name: &str, args: &mut Value);

    // Provided methods
    fn value_model(&self, _tool_name: &str) -> Option<ToolValueModel> { ... }
    fn project_args(
        &self,
        _prev_tool: &str,
        _prev_result: &Value,
        _link: &FollowUpLink,
    ) -> Option<Value> { ... }
    fn rate_limit_host(&self, _tool_name: &str, _args: &Value) -> Option<String> { ... }
}
Expand description

Trait for plugins that dynamically modify tool schemas and transform arguments.

Enrichers are executed in registration order by the Executor. Each enricher declares which tool categories it supports — only tools from those categories will be enriched and shown in list_tools().

Required Methods§

Source

fn supported_categories(&self) -> &[ToolCategory]

Which tool categories this provider/enricher supports. Tools from other categories won’t be shown when this enricher is active.

Source

fn enrich_schema(&self, tool_name: &str, schema: &mut ToolSchema)

Modify the tool schema during tools/list.

Source

fn transform_args(&self, tool_name: &str, args: &mut Value)

Transform arguments before tool execution.

Provided Methods§

Source

fn value_model(&self, _tool_name: &str) -> Option<ToolValueModel>

Optional: provider-shipped value model for tool_name. Returned models are merged into AdaptiveConfig.tools at startup so the Paper 3 enrichment planner can read them via effective_tool_value_model.

Default impl returns None — built-in enrichers that do not participate in the planner can ignore the method entirely.

Source

fn project_args( &self, _prev_tool: &str, _prev_result: &Value, _link: &FollowUpLink, ) -> Option<Value>

Build the JSON arguments for a speculatively pre-fetched follow-up call.

Given the tool that just produced prev_result (prev_tool), the follow-up tool’s FollowUpLink (with projection / projection_arg set), the host asks the enricher: “what args should I pass to <follow-up tool>?”

Returns:

  • Some(json) — emit one prefetch request per object in the returned array (planner caps at max_parallel_prefetches). Top-level shape is [{ <args1> }, { <args2> }, …].
  • None (default) — provider has no opinion; the host falls back to the generic projection in link.projection_arg.

Built-in enrichers should override this for the high-volume follow-up chains identified in paper3_corpus_findings.md (Glob → Read, Grep → Read, WebSearch → WebFetch, …).

Source

fn rate_limit_host(&self, _tool_name: &str, _args: &Value) -> Option<String>

Optional dynamic rate-limit host for tool_name, derived from runtime args. Provider returns the network host the call will hit (e.g. Some("api.github.com")) so the speculative dispatcher can cap concurrent in-flight prefetches per host.

Default: None — host falls back to ToolValueModel::rate_limit_host (the static configuration value), and if that is also None the prefetch is uncapped.

Override this for tools whose target host is per-call — WebFetch (host from url arg), WebSearch against multiple search engines, MCP wrappers around generic HTTP clients.

Dyn Compatibility§

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors§