crawl-mcp
Server Quality Checklist
Latest release: v0.2.0
- Disambiguation5/5
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.
Naming Consistency5/5All tool names follow a consistent verb_noun pattern: search_* for searching different media types and crawl_* for crawling variants. This is highly predictable.
Tool Count5/58 tools is well-scoped for a search-and-crawl server. Each tool serves a distinct need with no redundancy or bloat.
Completeness5/5The 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.
Average 4.3/5 across 8 of 8 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
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.
Conciseness3/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose4/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior2/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
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.
Conciseness4/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior4/5
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.
Conciseness4/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- 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 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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters5/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/gqy20/crawl-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server