The SERPdive MCP server lets you perform real-time web searches and retrieve clean, LLM-ready page content (not just links) from the live web.
Search the live web in any language with automatic localization, returning structured results with url, title, date, and content fields ready for citation
Get current information beyond LLM training cutoffs: news, prices, software releases, documentation, sports scores, niche facts, and more
Choose search depth via three models:
krill — free and unlimited under fair use; shortest useful answer (~700 tokens, low priority)
mako (default) — fast and concise, returning the key fact-carrying sentences from each page (1 credit per search)
moby — full page text for deep research or long-document analysis; slower and more token-intensive (1.5 credits per search)
Control result count via the optional max_results parameter (1–10), or let the engine decide
Receive structured JSON responses including query, model used, response time, and an array of results — suitable for direct LLM consumption and fact-quoting
Give any MCP client real-time web search with answer-ready results. SERPdive is the AI Search API: ask a question, get the actual content of the best pages, extracted, cleaned, and sized for an LLM. On a public, replayable 1,000-question benchmark, SERPdive runs at the same speed as Tavily, feeds your LLM 20.2% fewer tokens, and wins 60.7% of decided quality duels. If you are evaluating Tavily alternatives, that benchmark is public and replayable end to end: same questions, same judge, your machine.
There is a free tier, and it has no ceiling. The krill model is free and unlimited under fair use — no card, no credits, nothing to decrement. It returns the shortest set of sentences that still answers (about 700 tokens a search, roughly half what the usual alternatives send), one request at a time, at low priority. Use it to build; switch one word to mako when you need depth and steady latency.
One tool, serpdive_search. Two ways to run it:
Hosted (recommended): https://mcp.serpdive.com, nothing to install.
Local (this package): npx -y serpdive-mcp, stdio, zero dependencies.
Get a free API key at serpdive.com/dashboard/keys (no card required).
claude mcp add --transport http serpdive https://mcp.serpdive.com \
--header "Authorization: Bearer sd_live_YOUR_KEY"{
"mcpServers": {
"serpdive": {
"url": "https://mcp.serpdive.com/?key=sd_live_YOUR_KEY"
}
}
}Both https://mcp.serpdive.com/ and https://mcp.serpdive.com/mcp answer, so either URL shape works.
Related MCP server: firecrawl-mcp-server
Add to claude_desktop_config.json (Settings > Developer > Edit Config):
{
"mcpServers": {
"serpdive": {
"command": "npx",
"args": ["-y", "serpdive-mcp"],
"env": { "SERPDIVE_API_KEY": "sd_live_YOUR_KEY" }
}
}
}claude mcp add serpdive --env SERPDIVE_API_KEY=sd_live_YOUR_KEY -- npx -y serpdive-mcp{
"mcpServers": {
"serpdive": {
"command": "npx",
"args": ["-y", "serpdive-mcp"],
"env": { "SERPDIVE_API_KEY": "sd_live_YOUR_KEY" }
}
}
}serpdive_search(query, model?, max_results?)
Argument | Type | Description |
| string, required | The search, in any language. Localization is automatic. |
|
|
|
| integer, 1-10 | Cap on delivered results. Omit for the engine's calibrated mix. |
The response is the raw SERPdive JSON: query, model, response_time_ms, optional extra_info, and results as [{ url, title, date?, content }]. Failed searches are never billed.
There is no answer argument here, on purpose. Over MCP the consumer is always an
LLM, which can write its own answer from the extracted content — a second,
server-side synthesis costs a round-trip on every search and buys nothing. The
API still offers answer: true for callers that are
not models.
A mako search costs 1 credit, moby 1.5. Every account gets free monthly credits, no card required. Full reference: serpdive.com/docs.
MIT
Search the live web and get back answer-ready page content, not a list of links. Each result carries the actual text of the page (url, title, date, content), already extracted, cleaned and trimmed for LLM use, so facts can be quoted and cited straight from the response. Use it for anything that needs current or post-training information: news, prices, releases, docs, sports, niche facts. Write the query the way a person would type it, in any language: localization is automatic. The 'mako' model (default) returns the fact-carrying sentences of each page, fast and concise, right for most questions. The 'krill' model is free and unlimited under fair use: the shortest useful answer set (~700 tokens, fewer sources, no written answer), served at low priority — right when token budget matters more than depth. The 'moby' model returns full page text: slower (~1s more) and several times more tokens, so use it only when mako's key sentences are insufficient (long-document analysis, deep research).
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | 'mako' (default): the key sentences of each page, concise and fast. 'krill': free and unlimited under fair use — the shortest useful set (~700 tokens, fewer sources, no written answer), at low priority. 'moby': full page text — slower (~1s more) and returns several times more tokens; use only when mako's key sentences are insufficient (long-document analysis, deep research). | |
| query | Yes | The search query, in any language, phrased like a real web search. | |
| max_results | No | Maximum number of results to return (1 to 10). Omit to let the engine pick its calibrated mix. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation readOnlyHint and openWorldHint are complemented by detailed behavioral disclosure: returns cleaned text, model trade-offs (speed, token count, free tier), and automatic localization. No contradictions.
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?
Front-loaded with core value, then use cases, then model details. Each sentence earns its place; slightly verbose but well-structured.
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?
Despite no output schema, description specifies result fields (url, title, date, content) and model token ranges. Covers query phrasing, model selection, and use cases comprehensively for a search 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?
Schema covers 100% of parameters with descriptions. Description adds context on query phrasing ('write as a person would') and max_results omission behavior, enhancing understanding beyond schema.
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 it searches the live web and returns page content (not just links), specifying the unique value of cleaned, LLM-ready text. It distinguishes from typical search tools.
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?
Provides explicit use cases (current info, news, prices, releases, docs, sports, niche facts) and model selection guidance. Lacks 'when not to use' but no siblings make it less necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Only one tool exists, so there is no ambiguity with other tools. The tool has a clear, distinct purpose.
With a single tool, naming consistency is inherently perfect. The name follows a verb_noun pattern (serpdive_search) with a prefix, which is clear and descriptive.
The single tool provides a focused search function, but the tool count is on the low end. For a dedicated search server, one tool can be sufficient, though additional tools for configuration or specialized searches could enhance the set.
The tool covers the core search functionality with two models (mako and moby) for different needs. Minor gaps might include pagination or filtering options, but the tool is well-suited for its stated purpose of retrieving page content for LLM use.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Live AI-native web search with citations. One tool for every MCP client. Flat per-request pricing.
Docs: https://docs.keenable.ai/mcp-server Keenable is a free, remote MCP server that gives agents access to the web index. Search the web with ranked results and date/site filters, then fetch any indexed page as clean markdown. Works out of the box with no account or API key.
Serper MCP — wraps the Serper Google Search API (serper.dev)
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/serpdive/serpdive-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server