How to Use OpenClaw MiniMax Search

MiniMax Search in OpenClaw uses the MiniMax Coding Plan search API. Unlike Gemini, Kimi, or Grok grounded search, this provider returns structured search results with titles, URLs, snippets, and related queries. That makes it a better fit for workflows that need a result list rather than a single synthesized answer.

30-second answer

Create or copy a MiniMax Coding Plan key, set MINIMAX_CODE_PLAN_KEY in the Gateway environment, or configure plugins.entries.minimax.config.webSearch.apiKey. Set tools.web.search.provider to minimax. Choose region global or cn when needed. MiniMax Search supports query and count, with OpenClaw trimming returned results to the requested count.

Key names

The docs are precise about credentials. MINIMAX_CODE_PLAN_KEY is the preferred key. MINIMAX_CODING_API_KEY is also accepted as an alias. MINIMAX_API_KEY is read only as a compatibility fallback when it already points at a coding-plan token. Do not assume a normal model API key is always the right search key.

Region selection

MiniMax Search has separate global and CN endpoints: https://api.minimax.io/v1/coding_plan/search and https://api.minimaxi.com/v1/coding_plan/search. If region is unset, OpenClaw checks plugin region, MINIMAX_API_HOST, models.providers.minimax.baseUrl, and models.providers.minimax-portal.baseUrl. That keeps CN onboarding aligned with CN search.

OAuth note

Even if MiniMax authentication uses the OAuth minimax-portal path, web search still registers as provider id minimax. The OAuth provider base URL is only used as a region hint. That distinction matters when debugging provider names in config.

When to choose it

Choose MiniMax when you already have a Coding Plan key or want structured results with related queries. Choose a grounded answer provider when the user wants a single cited narrative. Choose an extractor when you already know the URLs.

Playbook angle

The Playbook pattern is to document the key type and region beside the provider name. Most MiniMax search failures are config-shape problems, not agent intelligence problems.

Runbook checklist

Before you automate this, run one small acceptance test with harmless input. Confirm the tool is available to the right agent, the credential is loaded from config or environment, the output shape matches the workflow, and the failure message is understandable to a tired operator. If the feature touches money, public channels, logged-in browsers, host commands, or customer data, put a review step before the side effect. If it only reads data, still record the source and timestamp so future sessions do not treat stale context as fresh truth. Keep the first version narrow, then expand once the logs show the agent is choosing the right tool for the right reason. When the docs are incomplete, prefer a conservative sentence over a clever invented shortcut that future agents cannot reliably verify. Add one monitoring habit as well: after the first real run, check the transcript or logs for missing prerequisites, broad prompts, stale assumptions, and accidental side effects. Tighten the instruction while the failure is fresh. The best OpenClaw workflows improve in small, documented passes instead of one giant rewrite after something breaks in public. For SEO pages, that same discipline matters: do not promise hidden capabilities, paid-provider limits, or setup shortcuts unless the current docs say so. Trust compounds when the guide is accurate even in the boring operational edge cases that matter during real maintenance windows.

Operator note

How to Use OpenClaw MiniMax Search works best when it is written into a small runbook instead of treated as a magic switch. Record who owns the workflow, which config keys are allowed, which credentials are required, what the agent may do without approval, and what counts as a failure. OpenClaw gives agents broad tools, but the reliable version is boring: one source of truth, one verification step, and one rollback path when a provider or channel behaves differently than expected.