WebSearch-MCP
The WebSearch-MCP server provides real-time web search capabilities for AI assistants using the Model Context Protocol (MCP). It integrates with a WebSearch Crawler API to retrieve and process up-to-date information.
Capabilities include:
Performing customizable web searches via a standardized MCP interface
Modifying search parameters (language, region, number of results, result type)
Filtering results by excluding/including specific domains or terms
Returning a configurable number of search results (default: 10)
Supporting various MCP clients including Claude Desktop, Cursor IDE, and Cline
Offering development tools for local testing and programmatic library usage
Utilizes FlareSolverr to bypass Cloudflare protection when crawling websites, ensuring more reliable search results from protected sites
Integrates with Docker to run the WebSearch Crawler API service, which handles the actual web searches and retrieves results from the internet
Performs web searches through Google's search engine, with the ability to customize search parameters like language, region, and result types
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@WebSearch-MCPfind recent news about AI advancements in healthcare"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
WebSearch-MCP
A Model Context Protocol (MCP) server implementation that provides a web search capability over stdio transport. This server integrates with a WebSearch Crawler API to retrieve search results.
Table of Contents
Related MCP server: MCP Server for Google Search
About
WebSearch-MCP is a Model Context Protocol server that provides web search capabilities to AI assistants that support MCP. It allows AI models like Claude to search the web in real-time, retrieving up-to-date information about any topic.
The server integrates with a Crawler API service that handles the actual web searches, and communicates with AI assistants using the standardized Model Context Protocol.
Installation
Installing via Smithery
To install WebSearch for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @mnhlt/WebSearch-MCP --client claudeManual Installation
npm install -g websearch-mcpOr use without installing:
npx websearch-mcpConfiguration
The WebSearch MCP server can be configured using environment variables:
API_URL: The URL of the WebSearch Crawler API (default:http://localhost:3001)MAX_SEARCH_RESULT: Maximum number of search results to return when not specified in the request (default:5)
Examples:
# Configure API URL
API_URL=https://crawler.example.com npx websearch-mcp
# Configure maximum search results
MAX_SEARCH_RESULT=10 npx websearch-mcp
# Configure both
API_URL=https://crawler.example.com MAX_SEARCH_RESULT=10 npx websearch-mcpSetup & Integration
Setting up WebSearch-MCP involves two main parts: configuring the crawler service that performs the actual web searches, and integrating the MCP server with your AI client applications.
Setting Up the Crawler Service
The WebSearch MCP server requires a crawler service to perform the actual web searches. You can easily set up the crawler service using Docker Compose.
Prerequisites
Docker and Docker Compose
Starting the Crawler Service
Create a file named
docker-compose.ymlwith the following content:
version: '3.8'
services:
crawler:
image: laituanmanh/websearch-crawler:latest
container_name: websearch-api
restart: unless-stopped
ports:
- "3001:3001"
environment:
- NODE_ENV=production
- PORT=3001
- LOG_LEVEL=info
- FLARESOLVERR_URL=http://flaresolverr:8191/v1
depends_on:
- flaresolverr
volumes:
- crawler_storage:/app/storage
flaresolverr:
image: 21hsmw/flaresolverr:nodriver
container_name: flaresolverr
restart: unless-stopped
environment:
- LOG_LEVEL=info
- TZ=UTC
volumes:
crawler_storage:workaround for Mac Apple Silicon
version: '3.8'
services:
crawler:
image: laituanmanh/websearch-crawler:latest
container_name: websearch-api
platform: "linux/amd64"
restart: unless-stopped
ports:
- "3001:3001"
environment:
- NODE_ENV=production
- PORT=3001
- LOG_LEVEL=info
- FLARESOLVERR_URL=http://flaresolverr:8191/v1
depends_on:
- flaresolverr
volumes:
- crawler_storage:/app/storage
flaresolverr:
image: 21hsmw/flaresolverr:nodriver
platform: "linux/arm64"
container_name: flaresolverr
restart: unless-stopped
environment:
- LOG_LEVEL=info
- TZ=UTC
volumes:
crawler_storage:Start the services:
docker-compose up -dVerify that the services are running:
docker-compose psTest the crawler API health endpoint:
curl http://localhost:3001/healthExpected response:
{
"status": "ok",
"details": {
"status": "ok",
"flaresolverr": true,
"google": true,
"message": null
}
}The crawler API will be available at http://localhost:3001.
Testing the Crawler API
You can test the crawler API directly using curl:
curl -X POST http://localhost:3001/crawl \
-H "Content-Type: application/json" \
-d '{
"query": "typescript best practices",
"numResults": 2,
"language": "en",
"filters": {
"excludeDomains": ["youtube.com"],
"resultType": "all"
}
}'Custom Configuration
You can customize the crawler service by modifying the environment variables in the docker-compose.yml file:
PORT: The port on which the crawler API listens (default: 3001)LOG_LEVEL: Logging level (options: debug, info, warn, error)FLARESOLVERR_URL: URL of the FlareSolverr service (for bypassing Cloudflare protection)
Integrating with MCP Clients
Quick Reference: MCP Configuration
Here's a quick reference for MCP configuration across different clients:
{
"mcpServers": {
"websearch": {
"command": "npx",
"args": [
"websearch-mcp"
],
"environment": {
"API_URL": "http://localhost:3001",
"MAX_SEARCH_RESULT": "5" // reduce to save your tokens, increase for wider information gain
}
}
}
}Workaround for Windows, due to Issue
{
"mcpServers": {
"websearch": {
"command": "cmd",
"args": [
"/c",
"npx",
"websearch-mcp"
],
"environment": {
"API_URL": "http://localhost:3001",
"MAX_SEARCH_RESULT": "1"
}
}
}
}Usage
This package implements an MCP server using stdio transport that exposes a web_search tool with the following parameters:
Parameters
query(required): The search query to look upnumResults(optional): Number of results to return (default: 5)language(optional): Language code for search results (e.g., 'en')region(optional): Region code for search results (e.g., 'us')excludeDomains(optional): Domains to exclude from resultsincludeDomains(optional): Only include these domains in resultsexcludeTerms(optional): Terms to exclude from resultsresultType(optional): Type of results to return ('all', 'news', or 'blogs')
Example Search Response
Here's an example of a search response:
{
"query": "machine learning trends",
"results": [
{
"title": "Top Machine Learning Trends in 2025",
"snippet": "The key machine learning trends for 2025 include multimodal AI, generative models, and quantum machine learning applications in enterprise...",
"url": "https://example.com/machine-learning-trends-2025",
"siteName": "AI Research Today",
"byline": "Dr. Jane Smith"
},
{
"title": "The Evolution of Machine Learning: 2020-2025",
"snippet": "Over the past five years, machine learning has evolved from primarily supervised learning approaches to more sophisticated self-supervised and reinforcement learning paradigms...",
"url": "https://example.com/ml-evolution",
"siteName": "Tech Insights",
"byline": "John Doe"
}
]
}Testing Locally
To test the WebSearch MCP server locally, you can use the included test client:
npm run test-clientThis will start the MCP server and a simple command-line interface that allows you to enter search queries and see the results.
You can also configure the API_URL for the test client:
API_URL=https://crawler.example.com npm run test-clientAs a Library
You can use this package programmatically:
import { createMCPClient } from '@modelcontextprotocol/sdk';
// Create an MCP client
const client = createMCPClient({
transport: { type: 'subprocess', command: 'npx websearch-mcp' }
});
// Execute a web search
const response = await client.request({
method: 'call_tool',
params: {
name: 'web_search',
arguments: {
query: 'your search query',
numResults: 5,
language: 'en'
}
}
});
console.log(response.result);Troubleshooting
Crawler Service Issues
API Unreachable: Ensure that the crawler service is running and accessible at the configured API_URL.
Search Results Not Available: Check the logs of the crawler service to see if there are any errors:
docker-compose logs crawlerFlareSolverr Issues: Some websites use Cloudflare protection. If you see errors related to this, check if FlareSolverr is working:
docker-compose logs flaresolverr
MCP Server Issues
Import Errors: Ensure you have the latest version of the MCP SDK:
npm install -g @modelcontextprotocol/sdk@latestConnection Issues: Make sure the stdio transport is properly configured for your client.
Development
To work on this project:
Clone the repository
Install dependencies:
npm installBuild the project:
npm run buildRun in development mode:
npm run dev
The server expects a WebSearch Crawler API as defined in the included swagger.json file. Make sure the API is running at the configured API_URL.
Project Structure
.gitignore: Specifies files that Git should ignore (node_modules, dist, logs, etc.).npmignore: Specifies files that shouldn't be included when publishing to npmpackage.json: Project metadata and dependenciessrc/: Source TypeScript filesdist/: Compiled JavaScript files (generated when building)
Publishing to npm
To publish this package to npm:
Make sure you have an npm account and are logged in (
npm login)Update the version in package.json (
npm version patch|minor|major)Run
npm publish
The .npmignore file ensures that only the necessary files are included in the published package:
The compiled code in
dist/README.md and LICENSE files
package.json
Contributing
Contributions are welcome! Please feel free to submit a Pull Request.
License
ISC
Available Tools
1 toolweb_searchB
Search the web for information. Use this tool when you need to search the web for information. You can use this tool to search for news, blogs, or all types of information. You can also use this tool to search for information about a specific company or product. You can also use this tool to search for information about a specific person. You can also use this tool to search for information about a specific product. You can also use this tool to search for information about a specific company. You can also use this tool to search for information about a specific event. You can also use this tool to search for information about a specific location. You can also use this tool to search for information about a specific thing. If you request search with 1 result number and failed, retry with bigger results number.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query to look up | |
| numResults | No | Number of results to return (default: 5) | |
| language | No | Language code for search results (e.g., 'en') | |
| region | No | Region code for search results (e.g., 'us') | |
| excludeDomains | No | Domains to exclude from results | |
| includeDomains | No | Only include these domains in results | |
| excludeTerms | No | Terms to exclude from results | |
| resultType | No | Type of results to return |
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 does not mention potential side effects, rate limits, or permissions. The only behavioral detail is the retry advice, which is insufficient for a tool performing external web requests.
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 overly repetitive, listing 'You can also use this tool to search for...' multiple times, which adds no value and wastes tokens. The retry advice is useful but could be condensed. A single sentence covering the core function and filtering options would suffice.
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?
For a tool with 8 parameters and no output schema, the description provides a basic overview but lacks details on pagination, error handling beyond the retry note, and the structure of results. The schema covers parameter details, but the description does not fully fill the gaps for a complex tool.
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?
All 8 parameters have descriptions in the schema, so the schema coverage is 100%. The description adds no additional parameter-specific information beyond what is in the schema, matching the baseline expectation. The retry advice does not relate to parameters.
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 'Search the web for information,' which defines the tool's purpose. However, it lacks specificity and reads as a general search tool rather than highlighting unique capabilities. There are no sibling tools, so no need for differentiation, but the description could be more concise.
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 includes explicit guidance on when to use ('when you need to search the web') and a specific retry strategy for failed requests with small result numbers. No siblings exist, so no alternatives to discuss, but the guidance is clear and actionable.
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. Dates show when Glama detected each change.
1 tool update
v1.0.0- First observed
web_search
TDQS
Only one tool exists, so there is no ambiguity. The single tool's purpose is clearly defined as searching the web.
With only one tool, naming consistency is trivially maintained. The name 'web_search' follows a clear verb_noun pattern.
A single tool for a web search server is minimal but acceptable for basic functionality. However, a more complete server might include tools for fetching page content or image search, making the count borderline.
The server provides only a search tool, missing common complementary tools like fetching web page content or performing advanced searches. This leaves notable gaps for typical workflows.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
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
Scrape, crawl and search the web for AI agents via MCP.
Live AI-native web search with citations. One tool for every MCP client. Flat per-request pricing.
Related MCP Servers
- AlicenseAqualityBmaintenanceA Model Context Protocol server that provides real-time web search capabilities to AI assistants through pluggable search providers, currently integrated with the Brave Search API.516MIT
- FlicenseAqualityCmaintenanceA Model Context Protocol server that provides web search capabilities using Google Custom Search API and webpage content extraction functionality.262-
- FlicenseCqualityDmaintenanceA Model Context Protocol server that enables web search capabilities using the Tavily API, allowing AI models to retrieve current information from the internet through natural language commands.3-
- AlicenseBqualityDmaintenanceA Model Context Protocol server that provides web search capabilities using Google Custom Search API and webpage content extraction functionality.2MIT
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/mnhlt/WebSearch-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server