Trait ToolEnricher 

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> { ... }
}

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

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.

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

Modify the tool schema during tools/list.

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

Transform arguments before tool execution.

Provided Methods

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.

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, …).

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.

Implementations on Foreign Types

impl ToolEnricher for ClickUpSchemaEnricher

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

Paper 3 — ClickUp issue → comments / detail chain.

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

ClickUp SaaS uses api.clickup.com.

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)

impl ToolEnricher for ConfluenceSchemaEnricher

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

Paper 3 value models for the six KB tools.

Read endpoints are ReadOnly with realistic typical/max sizes drawn from observed Confluence pages (a single page can be tens of KB once attachments / large tables / embedded images are rendered as storage XML). search_knowledge_base and list_knowledge_base_pages declare a get_knowledge_base_page follow-up with pageId projection so the planner can prefetch the most likely next call. Mutating endpoints are MutatesExternal and never speculatable.

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)

impl ToolEnricher for FormatPipelineEnricher

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)

impl ToolEnricher for FirefliesSchemaEnricher

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

Paper 3 — Fireflies meetings → transcript chain. Transcripts are large (typical 8 kB, max ~50 kB) but content is highly reusable across the session, so prefetch hit rate is high when the user asks “what was discussed”.

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

Fireflies API host.

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)

impl ToolEnricher for GitHubSchemaEnricher

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

Paper 3 — value-model annotations for GitHub read-only tools. Mirrors the GitLab structure (PRs/issues/comments) — they share the same list → detail → comments shape.

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

GitHub SaaS = api.github.com. Self-hosted Enterprise users can override per-tool via TOML; we don’t read args because the host is a session-level fixed value.

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)

impl ToolEnricher for GitLabSchemaEnricher

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

Paper 3 — value-model annotations for GitLab read-only tools.

Speculative pre-fetch wins for the canonical list → detail chains: after get_merge_requests the agent almost always reads discussions / diffs of the top hit; after get_issues it reads comments. We annotate the read-only endpoints (Pure for inside-of-TTL, ReadOnly otherwise) and leave mutating endpoints (create_issue, update_issue, …) as the default Indeterminate so they are never speculated.

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

Paper 3 — gitlab.com for SaaS, picked up from the runtime args if the tool carries an explicit instance URL. We don’t look at args here because GitLab tools live behind one configured client per session; the host falls back to the tool’s static rate_limit_host annotation.

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)

impl ToolEnricher for JiraSchemaEnricher

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

Paper 3 — Jira read-only chains (issues / comments). Issue detail and comments are the highest-value follow-ups; create / update / transition are mutating and never speculatable.

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

Jira hosts vary per deployment (Cloud vs Server vs Data Center). Operators set rate_limit_host per-tool in TOML for shared rate-limit grouping; we don’t statically assume Cloud.

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)

Implementors