Gigaxity Deep Research is a multi-source deep research MCP server that combines web search, RRF fusion, and LLM synthesis into a suite of tools for AI agents and REST clients.
search: Raw multi-source search (SearXNG, Tavily, LinkUp) with Reciprocal Rank Fusion, no LLM involved.
research: Full pipeline: search → LLM synthesis with citations; supports reasoning effort levels.
ask: Direct conversational answers from the LLM’s knowledge, skipping web search.
discover: Exploratory topic expansion that surfaces explicit, implicit, related, and contrasting angles, identifies knowledge gaps, and supports focus modes (general, academic, documentation, comparison, debugging, tutorial, news).
synthesize: Citation-aware synthesis of pre-gathered sources with a CRAG-style quality gate, contradiction detection, outline-guided generation, presets (comprehensive, fast, contracrow, academic, tutorial), and style overrides.
reason: Chain-of-thought reasoning; operates with or without sources, with adjustable depth (shallow/moderate/deep) for no-sources mode.
Additional capabilities:
Per-request API key override for multi-tenant billing.
Dual deployment as an MCP stdio server (for Claude Code, Cursor, etc.) or a FastAPI REST API.
Compatible with any OpenAI-compatible model (Qwen3, DeepSeek-R1, Llama 3.x, etc.).
Optional routing classifier for intelligent tool selection.
Supports any OpenAI-compatible chat-completions model as the synthesis engine, including OpenAI's own models, for generating citation-backed answers.
Adds Reddit as a social-first source via the gptr-mcp companion, allowing research queries to include Reddit content.
Integrates SearXNG as a primary metasearch source for multi-source search aggregation, enabling queries across multiple search engines.
Adds YouTube as a social-first source via the gptr-mcp companion, allowing research queries to include YouTube content.
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., "@gigaxity-deep-research Research the latest advancements in renewable energy storage and provide a summary with citations."
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.
Open-source deep research MCP server for Claude Code, Hermes, Cursor, and any MCP-compatible agent. Qwen3-30B-A3B-Thinking via OpenRouter plus multi-source web synthesis with citations.
Gigaxity Deep Research is a multi-source synthesis pipeline — six MCP tools (two primitives search/research plus four deep-research tools ask/discover/synthesize/reason) with a matching FastAPI REST surface, fronting parallel multi-source search, RRF fusion, citation binding, and contradiction detection. The synthesis stage runs against any OpenAI-compatible chat-completions model; the recommended default is Alibaba's Qwen3-30B-A3B-Thinking, a reasoning-tuned 30B-A3B MoE model, but DeepSeek-R1, Qwen-QwQ, Llama 3.x, and hosted-aggregator endpoints (OpenRouter and the like) all work — pick any model your endpoint serves. The search layer pulls from a "Triple Stack" of complementary MCPs (Context7, Exa, Jina) alongside SearXNG, Tavily, and LinkUp connectors. A bundled gptr-mcp companion — the MCP shim around GPT Researcher — adds Reddit, X, and YouTube as social-first sources.
If you want to run the synthesis model on your own hardware, the local-inference branch swaps OpenRouter for any OpenAI-compatible endpoint (vLLM, SGLang, or llama.cpp). The search-MCP layer is priced separately by each provider. See docs/guides/free-tier-strategy.md for what their free tiers cover and how to wire them up.
Python on FastAPI. MIT License. Runs as an MCP stdio server, FastAPI REST API, or both. Drop-in instructions for the full deep research stack live in CLAUDE.md / AGENTS.md (byte-identical) so any MCP-capable harness — Claude Code, Codex, Cursor, Hermes, etc. — or a standalone agent (system-prompt path) can mirror the configuration.
Gigaxity Deep Research wires a multi-source search layer (SearXNG, Tavily, LinkUp) to an RRF fusion stage and a synthesis engine with citation binding, then exposes the whole pipeline as six MCP tools — two primitives (search, research) plus four deep-research tools (ask, discover, synthesize, reason) — that Claude Code or any MCP-compatible agent can call. The synthesis stage runs against any OpenAI-compatible chat-completions model; the recommended default is Qwen3-30B-A3B-Thinking, a reasoning-tuned MoE model from Alibaba.
So when an agent hits a question outside its training cutoff, it doesn't hallucinate or shell out to a generic search tool. It calls discover to widen the source set, reads the top hits, and calls synthesize to fold the evidence into a citation-backed answer. Round-trip is typically 5–15 seconds against a hosted reasoning model.
Related MCP server: myscrape
The MCP server exposes two primitives plus four deep-research tools — six tools total. The primitives give you raw search and the simple combined pipeline; the deep-research tools split discovery, synthesis, and reasoning so each step can be driven independently.
Primitives
Tool | Purpose |
| Raw multi-source aggregation across SearXNG, Tavily, and LinkUp with RRF fusion. No LLM call. |
| Combined pipeline: multi-source search plus LLM synthesis with citations, in one call. |
Deep-research tools
Tool | Purpose |
| Exploratory expansion — surfaces explicit, implicit, related, and contrasting angles, then flags knowledge gaps |
| Citation-aware synthesis over pre-gathered content; CRAG-style quality gate, contradiction surfacing, outline-guided generation |
| Deep synthesis with optional CoT depth control over pre-gathered content |
| Fast conversational answer (direct LLM call, no search hop) |
Multi-source search: parallel queries across SearXNG, Tavily, and LinkUp with graceful degradation if any source is unavailable.
RRF fusion: Reciprocal Rank Fusion combines and re-ranks results across providers.
Adaptive routing: query classification picks the right combination of connectors per query.
Query expansion: HyDE-style variant generation for broader coverage.
Query decomposition: multi-aspect breakdown for complex queries.
Quality gate: CRAG-style filtering keeps low-quality sources out of synthesis, or fails open with a low-relevance caveat when only weak sources are available (rather than refusing).
Contradiction detection: PaperQA2-style disagreement surfacing flags conflicting claims rather than averaging them out.
Citation binding: VeriCite-style claim-to-evidence mapping in the final answer.
Outline-guided synthesis: SciRAG-style structured generation for tutorial and academic presets.
Output verification: post-synthesis hard-gate on empty, truncated, reasoning-only, or uncited synthesis output — failed outputs are flagged with a verdict header and not cached, rather than being relayed as clean successes. Soft conditions (partial citation coverage, surfaced contradictions) append an advisory note.
Focus modes: general, academic, documentation, comparison, debugging, tutorial, news.
Reasoning models: works with Qwen3-Thinking, DeepSeek-R1, Qwen-QwQ, and any other OpenAI-compatible chat-completions model.
Multi-tenant: accepts a per-request X-OpenRouter-Api-Key header so multiple users can share one server instance and bill their own OpenRouter accounts.
MCP and REST: the same orchestration logic powers both surfaces.
The Quick Starts below cover the orchestrator MCP — one of seven in the full stack. The complete deep research workflow (automatic per-query routing across the whole stack) comprises four parts:
Seven MCPs. This repo's orchestrator (gigaxity-deep-research) plus the Triple Stack (context7 + exa + jina — search/docs/code trio) plus three more (exa-answer, brightdata_fallback, gptr-mcp).
Companion projects and dependencies. SearXNG (primary search source, bundled at companions/searxng/) and GPT Researcher (transitive dependency of gptr-mcp); plus the minimal MCP wrappers bundled at companions/exa-answer/ and companions/brightdata-fallback/.
The pasteable instruction block in CLAUDE.md — drop into the global CLAUDE.md / AGENTS.md your harness loads (e.g. ~/.claude/CLAUDE.md for Claude Code), or paste into a standalone agent's system prompt. The agent then fires the research workflow on external-knowledge queries and routes each query class to the right MCP.
The bundled research-workflow skill — the deep reference for the routing classifier (token costs per tool, presets, fallback chains).
Walk the Setup roadmap below for a stage-by-stage path through all four.
The example below registers the server with Claude Code via ~/.claude.json. The same MCP stdio config block works for any MCP-capable harness (Codex, Cursor, Hermes, Continue.dev, etc.) — substitute that harness's config file path. For standalone agents that don't have an MCP harness, run the REST API instead (see the next quick start).
# Clone and install
git clone https://github.com/yoloshii/gigaxity-deep-research.git
cd gigaxity-deep-research
python -m venv .venv
source .venv/bin/activate
pip install -e .
# Configure
cp .env.example .env
# Edit .env: set RESEARCH_LLM_API_KEY (https://openrouter.ai/keys)
# and RESEARCH_SEARXNG_HOST (or leave default)Add to ~/.claude.json under mcpServers:
"gigaxity-deep-research": {
"type": "stdio",
"command": "/path/to/gigaxity-deep-research/.venv/bin/python",
"args": ["/path/to/gigaxity-deep-research/run_mcp.py"],
"env": {
"RESEARCH_LLM_API_BASE": "https://openrouter.ai/api/v1",
"RESEARCH_LLM_API_KEY": "YOUR_OPENROUTER_API_KEY",
"RESEARCH_LLM_MODEL": "qwen/qwen3-30b-a3b-thinking-2507"
}
}Restart Claude Code. The six tools (search, research, ask, discover, synthesize, reason) become callable as mcp__gigaxity-deep-research__<tool>.
The MCP alone gives you raw access to the six tools. Most of the deep research value — automatic per-query tool routing across the full seven-MCP stack, the social-first layer via gptr-mcp, the routing skill, and the global agent-instruction block — comes from the rest of the staircase. Walk it in Setup roadmap below.
When the model lives on a different machine from the orchestrator (e.g. you self-host the model on a GPU box and want the rest of the pipeline on a CPU-only edge node), run it as a REST API.
docker compose up -d
curl http://localhost:8000/api/v1/healthREST endpoints:
Endpoint | Method | Purpose |
| GET | Health check, lists active connectors |
| GET | Liveness probes per connector ( |
| POST | Exploratory expansion |
| POST | Citation-aware synthesis |
| POST | Chain-of-thought reasoning |
| POST | Quick answer |
| POST | Combined search + synthesis |
| POST | Multi-source search only (no LLM) |
| GET | List synthesis presets |
| GET | List focus modes |
Each endpoint accepts an optional X-OpenRouter-Api-Key header that overrides the env-configured key for that request. Multi-tenant deployments use it to bill each user separately.
Full REST reference: docs/reference/rest-api.md.
The Quick Starts above get the orchestrator MCP running against a model and a search source. The full deep research workflow — automatic tool routing across the seven-MCP stack, social-first research via gptr-mcp, the routing skill that classifies queries, plus the agent-instruction block that wires it all into Claude Code — needs the rest of the staircase below.
Each stage has a verify step, so you can stop at any point and know the layer below is solid. Stages 1–4 give you a working orchestrator. Stages 5–7 turn it into the full deep research stack.
# | Stage | What you do | Verify | Time | Doc |
1 | Core install | Clone repo, create venv, |
| 2 min | |
2 | Primary search source | Stand up SearXNG (bundled compose file under |
| 5 min | |
3 | LLM endpoint | Start a local model (vLLM / SGLang / llama.cpp) or point env vars at a hosted endpoint such as OpenRouter |
| 5–30 min | |
4 | Wire gigaxity into Claude Code |
|
| 5 min | |
5 | Companion MCPs (Triple Stack) | Install the bundled companions ( |
| 10–15 min | |
6 | Routing skill + agent instructions | Symlink | A research query triggers the | 3 min | |
7 | Full-stack smoke | Run one query of each routing class and confirm the right MCP fires | See the smoke matrix below | 5 min | (below) |
Run each query in Claude Code (or the agent of your choice) after Stage 7 and confirm the routing matches:
Query | Should route to | What you should see |
"What's the latest stable version of Bun?" |
| 1–2 s factual answer with citations |
"What does the OpenAI Python SDK's |
| Library/API documentation chunks |
"Show me a code example using |
| Curated code-context snippets |
"Find recent papers on corrective RAG" |
| arXiv hits — and the agent should translate the question into arXiv field syntax ( |
"Compare FastAPI vs Litestar for production APIs in 2026" |
| Citation-backed comparative synthesis |
"What do people on Reddit say about Bun vs Node for production?" |
| Reddit / X / YouTube community sentiment |
If a query routes somewhere unexpected, the most common cause is the global instruction block from Stage 6 not being pasted into your global CLAUDE.md / AGENTS.md. Without it, the agent has to discover the routing logic on its own per session.
Stage 2 is required, not optional. SearXNG is the only required search connector — Tavily and LinkUp are optional additional connectors that run in parallel and contribute to RRF fusion. Skipping SearXNG leaves the synthesis layer with nothing to fuse unless you configure Tavily or LinkUp as a substitute.
Verify Stage 4 before adding companions. A failing research call after Stage 5 is hard to debug because the failure could be any of seven MCPs misfiring; confirm the orchestrator alone works first.
Stage 6 is what makes the agent route automatically. Without the skill plus the instruction block, the seven MCPs are visible but the agent treats them as raw tools, not a stack.
local-inference branch defaults to http://localhost:8000/v1; main defaults to OpenRouter. Stage 3's verify command is the same either way, but the env var values differ — match them to your branch.
Mode | Branch | LLM backend | When to use |
OpenRouter (default) |
| Hosted Qwen3-30B-A3B-Thinking via OpenRouter | Single-machine setup, no GPU, fastest path to working |
Local inference (env-override today; code-level swap pending — see Roadmap) |
| Self-hosted Qwen3/DeepSeek/Llama via vLLM, SGLang, or any OpenAI-compatible server | On-prem requirement, GPU available, no usage-based cost. Works on either branch today by setting |
REST API (any backend) | both | Either, plus optional remote model server | Distributed compute — orchestrator and model on different machines |
The local-inference branch currently mirrors main and serves as a placeholder for the planned client-and-default swap. Once the swap lands, that branch will ship with RESEARCH_LLM_API_BASE defaulted to http://localhost:8000/v1 and the OpenRouter client replaced by a generic OpenAI-compatible client. Until then, point RESEARCH_LLM_API_BASE at your local endpoint on either branch — search, fusion, synthesis, and citations behave identically.
┌────────────────────── Gigaxity Deep Research ──────────────────────┐
│ │
│ MCP stdio (run_mcp.py) ──┐ ┌── REST (FastAPI) │
│ ▼ ▼ │
│ ┌─────────────────────────┐ │
│ │ Discovery layer │ │
│ │ routing · expansion · │ │
│ │ decomposition · focus │ │
│ │ (invokes LLM) │ │
│ └────────────┬────────────┘ │
│ ▼ │
│ ┌──────── Search aggregator (parallel, fail-graceful) ─────────┐ │
│ │ SearXNG · Tavily · LinkUp │ │
│ │ ↓ rank-merged across connectors ↓ │ │
│ │ RRF fusion │ │
│ └─────────────────────────┬────────────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────┐ │
│ │ Synthesis layer │ │
│ │ CRAG quality gate · │ │
│ │ contradiction detector ·│ │
│ │ outline guide · RCS │ │
│ │ (invokes LLM) │ │
│ └────────────┬────────────┘ │
│ ▼ │
│ Citation-bound markdown answer │
│ (+ contradictions, outline when preset enables) │
│ │
│ Shared dependency: OpenAI-compatible LLM │
│ (OpenRouter or local; Qwen3 30B et al.) │
└────────────────────────────────────────────────────────────────────┘Different tools enter the pipeline at different stages: research() runs the whole flow; discover() stops after the search aggregator (returns ranked sources + gaps); synthesize() and reason() skip Discovery and Search and operate on pre-gathered sources; ask() calls the LLM directly with no search hop; search() returns RRF-fused results without touching the LLM.
Gigaxity Deep Research is the synthesis MCP in a seven-MCP deep research stack — agent-framework-agnostic, designed to drop into any MCP-capable harness (Claude Code, Codex, Cursor, Hermes, etc.) or a standalone agent that takes a system prompt. The other six MCPs handle search, URL reading, and social discovery:
MCP | Role |
Context7 | Library and API documentation lookup |
Exa | Code-context search, advanced web search, crawling |
Exa Answer | Speed-critical factual lookups (1–2 s) |
Jina (bundled — self-hosted) | Free-tier web search, URL reading, arXiv/SSRN/BibTeX, rerank, dedup, PDF layout |
gigaxity-deep-research (this repo) | Multi-source search + synthesis with Qwen3-30B-A3B-Thinking |
Brightdata fallback | Last-resort scraper for blocked URLs (CAPTCHA, paywall, Cloudflare) |
gptr-mcp | Social-first research — community knowledge from Reddit, X/Twitter, YouTube |
The bundled research-workflow skill plus the instruction block in CLAUDE.md wire all seven together with a query classifier (quick factual, direct, exploratory, synthesis, social-first), so the agent picks the right tools per query class on its own. Drop the instruction block into your own global CLAUDE.md or AGENTS.md to mirror the setup. All seven sanitized MCP server configs live in docs/reference/mcp-configs.md for one-stop copy-paste.
Introduction: what this is, why it exists, where it fits
Quickstart: five-minute MCP install
Concepts: architecture: how the pipeline works
Concepts: presets: fast, tutorial, academic, comprehensive, contracrow
Concepts: fallback chains: how Brightdata, Jina, and the rest chain on URL/search/synthesis failures
Guide: MCP setup (Claude Code walkthrough — same MCP block adapts to any MCP-capable harness)
Guide: Bundled companions setup (SearXNG, Exa Answer, Jina, Brightdata)
Guide: Free-tier strategy: configuring the search MCPs against each provider's free tier
Reference: MCP tools: input/output reference for the six stdio MCP tools this server exposes
Reference: MCP configs: sanitized JSON blocks for all seven MCPs in the stack, in one place
Reference: Configuration: RESEARCH_* env vars for this server
The pipeline implements techniques from the recent literature:
Feature | Research basis |
Quality gate | CRAG (arXiv:2401.15884) |
Contradiction detection | PaperQA2 (arXiv:2409.13740) |
Query expansion | HyDE (arXiv:2212.10496) |
Query decomposition | Multi-hop retrieval (arXiv:2507.00355) |
Outline-guided synthesis | SciRAG (arXiv:2511.14362) |
Status | Feature | Description |
:white_check_mark: | OpenRouter mode | Default, shipped on |
:white_check_mark: | MCP + REST surfaces | Both stable, share orchestration logic |
:white_check_mark: | search · research · ask · discover · synthesize · reason | All six tools wired and tested |
:white_check_mark: | Multi-tenant via per-request key |
|
:white_check_mark: | Local inference branch | Bring-your-own Qwen3/DeepSeek/Llama with full parity to OpenRouter mode. Live on the |
:white_check_mark: | Self-hosted model guide | vLLM, SGLang, and llama.cpp walkthroughs plus Q4_K_M GGUF quant recommendation (browse community GGUF builds on HuggingFace), threshold table, and quant-format-per-server matrix in setup-local-inference.md |
:memo: | Streaming responses | SSE for |
:memo: | Pluggable rerankers | Optional Jina or Cohere rerank stage between fusion and synthesis |
:white_check_mark: Shipped  :construction: Planned  :memo: Exploring
Python 3.11+
An OpenRouter API key (https://openrouter.ai/keys) for default mode
A SearXNG instance, self-hosted (https://docs.searxng.org/) or third-party, as the primary search source
Optional: Tavily API key and/or LinkUp API key — each runs in parallel with SearXNG and contributes to RRF fusion when configured
Optional: Docker + Docker Compose for REST mode
MIT. Copyright (c) 2026 Yoloshii.
Quick conversational answer using LLM.
No search, direct response from model knowledge. Use for simple factual questions or follow-ups.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Question to answer | |
| context | No | Optional context to consider | |
| openrouter_api_key | No | Per-request key override; defaults to RESEARCH_LLM_API_KEY. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It notes 'quick' and 'direct response from model knowledge' but lacks disclosure on latency, cost, accuracy, or other behaviors. Minimal behavioral context beyond purpose.
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?
Extremely concise: two sentences plus a header. Front-loaded with core purpose. Every sentence adds value, no redundancy.
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 existing output schema (not shown), description need not explain returns. It covers purpose, usage context, and contrasts with siblings. Lacks mention of error handling or limitations, but adequate for a simple 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 description coverage is 100%, so baseline 3 applies. Description adds no extra context beyond schema: no explanation of context role or API key override, but schema already describes them adequately.
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?
Description clearly states 'Quick conversational answer using LLM' and 'No search, direct response from model knowledge,' distinguishing it from sibling tools like search and research. It specifically targets simple factual questions or follow-ups.
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?
Description advises use for 'simple factual questions or follow-ups' and contrasts with 'No search,' implying not for external discovery. However, it does not explicitly state when not to use or list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exploratory discovery with knowledge gap analysis.
Identifies what's known and unknown about a topic. Use for cold-start exploration.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Topic to explore | |
| top_k | No | Results per source | |
| focus_mode | No | Domain-specific discovery mode | general |
| identify_gaps | No | Analyze knowledge gaps | |
| openrouter_api_key | No | Per-request key override; defaults to RESEARCH_LLM_API_KEY. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full burden. It discloses the tool's function (gap analysis, identifying known/unknown) but omits behavioral traits like required permissions, rate limits, or side effects. The description adds moderate value but lacks depth expected for a complex tool.
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?
Very concise at three lines with a clear structure: one-line summary, one-line outcome, one-line usage guidance. No wasted words. However, it could be slightly more informative without losing brevity (e.g., hinting at output or key 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 five parameters and an output schema, the description is minimal. It mentions the core function and use case but does not explain the role of parameters like focus_mode or identify_gaps. The output schema likely covers return values, so this is acceptable but not exemplary.
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 baseline is 3. The description does not elaborate on any parameters; it relies entirely on the schema. While sufficient, it adds no extra meaning beyond what the schema provides.
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?
Clearly states it performs 'exploratory discovery with knowledge gap analysis' and 'identifies what's known and unknown about a topic'. The verb+resource+outcome is specific and distinct from siblings like search (which returns results) and ask (Q&A). Mention of 'cold-start exploration' reinforces its unique use case.
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?
Says 'Use for cold-start exploration', providing a clear when-to-use scenario. However, it does not specify when not to use or offer alternatives among siblings (e.g., if you need direct answers, use ask; if you need detailed research, use research). The guidance is present but minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deep reasoning with chain-of-thought analysis.
Two modes, picked automatically by whether sources is provided:
No-sources mode (default): direct chain-of-thought over the model's
own knowledge plus optional context. Use for problems the model can
reason about without external evidence; depth-controlled via
reasoning_depth.
Sources-aware mode (when sources is non-empty): chain-of-thought
synthesis over the pre-gathered sources, with the same shape REST
/api/v1/reason produces. reasoning_depth is ignored in this mode —
the chain-of-thought prompt is fixed because the reasoning shape is
what matters here, not the prose register.
For style variants over pre-gathered sources, call synthesize directly.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Problem or question requiring reasoning | |
| context | No | Background information or constraints (no-sources mode only) | |
| sources | No | Pre-gathered sources to reason over. If provided, switches to sources-aware mode and uses chain-of-thought synthesis. | |
| reasoning_depth | No | How thorough (no-sources mode only). shallow=2-3 steps, moderate=4-6, deep=7+ | moderate |
| openrouter_api_key | No | Per-request key override; defaults to RESEARCH_LLM_API_KEY. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses important behavioral traits: mode switching based on 'sources', that 'reasoning_depth' is ignored in sources-aware mode, and the fixed prompt nature in that mode. It also mentions the per-request API key override. Could be improved by explicitly stating it is a read-only operation with no side effects.
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?
Well-structured with clear mode breakdowns, using bullet-like formatting for readability. Every sentence provides necessary information, no wasted words.
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 presence of an output schema, the description doesn't need to detail return values. It covers the two modes, parameter behavior, and alternative tools. Missing aspects like error handling or rate limiting, but overall sufficient for the tool's complexity.
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%, baseline 3, but the description adds significant context: explains the two modes and how parameters behave differently in each (e.g., 'context' and 'reasoning_depth' only in no-sources mode, 'sources' switches modes). This greatly enriches the agent's understanding.
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 defines the tool's purpose: deep reasoning with chain-of-thought analysis, with two distinct modes. It distinguishes itself from the sibling tool 'synthesize' by noting that for style variants over pre-gathered sources, one should call 'synthesize' 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?
Explicitly states when to use each mode: no-sources mode for problems requiring reasoning without external evidence, sources-aware mode when sources are provided. Also provides an alternative: 'For style variants over pre-gathered sources, call synthesize directly.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full research pipeline: search + LLM synthesis with citations.
Pipeline: Multi-source search → Source aggregation → LLM synthesis → Citation formatting
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Research query | |
| top_k | No | Results per source | |
| reasoning_effort | No | Depth of analysis (low=concise, medium=balanced, high=academic) | medium |
| openrouter_api_key | No | Per-request key override; defaults to RESEARCH_LLM_API_KEY. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the pipeline steps (search, aggregation, synthesis, citation formatting), providing good behavioral insight. It does not mention potential costs or API key requirements, but the pipeline description is sufficient.
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 sentences: the first is a clear title-like statement, the second outlines the pipeline. No wasted words, front-loaded with key information.
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 existence of an output schema (context signal), the description does not need to detail return values. It explains the workflow and sufficiently differentiates from siblings, though it could mention potential dependencies like network access.
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 coverage is 100%, so baseline is 3. The description adds context about the pipeline (e.g., top_k affects per-source results) but does not elaborate on individual parameters beyond what is in the 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's a 'Full research pipeline' combining search and synthesis with citations, and lists the pipeline steps. This distinguishes it from sibling tools like 'search' (just search) and 'synthesize' (just synthesis).
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 implies use for comprehensive research tasks but does not explicitly state when to use this tool vs. alternatives like 'search' or 'synthesize'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multi-source search with RRF (Reciprocal Rank Fusion).
Returns ranked results from SearXNG, Tavily, and LinkUp. Use for raw search results without synthesis. No LLM call.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| top_k | No | Results per source (1-50) | |
| openrouter_api_key | No | Per-request key override; ignored by `search` since no LLM call is made, but accepted for consistency across tools. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description must cover behavior. Mentions RRF ranking, three sources, no LLM call. Lacks details like result limits or permissions but is adequate for a read search tool.
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 short, information-dense sentences. Front-loaded with key purpose. No wasted words.
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?
Has output schema, so return details not needed. Explains core purpose and differentiation. Could mention more about result structure or limitations.
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 coverage is 100%, baseline 3. Description adds no extra meaning to parameters 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?
Clearly states multi-source search with RRF, no synthesis, no LLM call. Verb and resource explicit. Distinguishes from siblings like synthesize.
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?
States 'Use for raw search results without synthesis', providing clear context. Could be more explicit about when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Synthesize pre-gathered content into coherent analysis.
Use when you already have sources from other tools.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Synthesis focus/question | |
| style | No | Output format/length. When None and a preset is provided, the preset's own style is used (preset wins by default; explicit style always overrides). When None and no preset, defaults to comprehensive. | |
| preset | No | Processing pipeline preset (comprehensive, fast, contracrow, academic, tutorial) | |
| sources | Yes | Pre-gathered source documents with title, content, url, origin, source_type | |
| gate_focus | No | Optional focus string the pre-synthesis relevance gate scores sources against instead of the full query (Q2 precision lever for verbose queries). Omitted/None/whitespace uses the full query. | |
| openrouter_api_key | No | Per-request key override; defaults to RESEARCH_LLM_API_KEY. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states the purpose without detailing side effects, safety, or any behavioral traits. For instance, it doesn't indicate whether the tool is read-only, whether it modifies any state, or what the synthesis process entails (e.g., uses LLM calls). This is a significant gap.
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 extremely concise at two sentences. The first sentence captures the primary purpose, and the second provides direct usage context. Every word is earned; no fluff.
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 complexity (6 parameters, output schema exists) and lack of annotations, the description is minimal. The output schema covers return values, so that's not an issue. However, the description does not explain the synthesis process, any prerequisites (other than having sources), or how to handle the output. It is adequate but lacks depth in behavioral context.
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 the schema itself fully documents the parameters. The tool description does not add any additional meaning beyond what the schema already provides. Thus, the baseline score of 3 is appropriate.
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 tool's action ('Synthesize pre-gathered content') and outcome ('into coherent analysis'). It distinguishes from sibling tools by explicitly mentioning that it works with already-gathered sources, which sets it apart from search or discover.
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 explicit guidance: 'Use when you already have sources from other tools.' This tells the agent when to invoke it, but it doesn't explicitly mention when not to use it or provide alternatives. Given the sibling tools, the guidance is sufficient but could be more comprehensive.
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.
v0.6.1askdiscoverreasonresearchsearchsynthesizeScored across 6 tools
Each tool has a distinct purpose: ask for quick answers, discover for exploration, reason for chain-of-thought, research for full pipeline, search for raw results, and synthesize for post-gathering analysis. No significant overlap.
All tool names are single, lowercase verbs: ask, discover, reason, research, search, synthesize. Very consistent pattern.
6 tools is ideal for a research server, covering all key operations without being excessive or sparse.
The set covers the full research workflow from exploration to synthesis, including raw search, quick answers, deep reasoning, and full pipeline. No obvious gaps.
Academic research MCP server for paper search, citation checks, graphs, and deep research.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Web research for agents: quality-scored Google search, webpage extraction, and deep research.
Your agent needs the open web — searched by more than one engine, and read as clean markdown rather than raw HTML. **What you can ask for** • "Search this question with two providers and tell me where they disagree." • "Scrape these 40 URLs into markdown, in one batch." • "Crawl this documentation site and give me every page." • "Do deep research on this topic and cite the sources." • "Find the academic papers behind this claim." **How to use it** Point any MCP client at https://mcp.aisa.one/search/mcp and sign in with OAuth — there is no key to create or paste. 30 tools across several independent providers: Tavily and Exa search, answers, contents and agent runs; Firecrawl scrape, batch scrape, crawl, map and search; Perplexity Sonar, Sonar Pro, reasoning and deep research; Oxylabs AI search and LLM jobs; OpenAI and Anthropic web search; and scholarly search. **Why this rather than the source** Several independent indexes behind one account, because one engine's blind spot is not visible from inside it. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Find the page here, then ask the same agent who links to it or how much traffic it gets — without adding a second server. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** https://mcp.aisa.one/seo-serp/mcp for the Google results page itself, https://mcp.aisa.one/seo-serp-other-engines/mcp for Bing, Baidu and Naver.
