ja ru zh

ai-search-mcp

Name: ai-search-mcp
Author: zhulingyu666

by zhulingyu666

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

AI Search MCP

エージェント向けに作られた Web 検索 MCP サーバー：設定不要ですぐ使える無料検索エンジン、プラグイン可能な高品質エンジン、内蔵キャッシュ、時間フィルタリング、そして1回の呼び出しで調査を完了する research 統合ツール。
An agent-friendly web search MCP server — zero-config free engines, region-aware failover, freshness filtering, and a one-call research tool.

なぜ作るのか（Why）

検索はエージェントにとって最も頻度の高いツールですが、既存のソリューションには決定的な欠点があります：

既存の方法	問題
公式 `fetch` MCP	既知の URL しか取得できず、検索ができない
Tavily / Brave / Exa 公式 MCP	品質は高いが、すべて有料 API Key が必要
コミュニティ DuckDuckGo MCP	無料だが脆弱、出力が非構造化、キャッシュ/リトライなし

ai-search-mcp がこの穴を埋めます：ゼロ設定ですぐ使え（DuckDuckGo / Bing / 百度 / 搜狗）、リージョンに応じて最適なエンジンを自動選択してフェイルオーバー、時間フィルタにも対応。さらに「検索 → 選択 → 取得 → 要約」という一連の調査を1回の research 呼び出しに圧縮できます。

Related MCP server: jiro

特徴（Features）

🆓 ゼロ設定ですぐ使える：npx ai-search-mcp を実行するだけ。API Key は一切不要
🔌 マルチエンジン・プラグ可能：無料エンジン duckduckgo · bing · baidu · so360 + 有料エンジン brave · tavily
🌏 リージョン連携の自動エンジン選択：SEARCH_ENGINE=auto（デフォルト）→ 中国リージョンは bing→baidu→sogou、その他は duckduckgo→bing を利用。429/タイムアウト時は自動フェイルオーバー。カンマ区切りのエンジンチェーンに対応
🕒 時間フィルタ：freshness=day|week|month|year または timeRange="YYYY-MM-DD..YYYY-MM-DD" を各エンジンへ自動マッピング
🧠 エージェント向け出力：構造化 JSON（{ id, title, url, snippet, domain }）で、生 HTML ではない。各結果には安定した id があり、そのまま引用可能
🧭 research 統合ツール：1回の呼び出し = 検索 + 上位ページ取得 → エビデンスブリーフ（5〜10往復のツール呼び出を削減）
⚡ 内蔵キャッシュ（TTL、デフォルト10分）：重複するネットワークリクエストを減らし、高速化と省リソース化を実現
🛡️ エンジニアリング冗長：タイムアウト、指数バックオフ再試行、統一エラーコード。RATE_LIMITED エラーでは suggestedEngine / retryAfter の提案も返却
🐢 礼儀正しいクローラー内蔵：エンジンごとのレート制限（デフォルト8回/分）、ランダムなリクエスト間隔を設定し、プラットフォームのリスク検知を能動的に回避。アンチスクレイピングの対処は一切しない（コンプライアンス優先）
📄 fetch_page ツール：任意の URL（または検索結果の id）を読みやすい Markdown に変換
🌏 プロキシ対応：SEARCH_HTTP_PROXY / HTTP(S)_PROXY
🧪 ビルド不要の純 JS（CommonJS）。130 のユニットテスト + エンドツーエンドスモークテスト

クイックスタート（Quick Start）

Node.js >= 18 が必要です。

# 直接用 npx 运行（无需安装）
npx -y ai-search-mcp

# 或全局/本地安装
npm i -g ai-search-mcp
ai-search-mcp

Claude Desktop

claude_desktop_config.json に次を追加します：

{
  "mcpServers": {
    "ai-search-mcp": {
      "command": "npx",
      "args": ["-y", "ai-search-mcp"]
    }
  }
}

Cursor / Cline / その他の MCP 対応クライアント

