Provides community search and discussion reading capabilities for Reddit, enabling sentiment analysis and complaint mining across subreddits.
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., "@research-mcp Compare what HN and Reddit are saying about AI coding assistants this month."
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.
A local MCP server that gives Claude federated, multi-source research — for project ideas, job hunting, tech trends and market validation.
On 2026-09-19, asked "what are the hottest markets right now," Claude came back with SEO content farms all repeating the same line: the AI wrapper era is over, 80% will fail. One structured data point contradicted the entire narrative — Cal AI: $40M ARR, bootstrapped, 7 employees, a calorie tracker. That number came from an ARR database, not an article.
The problem was never search quality. It was single-source dependency on the SEO layer, with nothing to cross-check against.
A good search doesn't rely on one source. Exhaustiveness comes from fan-out across source classes, dedup, and explicit disagreement detection — not from a better provider.
Related MCP server: research-dispatcher-mcp
Sources are grouped by what kind of truth they carry, not by brand. Every provider sits behind one interface and is swappable by config.
Class | Answers | Provider | Cost |
| what the web says | Tavily | 1,000 credits/mo free |
| what users actually say | HN Algolia, Reddit | free |
| what's hot right now | twitterapi.io | $0.15/1k tweets |
Swappability isn't theoretical: twitterapi.io can be shut down (SocialData.tools was), Tavily's free tier can change, Reddit can reject your OAuth app.
Claude (planner + synthesizer — already exists)
│ MCP
┌───────▼──────────────────────────────────┐
│ ROUTER │
│ fan-out · normalize · dedup │
│ round-robin interleave │
│ graceful degradation │
└───────┬──────────────────────────────────┘
┌────┴─────┬──────────┐
consensus community social
│
┌───────▼──────────────────────────────────┐
│ CORPUS (SQLite) — every result, forever │
└──────────────────────────────────────────┘Not a rebuild of GPT Researcher / open_deep_research. Their pattern is planner → parallel executors → synthesizer, and Claude already is that loop. What was missing is the retrieval layer underneath it.
Three behaviours the router guarantees:
concurrent — one slow source never serialises the pass
graceful — a dead or unconfigured provider is recorded and skipped, never fatal
interleaved — results round-robin across providers, so no single source owns the top of the list (engagement scores aren't comparable across platforms anyway; an HN 500 and a Reddit 500 mean different things)
Items surfacing from two sources are tagged corroborated_by — the seed of
real cross-checking.
Write-through, never a cache: results are always fetched live, the corpus only records what was seen and when. Two payoffs — longitudinal questions ("what changed since March") become a single join, and anything already pulled stays yours if a provider disappears.
Tool | Use it for |
| complaints, lived experience, launch reception, hiring demand |
| published claims, articles, docs — the consensus layer |
| the full comment thread under one Reddit post |
| how much history has accumulated |
| which sources are live vs missing credentials |
uv sync
cp .env.example .env # fill in what you have; HN needs nothingRegister with Claude Code:
claude mcp add research -s user -- uv --directory ~/research-mcp run research-mcpDebug standalone:
npx @modelcontextprotocol/inspector uv --directory ~/research-mcp run research-mcpHN — none. Works immediately.
Tavily — free key at app.tavily.com, no card. Advanced depth costs more than one credit, so a fanned-out pass burns the tier faster than the headline 1,000 suggests: budget ~20–30 real research tasks/month.
Reddit — via Arctic Shift (the Pushshift successor): free, unauthenticated, 2005→present, no key and no approval.
The official API is closed: self-service app creation returns a link to the
Responsible Builder Policy instead of credentials, unauthenticated .json
endpoints 403, and approval is a ticket that reportedly skews against small
projects.
Web search is not a substitute. Reddit's robots.txt blocks every crawler
except Google's ($60M licensing deal), so Bing, DuckDuckGo and the AI search
APIs built on them see nothing. Tavily scoped to reddit.com returns
subreddit landing pages regardless of query — verified 2026-09-19.
Browse, don't search. A plain listing returns 100 posts in ~1s; one server-side keyword search over the same subreddit takes 8-18s and trips the throttle. So with a date window the provider pages listings and matches locally: 19 days of r/hyrox in 8.5s. It is also more complete — browsing covers every post in the window, where search returns only what ranks, and "what do people complain about" is a question about the whole window. The archive is near-real-time: newest post observed 1.2h old.
⚠ Slow and heavily throttled on the full-text path. Measured, not from the docs: the published "~2 req/s" trips a 429 immediately and leaves the endpoint answering 422 for a while after. One keyword search takes 8–18s including retries, and a second straight after is refused. It sustains roughly one search per 30–60s. So Reddit cannot join interactive fan-out — the provider caps itself at one request per call and reports what it did not search.
No global full-text search: keyword params require a subreddit scope. Costs nothing here, since complaint mining is always "what does r/running say".
read_discussion pulls a full thread (up to 25k comments) in ONE request —
the highest-signal call, since first-person complaints are replies, not
thread titles. Prefer it over include_comments, which searches comment
bodies on the slow throttled path and returns fragments without context.
X — the official API has no free tier ($0.005/read, 7-day search window; full archive is Enterprise at $42K+/mo). twitterapi.io gives the full archive with no gate.
Cost is a rounding error. 100,000 credits = $1, 15 credits per tweet
(min 15/call). Billing is per PAGE: ~20 tweets ≈ 300 credits ≈ $0.003.
$1 ≈ 6,600 tweets. limit only trims what Claude is shown — everything
fetched is stored — so min_faves is a result-quality lever, not a budget one.
QPS is the real limit. A never-paid account is capped at 0.2 QPS (one request per five seconds), which throttles concurrent fan-out long before credits run out. Any paid top-up lifts it to 3 QPS permanently. The pricing table lists Free at 3/s — that's the past-customer rate.
Don't subscribe. Starter at $29/mo delivers ~208k tweets/month against a need of a few thousand. Pay-as-you-go $5 ≈ 33k tweets and flips the QPS tier for good.
⚠ Legally split: hiQ v. LinkedIn means scraping public data isn't a CFAA violation, but it does breach X's ToS — fine for personal tooling, revisit entirely if this ever ships to users. Providers in this category do get shut down (SocialData.tools), hence the swappable interface and the corpus.
v0.1 — search_community (HN + Reddit + X), search_web (Tavily), corpus.
Deliberately three tools, not six.
Next: Exa semantic search · lookup_facts (GitHub velocity, ARR, app-store
reviews) · UNCORROBORATED flagging across classes · fetch with clean extraction.
Report what the local research corpus has accumulated: how many results and searches are stored, the spread across source classes, and the date range covered. Use it to check whether a longitudinal question ("what changed since March") has enough history behind it to be answerable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It makes the read-only nature clear through 'Report what the local research corpus has accumulated' and 'has enough history behind it', strongly implying no mutation or side effects. It adds useful context about what data is summarized, though it stops short of explicitly saying the tool never modifies data.
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 tightly written sentences. The first states what the tool reports with concrete components; the second gives a practical usage scenario. No filler or repetition of the tool name.
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?
For a zero-parameter, read-only statistics tool with an output schema available, the description covers the essential what and when. Nothing needed for correct invocation is missing.
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?
The tool has zero parameters and the schema coverage is 100%, so there is no parameter documentation burden. The description adds value by describing what the output reports, which is effectively the parameterless call's meaning.
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 uses a specific verb ('Report') tied to a clear resource: the local research corpus. It enumerates exactly what the report contains (result and search counts, source-class spread, date range), which clearly distinguishes it from sibling search/read/demand 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?
The description gives a concrete when-to-use scenario: checking whether a longitudinal question has enough accumulated history to be answerable. It does not explicitly mention exclusions or alternatives, but no alternatives are needed for a stats/summary tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every configured source, its class, and whether credentials are present. Call this when results look thin -- a missing key means a whole source class is silently absent from every search.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that a missing key means a whole source class is silently absent from searches, which is valuable system behavior beyond a simple listing. It implies read-only status but doesn't explicitly address side effects, authentication, or rate limits.
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 with zero wasted words. The core listing function is front-loaded, and the interpretive guidance follows immediately. Every sentence earns its place.
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?
With zero parameters and an output schema present, the description covers what the tool does, what it returns conceptually, and when to call it. The 'missing key' clue gives agents operational context that makes the tool genuinely useful.
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?
The tool has zero parameters, so the baseline is 4. The empty schema already confirms there are no arguments, and the description doesn't need to add parameter-level meaning.
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 states a specific verb ('List'), a precise resource ('every configured source'), and the fields returned ('class, credentials presence'). This clearly separates it from the sibling search/read tools like search_community or search_web, which serve different functions.
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?
It gives an explicit trigger ('Call this when results look thin') and explains the diagnostic meaning of a missing key. It doesn't state when not to use it or name alternatives, but the tool's diagnostic nature is evident against sibling search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the FULL comment thread under one Reddit post.
This is the highest-signal call for complaint mining, and the natural follow-up to search_community. Posts are the question; comments are the answer. A thread titled "non stop injuries from training" carries dozens of first-person accounts -- what the injury was, what plan caused it, what people did instead -- none of which keyword search surfaces individually, because each one is a reply, not a title.
One request, up to 25k comments, no keyword matching involved. Prefer this over include_comments: searching comment bodies is the slow throttled path and returns fragments without the thread context that makes them readable.
Args: post_url_or_id: a reddit.com/r/.../comments//... URL, or the bare id. limit: max comments to retrieve.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| post_url_or_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool retrieves up to 25k comments, that it does not do keyword matching, and that it returns full thread context. It also warns that the alternative path is slow and throttled. It does not mention rate limits or auth, but the behavioral traits it does disclose are meaningful and go beyond a simple 'read' label.
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 front-loaded with the core purpose, then provides context, then a clear comparison, then parameter explanations. Every sentence earns its place; it is long but information-dense and well organized.
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's complexity (2 params, no enums, no nested objects) and the presence of an output schema, the description is complete. It explains the use case, the alternative, the scale limit, and the parameter semantics. An agent has everything needed to select and invoke it correctly.
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 0%, so the description must compensate. It explains post_url_or_id accepts either a full reddit URL or a bare id, and it explains limit as 'max comments to retrieve'. This adds real meaning beyond the bare schema field names, though it could be slightly more explicit about the default behavior of limit.
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 states a specific verb ('Read'), a specific resource ('the FULL comment thread under one Reddit post'), and explicitly contrasts it with sibling tools. It distinguishes itself from search_community and include_comments, making it clear what this tool does and what it is not.
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 explicitly says when to use this tool ('natural follow-up to search_community', 'highest-signal call for complaint mining') and when not to ('Prefer this over include_comments: searching comment bodies is the slow throttled path'). It names alternatives and gives a clear decision rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search what real people said, in their own words, across Hacker News, Reddit and X simultaneously.
Use this for: complaints and pain points about a product or workflow, how practitioners actually do something, reception of a launch, hiring demand (HN "Who is hiring"), and whether a trend has real users behind it or only press coverage.
Prefer this over search_web whenever the question is about lived experience rather than published claims. Web search returns the pages that RANK; this returns what was actually posted, comments included.
Args: question: plain-language question or keywords. platforms: subset of ["hn", "reddit", "x"]. Default: all configured. subreddits: REQUIRED for Reddit -- the archive has no global full-text search, only within a subreddit. Reddit is skipped with a clear reason if omitted. ⚠ Pass ONE subreddit per call. The archive is a free service that sustains roughly one search per 30-60s; a call naming several subreddits searches only the first and says so. To cover r/running, r/hyrox and r/Garmin, make three separate calls and expect each to take 10-20s. Batching them returns nothing. since/until: "YYYY-MM-DD" bounds. min_points: HN score floor -- use ~50 to cut noise on broad topics. min_faves: X like floor. Worth setting: X bills per page whether the tweets are useful or not, so filtering junk up front is the main lever on cost. ~10 for niche topics, ~100 for busy ones. sort: "top" (default) ranks X by engagement and skews OLD -- a Top search can return results 1-2 years back. "latest" returns today's posts, but they have near-zero likes because nothing has had time to vote, so min_faves must be dropped when using it. Use "top" for "what is the strongest signal", "latest" for "what is happening right now". include_comments: also search reply bodies, not just posts/stories. Slower and noisier, but where complaints actually live -- the first-person "this plan wrecked my knee" account is a reply, not a thread title. limit: how many results to SHOW per provider. Everything retrieved is stored in the corpus regardless -- this only trims the reply.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | top | |
| limit | No | ||
| since | No | ||
| until | No | ||
| question | Yes | ||
| min_faves | No | ||
| platforms | No | ||
| min_points | No | ||
| subreddits | No | ||
| include_comments | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers richly: it discloses rate limits ('roughly one search per 30-60s'), the subreddit limitation (only the first is searched), cost behavior ('X bills per page'), result recency skew ('Top search can return results 1-2 years back'), and the meaning of limit ('only trims the reply'). These are exactly the non-obvious behavioral traits an agent needs.
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 long, but the tool genuinely needs this level of detail given 10 parameters, no annotations, and several operational traps. It is front-loaded with purpose and selection guidance, then organized with a clear 'Args:' block. Every sentence carries operational value; there is no filler.
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's complexity and the complete absence of annotations, the description is remarkably complete: it covers when to use it, when not to, every parameter's semantics, cost concerns, rate limits, failure modes, and sorting behavior. The output schema exists, so return-value documentation is not the description's responsibility.
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 0%, so every parameter must be explained in the description, and it is. Each of the 10 parameters gets meaningful prose: question, platforms, subreddits with a REQUIRED warning, since/until format, min_points, min_faves with cost rationale, sort with top/latest trade-offs, include_comments with where complaints live, and limit with storage behavior.
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 opens with a specific, concrete statement: 'Search what real people said, in their own words, across Hacker News, Reddit and X simultaneously.' It names the exact resource, the verb, and the scope, and further differentiates itself from search_web by explaining that it returns what was actually posted rather than ranked pages.
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 gives explicit use cases ('complaints and pain points... reception of a launch, hiring demand') and explicit routing guidance: 'Prefer this over search_web whenever the question is about lived experience rather than published claims.' It also contrasts the behavior with web search, giving an agent clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find where money and effort are ALREADY moving on a problem.
This is the structured-evidence layer, and the strongest one for judging a business idea. Two sources, two different proofs:
Freelance gigs (Freelancer.com): somebody is paying a human, repeatedly, to do something by hand. Each result carries a budget and a bid count, so it answers "do they pay" and "how much" without asking anyone. The same job posted over and over is a product waiting to exist.
GitHub: an engineer scratching their own itch in public is a
workaround artifact, and stars are other people saying "me too".
stars_per_month matters more than total stars -- a 200-star repo from
2019 is history, the same from last month is a live unmet need.
Use this BEFORE search_web on any business question. Published articles describe markets; this shows transactions. Pair with search_community for the complaint in users' own words.
Args: question: the problem or domain, in keywords. since: "YYYY-MM-DD" — for GitHub this filters repo CREATION date. min_bids: ignore gigs below this many bidders (weak demand). min_stars: ignore repos below this star count. limit: results per source.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | No | ||
| min_bids | No | ||
| question | Yes | ||
| min_stars | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does this well by revealing that the tool queries two external sources, returns budget/bid counts and repos, and explains the interpretation of stars_per_month. However, it does not explicitly state whether the tool is read-only or mention rate limits or auth, which are common behavioral traits worth disclosing when annotations are absent.
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 longer than typical, but it is organized with a bolded lead sentence, bulleted source breakdowns, and an Args section. It front-loads the core purpose and packs domain context that helps the agent interpret results. A few sentences could be trimmed without losing value, but the structure keeps it scannable.
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?
For a tool with 5 parameters, 0% schema coverage, and no annotations, this description supplies the needed context to call it correctly. It explains the question format, each filter's semantics, the meaning of result signals (stars_per_month), and relationship to sibling tools. The output schema covers return structure, so nothing essential is missing.
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 0%, so the description must compensate for the sparse schema. It does so thoroughly: each of the five parameters gets an actionable explanation (e.g., 'since: YYYY-MM-DD — for GitHub this filters repo CREATION date', 'min_bids: ignore gigs below this many bidders'). This adds meaning well beyond the bare property names and types.
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 opens with a concrete, distinctive purpose: 'Find where money and effort are ALREADY moving on a problem.' It names the two data sources (Freelancer.com gigs and GitHub) and explicitly contrasts itself with search_web by calling itself the structured-evidence layer, which clearly distinguishes it from siblings without requiring schema inspection.
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 gives explicit usage guidance: 'Use this BEFORE search_web on any business question' and 'Pair with search_community for the complaint in users' own words.' It explains why (transactions vs articles) and also implies when not to use alternatives, making the decision criteria unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the general web for published claims, articles and documentation.
This is the CONSENSUS layer: it tells you what the web says, which is not the same as what is true. SEO content farms dominate commercial topics and repeat each other, so a unanimous answer here is weak evidence. Corroborate anything load-bearing with search_community or a structured source.
Args: question: the research question. queries: explicit query variants to fan out over. Supply several when the question is broad -- one phrasing returns one slice of the web. domains / exclude_domains: restrict or suppress sources. since: "YYYY-MM-DD". depth: "basic" (1 credit) or "advanced" (costs more, use sparingly).
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | basic | |
| limit | No | ||
| since | No | ||
| domains | No | ||
| queries | No | ||
| question | Yes | ||
| exclude_domains | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses important traits: SEO content farms bias results, consensus is weak evidence, queries return a slice of the web, and depth affects credit cost. It does not mention rate limits or output ordering, but the core behavioral profile is well covered.
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 efficiently organized: a one-sentence purpose, a brief but valuable caveat block, and a labeled parameter list. Every sentence earns its place, and the most important usage warning is front-loaded before parameter details.
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 has 7 parameters, no annotations, but a rich description and an output schema, the description covers most essentials: purpose, limitations, alternative tools, and parameter semantics. The only notable gap is the undocumented limit parametercase, which holds it back from a perfect score.
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 0%, so the description provides critical meaning for parameters. It explains question, queries with usage advice, domains/exclude_domains, since with a format, and depth with credit implications. However, it omits the limit parameter entirely, which appears only in the schema with a default value.
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 opens with a concrete verb-resource phrase: 'Search the general web for published claims, articles and documentation.' It clearly establishes the tool as the CONSENSUS layer, contrasting web consensus with truthijd and distinguishing it from other search tools. The mention of corroborating with search_community or structured sources further differentiates it from siblings.
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 gives explicit guidance on when to use this tool (for published claims and consensus) and when not to rely on it alone, recommending search_community or structured sources for load-bearing information. It also advises supplying multiple queries for broad questions and using advanced depth sparingly, though it stops short of a comprehensive when-to-use vs. when-not-to-use list.
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.1.0corpus_statsproviders_statusread_discussionsearch_communitysearch_demandsearch_webScored across 6 tools
Each tool targets a distinct evidence layer: search_community covers lived experience, search_web covers published claims, search_demand covers transactions and workarounds, and read_discussion is an explicit follow-up for thread-level depth. The meta tools (corpus_stats, providers_status) are clearly separated from search operations, so there is no real ambiguity.
The search_* tools are consistently named with a clear verb_noun pattern, and read_discussion follows suit. corpus_stats and providers_status are descriptive and readable but don't follow the verb-first pattern, creating a minor stylistic inconsistency rather than confusion.
Six tools is a well-scoped size for a research assistant. Each tool earns its place: three distinct search layers, one deep-dive reader, and two diagnostic/infrastructure tools that support the search workflow without bloating the surface.
The set covers the core research loop well: finding lived-experience evidence, published claims, demand signals, reading full Reddit threads, checking corpus depth, and diagnosing provider issues. The main gaps are lack of direct arbitrary URL/content fetching and no obvious way to query the accumulated corpus itself beyond stats.
Multi-engine scholarly research server for search, traversal, full text, and reading lists.
Cross-source search across 18 real-time data sources, source-cited and corroboration-checked.
Federated search of books and papers, BibTeX/RIS citations, open-access retrieval and reading.
Fan out deep research across multiple AI providers, synthesize into one unified report.
