Agent Search MCP
A free, multi-source web search MCP server enabling AI agents to search the internet with no API key required, offering advanced filtering, content extraction, and token-optimized results.
Tools:
free_search— Basic web search via DuckDuckGo, Sogou, Brave, or Tavily. Results are automatically deduplicated, scored, and ranked (1–50 results).free_search_advanced— Filtered search with controls for recency (day/week/month/year), language (auto/en/zh), minimum confidence score (1–3), domain inclusion/exclusion, and result count (1–20).free_extract— Extract the full content of a URL as clean Markdown, with configurable max length (default: 5000 chars).
Key Features:
No API key required for basic functionality (DuckDuckGo + Sogou work out of the box)
Multi-engine fallback chain: Free engines first; paid engines (Brave/Tavily) auto-enabled when API keys are set
Confidence scoring: Each result scored 1–3 based on how many sources returned it
Token optimization: Titles capped at 100 chars, snippets at 200 chars; deduplication reduces token usage ~40–50%
Chinese web search via Sogou integration
Built-in security: Prompt injection detection, phishing URL filtering, output boundary markers
Real-time provider health tracking with automatic filtering of unhealthy providers
Self-hostable: Data stays on your own infrastructure
CLI support: Run searches, extract pages, or start an HTTP server from the terminal
Compatible with Claude Code, Cursor, Windsurf, Codex, and other MCP clients
Provides global web search as a paid fallback engine, with rate limits (2000 free queries/month).
Provides free global web search without an API key, used as a core engine for multi-source verification.
Provides free Chinese web search without an API key, enabling native Chinese language results.
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 MCPsearch for latest AI news"
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.
Agent Search MCP: Free-first Web Search with Inspectable Evidence
A Node.js MCP server and CLI for English and Chinese web search.
Agent Search MCP starts without an API key. It returns compact multi-source evidence, records provider failures, and bounds work with request and evidence budgets. Paid providers run only when policy and credentials allow.
中文文档 · Product page · Benchmarks · Architecture · CHANGELOG
Install
npx -y agent-search-mcpRequires Node.js >= 18.17. The default runtime does not require a browser, database, Python, or a search API account.
Connect an MCP client
Use this stdio configuration in MCP clients that accept mcpServers JSON,
including Claude Desktop, Cursor, VS Code, and Windsurf:
{
"mcpServers": {
"agent-search": {
"command": "npx",
"args": ["-y", "agent-search-mcp"]
}
}
}Claude Code and Codex can register the same npx -y agent-search-mcp stdio
command through their MCP settings.
Add the optional Agent Skill
After connecting the MCP server, Agent Skills-compatible clients can install the repository-owned routing guide:
npx skills add lennney/agent-search-mcp --skill agent-searchInvoke it with a request such as Use $agent-search to verify this claim with official sources. The Agent Search Skill
chooses one of four bounded paths: quick discovery, stricter verification,
Chinese-source search, or extraction of a selected URL. It checks that the
needed MCP tool exists and asks before any install or configuration change.
Installing the Skill does not start or configure the MCP server.
Example: inspect a bounded search result
After building the local package, run a CLI query without adding a provider key:
npm run build
fasm search "MCP server without an API key" --jsonThe response contract keeps result evidence, meta.execution, and
partialFailures separate. A provider timeout or challenge remains visible to
the agent instead of being converted into an unexplained empty result. This is
a contract example, not a live availability or search-quality benchmark.
After a global install, check the local runtime without making a search request:
npm install -g agent-search-mcp
fasm doctorRelated MCP server: websearch-skill
Why Agent Search MCP
Need | Product behavior |
Free web search | Zero-key sources work without an API account |
Provider cost control | Paid providers run only under an explicit routing policy |
Token cost control | Compact output and one evidence budget bound response size |
Multi-source evidence | Results retain provenance, relevance, provider-family count, and partial failures |
Chinese web search | Sogou and Baidu handle Chinese queries without a translation layer |
Lightweight self-hosting | Pure Node.js runtime with stdio, Streamable HTTP, and CLI access |
The difference from a plain multi-engine wrapper
Plain multi-engine aggregation | Agent Search MCP |
Returns N deduplicated results | Returns results plus the number of independent sources (provider families, not adapter names) |
A provider failure quietly drops some results | Every failure stays in |
Stops when the result count looks sufficient | Stops only after a quality gate (count, relevance, confidence, source coverage) and returns the |
Fixed-size output | One shared evidence budget bounds response tokens; compact text keeps provenance |
One adapter counts as one source | The same upstream through several adapters never inflates |
The one-minute offline demo replays these differences through the production evidence scorer and formatter:
Inspect the search evidence
Each JSON response includes one Search Evidence Packet. It answers the routing questions an agent needs before it uses a result:
Question | Response field |
Which adapters ran? |
|
Why did the router stop? |
|
Did the request hit a work limit? |
|
Was evidence truncated? |
|
Did an upstream provider fail? |
|
Do multiple adapters represent independent sources? |
|
Run the one-minute offline contract demo:
npm run demo:evidence
npm run demo:evidence -- --jsonIt replays three synthetic scenarios through the production evidence scorer, formatter, and MCP output helper: same-family adapter overlap, visible fallback failure, and a bounded quality-gate stop. It makes no live availability or search-quality claim and performs no network request.
The default free_first policy never spends a configured API credential.
free_only blocks paid providers. quality_escalation can call one configured
paid provider after free evidence misses the quality gate, while paid_first
tries that provider before the free fallback.
Request budgets cap adapter attempts, elapsed time, and admitted results. The evidence budget caps query-relevant passages across the complete response. Compact mode keeps full detail for the first results and reduces later entries to source-preserving references.
Measured token reduction
The checked-in bilingual fixture measures formatting with a locked tokenizer:
Output | Average tokens per query | Savings vs normal |
Normal | 2396.0 | |
Compact | 1650.1 | 31.1% |
Compact+ | 1633.0 | 31.8% |
This fixture verifies output formatting and evidence-packet behavior. It does not measure live engine availability or search quality. See the benchmark method and limitations.
How the search router works
flowchart LR
A["AI agent"] --> M["MCP search tools"]
M --> P["Provider and request policy"]
P --> F["Zero-key sources"]
P --> O["Optional paid provider"]
F --> E["Deduplicate, rank, and preserve failures"]
O --> E
E --> B["Evidence and token budget"]
B --> R["Compact multi-source result"]The router evaluates each search batch against separate result, relevance,
confidence, and provider-family gates. It stops after the evidence passes those
gates and exposes the decision in meta.execution. Provider failures stay
visible in partialFailures, so an empty result cannot hide an upstream error.
The competitive landscape (2026-08-07) maps the crowded baseline and the product gaps. It records source dates and fixed commits for facts that can change. The 2026-08-10 update adds competitor activity since then: direct local competitors are dormant, and token-efficient evidence is becoming an industry-explicit lever. The earlier source-level product comparison contains the architecture-specific evidence.
Engines
The runtime registers 16 adapters: 9 zero-key adapters and 7 optional API adapters.
Engine | Access | Languages | Role |
DuckDuckGo | Zero-key | en | General Web Search |
Sogou Search | Zero-key | zh | Chinese Web Search |
Bing | Zero-key | en, zh | Multilingual Web Search |
Baidu | Zero-key | zh | Chinese Web Search |
Wikipedia | Zero-key | en, zh, ja, de, fr, es, auto | Encyclopedic references |
Startpage | Zero-key | en, auto | Privacy-oriented Web Search |
Yandex | Zero-key | ru, en, auto | Russian and international Web Search |
Mojeek | Zero-key | en, auto | Independent privacy-oriented index |
Wiby | Zero-key | en | Independent small-Web index |
Brave Search |
| en, zh | Optional commercial Web Search |
Tavily Search |
| en, zh | Optional agent-oriented Search |
Exa Search |
| en, zh | Optional neural Search |
You.com Search |
| en, zh | Optional commercial Web Search |
Tencent Web Search API |
| zh | Optional official Chinese Web Search |
Bocha Web Search |
| zh, en | Optional Chinese-first AI Search |
Serper Google Search |
| en, zh, auto | Optional Google SERP Search |
Tools
Tool | Description | Best for |
| Multi-engine Web Search with bounded fallback | Quick facts and general discovery |
| Filtered waterfall search and optional enrichment | Domain policy and progressive verification |
| Extract a URL as clean Markdown | Reading complete source pages |
| Fetch a public GitHub repository README | Project documentation |
| Fetch a CSDN article | Chinese technical articles |
| Fetch a Juejin article | Chinese developer articles |
| Search evidence with an LLM synthesis hint | Agent-authored answers from cited evidence |
Capability controls
Environment | Default | Purpose |
| all / none | Tool registration allowlist and denylist; deny wins |
| all / none | Engine execution allowlist and denylist; deny wins |
| free_first | Default routing: free_first, quality_escalation, paid_first, or free_only |
| brave,exa,tavily,youcom,tencent_wsa,bocha,serper | Selects the first configured optional provider; not a quality claim |
| 16 | Adapter-attempt budget |
| 30000 | End-to-end elapsed-time budget |
| 100 | Admitted raw-result budget |
| 1200 | Evidence-character budget |
search_with_synthesis uses the same canonical structuredContent evidence
packet as the primary search tools and adds prompt_hint; its text content is
only a compact compatibility view. Execution metadata distinguishes scheduled
adapters from retry-inclusive adapter attempts. http_requests is null until
all adapter transports can report it without false precision.
Wiby is a genuine zero-key source backed by its official JSON API and is used late in the free waterfall as an independent small-Web supplement. Optional providers require user credentials; any signup credit or trial quota is provider-controlled and is not treated as permanent free access.
All tools are read-only and idempotent. Search cancellation reaches rate-limit waits, retries, provider requests, and optional enrichment. Enrichment can improve a snippet but cannot increase source confidence or independent source count.
free_search_advanced.time_range remains in the compatibility schema. The
server returns UNSUPPORTED_FILTER before searching because the general web
providers do not share one enforceable recency contract.
Configuration
The generated capability table above lists the default request budgets. These settings cover the common deployment choices:
Goal | Environment variables |
Add an optional provider |
|
Choose spend policy |
|
Reduce response tokens |
|
Restrict tools or engines |
|
Use an explicit proxy |
|
Use a user-owned proxy pool |
|
Persist the exact-result cache |
|
Enable optional semantic processing |
|
Adding an API key does not authorize paid traffic. The routing policy controls
provider use. The default exact-result cache stays in memory; setting
SEARCH_CACHE_DIRECTORY opts into local persistence. Semantic processing is
the only optional feature that uses Python and Model2Vec.
Proxy pools select a deterministic first exit from the logical query and keep
multi-step provider requests sticky. Only a transport failure can move to the
next configured exit; a failed transport is cooled for 60 seconds. HTTP
responses, including 403, 429, and challenge pages, never trigger proxy
switching and continue through the provider's existing cooldown contract.
Engine-specific single-proxy variables take precedence over their pool. Proxy
credentials are never printed by fasm doctor.
HTTP deployment
HTTP mode requires HTTP_AUTH_TOKEN unless you set
HTTP_ALLOW_UNAUTHENTICATED=true. Browser requests with an Origin header must
match ALLOWED_ORIGINS. See the HTTP deployment guide
for TLS termination, token rotation, and reverse-proxy examples.
CLI
The package includes the fasm CLI:
fasm search "TypeScript MCP server"
fasm search "query" --count 5 --engines bing,baidu,youcom --json
fasm extract "https://example.com"
fasm extract "https://example.com" --json
fasm doctor
fasm doctor --json
HTTP_AUTH_TOKEN=change-me MODE=http npx agent-search-mcpfasm doctor reads local configuration without network probes and never prints
credential or proxy values.
Documentation and evidence
Document | Contents |
Routing, evidence, provider families, and configuration | |
Competitor activity through 2026-08-10, positioning, and improvement priorities | |
Baseline competitors, expectations, and product gaps snapshot | |
Source-level review of Agent search products | |
Token fixture, live-run scope, and quality evaluation method | |
Provider policy, budgets, and migration notes | |
Pre-expansion packed-install matrix and limitations | |
Isolated protocol experiment and remaining gates |
Companion: Slim Guard
Agent Search controls retrieval work and compresses search evidence. mcp-slim-guard sits between an agent and MCP servers to handle tool-schema compression and security policy.
npm install -g mcp-slim-guardDevelopment
git clone https://github.com/lennney/agent-search-mcp.git
cd agent-search-mcp
npm install
npm run build
npm test
npm run dev # stdio mode
npm run dev:http # HTTP mode (port 3000)The stable package supports Node.js 18, 20, and 22. The isolated MCP 2026 experiment requires Node.js 20 or newer.
License
Based on open-websearch by Aas-ee.
If Agent Search MCP helps your agent, star the repository so other developers can find the project.
Available Tools
7 toolsfetch_csdn_articleARead-onlyIdempotent
Fetch content from a CSDN blog article.
Best for: Chinese developer blog content on CSDN. Not recommended for: Other Chinese sites — use free_extract instead.
@readOnly true @idempotent true — makes outbound HTTP requests to the CSDN article URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | HTTPS article URL on blog.csdn.net |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds 'makes outbound HTTP requests to the CSDN article URL', confirming the network call. This adds context beyond annotations, but does not introduce new safety concerns.
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?
Three succinct sentences with no wasted words. Front-loads the core purpose, then usage guidelines, and then behavioral notes. Highly efficient.
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, yet the description does not specify what format the fetched content returns (e.g., plain text, markdown). This is a notable gap, though the tool is simple with one parameter.
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 description coverage is 100% with the url parameter well-described. The tool description does not add further meaning beyond the schema, so baseline 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?
Clearly states 'Fetch content from a CSDN blog article.' and distinguishes from siblings by specifying it is for CSDN and not for other Chinese sites, with an alternative tool named (free_extract).
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?
Provides explicit 'Best for' and 'Not recommended for' guidance, including a specific alternative tool. This directly helps an agent decide when 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.
fetch_github_readmeARead-onlyIdempotent
Fetch README content from a GitHub repository.
Best for: Getting project documentation quickly. Not recommended for: Non-GitHub URLs — use free_extract instead.
@readOnly true @idempotent true — makes outbound HTTP requests to raw.githubusercontent.com.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | GitHub repository URL (e.g., https://github.com/owner/repo) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint true, and the description adds that it 'makes outbound HTTP requests to raw.githubusercontent.com', providing useful behavioral context beyond the annotations. No contradictions.
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?
Description is very concise with two sentences and clear labels (Best for, Not recommended for). Front-loaded with action, and every sentence adds value. No 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?
For a simple tool with one parameter and no output schema, the description covers purpose, usage guidelines, behavioral details, and distinguishes from siblings. It does not specify the return format (markdown?), but that is a minor omission given the overall clarity.
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 description coverage is 100%, so the schema already documents the single parameter. The tool description does not add extra meaning beyond the schema, so 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 'Fetch README content from a GitHub repository' with specific verb and resource, and distinguishes from siblings by noting that non-GitHub URLs should use free_extract instead.
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?
Explicitly provides best-use case ('Getting project documentation quickly') and a clear exclusion ('Not recommended for: Non-GitHub URLs — use free_extract instead'), offering direct guidance on when 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.
fetch_juejin_articleARead-onlyIdempotent
Fetch content from a Juejin article.
Best for: Chinese developer articles on Juejin. Not recommended for: Non-Juejin content — use free_extract instead.
@readOnly true @idempotent true — makes outbound HTTP requests to juejin.cn API.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Juejin article URL |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe, repeatable usage. The description adds that it makes outbound HTTP requests to juejin.cn API, providing operational context beyond the annotations. No contradictions.
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 concise: three sentences plus annotation indicators. It is front-loaded with the main purpose and provides usage guidance efficiently. No extraneous text.
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 description lacks information about the output format (e.g., plain text, HTML, metadata). Given no output schema, the agent would benefit from knowing what the tool returns. This omission reduces completeness for a fetch operation.
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% description coverage for the single 'url' parameter, which is described as 'Juejin article URL'. The tool description further associates it with Juejin content but does not add detailed semantics like expected URL format or constraints 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 the tool's function: 'Fetch content from a Juejin article'. It distinguishes it from siblings by specifying Juejin as the source and mentioning free_extract for non-Juejin content.
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?
Provides explicit guidance: 'Best for: Chinese developer articles on Juejin' and 'Not recommended for: Non-Juejin content — use free_extract instead'. Also notes the tool makes outbound HTTP requests, which is relevant for usage considerations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
free_extractARead-onlyIdempotent
Extract full content from a URL. Returns clean markdown text.
Best for: Reading a specific page found in search results to get full context. Not recommended for: Bulk extraction — use free_search first to find relevant pages.
Behavior: Makes an outbound HTTP request to Jina Reader (r.jina.ai) which fetches and converts the page to markdown. Has SSRF protection: blocks private IPs, localhost, and metadata endpoints. 10s request timeout — pages exceeding this will fail with a timeout error. HTTP errors (4xx, 5xx) are returned as structured error responses.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to extract content from. Supports any public web page URL (http/https). For best results, use a complete URL including the protocol (https://). | |
| max_length | No | Maximum characters to return (default: 5000). Content beyond this limit is truncated. Increase for long articles, decrease for quick snippets. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, but the description adds valuable behavioral details: outbound HTTP request via Jina Reader, SSRF protection, 10s timeout, and error handling. No contradiction with annotations.
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 front-loaded with the core purpose, then structured with bullet-like sections for usage guidance and behavior. Every sentence is informative and nothing is redundant.
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?
Given the tool's simplicity (2 parameters, no output schema) and rich annotations, the description covers behavioral constraints, error handling, and use cases comprehensively.
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 detailed descriptions for both parameters. The description does not add new semantics beyond the schema, so a baseline 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 states a specific verb 'Extract full content from a URL' and clarifies the output as 'clean markdown text'. It distinguishes from sibling tools like free_search (search) and site-specific fetchers by focusing on general page extraction.
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?
Explicitly provides 'Best for' (reading a specific page from search results) and 'Not recommended for' (bulk extraction) with an alternative (free_search), guiding the agent on when 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.
free_searchARead-onlyIdempotent
Search the web with an explicit adapter set and bounded fallback.
Best for: Quick fact-finding, general search, when date/domain filters are not needed. Not recommended for: Filtered or verified-only results — use free_search_advanced. For full page content — use free_extract.
Twelve adapters are selectable; the default request uses DuckDuckGo + Sogou only. Adapters that share one upstream family are tried sequentially on failure and never double-count as corroboration. Explicitly requested optional API adapters run only when credentials are present and the free basket is short or below the quality gate. Results are deduplicated and include separate confidence, relevance, and source-count signals.
@readOnly true @idempotent true — makes outbound HTTP requests to configured search engines. Injection detection and SSRF protection active.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return (1-50). Default 10. Higher values increase token usage. | |
| query | Yes | Search query string. Use natural language (e.g., "latest AI news 2026"). For Chinese coverage, include Sogou or Baidu in engines. | |
| engines | No | Search engines to use (default: duckduckgo + sogou). Free engines work without API keys. Optional API engines require their corresponding environment-variable credentials. For Chinese results, include sogou or baidu. |
Output Schema
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| query | Yes | |
| engines | Yes | |
| results | Yes | |
| cache_hit | No | |
| rate_limits | No | |
| security_note | Yes | |
| partialFailures | No | |
| detected_language | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnly and idempotent annotations, the description details adapter fallback behavior, optional API credentials, deduplication, confidence signals, and security protections.
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 well-structured and concise, with each section serving a clear purpose: main action, usage guidelines, internal behavior, and safety notes.
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?
Given the tool's complexity (multiple engines, dedup, signals, security), the description covers all essential behavioral aspects and appropriate usage context, leaving no major gaps.
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?
Input schema already has 100% description coverage; the description adds context like Chinese coverage with Sogou/Baidu and notes about default engines and credentials, enhancing parameter understanding.
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 'Search the web' and distinguishes from siblings by explicitly naming free_search_advanced for filtered/verified results and free_extract for full page content.
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 'Best for' and 'Not recommended for' sections, directly stating when to use and when to use alternatives, including sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
free_search_advancedARead-onlyIdempotent
Advanced search with filters and quality control.
Best for: Domain filtering, high-confidence only, Chinese content. Not recommended for: Simple queries — use free_search instead.
@readOnly true @idempotent true — runs waterfall progressive search across policy-allowed engines. Makes outbound HTTP requests to search engines and optionally to Jina Reader for content enrichment.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results (1-20) | |
| query | Yes | Search query | |
| enrich | No | Enable content enrichment (extract full page for low-confidence results) | |
| language | No | Language preference | auto |
| waterfall | No | Enable waterfall progressive search (saves engine calls) | |
| enrich_max | No | Max results to enrich per search | |
| time_range | No | Deprecated compatibility field; returns UNSUPPORTED_FILTER because general-search recency is not enforced end to end | |
| min_confidence | No | Minimum source-reliability confidence (0-1). Legacy values 2-3 are treated as min_source_count. | |
| exclude_domains | No | Exclude these domains | |
| include_domains | No | Only search these domains | |
| min_source_count | No | Minimum independent upstream provider families; current adapters expose at most 12 | |
| waterfall_min_results | No | Minimum results per phase for waterfall confidence check | |
| waterfall_min_confidence | No | Minimum average confidence to stop waterfall early |
Output Schema
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| query | Yes | |
| engines | Yes | |
| results | Yes | |
| cache_hit | No | |
| rate_limits | No | |
| security_note | Yes | |
| partialFailures | No | |
| detected_language | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds valuable context: 'runs waterfall progressive search across policy-allowed engines. Makes outbound HTTP requests to search engines and optionally to Jina Reader for content enrichment.' This explains the tool's external calls and algorithmic behavior beyond the annotations.
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 very concise: three sentences plus two lines. The structure clearly separates purpose, best-for, and behavioral notes. Every sentence adds value, with no 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 13 parameters and an output schema. The description explains the high-level search mechanism (waterfall, enrichment, engine calls), which is sufficient for understanding. However, it could briefly mention the confidence waterfall logic to improve completeness, but it's still strong.
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 description coverage is 100%, so all parameters already have descriptions. The tool description adds general context about waterfall and enrichment but does not add specific parameter-level details beyond what the schema provides. Baseline 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 starts with 'Advanced search with filters and quality control,' which is a specific verb+resource combo. It explicitly distinguishes from sibling 'free_search' by stating 'Not recommended for: Simple queries — use free_search instead.' This clearly differentiates the tool's role.
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 'Best for' scenarios (domain filtering, high-confidence only, Chinese content) and a clear 'Not recommended for' with an alternative tool name. This helps agents decide when to invoke this tool versus its sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_with_synthesisARead-onlyIdempotent
Deep search with waterfall multi-engine verification. Returns structured results plus a prompt_hint for the agent to synthesize its own answer. No external LLM call or model API key is required; search and enrichment still make outbound network requests.
Best for: Complex queries needing multi-source verification and LLM synthesis. Not recommended for: Simple fact-finding — use free_search instead.
@readOnly true @idempotent true — runs waterfall search across free+paid engines with content enrichment.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of search results to gather (1-20) | |
| query | Yes | Search query | |
| language | No | auto | |
| min_confidence | No | Minimum source-reliability confidence (0-1). Legacy values 2-3 are treated as min_source_count. | |
| min_source_count | No | Minimum independent upstream provider families; accepts 1-12 for compatibility, current adapters expose at most 12. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral context: explains the waterfall multi-engine verification, states that no external LLM call is required but outbound network requests are made, and mentions the return of a prompt_hint. No contradictions.
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 concise, front-loaded with the core purpose, and every sentence adds value. Usage guidelines and annotations are clearly separated, and there is no unnecessary verbosity.
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?
Given the tool has 5 parameters and no output schema, the description adequately covers its behavior, return format (structured results + prompt_hint), and network requirements. It differentiates well from sibling tools. Minor gap: does not detail the structure of results, but acceptable for a search tool.
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 description coverage is 80% (4 out of 5 parameters have descriptions). The description does not add parameter-specific information beyond the schema, so it meets the baseline of 3. No additional semantic value is provided.
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 performs deep search with waterfall multi-engine verification and returns structured results plus a prompt_hint for synthesis. It explicitly differentiates from siblings by mentioning 'complex queries needing multi-source verification' and contrasts with 'free_search' 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?
Provides explicit 'Best for' and 'Not recommended for' sections, naming the alternative tool 'free_search' and giving clear context on when to use this tool (complex queries) versus when not to (simple fact-finding). Also notes that no external LLM call or API key is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
7 tool updates
v3.2.0- Added
fetch_csdn_article - Changed
fetch_github_readme1 field changed- removed
Input schema / additionalPropertiesRemoved value: -false
- Added
fetch_juejin_article - Changed
free_extract1 field changed- removed
Input schema / additionalPropertiesRemoved value: -false
- Changed
free_search5 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - changed
Input schema / properties / engines / descriptionPrevious value: -"Search engines to use (default: duckduckgo + sogou). Free engines work without API keys. Paid engines (brave/tavily/exa) require corresponding env vars. For Chinese results, include sogou or baidu."New value: +"Search engines to use (default: duckduckgo + sogou). Free engines work without API keys. Optional API engines require their corresponding environment-variable credentials. For Chinese results, include sogou or baidu." - changed
Input schema / properties / engines / items / enumPrevious value: -[ - "duckduckgo", - "sogou", - "bing", - "baidu", - "brave", - "tavily", - "exa" -]New value: +[ + "duckduckgo", + "sogou", + "bing", + "baidu", + "wikipedia", + "startpage", + "yandex", + "mojeek", + "wiby", + "brave", + "tavily", + "exa", + "youcom", + "tencent_wsa", + "bocha", + "serper" +] - changed
Input schema / properties / query / descriptionPrevious value: -"Search query string. Use natural language (e.g., \"latest AI news 2026\"). For Chinese queries, Sogou and Baidu are used automatically."New value: +"Search query string. Use natural language (e.g., \"latest AI news 2026\"). For Chinese coverage, include Sogou or Baidu in engines." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "cache_hit": { + "type": "boolean" + }, + "detected_language": { + "type": "string" + }, + "engines": { + "items": { + "enum": [ + "duckduckgo", + "sogou", + "bing", + "baidu", + "wikipedia", + "startpage", + "yandex", + "mojeek", + "wiby", + "brave", + "tavily", + "exa", + "youcom", + "tencent_wsa", + "bocha", + "serper" + ], + "type": "string" + }, + "type": "array" + }, + "meta": { + "additionalProperties": false, + "properties": { + "compacted_count": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "engines": { + "items": { + "type": "string" + }, + "type": "array" + }, + "evidence_budget": { + "additionalProperties": false, + "properties": { + "limit": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "truncated_results": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "unit": { + "const": "characters", + "type": "string" + }, + "used": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "unit", + "limit", + "used", + "truncated_results" + ], + "type": "object" + }, + "execution": { + "additionalProperties": false, + "properties": { + "budget": { + "additionalProperties": false, + "properties": { + "exhausted": { + "type": "boolean" + }, + "exhausted_reasons": { + "items": { + "enum": [ + "engine_calls", + "elapsed_ms", + "result_count", + "evidence_chars" + ], + "type": "string" + }, + "type": "array" + }, + "limits": { + "additionalProperties": false, + "properties": { + "elapsed_ms": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "engine_calls": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "evidence_chars": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "result_count": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "engine_calls", + "elapsed_ms", + "result_count", + "evidence_chars" + ], + "type": "object" + }, + "observed": { + "additionalProperties": false, + "properties": { + "elapsed_ms": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "engine_calls": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "evidence_chars": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "result_count": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "engine_calls", + "elapsed_ms", + "result_count", + "evidence_chars" + ], + "type": "object" + } + }, + "required": [ + "limits", + "observed", + "exhausted", + "exhausted_reasons" + ], + "type": "object" + }, + "early_stop": { + "type": "boolean" + }, + "engine_calls": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "mode": { + "enum": [ + "parallel", + "waterfall" + ], + "type": "string" + }, + "phases_completed": { + "items": { + "type": "string" + }, + "type": "array" + }, + "quality_gate": { + "additionalProperties": false, + "properties": { + "analyzedCount": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "basketConfidence": { + "maximum": 1, + "minimum": 0, + "type": "number" + }, + "basketRelevance": { + "maximum": 1, + "minimum": 0, + "type": "number" + }, + "providerFamilyCount": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "relevanceThreshold": { + "maximum": 1, + "minimum": 0, + "type": "number" + }, + "relevantResultsCount": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "sufficient": { + "type": "boolean" + }, + "topResultsCount": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "sufficient", + "basketConfidence", + "basketRelevance", + "relevantResultsCount", + "relevanceThreshold", + "providerFamilyCount", + "topResultsCount", + "analyzedCount" + ], + "type": "object" + }, + "quality_gate_stage": { + "enum": [ + "pre_semantic", + "post_semantic" + ], + "type": "string" + }, + "searched_engines": { + "items": { + "type": "string" + }, + "type": "array" + }, + "stop_reason": { + "enum": [ + "quality_gate_satisfied", + "phases_exhausted", + "budget_exhausted" + ], + "type": "string" + } + }, + "required": [ + "mode", + "engine_calls", + "searched_engines", + "phases_completed", + "early_stop", + "stop_reason" + ], + "type": "object" + }, + "filtered_count": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "filtered_total": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "high_confidence": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "total": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "total", + "high_confidence", + "engines" + ], + "type": "object" + }, + "partialFailures": { + "items": { + "additionalProperties": false, + "properties": { + "engine": { + "type": "string" + }, + "message": { + "type": "string" + }, + "suggestion": { + "type": "string" + }, + "type": { + "enum": [ + "validation_error", + "parse_error", + "timeout", + "upstream_4xx", + "upstream_5xx", + "rate_limited", + "bot_challenge", + "permission_denied", + "budget_exhausted", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "engine", + "type", + "message", + "suggestion" + ], + "type": "object" + }, + "type": "array" + }, + "query": { + "type": "string" + }, + "rate_limits": { + "additionalProperties": { + "additionalProperties": false, + "properties": { + "remaining": { + "type": "number" + }, + "resetInMs": { + "type": "number" + } + }, + "required": [ + "remaining", + "resetInMs" + ], + "type": "object" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "results": { + "items": { + "additionalProperties": false, + "properties": { + "compacted": { + "type": "boolean" + }, + "confidence": { + "maximum": 1, + "minimum": 0, + "type": "number" + }, + "evidence": { + "additionalProperties": false, + "properties": { + "extraction": { + "enum": [ + "search_snippet", + "reader_extracted" + ], + "type": "string" + }, + "matched_terms": { + "items": { + "type": "string" + }, + "type": "array" + }, + "passage_score": { + "type": "number" + }, + "published_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "selected_chars": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "source_chars": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "passage_score", + "matched_terms", + "published_at", + "extraction", + "source_chars", + "selected_chars" + ], + "type": "object" + }, + "relevance": { + "maximum": 1, + "minimum": 0, + "type": "number" + }, + "security": { + "additionalProperties": false, + "properties": { + "injection_detected": { + "type": "boolean" + }, + "threats": { + "items": { + "type": "string" + }, + "type": "array" + }, + "url_safe": { + "type": "boolean" + }, + "warnings": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "injection_detected", + "url_safe", + "threats", + "warnings" + ], + "type": "object" + }, + "snippet": { + "type": "string" + }, + "source_count": { + "maximum": 9007199254740991, + "minimum": 1, + "type": "integer" + }, + "sources": { + "items": { + "type": "string" + }, + "type": "array" + }, + "title": { + "type": "string" + }, + "url": { + "format": "uri", + "type": "string" + } + }, + "required": [ + "title", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "security_note": { + "type": "string" + } + }, + "required": [ + "query", + "engines", + "results", + "meta", + "security_note" + ], + "type": "object" +}
- Changed
free_search_advanced10 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - added
Input schema / properties / count / maximumAdded value: +20 - added
Input schema / properties / count / minimumAdded value: +1 - changed
Input schema / properties / count / typePrevious value: -"number"New value: +"integer" - changed
Input schema / properties / min_confidence / defaultPrevious value: -1New value: +0 - changed
Input schema / properties / min_confidence / descriptionPrevious value: -"Only return results verified by N+ sources"New value: +"Minimum source-reliability confidence (0-1). Legacy values 2-3 are treated as min_source_count." - changed
Input schema / properties / min_confidence / minimumPrevious value: -1New value: +0 - added
Input schema / properties / min_source_countAdded value: +{ + "default": 1, + "description": "Minimum independent upstream provider families; current adapters expose at most 12", + "maximum": 12, + "minimum": 1, + "type": "integer" +} - changed
Input schema / properties / time_range / descriptionPrevious value: -"Filter by recency"New value: +"Deprecated compatibility field; returns UNSUPPORTED_FILTER because general-search recency is not enforced end to end" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "cache_hit": { + "type": "boolean" + }, + "detected_language": { + "type": "string" + }, + "engines": { + "items": { + "enum": [ + "duckduckgo", + "sogou", + "bing", + "baidu", + "wikipedia", + "startpage", + "yandex", + "mojeek", + "wiby", + "brave", + "tavily", + "exa", + "youcom", + "tencent_wsa", + "bocha", + "serper" + ], + "type": "string" + }, + "type": "array" + }, + "meta": { + "additionalProperties": false, + "properties": { + "compacted_count": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "engines": { + "items": { + "type": "string" + }, + "type": "array" + }, + "evidence_budget": { + "additionalProperties": false, + "properties": { + "limit": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "truncated_results": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "unit": { + "const": "characters", + "type": "string" + }, + "used": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "unit", + "limit", + "used", + "truncated_results" + ], + "type": "object" + }, + "execution": { + "additionalProperties": false, + "properties": { + "budget": { + "additionalProperties": false, + "properties": { + "exhausted": { + "type": "boolean" + }, + "exhausted_reasons": { + "items": { + "enum": [ + "engine_calls", + "elapsed_ms", + "result_count", + "evidence_chars" + ], + "type": "string" + }, + "type": "array" + }, + "limits": { + "additionalProperties": false, + "properties": { + "elapsed_ms": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "engine_calls": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "evidence_chars": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "result_count": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "engine_calls", + "elapsed_ms", + "result_count", + "evidence_chars" + ], + "type": "object" + }, + "observed": { + "additionalProperties": false, + "properties": { + "elapsed_ms": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "engine_calls": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "evidence_chars": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "result_count": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "engine_calls", + "elapsed_ms", + "result_count", + "evidence_chars" + ], + "type": "object" + } + }, + "required": [ + "limits", + "observed", + "exhausted", + "exhausted_reasons" + ], + "type": "object" + }, + "early_stop": { + "type": "boolean" + }, + "engine_calls": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "mode": { + "enum": [ + "parallel", + "waterfall" + ], + "type": "string" + }, + "phases_completed": { + "items": { + "type": "string" + }, + "type": "array" + }, + "quality_gate": { + "additionalProperties": false, + "properties": { + "analyzedCount": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "basketConfidence": { + "maximum": 1, + "minimum": 0, + "type": "number" + }, + "basketRelevance": { + "maximum": 1, + "minimum": 0, + "type": "number" + }, + "providerFamilyCount": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "relevanceThreshold": { + "maximum": 1, + "minimum": 0, + "type": "number" + }, + "relevantResultsCount": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "sufficient": { + "type": "boolean" + }, + "topResultsCount": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "sufficient", + "basketConfidence", + "basketRelevance", + "relevantResultsCount", + "relevanceThreshold", + "providerFamilyCount", + "topResultsCount", + "analyzedCount" + ], + "type": "object" + }, + "quality_gate_stage": { + "enum": [ + "pre_semantic", + "post_semantic" + ], + "type": "string" + }, + "searched_engines": { + "items": { + "type": "string" + }, + "type": "array" + }, + "stop_reason": { + "enum": [ + "quality_gate_satisfied", + "phases_exhausted", + "budget_exhausted" + ], + "type": "string" + } + }, + "required": [ + "mode", + "engine_calls", + "searched_engines", + "phases_completed", + "early_stop", + "stop_reason" + ], + "type": "object" + }, + "filtered_count": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "filtered_total": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "high_confidence": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "total": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "total", + "high_confidence", + "engines" + ], + "type": "object" + }, + "partialFailures": { + "items": { + "additionalProperties": false, + "properties": { + "engine": { + "type": "string" + }, + "message": { + "type": "string" + }, + "suggestion": { + "type": "string" + }, + "type": { + "enum": [ + "validation_error", + "parse_error", + "timeout", + "upstream_4xx", + "upstream_5xx", + "rate_limited", + "bot_challenge", + "permission_denied", + "budget_exhausted", + "unknown" + ], + "type": "string" + } + }, + "required": [ + "engine", + "type", + "message", + "suggestion" + ], + "type": "object" + }, + "type": "array" + }, + "query": { + "type": "string" + }, + "rate_limits": { + "additionalProperties": { + "additionalProperties": false, + "properties": { + "remaining": { + "type": "number" + }, + "resetInMs": { + "type": "number" + } + }, + "required": [ + "remaining", + "resetInMs" + ], + "type": "object" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "results": { + "items": { + "additionalProperties": false, + "properties": { + "compacted": { + "type": "boolean" + }, + "confidence": { + "maximum": 1, + "minimum": 0, + "type": "number" + }, + "evidence": { + "additionalProperties": false, + "properties": { + "extraction": { + "enum": [ + "search_snippet", + "reader_extracted" + ], + "type": "string" + }, + "matched_terms": { + "items": { + "type": "string" + }, + "type": "array" + }, + "passage_score": { + "type": "number" + }, + "published_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "selected_chars": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + }, + "source_chars": { + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "passage_score", + "matched_terms", + "published_at", + "extraction", + "source_chars", + "selected_chars" + ], + "type": "object" + }, + "relevance": { + "maximum": 1, + "minimum": 0, + "type": "number" + }, + "security": { + "additionalProperties": false, + "properties": { + "injection_detected": { + "type": "boolean" + }, + "threats": { + "items": { + "type": "string" + }, + "type": "array" + }, + "url_safe": { + "type": "boolean" + }, + "warnings": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "injection_detected", + "url_safe", + "threats", + "warnings" + ], + "type": "object" + }, + "snippet": { + "type": "string" + }, + "source_count": { + "maximum": 9007199254740991, + "minimum": 1, + "type": "integer" + }, + "sources": { + "items": { + "type": "string" + }, + "type": "array" + }, + "title": { + "type": "string" + }, + "url": { + "format": "uri", + "type": "string" + } + }, + "required": [ + "title", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "security_note": { + "type": "string" + } + }, + "required": [ + "query", + "engines", + "results", + "meta", + "security_note" + ], + "type": "object" +}
- Added
search_with_synthesis
4 tool updates
v3.1.2- Removed
fetch_csdn_article - Removed
fetch_juejin_article - Added
free_search - Added
free_search_advanced
6 tool updates
v3.1.1- Added
fetch_csdn_article - Added
fetch_github_readme - Added
fetch_juejin_article - Changed
free_extract2 fields changed- changed
Input schema / properties / max_length / descriptionPrevious value: -"Max characters to return"New value: +"Maximum characters to return (default: 5000). Content beyond this limit is truncated. Increase for long articles, decrease for quick snippets." - changed
Input schema / properties / url / descriptionPrevious value: -"URL to extract"New value: +"URL to extract content from. Supports any public web page URL (http/https). For best results, use a complete URL including the protocol (https://)."
- Removed
free_search - Removed
free_search_advanced
3 tool updates
v1.0.0- First observed
free_extract - First observed
free_search - First observed
free_search_advanced
TDQS
Scored across 7 tools
Each tool has a clearly distinct purpose: specialized fetchers for popular developer sites (CSDN, GitHub, Juejin), general search with two levels (free_search and free_search_advanced), a content extraction tool (free_extract), and a synthesis search (search_with_synthesis). Descriptions include explicit differentiation, eliminating ambiguity.
Names consistently use snake_case with a verb_noun structure (e.g., fetch_csdn_article, free_search). Minor inconsistency: 'search_with_synthesis' is more descriptive but still follows the pattern. The 'free_' prefix is used for search-related tools, and 'fetch_' for site-specific fetchers, maintaining a logical grouping.
Seven tools is well-scoped for a search and content extraction server. It covers basic and advanced search, synthesis, general content extraction, and three site-specific fetchers. No tool feels redundant or missing; each earns its place.
The tool surface appears complete for its purpose: it provides search (basic, advanced, synthesis), general page extraction, and specialized fetchers for common developer resources. There are no obvious gaps like missing domain filters (advanced search has them) or search result management.
Maintenance
Related MCP Connectors
Multi-engine search for AI agents. Trust scoring, local corpus, MCP-native. Self-hostable, BYOK.
Web search for AI agents — one tool across 6 engines, routed to the cheapest + cached.
Agent-native search engine with live web research optimized for AI agents.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Related MCP Servers
- AlicenseAqualityFmaintenanceFree multi-source web search server for AI agents, with confidence scoring and token optimization.356Apache 2.0
- AlicenseAqualityBmaintenanceEnables AI agents to perform multi-engine web search, fetch web pages, and extract clean Markdown content via MCP, with no API keys required.36MIT
- AlicenseAqualityAmaintenanceFree self-hosted web search for AI agents with multi-engine parallel search, semantic re-ranking, and native China network support. Zero API keys.226MIT
- AlicenseAqualityCmaintenanceA Grok-first multi-source search MCP for AI agents that integrates Grok, Tavily, AnySearch, and Firecrawl to provide unified search results, cross-verification, and web content fetching.3MIT