reddit-mcp-server
This server lets you read Reddit content and, with authentication, create posts and replies.
Fetch a specific post or top posts from a subreddit, with time filtering.
Retrieve comments for a Reddit post.
Look up user info and a user’s posts/comments.
Get subreddit info and trending subreddits (trending requires OAuth).
Search Reddit for posts, subreddits, or users.
Create text/link posts and reply to existing posts; these writes require OAuth plus user credentials.
Test server status and configuration.
Most read tools can work keyless with limitations; writes and some tools require OAuth.
Provides tools for fetching content (posts, comments, user info, subreddit info) from Reddit and creating content (posts, replies) with appropriate credentials.
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., "@reddit-mcp-serverget top posts from r/technology from the past week"
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.
Reddit MCP Server
A Model Context Protocol (MCP) server for interacting with Reddit - fetch posts, comments, user info, and create content.
Reddit is closing its public API
Reddit announced on 2026-09-30 that it is ending RSS feeds and its public Data API, and moving apps to its Developer Platform (r/redditdev post, r/modnews post):
Date | What Reddit does |
2026-10-31 | Stops accepting new requests for public API access |
2026-11-13 | Stops supporting RSS feeds |
2027-01-12 | Starts removing API access for apps and users that haven't registered or responded to Reddit's outreach |
March 2027 | Closes public API access for all remaining apps and users |
What this server uses to keep working
The server reads from three sources and uses the best one you have:
Source | Needs | Used for | Lasts until |
Reddit's API (OAuth) |
| Every tool, with live data (writes also need username and password) | March 2027, per Reddit |
Reddit's RSS feeds | Nothing | Ranked listings (hot, top, rising, controversial) and the home feed, without credentials | 2026-11-13 |
Arctic Shift archive | Nothing | Most read tools without credentials | No announced end. It's free, run by one volunteer, has no uptime guarantee, and gets its data from Reddit's API |
Arctic Shift is a third-party copy of Reddit, not Reddit's API, though it collects its data through Reddit's API. Its scores and comment counts lag, and every result from it says so. See Keyless Mode for what each tool can do without credentials.
What it means for you
You have OAuth credentials: every read tool works. Write tools also need
REDDIT_USERNAMEandREDDIT_PASSWORD. Register your app at developers.reddit.com/app-registration before 2027-01-12, or Reddit may remove its access early.You don't have credentials: most read tools work with no setup. Reddit no longer accepts new API access requests, so new users run in keyless mode.
After 2026-11-13: without credentials, ranked listings for a single subreddit fall back to the archive's newest posts, because RSS is gone. The home feed and multireddits have no keyless source after that date.
After March 2027: Reddit says public API access closes, and that is the path the OAuth tools use, so the write tools and the OAuth-only reads stop working. Arctic Shift says it collects all its data through Reddit's API, so the archive may stop getting new posts then. Keyless reads would still return what it already holds.
Related MCP server: reddit-mcp
Features at a Glance
Feature | reddit-mcp-server | Other Reddit MCPs |
Create Posts | :white_check_mark: | :x: |
Reply to Posts/Comments | :white_check_mark: | :x: |
Edit Posts/Comments | :white_check_mark: | :x: |
Delete Posts/Comments | :white_check_mark: | :x: |
Spam Protection (Safe Mode) | :white_check_mark: | :x: |
Bot Disclosure Footer | :white_check_mark: | :x: |
Policy Compliance Built-in | :white_check_mark: | :x: |
Browse Subreddits | :white_check_mark: | :white_check_mark: |
Search Reddit | :white_check_mark: | :white_check_mark: |
User Analysis | :white_check_mark: | :white_check_mark: |
Post Comments | :white_check_mark: | :white_check_mark: |
OAuth Auth (60-100 rpm) | :white_check_mark: | :white_check_mark: |
Keyless mode (zero-setup) | :white_check_mark: | :x: |
Quick Start
Option 1: Claude Desktop Extension (Easiest)
Download and open the extension file - Claude Desktop will install it automatically:
Download reddit-mcp-server.mcpb
Option 2: NPX (No install required)
Add to your MCP config (Claude Desktop, Cursor, etc.). Credentials are optional: without them the server runs in keyless mode, and with them you get live data and every tool.
{
"mcpServers": {
"reddit": {
"command": "npx",
"args": ["reddit-mcp-server"],
"env": {
"REDDIT_CLIENT_ID": "your_client_id",
"REDDIT_CLIENT_SECRET": "your_client_secret"
}
}
}
}Option 3: Claude Code
REDDIT_CLIENT_ID=your_client_id REDDIT_CLIENT_SECRET=your_client_secret \
claude mcp add --transport stdio reddit -- npx reddit-mcp-serverLeave out the two variables to run keyless.
Features
Read-only Tools
Tool | Description |
| Get a specific Reddit post with engagement analysis |
| Get top posts from a subreddit or home feed |
| Browse a subreddit/home feed by sort (hot, new, top, rising, controversial) |
| Get comments from a specific post with threading |
| Expand collapsed comments in a thread |
| Get detailed information about a Reddit user |
| Get posts submitted by a specific user |
| Get comments made by a specific user |
| Get subreddit details and statistics |
| Get a subreddit's posting rules |
| Search for posts, subreddits, or users |
| Get currently trending subreddits (needs OAuth) |
| List a subreddit's available post flairs (needs OAuth) |
| Get your own account info (needs OAuth and user credentials) |
| Get your own recent posts and comments (needs OAuth and user credentials) |
| Get your saved posts and comments (needs OAuth and user credentials) |
| Check server status and configuration |
Most read tools also work without credentials. See Keyless Mode for each tool's limits.
Write Tools (Require User Credentials)
Write tools need Reddit's API, so they need OAuth credentials plus REDDIT_USERNAME and REDDIT_PASSWORD. Reddit closes its public API in March 2027 (details).
Tool | Description |
| Create a new post in a subreddit |
| Post a reply to an existing post or comment |
| Edit your own Reddit post (self-text only) |
| Edit your own Reddit comment |
| Save a post or comment to your account |
| Remove a post or comment from your saved items |
| Permanently delete your own post |
| Permanently delete your own comment |
Configuration
Environment Variables
Variable | Required | Default | Description |
| No | - | Reddit app client ID (omit for keyless mode) |
| No | - | Reddit app client secret |
| No | - | Reddit username (for write operations) |
| No | - | Reddit password (for write operations) |
| No | Auto-generated | Custom User-Agent string |
| No |
| Authentication mode: |
| No |
| Write safeguards: |
| No |
| Bot disclosure footer: |
| No | Built-in | Custom bot footer text (when disclosure is |
| No |
| In-memory caching of read requests: |
| No |
| Cache size cap in MB (LRU eviction beyond this) |
| No |
| Retries on HTTP 429 with Retry-After backoff ( |
Credentials are optional. See Keyless Mode for what works without them.
Full MCP Config Example
{
"mcpServers": {
"reddit": {
"command": "npx",
"args": ["reddit-mcp-server"],
"env": {
"REDDIT_CLIENT_ID": "your_client_id",
"REDDIT_CLIENT_SECRET": "your_client_secret",
"REDDIT_USERNAME": "your_username",
"REDDIT_PASSWORD": "your_password",
"REDDIT_SAFE_MODE": "standard"
}
}
}
}Safe Mode (Spam Protection)
Protect your Reddit account from spam detection and bans with built-in safeguards. Enabled by default (standard mode) per Reddit's Responsible Builder Policy.
Why Use Safe Mode?
Reddit's spam detection can flag accounts for:
Rapid posting or commenting
Duplicate or similar content
Posting the same content across multiple subreddits
Non-standard User-Agent strings
Safe Mode helps prevent these issues automatically.
Mode Options
Mode | Write Delay | Duplicate Detection | Use Case |
| None | No | Explicit opt-out only |
| 2 seconds | Last 10 items + cross-sub | Default, recommended |
| 5 seconds | Last 20 items + cross-sub | For cautious automated posting |
Disable Safe Mode
Safe mode is enabled by default. To explicitly disable:
export REDDIT_SAFE_MODE=off
npx reddit-mcp-serverWhat Safe Mode Does
Rate Limiting: Enforces minimum delays between write operations
Duplicate Detection: Blocks identical content from being posted twice
Cross-Subreddit Detection: Prevents posting the same content to multiple subreddits (per Reddit policy)
Smart User-Agent: Auto-generates Reddit-compliant User-Agent format when username is provided
Bot Disclosure
Reddit's Responsible Builder Policy requires bots to disclose their automated nature. Enable automatic bot footers on all posted content:
export REDDIT_BOT_DISCLOSURE=auto
npx reddit-mcp-serverWhen enabled, a footer is appended to all posts, replies, and edits:
---
🤖 I am a bot | Built with reddit-mcp-serverCustomize the footer with REDDIT_BOT_FOOTER:
export REDDIT_BOT_DISCLOSURE=auto
export REDDIT_BOT_FOOTER=$'\n\n---\n^(🤖 Custom bot footer text)'Authentication
⚠️ Reddit API Changes (2026)
Reddit's unauthenticated API no longer works. As of mid-2026, Reddit blocks unauthenticated API requests with HTTP 403, so reading Reddit's API needs OAuth credentials. REDDIT_AUTH_MODE=anonymous still exists, but it is now an alias for keyless mode.
Reddit is closing its public API. See Reddit is closing its public API for the dates and what this server does about them.
Reddit closed self-service OAuth app creation in November 2025, and as of 2026-10-31 it accepts no new requests for public API access. Existing OAuth credentials keep working until March 2027 if the app is registered by 2027-01-12. Reddit starts removing access for unregistered apps on that date.
Getting Credentials
If you already have a Reddit app (created at /prefs/apps before November 2025, or approved through Reddit's Developer Support): use your existing client ID and secret. They still work at 60-100 req/min. Register the app at developers.reddit.com/app-registration before 2027-01-12.
If you don't have credentials: Reddit no longer accepts new requests for public API access, so use keyless mode.
Mode Comparison
Mode | Rate Limit | Setup Required | Tools Available | Best For |
| 60-100 req/min | OAuth credentials | All tools | Most users |
| 60-100 req/min | OAuth credentials | All tools | Explicit mode |
| Shared, free | None | Most read tools (Keyless Mode) | New users |
| Shared, free | None | Same as | Legacy alias |
Keyless Mode
Without OAuth credentials, reads come from two free sources:
Reddit's RSS feeds for ranked listings (
hot,top,rising,controversial, and the home feed). Reddit retires RSS on 2026-11-13. When a feed fails for a named subreddit, the server falls back to the archive's newest posts and says ranking is unavailable.The Arctic Shift archive, a free third-party copy of Reddit run by one volunteer. It is not Reddit's API and has no uptime guarantee.
Tool | Keyless source | Limits |
| Arctic Shift | One subreddit; no multireddits |
| RSS, then Arctic Shift | Archive fallback is newest-first, not ranked |
| Arctic Shift | |
| Arctic Shift | Recent comments may be missing; no sort |
| Arctic Shift | |
| Arctic Shift | Account age estimated from first activity; status flags unknown |
| Arctic Shift | Newest first only |
| Arctic Shift | |
| Arctic Shift | Posts need |
Archive caveats: scores and comment counts lag, and are often 0 or 1 on recent posts. Keyword search on large subreddits is slow, and the archive throttles it. The server waits up to 10 seconds and retries once. If that fails too, the error says when to retry. Every archive result ends with a note naming the source.
Still needs OAuth: get_trending_subreddits, get_post_flairs, get_me, get_my_overview, get_my_saved, search_reddit with type=user, and all write tools.
Read-Only Access (OAuth)
{
"env": {
"REDDIT_CLIENT_ID": "your_client_id",
"REDDIT_CLIENT_SECRET": "your_client_secret"
}
}Write Operations (OAuth + User Credentials)
To create posts, reply, edit, or delete content, add your Reddit username and password:
{
"env": {
"REDDIT_CLIENT_ID": "your_client_id",
"REDDIT_CLIENT_SECRET": "your_client_secret",
"REDDIT_USERNAME": "your_username",
"REDDIT_PASSWORD": "your_password",
"REDDIT_SAFE_MODE": "standard"
}
}Development
Commands
pnpm install # Install dependencies
pnpm build # Build TypeScript
pnpm dev # Rebuild on every change
pnpm inspect # Build and open the MCP inspector
pnpm validate # Format, lint, typecheck, test and build
pnpm test # Run tests
pnpm lint # Lint code
pnpm format # Format codeCLI Options
npx reddit-mcp-server --version # Show version
npx reddit-mcp-server --help # Show helpHTTP Server Mode
For Docker deployments or web-based clients, use HTTP transport:
TRANSPORT_TYPE=httpStream PORT=3000 node dist/index.jsThe MCP endpoint is Streamable HTTP at
/mcp. Version 2.0 removed the legacy SSE endpoint (/sse) and/ready.The server binds
127.0.0.1unless you setHOST. The Docker image setsHOST=0.0.0.0./healthanswers{"name":"reddit-mcp-server","status":"running"}and needs no token.
With OAuth Protection
export OAUTH_ENABLED=true
export OAUTH_TOKEN=$(openssl rand -hex 32)
TRANSPORT_TYPE=httpStream node dist/index.jsIf OAUTH_TOKEN is unset or empty, the server generates one and prints it at startup. Make authenticated requests:
curl -H "Authorization: Bearer $OAUTH_TOKEN" \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' \
http://localhost:3000/mcpA request with no token gets 401, and a wrong token gets 403.
Docker
Quick Start
# Pull and run
docker pull ghcr.io/jordanburke/reddit-mcp-server:latest
docker run -d \
--name reddit-mcp \
-p 3000:3000 \
-e REDDIT_CLIENT_ID=your_client_id \
-e REDDIT_CLIENT_SECRET=your_client_secret \
-e REDDIT_SAFE_MODE=standard \
ghcr.io/jordanburke/reddit-mcp-server:latestLeave out the two credential variables to run the container keyless.
Docker Compose
services:
reddit-mcp:
image: ghcr.io/jordanburke/reddit-mcp-server:latest
ports:
- "3000:3000"
environment:
- REDDIT_CLIENT_ID=${REDDIT_CLIENT_ID}
- REDDIT_CLIENT_SECRET=${REDDIT_CLIENT_SECRET}
- REDDIT_USERNAME=${REDDIT_USERNAME}
- REDDIT_PASSWORD=${REDDIT_PASSWORD}
- REDDIT_SAFE_MODE=standard
- OAUTH_ENABLED=${OAUTH_ENABLED:-false}
# Unset or empty: the server generates a token and prints it at startup
- OAUTH_TOKEN=${OAUTH_TOKEN}
restart: unless-stoppedBuild Locally
docker build -t reddit-mcp-server .
docker run -d --name reddit-mcp -p 3000:3000 --env-file .env reddit-mcp-serverReddit Responsible Builder Policy
This server is designed with Reddit's Responsible Builder Policy in mind:
Safe mode on by default — rate limiting and duplicate detection prevent spam
Cross-subreddit duplicate detection — blocks identical content across subreddits
Bot disclosure support — optional automated footer for transparency
No voting/karma manipulation — upvote/downvote tools are intentionally excluded
No private messaging — DM tools are intentionally excluded
Policy-aware AI instructions — MCP server instructions remind AI assistants of data usage restrictions
Credits
Fork of reddit-mcp-server by Alexandros Lekkas
Inspired by Python Reddit MCP Server by Arindam200
Available Tools
12 toolscreate_postC
Create a new post in a subreddit
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Content of the post (text for self posts, URL for link posts) | |
| is_self | No | Whether this is a self (text) post (true) or link post (false) | |
| subreddit | Yes | Name of the subreddit to post in | |
| title | Yes | Title of the post |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions creation but fails to describe critical behaviors like authentication requirements, rate limits, error conditions (e.g., invalid subreddit), or what happens upon success (e.g., returns a post ID). This leaves significant gaps for an agent to understand how to use it safely and effectively.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly.
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 complexity of a creation tool with no annotations and no output schema, the description is inadequate. It doesn't cover behavioral aspects like authentication, error handling, or return values, leaving the agent with insufficient information to use the tool correctly in 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%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond implying 'subreddit' and 'post' context, which is minimal value. Baseline 3 is appropriate as the schema does the heavy lifting.
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 action ('Create') and target resource ('new post in a subreddit'), making the purpose immediately understandable. However, it doesn't distinguish this tool from potential alternatives like 'reply_to_post' or specify what type of post (text vs. link) beyond what the schema indicates, preventing a perfect score.
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 no guidance on when to use this tool versus alternatives like 'reply_to_post' or 'search_reddit', nor does it mention prerequisites such as authentication or subreddit permissions. It simply states what the tool does without contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_post_commentsC
Get comments for a specific Reddit post
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of comments to load | |
| post_id | Yes | The ID of the post | |
| sort | No | Comment sort order: best, top, new, controversial, old, qa | best |
| subreddit | Yes | The subreddit where the post is located |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the basic function without mentioning rate limits, authentication requirements, pagination behavior, error conditions, or what format the comments are returned in. This leaves significant gaps in understanding how the tool behaves in practice.
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 purpose without any wasted words. It's appropriately sized for a straightforward retrieval tool and gets directly to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns, how comments are structured, whether there are authentication requirements, or any limitations. The agent would need to guess about important behavioral aspects when invoking this 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?
The description mentions 'for a specific Reddit post' which hints at the 'post_id' parameter, but doesn't explain any parameters beyond what's already documented in the schema. With 100% schema description coverage, the baseline score of 3 is appropriate since the schema does the heavy lifting of parameter documentation.
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 action ('Get comments') and target resource ('for a specific Reddit post'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'get_user_comments' or 'reply_to_post', which would require explicit comparison to earn a perfect score.
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 no guidance on when to use this tool versus alternatives like 'get_user_comments' or 'get_reddit_post'. It lacks any context about prerequisites, limitations, or appropriate scenarios, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_reddit_postC
Get a Reddit post
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | The ID of the post to fetch | |
| subreddit | Yes | The subreddit to fetch posts from |
TDQS
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. 'Get a Reddit post' implies a read-only operation, but it doesn't specify authentication requirements, rate limits, error handling, or what data is returned (e.g., title, body, upvotes). For a tool with zero annotation coverage, this leaves critical behavioral aspects undocumented.
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 extremely concise ('Get a Reddit post')—a single sentence with no wasted words. It's front-loaded with the core action. However, this brevity comes at the cost of completeness, as it omits necessary context for effective tool selection and use.
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 moderate complexity (2 required parameters, no output schema, and no annotations), the description is incomplete. It doesn't address return values, error cases, or how it differs from siblings. While the schema covers parameters, the lack of behavioral and contextual information makes this inadequate for a tool in a server with many similar alternatives.
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 clear descriptions for both parameters ('post_id' and 'subreddit'). The description adds no additional meaning beyond what the schema provides—it doesn't explain parameter relationships (e.g., that 'post_id' might be relative to 'subreddit') or usage nuances. With high schema coverage, 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 'Get a Reddit post' clearly states the verb ('Get') and resource ('Reddit post'), making the basic purpose understandable. However, it doesn't differentiate this tool from similar siblings like 'get_post_comments' or 'get_top_posts', which also retrieve Reddit content. The description is functional but lacks specificity about what exactly is retrieved (e.g., post metadata, content, or both).
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 no guidance on when to use this tool versus alternatives. With siblings like 'get_post_comments' (for comments), 'get_top_posts' (for popular posts), and 'search_reddit' (for broader searches), there's no indication that this tool is specifically for fetching a single post by ID. The agent must infer usage from the parameter names alone, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subreddit_infoC
Get information about a subreddit
| Name | Required | Description | Default |
|---|---|---|---|
| subreddit_name | Yes | Name of the subreddit |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It doesn't disclose behavioral traits such as whether this is a read-only operation (implied by 'Get' but not stated), rate limits, authentication needs, error handling, or what happens if the subreddit doesn't exist. The description is minimal and lacks essential context for safe and effective use.
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, efficient sentence with zero waste. It's appropriately sized for a simple tool and front-loaded with the core purpose. Every word earns its place, making it easy to parse quickly.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what information is returned (e.g., description, subscriber count, rules), potential errors, or usage constraints. For a tool with no structured data beyond the input schema, more context is needed to guide the agent effectively.
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 description adds no meaning beyond the input schema, which has 100% coverage for the single parameter 'subreddit_name'. The schema already describes it as 'Name of the subreddit', so the description doesn't compensate or provide additional context like format examples (e.g., 'programming' without 'r/'). Baseline 3 is appropriate as the schema does the heavy lifting.
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 'Get information about a subreddit' states a clear verb ('Get') and resource ('subreddit'), but it's vague about what specific information is retrieved. It distinguishes from siblings like 'get_top_posts' or 'get_trending_subreddits' by focusing on subreddit metadata rather than content, but lacks specificity about the scope of information.
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?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't clarify if this should be used before posting to check subreddit rules versus using 'get_top_posts' for content discovery, or how it differs from 'get_user_info' for user-specific data. The description implies usage for subreddit metadata but offers no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_top_postsC
Get top posts from a subreddit
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of posts to fetch | |
| subreddit | Yes | Name of the subreddit | |
| time_filter | No | Time period to filter posts (e.g. 'day', 'week', 'month', 'year', 'all') | week |
TDQS
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 states the tool 'gets' data, implying a read-only operation, but doesn't mention potential rate limits, authentication requirements, pagination, or what 'top' entails (e.g., sorting criteria). The description is minimal and misses key behavioral traits needed for safe and effective use.
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, efficient sentence with no wasted words, making it easy to parse. However, it's front-loaded but overly brief, potentially sacrificing clarity for brevity. It earns a high score for conciseness but loses a point because the minimalism might hinder understanding without additional context.
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 moderate complexity (3 parameters, no output schema, no annotations), the description is incomplete. It lacks details on behavioral aspects like rate limits or authentication, doesn't explain the output format (e.g., what data is returned for posts), and offers no usage guidelines. While the schema covers parameters well, the overall context for an agent to use the tool effectively is insufficient.
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 clear descriptions for all parameters (limit, subreddit, time_filter) including defaults and enum values. The description adds no additional parameter semantics beyond what the schema provides, such as explaining 'top' in relation to parameters. Since the schema is comprehensive, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 'Get top posts from a subreddit' clearly states the action (get) and resource (top posts from a subreddit), but it's somewhat vague about what 'top' means (e.g., by upvotes, hotness) and doesn't explicitly distinguish this tool from siblings like 'get_reddit_post' (which might fetch a specific post) or 'search_reddit' (which might allow broader queries). It avoids tautology but lacks specificity for full differentiation.
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 no guidance on when to use this tool versus alternatives. It doesn't mention siblings like 'get_reddit_post' for individual posts or 'search_reddit' for custom searches, nor does it specify prerequisites or exclusions (e.g., whether it requires authentication). Usage is implied by the name but not explicitly stated, leaving gaps for an agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_trending_subredditsB
Get currently trending subreddits
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool does ('Get currently trending subreddits') without detailing aspects like rate limits, authentication requirements, data freshness, or return format (e.g., list structure, pagination). This leaves significant gaps in understanding how the tool behaves in practice.
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, clear sentence with no wasted words. It is front-loaded with the core purpose ('Get currently trending subreddits'), making it easy to scan and understand quickly. Every part of the sentence earns its place by conveying essential 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'trending' means (e.g., based on views, upvotes, time frame), the format of the returned data, or any limitations (e.g., number of results). For a tool that fetches dynamic data, more context is needed to use it effectively.
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 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. A baseline score of 4 is applied since no parameters exist, and the description doesn't introduce confusion by referencing non-existent parameters.
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 action ('Get') and target resource ('currently trending subreddits'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_top_posts' or 'get_subreddit_info', which might also retrieve subreddit-related information, so it doesn't reach the highest score.
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 no guidance on when to use this tool versus alternatives. For example, it doesn't clarify if this is for real-time trends versus historical data, or how it differs from 'get_top_posts' or 'search_reddit'. Without such context, users might struggle to select the appropriate tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_user_commentsC
Get comments made by a specific user
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of comments to return | |
| sort | No | Sort order: new, hot, top, controversial | new |
| time_filter | No | Time filter for top/controversial: hour, day, week, month, year, all | all |
| username | Yes | The username to get comments for |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Get') but doesn't cover critical traits like whether this is a read-only operation, potential rate limits, authentication needs, or what the return format looks like (e.g., list of comments with metadata). This leaves significant gaps for an agent to understand the tool's behavior.
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, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 complexity of a tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the return values, error conditions, or behavioral nuances, leaving the agent with insufficient context to use the tool effectively beyond basic parameter input.
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 input schema has 100% description coverage, clearly documenting all 4 parameters (username, limit, sort, time_filter) with defaults, enums, and constraints. The description adds no additional meaning beyond the schema, so it meets the baseline of 3 for adequate coverage without extra 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 clearly states the verb ('Get') and resource ('comments made by a specific user'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get_post_comments' or 'get_user_posts', which also retrieve comments or user content, so it misses full sibling distinction.
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 no guidance on when to use this tool versus alternatives like 'get_user_posts' or 'get_post_comments'. It lacks context on prerequisites, such as needing a valid username, and doesn't mention any exclusions or specific use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_user_infoC
Get information about a Reddit user
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | The username of the Reddit user to get info for |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It doesn't indicate whether this is a read-only operation, what permissions might be required, whether there are rate limits, what kind of information is returned, or if there are any constraints on which users can be queried. 'Get information' implies a read operation but provides no behavioral context beyond that basic inference.
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, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a simple lookup tool and front-loads the essential information. Every word earns its place in this minimal but complete statement of function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what information is returned about users, whether there are limitations on which users can be queried, or what format the response takes. Given the lack of structured metadata, the description should provide more context about the tool's behavior and output.
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 description doesn't mention any parameters, but the input schema has 100% description coverage with a single well-documented 'username' parameter. Since the schema fully documents the parameter, the baseline score of 3 is appropriate. The description adds no additional parameter semantics beyond what's already in 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 states the action ('Get information') and target resource ('about a Reddit user'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'get_user_comments' or 'get_user_posts' - all three retrieve user-related data but this one is more general. The description is specific enough to understand what it does but lacks sibling differentiation.
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 no guidance on when to use this tool versus alternatives. With sibling tools like 'get_user_comments', 'get_user_posts', and 'get_subreddit_info' available, there's no indication whether this tool provides comprehensive user profile data, basic metadata, or something else. The agent must infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_user_postsC
Get posts submitted by a specific user
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of posts to return | |
| sort | No | Sort order: new, hot, top, controversial | new |
| time_filter | No | Time filter for top/controversial: hour, day, week, month, year, all | all |
| username | Yes | The username to get posts for |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe important behaviors: whether this is a read-only operation, if there are rate limits, what authentication is required, what happens with invalid usernames, or the format/structure of returned posts. For a tool with 4 parameters and no annotation coverage, this is a significant gap.
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, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a straightforward retrieval tool and front-loads the essential information. Every word 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?
Given the tool has 4 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what kind of posts are returned (e.g., titles, content, metadata), whether results are paginated, error conditions, or authentication requirements. For a data retrieval tool with multiple filtering options, more context is needed.
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 schema already fully documents all 4 parameters with descriptions, defaults, enums, and constraints. The description adds no additional parameter semantics beyond implying the 'username' parameter is required (which is already in the schema). Baseline 3 is appropriate when the schema does all the heavy lifting.
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 verb 'Get' and resource 'posts submitted by a specific user', making the purpose immediately understandable. It distinguishes from siblings like get_user_comments (which gets comments) and get_top_posts (which gets posts by popularity rather than by user). However, it doesn't specify whether this includes all types of posts or just certain categories, which prevents a perfect score.
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 no guidance on when to use this tool versus alternatives. It doesn't mention when to choose get_user_posts over get_user_info (which might include post summaries) or search_reddit (which could filter by user), nor does it specify prerequisites like needing a valid username. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reply_to_postC
Post a reply to an existing Reddit post
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The content of the reply | |
| post_id | Yes | The ID of the post to reply to | |
| subreddit | No | The subreddit name if known (for validation) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Post a reply' implies a write/mutation operation, it doesn't disclose authentication requirements, rate limits, error conditions, or what happens upon success. For a mutation tool with zero annotation coverage, this minimal description leaves critical behavioral aspects unspecified.
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, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a straightforward tool and gets directly to the point. Every word earns its place in this minimal but complete statement of function.
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 this is a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address authentication needs, rate limits, error handling, or what the tool returns. With 3 parameters and complex Reddit API interactions likely involved, more context about behavioral expectations would be helpful for an AI agent.
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 schema already documents all three parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema. It doesn't explain parameter relationships, format requirements, or usage patterns. The baseline of 3 is appropriate when the schema does all the parameter documentation work.
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 action ('Post a reply') and target resource ('to an existing Reddit post'), making the purpose immediately understandable. It distinguishes from siblings like 'create_post' by specifying it's for replying rather than creating new posts. However, it doesn't explicitly differentiate from other comment/reply-related tools that might exist.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like authentication), when not to use it, or how it differs from similar operations. With multiple sibling tools available, this lack of contextual guidance is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_redditC
Search for posts on Reddit
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return | |
| query | Yes | The search query | |
| sort | No | Sort order: relevance, hot, top, new, comments | relevance |
| subreddit | No | Search within a specific subreddit (optional) | |
| time_filter | No | Time filter: hour, day, week, month, year, all | all |
| type | No | Type of content: link (posts), sr (subreddits), user (users) | link |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Search for posts' implies a read-only operation, but it doesn't mention rate limits, authentication needs, pagination behavior, or what happens when no results are found. For a search tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a search tool and front-loads the core functionality without unnecessary elaboration.
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 6 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the search returns (e.g., post metadata, content snippets), error conditions, or how results are structured. The agent must rely entirely on the input schema for parameter details without 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?
Schema description coverage is 100%, with all 6 parameters well-documented in the schema itself (e.g., 'limit' with min/max, 'sort' with enum values). The description adds no parameter information beyond what's in the schema, so it meets the baseline for high schema coverage without compensating 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 'Search for posts on Reddit' clearly states the verb ('Search') and resource ('posts on Reddit'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_top_posts' or 'get_reddit_post' that also retrieve posts, missing full sibling distinction.
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 no guidance on when to use this tool versus alternatives like 'get_top_posts' (for trending content) or 'get_reddit_post' (for specific posts). There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
test_reddit_mcp_serverD
Test the Reddit MCP Server
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Test' implies some diagnostic or validation operation, but the description doesn't reveal what gets tested, what side effects occur, whether authentication is needed, or what the expected output might be. It provides no behavioral context beyond the vague verb.
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 extremely concise at just 5 words, but this brevity comes at the cost of being under-specified rather than efficient. While it's front-loaded with the only information provided, the single sentence fails to earn its place by not conveying meaningful guidance. It's more minimal than optimally concise.
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 no annotations, no output schema, and a completely uninformative description, the contextual information is severely inadequate. The description provides no insight into what 'testing' entails, what results to expect, or how this tool fits within the Reddit MCP ecosystem alongside its 11 sibling tools. This leaves critical gaps for tool understanding and invocation.
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 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description doesn't need to compensate for any parameter gaps. While it doesn't add any parameter information beyond what the schema provides, the baseline for zero parameters with full coverage is appropriately set at 4.
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 'Test the Reddit MCP Server' is a tautology that restates the tool name without specifying what action it performs. It doesn't identify a specific verb or resource, nor does it distinguish this tool from its siblings like create_post or get_subreddit_info. The purpose remains vague and unhelpful for tool selection.
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 no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, leaving the agent with no information about appropriate usage scenarios. This is particularly problematic given there are 11 sibling tools with clear purposes like get_user_info or search_reddit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
12 tool updates
v1.0.0- First observed
create_post - First observed
get_post_comments - First observed
get_reddit_post - First observed
get_subreddit_info - First observed
get_top_posts - First observed
get_trending_subreddits - First observed
get_user_comments - First observed
get_user_info - First observed
get_user_posts - First observed
reply_to_post - First observed
search_reddit - First observed
test_reddit_mcp_server
TDQS
Scored across 12 tools
Most tools have distinct purposes targeting different Reddit resources like posts, comments, subreddits, and users, with clear action separation. However, 'get_post_comments' and 'get_reddit_post' could potentially overlap in retrieving post-related data, causing minor ambiguity if an agent needs both post details and comments simultaneously.
Tool names follow a consistent verb_noun pattern using snake_case throughout, such as 'get_subreddit_info' and 'create_post', which aids predictability. The only deviation is 'test_reddit_mcp_server', which breaks the pattern by including 'server' and serving a meta-purpose, but this is a minor inconsistency in an otherwise uniform set.
With 12 tools, the count is well-scoped for a Reddit API server, covering core functionalities like posting, reading, searching, and user/subreddit interactions. Each tool appears to earn its place by addressing a specific aspect of Reddit's domain without being overly bloated or sparse.
The tool set provides comprehensive coverage for reading and basic interaction on Reddit, including CRUD-like operations for posts and comments, user and subreddit info retrieval, and search capabilities. Minor gaps exist, such as no tools for updating or deleting posts/comments or managing user settings, but agents can likely work around these for most common workflows.
Maintenance
Related MCP Connectors
BGG MCP provides access to the BoardGameGeek API through the Model Context Protocol, enabling retr…
Reddit API as MCP tools: search, subreddits, posts, comments, users, monitors, webhooks, feedback.
Browse and manage Reddit posts, comments, and threads. Fetch user activity, explore hot/new/rising…
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Related MCP Servers
- AlicenseNot gradedqualityFmaintenance⚙️ A Model Context Protocol (MCP) that provides tools for fetching and creating Reddit content2,233 npm1MIT
- AlicenseNot gradedqualityDmaintenanceProvides access to public Reddit data through tools for searching subreddits, viewing posts, and reading comments without requiring authentication. It enables Model Context Protocol clients to interact with Reddit's public JSON API via stdio or HTTP transports.10 npmMIT
- AlicenseNot gradedqualityDmaintenanceEnables fetching and reading Reddit content such as posts, comments, and subreddit listings via the MCP protocol.10 npmMIT
- AlicenseNot gradedqualityDmaintenanceA read-only MCP server that connects to the Reddit Data API to search posts, browse subreddits, read comments, view user profiles, and check trending content through the Model Context Protocol.74 npm2MIT