Claude Web Search MCP Server
클로드 웹 검색 MCP 서버
이 MCP(Model Context Protocol) 서버는 Claude API를 사용하여 웹 검색 기능을 제공합니다. LLM은 표준화된 인터페이스를 통해 웹에서 최신 정보에 접근할 수 있습니다.
특징
Claude의 웹 검색 API를 사용한 웹 검색 도구
도메인 필터링 지원(허용 및 차단된 도메인)
검색당 구성 가능한 최대 결과
Claude Desktop 구성 파일에서 자동 구성
Related MCP server: Google Search MCP
필수 조건
Node.js 18 이상
웹 검색이 활성화된 Anthropic API 키
테스트용 Claude Desktop 앱
설치 및 설정
저장소를 복제합니다.
지엑스피1
종속성 설치:
npm install서버를 빌드하세요:
npm run build이렇게 하면 TypeScript 코드가 컴파일되고 서버가 실행 가능하게 됩니다.
글로벌 액세스를 위해 서버를 연결하세요:
npm link이렇게 하면
mcp-server-claude-search명령을 시스템 전체에서 사용할 수 있고, Claude Desktop 앱에서 해당 명령을 찾을 수 있습니다.
Claude Desktop App으로 서버 실행
서버가 설치되고 연결되면 Claude Desktop 앱이 올바르게 구성된 경우 서버를 자동으로 관리할 수 있습니다.
Claude Desktop 앱 구성: Claude Desktop 앱의 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찾아 실행할 수 있습니다.웹 검색 사용: 이제 클로드와의 대화에서 웹 검색 기능을 사용할 수 있습니다.
수동 서버 실행(테스트/개발용)
테스트나 개발 목적으로 서버를 수동으로 실행하려는 경우(Claude Desktop 앱 관리 외부):
전역적으로 연결된 명령을 사용합니다.
mcp-server-claude-searchtsx를 사용하여 직접(자동 재시작을 통한 개발의 경우):
npm run dev컴파일된 코드를 직접 실행합니다.
npm start
웹 검색 도구 매개변수
LLM에서 호출할 때 웹 검색 도구는 다음 매개변수를 지원합니다.
query(필수): 검색 쿼리 문자열.maxResults(선택 사항): 반환할 검색 결과의 최대 개수(기본값: 5).allowedDomains(선택 사항): 검색 결과에 포함할 도메인 배열(예:["example.com", "wikipedia.org"]).blockedDomains(선택 사항): 검색 결과에서 제외할 도메인 배열입니다.
특허
MIT
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