research-mcp

Overview Schema Source Related Servers Discussions Admin

search_community

Search first-hand posts and comments across Hacker News, Reddit, and X to surface real complaints, pain points, and lived experiences for research and trend validation.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	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

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 22, 2026

TDQS

A5/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server