AnySearch Skill: A Runtime-Agnostic Search Skill for AI Agents

The gap AnySearch Skill fills between an agent and a search API

An agent that needs current information has two bad options. It can call a search API directly, which means every agent framework ships its own HTTP glue, its own retry logic and its own pagination handling. Or it can rely on whatever browsing tool the platform provides, which varies by host and often returns a rendered page rather than structured results.

AnySearch Skill takes the first option and standardises it. The repository describes itself as a unified real-time search engine skill for AI agents, covering general web search, vertical domain search, parallel batch search and full-page content extraction. The unit of distribution is the skill directory, not a library you import. That is the design decision that matters: the project targets agent platforms that load skills from a folder, and it names Claude Code, OpenCode, Cursor, Windsurf, Codex and OpenClaw as hosts.

The audience is therefore narrow and specific. If you run an agent that reads skills from ~/.claude/skills, ~/.config/opencode/skills, a project-level .skills directory, or a shared ~/.agents/skills directory, this drops in. If you are building a backend service that needs search results, you are not the target user; you want the underlying HTTP API, not a skill wrapper.

Four CLIs, one command surface, and the runtime detection rule

The mechanism is deliberately boring. The repository ships scripts/anysearch_cli.py, scripts/anysearch_cli.js, scripts/anysearch_cli.ps1 and a Bash CLI, all exposing the same subcommands. The README's verification step uses the doc subcommand as the entry test, which means the CLI surface is meant to be identical across runtimes and the doc command is the cheapest way to prove a runtime works.

Dependencies differ by runtime, and this is where most installs go wrong. requirements.txt contains a single line, requests>=2.20, and the file itself notes that only the Python CLI needs it. The Node.js, Bash and PowerShell CLIs require nothing from that file. The Bash fallback does require jq and curl, per the README's runtime check comments.

The README sets an explicit priority: Python over Node.js over Shell. It also warns against assuming python exists, noting that on many macOS systems the correct executable is python3. Python must be 3.6 or newer; Node.js must be 12 or newer; the shell fallback needs PowerShell 5.1+ on Windows or bash 3.2+ elsewhere.

API key resolution is a four-level chain: the --api_key CLI flag wins, then .env, then a system environment variable, then anonymous access. That ordering is documented in both the README and .env.example, so a stale exported variable will not silently override a key you placed in .env, but a flag on the command line will.

Installing AnySearch Skill and running the first real command

The README recommends a pinned release rather than the default branch. Download the tag you want, unzip it, and move the resulting directory into your agent's skill directory under the name anysearch.

curl -L -o anysearch-skill.zip https://github.com/anysearch-ai/anysearch-skill/archive/refs/tags/v3.1.1.zip
unzip anysearch-skill.zip
mv anysearch-skill-3.1.1 ~/.claude/skills/anysearch

The unzip step creates a directory named after the ref, for example anysearch-skill-3.1.1, so adjust the source name to match whatever tag you downloaded. The README lists alternative destinations for OpenCode (~/.config/opencode/skills/anysearch), Cursor and Windsurf (a project-level .skills/anysearch), and a generic agent skill directory. It also calls out ~/.agents/skills/ as a shared location for tools that read the same skill directory, including Codex, Cursor and OpenClaw.

If your platform has a skill marketplace, the README says to search for anysearch there instead and skip the manual steps.

The Python CLI needs requests, so install that first if you intend to use it.

pip install -r requirements.txt

Then run the entry test. The README's instruction is to run the doc command with each available runtime and observe which one completes without errors or warnings, rather than assuming the highest-priority runtime is the one that works.

python3 <skill_dir>/scripts/anysearch_cli.py doc

On a machine where python resolves to Python 3, python works too. On many macOS systems the README expects python3 to be the correct executable. If Python is unavailable, the equivalent entry test is node <skill_dir>/scripts/anysearch_cli.js doc, or the PowerShell and Bash variants shown in the README.

The API key step is optional. Anonymous access works, at lower rate limits and quota. To register, the README shows a single POST that needs only a real email address, no verification code.

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 has code 0 and returns the account plus a one-time plaintext key under data.api_key.key. The README's instruction to the agent is to write that value to .env as ANYSEARCH_API_KEY=<key> immediately, because it is shown only once. You can also copy .env.example to .env and fill the value in by hand.

