This server provides read-only Reddit tools to research communities, check posts and accounts, and guide posting — all through your own signed-in Chrome without Reddit API keys.
subreddit_rules: Get a subreddit's rules, size, description, and flagged self-promotion rules before posting.
find_communities: Search for subreddits about a topic, returning self-promotion rule flags and promo thread mentions.
account_check: Check a Reddit account's visibility, age, karma, and recent post removals (to detect shadowbans).
post_status: Check if a post is live, removed, or deleted, along with its score and comments.
threadfox_full_kit: Learn how to access the full ThreadFox kit (posting, replies, outcome ledger, course) with a license key.
Provides read-only tools for Reddit, allowing users to fetch subreddit rules, descriptions, and sizes, and check post status including live/removed/deleted states, scores, and comment counts.
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., "@threadfox-lite check the rules for r/startups before I post"
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.
Free, read-only Reddit tools for Claude Desktop, Claude Code, Codex and any MCP client, plus a reddit-rules-first agent skill.
subreddit_rules: a subreddit's rules, size and description, with the self-promotion rules flagged. Call it before writing a post.
find_communities: subreddits about a topic ("bakery marketing", "indie games"), each with its self-promotion rules flagged and whether it mentions a promo thread.
account_check: a Reddit account's age, karma and standing, and whether its recent posts are removed or hidden from search (the practical sign of a spam filter or shadowban).
post_status: whether a post is still live, removed by moderators or deleted, with score and comments. Check at 1, 6 and 24 hours.
threadfox_full_kit: what the full ThreadFox kit adds (finding conversations where people ask for what you sell, posting from your own Chrome, replies, an outcome ledger, a 12-module course).
Reads only, through your own signed-in Chrome. Reddit now sends every signed-out request, including its public JSON, to a login page, so ThreadFox Lite reads the way you do: in your Chrome, signed in as you, one small read at a time. It never posts, votes or changes anything, and needs no Reddit API keys. One-time setup: Microsoft's Playwright Extension in the Chrome where you are signed in to Reddit. Node.js is fetched for you if you don't have it (the official build from nodejs.org into ~/.threadfox/runtime, checked against its published SHA-256; nothing installed system-wide). It stays light on your computer: one Reddit read at a time across every ThreadFox app on the machine, and its Chrome connection closes after 10 idle minutes and never leaves background processes behind. The first read asks you to pick a tab in Chrome.
Claude Code plugin (the tools and the skill together):
/plugin marketplace add amflimited/threadfox-lite
/plugin install threadfox-lite@threadfoxClaude Code, the MCP server only:
claude mcp add threadfox-lite -- uvx threadfox-liteClaude Desktop: download the .mcpb file from the latest release and open it; if Windows asks which app should open it, choose Claude. Claude Desktop sets up Python for it by itself.
Codex (~/.codex/config.toml):
[mcp_servers.threadfox-lite]
command = "uvx"
args = ["threadfox-lite"]Any other MCP client: run uvx threadfox-lite (the package is on PyPI).
Bought ThreadFox on MCP Marketplace? Set MCP_LICENSE_KEY to your key, ask your AI to run threadfox_full_kit, or go straight to https://threadfox.vip/redeem.
Related MCP server: reddirect
skills/reddit-rules-first/SKILL.md works on its own in any agent that reads skills: rules first, one post per community, disclose, check what stayed up. Install it anywhere with npx skills add amflimited/threadfox-lite.
Also listed in the official MCP Registry as io.github.amflimited/threadfox-lite.
Made by AMF Indiana, the team behind ThreadFox (https://threadfox.vip). Built from our own run: 978,227 recorded views from two days of posts (Sept 20-21 UTC), with no ad spend. Not affiliated with Reddit, OpenAI or Anthropic. MIT licence.
Check a Reddit account before posting: whether other people can see it (not shadowbanned or suspended), its age and karma, and its recent posts with any removals.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states it checks visibility, age, karma, and recent posts but does not disclose potential limitations (e.g., whether it handles private accounts, rate limits, or how recent 'recent' is) or the exact output format. This is acceptable but shallow.
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, concise sentence that front-loads the purpose and then details what is checked. It wastes no words and is 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?
For a relatively simple tool with one parameter and no output schema, the description is fairly complete for basic usage. However, it lacks information on return format, error conditions (e.g., nonexistent username), or how this integrates with the posting workflow beyond 'before posting'.
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 0%, so the description must compensate for the single 'username' parameter. The description implies the username identifies the account but does not specify format, validity, or examples. Baseline for few parameters is moderate; it adds no meaningful detail beyond 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 clearly identifies the purpose: checking a Reddit account before posting, including visibility status, age/karma, and recent posts with removals. It distinguishes this from posting or community-finding tools, though it doesn't explicitly differentiate from siblings beyond context.
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 before posting ('before posting') and specifies what it checks, but it does not explicitly state when not to use it or name alternatives. With siblings like 'post_status' and 'threadfox_full_kit', additional guidance on when to choose this tool over them would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find subreddits about a topic, each with its self-promotion rules flagged and whether it mentions a promo thread. Use a few words, e.g. 'bakery marketing' or 'indie games'.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| topic | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that results include self-promotion rules and promo-thread mentions, which is useful behavioral output context. However, it doesn't disclose whether this is a read-only operation, rate limits, or what happens with no results. The description adds some value but not rich 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?
Two sentences with no filler. The core purpose is front-loaded, and the usage example is compact and immediately actionable. 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?
For a simple 2-parameter tool with no output schema, the description covers the main intent and topic phrasing. However, it lacks any mention of the 'limit' parameter's behavior, result ordering, or edge cases (e.g., no matches). It's adequate but has clear gaps.
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 the 'topic' parameter well with examples, but says nothing about 'limit' beyond its schema default. The description adds meaning for one of two parameters, leaving the other to the schema's minimal title/default.
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 ('Find') and resource ('subreddits about a topic'), and adds the distinctive output detail (self-promotion rules flagged, promo thread mention) that differentiates it from generic search tools. It doesn't explicitly name a sibling to distinguish from, but the topic-based search intent is 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 gives concrete usage guidance: 'Use a few words, e.g. 'bakery marketing' or 'indie games''. This tells the agent how to phrase the topic parameter. It doesn't explicitly state when not to use it or name alternatives, but the examples imply the intended query style.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a Reddit post is still live, removed by moderators or deleted, with its score and comments.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
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 states the tool checks live/removed/deleted status and returns score and comments, implying a read-only operation. However, it does not disclose whether authentication is required, what happens for invalid URLs, or whether there are rate limits. The description gives some insight but lacks completeness.
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, well-structured sentence that front-loads the core purpose. It contains no unnecessary words and is immediately understandable. It earns its place without fluff.
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 simple one-parameter tool, the description is mostly complete but lacks details about the exact return format or error behavior. Since there is no output schema, the description should clarify what 'with its score and comments' means precisely (e.g., status values, data types). This is a moderate gap but not fatal.
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 has one parameter, 'url', with no description. The tool description implies that the URL is the post URL, but it does not specify expected format (full URL, path, etc.) or any constraints. With 0% schema coverage, the description should compensate but only provides minimal implicit meaning. This is a notable gap.
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 ('Check') on a specific resource ('Reddit post') with specific outcomes (live, removed, deleted) and additional data (score, comments). This differentiates it from the sibling tools, which are unrelated (subreddit_rules, threadfox_full_kit). No 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 tool's purpose is so specific that an agent would naturally know when to use it. However, the description does not explicitly mention alternatives or conditions for when not to use it. Since the siblings are unrelated, this is less critical, but explicit guidance would improve it. Score 4 reflects clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a subreddit's rules, size and description, and flag the rules that mention self-promotion. Call this before writing any post for that community.
| Name | Required | Description | Default |
|---|---|---|---|
| subreddit | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly states it reads and flags rules mentioning self-promotion, which implies a safe, read-only operation. It doesn't disclose output format or permissions, but for a read tool, this is adequate and not misleading.
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 concise sentences with no waste. The primary action is front-loaded, and the usage instruction is a single clear directive. Perfectly sized.
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 simplicity (one parameter, read-only, no output schema), the description covers the essential behavior and usage. It doesn't explain return format, but since there is no output schema, that's not a required addition. The instruction to call before posting is valuable contextual guidance.
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 only parameter, 'subreddit', has a type and title but no description. Schema description coverage is 0%, and the description doesn't clarify the expected format (e.g., with or without 'r/'). The description adds no extra meaning beyond the schema, leaving the agent to infer the 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 uses a specific verb 'Read' and names the resource ('a subreddit's rules, size and description') and the specific action of flagging self-promotion mentions. It clearly distinguishes from the sibling tools post_status and threadfox_full_kit, which sound unrelated.
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 instructs when to use it: 'Call this before writing any post for that community.' This provides clear usage context, though it doesn't mention alternatives or exclusions. Since there are siblings, it doesn't explicitly route away from them, but the usage timing is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How to get the full ThreadFox kit: your AI reads the rules, writes a post that fits each community, publishes from your own Chrome, answers comments and records every outcome.
| Name | Required | Description | Default |
|---|---|---|---|
No 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 does disclose meaningful side effects: publishing from the user's own Chrome and answering comments, plus recording every outcome. But it skips prerequisites, reversibility, output handling, and failure behavior, so the side-effect profile is only partially 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?
The description is one compact sentence with the key idea front-loaded and the workflow steps in a readable sequence. The comma-separated list is slightly prose-y but contains 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 zero-parameter, no-output-schema tool, the description covers the high-level process but leaves integration details open: what 'get the kit' returns, how 'records every outcome' is stored or exposed, and how the AI should coordinate with the sibling tools. It is minimally sufficient, not fully specified.
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 description has no parameter documentation burden. The workflow list adds process context without needing to explain argument semantics.
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 names the resource ('full ThreadFox kit') and lists a workflow (reads rules, writes posts, publishes from Chrome, answers comments, records outcomes), so an agent can tell it covers an end-to-end process rather than a single utility. However, the opening phrase 'How to get...' restates the tool name and never explicitly states what invoking the tool does or returns. The differentiation from siblings is implied by 'full kit' but not stated.
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?
There is no explicit statement of when to use this tool versus subreddit_rules or post_status. An agent can infer that the full kit might subsume the sibling tools, but the description provides no conditions, exclusions, or alternative routing.
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.2.6account_checkfind_communitiesv0.1.0post_statussubreddit_rulesthreadfox_full_kitScored across 5 tools
Most tools target clearly distinct entities: account, community discovery, specific subreddit rules, and post status. The only mild overlap is between find_communities and subreddit_rules both touching rules, and account_check vs post_status both involving post removals, but their inputs and purposes are separated well enough.
All names are snake_case and readable, but the pattern is mixed: account_check and post_status are noun-based, find_communities is verb-first, subreddit_rules is a noun phrase, and threadfox_full_kit is a product name. There is no consistent verb_noun convention, but the style is not chaotic.
Five tools is a reasonable size for a focused Reddit helper server. One tool, threadfox_full_kit, is a promotional pointer to another product rather than a functional operation, which slightly reduces how well each tool earns its place.
The tools cover account health, community discovery, subreddit rules, and post status checking, but the workflow repeatedly references posting and writing posts, and there is no tool to actually create, edit, or delete a post. This is a significant gap for the apparent purpose of running a Reddit posting workflow.
Reddit MCP server: search posts, subreddit feeds, comments & user profiles as JSON. No API key.
Reddit MCP — public Reddit data via the Atom/RSS feeds.
Lemmy MCP — public reads on any Lemmy instance.
Browse and manage Reddit posts, comments, and threads. Fetch user activity, explore hot/new/rising…