Integrates with OpenAI-compatible APIs for AI-powered content extraction and summarization, allowing users to process web page content with custom instructions and JSON schemas.
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., "@crawl-mcp search 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.
基于 crawl4ai 和 FastMCP 的 MCP 服务器，提供网页爬取和搜索功能。
crawl_single - 单页爬取（自动降级：快速提取 → 浏览器渲染）
crawl_site - 递归爬取整个网站
crawl_batch - 批量爬取（自动降级，三阶段并行优化）
search_text - 通用网页搜索
search_news - 新闻内容搜索
search_images - 图片搜索（支持下载和 AI 分析）
search_books - 图书/电子书搜索
search_videos - 视频搜索（含时长、播放量等）
LLM 后处理（实验性）- 对已爬取的 Markdown 进行 AI 摘要/结构化提取
图片分析 - 使用视觉模型分析图片内容
核心定位：专业爬取工具。不配置 API Key 即可使用全部爬取和搜索功能。
Related MCP server: Deep Search MCP Server
crawl_single / crawl_batch 内置自动降级：静态页走快速路径（~0.5s），SPA 自动 fallback 到浏览器。
场景 | 耗时 | 说明 |
crawl_single（静态博客） | ~0.5s | 快速提取路径 |
crawl_single（SPA 网站） | ~0.6s + ~23s | 快速检测失败 → 浏览器降级 |
crawl_batch 10 页（全静态） | ~0.5s | 并行快速提取 |
crawl_batch 10 页（混合） | ~24s | 静态页快速 + SPA 浏览器 |
search_text / news / books / videos | ~1.5-2s | ddgs 搜索 |
关键优势：
无需手动选择工具：crawl_single 自动判断用快速提取还是浏览器
静态页面享受亚秒级速度，SPA 自动降级保证完整性
批量爬取智能分流：静态 URL 并行快提取，失败项才走浏览器
搜索类工具全部基于 ddgs，秒级响应
无需配置任何 API Key 即可使用核心功能
pip install crawl-mcp默认配置不需要任何 API Key。以下工具都可以直接使用：
crawl_single / crawl_batch / crawl_site
search_text / search_news / search_books / search_videos / search_images
只有两类可选能力需要 API Key：
传入 llm_config 做 LLM 后处理
调用 search_images 且设置 analyze=true 做图片分析
{
"mcpServers": {
"crawl-mcp": {
"command": "uvx",
"args": ["crawl-mcp"]
}
}
}如果需要 llm_config 后处理或图片分析，再增加 env：
{
"mcpServers": {
"crawl-mcp": {
"command": "uvx",
"args": ["crawl-mcp"],
"env": {
"CRAWL_MCP_API_KEY": "your-api-key",
"CRAWL_MCP_BASE_URL": "https://api.openai.com/v1",
"CRAWL_MCP_TEXT_MODEL": "glm-4.7",
"CRAWL_MCP_VISION_MODEL": "glm-4.6v"
}
}
}
}变量 | 说明 | 必需 | 默认值 |
| LLM 后处理 / 图片分析使用的 API 密钥 | 否 | - |
| OpenAI 兼容 API 基础 URL | 否 |
|
| LLM 后处理模型名称 | 否 |
|
| 图片分析模型名称 | 否 |
|
不配置 CRAWL_MCP_API_KEY 时，所有爬取和搜索工具仍可正常使用。传入 llm_config 时会跳过 LLM 后处理并返回 llm_skipped；search_images(analyze=true) 会返回图片分析配置错误，但普通图片搜索和下载不受影响。
crawl_single 和 crawl_batch 支持可选的 llm_config 参数：
{
"instruction": "提取产品信息",
"schema": {
"type": "object",
"properties": {
"name": {"type": "string"},
"price": {"type": "number"}
}
}
}instruction: 提取指令
schema: 可选的 JSON Schema（用于结构化数据提取）
前提条件：必须配置 CRAWL_MCP_API_KEY，否则会优雅跳过并在结果中返回 llm_skipped 提示。
已知一个明确 URL、需要提取页面正文 Markdown 时使用。内置「快速提取 → 浏览器渲染」自动降级策略：
{
"name": "crawl_single",
"arguments": {
"url": "https://example.com/article"
}
}返回示例：
{
"success": true,
"markdown": "# Article Title\n\nContent...",
"title": "Article Title",
"method": "fast_extract"
}可选参数：
enhanced: 浏览器增强模式，适用于 SPA/慢加载页面；只在浏览器路径生效
prefer_fast: 是否优先快速提取（默认 true，设 false 强制浏览器）
min_content_length: 快速提取最小内容长度阈值（默认 200 字符）
llm_config: LLM 后处理配置（实验性，需 API Key）
若要强制浏览器增强模式，请同时设置
prefer_fast=false和enhanced=true。fallback_reason仅在快速提取失败后进入浏览器 fallback 时返回。
已知一组 URL、需要并行抓取多个页面时使用。它会先并行快速提取所有 URL，只把失败、内容不足或 SPA 骨架页送入浏览器 fallback。
{
"name": "crawl_batch",
"arguments": {
"urls": [
"https://example.com/a",
"https://example.com/b"
],
"concurrent": 3
}
}可选参数：
concurrent: 浏览器 fallback 并发数（默认 3）
prefer_fast: 是否优先快速提取（默认 true，设 false 时所有 URL 直接走浏览器）
min_content_length: 快速提取最小内容长度阈值（默认 200 字符）
llm_config: LLM 后处理配置（实验性，需 API Key）
llm_concurrent: LLM 后处理并发数（默认 3）
返回为结果列表。method 仅在 prefer_fast=true 的快速/降级路径中出现；fallback_reason 仅在单项发生浏览器 fallback 时出现。
只有一个网站入口、希望沿站内链接发现并抓取若干页面时使用。它使用浏览器和 BFS 深度策略，不走快速提取，也不支持 LLM 后处理。
{
"name": "crawl_site",
"arguments": {
"url": "https://example.com",
"depth": 2,
"pages": 10,
"concurrent": 3
}
}参数：
depth: 最大链接深度（默认 2）
pages: 最大页面数（默认 10）
concurrent: 浏览器爬取并发数（默认 3）
返回包含 successful_pages、total_pages、success_rate 和 results。
适用于搜索技术文档、百科、博客、论坛、教程等网页内容。搜索工具只返回摘要和链接，不抓取页面正文；如需正文，请对结果 URL 再调用 crawl_single 或 crawl_batch。
{
"name": "search_text",
"arguments": {
"query": "Python 快速排序算法",
"region": "cn-zh",
"max_results": 5
}
}返回格式：
{
"success": true,
"query": "Python 快速排序算法",
"count": 5,
"results": [
{"title": "...", "href": "https://...", "body": "..."}
]
}搜索图片，支持下载到本地和 AI 分析。
{
"name": "search_images",
"arguments": {
"query": "cute cat",
"max_results": 10,
"download": true,
"download_count": 5,
"analyze": true,
"analysis_prompt": "描述这张图片的内容和风格"
}
}返回格式：
{
"success": true,
"query": "cute cat",
"search_results": {"count": 10, "results": [...]},
"download_results": {"total": 5, "downloaded": 5, ...},
"analysis_results": {"count": 5, "results": [...]}
}图书搜索和视频搜索，用法与 search_text 类似。返回字段由 ddgs 上游决定，通常包含标题、链接、摘要或媒体信息，具体字段会随来源变化。
uv sync
uv run pytest
uv run python -m crawl4ai_mcp.fastmcp_server --http当前准备发布版本：0.2.0
发布前检查：
uv run pytest tests/unit
uv run ruff check .
uv run ruff format --check .
uv build创建并推送 tag 后会触发 GitHub Actions 发布到 PyPI：
git tag v0.2.0
git push origin v0.2.0MIT License
批量爬取多个网页（自动降级版）
适用于已经有一组明确 URL、需要并行抓取多个页面的场景。 默认对所有 URL 并行快速提取；只有失败、内容过短或 SPA 骨架页才进入浏览器 fallback。 若只有一个 URL，请使用 crawl_single；若只有入口页并希望发现站内链接，请使用 crawl_site。
参数组合：
prefer_fast=True：静态页走快速路径，失败项才走浏览器 fallback。
prefer_fast=False：所有 URL 都直接走浏览器，不返回 fast/fallback 方法标记。
min_content_length 只影响快速提取是否被认为足够完整。
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | URL 列表 | |
| concurrent | No | 网页爬取并发数（默认：3） | |
| llm_config | No | [实验性] LLM 后处理配置（可选），需设置 CRAWL_MCP_API_KEY 才生效 | |
| prefer_fast | No | 是否优先尝试快速提取（默认 True） | |
| llm_concurrent | No | LLM 处理并发数（默认：3） | |
| min_content_length | No | 快速提取最小内容长度阈值（默认 200 字符） |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description explains the key behavioral nuance: default parallel fast extraction with browser fallback on failure, too-short content, or SPA skeleton pages. It also discloses that setting prefer_fast=False changes the output by omitting fast/fallback method markers. This goes beyond a basic summary, though it doesn't mention potential side effects or rate limits.
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: it states the purpose, typical usage, alternatives, and then parameter combinations. It is concise, using bullet points for clarity, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers the main use case, fallback behavior, and key parameter effects. An output schema exists, so return values need not be described. It does not detail concurrency or LLM config semantics, but those are documented in the schema, making the overall description sufficient.
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 baseline is 3. The description adds value by explaining how prefer_fast and min_content_length interact (e.g., min_content_length only affects whether fast extraction is deemed sufficient, and prefer_fast=False disables the fast path entirely). This contextualizes parameters beyond the schema's basic descriptions.
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 it performs batch crawling of multiple web pages with an automatic degradation strategy. It explicitly says it's for scenarios with a clear set of URLs needing parallel crawling, and distinguishes itself from crawl_single and crawl_site.
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 guidance: use crawl_single for a single URL, use crawl_site for an entry page with link discovery needs. This gives clear when-to-use and alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
爬取单个网页（自动降级：快速提取 → 浏览器渲染）
适用于已经知道一个明确 URL、需要提取该页面正文 Markdown 的场景。 默认先尝试轻量级快速提取（适合静态文章/文档页），失败、内容过短或检测到 SPA 骨架页时 自动切换到浏览器渲染。若要从一个入口页继续发现站内链接，请使用 crawl_site； 若已有多个明确 URL，请使用 crawl_batch。
参数组合：
默认 prefer_fast=True：先快提取，必要时 fallback 到浏览器。
prefer_fast=False：跳过快速提取，强制直接使用浏览器。
enhanced=True：只影响浏览器路径的等待时间；不会单独跳过快速提取。 如需强制浏览器增强模式，请同时设置 prefer_fast=False, enhanced=True。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 要爬取的网页 URL | |
| enhanced | No | 浏览器增强模式。适用于 SPA/慢加载页面，等待时间更长；仅在浏览器路径生效。 | |
| llm_config | No | [实验性] LLM 后处理配置（可选），需设置 CRAWL_MCP_API_KEY 才生效。 支持三种格式: - 字典: {"instruction": "总结", "schema": {...}} - JSON 字符串: '{"instruction": "总结"}' - 纯文本: "总结页面内容"（自动作为 instruction） 未设置 API Key 时传此参数会优雅跳过，结果中包含 llm_skipped 提示。 | |
| prefer_fast | No | 是否优先尝试快速提取（默认 True）。设为 False 时强制浏览器爬取。 | |
| min_content_length | No | 快速提取结果的最小内容长度阈值（默认 200 字符） |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently reveals the auto-degradation algorithm (fast extraction first, then browser rendering on failure, short content, or SPA detection) and clarifies parameter interactions (e.g., 'enhanced=True：只影响浏览器路径的等待时间'). However, it does not mention potential rate limits, timeouts, or error handling beyond the fallback behavior, so it falls slightly short of a perfect score.
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: it begins with a concise summary line, then details the core use case, follow with alternative tool guidance, and ends with parameter combination explanations. While it is somewhat lengthy, every sentence contributes essential information, and the structure aids readability. It earns a 4 rather than 5 due to slight redundancy in the parameter combos section.
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 having no annotations, the description is remarkably complete for a tool with 5 parameters and an output schema. It covers the core behavior (auto-degradation), usage context, alternatives, and all parameter interplay. The presence of an output schema means return values don't need description, and the schema fully documents each parameter. There are no major knowledge gaps for an agent to invoke this tool 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?
Since schema description coverage is 100%, the baseline is 3. The description adds meaningful value by explaining parameter combinations and edge cases not explicitly in the schema, such as '如需强制浏览器增强模式，请同时设置 prefer_fast=False, enhanced=True' (to force browser enhanced mode, set both prefer_fast=False and enhanced=True). This enriches understanding beyond the schema descriptions.
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 explicitly states the tool's function: '爬取单个网页' (crawl a single webpage) and '提取该页面正文 Markdown' (extract main content as Markdown), providing a specific verb, resource, and output format. It further differentiates from siblings by naming crawl_site and crawl_batch for alternative use cases, making the purpose unambiguous.
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 clearly specifies when to use this tool: '适用于已经知道一个明确 URL、需要提取该页面正文 Markdown 的场景' (for scenarios where you already know a specific URL and need to extract the page content as Markdown). It also provides explicit alternatives: '若要从一个入口页继续发现站内链接，请使用 crawl_site；若已有多个明确 URL，请使用 crawl_batch', with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
从入口页开始递归爬取站内页面（浏览器 + BFS 深度爬取）
适用于只有一个网站入口、希望沿站内链接抓取若干页面的场景。 与 crawl_batch 不同，本工具会从起始页发现链接；与 crawl_single/crawl_batch 不同， 本工具不走快速提取自动降级，也不支持 LLM 后处理。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 起始 URL | |
| depth | No | 最大链接深度（默认 2）。数值越大，可能访问更多站内页面。 | |
| pages | No | 最大页面数（默认 10）。用于限制递归爬取规模。 | |
| concurrent | No | 浏览器爬取并发数（默认 3）。 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It transparently discloses key behaviors: browser-based crawling, BFS depth traversal, link discovery from the start page, and explicitly excludes fast extraction auto-degradation and LLM post-processing. This goes beyond the schema, giving a clear behavioral profile, though it could mention rate limits or robots.txt compliance.
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, consisting of three sentences. The core action is front-loaded, and the sibling comparisons are efficiently packed. It is slightly dense, but every sentence earns its place, making it appropriately sized.
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 moderate complexity (4 parameters, output schema present). The description covers purpose, usage scenario, behavioral traits, and exclusions. Since an output schema exists, return-value details are not required. The description is complete enough for an agent to decide when to use it and what to expect, though minor edge-case behaviors (e.g., error handling) are unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides complete descriptions for all four parameters (100% coverage), so the baseline is 3. The description itself does not add significant parameter-level semantics beyond what the schema already states; it only implicitly mentions depth and page limits, which are already documented.
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 a specific action ('recursively crawl site pages') and identifies the resource (site pages). It explicitly distinguishes itself from crawl_batch (which doesn't discover links from the starting page) and crawl_single/crawl_batch (which use fast extraction and support LLM post-processing), making its unique role unambiguous.
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 provides an explicit usage scenario: '适用于只有一个网站入口、希望沿站内链接抓取若干页面的场景' (suitable for a single entry point and wanting to crawl pages via internal links). It also contrasts with sibling tools, clarifying when not to use it and what alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索图书
适用于查找技术书籍、学术资料、电子书等。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 搜索关键词 | |
| region | No | 区域代码（同 search_text） | wt-wt |
| max_results | No | 最大结果数（默认：10） |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It only restates the operation as 'search' and gives use cases, without confirming read-only behavior, pagination, quirks, or failure modes.
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 just two short, purposeful sentences: a clear function name and a scope sentence. No filler or redundant sections.
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 search tool with a fully documented input schema and an output schema present, this description is largely sufficient. It could be improved by explicitly noting when to prefer search_books over search_text, but the sibling set and scope sentence make the use case clear.
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?
All three parameters are documented in the schema with descriptions, so coverage is 100%. The tool description adds no additional parameter details beyond what the schema already provides.
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 identifies the action as '搜索图书' (search books) and specifies applicable content types (technical books, academic materials, ebooks). This distinguishes it from siblings like search_videos and search_images.
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 phrase '适用于查找技术书籍、学术资料、电子书等' provides clear usage context for book-related searches. It does not explicitly mention alternatives or exclusions, but the sibling set makes the intended domain evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索图片（支持下载和分析）
=== 基础搜索 === query: 搜索关键词 max_results: 搜索结果数量（默认：10）
=== 搜索过滤 === region: 区域代码 (wt-wt/us-en/cn-zh等) safesearch: 安全搜索 (on/moderate/off) timelimit: 时间限制 (d=天, w=周) size: 图片尺寸 (Small/Medium/Large/Wallpaper) color: 颜色过滤 (如 "Red", "Monochrome") type_image: 类型 (photo/clipart/gif/transparent/line) layout: 布局 (Square/Tall/Wide)
=== 下载选项 === download: 是否下载到本地（默认：False） download_count: 下载数量（默认：全部） output_dir: 下载目录（默认：./downloads/images）
=== 分析选项 === analyze: 是否使用图片模型分析（默认：False） analysis_prompt: 分析提示词 analyze_concurrent: 图片分析并发数（默认：3）
=== 返回格式 === { "success": True, "query": "butterfly", "search_results": { "count": 10, "results": [ { "title": "...", "image": "https://...", "thumbnail": "https://...", "width": 1920, "height": 1080, "source": "Bing" }, ... ] }, "download_results": { # 仅当 download=True 时 "total": 5, "downloaded": 5, "output_dir": "./downloads/images" }, "analysis_results": { # 仅当 analyze=True 时 "count": 5, "results": [ { "image": "...", "type": "local", "analysis": "这是一张..." } ] } }
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | ||
| color | No | ||
| query | Yes | ||
| layout | No | ||
| region | No | wt-wt | |
| analyze | No | ||
| download | No | ||
| timelimit | No | ||
| output_dir | No | ./downloads/images | |
| safesearch | No | moderate | |
| type_image | No | ||
| max_results | No | ||
| download_count | No | ||
| analysis_prompt | No | 详细描述这张图片的内容 | |
| analyze_concurrent | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains defaults for every parameter, conditional output presence (e.g., download_results only when download=True), and the exact structure of all return fields. It also discloses concurrency settings and output directory behavior. This is exceptionally transparent.
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?
Although long, the description is well-organized into clear sections (basic search, filters, download, analysis, return format). Each section is directly relevant to the parameters it explains, and no content is redundant with the schema. The front-loaded summary line gives immediate context. It is as concise as possible given the tool's complexity.
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 exceptionally complete for a tool with 15 parameters and no annotations. It includes the return format with a detailed example, parameter explanations, defaults, conditional behavior, and even the concurrency model. Nothing about the tool's behavior is left ambiguous, making it fully self-contained for an AI agent.
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 0%, yet the description provides semantic meaning for all 15 parameters. It explains the format for region codes, safesearch values, time limits, size/type/layout options, color examples, and the meaning of download/analyze flags. It also clarifies default values and the count semantics. This fully compensates for the schema's lack of descriptions.
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 '搜索图片（支持下载和分析）' which clearly states the verb (search) and resource (images), and explicitly notes additional capabilities (download and analysis). This distinguishes it from sibling tools like search_videos, search_text, and search_books, which are for other media types.
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 clearly implies its usage for image search with a comprehensive list of filters, download, and analysis options. However, it does not explicitly contrast itself with alternatives or state when-not-to-use, which would merit a 5. The context is sufficiently clear from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索新闻内容
适用于搜索突发新闻、时事、财经、体育等时效性内容。 只返回新闻搜索结果摘要和来源链接，不抓取全文；如需全文，请对结果 URL 再调用 crawl_single。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 搜索关键词 | |
| region | No | 区域代码（同 search_text） | wt-wt |
| timelimit | No | 时间限制 (d=天, w=周, m=月) | |
| safesearch | No | 安全搜索 (on/moderate/off) | moderate |
| max_results | No | 最大结果数（默认：10） |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the key behavioral boundaries: only returns search result summaries and source links, not full article text, and recommends crawl_single for full content. It does not mention rate limits, authentication, or result ordering, but the core behavior is transparently described.
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 and well-structured: a one-line purpose statement, followed by usage context and a clear limitation/alternative. Every sentence adds value and there is no redundancy or filler.
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 a full parameter schema and an output schema, so the description need not explain return values. It effectively covers the main use case, the critical limitation (no full text), and the follow-up action (crawl_single). Minor gaps like pagination or sort behavior are not essential for a search tool of this complexity, so the description is near-complete.
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 input schema fully documents all five parameters (query, region, timelimit, safesearch, max_results). The description adds no extra parameter-level information, but the baseline of 3 is appropriate because the schema already handles semantics completely.
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 identifies the tool's function: '搜索新闻内容' (search news content). It also distinguishes itself from siblings by explicitly stating it returns only summaries and source links rather than full text, and points to crawl_single for full text, making its unique role among the sibling tools clear.
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 states when to use it ('适用于搜索突发新闻、时事、财经、体育等时效性内容') and what it does not do ('不抓取全文'), providing an explicit alternative ('如需全文，请对结果 URL 再调用 crawl_single'). This gives the agent clear selection and follow-up guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索网页内容（通用搜索）
适用于搜索技术文档、百科、博客、论坛、教程等网页内容。 只返回搜索结果摘要和链接，不抓取页面正文；如需正文，请对结果 URL 再调用 crawl_single/crawl_batch。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 搜索关键词 | |
| region | No | 区域代码 - wt-wt: 无区域限制（默认） - us-en: 美国（英语） - cn-zh: 中国（中文） - uk-en: 英国（英语） - jp-jp: 日本（日语） | wt-wt |
| timelimit | No | 时间限制 (d=天, w=周, m=月, y=年) | |
| safesearch | No | 安全搜索 (on/moderate/off) | moderate |
| max_results | No | 最大结果数（默认：10） |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and clearly discloses that only search result summaries and links are returned, not the page body. It does not mention limitations like pagination or rate limits, but the key behavioral trait is communicated effectively.
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 consists of two tight sentences: the first states purpose and use cases, the second sets expectations about output and directs to crawl tools for full content. Every word earns its place, and it starts with the verb phrase '搜索网页内容'.
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 covers purpose, use cases, and a key behavioral limitation, while the output schema handles return value details. It could have mentioned default result count or that it supports multiple regions, but the schema already documents those. Overall, it's adequate for a search tool with 5 parameters.
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 does not add parameter-specific meaning beyond the schema, but it correctly implies the tool is for textual search. It does not repeat parameter details, which is acceptable given the thorough 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 performs a general web text search, listing specific content types (technical docs, encyclopedias, blogs, forums, tutorials). It distinguishes from sibling tools like search_videos and search_books, and from crawl tools by explicitly noting it does not fetch 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 explicitly states when to use this tool (searching text-oriented web content) and when to use alternatives: if full page content is needed, it directs the user to call crawl_single/crawl_batch on the result URLs. This clear usage guidance sets it apart from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索视频
适用于查找教程视频、演示视频、课程录像等。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 搜索关键词 | |
| region | No | 区域代码（同 search_text） | wt-wt |
| timelimit | No | 时间限制 (d=天, w=周) | |
| safesearch | No | 安全搜索 (on/moderate/off) | moderate |
| max_results | No | 最大结果数（默认：10） |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the purpose and use cases, with no mention of safety, side effects, authentication, rate limits, or return behavior. For a search tool, read-only is implied but not explicitly stated.
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 only two sentences long, but the first sentence '搜索视频' is a direct restatement of the tool name and adds no new information. The second sentence provides useful context. While compact, the redundancy prevents a higher score.
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, the presence of an output schema, and complete parameter descriptions, the description covers the core purpose and a use case. However, it lacks explicit usage guidelines and behavioral transparency, making it minimally viable but not comprehensive.
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 all five parameters (query, region, timelimit, safesearch, max_results) fully described in the input schema. The description adds no parameter-specific meaning, which is acceptable given the schema's completeness.
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 '搜索视频' restates the tool name, but the second sentence '适用于查找教程视频、演示视频、课程录像等' specifies concrete use cases (tutorials, demos, course recordings). This clarifies the resource type and intended scope, even though it does not explicitly distinguish from sibling search tools.
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 phrase '适用于查找...' implies a context for using the tool (video-related searches), but there is no explicit when-to-use vs alternatives or exclusions. The agent gets some guidance but lacks clear differentiation from sibling search tools like search_text or search_images.
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.
v0.2.0crawl_batchcrawl_singlecrawl_sitesearch_bookssearch_imagessearch_newssearch_textsearch_videosScored across 8 tools
Each search tool targets a distinct content type (videos, images, text, books, news), and each crawl tool specifies a clear scenario (single URL, site discovery, batch URLs). No two tools have overlapping purposes.
All tool names follow a consistent verb_noun pattern: search_* for searching different media types and crawl_* for crawling variants. This is highly predictable.
8 tools is well-scoped for a search-and-crawl server. Each tool serves a distinct need with no redundancy or bloat.
The tool set covers the full search-and-crawl lifecycle: searching multiple content types, extracting page content, batch processing, and site traversal. There are no obvious missing operations for the stated purpose.
MCP server for web extraction and rendering via AceDataCloud WebExtrator
One MCP for the Web. Easily search, crawl, navigate, and extract websites without getting blocked.…
Scrape, crawl and search the web for AI agents via MCP.
All HasData scraping tools in one MCP server: Google, TikTok, Instagram, maps, e-commerce and more.