For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/articles/anysearch-for-ai-agents-structured-search.md.
Search has become one of the most important external capabilities available to an AI agent. A strong model can reason well, but it cannot re...
Search has become one of the most important external capabilities available to an AI agent. A strong model can reason well, but it cannot recover a fact that was never retrieved, distinguish current information from stale reporting without evidence, or reliably infer a missing company record.
AnySearch approaches this problem as infrastructure for agents rather than as a search page for people. Instead of returning only links, titles, and short snippets, it aims to route a query to relevant web or vertical sources, remove duplicates and low-value material, extract the useful content, and deliver a structured response that can enter the model’s reasoning context directly.
The product ranked first on Product Hunt for both the day and the week of July 6, 2026. Its launch description emphasizes real-time, filtered, de-duplicated, structured information delivered through an API, MCP server, or installable agent Skill.
This article explains how that agent-oriented search workflow differs from a conventional search API, walks through the examples shown in the original report, and provides practical installation and evaluation guidance.
Benchmark note: The accuracy and latency figures below come from an AnySearch comparison reproduced by the source article. The public materials reviewed for this version did not include the complete evaluation code, raw outputs, judging prompts, or statistical analysis. Treat the figures as vendor-reported results rather than an independently reproduced benchmark.
A human can scan a page of results, ignore advertisements, recognize duplicate articles, and decide which links deserve attention.
An agent often receives every result as input. That creates several costs:
The problem is not only retrieval accuracy. It is the shape and density of the information returned.
A useful agent-search system should therefore answer three questions before passing information to the model:
AnySearch is designed around those steps.
AnySearch was Product Hunt’s number-one launch of the day and week for July 6, 2026. Product Hunt describes it as real-time structured search trusted by agents and developers, with filtered, de-duplicated information from sources searched in parallel.
The source article also presents a 300-question evaluation built from three benchmark groups:
It states that the same language model was used with AnySearch, Brave Search, and Parallel so that the search layer—not the model choice—was the main variable.
| Search system | Overall accuracy | FreshQA | WebWalkerQA |
|---|---|---|---|
| AnySearch | 76.4% | 80.0% | 65.2% |
| Brave Search | 64.0% | 74.0% | 46.8% |
| Parallel | 72.2% | 78.0% | 61.0% |
FreshQA evaluates questions that depend on current or changing information. WebWalkerQA focuses on navigating websites and locating evidence across multiple pages. Together, they are relevant to agents that need more than a shallow list of links.
FRAMES is named in the source’s combined evaluation, but the per-benchmark chart shown in the article displays only FreshQA and WebWalkerQA in addition to the combined score.
The latency chart reports lower values for AnySearch in both the average comparison and the WebWalkerQA subset.
| Search system | Average latency value | WebWalkerQA latency value |
|---|---|---|
| AnySearch | 48.0 | 76.5 |
| Brave Search | 68.9 | 133.0 |
| Parallel | 77.4 | 145.6 |
The source image does not label the unit clearly, so the table intentionally preserves the reported values without converting them into seconds or milliseconds.
AnySearch currently supports three main integration methods:
The official GitHub projects provide an Apache-2.0-licensed Skill and MCP server. Both support general web search, vertical-domain search, parallel batch search, and full-page URL extraction.
The official repository recommends downloading a pinned release rather than taking unreleased changes directly from the main branch.
# Download a pinned AnySearch Skill release.
# Check the releases page and replace v2.1.0 when a newer stable tag exists.
curl -L -o anysearch-skill.zip \
https://github.com/anysearch-ai/anysearch-skill/archive/refs/tags/v2.1.0.zip
# Extract the release.
unzip anysearch-skill.zip
Move the extracted directory into the location used by your agent:
# Claude Code
mv anysearch-skill-2.1.0 ~/.claude/skills/anysearch
# OpenCode
mv anysearch-skill-2.1.0 ~/.config/opencode/skills/anysearch
# Cursor or Windsurf project
mv anysearch-skill-2.1.0 /.skills/anysearch
# Shared agent location
mv anysearch-skill-2.1.0 ~/.agents/skills/anysearch
The exact directory depends on the agent platform and its current Skill-discovery rules.
The official Skill and MCP documentation says that anonymous access is available with lower rate limits. An API key is optional but recommended for higher or more predictable usage.
Do not commit an API key to a public repository. Store it in an environment variable, secret manager, or ignored local configuration file.
The first test in the source article asked the agent to find a real, production-oriented Go implementation of an API rate limiter rather than another introductory tutorial.
The prompt was:
I am building a project and need to implement an API rate limiter in Go. I do not want a tutorial. Find production-grade code from real open-source projects.
Without the specialized search workflow, the agent reportedly returned familiar links and isolated excerpts. That result may explain the concept, but it is less helpful when the developer needs the complete implementation context.
The AnySearch-assisted run returned a more structured code-oriented result with a clearer call chain and material drawn from actual repositories.
The distinction matters because production code is not only an algorithm. A useful search result should help the agent inspect:
A code search that extracts one attractive function without its surrounding assumptions can mislead an implementation agent.
A more explicit query can improve results regardless of the search provider:
Find maintained open-source Go projects that implement API rate limiting
in production code.
Requirements:
- Return repository and exact file paths.
- Prefer code used in a real server or gateway.
- Include initialization and request-flow context.
- Identify algorithm, backing store, tests, and license.
- Exclude tutorial repositories and copied snippets.
- Note the date of the latest relevant commit.
The search system should return evidence. The coding agent should still inspect the repository, license, tests, security assumptions, and current maintenance status before adapting the code.
The second test compared AnySearch and Exa on the same company-research request.
Both reports covered basic public company information reasonably well. The difference appeared in the risk section.
AnySearch reportedly found locally published compliance records and platform notices that were absent from the Exa-generated report. The source attributes this difference to access to Chinese vertical data sources rather than to the language model.
This example highlights a general limitation in company research: a global web index may provide strong coverage of an organization’s website, international reporting, and English-language databases while missing local regulatory, court, complaint, or platform records.
A due-diligence agent should search multiple categories explicitly:
Important: Search-assisted due diligence is not a substitute for professional legal, financial, or compliance review. Records may be incomplete, names may collide, and automated summaries can misinterpret evidence.
The third test asked AnySearch to generate a global energy-market report covering:
The output shown in the source includes regional inventory detail, European price comparisons, and emissions data. It cites recent information, including the US Energy Information Administration’s July 9 release and European day-ahead prices for July 12.
This is a good example of a multi-domain query. It requires the system to recognize that one request contains several independent data paths rather than one ordinary web search.
A reliable implementation should:
Current data should always include timestamps. “Latest” is not meaningful unless the report says when the underlying measurement was published and what period it covers.
The central design claim is that AnySearch rebuilds the retrieval pipeline around agent behavior.
The process shown in the source has five stages:
The system first identifies what kind of evidence the query requires.
A company-background request may need registration records, patents, legal databases, and complaint platforms. A code question should route to repositories and documentation. An energy-market request may require official inventory and electricity-market data.
Describe your idea once, and We0 AI can generate a showcase site, pages, and CMS, then help you attract customers and traffic after launch.
One complete project generation for free registration
Best for trying one complete generation flow and seeing a first project draft quickly.
This is different from sending every request through one generic index.
AnySearch says it supports general search plus more than 20 vertical categories covering areas such as:
The public MCP interface includes a domain-directory method. An agent is expected to request valid domains and parameter schemas rather than inventing unsupported filters.
A question that spans several domains can launch multiple independent searches. The MCP server supports batch execution of one to five query objects, and a failure in one branch does not have to block every other branch.
Parallel retrieval can reduce total waiting time, but only if the aggregation layer prevents fast low-quality results from crowding out slower authoritative evidence.
The original article describes three ranking ideas:
The intended outcome is to perform more filtering before content enters the language model.
That differs from a pipeline that returns a large result set and asks the model to remove duplicates itself. Pre-filtering can save tokens, but it introduces another responsibility: the ranking system must not silently remove a minority source or a critical contradictory record.
After ranking, AnySearch extracts the main content, removes page noise, and converts the result into Markdown.
The official MCP server also exposes a URL-extraction operation that returns page content as Markdown, with a documented truncation limit of 50,000 characters.
Structured output can reduce the work required from the model, especially when the result includes:
Suppose an agent receives ten results about one event. If seven are rewrites of the same original report, the context contains repeated claims rather than seven independent confirmations.
That causes three problems:
Source-aware de-duplication tries to preserve distinct evidence rather than simply preserving the highest-ranked pages.
A practical agent-search response should make provenance visible. Developers need to know whether five results represent five original sources, five syndications of one source, or a mixture of primary and secondary evidence.
The source describes lower token consumption as a benefit of AnySearch, but it does not publish one universal token-reduction percentage.
That is appropriate because savings depend on:
A fair evaluation should measure the complete task, not only the first search response.
Useful metrics include:
| Metric | What it measures |
|---|---|
| Search input tokens | Context consumed by retrieved material |
| Total agent tokens | Search, reasoning, follow-up, and final generation |
| Search calls per task | Whether weak retrieval causes repeated searches |
| Distinct source count | Evidence diversity after de-duplication |
| Citation precision | Whether cited sources support the claims |
| Answer completeness | Whether the response covers required dimensions |
| End-to-end latency | Time until the task is usable |
| Task success rate | Whether the agent completes the intended job |
A short response that omits critical evidence is not an optimization. Token reduction is valuable only when answer quality and traceability are preserved.
A search component used in production must handle failures that rarely appear in a product demonstration.
The source highlights:
The public MCP documentation also supports:
Production teams should still add their own controls:
Search output is untrusted external input. Clean Markdown can still contain malicious instructions, fabricated claims, or compromised content.
Traditional search helps a person locate a page. Agent search has a different objective: deliver evidence that a machine can use in reasoning and execution.
That changes the design priorities.
| Human-oriented search | Agent-oriented search |
|---|---|
| Optimized for scanning | Optimized for machine ingestion |
| Links and snippets | Structured evidence |
| User removes duplicates | System should reduce duplicates |
| User notices stale dates | Dates should be explicit |
| User decides what to trust | Provenance and quality signals are required |
| Browsing can be exploratory | Repeated searches consume time and tokens |
| Visual layout matters | Stable schemas and Markdown matter |
The model determines how well an agent can reason with evidence. The search layer determines which evidence is available in the first place.
As model capability improves, retrieval quality becomes more—not less—important. A powerful model can produce a highly persuasive answer from weak context. That makes source selection, freshness, and traceability part of the agent’s safety and reliability system.
A developer should not select a search provider from one public benchmark or one impressive example.
Build an evaluation set from the actual tasks your agent performs.
Include easy and difficult cases:
Use the same model, prompt, tool policy, and output schema for each provider.
Store the returned sources before the model summarizes them. Otherwise, you cannot determine whether an error came from retrieval or reasoning.
Measure latency, total tokens, repeated search calls, coverage, citation support, freshness, and failure rate.
Financial, legal, security, medical, and compliance tasks require expert review. A search API can improve evidence collection but cannot assume professional responsibility.
Disable one source, slow down one route, return malformed content, and inject duplicate results. Production reliability depends on how the system behaves when retrieval is imperfect.
AnySearch is a real-time search infrastructure service designed for AI agents and developers. It provides web search, vertical-domain search, batch search, and full-page extraction with structured output.
It has a website where people can try searches, but its main positioning is agent infrastructure. The core integrations are API, MCP, and an installable Skill.
The official Skill and MCP documentation says anonymous access is supported with lower rate limits and quota. An API key is optional but recommended for more regular use.
The public documentation mentions finance, academic research, security, legal information, code, and additional categories. Agents should query the supported domain directory before using domain-specific parameters.
It attempts to route queries before retrieval, reduce repeated sources, prioritize information-dense results, remove page noise, and return structured Markdown. Actual token savings depend on the query and the wider agent workflow.
The score is reported by AnySearch and reproduced in the source article. The full public evaluation package was not found during verification, so the result should be treated as a vendor-reported comparison.
No. It can help collect company, legal, financial, and public-risk information, but professionals must verify identity, source authority, completeness, jurisdiction, and interpretation.
The AnySearch Skill and MCP server repositories are public under the Apache-2.0 license. The hosted API backend is a separate service and is not covered by those repository licenses.
AnySearch treats search as an input layer for agents rather than as a list of pages for people. It routes queries across general and vertical sources, searches multiple paths, ranks and de-duplicates evidence, removes page noise, and returns structured content through API, MCP, or Skill integrations.
The examples in the source show why that design matters for production code discovery, local company due diligence, and current multi-market data. In each case, the agent needs complete, timely, and traceable evidence—not only relevant links.
Its Product Hunt ranking and vendor-reported benchmark results make AnySearch worth testing, but teams should reproduce the comparison with their own queries, model, token accounting, and quality criteria before changing a production retrieval stack.
In an agent workflow, the model decides what to do with the evidence; the search layer decides whether the right evidence ever reaches the model.
Start from one sentence and have a complete website in minutes.
