AnySearch MCP Server: One Remote Endpoint for Web, Vertical and Batch Search

What AnySearch MCP Server actually provides

The README describes four capabilities: general web search for open-ended natural language queries, vertical domain search across finance, academic, security, legal and code, parallel batch search that runs multiple independent queries in one call, and URL content extraction that returns full page content as Markdown. That last one is the distinguishing piece. Many MCP search servers return titles, snippets and links; a tool that also converts a page to Markdown means an agent can read a result without a second fetch tool.

The audience is narrow and specific. This is for people running an MCP-capable client such as Claude Code, Cursor, OpenCode, VS Code, Windsurf or Cline who want search as a tool call rather than a browser tab. It is not a library you import, and it is not a search engine you host. The repository contains a README, a Chinese README, a licence, a NOTICE file, a SECURITY.md and a .gitignore. There is no server source to read, which matters for anyone who needs to know how results are ranked or filtered.

The transport decision: Streamable HTTP instead of stdio

The production endpoint is https://api.anysearch.com/mcp and, per the README, it natively uses Streamable HTTP. The README states that current OpenCode, Claude Code, Cursor, VS Code, Windsurf and Cline releases can connect directly, with no SSE or stdio proxy needed.

That choice removes a whole class of setup friction. A stdio MCP server normally means installing a package, pinning a version and letting the client spawn a subprocess, which breaks in sandboxed or containerised environments. A remote HTTP endpoint is just a URL and headers. The trade-off is the reverse side of the same coin: every query leaves your machine for api.anysearch.com, and the server's availability becomes your availability. If the endpoint is down, your agent loses the tool. The README does not document a fallback, a self-hosted deployment or an offline mode.

Installing AnySearch MCP Server in Claude Code and OpenCode

The API key is optional. Without one, the README says all features still work through anonymous access with lower rate limits. The fastest authenticated path in Claude Code is a single command, which stores the server at user scope in ~/.claude.json so it is available across every project on the machine. Drop the Authorization header option for anonymous access.

claude mcp add --transport http anysearch https://api.anysearch.com/mcp --scope user --header "Authorization: Bearer <your_api_key>" --header "X-Anysearch-Client: mcp/1.0.0"

After running it, the README gives two verification commands. The first prints the stored server definition, the second lists configured servers.

claude mcp get anysearch
claude mcp list

For a configuration shared through the repository rather than the machine, the README shows a project-root .mcp.json. Claude Code expands ${VAR} and ${VAR:-default} inside url and headers, so the key can stay out of the file.

{
  "mcpServers": {
    "anysearch": {
      "type": "http",
      "url": "https://api.anysearch.com/mcp",
      "headers": {
        "Authorization": "Bearer ${ANYSEARCH_API_KEY}",
        "X-Anysearch-Client": "mcp/1.0.0"
      }
    }
  }
}

OpenCode uses a different file and a different substitution syntax. The README points at ~/.config/opencode/opencode.json for a global config, or opencode.json in the project root; on Windows the global path is %USERPROFILE%\.config\opencode\opencode.json. Note that "oauth": false is set deliberately, to skip an OAuth discovery flow that this API-key-authenticated server does not need.

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "anysearch": {
      "type": "remote",
      "url": "https://api.anysearch.com/mcp",
      "enabled": true,
      "oauth": false,
      "headers": {
        "Authorization": "Bearer {env:ANYSEARCH_API_KEY}",
        "X-Anysearch-Client": "mcp/1.0.0"
      }
    }
  }
}

One detail worth keeping: the README says to remove only the Authorization entry to switch to anonymous access, and to keep X-Anysearch-Client. That header appears to identify the client version to the service, so stripping it is not part of the documented anonymous path.

Registering an API key without leaving the agent

The most unusual part of the README is an agent-driven registration flow. A single POST creates the account and returns a plaintext API key, with no verification code and no manual signup. The email becomes the account username.

curl -s -X POST "https://api.anysearch.com/v1/auth/email/register" \
  -H "Content-Type: application/json" \
  -d '{"email": "[email protected]"}'

On success the response carries code: 0 and a data object with the username, a login_url and an api_key block containing an as_sk_ prefixed key, a key_prefix, a rate_limit of 100 and a quota_limit of 0. The README warns that the key is shown only once, though it can be retrieved later from the dashboard, and that the email must be real and reachable.

Error handling is string-based rather than code-based: the README says errors always return code: -1 and that callers should branch on the message text. The documented messages are Invalid email address., email_already_registered, a message containing Rate limited with a retry interval, a message starting with Key creation failed., and Internal server error. That design is easy to integrate but brittle. Matching on prose means a reworded message on the server side silently changes client behaviour, and there is no documented error code to fall back on.

Key priority, exhaustion and the limits of the documentation

The README defines a four-level priority order: the --api_key CLI flag or Authorization header wins, then the ANYSEARCH_API_KEY environment variable, then a .env file containing ANYSEARCH_API_KEY=<key>, then anonymous access. When a key is present it is sent as Authorization: Bearer <key> and gets higher rate limits. The README does not state what the anonymous rate limit actually is, only that it is lower.

The behaviour table describes two exhaustion cases. If a key is exhausted and an auto-registered key is returned, the agent should ask the user for confirmation before persisting the new key. If a key is exhausted and no new key comes back, the agent should tell the user and suggest configuring a new key. What is missing is the recovery path inside a running conversation: the README does not document whether an in-flight batch query is retried, partially returned or dropped when the quota trips. For a tool that advertises parallel batch search, that gap matters, because a batch is exactly where a mid-call failure is hardest to reason about. Treat the exhaustion flow as something to test yourself before depending on it.

When AnySearch MCP Server is the wrong choice

The clearest mismatch is self-hosting. The repository publishes no server implementation, so there is nothing to run on your own infrastructure. Teams with data-residency rules, air-gapped networks or a requirement that queries never leave a controlled boundary cannot satisfy those requirements with this project as documented.

A second mismatch is anyone who needs to inspect or tune retrieval. The README does not describe the ranking model, the sources behind vertical domain search, or how the finance, academic, security, legal and code verticals differ in behaviour. If your application depends on reproducible result ordering, you cannot verify that here. A third case: if your MCP client cannot send custom headers, the only documented path left is anonymous access, since every authenticated example in the README depends on an Authorization header or the --api_key flag.

How it compares with a stdio search server

The natural alternative is a locally installed stdio MCP search server, the pattern used by many community search integrations. The difference is architectural, not cosmetic. A stdio server runs as a subprocess on your machine, so the search provider is a dependency you install, version and update, and the process inherits your network and credentials. AnySearch MCP Server inverts that: the client holds a URL and a bearer token, and the provider is a hosted service.

That inversion buys setup speed and costs control. You get one endpoint for general search, vertical search, batch queries and Markdown extraction, with no local process to keep alive. You give up the ability to read the code, pin a version, or run the retrieval path offline. For a coding agent that needs to look things up during a session, the hosted model is usually the better fit. For a pipeline where search results feed a regulated decision, the stdio model at least gives you something to audit.

Licence, maintenance and what to check before adopting

The repository is licensed under Apache-2.0, and a NOTICE file sits alongside the LICENSE, which is the standard Apache arrangement for attributions. Because the repository contains documentation rather than server code, the licence mainly governs the README, the Chinese README and the configuration examples. It does not grant you rights to the hosted service at api.anysearch.com, whose terms are not described in the README. If you plan to redistribute the configuration examples inside a product, read the NOTICE before you do.

On maintenance: the repository is not archived, and the last push was on 2026-08-24. There are no retrieved releases, so there is no version history to reason about and no changelog to check before an upgrade. In practice the upgrade surface is small, since clients point at a URL rather than a pinned package. The real version risk lives in the X-Anysearch-Client header, which the examples set to mcp/1.0.0; if the service ever requires a newer value, that string is the thing you would change. Before adopting, verify three things: that your client connects to the Streamable HTTP endpoint, that ANYSEARCH_API_KEY resolves in the environment your client starts from, and that the anonymous rate limit is tolerable if you never register a key.

Editorial conclusion

Adopt AnySearch MCP Server if you already run a Streamable HTTP capable MCP client and want search plus URL extraction behind one URL without operating your own search backend. Skip it if you need a self-hosted, air-gapped search layer, or if you want to audit the retrieval logic, because the repository publishes no server source. Before rolling it into a workflow, confirm that your client accepts custom headers, that your API key is set as ANYSEARCH_API_KEY (or passed via --header), and that you are comfortable sending queries to api.anysearch.com. The last push to the repository was on 2026-08-24.

Frequently asked questions

Official sources

1. anysearch-ai/anysearch-mcp-server on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README