Summary

Add Moonshot/Kimi native web search as an optional gateway-level provider for the existing web_search tool.

Problem to solve

When using Moonshot Kimi (e.g. K2.5) as the primary model, there is currently no way for the main OpenClaw agent to use Kimi’s native web search capabilities.

Today, users must choose between:

• Using Brave/Perplexity via web_search (external dependency), or
• Implementing workarounds such as plugins that perform a second model call to Moonshot for search.

Both options are suboptimal when the selected model already provides a first-party search mechanism.

Previous discussions (e.g. #877) correctly identified concerns with model-autonomous search, but that leaves no supported path for gateway-controlled native provider search.

Proposed solution

Add Moonshot/Kimi native search as an optional backend provider for OpenClaw’s existing web_search tool, implemented entirely at the gateway level.

Key characteristics:

• web_search remains an explicit OpenClaw tool
• The gateway decides when search occurs
• The gateway executes the request
• The model receives only structured results
• No model-autonomous or hidden search calls

Example configuration:

tools: {
  web: {
    search: {
      enabled: true,
      provider: "moonshot",
      moonshot: {
        model: "kimi-k2.5",
        baseUrl: "https://api.moonshot.ai/v1",
        apiKey: "...",          // or MOONSHOT_API_KEY env var
        thinking: false,        // required for Kimi K2.5 search
        temperature: 0.6,
        top_p: 0.95
      }
    }
  }
}

Implementation outline:

• Extend web_search with a new provider backend (moonshot)
• Gateway calls Moonshot /v1/chat/completions
• Force tool usage: $web_search
• Disable thinking mode for search calls (Kimi K2.5 requirement)
• Normalize results into { title, url, snippet }, matching existing providers
• Gateway retains control over rate limits, logging, budgets, and policies

This preserves OpenClaw’s existing governance model while enabling first-party search for Moonshot users.

Alternatives considered

1. Continue using Brave/Perplexity

   • Works, but introduces external dependencies even when the model has native search.

2. Plugin-based second model calls

   • Causes additional latency and cost.
   • Creates agent-to-agent patterns that are harder to reason about.
   • Bypasses the gateway’s normal search abstraction.

3. Model-autonomous native search

   • Explicitly not proposed due to governance, auditing, and cost-control concerns (as discussed in Native Web Search Support (Anthropic, OpenAI, xAI, Google) #877).

Impact

Affected users/systems/channels

• Users running OpenClaw with Moonshot/Kimi as the primary model
• Workflows that require up-to-date web information
• Tooling built around web_search

Severity

• Blocks optimal use of Kimi models for search-heavy agents
• Forces inefficient or external workarounds

Frequency

• Always affects Moonshot/Kimi users who need web search

Consequences

• Extra model calls and higher cost
• Increased latency
• More complex agent/plugin setups
• Reduced incentive to use Moonshot models as first-class citizens in OpenClaw

Evidence/examples

• Moonshot/Kimi exposes a native $web_search tool, but it is not accessible through OpenClaw’s web_search.
• Users currently resort to second-call plugins to access this functionality, which is less efficient and harder to maintain.
• Issue Native Web Search Support (Anthropic, OpenAI, xAI, Google) #877 highlights concerns with native search, but focused on model-autonomous usage rather than gateway-controlled providers.

Additional information

Before implementing anything, I’m explicitly asking whether maintainers would be open to this approach and whether there are constraints or preferences to follow (e.g. feature flag, documentation expectations, provider neutrality concerns).

If approved, I’m happy to implement the provider, documentation, and schema updates in a PR aligned with existing patterns.