Reddit MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific Reddit entities: comments, submissions, subreddits, and searches. No overlap exists between tools like get_comment_by_id and get_comments_by_submission, which serve different retrieval needs.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with underscores (e.g., get_comment_by_id, search_posts). The naming is predictable and readable throughout the set, with no deviations in style.
Tool Count4/5
Six tools is reasonable for a Reddit API server, covering core read operations. It's slightly lean but includes key functionalities like retrieval and search, though it lacks write operations which might be expected in a full-featured server.
Completeness3/5
The tool set provides good read coverage for comments, submissions, and subreddits, but there are notable gaps: no create, update, or delete operations (e.g., posting comments or submissions). This limits agents to read-only workflows, which may cause failures in interactive scenarios.
Average 3.1/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Retrieve' but doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires authentication, rate limits, error handling, or what 'Detailed information' includes. This leaves significant gaps for an agent to understand how to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: purpose, parameter, and return value. It's front-loaded with the main action, and each sentence adds value without redundancy. Minor improvements could include merging the Args/Returns sections into a single line for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no nested objects) but lack of annotations and output schema, the description is minimally adequate. It covers the basic purpose and parameter but misses behavioral context and output details, which are crucial for a retrieval tool. It's complete enough to avoid being inadequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds meaning by specifying that 'submission_id' is the 'ID of the submission to retrieve', which clarifies the parameter's purpose beyond the schema's title 'Submission Id'. However, it doesn't provide format details (e.g., string format, examples) or constraints, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieve') and resource ('a specific submission by ID'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get_comment_by_id' or 'get_comments_by_submission', which follow similar patterns for comments versus submissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'search_posts' or 'get_comments_by_submission'. It mentions retrieving by ID but doesn't specify prerequisites (e.g., needing a known submission ID) or exclusions (e.g., not for bulk retrieval).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 basic action ('search') and return type ('List of matching posts with their details'), but lacks critical details such as whether this is a read-only operation, potential rate limits, authentication requirements, pagination behavior, or error handling. For a search tool with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with three sentences that cover purpose, parameters, and returns without unnecessary fluff. It's front-loaded with the core function. However, the structure could be slightly improved by integrating parameter details more seamlessly, but it remains efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search operation with multiple parameters (e.g., sort, syntax, time_filter), no annotations, and no output schema, the description is incomplete. It doesn't explain the return format beyond 'List of matching posts with their details,' nor does it cover behavioral aspects like rate limits or error cases. For a tool with rich input schema but no other structured data, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It mentions 'Search parameters including subreddit name, query, and filters,' which adds some context beyond the schema by hinting at the parameters' roles. However, it doesn't detail specific filters or explain parameter interactions, leaving gaps. Given the low coverage, this partial compensation earns a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for posts within a subreddit.' It specifies the verb ('search') and resource ('posts within a subreddit'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'search_subreddits' or 'get_submission', which is why it doesn't achieve 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.
Usage Guidelines2/5
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 sibling tools like 'search_subreddits' (for searching subreddits themselves) or 'get_submission' (for retrieving a specific post), leaving the agent to infer usage context. This lack of explicit comparison or exclusion criteria results in a low score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 retrieving comments and replacing MoreComments objects, but doesn't cover important aspects like authentication requirements, rate limits, error conditions, pagination, or what happens when submission_id is invalid. The behavioral context is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for Args and Returns. It's appropriately sized with no redundant information. Every sentence serves a purpose, though it could be slightly more front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a retrieval tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description provides adequate basic information but lacks depth. It explains what the tool does and its parameters but doesn't cover behavioral aspects, error handling, or relationship to sibling tools, leaving gaps in contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clearly explains both parameters: 'submission_id' identifies the target submission, and 'replace_more' controls whether MoreComments objects are replaced with actual comments. This adds meaningful context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and resource 'comments from a specific submission', making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get_comment_by_id' or explain how this differs from general comment retrieval methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_comment_by_id' or 'search_posts'. It mentions retrieving comments from a specific submission but doesn't clarify use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action ('Retrieve') and return ('Detailed information'), but doesn't disclose behavioral traits such as authentication needs, rate limits, error handling, or what 'detailed information' entails. This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with a clear purpose statement followed by structured Args and Returns sections. Every sentence earns its place without redundancy, making it efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and parameter but lacks details on behavior, usage context, and output specifics, leaving room for improvement in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 1 parameter, the description compensates by explaining the parameter's purpose ('Name of the subreddit to retrieve'), adding meaningful context beyond the schema's basic type. This is sufficient for the single parameter, though it doesn't detail format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieve') and resource ('a subreddit by name'), making the purpose specific and understandable. It distinguishes from siblings like 'search_subreddits' by focusing on retrieval of a single subreddit rather than searching, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'search_subreddits' for finding subreddits or other siblings for different data types. The description implies usage for retrieving a known subreddit by name but lacks 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.
Behavior2/5
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 tool returns a list of matching subreddits with details, but lacks critical information such as whether this is a read-only operation, potential rate limits, authentication requirements, or how results are sorted/paginated. The description is minimal and misses key behavioral traits for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured, using only three sentences that efficiently cover purpose, parameters, and return value. Every sentence adds value with no wasted words, and it's front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (search with two modes), no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It covers the basic purpose and parameter structure but lacks behavioral details, usage context, and output specifics. It's adequate as a minimal overview but leaves significant gaps for an AI agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the input schema by explaining that the 'by' parameter accepts either 'SearchByName' or 'SearchByDescription' objects, clarifying the two distinct search modes. Since schema description coverage is 0% (parameters have no descriptions in the schema), the description compensates well by outlining the parameter's purpose, though it doesn't detail the nested properties within each search type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for subreddits using name-based or description-based search, providing a specific verb ('search') and resource ('subreddits'). It distinguishes from sibling tools like 'search_posts' (which searches posts) and 'get_subreddit' (which retrieves a specific subreddit), though it doesn't explicitly differentiate from them in the description text itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_subreddit' (for retrieving a known subreddit) or 'search_posts' (for searching within subreddit content). It mentions the two search methods but offers no context on which to choose or any prerequisites for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 retrieves comment details with replies, which implies a read-only operation, but doesn't cover aspects like error handling (e.g., what happens if the ID is invalid), authentication needs, rate limits, or data format. This leaves significant gaps in understanding 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by clear sections for arguments and returns. Every sentence adds value without redundancy, making it efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is minimally adequate but lacks depth. It covers the basic operation and parameter semantics but omits behavioral details like error cases or output structure, which could hinder an agent's ability to use it correctly in edge scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter by explaining that 'comment_id' is the 'ID of the comment to retrieve', which clarifies its purpose beyond the schema's basic type information. With 0% schema description coverage and only one parameter, this compensation is adequate, though it could benefit from details like ID format or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Retrieve') and resource ('a specific comment by ID'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_comments_by_submission', which might retrieve multiple comments, leaving some ambiguity about when to choose this tool over others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying 'a specific comment by ID', suggesting it's for retrieving a single, known comment. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'get_comments_by_submission' or mention any prerequisites or exclusions, leaving the agent to infer context from the parameter name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![reddit-mcp MCP server](https://glama.ai/mcp/servers/GridfireAI/reddit-mcp/badges/card.svg)](https://glama.ai/mcp/servers/GridfireAI/reddit-mcp)

Score Badge

Copy to your README.md:

[![reddit-mcp MCP server](https://glama.ai/mcp/servers/GridfireAI/reddit-mcp/badges/score.svg)](https://glama.ai/mcp/servers/GridfireAI/reddit-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/GridfireAI/reddit-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server