A
licenseB
qualityD
maintenanceA Model Context Protocol server that enables LLMs to perform web searches using Google's Custom Search API through a standardized interface.
1
47
MIT
Scrapeless MCP Server
无刮擦 Mcp 服务器
模型上下文协议 (MCP) 是一种开放协议，可实现 LLM 应用程序与外部数据源和工具的无缝集成。MCP 提供了一种标准化的方式将 LLM 与所需的上下文连接起来，帮助您高效地增强聊天界面、构建 AI 驱动的 IDE 或创建自定义 AI 工作流。
使用 Scrapeless MCP 服务器，将实时 Google SERP（Google 搜索、Google 航班、Google 地图、Google 招聘……）结果无缝集成到您的 LLM 应用程序中。该服务器充当 LLM（例如 ChatGPT、Claude 等）与 Scrapeless 的 Google SERP 之间的桥梁，为 AI 工作流、聊天机器人和研究工具提供动态上下文检索功能。
👉 实时 MCP 端点：
📦 NPM 包： scrapeless-mcp-server
概述
该项目提供了多个 MCP 服务器，使 Claude 等 AI 助手能够执行各种搜索操作并从以下位置检索数据：
Google 搜索
Related MCP server: MCP Web Research Server
工具
1. 搜索工具
名称：
google-search描述：使用 Scrapeless 搜索网页
参数：
query（必需）：该参数定义了您要搜索的查询。您可以使用常规 Google 搜索中使用的任何查询，例如 inurl:、site:、intitle:。gl（可选，默认值：“us”）：该参数定义 Google 搜索所使用的国家/地区。它是一个由两个字母组成的国家/地区代码。（例如，us 代表美国，uk 代表英国，fr 代表法国）。hl（可选，默认值：“en”）：该参数定义 Google 搜索使用的语言。它是一个由两个字母组成的语言代码。（例如，en 表示英语，es 表示西班牙语，fr 表示法语）。
设置指南
1. 获取无刮擦密钥
2.配置
{
"mcpServers": {
"scrapelessMcpServer": {
"command": "npx",
"args": ["-y", "scrapeless-mcp-server"],
"env": {
"SCRAPELESS_KEY": "YOUR_SCRAPELESS_KEY"
}
}
}
}示例查询
以下是如何将这些服务器与 Claude Desktop 一起使用的一些示例：
Google 搜索
Please search for "climate change solutions" and summarize the top results.安装
先决条件
Node.js 22 或更高版本
NPM 或 Yarn
从源安装
克隆存储库：
git clone https://github.com/scrapeless-ai/scrapeless-mcp-server.git
cd scrapeless-mcp-server安装依赖项：
npm install构建服务器：
npm run build社区
Available Tools
1 toolgoogle-searchCInspect
Fetch Google Search Results
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| gl | No | Parameter defines the country to use for the Google search. It's a two-letter country code. (e.g., us for the United States, uk for United Kingdom, or fr for France). | |
| hl | No | Parameter defines the language to use for the Google search. It's a two-letter language code. (e.g., en for English, es for Spanish, or fr for French). | |
| query | Yes | Parameter defines the query you want to search. You can use anything that you would use in a regular Google search. e.g. inurl:, site:, intitle:. We also support advanced search query parameters such as as_dt and as_eq. |
TDQS
C2.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Fetch' implies a read operation, but it doesn't disclose critical traits like rate limits, authentication needs, response format, pagination, or error handling. For a search tool with zero annotation coverage, this is a significant gap.
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 extremely concise with just three words, front-loaded and zero waste. Every word ('Fetch Google Search Results') directly contributes to stating the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (search functionality with parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain return values, error cases, or behavioral constraints, leaving the agent with insufficient information to use the tool effectively beyond basic input.
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 schema already documents all three parameters (query, gl, hl) with clear descriptions. The description adds no additional meaning beyond what the schema provides, such as examples or usage tips. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch Google Search Results' states the basic action (fetch) and resource (Google Search Results), but it's vague about scope and format. It doesn't specify what kind of results (e.g., web pages, images, news) or how many results are returned. Without sibling tools, differentiation isn't needed, but the purpose could be more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are no sibling tools mentioned, so no explicit comparisons are needed, but it lacks context about use cases, prerequisites, or limitations. It's a generic statement with no usage instructions.
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.
1 tool update
v1.0.0- First observed
google-search
TDQS
C2.9/5.0
Scored across 1 tool
Disambiguation5/5
With only one tool, there is no possibility of ambiguity or overlap between tools. The tool 'google-search' has a clear and distinct purpose of fetching Google search results, so agents cannot misselect between multiple options.
Naming Consistency5/5
The single tool name 'google-search' follows a consistent pattern of verb-noun (search as the verb, Google as the noun context), and with only one tool, there is no inconsistency to evaluate. The naming is clear and adheres to a predictable structure.
Tool Count2/5
The server has only one tool, which feels thin and under-scoped for a scraping-related domain. A single tool for fetching Google search results may not provide sufficient coverage for typical scraping workflows, such as parsing results, handling pagination, or interacting with other search engines, making it borderline too few for the apparent purpose.
Completeness2/5
Inferring the domain as web scraping or search data fetching, the tool surface is severely incomplete. It only offers a basic search fetch without supporting operations like filtering results, extracting specific data, managing queries, or integrating with other scraping tasks, leading to significant gaps that could cause agent failures in broader scraping scenarios.
Maintenance
ActivityMaintained
ResponsivenessUnresponsive
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
MCP server for Google search results via SERP API
Free web search for AI agents. No API key required. Hosted MCP in active development.
Related MCP Servers
- AlicenseBqualityDmaintenanceA Model Context Protocol server that enables Claude to perform web research by integrating Google search, extracting webpage content, and capturing screenshots.3999 npm20MIT
- AlicenseAqualityCmaintenanceA Model Context Protocol server that enables Claude to perform web research by integrating Google search, extracting webpage content, and capturing screenshots in real-time.4999 npm9MIT
- FlicenseAqualityDmaintenanceA Model Context Protocol server that provides web and image search capabilities through Google's Custom Search API, allowing AI assistants like Claude to access current information from the internet.22-