This server provides read-only Reddit data via MCP using the Arctic Shift archive, with no account, API key, or browser required.
Get a thread: get_thread fetches a post and its full comment tree from a URL or ID, with sorting and comment-count controls.
Bulk post lookup: get_posts retrieves metadata for up to 500 posts by ID.
Bulk comment lookup: get_comments fetches up to 500 comments by ID, useful for expanding collapsed replies.
Search posts: Filter by subreddit, author, keyword (title/body), URL prefix, or date range; sort and limit results.
Search comments: Filter by subreddit, author, keyword, post ID, parent comment ID, or date range; also works as a user comment history.
Search subreddits: Find by name, prefix, subscriber count, age, or NSFW status.
Output controls: Support raw JSON, field allowlists, max character budgets, sorting/dating options.
Limitations: all tools are read-only (no voting, posting, or commenting); recent post/comment scores and comment counts under ~36 hours are placeholders; subreddit subscriber counts may lag; the underlying Arctic Shift service has no uptime SLA.
Provides read-only access to Reddit, enabling retrieval and search of posts, comments, and 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., "@simple-reddit-mcp show me the latest posts from r/programming"
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 read-only Reddit MCP server that needs no Reddit account, no API key, and no browser. It reads threads, comments and subreddits from the Arctic Shift archive over plain keyless HTTP.
One runtime dependency, zeromcp, keeps simple-reddit-mcp lightweight and quick to start.
Python 3.11 or newer
uv (recommended) or pip
Related MCP server: reddirect
uvx simple-reddit-mcpThe server speaks MCP over stdio: JSON-RPC on stdout, logs on stderr.
Claude:
claude mcp add reddit --scope user -- uvx simple-reddit-mcpor
{
"mcpServers": {
"reddit": {
"command": "uvx",
"args": ["simple-reddit-mcp"]
}
}
}Codex — in ~/.codex/config.toml:
[mcp_servers.reddit]
command = "uvx"
args = ["simple-reddit-mcp"]Implemented:
Tool | Arctic Shift endpoint | Purpose |
|
| A post plus its comment tree, from any reddit URL or id |
|
| Bulk post lookup by id (up to 500) |
|
| Bulk comment lookup by id (up to 500) |
|
| Discovery by subreddit / keyword / author / date range |
|
| Comment-level search; with |
|
| Find subreddits by name, prefix, size, or age |
Not currently implemented:
Tool | Arctic Shift endpoint |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
— |
|
Read-only. Voting, commenting and posting require Reddit auth
score and num_comments are placeholders for ~36h. Arctic Shift archives
a post the moment it appears and backfills vote data later, so fresh posts
report 1 and 0. Rendered output flags anything under 36h old.
Free service = no uptime SLA.
uv sync --group dev
uv run --group dev pytestTo publish a new release to PyPI, bump version and push to master:
uv version --bump patch # bumps pyproject.toml and relocks
git commit -am "release $(uv version --short)"
git pushMIT licensed.
Built on zeromcp (MIT).
Data comes from Arctic Shift, a free service; be considerate with it.
Look up comments in bulk by id.
Use for the comment ids returned inside a [+N more replies] marker, or any
comment permalink you already resolved.
Caveat: Arctic Shift archives posts the moment they appear and backfills vote data after ~36h, so score and num_comments on anything newer than that are placeholders (usually 1 and 0) - never report them as real counts.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Comma separated comment ids, bare or t1_ prefixed. Up to 500. | |
| raw | No | Return the raw Arctic Shift JSON instead of markdown. | |
| fields | No | Comma separated field allowlist to shrink the response. | |
| max_chars | No | Character budget for the rendered output. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a significant behavioral caveat beyond the annotations: Arctic Shift archives posts immediately and backfills vote data after ~36h, making score and num_comments placeholders. This warns the agent against reporting fake counts, which is essential context that annotations alone do not provide.
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 sentences, front-loaded with the core purpose, followed by usage context and a clearly marked caveat. Every sentence earns its place with 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?
The tool has no output schema, so the description must carry more weight. It covers purpose, usage, and a critical data caveat, which is adequate for a bulk lookup tool. It doesn't explain markdown vs. raw output, but the schema covers that via the 'raw' parameter. Overall it feels complete given the 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 covers all 4 parameters with full descriptions, so baseline is 3. The description adds value by clarifying what kind of IDs to supply (from reply markers or permalinks) and that lookups are bulk. This helps the agent understand the 'ids' parameter beyond its schema description.
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 a specific action ('Look up comments in bulk by id') and identifies the resource (comments) and method (by id). It distinguishes itself from siblings by focusing on bulk id lookup, contrasting with search-based or thread-level 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 explicit guidance on when to use this tool: for comment ids from '[+N more replies]' markers or resolved permalinks. It does not explicitly mention alternatives, but the context is clear enough to avoid confusion with search_comments or get_thread.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up posts in bulk by id.
Use when you already have post ids (for example from search_comments
results) and want their titles, authors and scores.
Caveat: Arctic Shift archives posts the moment they appear and backfills vote data after ~36h, so score and num_comments on anything newer than that are placeholders (usually 1 and 0) - never report them as real counts.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Comma separated post ids, bare or t3_ prefixed. Up to 500. | |
| raw | No | Return the raw Arctic Shift JSON instead of markdown. | |
| fields | No | Comma separated field allowlist to shrink the response. | |
| max_chars | No | Character budget for the rendered output. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and open-world hints, but the description adds a crucial warning about placeholder vote data for posts newer than ~36h. This discloses behavioral quirks (backfill delay) and tells the agent never to report placeholder scores/comments as real, going well beyond the annotations.
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?
Three short paragraphs front-load the primary purpose, then provide usage context and a caveat. No wasted sentences; every part contributes essential information. The structure is clean and 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 bulk lookup tool with no output schema, the description covers returned fields (titles, authors, scores), notes the placeholder caveat, and the schema documents all parameters. This is sufficient for the agent to invoke it successfully without missing key 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% with all parameters well-documented. The description does not add any parameter-specific nuance beyond the schema (e.g., it mentions 'bulk' but the schema already says 'up to 500'). This meets the baseline for high schema coverage.
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 verb and resource: 'Look up posts in bulk by id.' It clearly distinguishes this from sibling search tools (which find posts by query) and from get_thread/get_comments by emphasizing bulk retrieval by known IDs. The mention of returning titles, authors, and scores further clarifies the tool's scope.
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 an explicit 'Use when' condition: when you already have post IDs, e.g., from search_comments results. This implies when not to use (when you lack IDs) and implies alternatives like search tools. However, it does not explicitly name an alternative tool, so it falls short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a reddit post and its comment tree from any reddit URL or id.
The primary tool: give it whatever the user pasted. Comments come back as an
indented markdown tree; collapsed branches show as [+N more replies].
Caveat: Arctic Shift archives posts the moment they appear and backfills vote data after ~36h, so score and num_comments on anything newer than that are placeholders (usually 1 and 0) - never report them as real counts.
| Name | Required | Description | Default |
|---|---|---|---|
| raw | No | Return the raw Arctic Shift JSON instead of markdown. | |
| sort_top | No | Order comments by score instead of reddit's tree order. | |
| max_chars | No | Character budget for the rendered output. | |
| parent_id | No | Comment id to focus on; only that subtree is returned. | |
| url_or_id | Yes | A reddit thread URL, share link, redd.it link, or post/comment id (bare or t3_/t1_ prefixed). | |
| comment_limit | No | Max comments to fetch, 0-25000. Use 0 for post metadata only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld/idempotent annotations, the description discloses output format (indented markdown tree, collapsed branches) and a critical data quality caveat about Arctic Shift placeholders. This significantly informs the agent about runtime behavior and data reliability.
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 with purpose, then output behavior, then caveat. Each sentence contributes essential information without wordiness.
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 6 parameters and no output schema, the description covers the primary use case, return format, and an important limitation. It does not detail every parameter or edge case, but the schema fills the gaps, making it complete enough for a read-only 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 coverage is 100%, so parameters are already well documented. The description adds value by emphasizing the flexible url_or_id format (any URL or id) and explaining the default output format, which complements rather than repeats 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 explicitly states 'Read a reddit post and its comment tree from any reddit URL or id,' using a specific verb and resource. It also positions itself as 'the primary tool' for pasted links, distinguishing it from siblings like get_posts or get_comments.
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 indicates when to use it ('give it whatever the user pasted') and adds a caveat about when data is unreliable (new posts have placeholder scores). However, it does not explicitly name alternatives or exclusions for using other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find comments by subreddit, author, keyword, post or date range.
With author alone this doubles as user comment history. Comment keyword
search is the slowest endpoint - pair body with a subreddit, an author or a
date range.
Caveat: Arctic Shift archives posts the moment they appear and backfills vote data after ~36h, so score and num_comments on anything newer than that are placeholders (usually 1 and 0) - never report them as real counts.
| Name | Required | Description | Default |
|---|---|---|---|
| raw | No | Return the raw Arctic Shift JSON instead of markdown. | |
| body | No | Keyword search over the comment body. Needs `subreddit`, `author`, `link_id` or `parent_id`. | |
| sort | No | `asc` or `desc` by creation time. | |
| after | No | Earliest creation date: epoch, ISO date, or relative like `3d` / `1year`. | |
| limit | No | Number of comments to return, 1-100. | |
| author | No | Restrict to one author. On its own this is a user's comment history. | |
| before | No | Latest creation date, same formats as `after`. | |
| fields | No | Comma separated field allowlist to shrink the response. | |
| link_id | No | Only comments under this post id. | |
| max_chars | No | Character budget for the rendered output. | |
| parent_id | No | Only replies to this comment id. | |
| subreddit | No | Restrict to one subreddit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses important behavioral traits: the Arctic Shift caveat that 'score and num_comments on anything newer than that are placeholders (usually 1 and 0) - never report them as real counts.' It also notes that keyword search is the slowest endpoint. This adds significant value beyond annotations.
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 paragraphs with zero filler. The first sentence establishes purpose, the second gives usage advice, and the third presents a critical caveat. Every sentence earns its place and the structure is logical and front-loaded.
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 high parameter count (12), rich schema descriptions, and no output schema, the description is remarkably complete. It covers search dimensions, performance trade-offs, and data-quality caveats. The raw field's schema description plus the caveat about score/num_comments indirectly inform the output format, making further explanation unnecessary.
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 schema covers all 12 parameters with descriptions, so baseline is 3. The description adds extra semantics: 'With author alone this doubles as user comment history' clarifies the author parameter, and pairing body with subreddit/author/date range provides practical constraints not fully stated in the schema. This lifts it above 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 clearly states the tool's function: 'Find comments by subreddit, author, keyword, post or date range.' This is a specific verb ('Find') plus a resource ('comments') with enumerated search dimensions, which distinguishes it from sibling tools like search_posts and get_comments.
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 usage guidance: 'With author alone this doubles as user comment history' and 'Comment keyword search is the slowest endpoint - pair body with a subreddit, an author or a date range.' This tells the agent when to use the tool and how to optimize queries, including performance considerations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find posts by subreddit, author, keyword or date range.
Keyword parameters (query, title, selftext) are only accepted together
with subreddit or author, and can still time out on very busy ones - a
date range makes them reliable.
Caveat: Arctic Shift archives posts the moment they appear and backfills vote data after ~36h, so score and num_comments on anything newer than that are placeholders (usually 1 and 0) - never report them as real counts.
| Name | Required | Description | Default |
|---|---|---|---|
| raw | No | Return the raw Arctic Shift JSON instead of markdown. | |
| url | No | Prefix match on the post's outbound URL. | |
| sort | No | `asc` or `desc` by creation time. | |
| after | No | Earliest creation date: epoch, ISO date, or relative like `3d` / `1year`. | |
| limit | No | Number of posts to return, 1-100. | |
| query | No | Keyword search over title and selftext. Needs `subreddit` or `author`. | |
| title | No | Keyword search over the title only. Needs `subreddit` or `author`. | |
| author | No | Restrict to one author. | |
| before | No | Latest creation date, same formats as `after`. | |
| fields | No | Comma separated field allowlist to shrink the response. | |
| selftext | No | Keyword search over the body only. Needs `subreddit` or `author`. | |
| max_chars | No | Character budget for the rendered output. | |
| subreddit | No | Restrict to one subreddit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, open-world, and idempotent, so the description focuses on additional behavioral details. It discloses that Arctic Shift archives posts immediately and backfills vote data after ~36h, making score and num_comments placeholders on recent posts, and warns about possible timeouts. This is high-value context beyond the annotations.
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 the purpose, the second covers parameter constraints, and the third explains the important data caveat. No filler sentences; every part 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?
Despite having 13 parameters, the description focuses on the essential usage constraints and the major data-quality caveat that could mislead users. Return format is already addressed in the schema's raw parameter description, and annotations provide safety context, so the description is complete for practical use.
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 schema covers all 13 parameters with 100% coverage, so the baseline is met. The description adds cross-parameter semantics by explaining that query, title, and selftext are only accepted with subreddit or author, and that a date range makes them reliable—constraints not visible from individual schema entries.
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 'Find posts by subreddit, author, keyword or date range,' using a specific verb and resource scope that clearly distinguishes search_posts from sibling tools like get_posts and search_comments. It communicates the core search capability immediately and effectively.
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 constraints: keyword parameters require subreddit or author, and a date range improves reliability. It doesn't explicitly compare to sibling tools or state when to prefer this tool over others, but the parameter-level guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find subreddits by name, prefix, subscriber count or age.
Subreddit records are refreshed infrequently, so subscriber counts lag reality by more than the ~36h that applies to posts and comments.
Caveat: Arctic Shift archives posts the moment they appear and backfills vote data after ~36h, so score and num_comments on anything newer than that are placeholders (usually 1 and 0) - never report them as real counts.
| Name | Required | Description | Default |
|---|---|---|---|
| raw | No | Return the raw Arctic Shift JSON instead of markdown. | |
| sort | No | `asc` or `desc`. | |
| after | No | Earliest subreddit creation date: epoch, ISO date, or relative like `1year`. | |
| limit | No | Number of subreddits to return, 1-1000. | |
| before | No | Latest subreddit creation date, same formats as `after`. | |
| fields | No | Comma separated field allowlist to shrink the response. | |
| over18 | No | Filter on the NSFW flag. | |
| max_chars | No | Character budget for the rendered output. | |
| sort_type | No | `subscribers` (default), `created_utc`, or `subreddit`. | |
| subreddit | No | Exact subreddit name. | |
| max_subscribers | No | Only subreddits with at most this many subscribers. | |
| min_subscribers | No | Only subreddits with at least this many subscribers. | |
| subreddit_prefix | No | Match subreddits whose name starts with this. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable caveats about data freshness ('subscriber counts lag reality') and warns against reporting placeholder values. However, the second caveat about score/num_comments appears misplaced for a subreddit search tool, causing some confusion.
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 concise and front-loaded with purpose, but the second caveat about posts/comments is tangential and detracts from focus. Still, the core message is clear and efficiently stated.
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 search tool with 13 parameters and no output schema, the description covers the purpose and important data-freshness caveats, but does not describe return format (markdown default) or additional behavior. The misplaced caveat slightly reduces completeness, but overall it is adequate for basic usage.
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 every parameter is already documented in the schema. The tool description only maps high-level criteria (name, prefix, subscribers, age) to parameters but does not add new meaning beyond the schema, which serves as the 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 'Find subreddits by name, prefix, subscriber count or age' with a specific verb and resource, clearly distinguishing it from sibling tools that search posts or comments. This makes the tool's purpose immediately clear.
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 for subreddit lookups vs. posts/comments, but does not explicitly say 'use this instead of search_posts/search_comments'. The context from sibling names provides implicit guidance, but there are no stated exclusions or alternatives.
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.0get_commentsget_postsget_threadsearch_commentssearch_postssearch_subredditsScored across 6 tools
Each tool targets a distinct operation: get_thread retrieves a single post with its comment tree, get_posts and get_comments handle bulk lookups by ID, and the three search tools query posts, comments, and subreddits respectively. The purposes are clearly separated and the verbose caveats do not create ambiguity.
All tool names follow a consistent 'verb_noun' pattern, using 'get_' for direct ID-based retrieval and 'search_' for query-based discovery. The only minor deviation is 'get_thread' being singular while others are plural, but the pattern is otherwise uniform and predictable.
Six tools is well-scoped for a read-only Reddit client covering posts, comments, and subreddits through both direct access and search. Each tool serves a distinct purpose without unnecessary redundancy, fitting comfortably within the ideal 3-15 range.
The surface covers the core read operations: single-thread retrieval, bulk post/comment fetching, and searching across posts, comments, and subreddits. Minor gaps exist, such as no direct subreddit or user profile endpoint, but search_subreddits and search_comments with author can fill these needs effectively.
Reddit MCP server: search posts, subreddit feeds, comments & user profiles as JSON. No API key.
Reddit MCP — public Reddit data via JSON endpoints (no auth required)
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