{
  "mcpServers": {
    "ai-search-mcp": {
      "command": "npx",
      "args": ["-y", "ai-search-mcp"],
      "env": {
        "SEARCH_REGION": "cn-zh"
      }
    }
  }
}

中国ユーザーは SEARCH_REGION=cn-zh を追加することを推奨します。国内で直接接続可能なエンジンチェーン（bing → baidu → sogou）を自動選択し、プロキシ不要で利用できます。

ソースから実行

git clone https://github.com/zhulingyu666/ai-search-mcp.git
cd ai-search-mcp
npm install
npm start

ツール説明（Tools）

`search` — 検索

{
  "query": "2026年 大模型 最新进展",
  "maxResults": 10,
  "site": "github.com",
  "region": "us-en",
  "freshness": "week"
}

戻り値（構造化 JSON）：

{
  "query": "2026年 大模型 最新进展",
  "queryRewritten": "大模型 最新进展",
  "queryYear": 2026,
  "engine": "bing",
  "engineSwitched": false,
  "cached": false,
  "total": 10,
  "deduped": 2,
  "freshnessApplied": true,
  "freshnessAutoInferred": true,
  "timeRange": "2025-08-25..2026-08-25",
  "results": [
    {
      "id": "a1b2c3d4",
      "title": "...",
      "url": "https://...",
      "snippet": "...",
      "domain": "example.com"
    }
  ]
}

中文查询自动改写：クエリに中国語が含まれている「20xx年」という年代表記（例：「2026年大模型最新进展」）がある場合、ツールは年号語を削除し、freshness=year を自動付与して時間の意図を補償します。これは Bing などが中国語の分かち書きに弱く、年号が先頭にあると「2026年百科/日历」のような意味論的な結果が返るためです。この書き換えは queryRewritten / queryYear / freshnessAutoInferred で透過的に返るため、エージェント側で受け入れるか判断できます。

パラメータ	型	デフォルト	説明
`query`	string	—	検索キーワード（必須）
`maxResults`	number	10	返却件数（1〜20）
`site`	string	—	特定のドメインのみに限定、例：`github.com` （`includeDomains` の互換エイリアス）
`includeDomains`	string[]	—	これらのドメインの結果のみ返す、例：`["github.com","arxiv.org"]`（エンジンの `site:` が機能しない場合は結果側でフィルタ補償）
`excludeDomains`	string[]	—	これらのドメインを除外、例：`["baidu.com"]`
`region`	string	—	リージョンヒント：DDG 的 `kl` コード（例：`cn-zh`、`us-en`） / Bing 的 `setlang` / Brave 的 `country`;同時にエンジン自動選択にも使用
`freshness`	string	—	`day` \| `week` \| `month` \| `year`（各エンジンの時間フィルターにマッピング）
`timeRange`	string	—	正确な時間範囲 `"YYYY-MM-DD..YYYY-MM-DD"`（`freshness` 躍り優先）

各結果には安定した id（sha1 プレフィックス）が付与されます。この id を fetch_page に渡すと、ページの詳細を読むことができます。URL を手動で組み立てる必要はありません。

`research` — 1回の呼び出しで調査を完了

エージェントの「検索 → ページ選択 → 取得 → 要約」というループの代わりに、1回の呼び出しで完了します：

{
  "query": "2026 LLM open source models comparison",
  "maxResults": 5,
  "fetchTopN": 2,
  "freshness": "month"
}

戻り値はエビデンスブリーフ：

内訳

{
  "query": "...",
  "engine": "bing",
  "overview": { "total": 5, "results": [ { "id": "...", "title": "...", "url": "...", "snippet": "...", "domain": "..." } ] },
  "pages": [ { "id": "...", "url": "...", "title": "...", "headings": [ { "level": 1, "text": "..." } ], "content": "...", "length": 4000, "truncated": false } ],
  "note": "证据简报已就绪，请基于页面内容总结并标注来源 URL。"
}