cp .env.example .env
# then set ANYSEARCH_API_KEY=<your_api_key_here>

After that, the doc command is still the fastest way to confirm the key is being picked up, since a working key changes the quota the CLI reports rather than the shape of the output.

The registration flow is the sharpest edge in the project

The README is unusually explicit that registration and anonymous use are mutually exclusive, and that once a user picks one, the flow should not switch mid-way. That warning exists because the failure modes are unpleasant.

The email must be real and reachable, since it becomes the account username. If the address is already registered, the API returns email_already_registered and the README says explicitly not to retry; the user should sign in at the login_url instead. If the key creation fails after the account is created, the error message starts with Key creation failed. and contains the email and sign-in URL, and the README's instruction is to hand those to the user so they can create a key manually from the dashboard.

Rate limiting is handled by parsing the retry interval out of the message string, for example "Rate limited, retry after 300 seconds." Branching on message text rather than a numeric error code is fragile. The README does state that errors always return code -1, so the only machine-readable distinction is the message itself. If the service ever rewords those strings, any agent following the documented logic will misclassify the error.

The second limitation is scope. This is a skill, not a service. It has no documented SLA, no documented uptime figure, and no documented behaviour for partial batch failures beyond whatever the CLI returns. If your workload needs guaranteed throughput, a documented quota contract, or an audit trail, the README does not describe those, and you should treat that silence as a real gap rather than an oversight in the documentation.

How it compares with wiring an agent straight to a search API

The obvious alternative is to skip the skill layer and have your agent call a search API directly, which is what most agent frameworks do today. The difference is not capability, it is where the code lives. With a direct integration you own the HTTP client, the result normalisation and the runtime choice, and you can target any language your agent already runs. With AnySearch Skill you inherit four ready-made CLIs and a fixed directory layout, but you also inherit the project's runtime priority order and its dependency rules.

A second alternative is a browser or page-fetch tool already bundled with the agent platform. That approach returns rendered content and keeps everything inside one tool, but it does not give you parallel batch search or a vertical domain search mode as separate operations. The README presents batch search and full-page extraction as distinct capabilities alongside general web search, which suggests the project expects agents to choose between them per task rather than always fetching pages.

The trade-off worth naming: a direct API integration is easier to test in isolation, because you can mock the HTTP layer. A skill directory is easier to distribute, because installation is a zip and a move, and the same artifact works across hosts that have nothing else in common.

Maintenance, licensing and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-02, which coincides with the v3.1.1 release. The two prior releases are v3.1.0 on 2026-08-21, labelled as adding a direct HTTP CLI with REST-native search and batch improvements, and v3.0.1 on 2026-07-22, labelled as one-step registration, flattened sub_domain_params and CLI hardening. Three releases in roughly six weeks is a fast cadence, and the release labels suggest the CLI surface is still moving.

That cadence is the upgrade cost. Because installation is a pinned zip that you unzip and move into a skill directory, upgrading means repeating the download and the move. The README's own download comment tells you to replace v3.1.1 with the latest tag, which implies manual tag tracking rather than an auto-update path. If you have local modifications inside the skill directory, a re-download will not merge them.

SHA256SUMS.txt is present at the repository root, which gives you a way to verify a downloaded artifact against the published checksum. The README does not document a rollback procedure, so if a new tag breaks your agent, the recovery path is to re-download the previous tag and move it back into place.

The licence is Apache-2.0, and the repository carries both LICENSE and NOTICE files. Apache-2.0 permits commercial use and modification and includes a patent grant, but it also requires that you preserve the NOTICE file contents when you redistribute. If you fork the skill and ship it inside a product, read the NOTICE file rather than assuming the LICENSE alone tells the whole story. This is a description of the licence text, not legal advice.

Editorial conclusion

Adopt AnySearch Skill if your agent platform reads a skills directory and you want search, batch search and page extraction behind one CLI that runs on Python, Node.js, Bash or PowerShell. Skip it if you need a hosted search API with a documented SLA, or if you cannot accept that the registration flow creates an account from an email address in one call. Before rolling it out to a team, verify three things yourself: which runtime the entry test actually picks on each machine, whether anonymous quota is enough for your query volume, and where the API key ends up, since the README says it is shown only once and must be written to .env.

Frequently asked questions

Official sources

1. anysearch-ai/anysearch-skill on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases