Zoom Search
Zoom Search
Zoom Search is a search and evidence tool for AI agents. It helps agents rewrite search questions, gather broader web evidence, zoom into high-value source domains, and return sourced answers with metrics.
It is built for agentic applications that need stronger source discovery, traceability, and answer grounding than a single search call.
Why Zoom Search
Agent search tool: expose structured answers, sources, warnings, and metrics for tool-calling agents.
Better evidence gathering: rewrite agent questions into stronger search variants.
Source-domain zoom-in: search broadly first, then focus on high-value domains.
Traceable outputs: preserve source domains, duplicate provenance, warnings, and runtime metrics.
MCP/LangGraph ready: use Zoom Search through MCP or LangGraph integrations.
Provider-flexible: use built-in engines or custom OpenAI-compatible and native HTTP providers.
Related MCP server: MyWebSearch MCP
Install
pip install zoom-searchQuickstart
Run a deterministic local demo without API keys:
import asyncio
from zoom_search import search
async def main() -> None:
response = await search(
question="What hotels in Shenzhen have rooms with exercise bikes?",
demo_mode=True,
output_mode="answer_with_sources",
seed=7,
)
print(response.answer)
print(response.results)
asyncio.run(main())Agent Tool Example
Install the MCP extra:
pip install "zoom-search[mcp]"Add Zoom Search to your MCP client:
{
"mcpServers": {
"zoom-search": {
"command": "zoom-search-mcp",
"env": {
"ZOOM_SEARCH_LLM_ENGINE": "gemini",
"ZOOM_SEARCH_LLM_MODEL": "gemini-2.5-flash",
"ZOOM_SEARCH_LLM_API_KEY": "YOUR_GEMINI_API_KEY",
"ZOOM_SEARCH_SEARCH_ENGINE": "tavily",
"ZOOM_SEARCH_SEARCH_API_KEY": "YOUR_TAVILY_API_KEY"
}
}
}
}Your agent can then call the zoom_search tool with a question argument:
{
"question": "Which vector databases support hybrid search and metadata filtering for Python apps?",
"output_mode": "answer_with_sources"
}The tool returns sourced answers, source-domain zoom-in, warnings, and runtime metrics.
Or wrap it as a LangGraph/LangChain tool:
import os
from langchain.tools import tool
from zoom_search import search
@tool
async def zoom_search_evidence(query: str) -> dict:
response = await search(
question=query,
llm_engine=os.environ["ZOOM_SEARCH_LLM_ENGINE"],
llm_model=os.environ["ZOOM_SEARCH_LLM_MODEL"],
llm_api_key=os.environ["ZOOM_SEARCH_LLM_API_KEY"],
search_engine=os.environ["ZOOM_SEARCH_SEARCH_ENGINE"],
search_api_key=os.environ["ZOOM_SEARCH_SEARCH_API_KEY"],
output_mode="answer_with_sources",
)
return response.to_dict()See docs/agent-integration.md for MCP client configuration and provider environment variables.
Benchmarks
Historical evaluations compare direct search against the Zoom Search agent workflow, showing better useful result coverage and stronger final answers with bounded extra time and token cost.
Case | Good results | Answer quality | Extra time | Extra tokens |
Playwright authentication reuse | 5 -> 7 | 6.6 -> 8.7 | +5.89s | +2,324 |
GitHub Actions secrets inherit | 1 -> 4 | 2.0 -> 7.8 | +8.93s | +2,936 |
Hydrangea pruning comparison | 4 -> 12 | 7.2 -> 8.4 | +12.17s | +5,073 |
See the full benchmark notes in docs/benchmarks.md.
Runnable examples for demo mode, streaming, conversation history, and LangGraph are available in the examples/ directory.
Documentation
Advanced configuration: https://github.com/goofrey/zoom-search/blob/main/docs/advanced-configuration.md
Agent integration: https://github.com/goofrey/zoom-search/blob/main/docs/agent-integration.md
Development checks: https://github.com/goofrey/zoom-search/blob/main/docs/development.md
Benchmarks: https://github.com/goofrey/zoom-search/blob/main/docs/benchmarks.md
License
Zoom Search is open source under the MIT License.
Available Tools
1 toolzoom_searchC
Run Zoom Search and return answer, sources, warnings, metrics, and evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| question | Yes | ||
| demo_mode | No | ||
| output_mode | No | answer_with_sources | |
| zoomin_num_results | No | ||
| zoomout_num_results | No | ||
| previous_conversation | No | ||
| include_raw_diagnostics | No | ||
| top_k_domains_per_query | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description enumerates the types of outputs (answer, sources, warnings, metrics, evidence), which partially reveals behavior. However, no annotations exist, and the description does not disclose side effects, authorization needs, rate limits, or whether the tool is destructive. For a search-like tool, this is acceptable but incomplete.
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 a single sentence, achieving brevity. It front-loads the action and lists outputs. However, it could be more informative without increasing length, e.g., by noting the search technology or providing a hint about required parameters.
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 complexity (9 parameters, 1 required, 0% schema coverage), the description is far from complete. An output schema exists, which helps for return types, but the parameter semantics gap and lack of usage guidance leave the description insufficient for an agent to effectively invoke the 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?
With 0% schema description coverage and 9 parameters, the description offers no explanation of any parameter. It does not mention the required 'question' parameter or optional ones like 'seed', 'output_mode', or numer results. This severely hampers correct invocation.
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 action ('Run Zoom Search') and the outputs (answer, sources, warnings, metrics, evidence). It is specific about the return value composition, which helps the agent understand the purpose. However, without sibling tools, differentiation is not tested, and 'Zoom Search' is not elaborated, so it is not a 5.
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 provides no guidance on when to use this tool, prerequisites, or alternatives. There is no mention of context or exclusionary criteria, leaving the agent with no usage heuristics beyond the name.
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
v0.1.4- First observed
zoom_search
TDQS
Scored across 1 tool
With only one tool, there is no risk of ambiguity; the tool's purpose is entirely distinct by default.
The single tool uses a clear snake_case naming convention, which is consistent by default.
The server has only one tool, which is on the low end of tool count. While it serves a focused purpose, it feels slightly thin for a server that could potentially offer more related operations.
The single tool covers the core search functionality and returns comprehensive results (answer, sources, warnings, metrics, evidence). However, there might be missing features like search configuration or history, but the current scope is reasonable.
Maintenance
Related MCP Connectors
Live AI-native web search with citations. One tool for every MCP client. Flat per-request pricing.
Multi-engine search for AI agents. Trust scoring, local corpus, MCP-native. Self-hostable, BYOK.
Search the agentic web. 4,100+ sites, 11 tools incl. check_url + verify_mcp for probe-before-use.
Web search, fetch, extract, and research for AI agents. Markdown output + AI-synthesized answers.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to perform web searches with full content retrieval and multi-engine provenance, including trust scoring and local corpus persistence, via MCP integration.3 npm2Apache 2.0
- FlicenseNot gradedqualityCmaintenanceEnables AI agents to perform unified web research through a single MCP server, including search, page fetching, recursive crawling, document parsing, YouTube transcript extraction, and deep multi-query research.2-
- AlicenseNot gradedqualityAmaintenanceEnables AI agents to perform live web searches across 9 engines, scrape web pages into clean formats, and run agentic research with citations via MCP.1MIT
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to search the live web and extract readable page content as MCP tools, with ranked results, domain filters, and news support.39 npmMIT