複数ページを並列取得。単一のページが失敗した場合は { url, error } として記録され、全体の結果に影響はありません
スマートなページ選択：pages はドメインの多様性に基づいて選びます（最初に各ドメインの最高ランクの1件、その後ランクの順に補完）。単一サイトの独占を回避し、あるサイトの 403/反スクレイピング時も他ドメインのページは影響を受けません。rank フィールドは検索結果内での元の順位
extractMode（デフォルト summary）：summary はノイズを除去した本文の要点を返し（トークン節約）、full はページ全体の Markdown を返します
要約はホストモデルが実施します——MCP 内部ではどの LLM にも依存せず、外部依存ゼロ、ベンダー非依存を維持

`fetch_page` — ウェブページを取得して構造化コンテンツに変換

{
  "url": "https://example.com/article",
  "extractMode": "summary",
  "maxLength": 8000
}

extractMode：summary（デフォルト。トークンを節約し、ノイズ除去後の本文 mainText を返す）/ full（ページ全体の markdown を返す）
戻り値: { url, title, description, headings, mainText, markdown, length, truncated, cached }。headings はページの見出し構成なので、エージェントはまず構造を確認してから詳細を読むかを選べます

検索結果の id も利用できます：{ "id": "a1b2c3d4", "maxLength": 8000 }。

設定（環境変数）

変数	デフォルト	説明
`SEARCH_ENGINE`	`auto`	単一エンジン、またはカンマ区切りのエンジンチェーン（例：`brave,tavily`）。`auto` = リージョンに応じて自動選択
`SEARCH_REGION`	—	エンジン自動選択で使用するデフォルトリージョン。例：`cn-zh`（`search` のデフォルト `region` でもある）
`SEARCH_MAX_RESULTS`	`10`	デフォルトの結果件数（1〜20）
`SEARCH_CACHE_TTL`	`600300`	キャッシュ TTL（秒）。`0` で無効
`SEARCH_CACHE_FILE`	—	キャッシュ永続化ファイルのパス。例：`./.cache/search.json`。設定すると再起動してもキャッシュが失われない（単一プロセス専用）
`SEARCH_TIMEOUT_MS`	`10000`	単一リクエストのタイムアウト（ミリ秒）
`SEARCH_RATE_PER_MINUTE`	`8`	各エンジンの1分あたりの最大リクエスト数（`0` でレート制限無効）
`SEARCH_MIN_DELAY_MS` / `SEARCH_MAX_DELAY_MS`	`500` / `2000`	リクエスト間のランダム遅延範囲（ミリ秒）。`0` で無効
`SEARCH_LANG_ROUTING`	`0`	`1` = 中国語クエリは百度/搜狗を優先（百度/搜狗に到達可能なネットワークであること。後述参照）
`SEARCH_LOG_LEVEL`	`info`	`debug` \| `info` \| `warn` \| `error` \| `off`（構造化ログを stderr に出力し、MCP プロトコルを汚染しない）
`SEARCH_LOG_QUERY`	`1`	`0` = ログ内のクエリ語をマスク（プライバシー保護）
`FETCH_MAX_LENGTH`	`8000`	`fetch_page` / `research` のページ Markdown 長の上限（文字数）
`BRAVE_API_KEY`	—	`brave` エンジン利用時に必須
`TAVILY_API_KEY`	—	`tavily` エンジン利用時に必須
`SEARCH_HTTP_PROXY`	—	プロキシのアドレス。例：`http://127.0.0.1:7890`（`HTTPS_PROXY`/`HTTP_PROXY` にフォールバック）
`SEARCH_USER_AGENT`	内蔵	カスタム User-Agent

エンジン比較

