simple-reddit-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation5/5
Each tool targets a distinct operation: get_thread retrieves a single post with its comment tree, get_posts and get_comments handle bulk lookups by ID, and the three search tools query posts, comments, and subreddits respectively. The purposes are clearly separated and the verbose caveats do not create ambiguity.
Naming Consistency5/5All tool names follow a consistent 'verb_noun' pattern, using 'get_' for direct ID-based retrieval and 'search_' for query-based discovery. The only minor deviation is 'get_thread' being singular while others are plural, but the pattern is otherwise uniform and predictable.
Tool Count5/5Six tools is well-scoped for a read-only Reddit client covering posts, comments, and subreddits through both direct access and search. Each tool serves a distinct purpose without unnecessary redundancy, fitting comfortably within the ideal 3-15 range.
Completeness4/5The surface covers the core read operations: single-thread retrieval, bulk post/comment fetching, and searching across posts, comments, and subreddits. Minor gaps exist, such as no direct subreddit or user profile endpoint, but search_subreddits and search_comments with author can fill these needs effectively.
Average 4.5/5 across 6 of 6 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.jsonto 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
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable caveats about data freshness ('subscriber counts lag reality') and warns against reporting placeholder values. However, the second caveat about score/num_comments appears misplaced for a subreddit search tool, causing some confusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with purpose, but the second caveat about posts/comments is tangential and detracts from focus. Still, the core message is clear and efficiently stated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 13 parameters and no output schema, the description covers the purpose and important data-freshness caveats, but does not describe return format (markdown default) or additional behavior. The misplaced caveat slightly reduces completeness, but overall it is adequate for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented in the schema. The tool description only maps high-level criteria (name, prefix, subscribers, age) to parameters but does not add new meaning beyond the schema, which serves as the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Find subreddits by name, prefix, subscriber count or age' with a specific verb and resource, clearly distinguishing it from sibling tools that search posts or comments. This makes the tool's purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for subreddit lookups vs. posts/comments, but does not explicitly say 'use this instead of search_posts/search_comments'. The context from sibling names provides implicit guidance, but there are no stated exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and open-world hints, but the description adds a crucial warning about placeholder vote data for posts newer than ~36h. This discloses behavioral quirks (backfill delay) and tells the agent never to report placeholder scores/comments as real, going well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short paragraphs front-load the primary purpose, then provide usage context and a caveat. No wasted sentences; every part contributes essential information. The structure is clean and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a bulk lookup tool with no output schema, the description covers returned fields (titles, authors, scores), notes the placeholder caveat, and the schema documents all parameters. This is sufficient for the agent to invoke it successfully without missing key context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with all parameters well-documented. The description does not add any parameter-specific nuance beyond the schema (e.g., it mentions 'bulk' but the schema already says 'up to 500'). This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Look up posts in bulk by id.' It clearly distinguishes this from sibling search tools (which find posts by query) and from get_thread/get_comments by emphasizing bulk retrieval by known IDs. The mention of returning titles, authors, and scores further clarifies the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit 'Use when' condition: when you already have post IDs, e.g., from search_comments results. This implies when not to use (when you lack IDs) and implies alternatives like search tools. However, it does not explicitly name an alternative tool, so it falls short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a significant behavioral caveat beyond the annotations: Arctic Shift archives posts immediately and backfills vote data after ~36h, making score and num_comments placeholders. This warns the agent against reporting fake counts, which is essential context that annotations alone do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, followed by usage context and a clearly marked caveat. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description must carry more weight. It covers purpose, usage, and a critical data caveat, which is adequate for a bulk lookup tool. It doesn't explain markdown vs. raw output, but the schema covers that via the 'raw' parameter. Overall it feels complete given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 4 parameters with full descriptions, so baseline is 3. The description adds value by clarifying what kind of IDs to supply (from reply markers or permalinks) and that lookups are bulk. This helps the agent understand the 'ids' parameter beyond its schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Look up comments in bulk by id') and identifies the resource (comments) and method (by id). It distinguishes itself from siblings by focusing on bulk id lookup, contrasting with search-based or thread-level tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use this tool: for comment ids from '[+N more replies]' markers or resolved permalinks. It does not explicitly mention alternatives, but the context is clear enough to avoid confusion with search_comments or get_thread.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld/idempotent annotations, the description discloses output format (indented markdown tree, collapsed branches) and a critical data quality caveat about Arctic Shift placeholders. This significantly informs the agent about runtime behavior and data reliability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with purpose, then output behavior, then caveat. Each sentence contributes essential information without wordiness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters and no output schema, the description covers the primary use case, return format, and an important limitation. It does not detail every parameter or edge case, but the schema fills the gaps, making it complete enough for a read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already well documented. The description adds value by emphasizing the flexible url_or_id format (any URL or id) and explaining the default output format, which complements rather than repeats the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Read a reddit post and its comment tree from any reddit URL or id,' using a specific verb and resource. It also positions itself as 'the primary tool' for pasted links, distinguishing it from siblings like get_posts or get_comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use it ('give it whatever the user pasted') and adds a caveat about when data is unreliable (new posts have placeholder scores). However, it does not explicitly name alternatives or exclusions for using other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, open-world, and idempotent, so the description focuses on additional behavioral details. It discloses that Arctic Shift archives posts immediately and backfills vote data after ~36h, making score and num_comments placeholders on recent posts, and warns about possible timeouts. This is high-value context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the purpose, the second covers parameter constraints, and the third explains the important data caveat. No filler sentences; every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 13 parameters, the description focuses on the essential usage constraints and the major data-quality caveat that could mislead users. Return format is already addressed in the schema's raw parameter description, and annotations provide safety context, so the description is complete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 13 parameters with 100% coverage, so the baseline is met. The description adds cross-parameter semantics by explaining that query, title, and selftext are only accepted with subreddit or author, and that a date range makes them reliable—constraints not visible from individual schema entries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Find posts by subreddit, author, keyword or date range,' using a specific verb and resource scope that clearly distinguishes search_posts from sibling tools like get_posts and search_comments. It communicates the core search capability immediately and effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage constraints: keyword parameters require subreddit or author, and a date range improves reliability. It doesn't explicitly compare to sibling tools or state when to prefer this tool over others, but the parameter-level guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses important behavioral traits: the Arctic Shift caveat that 'score and num_comments on anything newer than that are placeholders (usually 1 and 0) - never report them as real counts.' It also notes that keyword search is the slowest endpoint. This adds significant value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three paragraphs with zero filler. The first sentence establishes purpose, the second gives usage advice, and the third presents a critical caveat. Every sentence earns its place and the structure is logical and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count (12), rich schema descriptions, and no output schema, the description is remarkably complete. It covers search dimensions, performance trade-offs, and data-quality caveats. The raw field's schema description plus the caveat about score/num_comments indirectly inform the output format, making further explanation unnecessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 12 parameters with descriptions, so baseline is 3. The description adds extra semantics: 'With author alone this doubles as user comment history' clarifies the author parameter, and pairing body with subreddit/author/date range provides practical constraints not fully stated in the schema. This lifts it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Find comments by subreddit, author, keyword, post or date range.' This is a specific verb ('Find') plus a resource ('comments') with enumerated search dimensions, which distinguishes it from sibling tools like search_posts and get_comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'With author alone this doubles as user comment history' and 'Comment keyword search is the slowest endpoint - pair body with a subreddit, an author or a date range.' This tells the agent when to use the tool and how to optimize queries, including performance considerations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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:
Score Badge
Copy to your README.md:
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/ekatiyar/simple-reddit-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server