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
概要
このプロジェクトは、Claude のような AI アシスタントがさまざまな検索操作を実行し、以下からデータを取得できるようにする複数の MCP サーバーを提供します。
Google検索
Related MCP server: MCP Web Research Server
ツール
1. 検索ツール
名前:
google-search説明: Scrapelessを使用してWebを検索します
パラメータ:
query(必須): パラメータは検索クエリを定義します。通常のGoogle検索で使用するものなら何でも使用できます。例: inurl:、site:、intitle:。gl(オプション、デフォルト:「us」): このパラメータは、Google検索で使用する国を定義します。2文字の国コードです。(例:米国の場合はus、英国の場合はuk、フランスの場合はfr)。hl(オプション、デフォルト:"en"):このパラメータは、Google検索で使用する言語を定義します。2文字の言語コードです。(例:英語:en、スペイン語:es、フランス語:fr)。
セットアップガイド
1. Scrapeless Keyを入手する
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
| 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
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.
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.
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.
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.
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.
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
Scored across 1 tool
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.
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.
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.
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
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 LLMs to perform web searches using Google's Custom Search API through a standardized interface.147MIT
- 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-