エンジン	無料	API Key	時間フィルタ	説明
`google`	✅	❌	❌	海外専用（中国国内不可用）。インデックス品質は世界最高、アンチスクレイピングが厳しく、海外 IP + Cookie セッションなどが必要
`bing`	✅	❌	✅（`qft`）	全世界利用可能。中国リージョンでのデフォルトで、中英文カバレッジが良い、国内からプロキシ不要で直結可能
`duckduckgo`	✅	❌	✅（`df`）	全世界対応のフォールバック。中国本土からの直結はタイムアウトすることがある
`yandex`	✅	❌	❌（none）	海外専用。ロシア語/CIS コンテンツに強く、一部ネットワークからは到達性が良い、スクレイピング耐性は中
`so360`	✅	❌	❌（none）	360 検索。データセンター・国内 IP からでも直接接続可能、アンチスクレイピングは比較的寛容、中国語ネイティブなエンジン
`baidu`	✅	❌	❌（none）	国内専用。中国語のインデックスは強いが、アンチスクレイピングが厳しい（データセンター IP では Cookie を付与しても画像認証を要求される）
`sogou`	✅	❌	❌（none）	国内専用。WeChat コンテンツに強い。ただし JS 生成の SNUID セッションが無いと 302 でリダイレクトされる
`brave`	❌	✅	✅（`freshness`）	公式 API。品質高く、無料クォータあり
`tavily`	❌	✅	✅（`time_range`）	LLM/RAG 検索専用に設計

ネットワーク注意事項

中国本土はプロキシ不要: デフォルトの SEARCH_ENGINE=auto + SEARCH_REGION=cn-zh → bing → so360 → baidu → sogou はすべて直結で使用でき、追加設定は一切不要。特に 360 検索（so360）はデータセンター・ホスティング IP に対してもっとも寛容で、国内で最も信頼性のある中国語ネイティブエンジンです。
海外展开設：デフォルトで SEARCH_REGION を設定しない（または cn 以外）→ デフォルトチェーンは google → bing → duckduckgo → yandex。Google は品質が最高、Bing は最も安定しており、いずれかが失敗すると自動で切り替えます。Google/Yandex が中国国内から到達不可または認証コードにブロックされました。
無料エンジンはレート制限あり。429 は構造化エラー（RATE_LIMITED、suggestedEngine と retryAfter を維持）として返します。エンジンチェーンは 429 やタイムアウト時に自動フェイルオーバーします。
一部サイト（百度百科、中国国内ポータルなど）はスクリプト取得を拒否（HTTP 403）：fetch_page は構造化エラーを返し、research は該当ページを失敗として記録して続行します。
DuckDuckGo / Brave / Tavily にアクセスするにはプロキシが必要ですか：
```
SEARCH_ENGINE=duckduckgo SEARCH_HTTP_PROXY=http://127.0.0.1:7890 ai-search-mcp
```
丁寧なクローラー方針：ツールはエンジンごとにレート制限（デフォルト 8回/分）とランダム間隔を組み込みます。百度/搜狗では、トップページからセッションCookie（BAIDUID / SUID）を担保することで成功率を上げますが、キャプチャー回避、UA 偽装のローテーション、プロキシプールのローテーションなどのアンチスクリプティングには対応していません（コンプライアンス上の境界）。ローテーションは、403/認証に遭遇した場合はアクセス頻度の低減やエンジン切替で検知してください。
百度/搜狗の可用性（実測）：これらのエンジンはネットワーク環境に非常に敏感です。データセンター / 海外 IP では、百度は Cookie を設定してもグラフィカル認証（wappass）が強制されますし、搜狗は JSで生成される SNUID がないと 302 でぶり戻されます（antispider）。そのためデフォルト環境では自動的に Bing/360 へ移します。中国大陸の**住宅用 IP（宽带）**から百度/搜狗が使える場合は、SEARCH_LANG_ROUTING=1 を設定することで、中文の検索クエリで百度/搜狗/360（中国語ネイティブ、分かちに優れる）を優先利用できます。
私たちは対象サイトの robots.txt と利用規約を尊重します。本ツールは検索のスニペットとリンクのみを返し、全文を再配布しません。

開発（Development）

npm test          # 126 个单元测试（Node 内置 test runner）
node scripts/smoke-test.js   # 端到端冒烟：search + freshness + research（需要网络）

ログ例（stderr、`SEARCH_LOG_LEVEL=debug`）

