Claude Web Search MCP Server
クロードウェブ検索MCPサーバー
このMCP(モデルコンテキストプロトコル)サーバーは、Claude APIを使用したWeb検索機能を提供します。これにより、LLMは標準化されたインターフェースを通じてWebから最新の情報にアクセスできるようになります。
特徴
Claude の Web 検索 API を使用した Web 検索ツール
ドメインフィルタリング(許可ドメインとブロックドメイン)のサポート
検索ごとに設定可能な最大結果数
Claude Desktop 構成ファイルからの自動構成
Related MCP server: Google Search MCP
前提条件
Node.js 18以上
ウェブ検索が有効になっているAnthropic APIキー
Claude テスト用デスクトップアプリ
インストールとセットアップ
リポジトリをクローンします。
git clone https://github.com/Doriandarko/claude-search-mcp.git cd claude-search-mcp依存関係をインストールします:
npm installサーバーを構築します。
npm run buildこれにより、TypeScript コードがコンパイルされ、サーバーが実行可能になります。
グローバル アクセス用にサーバーをリンクします。
npm linkこれにより
mcp-server-claude-searchコマンドがシステム全体で使用できるようになり、Claude デスクトップ アプリがそれを検出できるようになります。
Claudeデスクトップアプリでサーバーを実行する
サーバーがインストールされリンクされると、正しく構成されていれば、Claude Desktop アプリはそれを自動的に管理できます。
Claudeデスクトップアプリの設定: ClaudeデスクトップアプリのMCPサーバー設定ファイル(通常は
claude_desktop_config.json)を開きます。このサーバーのエントリを追加または更新します。{ "mcpServers": { // ... other servers ... "claude-search": { "command": "mcp-server-claude-search", "env": { "ANTHROPIC_API_KEY": "YOUR_ANTHROPIC_API_KEY_HERE" } } // ... other servers ... } }"YOUR_ANTHROPIC_API_KEY_HERE"実際のAnthropic APIキーに置き換えてください。env変数がここで設定されていない場合、サーバーは~/code/claude-search-mcp/claude_desktop_config.jsonからもこのキーを読み取ろうとしますが、メイン設定でサーバーごとに定義することをお勧めします。Claudeデスクトップアプリを起動します。Claudeデスクトップアプリケーションを起動(または再起動)します。これで、必要に応じて
mcp-server-claude-search検出して起動できるようになります。Web 検索の使用: Claude との会話で Web 検索機能を使用できるようになりました。
手動サーバー実行(テスト/開発用)
テストまたは開発目的でサーバーを手動で実行する場合 (Claude デスクトップ アプリの管理外で) :
グローバルにリンクされたコマンドを使用する:
mcp-server-claude-searchtsx を直接使用する (自動再起動による開発の場合):
npm run devコンパイルされたコードを直接実行する:
npm start
ウェブ検索ツールのパラメータ
Web 検索ツールは、LLM によって呼び出されたときに次のパラメータをサポートします。
query(必須): 検索クエリ文字列。maxResults(オプション): 返される検索結果の最大数 (デフォルト: 5)。allowedDomains(オプション): 検索結果に含めるドメインの配列 (例:["example.com", "wikipedia.org"])。blockedDomains(オプション): 検索結果から除外するドメインの配列。
ライセンス
マサチューセッツ工科大学
Available Tools
1 toolweb_searchA
Search the web for real-time information about any topic. Use this tool when you need up-to-date information that might not be available in your training data, or when you need to verify current facts.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query to look up on the web | |
| maxResults | No | Maximum number of search results to return (default: 5) | |
| allowedDomains | No | Only include results from these domains | |
| blockedDomains | No | Never include results from these domains |
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. It mentions the tool's purpose and usage context but lacks details on behavioral traits such as rate limits, authentication needs, or specific output format. The description does not contradict any annotations, but it could be more informative about operational constraints.
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 and concise, consisting of two sentences that directly address purpose and usage guidelines without unnecessary details. Every sentence earns its place by providing essential information efficiently.
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 (web search with 4 parameters) and no output schema, the description is adequate but could be more complete. It covers purpose and usage well but lacks details on behavioral aspects like result format or limitations. With no annotations, it should ideally provide more context to fully guide the 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?
The input schema has 100% description coverage, so the schema already documents all parameters well. The description does not add any parameter-specific information beyond what the schema provides, such as examples or additional context. This meets the baseline for high schema coverage, but no extra value is added.
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's purpose with specific verbs ('search the web') and resources ('real-time information about any topic'). It distinguishes the tool's function from potential alternatives by emphasizing real-time, up-to-date information that might not be in training data, which is essential for a web search tool.
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: 'when you need up-to-date information that might not be available in your training data, or when you need to verify current facts.' This provides clear context and guidance for the agent, even though no sibling tools are listed, making it comprehensive for decision-making.
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
- First observed
web_search
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion or overlap between tools, as there are no other tools to compare it against. The single tool's purpose is clearly defined and distinct by default.
The single tool name 'web_search' follows a consistent verb_noun pattern, and since there are no other tools, there is no inconsistency to evaluate. The naming is straightforward and appropriate for its function.
A single tool is generally too few for most server purposes, as it limits functionality and can feel thin or incomplete. For a web search server, while the core function is covered, additional tools like advanced search filters or result management might be expected to enhance utility.
The server provides a basic search function, which covers the essential need for real-time information retrieval. However, there are notable gaps, such as lack of tools for refining searches, handling pagination, or accessing specific types of content, which could limit agent effectiveness in complex scenarios.
Maintenance
Related MCP Connectors
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
Web search and page-reading for AI agents. One-click OAuth connect, or a Caesar API key.
Web search, browser automation, scraping, crawling and CAPTCHA solving for AI agents.
The best web search for your AI Agent
Related MCP Servers
- AlicenseBqualityCmaintenanceFacilitates web search capabilities using Perplexity's API, allowing users to retrieve search results through Claude's interface.18MIT
- AlicenseBqualityDmaintenanceEnables Large Language Models to perform real-time web searches using Google Custom Search API. Integrates with Claude Desktop to retrieve current information from the internet.1MIT
- AlicenseNot gradedqualityDmaintenanceExposes Perplexity AI's search capabilities to Claude, enabling real-time web search and information retrieval within the assistant. The project is currently in active development with plans to support Perplexity Spaces and multi-source data synthesis.Apache 2.0
- AlicenseNot gradedqualityDmaintenanceEnables web search via Brave Search API with freshness filters, full page content fetching, and usage tracking. Designed for Claude integration.399 npmGPL 3.0