AnySearch MCP Server: A Hosted Search Endpoint for MCP Clients
Unified real-time search MCP server supporting general web search, vertical domain search, parallel batch search, and full-page URL content extraction.
At a glance
- What is it?
- AnySearch is a remote MCP server that exposes web search, vertical domain search, batch queries and URL-to-Markdown extraction over Streamable HTTP. The interesting design decision is that the server itself is not something you install: you point a client at api.anysearch.com/mcp and optionally attach a key.
- Who is it for?
- Adopt AnySearch if your agent runs in a client that already speaks remote MCP over Streamable HTTP (OpenCode, Claude Code, Cursor, VS Code, Windsurf, Cline per the README) and you want search without operating a search backend. Do not adopt it if you need a self-hosted, air-gapped or offline search path, or if your client only supports stdio transport, because the README says no SSE or stdio proxy is needed and points solely at https://api.anysearch.com/mcp.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 23 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem AnySearch solves is transport and plumbing, not search quality
Giving an agent web access usually means running a search API wrapper yourself: a small service that holds credentials, normalises results, and exposes them as tools. AnySearch removes that service. The repository describes a hosted MCP server at https://api.anysearch.com/mcp that exposes four capabilities: open-ended natural language web search, structured queries across vertical domains (the README lists finance, academic, security, legal and code), parallel batch search that runs several independent queries in one call, and URL content extraction that returns full page content as Markdown. The target user is someone configuring an MCP-capable coding agent or desktop client who wants search and page fetching available as tools without writing or deploying a backend. The vertical domain list is the one part that suggests a real editorial decision rather than a thin proxy: a legal or academic query routed to a domain-specific index is a different request shape from a general web query, and the server treats them as separate tools rather than one search box with a filter argument.
Remote Streamable HTTP only: what the architecture implies
There is no local process. The README states the production endpoint natively uses Streamable HTTP and that current OpenCode, Claude Code, Cursor, VS Code, Windsurf and Cline releases connect to it directly, with no SSE or stdio proxy needed. That single sentence determines most of the operational profile. Authentication travels as an Authorization: Bearer header, and a second header, X-Anysearch-Client, carries a client identifier (the examples set it to mcp/1.0.0). Because the server is remote and stateless from your side, there is nothing to upgrade, no container to rebuild, and no local port to manage. The cost is the inverse: every tool call is a network round trip to a third party, your queries leave your machine, and if api.anysearch.com is unreachable the tools simply are not there. The README does not describe a self-hosted deployment path, a Docker image, or a local binary, so treating this as an offline-capable component would be a misreading of the material.
Key priority order and the four-step resolution chain
An API key is optional. The README is explicit that without a key all features still work through anonymous access, with lower rate limits. When a key is present, the server resolves it in a fixed order: the --api_key CLI flag or the Authorization header wins, then the ANYSEARCH_API_KEY environment variable, then an ANYSEARCH_API_KEY entry in a .env file, and finally anonymous access. That ordering matters in practice because it decides which credential wins when two are configured at once. If you export ANYSEARCH_API_KEY in your shell but also hardcode a header in a project .mcp.json, the header takes precedence, and a stale hardcoded key will silently shadow the environment variable you thought you were rotating. The README also documents the exhaustion behaviour: when a key is exhausted and the server returns an auto-registered key, the agent is told to ask the user for confirmation before persisting the new key; when a key is exhausted with no replacement, the instruction is to inform the user and suggest configuring a new one. That is a deliberate human-in-the-loop checkpoint rather than silent credential rotation.
Getting it running: the actual client configurations
For OpenCode, the README uses ~/.config/opencode/opencode.json globally (or opencode.json in the project root, and %USERPROFILE%\.config\opencode\opencode.json on Windows). The entry sets "type": "remote", "url": "https://api.anysearch.com/mcp", "enabled": true, "oauth": false, and a headers object containing "Authorization": "Bearer {env:ANYSEARCH_API_KEY}" plus "X-Anysearch-Client": "mcp/1.0.0". The README notes that OpenCode substitutes environment variables with the {env:NAME} syntax and that "oauth": false avoids an OAuth discovery flow the server does not need. For Claude Code, the command form is 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". The user scope writes to ~/.claude.json and makes the server available across all projects on the machine. A shareable alternative is a .mcp.json file in the project root with "type": "http" and the same URL and headers, using ${ANYSEARCH_API_KEY} for substitution; the README states Claude Code expands ${VAR} and ${VAR:-default} inside url and headers, and that project-scoped servers require approval on first interactive open. Verification commands are given as claude mcp get anysearch and claude mcp list, with /mcp showing server status and available tools inside the client. For Cursor, the file is .cursor/mcp.json for a project or ~/.cursor/mcp.json globally, and the supplied README excerpt is truncated mid-header, so the Cursor block cannot be reproduced in full from this material.
The registration flow assumes an agent that can make outbound HTTP calls
The most unusual documented feature is one-call account registration. A single POST to https://api.anysearch.com/v1/auth/email/register with a JSON body containing an email address returns, on code 0, the account details and a one-time plaintext API key under data.api_key.key, with fields for rate_limit, quota_limit, expires_at and key_prefix. The README instructs the agent to place that key into the MCP server config as the Bearer value or into ANYSEARCH_API_KEY, and to tell the user their username (which equals the email) and the login_url. The email must be real and reachable, because it becomes the account username. Error handling is string-based: every error returns code -1 and the caller branches on the message text. Invalid email address means re-prompt. email_already_registered means stop and send the user to the login URL, explicitly without retrying. A message containing Rate limited carries a retry interval in the text, for example retry after 300 seconds. A message starting with Key creation failed means the account exists but key generation failed, and the email and URL are embedded in that message so the user can sign in and create a key manually. Internal server error means retry later or fall back to anonymous. Branching on message substrings is brittle compared with branching on a stable error code, and the README does not document a machine-readable error enum, so any client-side automation built on this will need to handle message text that can change.
Where it is the wrong tool
The remote-only design rules out several legitimate setups. If your client speaks only stdio transport, this server does not fit as documented. If your environment has no outbound access to api.anysearch.com, or if policy forbids sending queries and page URLs to a third party, there is no local fallback described. If you need deterministic, reproducible retrieval for evaluation harnesses, a hosted search index that changes under you is a poor substrate, and the README offers no snapshot, versioning or caching semantics. The anonymous tier is the weakest documented option: the README states only that limits are lower than with a key, without publishing the anonymous numbers, so capacity planning on anonymous access is guesswork until you measure it. There is also no release history in the supplied material (recent releases returned none), which makes it hard to judge how the tool schemas have changed over time. None of these are defects in the code; they are boundaries of a hosted-service model that the README does not pretend to cross.
Alternatives and the actual difference in approach
The obvious comparison is a self-hosted search MCP server built on a search API you already pay for, or on a local index such as a SearxNG instance you operate. The difference is not result quality, it is where the boundary sits. A self-hosted server keeps credentials and query text inside your network, lets you pin a version and read the tool schema in your own repository, and lets you swap the upstream provider without changing client configuration. AnySearch trades that for zero deployment: one URL, an optional Bearer token, and no process to supervise. A second comparison is the provider's own first-party MCP endpoints, which some search vendors publish; those typically authenticate with a provider key you already hold and expose that provider's index only, whereas AnySearch presents a single endpoint that fronts general web search plus separate vertical domains and a URL extraction tool. The practical test is whether you need to control the retrieval layer or merely consume it. If your agent's search behaviour is part of what you are evaluating, you want the layer you can instrument and version. If search is incidental infrastructure behind a coding assistant, the hosted endpoint is the shorter path.
Licence, maintenance and what a hosted MCP server actually costs you
The repository is Apache-2.0. That covers the code in the repository, but the README describes a client that talks to a hosted service at api.anysearch.com, and a software licence does not grant rights to a service, define its availability, or set its rate limits. Anyone treating the Apache-2.0 identifier as the whole picture should separate the two: the licence governs what you can do with the source, and the terms of the hosted endpoint govern what you can do with the search itself. This is not legal advice; read the service terms before routing production traffic through it. On maintenance cost, the picture is unusually light and unusually opaque at the same time. There is no local runtime to patch, so upgrade work is limited to editing a client config file when a header or URL changes. The opaque part is that the tool surface lives on the server: if a tool is renamed or a vertical domain is added, your client picks that up on the next connection with no changelog in the repository to warn you. The README's own client identifier header, X-Anysearch-Client: mcp/1.0.0, suggests the server can distinguish client versions, which may matter if behaviour diverges later, but the material does not describe any version negotiation. If you depend on specific tool names in prompts or scripts, that dependency is on a remote schema you do not control.
Editorial conclusion
Adopt AnySearch if your agent runs in a client that already speaks remote MCP over Streamable HTTP (OpenCode, Claude Code, Cursor, VS Code, Windsurf, Cline per the README) and you want search without operating a search backend. Do not adopt it if you need a self-hosted, air-gapped or offline search path, or if your client only supports stdio transport, because the README says no SSE or stdio proxy is needed and points solely at https://api.anysearch.com/mcp. Before wiring it into anything shared, verify three things: that your client version actually connects to a remote HTTP MCP endpoint, that the tool names and schemas your agent sees match what your prompts assume, and what the anonymous rate limit actually is in practice, since the README only says anonymous access has lower limits than a keyed request.
Community notes