[ai-search-mcp] [info] ready (version 0.3.2, engine=auto, region=cn-zh, logLevel=debug)
[ai-search-mcp] [info] rewrite q="2026年 大模型 最新进展" -> q="大模型 最新进展" +freshness=year
[ai-search-mcp] [info] search q="大模型 最新进展" engine=bing cached=false took=972ms total=3 deduped=1
[ai-search-mcp] [info] fetch url=https://example.com/ len=130 mode=summary took=1189ms
[ai-search-mcp] [debug] engine-fail engine=baidu err=RATE_LIMITED took=1203ms
[ai-search-mcp] [warn] fetch-fail url=https://baike.baidu.com/... err=ENGINE_ERROR took=512ms

ライセンス（License）

MIT

Disclaimer:このプロジェクトは独立したオープンソースプロジェクトであり、DuckDuckGo 、Bing/Microsoft、Brave、Tavily、百度、搜狗との間に関連・推薦・運営・スポンサー関係は一切ありません。百度/搜狗は公開HTMLを解析するものであり、これらのサイトのページ構造が変更された場合、解析が機能しなくなる可能性があります。

Available Tools

3 tools

fetch_pageA

Fetch a page and return its content as structured Markdown. Pass either "url" or the "id" returned by search/research (id looks up the already-seen URL). extractMode "summary" returns de-noised mainText (saves tokens); "full" returns the full page Markdown. Output: {"url":str,"title":str,"description":str,"headings":[{level:int,text:str}], "mainText":str,"markdown":str,"length":int,"truncated":bool,"cached":bool}

Name	Required	Description
`id`	No	Stable result id from search/research
`url`	No	The http(s) URL to fetch (mutually exclusive with id)
`maxLength`	No	Maximum characters of primary content to return (default 8000)
`extractMode`	No	summary = de-noised main text (token-efficient); full = whole page Markdown (default full)

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that id uses an already-seen URL, summary mode de-noises mainText, and the output includes truncated and cached fields, which inform the agent about caching and truncation behavior. It does not cover failure modes or rate limits, but that is beyond typical selection criteria.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three tight sentences followed by an explicit output shape, with no filler. The core action is front-loaded, and every subsequent sentence adds information an agent needs for correct invocation. The output spec is lengthy but necessary since there is no output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no annotations and no output schema, the description fully compensates: it explains purpose, parameter usage, behavioral nuances, and return value structure. The explicit output JSON gives agents a precise contract of what to expect, making the tool effectively self-contained. No critical selection or invocation information is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by clarifying that id looks up the already-seen URL and that summary extractMode 'saves tokens', directly addressing cost implications. The output block also connects maxLength to truncation and cached to caching behavior, which the schema alone does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Fetch a page and return its content as structured Markdown', a precise verb-resource-output statement that leaves no doubt about the tool's function. It also differentiates from siblings by explaining the id comes from search/research, positioning fetch_page as the retrieval step after search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly explains when to pass 'url' versus the 'id' returned by search/research, including that id looks up an already-seen URL. It also gives a clear choice criterion for extractMode: summary saves tokens, full returns the complete page. It stops short of naming explicit alternatives or exclusions, but the workflow context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

researchA

One-call research: search + fetch the top pages and return an evidence brief. Use this instead of chaining search/fetch_page yourself. Pages are selected for domain diversity (top hit per domain, then by rank) so one anti-bot 403 site can't sink the brief. Output: {"query":str,"engine":str,"cached":bool, "overview":{"total":int,"results":[{"id":str,"title":str,"url":str,"snippet":str,"domain":str}]}, "pages":[{"id":str,"url":str,"rank":int,"title":str,"headings":[{level:int,text:str}],"content":str,"length":int,"truncated":bool}|{"url":str,"rank":int,"error":str}]} Base your answer on the pages' content and cite their URLs.

