Provides comprehensive web search capabilities by querying Google via Serper API, with full content extraction using Mozilla Readability.
Provides news article search capabilities by querying Google News via Serper API, optimized for recent articles with content extraction.
Click on "Deploy 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., "@deep-search-mcp deep search for React server components"
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.
An MCP (Model Context Protocol) server that performs comprehensive web searches by combining Google search with advanced content extraction using Mozilla's Readability algorithm.
Advanced Content Extraction - Uses Mozilla's Readability algorithm (same as Firefox Reader View) for clean article extraction
Multiple Search Types - Web search, news search, and image search
Domain Filtering - Include or exclude specific domains from results
Retry Logic - Automatic retries with exponential backoff for reliability
Controlled Concurrency - Fetches pages in batches to avoid overwhelming servers
Full Content - Returns complete page content, not just snippets
Related MCP server: Web Search MCP Tool
This MCP server uses Serper.dev for Google search results.
Go to https://serper.dev
Sign up for a free account (2,500 free searches)
Copy your API key from the dashboard
No installation needed - just configure your MCP client:
{
"mcpServers": {
"deep-search": {
"command": "npx",
"args": ["-y", "@thejusdutt/deep-search-mcp"],
"env": {
"SERPER_API_KEY": "your-serper-api-key-here"
}
}
}
}npm install -g @thejusdutt/deep-search-mcpThen configure:
{
"mcpServers": {
"deep-search": {
"command": "deep-search-mcp",
"env": {
"SERPER_API_KEY": "your-serper-api-key-here"
}
}
}
}deep_searchComprehensive web search with full content extraction.
Parameters:
Parameter | Type | Default | Description |
| string | required | The search query |
| number | 10 | Number of results (1-10) |
| number | 50000 | Max characters per page (5000-100000) |
| string | "web" | Search type: "web", "news", or "images" |
| string | - | Comma-separated domains to include |
| string | - | Comma-separated domains to exclude |
Examples:
// Basic web search
deep_search({ query: "React best practices 2025" })
// News search
deep_search({ query: "AI announcements", search_type: "news" })
// Image search - returns image URLs and source pages
deep_search({ query: "cute cats", search_type: "images" })
// Search specific sites only
deep_search({
query: "TypeScript tips",
include_domains: "github.com,dev.to"
})
// Exclude certain sites
deep_search({
query: "web development trends",
exclude_domains: "pinterest.com,facebook.com"
})deep_search_newsOptimized for news article search.
Parameters:
Parameter | Type | Default | Description |
| string | required | The news topic to search |
| number | 10 | Number of articles (1-10) |
| number | 30000 | Max characters per article |
Example:
deep_search_news({ query: "OpenAI latest updates" })Add to ~/.kiro/settings/mcp.json or claude_desktop_config.json:
{
"mcpServers": {
"deep-search": {
"command": "npx",
"args": ["-y", "deep-search-mcp"],
"env": {
"SERPER_API_KEY": "your-api-key"
}
}
}
}Add to your Continue config:
{
"mcpServers": [
{
"name": "deep-search",
"command": "npx",
"args": ["-y", "deep-search-mcp"],
"env": {
"SERPER_API_KEY": "your-api-key"
}
}
]
}Standard Google search with full page content extraction using Mozilla Readability.
Searches Google News for recent articles. Use search_type: "news" or the dedicated deep_search_news tool.
Searches Google Images and returns:
title - Image title/description
link - Source page URL where the image is hosted
snippet - Direct image URL
Note: Image search returns metadata and URLs only - it does not download or display actual images.
Search - Queries Google via Serper API to get top results
Fetch - Downloads each result page with retry logic (web/news only)
Extract - Uses Mozilla Readability to extract clean article content
Format - Returns consolidated markdown with full content from each page
Node.js 18+
Serper API key (get one free)
MIT
Issues and PRs welcome at GitHub
Performs a comprehensive web search by querying Google, fetching the FULL content from top results using advanced content extraction (Readability algorithm), and returning consolidated content. Supports web, news, and image search types. Includes retry logic for reliability.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query to look up | |
| num_results | No | Number of results to fetch (1-10, default: 10) | |
| search_type | No | Type of search: 'web' for general search, 'news' for news articles, 'images' for image search | web |
| exclude_domains | No | Comma-separated list of domains to exclude (e.g., 'pinterest.com,facebook.com') | |
| include_domains | No | Comma-separated list of domains to include (e.g., 'reddit.com,github.com') | |
| max_content_per_page | No | Maximum characters of content to return per page (5000-100000, default: 50000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose meaningful mechanics: Google querying, full-page content extraction via the Readability algorithm, consolidation of results, and retry logic. What is missing is the operational envelope for a network-bound search tool - rate limits, latency expectations, failure/empty-result behavior, and whether content is truncated or cached.
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?
Three sentences, front-loaded with the core action, then supported capabilities, then a reliability note. Nothing is redundant, though the trailing 'Includes retry logic for reliability' is the weakest sentence and could be folded into the behavioral detail rather than standing alone.
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?
With no annotations and no output schema, the description must carry the load, and it partially does by describing the consolidated-content return. However, for a six-parameter search tool with a sibling that overlaps, it lacks any statement of how results are shaped (per-result structure, truncation at max_content_per_page) and gives no basis for preferring it over deep_search_news.
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 every parameter including query, num_results, search_type, domain filters, and max_content_per_page is already fully documented in the schema. The description adds only the high-level mention of web/news/image search types, which does not extend beyond the enum already documented. Baseline 3 applies.
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 names a specific verb and resource (web search) and details the mechanism: querying Google, fetching full content from top results via Readability, and returning consolidated content. It also enumerates the supported search types. However, it never distinguishes itself from the sibling deep_search_news, even though it claims to handle news search itself, which muddies selection.
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?
There is no explicit guidance on when to choose this tool versus the sibling deep_search_news, despite the obvious overlap since this tool also supports a 'news' search type. The only hint is the enumeration of search types, which implies context but stops short of routing the agent. No exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches for recent news articles on a topic, fetches full article content, and returns consolidated results. Optimized for news and current events.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The news topic to search for | |
| num_results | No | Number of news articles to fetch (1-10, default: 10) | |
| max_content_per_page | No | Maximum characters per article (default: 30000) |
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 disclose the multi-step pipeline (search, fetch full article content, consolidate), which is genuinely useful. However it says nothing about permissions, rate limits, failure modes when articles can't be fetched, or how truncation via max_content_per_page affects output.
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?
Two tight sentences; the core action and the consolidating behavior come first, with the news-focus qualifier at the end. Nothing is redundant, though there is no explicit output-format note.
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 3-parameter tool with no annotations and no output schema, the description covers the essential workflow but leaves gaps: it doesn't characterize the return structure ('consolidated results' is vague) or the trade-off implied by max_content_per_page truncation.
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 all three parameters (query, num_results, max_content_per_page) already have descriptions with defaults and ranges. The description adds no parameter-level detail beyond the schema, so the baseline of 3 applies.
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?
States a specific verb and resource (searches news articles) plus the multi-step behavior (fetches full content, returns consolidated results). The 'Optimized for news and current events' clause implicitly differentiates it from the sibling deep_search, though it never names that sibling directly.
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?
'Optimized for news and current events' gives an implied usage domain, but there is no explicit when-to-use/ when-not guidance and no reference to the sibling deep_search, which is the obvious alternative for non-news queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.0.3deep_searchdeep_search_newsScored across 2 tools
deep_search and deep_search_news overlap because deep_search explicitly supports news search types, so an agent may be unsure when to use the specialized news tool versus the general one. The descriptions help clarify that one is optimized for news, but the functional boundary remains fuzzy.
Both tools use consistent snake_case and share the deep_search prefix, making the set predictable and readable. It is not a strict verb_noun pattern, but the convention is internally consistent.
Only two tools are provided for a search server, and one is largely a specialization of the other, so the set feels thin and partially redundant. A slightly broader surface, such as separate image or filtered search tools, would better match the apparent scope.
General web and news search are covered, but image search is only a mode inside deep_search and there are no distinct tools for other common search needs or filters. The specialized news tool duplicates functionality already present in deep_search.
Search the web and extract clean, readable text from webpages. Process multiple URLs at once to sp…
Web search, fetch, extract, and research for AI agents. Markdown output + AI-synthesized answers.
Web research for agents: quality-scored Google search, webpage extraction, and deep research.
Web search, URL content extraction to Markdown, site mapping, and recursive web crawler.
