专为 Agent 打造的上网搜索 MCP 服务器：开箱即用的免费搜索引擎、可插拔的高质量引擎、内置缓存、时间过滤，以及一次调用完成整轮调研的
research组合工具。An agent-friendly web search MCP server — zero-config free engines, region-aware failover, freshness filtering, and a one-call
researchtool.
搜索是 Agent 最高频的工具，但现有方案都有硬伤：
现有方案 | 问题 |
官方 | 只能抓已知 URL，不会搜索 |
Tavily / Brave / Exa 官方 MCP | 质量高，但全部要付费 API Key |
社区 DuckDuckGo MCP | 免费但脆弱，输出非结构化，无缓存/重试 |
ai-search-mcp 填补了这个空档：零配置就能用（DuckDuckGo / Bing / 百度 / 搜狗），自动按区域选择最合适的引擎并故障转移，支持时效过滤，还能把「搜→选→抓→总结」的整轮调研压成一次 research 调用。
Related MCP server: websearch-skill
🆓 零配置开箱即用：npx ai-search-mcp 直接跑，不需要任何 API Key
🔌 多引擎可插拔：免费引擎 duckduckgo · bing · baidu · sogou 360+ 付费引擎 brave · tavily
🌏 区域感知自动选引擎：SEARCH_ENGINE=auto（默认）→ 中国区域走 bing→baidu→sogou，其他区域走 duckduckgo→bing；429/超时自动故障转移，支持逗号分隔引擎链
🕒 时间过滤：freshness=day|week|month|year 或 timeRange="YYYY-MM-DD..YYYY-MM-DD"，按引擎自动映射
🧠 Agent 友好输出：结构化 JSON（{ id, title, url, snippet, domain }），不是原始 HTML；每条结果带稳定 id，可直接引用
🧭 research 组合工具：一次调用 = 搜索 + 抓取 Top 页 → 证据简报（消灭 5~10 次工具往返）
⚡ 内置缓存（TTL，默认 10 分钟）：减少重复网络请求，更快更省
🛡️ 工程兜底：超时、指数退避重试、统一错误码，RATE_LIMITED 错误附带 suggestedEngine / retryAfter 建议
🐢 礼貌爬虫内置：按引擎限频（默认 8 次/分）+ 随机请求间隔，主动避免触发平台风控，不做任何反爬对抗（合规优先）
📄 fetch_page 工具：任意 URL（或搜索结果 id）转成可读 Markdown
🌏 代理支持：SEARCH_HTTP_PROXY / HTTP(S)_PROXY
🧪 零构建纯 JS（CommonJS），130 个单元测试 + 端到端冒烟测试
需要 Node.js >= 18。
# 直接用 npx 运行（无需安装）
npx -y ai-search-mcp
# 或全局/本地安装
npm i -g ai-search-mcp
ai-search-mcp在 claude_desktop_config.json 中加入：
{
"mcpServers": {
"ai-search-mcp": {
"command": "npx",
"args": ["-y", "ai-search-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 startsearch — 搜索{
"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透明返回，Agent 可自行判断是否接受。
参数 | 类型 | 默认 | 说明 |
| string | — | 搜索关键词（必填） |
| number | 10 | 返回条数（1–20） |
| string | — | 限定单个域名，如 |
| string[] | — | 只返回这些域名的结果，如 |
| string[] | — | 排除这些域名的结果，如 |
| string | — | 区域提示：DDG |
| string | — |
|
| string | — | 精确时间窗 |
每条结果带稳定
id（sha1 前缀）。把这个id传给fetch_page即可深读该页，无需再手拼 URL。
research — 一次调用完成整轮调研替代 Agent「搜索 → 选页 → 抓取 → 总结」的循环，一次调用搞定：
{
"query": "2026 LLM open source models comparison",
"maxResults": 5,
"fetchTopN": 2,
"freshness": "month"
}返回证据简报（evidence brief）：
{
"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 按域名多样性选取（先每个域名取排名最高的一条，再按排名补足），避免单站垄断——某个站反爬 403 时其他域名的页面不受影响；rank 字段标注该结果在搜索结果中的原始排名
extractMode（默认 summary）：summary 返回去噪后的正文要点（省 token），full 返回整页 Markdown
总结由宿主模型完成——MCP 内部不依赖任何 LLM，保持零外部依赖、厂商无关
fetch_page — 抓取网页转结构化内容{
"url": "https://example.com/article",
"extractMode": "summary",
"maxLength": 8000
}extractMode：summary（默认省 token，返回去噪正文 mainText）/ full（返回整页 markdown）
返回 { url, title, description, headings, mainText, markdown, length, truncated, cached }——headings 是页面标题大纲，Agent 可先看结构再决定是否深读
也可以用结果 id：{ "id": "a1b2c3d4", "maxLength": 8000 }。
status — 透明状态页（诊断用）搜索失败时用 status 看为什么——是全部引擎挂掉、某个引擎被限频，还是你自己的 IP 被临时 Ban：
{
"server": "ai-search-mcp",
"uptimeSec": 1234,
"config": { "engine": "auto", "region": "cn-zh", "ratePerMinute": 8, "cacheTtlMs": 600000, "langRouting": false, "selectorOverride": false },
"cache": { "size": 12, "hits": 34, "misses": 5 },
"engines": [
{ "engine": "bing", "status": "cooling", "lastCode": "RATE_LIMITED", "consecutiveFailures": 3,
"lastOkAt": "2026-08-26T05:00:00.000Z", "lastFailAt": "2026-08-26T05:05:00.000Z", "cooldownUntil": "2026-08-26T05:06:00.000Z" },
{ "engine": "baidu", "status": "healthy", "lastCode": null, "consecutiveFailures": 0, ... }
]
}引擎状态：untested（未用过）→ healthy / degraded（连续失败）→ cooling（冷却中，链会跳过）
优雅降级：RATE_LIMITED 立即触发冷却（按 retryAfter，默认 60s），其他失败连续 2 次进入冷却——冷却期的引擎会被引擎链跳过，不再浪费请求
全部引擎失败时，search 的错误响应带 engineStatus 快照 + 归因摘要（如 bing=RATE_LIMITED (冷却至 13:45), baidu=验证码...），并区分"全部冷却"（疑似 IP 被 Ban）与普通失败
变量 | 默认 | 说明 |
|
| 单个引擎或逗号分隔引擎链（如 |
| — | 引擎自动选择的默认区域，如 |
|
| 默认结果条数（1–20） |
|
| 缓存 TTL（秒，0 表示关闭） |
| — | 缓存持久化文件路径，如 |
| — | 本地解析规则覆盖文件（JSON），引擎改版时免发版修复 |
| — | 远程解析规则覆盖 URL（如 GitHub Gist），启动时拉取；作者更新 Gist 即可修复所有用户 |
|
| 单次请求超时（毫秒） |
|
| 每个引擎每分钟最大请求数（0 关闭限频） |
|
| 请求间随机延迟范围（毫秒，0 关闭） |
|
|
|
|
|
|
|
|
|
|
|
|
| — | 使用 |
| — | 使用 |
| — | 代理地址，如 |
| 内置 | 自定义 User-Agent |
引擎 | 免费 | API Key | 时间过滤 | 说明 |
| ✅ | ❌ | ❌ | 海外专用（墙内不可达）；索引质量全球最佳，反爬严，需海外 IP + Cookie 会话 |
| ✅ | ❌ | ✅（ | 全球通用；中国区域默认，中英文覆盖好，国内免代理直连 |
| ✅ | ❌ | ✅（ | 全球备选；中国大陆直连可能超时（需代理） |
| ✅ | ❌ | ❌ | 海外专用；俄语/CIS 内容强，部分网络可达性好，反爬中等 |
| ✅ | ❌ | ❌ | 360 搜索；数据中心/国内 IP 均可直连，反爬相对宽松，中文原生引擎 |
| ✅ | ❌ | ❌ | 仅限国内；中文索引强，但反爬严（数据中心 IP 下带 Cookie 仍会触发图形验证码） |
| ✅ | ❌ | ❌ | 仅限国内；微信内容覆盖好，但缺 JS 生成的 SNUID 会话会被 302 拦回 |
| ❌ | ✅ | ✅（ | 官方 API，质量高，有免费额度 |
| ❌ | ✅ | ✅（ | 专为 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 在墙内不可达/被验证码拦截属预期（当前网络会先超时/报 RATE_LIMITED 后自动切换）。
免费引擎会限流。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 与服务条款；本工具只返回搜索摘要与链接，不转载全文内容。
所有引擎的 SERP 解析规则（标题/URL/摘要提取正则、反爬检测关键词）都外置在 src/selectors/*.json。当某个搜索引擎改版导致解析失效时，不必等待新版 npm——按优先级覆盖即可：
内置规则（随包分发，默认）
本地文件 SEARCH_SELECTOR_FILE=/path/selectors.json
远程 URL SEARCH_SELECTOR_OVERRIDE_URL=https://gist.githubusercontent.com/.../selectors.json（启动时拉取，优先级最高）
覆盖文件格式（按引擎 key 合并，未提到的引擎保持内置规则）：
{
"bing": {
"challenge": ["captcha", "challenge"],
"fields": {
"title": {
"pattern": "<h2[^>]*>\\s*<a[^>]+href=\"([^\"]+)\"[^>]*>([\\s\\S]*?)<\\/a>\\s*<\\/h2>",
"flags": "gi",
"urlGroup": 1,
"textGroup": 2
},
"snippet": {
"window": "after",
"size": 2000,
"pattern": "<p[^>]*>([\\s\\S]*?)<\\/p>",
"flags": "i",
"group": 1
}
}
}
}字段说明：title 必填（urlGroup = URL 捕获组，textGroup = 标题捕获组）；url 可选（window: "before" 在标题前窗口找链接）；snippet/snippetAlt 可选（window: "after" 在标题后找摘要，groups 支持多个捕获组取首个非空）；challenge 为反爬检测子串列表；domain.fallback 为 URL 解析失败时的兜底域名。
免发版工作流：用户报告"XX 引擎搜索坏了" → 作者把修复后的规则更新到一个 Gist → 用户设 SEARCH_SELECTOR_OVERRIDE_URL=<gist> 重启即修复。覆盖加载失败（文件损坏/网络不通）永远不会阻塞启动，自动回退上一级规则并打 warn 日志。
npm test # 137 个单元测试（Node 内置 test runner）
node scripts/smoke-test.js # 端到端冒烟：search + freshness + research（需要网络）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免责声明：本项目为独立开源项目，与 DuckDuckGo、Bing/Microsoft、Brave、Tavily、百度、搜狗均无关联、背书或赞助关系。百度/搜狗基于公开 HTML 解析，若这些站点变更页面结构可能导致解析失效。
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 | Default |
|---|---|---|---|
| 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) |
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.
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.
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.
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.
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.
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.
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 | Default |
|---|---|---|---|
| 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] |
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.
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.
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.
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.
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.
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.
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 | Default |
|---|---|---|---|
| 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] |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.3.4fetch_pageresearchsearchEach 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.
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.
With only 3 tools, the server is well-scoped for a web search and research workflow. Each tool earns its place with minimal redundancy.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Agent-driven search: build, import, tune, search, and score result quality — all over MCP.
Search the agentic web. 4,100+ sites, 11 tools incl. check_url + verify_mcp for probe-before-use.
Scrape, crawl and search the web for AI agents via MCP.
Stealth web browser for agents: search, fetch, click, download and type in persistent MCP sessions.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/zhulingyu666/ai-search-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