Name	Required	Description
`site`	No	Restrict to one domain, e.g. github.com (alias for a single includeDomains entry)
`query`	Yes	The web search query (required)
`region`	No	Region hint. DuckDuckGo: kl code (cn-zh, us-en). Bing: setlang. Brave: country
`fetchTopN`	No	How many of the top results to fetch as full pages (default 2, 0 = overview only)
`freshness`	No	Only results from the last day\|week\|month\|year (auto-applied as year when a Chinese query drops a 20xx年 year token)
`timeRange`	No	Exact window "YYYY-MM-DD..YYYY-MM-DD" (takes precedence over freshness)
`maxResults`	No	Max results (1-20, default from SEARCH_MAX_RESULTS)
`extractMode`	No	summary = de-noised main text per page (default, token-efficient); full = whole page Markdown
`maxPageLength`	No	Characters of Markdown kept per page (default 8000)
`excludeDomains`	No	Never return results from these domains, e.g. [baidu.com]
`includeDomains`	No	Only return results from these domains, e.g. [github.com, arxiv.org]

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden, and it does so thoroughly. It discloses the domain-diversity selection strategy, the anti-bot 403 resilience reasoning, and the exact output shape including per-page error objects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and use guidance, then adds a compact but necessary output schema. Every sentence earns its place, and the JSON block is justified because there is no separate output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 11-parameter tool with no annotations and no output schema, the description is remarkably complete. It explains the composite workflow, selection behavior, error handling, and return structure, so an agent has enough context to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema description coverage is 100%, so the schema already documents every parameter, including defaults, aliases, and precedence. The description itself adds no parameter-specific meaning beyond what the schema provides, matching the baseline for full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'One-call research: search + fetch the top pages and return an evidence brief,' which clearly identifies the operation, the resource, and the composite behavior. It also explicitly distinguishes itself from the sibling tools by saying to use it 'instead of chaining search/fetch_page yourself.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage context: use this tool instead of manually chaining search and fetch_page. It names the relevant alternatives, though it does not spell out exclusions such as 'when you only need a single page, use fetch_page.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

searchA

Search the web and return structured results. Output: {"query":str,"queryRewritten":str?,"queryYear":int?,"engine":str,"engineSwitched":bool,"cached":bool, "total":int,"deduped":int,"freshnessApplied":bool,"freshnessAutoInferred":bool?, "results":[{"id":str,"title":str,"url":str,"snippet":str,"domain":str}]} Use the "id" of a result with fetch_page to deep-read a page.

Name	Required	Description
`site`	No	Restrict to one domain, e.g. github.com (alias for a single includeDomains entry)
`query`	Yes	The web search query (required)
`region`	No	Region hint. DuckDuckGo: kl code (cn-zh, us-en). Bing: setlang. Brave: country
`freshness`	No	Only results from the last day\|week\|month\|year (auto-applied as year when a Chinese query drops a 20xx年 year token)
`timeRange`	No	Exact window "YYYY-MM-DD..YYYY-MM-DD" (takes precedence over freshness)
`maxResults`	No	Max results (1-20, default from SEARCH_MAX_RESULTS)
`excludeDomains`	No	Never return results from these domains, e.g. [baidu.com]
`includeDomains`	No	Only return results from these domains, e.g. [github.com, arxiv.org]

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden, and it does so well by disclosing the full structured output shape, including query rewriting, engine switching, caching, deduplication, and freshness handling. It does not mention rate limits or authentication, but for a read-only search tool the output detail provides substantial transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and the output block is dense and useful rather than repetitive. The only length comes from the necessary output schema, which compensates for the missing output-schema field. It is reasonably concise and every part contributes to the tool's usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete enough for invoking a search tool: it specifies behavior, output structure, and a follow-up action using fetch_page. It lacks explicit error/edge-case behavior and does not mention how research relates to this tool, but those are not critical given the rich schema and detailed output specification.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameters are already fully documented in the schema. The tool description adds no additional meaning about the parameters themselves; it focuses on output structure. Baseline 3 is appropriate here because the schema does the needed work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Search the web and return structured results.' It is clearly distinct from fetch_page, and the output schema plus the instruction to use result IDs with fetch_page reinforces that this tool is for discovery rather than reading full pages. However, it does not explicitly differentiate from the research sibling tool, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context that this tool is for web search and explicitly instructs the agent to use fetch_page with a result ID to deep-read a page, which clarifies one key alternative. It does not provide explicit when-to-use versus research or list exclusions, but the workflow is evident enough for correct selection in most cases.

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.

