reddirect
reddirect is a Reddit MCP server that lets you browse and interact with Reddit without API keys. Write operations require a one-time browser login.
Authentication
check_session– view current login status (anonymous or logged in)authorize– one-time browser login to enable write operations
Browse & Read
browse_subreddit– view posts sorted by hot, new, top, rising, or controversial (with time filters)get_post– fetch a full post with its comment tree (flat, depth-annotated)search_reddit– search globally or within a specific subredditget_subreddit_info– view description, rules, subscriber count, and NSFW statusget_flairs– retrieve available post flairs for a subredditget_user_profile– see karma breakdown and account age for any user
Write & Edit
create_post– submit text or link posts with optional flaircrosspost– crosspost an existing post to another subredditreply– reply to any post or commentedit_content– edit your own posts or commentsdelete_content– delete your own posts or comments
Engagement
vote– upvote, downvote, or remove a votesave_item/unsave_item– save or remove posts and commentsget_saved_items– retrieve your saved posts and comments
Account Management
get_inbox– view messages, mentions, and replies (filterable by type)mark_inbox_read– mark all unread messages as readget_subscriptions– list subscribed subredditssubscribe_subreddit/unsubscribe_subreddit– manage subreddit subscriptions
Queue
queue_action– enqueue write actions with randomized delaysqueue_status– check progress of queued actionsqueue_cancel– cancel a queued action
Allows browsing, posting, commenting, voting, and managing Reddit account without API keys.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@reddirectshow me the top 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.
reddirect
Reddit MCP Server - No API Keys Required
Browse, post, comment, vote, and queue actions with timed delays from any MCP client. No API keys. Just install and go.
Why reddirect?
Every other Reddit MCP server requires you to register an app, get API keys, and configure OAuth. reddirect doesn't. It uses Reddit's public OAuth for reads and a one-time browser login for writes - zero setup friction.
Other Reddit MCPs | reddirect | |
API keys | Required | Not needed |
App registration | Required | Not needed |
OAuth setup | Required | Not needed |
Password stored | In config file | Never stored |
Install time | 10+ minutes | 30 seconds |
Related MCP server: reddit-rss-mcp
Quick Start
1. Install
npm install -g reddirect2. Add to your MCP client
Add to your MCP client configuration:
{
"mcpServers": {
"reddirect": {
"command": "npx",
"args": ["-y", "reddirect"]
}
}
}3. Use it
Reads work immediately - browse subreddits, search posts, check profiles.
For writes, run the authorize tool once. A Chrome window opens, you log into Reddit, and it closes automatically. That's it.
Tools
Tool | Description |
| Check auth status - anonymous or logged in |
| One-time browser login for write access |
Tool | Description |
| Browse posts with sort (hot / new / top / rising / controversial) and time filters |
| Fetch a post with flat, depth-annotated comment tree |
| Search globally or within a subreddit |
| Get description, rules, subscriber count |
| Get available post flairs for a subreddit (IDs and text) |
| Get karma breakdown and account age |
Tool | Description |
| Create text or link posts with optional flair (supports flair ID and text) |
| Share an existing post to a different subreddit (auto-fetches original title) |
| Reply to a post or comment |
| Edit your own posts or comments |
| Delete your own posts or comments |
Tool | Description |
| Upvote, downvote, or remove vote |
| Save a post or comment |
| Remove from saved items |
| List your saved items |
Tool | Description |
| View messages, mentions, and replies |
| Mark all unread as read |
| List subscribed subreddits |
| Subscribe to a subreddit |
| Unsubscribe from a subreddit |
Tool | Description |
| Enqueue any write operation with a randomized delay (default 2-3 min) |
| Check progress of queued items - pending, processing, completed, or failed |
| Cancel a specific queued item or clear the entire queue |
Space out multiple write operations with natural, randomized timing. Enqueue posts, replies, votes, or any write action - they execute sequentially with configurable delays between each.
How It Works
┌─────────────────────────────────────────────┐
│ MCP Client │
│ (Any MCP Client) │
└──────────────────┬──────────────────────────┘
│ stdio
┌──────────────────▼──────────────────────────┐
│ reddirect │
│ │
│ Reads ──► Anonymous OAuth ──► reddit API │
│ Writes ─► User token (JWT) ──► reddit API │
└─────────────────────────────────────────────┘Reads use Reddit's public installed_client OAuth grant - no credentials needed.
Writes use a token_v2 JWT extracted from a one-time Chrome login via the DevTools Protocol. No passwords are stored. The token lasts ~24 hours.
Requirements
Node.js 18+
Google Chrome - only needed once for the
authorizestep (not needed for reads)
Troubleshooting
Problem | Fix |
Writes say "authentication required" | Run the |
Chrome window doesn't appear | Make sure Google Chrome is installed |
"Server error" during login | Reddit rate limit - wait 10 minutes |
Session expired | Run |
Want to reset session | Delete |
License
MIT - License
Available Tools
20 toolsauthorizeAuthorize Reddit AccountA
One-time authorization: opens Reddit in your browser to connect your account. You click 'Allow', and reddirect gets permanent access. No API keys or passwords stored. Only needs to be done once.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, description details that it opens Reddit in browser, requires user click 'Allow', grants permanent access, and stores no API keys or passwords. This fully discloses the interactive nature and security posture.
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 efficient sentences with front-loaded key information. No wasted words.
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 parameters and no output schema, description covers the process, security, and one-time nature. Could mention that other tools become usable after authorization, but not essential.
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?
No parameters (schema coverage 100%), so baseline 4. Description adds value by explaining the authorization process and that no credentials are stored, which is helpful context beyond the empty 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?
Clearly states it's a one-time authorization tool to connect Reddit account, opens browser, permanent access. Distinguishes from all sibling tools which are Reddit actions, not authorization.
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?
Explicitly says 'One-time authorization' and 'Only needs to be done once', implying it's a prerequisite. However, does not explicitly state when to use versus alternatives, though context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
browse_subredditBrowse SubredditA
Browse posts from a subreddit with sort options (hot, new, top, rising, controversial). For top and controversial, you can specify a time range.
| Name | Required | Description | Default |
|---|---|---|---|
| subreddit | Yes | Subreddit name without r/ prefix | |
| sort | No | Sort order for posts | hot |
| time | No | Time range filter (only for top and controversial) | |
| limit | No | Number of posts to return |
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 does not mention read-only nature, authentication requirements, rate limits, or error handling. Only parameter behavior (sort/time link) is hinted, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy, essential information front-loaded. Every word earns its place. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers main purpose and parameter dependency but omits details about return structure, pagination behavior (limit parameter described), and edge cases. For a simple listing tool with no output schema, it is minimally adequate but not comprehensive.
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?
Input schema has 100% coverage with clear parameter descriptions. The description adds minor value by explicitly noting that time range is only for 'top' and 'controversial', but this is already inferable from the schema's enum and description. Baseline 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 clearly states the action ('browse posts'), the resource ('from a subreddit'), and the available options (sort orders, time range). It effectively distinguishes from sibling tools like get_post (specific post) and search_reddit (search across Reddit).
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 explicit guidance on when to use this tool versus alternatives like get_subreddit_info or search_reddit. The description implies usage for browsing posts with sorting but does not provide exclusions or comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_sessionCheck Reddit SessionA
Check if connected to a Reddit account. Shows username if authorized, or anonymous if not. Run 'authorize' tool to connect your account for write operations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the read-only nature and output behavior (username vs anonymous). It adds value by clarifying the tool's state query without side effects.
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 that front-load the core purpose, with no wasted words.
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 no parameters or output schema, the description fully explains the tool's function and how it integrates with the sibling 'authorize' tool, making it complete for its simplicity.
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?
No parameters exist; the empty schema is fully covered. The description doesn't need to add parameter details, and the baseline for 0 params is 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 clearly states the tool checks Reddit connection, showing authorized username or anonymous status. This distinguishes it from sibling tools like 'authorize' which handles authentication.
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?
Explicitly states when to use (to check connection) and directs to 'authorize' tool for write operations, providing clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_postCreate Reddit PostA
Create a new text or link post in a subreddit. Returns the permalink of the created post.
| Name | Required | Description | Default |
|---|---|---|---|
| subreddit | Yes | Subreddit name without r/ prefix | |
| title | Yes | Post title | |
| type | No | Post type: text (self post) or link | text |
| body | No | Post body text (for text posts) or URL (for link posts) | |
| flair_text | No | Flair text to apply to the post |
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 adequately states the creation action and return value (permalink), but omits details such as required authentication, rate limits, or potential side effects. This is minimally acceptable for a creation tool.
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 two sentences, front-loading the purpose and including key return information. Every word serves a purpose without redundancy.
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 five parameters and no output schema, the description sufficiently covers the core behavior and return value. It is complete enough for basic usage, though additional detail on optional parameters like flair_text would enhance completeness.
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% parameter description coverage, so the description adds limited value beyond confirming the post type (text/link) and return value. The description does not provide additional context that the schema lacks, earning a baseline score of 3.
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 a new post), specifies the resource (subreddit), and differentiates between text and link posts. The mention of returning a permalink adds further clarity. This distinguishes it from sibling tools like delete_content or edit_content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one wants to create a post, but it does not explicitly state when to use this tool versus alternatives like reply or edit_content. No exclusions or prerequisites are mentioned, which limits guidance for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_contentDelete Post or CommentA
Delete your own Reddit post or comment.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full Reddit URL of your post or comment to delete |
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 the action without mentioning side effects (destructive), authentication requirements, or whether it works on others' content. Minimal transparency.
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 sentence with no wasted words. It is perfectly concise and front-loaded with the essential purpose.
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 of the tool (one parameter, no output schema), the description is minimally adequate. However, it lacks details on return values, error handling, or prerequisites, leaving some 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 coverage is 100% with a clear parameter description. The tool description adds no additional meaning beyond what the schema already provides, so a 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 clearly states the verb (delete) and the resource (your own Reddit post or comment). It is specific enough to distinguish from sibling tools like edit_content or create_post.
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 when to use (when you want to delete your own content) but does not explicitly state when not to use or provide alternatives. No guidance on handling errors or restrictions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
edit_contentEdit Post or CommentA
Edit your own Reddit post or comment. Provide the URL of the content to edit.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full Reddit URL of your post or comment to edit | |
| new_body | Yes | New text content |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose behavioral traits like edit limits, visibility of edit history, or required authentication. A mutation tool should note restrictions.
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, clear and front-loaded. Every sentence adds value.
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 edit tool, description provides basic purpose and param hint. However, missing restrictions (editing window, own vs others) and no output schema description. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters fully. Description only reinforces the URL usage, adding no extra meaning for new_body. Baseline 3.
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?
Description clearly states the verb (edit) and resource (your own Reddit post or comment), and implies ownership restriction. Differentiates from siblings like delete_content and create_post.
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?
Description implies ownership constraint ('your own') but does not explicitly list when to avoid using or name alternative tools for other actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_inboxGet InboxA
Get your Reddit inbox messages including unread, mentions, and comment replies.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Filter inbox by message type | all |
| limit | No | Number of messages to return |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It correctly indicates a read operation ('get') with no apparent side effects, but does not disclose authentication requirements, rate limits, or any potential pitfalls like empty responses.
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 conveys the core purpose without extraneous information. It is front-loaded with the primary action and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 parameters, no nested objects) and the absence of an output schema, the description provides sufficient context for a basic retrieval tool. It identifies the resource and key subtypes, though a note on expected output format would enhance completeness.
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%, and both parameters have detailed descriptions. The description's mention of specific message types ('unread, mentions, comment replies') partially overlaps with the filter enum but does not add significant new meaning 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 states the action ('get') and resource ('inbox messages'), and lists specific message types (unread, mentions, comment replies). It is specific enough to distinguish from sibling tools like 'mark_inbox_read', but does not explicitly differentiate from them.
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 retrieving inbox messages but provides no explicit guidance on when to use this tool over alternatives (e.g., when to filter by specific types vs. using 'get_saved_items'). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_postGet Reddit PostA
Fetch a Reddit post and its comments. Returns comments as a flat array with depth and parent_id fields.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full Reddit post URL or permalink path (e.g., /r/sub/comments/id/title/) | |
| comment_limit | No | Maximum number of comments to return |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return format (flat array with depth and parent_id) but does not explicitly confirm read-only behavior or mention side effects. 'Fetch' implies no modification but could be more explicit.
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 efficiently convey purpose and key behavioral detail. No wasted words, though structure could be improved with bullets.
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?
No output schema, so description must explain return values. It covers comments structure but lacks post object details, error cases, or authentication requirements. Adequate but incomplete for a production 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 baseline is 3. Description rephrases parameter info (URL format, comment limit default) but adds no new meaning beyond schema. Minor value from describing output structure.
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 'Fetch a Reddit post and its comments' with specific verb and resource. It distinguishes from sibling tools like browse_subreddit or get_subreddit_info by focusing on a single post retrieval.
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 use for fetching a specific post by URL, but does not explicitly state when to use or alternatives. No guidance on exclusion or comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_saved_itemsGet Saved ItemsB
Get your saved Reddit posts and comments.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of saved items to return |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. It only states the basic action without revealing side effects (e.g., read-only, no destructive behavior), authentication requirements, rate limits, or pagination behavior. The description adds minimal value beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that conveys the purpose without unnecessary words. While it is succinct, it could benefit from slightly more detail (e.g., scoping to the authenticated user) without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one optional parameter, no output schema, no annotations), the description is minimally adequate but lacks context such as authentication assumption, return format, or pagination details. It meets the basic requirement 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?
The input schema covers 100% of parameters with a description for 'limit'. The tool description does not provide any additional meaning or context for the parameter beyond what the schema already offers, so a 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 clearly states the verb 'Get' and the resource 'saved Reddit posts and comments', making the tool's purpose explicit. It distinguishes itself from sibling tools like 'save_item' and 'unsave_item' by focusing on retrieval rather than modification.
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 such as 'save_item' or 'unsave_item'. There is no mention of prerequisites, authentication, or usage context, leaving the agent to infer 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_subreddit_infoGet Subreddit InfoB
Get subreddit information including description, rules, subscriber count, and whether it is NSFW.
| Name | Required | Description | Default |
|---|---|---|---|
| subreddit | Yes | Subreddit name without r/ prefix |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It does not mention error handling for nonexistent subreddits, rate limits, or authentication needs, leaving agent uncertainty.
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?
Single sentence, concise, and front-loaded with the action. No extraneous words.
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 read operation with one parameter and no output schema, the description covers the essential purpose. However, missing error behavior and return format details slightly reduce completeness.
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% for the single parameter 'subreddit'. The description does not add extra meaning beyond the schema's hint about omitting 'r/'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Get' and resource 'subreddit information', and lists specific data items (description, rules, subscriber count, NSFW status). It clearly differentiates from sibling tools like 'browse_subreddit' which likely focuses on posts.
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 given on when to use this tool versus alternatives, nor any prerequisites or when-not scenarios. The agent has no explicit criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subscriptionsGet SubscriptionsA
List your subscribed subreddits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It implies a read-only operation ('list'), but does not explicitly state that it does not modify state, require authentication, or have side effects. The description is minimally adequate but lacks explicit safety assurances.
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 is front-loaded with the action and resource. No extraneous words or information, earning 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 simplicity (no params, no output schema), the description is minimally complete. However, it omits details about the return format (e.g., list of subreddit names vs. full objects) and potential pagination, which would help an agent interpret results correctly.
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 zero parameters, and the description does not need to add parameter information beyond what the schema already provides. A baseline of 4 is appropriate for a parameterless tool.
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 'List your subscribed subreddits' uses a specific verb ('list') and clearly identifies the resource ('subscribed subreddits'). It distinguishes from sibling tools like browse_subreddit (browse content within a subreddit) and get_subreddit_info (details about a specific subreddit).
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, such as browse_subreddit or get_subreddit_info. It does not mention prerequisites (e.g., authentication) or scenarios where this is preferred over other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_user_profileGet User ProfileA
Get a Reddit user's public profile including karma breakdown and account age.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Reddit username without u/ prefix |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only repeats the purpose and adds no details on authentication, rate limits, error cases (e.g., nonexistent user), or whether the tool is safe to call repeatedly. This is insufficient for a tool with no output schema.
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 sentence, front-loading the tool's purpose. No wasted words; every part is necessary and informative.
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 simplicity (one required parameter, no output schema), the description is adequate but not thorough. It mentions the profile includes karma breakdown and account age, but doesn't confirm other fields or error conditions. Slightly below ideal completeness.
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?
Input schema coverage is 100%, and the schema already describes the 'username' parameter. The description adds no additional semantic meaning beyond what the schema provides, so a 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 clearly states the tool's purpose: get a Reddit user's public profile. It specifies the resource (Reddit user) and the contents (karma breakdown and account age). This distinguishes it from sibling tools like browse_subreddit or get_subreddit_info.
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 clear context on when to use this tool (to retrieve a user's public profile). However, it does not explicitly mention when not to use it or suggest alternatives, which would be helpful given the numerous sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mark_inbox_readMark Inbox ReadB
Mark all unread inbox messages as read.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a state change but does not disclose side effects, reversibility, or permissions needed. With no annotations, the description carries full burden and fails to provide sufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that clearly conveys the tool's purpose with no unnecessary words. It is front-loaded and efficient.
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?
While the tool is simple, the description lacks behavioral details such as whether the action is reversible or idempotent. Given no output schema, more context about the effect would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema coverage is 100%. The description adds no parameter information, which is acceptable given the no-parameter baseline of 3.
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 action: marking all unread inbox messages as read. It uses a specific verb and resource, distinguishing it from sibling tools like get_inbox which retrieves messages.
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 does not mention that it should be used after viewing the inbox or that it replaces manual marking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
replyReply to Post or CommentC
Reply to a Reddit post or comment. Provide a full URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full Reddit URL of the post or comment to reply to | |
| body | Yes | Reply text content |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral details beyond the basic action. It does not disclose that replying creates a new comment (a write operation), that the URL must be a valid Reddit URL, or any side effects, authentication needs, or rate limits. Since no annotations are provided, the description carries the full burden but fails to provide sufficient transparency.
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 very short (one sentence plus an instruction), making it concise but lacking in substance. It front-loads the purpose and a key requirement, but every sentence is necessary. The brevity comes at the cost of missing important 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 simplicity and the lack of annotations, the description is incomplete. It does not mention that the URL must point to an existing post or comment, that the user must be authorized, or how the reply will appear. The sibling tools list includes related actions, but the description does not help the agent decide when to reply vs. create or edit.
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 already has 100% coverage with clear descriptions for both parameters. The description adds only 'Provide a full URL,' which emphasizes the URL requirement but does not add new semantic meaning beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool replies to a Reddit post or comment and instructs to provide a full URL. It is specific about the action and resource, but does not explicitly differentiate from sibling tools like 'create_post' or 'edit_content', though the verb 'reply' implies a response to existing content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, no context about prerequisites (e.g., the user must be logged in), and no mention of when not to use it. The only instruction is to provide a full URL, which is more of a parameter hint than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save_itemSave Post or CommentB
Save a Reddit post or comment to your saved items list.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full Reddit URL of the post or comment to save |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits such as authentication requirements, idempotency, or side effects. It only says 'save', leaving critical details unstated.
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, but it could be more efficient by also including usage notes. Still, it is not verbose.
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 fails to provide sufficient context for a state-changing operation, such as reversibility or duplicate handling.
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 already documents the url parameter fully (100% coverage), so the description adds no extra meaning. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('save') and the resource ('a Reddit post or comment'), clearly differentiating it from siblings like unsave_item and get_saved_items.
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, nor any prerequisites like authentication. The description simply states the function without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_redditSearch RedditB
Search Reddit globally or within a specific subreddit. Returns matching posts.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| subreddit | No | Limit search to a specific subreddit (without r/ prefix) | |
| sort | No | Sort order for results | relevance |
| time | No | Time range filter | all |
| limit | No | Number of results to return |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must convey behavioral traits. It only states 'Returns matching posts' without details on pagination, rate limits, or authentication needs. This is insufficient.
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, 12 words, front-loaded with purpose. No superfluous content.
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?
No output schema, yet description does not explain return format (e.g., what fields are in 'matching posts'). Additional details on result structure or pagination would improve completeness.
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 documented. The description adds context for global vs subreddit search but no further semantic meaning beyond the schema. Baseline 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 clearly states 'Search Reddit globally or within a specific subreddit. Returns matching posts.' This uses specific verbs and resources, and distinguishes from siblings like browse_subreddit.
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 on when to use this tool vs alternatives such as browse_subreddit or get_subreddit_info. The description lacks context on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
subscribe_subredditSubscribe to SubredditB
Subscribe to a subreddit.
| Name | Required | Description | Default |
|---|---|---|---|
| subreddit | Yes | Subreddit name without r/ prefix |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond the basic action. With no annotations, the agent is left unaware of whether the action requires authentication, is reversible, or has side effects like notifications.
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 core purpose. Every word is necessary and no filler is present.
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 minimally complete. However, it lacks any mention of prerequisites, outcomes, or related tools (like 'get_subscriptions'), which could help the agent understand the broader 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?
The parameter schema includes a description ('Subreddit name without r/ prefix'), but the tool description itself does not add any further parameter meaning. Since schema coverage is 100%, the baseline is 3.
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 'Subscribe to a subreddit,' which matches the tool name and distinguishes it from related tools like 'unsubscribe_subreddit'. However, it does not elaborate on scope or side effects.
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 on when to use this tool versus alternatives, such as when the user is already subscribed or needs to check subscriptions first. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
unsave_itemUnsave Post or CommentB
Remove a Reddit post or comment from your saved items list.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full Reddit URL of the post or comment to unsave |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the basic action without mentioning side effects, authentication requirements, error handling, or idempotency. This is a significant gap for a write operation.
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 with no filler. It is appropriately sized for a simple tool, though a slightly more structured format could improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, and no annotations, the description is adequate but lacks completeness. It does not mention return behavior or error scenarios, but it covers the core function. For a simple tool, this is minimally viable.
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% coverage with a clear description for the 'url' parameter. The tool description adds no extra meaning beyond what is already in the schema, so it meets the baseline but does not enhance parameter understanding.
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 specifies the verb 'Remove' and the resource 'saved items list' for both posts and comments. It distinguishes from siblings like 'save_item' (opposite action) and 'delete_content' (removes content itself), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for unsaving previously saved items but does not explicitly state when to use it versus alternatives like 'delete_content' or 'save_item'. No guidance on prerequisites or conditions such as needing to have the item saved first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
unsubscribe_subredditUnsubscribe from SubredditB
Unsubscribe from a subreddit.
| Name | Required | Description | Default |
|---|---|---|---|
| subreddit | Yes | Subreddit name without r/ prefix |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as authentication requirements, side effects, or success/failure conditions. The bare description does not inform the agent about state changes or permissions needed.
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, consisting of a single sentence. It is front-loaded and waste-free, though this brevity may contribute to the lack of detail in other dimensions.
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 of the tool (one parameter, no output schema), the description is minimally complete. However, it does not explain the expected result of the action or any conditions, which could be important for an agent to handle errors or confirm outcomes. More context, such as requiring a prior subscription, would improve completeness.
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 100% of parameter descriptions, including the note about omitting 'r/'. The description adds no further meaning beyond what the schema already provides, so it meets the baseline without additional clarification.
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 (unsubscribe) and the resource (subreddit). It distinguishes from sibling 'subscribe_subreddit' by being the inverse operation. The one-sentence description is direct and sufficient.
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 like 'subscribe_subreddit' or any prerequisites (e.g., must be subscribed first). The description lacks contextual cues for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
voteVote on Post or CommentB
Upvote, downvote, or remove your vote on a single Reddit post or comment. One vote per call.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full Reddit URL of the post or comment | |
| direction | Yes | Vote direction: up, down, or unvote to remove |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states that it modifies vote state and limits to one vote per call, but does not disclose whether votes are reversible (the 'unvote' option implies reversibility, but this is not explained). With no annotations, the description carries the full burden, but it fails to mention authentication requirements, rate limits, or what happens on success/failure.
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, each adding value: the first states the resource and allowed actions, the second enforces the call limit. No wasted words. Front-loaded purpose.
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 no output schema and no annotations, the description should explain return values (e.g., success indicator, updated vote count) or error scenarios (e.g., invalid URL, vote not allowed). It does not. The tool is simple, but the description lacks completeness for an agent to fully understand consequences.
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 the input schema itself documents both parameters. The description adds no additional meaning beyond stating the three directions (up, down, unvote), which are already in the schema enum. Baseline 3 applies because 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?
Clearly states it upvotes, downvotes, or removes a vote on a single Reddit post or comment. The verb 'vote' combined with the three actions makes the purpose specific and distinct from sibling tools like 'reply' or 'save_item'.
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 explicit guidance on when to use this tool vs. alternatives. The description does not mention prerequisites (e.g., authentication, eligibility to vote on content), nor does it clarify that votes are not allowed on own content or in archived threads. 'One vote per call' is the only usage hint.
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. Dates show when Glama detected each change.
20 tool updates
v1.0.0- First observed
authorize - First observed
browse_subreddit - First observed
check_session - First observed
create_post - First observed
delete_content - First observed
edit_content - First observed
get_inbox - First observed
get_post - First observed
get_saved_items - First observed
get_subreddit_info - First observed
get_subscriptions - First observed
get_user_profile - First observed
mark_inbox_read - First observed
reply - First observed
save_item - First observed
search_reddit - First observed
subscribe_subreddit - First observed
unsave_item - First observed
unsubscribe_subreddit - First observed
vote
TDQS
Each tool targets a distinct action or resource (e.g., authorize, browse, create, delete, vote, save). No two tools have overlapping purposes; even similar operations like subscribe/unsubscribe are clearly differentiated.
All tool names follow a consistent verb_noun pattern in lowercase snake_case (e.g., browse_subreddit, create_post, get_inbox). Even single-word names like 'authorize' and 'reply' fit the verb-first pattern.
With 20 tools, the server covers a wide range of Reddit operations without being bloated. The count is appropriate for a full-featured Reddit client, balancing usability and coverage.
The server covers core CRUD operations, voting, saving, searching, and inbox management. Missing a tool to list the user's own posts or comments, but this is a minor gap given the overall breadth.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
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)
Free, no-key Bible MCP server — 86 translations in 32 languages, from any MCP client.
Lemmy MCP — public reads on any Lemmy instance.
Related MCP Servers
- AlicenseBqualityDmaintenanceAn MCP server that provides both read-only and authenticated access to Reddit content and interactions without requiring a developer API key. It enables users to browse posts, search subreddits, and perform write actions like commenting and voting by leveraging browser session cookies.81-
- AlicenseAqualityDmaintenanceA dependency-free MCP server that reads Reddit through its RSS feeds, enabling search, browsing subreddits, and reading post comments without any API keys or authentication.31413MIT
- AlicenseAqualityBmaintenanceAn MCP server that enables authenticated Reddit account actions like posting, commenting, voting, and messaging via the Reddit API.1232MIT
- AlicenseNot gradedqualityBmaintenanceA local, read-only Reddit MCP server that provides tools for searching posts, retrieving posts/comments, subreddit information, and user content via the official Reddit Data API with caching and privacy-focused features.-
Appeared in Searches
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jeebus87/reddirect'
If you have feedback or need assistance with the MCP directory API, please join our Discord server