Summary

Allow plugins to register custom search providers for the built-in web_search tool, rather than hardcoding providers in the schema.

Current Behavior

tools.web.search.provider only accepts "brave" or "perplexity" (hardcoded in the Zod schema). Users who want alternative search backends (Kagi, Serper, SerpAPI, Tavily, etc.) have no clean integration path.

Proposed Behavior

Plugins can register search providers that become available as tools.web.search.provider options:

api.registerSearchProvider({
  id: "kagi",
  label: "Kagi",
  configSchema: {
    type: "object",
    properties: {
      apiKey: { type: "string" }
    }
  },
  async search(params, config) {
    // params: { query, count, country, freshness, ... }
    // config: plugin config from tools.web.search.kagi
    // returns: { results: [{ title, url, snippet }], ... }
  }
});

Config would look like:

{
  tools: {
    web: {
      search: {
        provider: "kagi",  // now valid
        kagi: {
          apiKey: "..."
        }
      }
    }
  }
}

Benefits

• User choice: Different search APIs have different strengths (Kagi for quality, Brave for privacy, Perplexity for AI summaries, etc.)
• No core bloat: New providers ship as plugins, not core changes
• Consistent UX: One web_search tool, user picks the backend
• Ecosystem growth: Third-party search integrations without forking

Alternatives Considered

1. Separate tools per provider (kagi_search, tavily_search, etc.) — clutters the tool namespace, confuses the LLM with multiple search tools
2. Skill-based workarounds — works but requires manual exec calls, not native tool integration

Implementation Notes

• The schema would need to accept dynamic provider values (validated at runtime against registered providers)
• Provider config would nest under tools.web.search.<providerId>
• Fallback/priority could be added later (try Kagi, fall back to Brave)

Happy to help with implementation if there's interest!