3 tool updatesv0.3.4Aug 26, 2026
- First observedfetch_page
- First observedresearch
- First observedsearch

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored 2026-08-26 01:35 across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: search for web results, fetch_page for retrieving a specific page's content, and research for combining search and deep-reading. There is no overlap or chance of misselection.

Naming Consistency5/5

All tool names follow the same snake_case, verb_noun pattern (fetch_page, search, research). Although 'search' and 'research' are single-word verbs, the pattern is consistent and predictable.

Tool Count5/5

With only 3 tools, the server is well-scoped for a web search and research workflow. Each tool earns its place with minimal redundancy.

Completeness5/5

The tool surface covers the full research lifecycle: search to discover results, fetch_page to retrieve content, and research to combine both efficiently. No critical gaps exist for the stated purpose.

Maintenance

ActivityStale

ResponsivenessNo recent community issues

Resources

Related MCP Connectors

SearchPipeA
tech.searchpipe
Web search API and MCP server for developers building AI agents.
Search Browser Automation Agent Orchestration
31
https://searchpipe.tech/mcp/
SearchStackA
dev.searchstack
Agent-driven search: build, import, tune, search, and score result quality — all over MCP.
Search Vector Databases Location Services
2
https://mcp.searchstack.dev
Not Human SearchA
ai.nothumansearch
Search the agentic web. 4,100+ sites, 11 tools incl. check_url + verify_mcp for probe-before-use.
Search Browser Automation Web Scraping
143
https://nothumansearch.ai/mcp
MESSORAA
dev.messora
Scrape, crawl and search the web for AI agents via MCP.
Web Scraping Browser Automation Search
1
https://mcp.messora.dev/mcp

Related MCP Servers

websearch-skill
Search Web Scraping Browser Automation
hec-ovi
A
license
A
quality
D
maintenance
Enables AI agents to perform multi-engine web search, fetch web pages, and extract clean Markdown content via MCP, with no API keys required.
Updated 3 months ago (2026-08-13 14:14 UTC)
3
58 PyPI
8
MIT
jiro
Browser Automation Web Scraping Search
DevAnimecx
A
license
Not graded
quality
B
maintenance
Enables AI agents to perform live web searches across 9 engines, scrape web pages into clean formats, and run agentic research with citations via MCP.
Updated 16 days ago (2026-10-22 16:17 UTC)
60 PyPI
6
MIT
Search Toolkit
Search Web Scraping Agent Orchestration
TheWiseWolfHolo
A
license
Not graded
quality
B
maintenance
Enables AI agents to perform web search, extraction, and research across multiple provider backends with persistent multi-key rotation and auditable routing. Supports MCP, CLI, and Agent Skill entry points.
Updated 21 hours ago (2026-11-06 21:25 UTC)
MIT
Universal Web Retrieval MCP
Browser Automation Search Web Scraping
withgardener
A
license
A
quality
B
maintenance
Enables MCP-capable agents to perform reliable web search and content fetching through a single server that automatically fails over across multiple providers. It handles keyed or keyless authentication automatically and returns clean Markdown or text results.
Updated 4 days ago (2026-11-03 09:18 UTC)
3
1
MIT

AI Search MCP

なぜ作るのか（Why）

特徴（Features）

クイックスタート（Quick Start）

Claude Desktop

Cursor / Cline / その他の MCP 対応クライアント

ソースから実行

ツール説明（Tools）

search — 検索

research — 1回の呼び出しで調査を完了

fetch_page — ウェブページを取得して構造化コンテンツに変換

設定（環境変数）

エンジン比較

ネットワーク注意事項

開発（Development）

ログ例（stderr、SEARCH_LOG_LEVEL=debug）

ライセンス（License）

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`search` — 検索

`research` — 1回の呼び出しで調査を完了

`fetch_page` — ウェブページを取得して構造化コンテンツに変換

ログ例（stderr、`SEARCH_LOG_LEVEL=debug`）