camoufox-research

Overview Schema Source Related Servers Discussions Admin

research

Deep-поиск ОДНИМ вызовом — норматив «10 источников» за один ход. queries — несколько формулировок запроса (агент сам планирует подзапросы, паттерн gpt-researcher); сервер ищет по каждой, дедуплицирует URL и возвращает список со сниппетами.

Instructions

⚠️ ЭТОТ ВЫЗОВ НЕ СЧИТАЕТСЯ В БЮДЖЕТЕ КАМПАНИИ (search_calls): research() — «в воздух» (нет camp_id); для бюджета используй research_start (кампания) — там волны считаются кросстаблично в campaigns.search_calls (budget_review.py / research_status). fetch_top>0 — сразу читает топ-N источников (тексты статей).

Режим «20+ источников, не топы» (реальный ресёрч):

target_domains=N — цель по РАЗНЫМ доменам (20 = двадцать разных сайтов). Пока не набрали — доборка волнами: базовые запросы, потом follow-up из термов сниппетов, потом пагинация.
domains_limit=K — не больше K источников с одного домена.
expand=True — к каждому запросу переформулировки («X comparison», «X documentation») — свежие домены и углы.
terms_wave=True — вторая волна из РЕДКИХ ТЕРМОВ первой волны (имена, названия из сниппетов) — паттерн Open Deep Research.
quality_first=True — отбор по качеству домена: доки/GitHub/arXiv первыми, форумы вниз (паттерн gpt-researcher source ranking).
fetch_all=True — тексты ВСЕХ отобранных, а не топ-N.
as_json=True — машинный JSON: meta (счётчики, follow-up запросы), sources (title/url/domain/tier/tier_label/snippet), texts, notes. Идеален для автоматизации и синтеза агентом.
academic=True — вертикальный АКАДЕМИЧЕСКИЙ канал: arXiv + Semantic Scholar (бесплатные API, без ключей) — первоисточники (tier 0), которых DDG почти не видит (паттерн Exa vertical index).
llm_planner=True — LLM (DeepSeek/Ollama) генерирует 10 follow-up запросов как в gpt-researcher/STORM (Layer B, опционально, требует DEEPSEEK_API_KEY или OLLAMA_HOST, иначе пропуск). Пример глубокого ресёрча: research(queries=["deep research agents"], target_domains=20, domains_limit=2, expand=True, terms_wave=True, quality_first=True, academic=True, llm_planner=True, fetch_all=True, as_json=True, max_results_per_query=6) Результат кэшируется на сутки. КОГДА: «собери 10-20+ источников» ОДНИМ вызовом, результат нужен сейчас (без кампании). НЕ КОГДА: нужен прогресс/статус и бюджет search_calls → research_start (кампания в sqlite); нужен только топ-5 → web_search.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`expand`	No
`as_json`	No
`queries`	Yes
`academic`	No
`fetch_all`	No
`fetch_top`	No
`max_chars`	No
`terms_wave`	No
`llm_planner`	No
`article_only`	No
`max_parallel`	No
`domains_limit`	No
`quality_first`	No
`target_domains`	No
`max_results_per_query`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.18.1Aug 28, 2026

addedInput schema / properties / academic

Added value: +{
+  "default": false,
+  "title": "Academic",
+  "type": "boolean"
+}

addedInput schema / properties / as_json

Added value: +{
+  "default": false,
+  "title": "As Json",
+  "type": "boolean"
+}

addedInput schema / properties / domains_limit

Added value: +{
+  "default": 0,
+  "title": "Domains Limit",
+  "type": "integer"
+}

addedInput schema / properties / expand

Added value: +{
+  "default": false,
+  "title": "Expand",
+  "type": "boolean"
+}

addedInput schema / properties / fetch_all

Added value: +{
+  "default": false,
+  "title": "Fetch All",
+  "type": "boolean"
+}

addedInput schema / properties / llm_planner

Added value: +{
+  "default": false,
+  "title": "Llm Planner",
+  "type": "boolean"
+}

addedInput schema / properties / quality_first

Added value: +{
+  "default": false,
+  "title": "Quality First",
+  "type": "boolean"
+}

addedInput schema / properties / target_domains

Added value: +{
+  "default": 0,
+  "title": "Target Domains",
+  "type": "integer"
+}

addedInput schema / properties / terms_wave

Added value: +{
+  "default": false,
+  "title": "Terms Wave",
+  "type": "boolean"
+}

First observedv0.1.0Aug 20, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it discloses that the server searches per query, deduplicates URLs, returns snippets, caches results for a day, optionally fetches article texts, and can require DEEPSEEK_API_KEY or OLLAMA_HOST for llm_planner. It also clarifies budget-counting behavior, which goes beyond what the schema could convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured: an intro, a warning, a bulleted parameter breakdown, a concrete example, and when/not-when guidance. Every section earns its place for a 15-parameter tool, though some internal references like 'budget_review.py / research_status' and repeated 'gpt-researcher' pattern mentions add slight redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is nearly complete for a complex tool: it covers usage scenarios, alternatives, caching, authentication requirements, an example call, and the shape of as_json output. It falls short only by omitting the semantics of max_chars, article_only, and max_parallel, so an agent would have to infer their meaning from names alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate. It explains most parameters in detail: queries, target_domains, domains_limit, expand, terms_wave, quality_first, fetch_all, as_json, academic, llm_planner, fetch_top, and max_results_per_query via the example. However, max_chars, article_only, and max_parallel are not explained, leaving a small but real semantic gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Deep-поиск ОДНИМ вызовом — норматив «10 источников» за один ход', making clear this is a deep search that returns deduplicated sources with snippets. It further differentiates from siblings by explicitly stating when research() is not appropriate and pointing to web_search and research_start as alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides an explicit КОГДА / НЕ КОГДА section, naming concrete alternatives: use research_start when campaign budget/status tracking is needed, and web_search when only a top-5 result is required. It also warns that this call does not count toward campaign search_calls budget, which is essential for correct tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server