Loading ToolBench
Deep research MCP server for Claude Code and MCP-compatible agents — multi-source web search, citation-aware synthesis, and chain-of-thought reasoning over any OpenAI-compatible model.
Gigaxity Deep Research exposes 14 tools across a modular architecture (main server + 3 companion servers). Tool definitions are visible in source code with schemas and descriptions present, but quality is inconsistent. Most tools have adequate descriptions (100-300 chars), but several lack critical parameter documentation, output schemas are undocumented, and error handling is sparse. Naming is mostly clear (search, research, ask, discover, synthesize, reason, scrape_as_markdown, exa_answer, etc.) but some compound names (exa_answer vs exa_answer_detailed) create minor disambiguation friction. The server's architecture is modular and well-structured, but definition rigor falls short of production baseline. Average per-tool score across all 14 tools is 52.
Quick conversational answer using LLM. No search, direct response from model knowledge. Use for simple factual questions or follow-ups.
Exploratory discovery with knowledge gap analysis. Identifies what's known and unknown about a topic. Use for cold-start exploration.
Fast factual answer with citations. 1-2s, 94% SimpleQA accuracy. Use for mid-task factual lookups where speed matters more than depth. Exa searches its neural index and returns a direct answer with citations. Do NOT use for exploratory research — use research-workflow for that.
Detailed factual answer with full source text. For when you need more context. Like exa_answer but includes the full text of source pages in the response. Use when you need to verify claims or extract additional details from sources.
Read a URL and return clean markdown content via Jina Reader.
synthesize and reason tools have minimal descriptions (50 chars each). 'Synthesis from pre-gathered sources...' and 'Deep reasoning with chain-of-thought...' lack specificity about WHEN to use them, what distinguishes them from each other, or what output structure to expect.
Output schemas are not documented for any tool. Tools return LLM-synthesized text, ranked result lists, and markdown content, but the expected response structure (fields, types, pagination) is absent from all 14 tool definitions. This forces LLMs to infer output structure and wastes tokens on parsing unstructured text.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Deep reasoning with chain-of-thought synthesis.
Rerank a list of search results using Jina Reranker.
Full research pipeline: search + LLM synthesis with citations. Pipeline: Multi-source search → Source aggregation → LLM synthesis → Citation formatting
Scrape a blocked URL as markdown using Brightdata Web Unlocker. Bypasses CAPTCHA, paywalls, and Cloudflare challenges. Use only when other fetchers (Jina, WebFetch) have failed on the same URL.
Multi-source search with RRF (Reciprocal Rank Fusion). Returns ranked results from SearXNG, Tavily, LinkUp, and Brave. Use for raw search results without synthesis. No LLM call.
Search arXiv for academic papers.
Search SSRN via OpenAlex for research papers and working papers.
Search the live web via s.jina.ai or svip.jina.ai.
Synthesis from pre-gathered sources with optional quality gating and contradiction detection.
Parameter descriptions are missing or overly terse for several tools. 'read_url' exposes only {'url': string} with minimal guidance. 'scrape_as_markdown' has only {'url': string}. LLMs cannot infer expected format, timeout behavior, or fallback strategy from bare parameter names.
exa_answer and exa_answer_detailed create naming friction. They perform similar operations (fast factual answers) but differ only in output detail. Names like 'exa_answer_fast' vs 'exa_answer_detailed' or a single 'exa_answer' tool with a 'detail_level' parameter would be clearer. Current naming forces LLMs to reason about subtle differences.
Error handling is absent or minimal. No tool documents what happens on network failure, timeout, API key missing, quota exceeded, or malformed input. Error messages do not guide LLM recovery ('User not found. Try search_users()' pattern is missing).
API credentials (openrouter_api_key, EXA_API_KEY, BRIGHTDATA_API_TOKEN) are exposed as tool parameters or environment variables. openrouter_api_key is even listed as a parameter in search, research, ask, discover, synthesize, reason. This violates the secret-injection pattern, credentials must never appear in tool definitions or request logs.
Pagination is not documented. search, discover, and search_web accept 'top_k' or 'num' parameters but do not document max limits, whether results are truncated, or how to retrieve additional pages. search_arxiv and search_ssrn cap at 10 results by default but do not explain how to iterate or if there are more results available.
The 'synthesize' tool accepts a 'style' parameter with no enum, no valid values documented, and no guidance on what styles are supported. This invites LLM hallucination of invalid style names.
Companion servers (exa-answer, jina-mcp, brightdata-fallback) are modular but their relationship to the main server and composition expectations are not explicit. Tool definitions do not clarify which companion to call for which use case, or how to chain them (e.g., 'read_url fails → try scrape_as_markdown').