Allows to search, browse, and analyze Reddit content in real-time. Provides tools for searching subreddits, full-text search, reading comments, getting post details, subreddit info, and analyzing business opportunities.
Click on "Install 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., "@Reddit MCP Server find business opportunities in r/Entrepreneur"
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.
Your AI, plugged into Reddit. No API key. No login. Just the raw feed.
Give Claude — or any MCP client — real-time access to Reddit: browse subreddits, pull comment threads, mine startup ideas and pain points. Built on FastMCP and Playwright, it scrapes the public web interface with a fast, headless browser. The result: live Reddit data, straight from the source, with zero setup cost.
You: "What are people complaining about in r/SaaS this week?"
AI: ▸ 214 posts scanned · 37 pain points found · score 1260 "Paying for
overpriced subscriptions is ridiculous" · 8 ideas over 1000 points🔍 Search & browse — scan one or many subreddits with native sorting, time filters and keyword filtering
💬 Comments & details — threaded comment trees with authors, scores and depth, plus full post bodies
📊 Subreddit & user intel — description, active users, top posts; any user's public posts and karma
🚀 Business opportunity radar — scores posts for startup/pain-point potential (see the algorithm)
⚡ Built for speed — one shared browser reused across calls, an in-memory TTL cache, asset blocking, retries with backoff, anti-bot detection
Related MCP server: Reddit MCP Server
Ask your assistant in plain language — it speaks MCP natively:
"Search Reddit for 'best mechanical keyboard 2025' from the last month."
{
"total_results": 25,
"query": "best mechanical keyboard 2025",
"posts": [
{
"title": "The Keychron Q3 is criminally underrated",
"score": 812,
"num_comments": 143,
"author": "keeblover42",
"url": "https://www.reddit.com/r/MechanicalKeyboards/comments/...",
"post_type": "self"
}
]
}"Analyze r/SaaS and r/Entrepreneur for startup pain points."
{
"total_posts_scanned": 214,
"high_score_ideas": 8,
"ideas": [
{
"title": "Paying for overpriced subscriptions is ridiculous — someone should make a smart subscription manager",
"opportunity_score": 1260,
"matched_keywords": ["pay", "subscription", "should exist", "problem"],
"url": "https://www.reddit.com/r/SaaS/comments/..."
}
]
}Tool | Parameters | Description |
|
| Browse posts from specific subreddits with sorting. |
|
| Perform a global keyword search across Reddit. |
|
| Extract threaded comments with hierarchical depth. |
|
| Get full details: selftext, link, flair, metadata. |
|
| Name, description, active users and top posts. |
|
| Browse a user's public posts and karma. |
|
| Get the current top posts of |
|
| Identify high-potential SaaS/startup pain points. |
| — | Verify the server is alive (no network access). |
git clone https://github.com/Simonc44/Reddit-MCP-Server.git
cd Reddit-MCP-Server
python -m venv .venv && source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -r requirements.txt
playwright install chromium # one-time browser downloadThat's it — the server is ready. Point your MCP client at python /path/to/server.py.
Add to claude_desktop_config.json (use absolute paths):
{
"mcpServers": {
"reddit-mcp": {
"command": "/path/to/your/virtualenv/bin/python",
"args": ["/path/to/reddit-mcp-server/server.py"]
}
}
}Windows: use double backslashes in your paths.
claude mcp add reddit-mcp -- python /path/to/reddit-mcp-server/server.py$$Score = (Upvotes \times 2) + (Comments \times 3)$$
With multipliers and bonuses:
High engagement — comments/upvotes ratio $> 0.3$ → ×1.3 (or ×1.15 if $> 0.15$)
Monetization keywords — $+15$ per match (pay, subscription, SaaS, pricing, …)
Pain-point keywords — $+20$ per match (problem, frustrated, broken, wish, hate, …)
Dual-category bonus — both categories detected → overall ×1.25
Keyword matching respects word boundaries (pay matches paying, not paywall), and every idea includes its matched_keywords so the AI can explain its reasoning.
Every knob is an environment variable — no code changes needed:
Variable | Default | Description |
|
| Run Chromium headless ( |
|
| Browser viewport. |
| modern Chrome UA | User-agent sent to Reddit. |
|
| Navigation timeout (ms). |
|
| Content wait timeout (ms). |
|
| Pause (s) between subreddit requests — be polite to Reddit. |
|
| Scroll iterations to trigger lazy-loaded content. |
|
| Retry attempts per page load (exponential backoff). |
|
| Base backoff (s) between retries. |
|
| TTL (s) of the in-memory cache for listings ( |
|
| Log level ( |
uv sync --extra dev # reproducible env in .venv/ (uv is optional — pip works too)
make lint # ruff
make typecheck # mypy (server + tests)
make test # pytest — 133 offline unit tests
make coverage # pytest + coverage gate (100 %)
make test-live # live tests against real reddit.com (needs Chromium)
make run # start the MCP serverTests are a first-class citizen here:
tests/test_server.py, tests/test_scraper.py, tests/test_browser.py — 133 offline tests using fake Playwright objects: 100 % coverage, no browser, no network.
tests/test_integration.py — live end-to-end tests against the real Reddit website (opt-in: REDDIT_LIVE_TESTS=1 pytest -m integration).
CI (.github/workflows/ci.yml) runs ruff, mypy and the coverage gate on Python 3.10–3.12, plus an opt-in live job.
docker build -t reddit-mcp-server .
docker run -i --rm reddit-mcp-serverChromium is installed inside the image, and the server runs as an unprivileged user.
Rate limits & IP blocks — heavy scraping can trigger Reddit's anti-bot (HTTP 429 / login redirects). The server retries with backoff and detects them; increase REDDIT_REQUEST_DELAY if you get blocked.
Dynamic DOM — this is a scraper, not an API: if Reddit changes its frontend, selectors may break. The live test suite exists to catch exactly that — run it before opening an issue.
Member counts — Reddit's anonymous UI no longer exposes a subreddit's total member count; get_subreddit_info returns members: null when unavailable (other stats come from the structured page header and are reliable).
Speed — first call of a session launches Chromium (5–30 s); subsequent calls reuse the shared browser and cache.
No private auth — public-facing pages only; no account login.
Contributions are very welcome — improving selectors, adding tools, refining docs. See CONTRIBUTING.md.
Found a vulnerability? Report it privately — see SECURITY.md.
MIT © 2026 Simon Chusseau
Scan subreddits for business opportunities (SaaS/startup pain points).
Scores posts with: popularity (upvotes), engagement (comments) and semantic relevance (monetization + pain-point keywords). See README for the formula.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | "hot", "new", "top" or "rising". | hot |
| limit | No | Maximum number of ideas to return (capped at 200). | |
| keywords | No | Optional extra keywords to filter posts by title. | |
| min_score | No | Minimum opportunity score to include a post. | |
| subreddits | No | Subreddits to analyze (defaults to a curated startup set). | |
| time_filter | No | Time window for "top": "hour", "day", "week", "month", "year", "all". | day |
| 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 behavioral disclosure burden. It reveals that posts are scored by popularrity, engagement, and semantic relevance, and points to README for the formula. However, it doesn't address read-only behavior, rate limits, auth requirements, or output side effects, leaving part of the burden unmet.
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 three short sentences, front-loaded with the primary purpose and scoring criteria, with no filler. The README pointer avoids dumping formula details while still being honest about where to find them.
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 a full input schema, an output schema, and zero annotations, the description covers the core purpose, scoring dimensions, and formula location. It doesn't enumerate defaults or parameter interactions, but those are already present in the schema, so what remains is sufficient for most calling scenarios.
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 all six parameters are already documented. The description adds no parameter-specific guidance beyond mentioning monetization and pain-point keywords, which loosely relates to the semantic relevance concept but not to any specific parameter.
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, 'Scan subreddits', and a clear resource and outcome: identifying business opportunities (SaaS/startup pain points). This is distinct from sibling tools like search_reddit, get_trending_posts, or get_post_detais, none of which target business opportunity scoring.
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 the tool is for finding business opportunities, so an agent can infer when to use it, but it does not explicitly state when to prefer this tool over search_reddit or get_trending_posts, nor does it mention exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract the threaded comments of a Reddit post.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of comments to return (capped at 200). | |
| post_url | Yes | Full URL of the post (absolute paths like /r/.../comments/... also work). |
| 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. 'Extract' implies a read-only operation and 'threaded' usefully signals nested comment structure. However, it does not disclose auth requirements, rate limits, pagination behavior, or error cases, leaving notable gaps.
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 a single focused sentence with no filler or redundancy. The key purpose is front-loaded and immediately actionable.
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 an output schema present and full parameter coverage in the input schema, the description is mostly sufficient for a simple retrieval tool. However, the lack of guidance on alternatives, auth, rate limits, or failure behavior leaves it merely adequate rather than complete.
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%, and the schema already documents post_url and limit with defaults and bounds. The description adds no parameter-specific meaning beyond the schema, so 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 uses a specific verb ('Extract') and a precise resource ('threaded comments of a Reddit post'), making the tool's purpose unmistakable. This clearly distinguishes it from siblings like get_post_details or search_reddit, which target different data.
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 context is clear: use this tool when you need comments from a specific Reddit post. It does not explicitly list alternatives or exclusions, but the phrasing makes the intended use obvious relative to the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full content of a Reddit post: title, author, score, selftext, flair and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| post_url | Yes | Full URL of the post (absolute paths also work). |
| 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 must carry the burden. 'Get' reasonably implies a read-only operation, and listing returned fields is transparent about output. However, it does not disclose potential rate limits, authentication requirements, or behavior on invalid URLs. It is not misleading, but lacks deeper behavioral context.
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?
A single sentence that front-loads the verb and resource, then lists the returned content fields. Every element adds value and there is no redundancy or 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 has one well-documented parameter and an output schema, the description sufficiently covers what it returns and why it exists. It does not explain return formatting, but the output schema handles that. It could mention sibling differentiation, but that is covered in the usage dimension.
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%, and the post_url parameter is already fully described in the schema ('Full URL of the post (absolute paths also work)'). The tool description adds no additional meaning about this parameter, so the baseline score of 3 applies.
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 the specific verb 'Get' with the resource 'full content of a Reddit post' and enumerates concrete fields (title, author, score, selftext, flair, metadata). This clearly distinguishes it from sibling tools like get_post_comments, which target comments rather than post content, and search_reddit, which performs searches.
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 usage: when you need full post content, use this tool. However, it offers no explicit guidance about when to choose it over siblings such as get_post_comments, and does not mention alternatives or exclusions. This is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get public info about a subreddit: description, stats and top posts.
Stats are read from the structured shreddit-subreddit-header element
(name, description, active users). Note: Reddit's anonymous UI no longer
displays the total member count, so members is only populated when the
current subreddit appears in the sidebar "Top communities" list.
| Name | Required | Description | Default |
|---|---|---|---|
| subreddit | Yes | Subreddit name, with or without the r/ prefix (e.g. "python"). |
| 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 behavioral burden and does well by disclosing an important data quirk: Reddit's anonymous UI no longer shows total members, so 'members' is populated only under a specific sidebar condition. It also clarifies that stats are read from a structured element, giving the agent expectations about data sourcing.
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 compact and front-loaded: the first sentence states what the tool returns, and the second sentence adds a valuable caveat without drifting into unnecessary detail. Every sentence contributes useful 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 low parameter count, presence of an output schema, and no required authentication detail (since it is 'public info'), the description is largely complete for invoking the tool. A slight gap is that it does not mention pagination or criteria for 'top posts,' but this is minor and may be covered by the output schema.
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 single 'subreddit' parameter is fully documented with format guidance ('with or without the r/ prefix'). The description itself does not add parameter-level meaning beyond what the schema already provides, so the baseline 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 states a specific verb-resource pairing: 'Get public info about a subreddit' and enumerates the contained data: 'description, stats and top posts.' This clearly distinguishes it from sibling tools focused on comments, posts, users, or searches.
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 usage context by naming the resource and data type, so an agent can infer it is for retrieving subreddit-level public information. However, it does not explicitly contrast with sibling tools or state when not to use it, such as when searching Reddit or fetching specific posts/comments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the currently trending posts across Reddit (r/popular).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of posts to return (capped at 100). | |
| time_filter | No | "hour", "day", "week", "month", "year", "all". | day |
| 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 burden of behavioral disclosure. It clarifies the source is r/popular and that results are current, but it does not mention rate limits, authentication, or other runtime behavior. The output schema covers return shape, and the read-only nature is implied by 'Get', so this is adequate but not rich.
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 a single, front-loaded sentence with no filler or repetition. Every word adds meaning, and the key scope ('r/popular') appears early.
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 low complexity, full schema coverage, and presence of an output schema, the one-sentence description is sufficient for an agent to understand what the tool does and what it returns. No critical context appears to be 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 100%, so both parameters (limit and time_filter) are already fully documented in the schema. The description adds no additional parameter-level meaning beyond the general 'currently trending' framing, matching the baseline for fully covered schemas.
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 ('Get') with a clear resource ('currently trending posts') and an explicit scope ('across Reddit (r/popular)'). This distinguishes it from sibling tools like search_reddit or get_subreddit_info without ambiguity.
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 clearly implies this tool is for Reddit-wide trending content rather than search, subreddit-specific, or user-specific data. It does not explicitly name alternatives or state when not to use it, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse the public posts of a Reddit user.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | "hot", "new", "top" or "controversial". | new |
| limit | No | Maximum number of posts to return (capped at 100). | |
| username | Yes | Reddit username, with or without the u/ prefix. |
| 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 for behavioral disclosure. It only says 'browse public posts', which weakly implies read-only and public scope, but it does not describe pagination, output shape, error handling, or any behavioral constraints. The schema covers sort and limit defaults, but not the broader behavioral context.
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 a single short sentence with no filler and the action front-loaded. It is efficiently phrased, though it is sparse enough that some useful behavioral context could be added without harming structure.
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?
An output schema exists and parameter schemas are fully descriptive, so the essential invocation details are present. The description is missing usage guidance and any behavioral nuance, but for a simple low-complexity list tool it remains minimally adequate rather than seriously incomplete.
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%; all three parameters have helpful descriptions, including the u/ prefix handling, sort options, and the 100-post cap. The tool description adds no parameter-level information beyond the schema, so the baseline 3 applies.
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 one-sentence description states a clear verb ('browse') and a specific resource ('public posts of a Reddit user'), which makes the purpose immediately understandable. It distinguishes itself from siblings like get_post_comments and get_post_details by targeting a user's post listing, but it does not explicitly contrast with search tools such as search_reddit, so it stops short of a 5.
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 the tool is used when you want a known user's public posts, but it gives no explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, so an agent has to infer selection criteria from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check that the server is alive and ready to scrape.
Returns: A dict with the server status and version.
| 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 burden of behavior disclosure. It states that the tool performs a liveness/readiness check and returns a dict with server status and version. It does not detail auth, error behavior, or response key semantics, but for a zero-parameter health check this is reasonably transparent.
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, purposeful sentences: one states the action and purpose, the other summarizes the return value. The most important information is front-loaded and 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?
For a health-check tool with no parameters and a stated return format, the description is complete. The presence of an output schema means detailed return fields need not be repeated, and the tool's role among the sibling tools is clear.
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?
There are zero parameters, so the description does not need to explain parameter meaning. The baseline for zero-parameter tools is 4, and the description adds no unnecessary parameter details.
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 ('Check') and resource ('server') and clearly states the intended condition: alive and ready to scrape. This also distinguishes it from the Reddit-focused sibling tools, which are all about content retrieval rather than server health.
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 phrase 'ready to scrape' gives clear context that this tool should be used before scraping to verify server availability. It does not explicitly name alternatives or state when not to use it, but the use case is obvious and distinct from the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse posts from one or more subreddits, optionally filtered by keywords.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | "hot", "new", "top" or "rising". | hot |
| limit | No | Maximum number of posts to return (capped at 100). | |
| keywords | No | Optional list of keywords to filter posts by title. | |
| subreddits | Yes | Subreddits to scan, with or without the r/ prefix (e.g. ["python", "webdev"]). | |
| time_filter | No | Time window for "top": "hour", "day", "week", "month", "year", "all". | day |
| 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 of behavioral disclosure. It only says 'Browse posts', which implies a read operation but does not state limits, authentication needs, filtering behavior details, or what happens with invalid subreddits. Key non-obvious behaviors are left undisclosed.
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 a single focused sentence that communicates the core action and the main optional modifier without wasted words. It is front-loaded and easy to scan.
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?
Despite having five parameters, no annotations, and multiple related sibling tools, the description is minimal. It does not clarify how it differs from 'search_reddit_query', when to use it, or any operational caveats. The output schema helps, but the description alone leaves the agent with limited contextual grounding.
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%, and the input schema thoroughly documents parameters including defaults, caps, and allowed values. The description adds only a generic mention of keyword filtering, so it provides no significant value beyond the schema, keeping this at baseline.
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 clear verb ('Browse') and resource ('posts from one or more subreddits'), and mentions optional keyword filtering. It is understandable, though it does not explicitly distinguish this tool from the similarly named sibling 'search_reddit_query'.
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 this tool is for browsing posts by subreddit, optionally with keyword filters, but it provides no explicit guidance about when to prefer it over alternatives like 'search_reddit_query'. There is no exclusion or mention of alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Reddit by keywords through the search page.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | "relevance", "hot", "top", "new" or "comments". | relevance |
| limit | No | Maximum number of results (capped at 100). | |
| query | Yes | Search text (e.g. "best python framework 2025"). | |
| subreddit | No | Optionally restrict the search to a single subreddit. | |
| time_filter | No | "hour", "day", "week", "month", "year", "all". | week |
| 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 communicates the basic read-only nature of the operation ('Search') and hints at the mechanism ('through the search page'), but it does not disclose pagination behavior, rate limits, output format characteristics, or any unusual constraints.
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 a single, front-loaded sentence with no filler. It is appropriately concise for a simple search operation, though it could be slightly expanded to clarify scope and alternatives without becoming bloated.
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?
The description is too sparse to be fully contextually complete. It does not address the existence of the closely related sibling 'search_reddit', nor does it mention any practical constraints or expected behavior. The output schema covers return values, but the description still leaves important selection and invocation context unresolved.
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 input schema fully documents all five parameters. The description adds nothing beyond the obvious keyword-based purpose, which is appropriate given the schema already provides detailed semantic explanations for every parameter.
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 identifies the action ('Search Reddit') and specifies the input type ('by keywords') and mechanism ('through the search page'). It is not a tautology and conveys the core purpose. However, it does not differentiate this tool from its sibling 'search_reddit', which likely serves a similar role.
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 no guidance about when to use this tool versus 'search_reddit' or any other sibling. It does not state any exclusions, conditions, or preferred contexts, leaving the agent to guess which of the two search-related tools to invoke.
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. Dates show when Glama detected each change.
v0.3.0analyze_opportunitiesget_post_commentsget_post_detailsget_subreddit_infoget_trending_postsget_user_postshealth_checksearch_redditsearch_reddit_queryMost tools are clearly separated by resource and action, but search_reddit and search_reddit_query overlap heavily in purpose and are easy to confuse. The rest of the tools, such as get_post_details and get_subreddit_info, are distinct.
Tool names mostly follow a consistent verb_noun pattern like get_post_details and get_user_posts. search_reddit_query is an awkward exception and health_check is more of a utility, but the overall naming is still readable and predictable.
Nine tools is a well-scoped count for a Reddit browsing and analysis server. Each tool has a clear role, and the number feels neither bloated nor too sparse.
The server covers the main read-only Reddit workflows: posts, comments, subreddits, users, search, and trending content. Minor gaps like explicit subreddit post listing or user comments exist, but they are not likely to block typical agent tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Find high-intent Reddit conversations and manage lead workflows from MCP-compatible AI agents.
Reddit posts, comments, subreddits, and search for AI agents. Free key, self-minted, no signup.
Read-only Reddit search API for AI agents: posts, comments, comment trees, subreddit rules.
Reddit growth toolkit — opportunities, replies, cold DMs, brand mentions, SEO, autopilot.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Simonc44/Reddit-MCP-Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
