Integrates Brave Search as an optional paid search engine with a free tier, providing web search results that can be used alongside free engines for enhanced coverage.
Integrates DuckDuckGo as a free, privacy-focused search engine for web search results, used by default for global queries.
Integrates Sogou as a free Chinese search engine for web search results, used by default for Chinese language queries and coverage.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Agent Search MCP search for MCP server best practices"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
๐ Free multi-source search for AI agents โ multi-source verification, token savings, MCP native.
Works with Hermes, Claude Code, Cursor, Windsurf, OpenClaw, and any MCP-compatible client.
English ยท ไธญๆ ยท ๅฎ่ฃ ยท ๆๆกฃ
# Option 1: npx (recommended)
npx agent-search-mcp
# Option 2: global install
npm install -g agent-search-mcp# ~/.hermes/config.yaml
mcp_servers:
agent-search:
command: npx
args: ["agent-search-mcp"]// ~/.claude/mcp.json
{
"mcpServers": {
"agent-search": {
"command": "npx",
"args": ["agent-search-mcp"]
}
}
}// .cursor/mcp.json
{
"mcpServers": {
"agent-search": {
"command": "npx",
"args": ["agent-search-mcp"]
}
}
}// ~/.codeium/windsurf/mcp_config.json
{
"mcpServers": {
"agent-search": {
"command": "npx",
"args": ["agent-search-mcp"]
}
}
}// openclaw.config.ts
{
mcpServers: {
"agent-search": {
command: "npx",
args: ["agent-search-mcp"]
}
}
}Related MCP server: GroundRoute
No API key required. Uses DuckDuckGo + Sogou search engines.
Engine | Type | API Key | Coverage |
DuckDuckGo | Free | โ | Global |
Sogou | Free | โ | Chinese |
Brave Search | Paid (Free Tier) | Optional | Global |
Tavily | Paid (Free Tier) | Optional | Global |
Results are verified across multiple search engines. Each result includes a confidence score (1-3) based on how many engines returned it.
{
"title": "Build an MCP Server",
"url": "https://example.com/mcp",
"snippet": "How to build MCP servers...",
"confidence": 2 // Verified by 2 engines
}Optimized output reduces token consumption by ~40-50%:
Optimization | Savings |
Top-1 snippet per URL | ~25% |
Title truncation (โค100 chars) | ~15% |
Snippet truncation (โค200 chars) | ~15% |
Deduplication | ~10% |
Confidence filtering | ~10% |
Three tools, discoverable by agents:
Tool | Purpose | When to Use |
| Basic search | Quick questions |
| Filtered search | Date ranges, domains, high confidence |
| URL extraction | Read full page content |
free_searchBasic web search with multi-source verification.
{
"query": "TypeScript MCP server",
"count": 5
}free_search_advancedAdvanced search with filters.
{
"query": "MCP server",
"count": 10,
"min_confidence": 2,
"time_range": "week",
"language": "zh",
"include_domains": ["github.com"],
"exclude_domains": ["reddit.com"]
}Parameters:
min_confidence (1-3): Only return results verified by N+ sources
time_range: day, week, month, year
language: auto, en, zh
include_domains: Only search these domains
exclude_domains: Exclude these domains
free_extractExtract full content from a URL as Markdown.
{
"url": "https://example.com/article",
"max_length": 5000
}search://capabilitiesReturns a Markdown document describing all available tools and features. Agents can discover capabilities on-demand.
search://healthReturns JSON with health status of each search provider:
[
{
"provider": "duckduckgo",
"lastSuccess": 1719000000000,
"errorCount": 0,
"avgLatency": 450,
"isHealthy": true
}
]Variable | Description | Required |
| Brave Search API key (2000 free/month) | No |
| Tavily API key (1000 free/month) | No |
| Log level (info, debug) | No |
Zero config works โ no API keys needed for basic search.
Set environment variables to enable fallback to paid engines when free results are insufficient:
export BRAVE_API_KEY=your_key_here
export TAVILY_API_KEY=your_key_hereAgent
โ MCP Protocol (stdio)
MCP Server
โโโ Tools Layer (progressive disclosure)
โ โโโ free_search (default)
โ โโโ free_search_advanced (optional)
โ โโโ free_extract (optional)
โโโ Aggregation Layer
โ โโโ Top-1 Snippet merge
โ โโโ URL + Title dedup
โ โโโ Scoring + Confidence
โ โโโ Output truncation
โโโ Fallback Chain
โ โโโ Phase 1: Free engines (DDG + Sogou)
โ โโโ Phase 2: Paid engines (Brave + Tavily)
โโโ Infrastructure
โโโ Cache (LRU, 60s TTL)
โโโ Rate Limiter (1s per provider)
โโโ Health Tracker
โโโ SSRF ProtectionDocument | Description |
Product Requirements Document | |
Technical Architecture | |
Implementation Plan | |
5-Team Review Results | |
Fork & Modification Plan | |
Version History |
# Clone
git clone https://github.com/lennney/agent-search-mcp.git
cd agent-search-mcp
# Install
npm install
# Build
npm run build
# Test
npm test
# Run
npm startBased on open-websearch by Aas-ee.
Copyright 2025 Open-WebSearch MCP Server Contributors
Based on open-websearch by Aas-ee (Apache 2.0).
Modified by Agent Search MCP Contributors.
Copyright 2026 Agent Search MCP ContributorsContributions welcome! Please read CONTRIBUTING.md first.
MCP server, Model Context Protocol, AI agent search, free web search, multi-source search, DuckDuckGo MCP, Sogou search, token optimization, Hermes MCP, Claude Code MCP, Cursor MCP, AI tool, web search for agents, search aggregation, confidence scoring
Extract full content from a URL. Returns clean markdown.
Best for: Reading a specific page found in search results. Not recommended for: Bulk extraction โ use search first.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to extract | |
| max_length | No | Max characters to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses the output format (clean markdown) and that it extracts full content. However, it does not mention potential behaviors like handling redirects, error responses, or rate limits. Given the simplicity, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with front-loaded purpose and clear usage guidelines. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, but the description clarifies the return type (clean markdown). It provides enough context for a simple extraction tool, though it could mention error handling or limitations. Overall, it is complete for its scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both parameters (url and max_length). The description does not add new parameter details beyond what the schema already provides, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts full content from a URL and returns clean markdown. It distinguishes itself from sibling tools like free_search and free_search_advanced by specifying it is for reading a specific page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('Best for: Reading a specific page found in search results') and when not to use it ('Not recommended for: Bulk extraction โ use search first'), providing clear guidance and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web with automatic fallback between free and paid engines. Phase 1: DuckDuckGo + Sogou (free, no key required). Phase 2: Brave + Tavily (paid, requires BRAVE_API_KEY / TAVILY_API_KEY env vars). All results are deduplicated, scored, and ranked.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limit | No | Number of results to return (1-50) | |
| engines | No | Search engines to use (default: duckduckgo) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description fully discloses behavioral traits: automatic fallback between free/paid engines, required API keys, deduplication, scoring, and ranking. This is comprehensive and leaves no ambiguity about the tool's operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the core purpose. Every sentence adds value: purpose, phases with requirements, and output behavior (deduplication, scoring, ranking). No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema, the description is fairly complete. It explains the fallback, engine requirements, and output quality. However, it does not describe the structure of the return value, which might require the agent to infer an ordered list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes 'limit' and 'engines' parameters, but the description adds context by mapping engines to phases and explaining free vs. paid. However, the 'query' parameter lacks additional semantic explanation beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool searches the web with automatic fallback between free and paid engines, and specifies the two phases and engines. It distinguishes itself from siblings by emphasizing the automatic fallback mechanism, which is a unique selling point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not explicitly state when to use it versus the sibling tools 'free_extract' or 'free_search_advanced'. It lacks guidance on alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Advanced search with filters and quality control.
Best for: Date ranges, domain filtering, high-confidence only, Chinese content. Not recommended for: Simple queries โ use free_search instead.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| count | No | Number of results (1-20) | |
| min_confidence | No | Only return results verified by N+ sources | |
| time_range | No | Filter by recency | |
| language | No | Language preference | auto |
| include_domains | No | Only search these domains | |
| exclude_domains | No | Exclude these domains |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. While it mentions 'quality control' and parameter min_confidence implies verification, it doesn't detail aspects like result ordering, rate limits, or output structure. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence stating purpose, then bullet-like lists for best/not recommended. No wasted words, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description should hint at return structure, but it doesn't. The tool's function (search results) is clear, but details like result format or pagination are missing. Adequate for basic use but incomplete for complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description adds high-level context ('filters and quality control') but no additional meaning beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Advanced search with filters and quality control' and distinguishes from sibling 'free_search' by specifying best for date ranges, domain filtering, high-confidence, Chinese content. It also explicitly says not for simple queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use ('Best for: Date ranges, domain filtering, high-confidence only, Chinese content') and when-not-to-use ('Not recommended for: Simple queries โ use free_search instead'), directly referencing a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0free_extractfree_searchfree_search_advancedScored across 3 tools
Each tool has a distinctly different purpose: basic search (free_search), advanced search with filters (free_search_advanced), and content extraction from URLs (free_extract). No overlap.
All tools share the 'free_' prefix. While 'free_search' and 'free_search_advanced' follow a noun-modifier pattern, 'free_extract' uses a verb form, creating a minor inconsistency.
Three tools cover the essential functionality of a search server (search, advanced search, and content extraction) without redundancy or excess.
Core needs are met, but advanced features like pagination, result count control, or batch operations are absent, which could be limiting for complex workflows.
Web search for AI agents โ one tool across 6 engines, routed to the cheapest + cached.
The best web search for your AI Agent
Agent-native search engine with live web research optimized for AI agents.
Multi-engine search for AI agents. Trust scoring, local corpus, MCP-native. Self-hostable, BYOK.
