reddit-research-agent

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools are cleanly separated by resource and output type: discovery, search, thread reading, community info, and user activity. The main potential confusion is between track_mentions and search_reddit, and to a lesser extent research_topic and harvest_quotes, but the descriptions give enough context to choose correctly.
Naming Consistency4/5
The vast majority of tools follow a clear verb_noun pattern such as harvest_quotes, find_subreddits, get_thread, and compare_terms. The only deviation is server_status, which uses a noun phrase instead of an action-oriented name, so consistency is strong but not perfect.
Tool Count5/5
Twelve tools is a well-scoped size for a Reddit research agent. The set covers high-level research entry points, community discovery, search, browsing, thread inspection, user checks, and server diagnostics without feeling bloated or redundant.
Completeness5/5
The tool surface covers the full research lifecycle: discover subreddits, search and browse posts, read threads, assess community size, check rules, track mentions, and verify server status. There are no obvious dead ends or missing operations for the stated research purpose.
Average 4.2/5 across 12 of 12 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on September 1, 2026
- 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.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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the scoping detail that it lists posts from a single subreddit, but it does not discuss pagination, return format, or error 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 a single, clear sentence with no filler. It front-loads the action and resource, and it does not duplicate schema details unnecessarily.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only list tool with full schema coverage and supportive annotations, the description plus schema is largely sufficient to invoke the tool correctly. A minor gap is the lack of any mention of the returned post shape or pagination, but no output schema exists and the tool's behavior is straightforward.
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?
Schema description coverage is 100%, with each parameter already explained in the input schema. The description mostly restates the listing enum and adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 applies.
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 'list' and the resource 'posts from one subreddit', with the available listing types enumerated. It is distinguishable from siblings like search_reddit and get_thread, though it does not explicitly name them.
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 phrase 'from one subreddit' implies the tool's scope and suggests it is not for cross-subreddit search or single-thread retrieval. However, there is no explicit when-to-use guidance or mention of alternatives such as search_reddit or get_subreddit_info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the tool's safety profile is established. The description adds useful context about the kind of information returned, but does not disclose further behavioral details such as output format, pagination, or rate limits. This is acceptable given the annotations, but not notably rich.
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?
Two sentences with no filler. The first sentence front-loads the core output, and the second sentence justifies the tool's purpose with a concrete example. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter, read-only tool, the description is largely complete: it names the community scope, the returned information categories, and a realistic use case. Since there is no output schema, describing the high-level return contents as 'size, age, activity, and description' is sufficient, though exact structure is not specified.
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 input schema has 100% description coverage for the single parameter, including 'Community name, with or without the r/ prefix.' The tool description adds no additional parameter-specific guidance, so it meets the baseline without exceeding it.
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 identifies the tool as providing 'size, age, activity, and description of one community,' which is specific and distinct from sibling tools focused on content, rules, or user activity. The verb is implied by the title 'Get subreddit info,' but the description elaborates the resource and its unique data categories well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete use case: 'Use it to weigh a finding,' explaining how community scale affects interpretation. It gives clear context for when this tool is valuable, though it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and destructiveHint, covering the safety profile. The description adds useful output details—permalinks and community breakdown—but does not disclose behaviors like sorting, relevance, or account requirements, which would go beyond the 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?
Three sentences, each serving a purpose: what it finds, what it returns, and when to use it. The information is front-loaded and there is no redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by stating the return values (posts, permalinks, community breakdown). The 4 parameters are fully covered by the schema, and the description provides enough context for correct tool selection and invocation. It does not mention pagination or sorting, but these are not essential for basic use.
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?
Schema description coverage is 100%, so the schema fully documents all four parameters. The description adds slight context by mapping 'term' to 'brand, product, or phrase' and 'subreddits' to 'communities', but this is marginal beyond what the schema already provides.
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 'Find' and the resource (brand, product, or phrase mentions), and specifies the return value: matching posts with permalinks and a community breakdown. It does not explicitly name a sibling tool to differentiate from, but the community breakdown distinguishes it from generic search tools like search_reddit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before deciding which threads to read in full' provides clear contextual guidance, implying a workflow of using this tool to survey mentions first, then reading full threads. It does not explicitly state when not to use it or name an alternative, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful practical context about the nature of the returned content and a common pattern in subreddit rules, which helps the agent understand the tool's value without contradicting 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short, purposeful sentences: one defines what is returned, one says when to use the tool, and one provides a relevant domain warning. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only lookup with no output schema, the description covers the tool's purpose, usage timing, and an important caveat about self-promotion. It does not describe the return format, but this is a minor gap given the tool's simplicity.
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 input schema fully documents the single 'subreddit' parameter, including support for the r/ prefix, so the description does not need to add much. The phrase 'community' loosely aligns with the parameter but provides no additional semantic detail.
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 identifies the tool's resource as 'posting rules of a community,' which is clear and more specific than the generic title. It lacks an explicit verb like 'retrieves' and does not explicitly distinguish itself from siblings, but the intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a direct usage instruction: read these rules before suggesting the user post anything anywhere. It also supplies a reason why this matters with the common self-promotion ban warning, though it does not mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by revealing that results merge Reddit's subreddit search with recent-post communities, and that results can include non-obvious subreddits whose names don't mention the topic. This explains behavior beyond the structured fields.
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 two sentences with no filler. The first sentence states the core purpose, and the second explains the method and key differentiator. Every sentence earns its place, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with two simple parameters, the description fully conveys what the tool does and how it behaves. It does not explicitly describe the return format, but 'Find the communities' strongly implies a list of subreddits, and the absence of an output schema does not create a significant gap here.
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?
Schema description coverage is 100%, with both 'topic' and 'limit' already described in the schema. The description does not add parameter-specific details, but it doesn't need to because the schema carries the full parameter burden. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Find') and resource ('communities where a topic is actually discussed'). It also distinguishes itself from siblings by explaining the unique merging strategy and explicitly noting it surfaces subreddits that never mention the topic in their name, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly communicates when to use the tool: when the goal is discovering communities for a topic, especially when relevant subreddits may not have obvious names. It does not explicitly name exclusions or alternatives, but the context is strong enough for an agent to choose it over post-oriented tools like search_reddit or browse_subreddit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, non-destructive, and open-world, so the description only needs to add scope and context. It discloses that the tool returns recent public posts and comments and implies historical breadth, which goes beyond the schema and annotations without contradicting them.
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?
Two sentences deliver the essential information with no fluff. The data scope is front-loaded, and the follow-up sentence adds meaningful guidance on when the tool matters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two well-documented parameters, the description covers the core behavior and return substance. It could be more precise about what 'recent' means or how results are ordered, but the schema and annotations cover most operational concerns.
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 fully documents both parameters, including defaults and the requirement to omit 'u/' from the username. The description does not add further parameter-level detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving a redditor's recent public posts and comments, matching the title and name. It also frames the purpose—weighing a source's history—which helps an agent understand the resource and its intended use. This is distinct from sibling tools focused on subreddits, threads, or searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete use case: evaluating a source's posting history in context. It explains why the tool should be used for source assessment, but it does not explicitly state when to prefer alternatives or list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by disclosing exactly what is returned (post counts, comments, upvotes, share of group) and explicitly narrowing the behavior to volume-only measurement, which prevents misinterpretation 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words: the first states the core purpose, the second lists outputs, and the third clarifies boundaries. The most important scoping information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only comparison tool with simple parameters, the description covers purpose, output shape, and non-goals. The schema covers parameter details, and annotations cover safety, so nothing essential is missing for an agent to select and call it correctly.
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 input schema already documents all three parameters with 100% coverage, so the baseline applies. The description reinforces the meaning of 'terms' by mentioning per-term results and group share, but it does not add meaningful detail for subreddit or timeFilter beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (compare) applied to a specific resource (Reddit discussion volume for several terms) and enumerates the exact returned metrics. It also explicitly distinguishes itself from sentiment and market-share tools, which helps separate it from siblings like research_topic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use context: when you want to compare raw volume of conversation across terms. It also states what the tool does not do ('not sentiment, and it is not market share'), providing useful exclusion criteria, though it does not name specific alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, non-destructive operation, so the description adds useful behavioral detail beyond them: results are flattened, sorted by score, and include permalinks. It does not cover every edge case like rate limits, but the key return-shape behavior is disclosed.
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?
Two sentences deliver the tool's purpose, output shape, and accepted input formats without repetition or filler. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description sufficiently covers what the caller gets: the post, its comments, ordering, and permalinks. Combined with the annotations and complete parameter schemas, an agent has enough context to call the tool correctly.
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 already describes all three parameters with 100% coverage. The description mostly restates the reference parameter's accepted input forms and adds no new meaning for sort or commentLimit. This matches the schema-heavy baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read'), a specific resource ('one thread'), and the full scope ('the post and its comments'). It clearly differentiates from sibling tools like browse_subreddit or get_subreddit_info by targeting a single thread rather than a subreddit or user activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended use case clear: retrieve a complete thread given a URL, permalink, or post id. It does not explicitly contrast with sibling tools, but the reference-based input and 'one thread' framing give a strong context for when it should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only and non-destructive. On top of that, the description discloses important behavior: results are verbatim, carry permalinks for citation, and are tagged by intent. This goes beyond what annotations alone tell an agent.
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?
Four sentences, all purposeful: what it does, when to use it, what output looks like, and what intents mean. Non-needed details are absent and key usage guidance is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter read-only tool with a fully documented schema and no output schema, the description provides the key missing context: return value shape, citability, and intent taxonomy. An agent has enough to call and interpret the tool correctly.
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?
Input schema covers 100% of parameters with descriptions, so the schema carries the parameter semantics. The narrative adds overall context about intents and verbatim output but no parameter-level details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource: 'Research a topic and return only the quotable sentences, tagged by intent.' It adds the distinguishing constraint 'only the quotable sentences' and names the exact output shape, which separates it from broader research or browsing siblings even without naming one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use guidance: 'Use this when the goal is customer language: the exact words people use about a problem, a want, or an objection.' It does not name alternative tools or state when not to use it, but the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses the important re-ranking behavior: results are re-ranked to surface the most discussed threads rather than the most upvoted. This adds real behavioral context that annotations do not capture, though it does not cover details like rate limits or pagination.
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 two sentences with no filler. It front-loads the core purpose and then adds the most decision-relevant behavioral detail, making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with six parameters and no output schema, the description covers the key behavioral nuance and the optional subreddit restriction. It does not describe the return shape or edge cases, but the schema fully documents parameters, so the description is adequately complete for invocation.
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 coverage is 100%, so the baseline is 3. The description adds extra semantic value by explaining the practical effect of the default rankByDiscussion behavior and connecting it to research use, which goes beyond the schema's dry parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Search Reddit posts') and a scoping option ('optionally inside one subreddit'), which clearly identifies what the tool does. It also distinguishes the tool from sibling tools like browse_subreddit or find_subreddits by focusing on search over Reddit posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by explaining that the default re-ranking favors highly discussed threads, 'which is usually what research wants.' It does not explicitly name alternatives or exclusion criteria, but the research-oriented context is enough to guide an agent on when to choose this tool.
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 rich behavioral detail beyond the readOnly/openWorld annotations: it discovers subreddits when none are given, ranks by discussion depth rather than upvotes, pulls comments from winning threads, and returns permalinks. This accurately previews the tool's behavior without contradicting 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly written in four sentences with no wasted words. It front-loads the core action, then efficiently covers workflow, output guarantees, and a practical usage tip.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and a multi-step orchestration, the description is largely complete: it covers workflow, key output clues (evidence, permalinks, thread rankings), and usage strategy. It stops short of describing a concrete return structure, but the schema and annotations carry much of the remaining burden.
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 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining that subreddits can be omitted for automatic discovery and that includeComments=false provides a cheap overview before committing context. This semantic context raises the score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: "Run a full Reddit research pass and return the evidence." It clearly differentiates itself from sibling tools by describing the orchestration flow (discover subreddits, search, rank, pull comments) and positioning itself as the first-stop research tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says "This is the tool to reach for first," giving strong when-to-use guidance. It also advises setting includeComments false for a cheap overview before committing context. However, it does not explicitly name sibling alternatives or state when to prefer them, so it is not a full 5.
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 annotations (readOnlyHint, destructiveHint), the description discloses meaningful behavior: it performs one live request to Reddit, reports auth mode, credential acceptance, and the request result. This gives the agent a clear picture of side effects and outputs without requiring schema inspection.
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?
Three sentences with clear front-loading: action, usage, and details. Minor redundancy exists between the first and third sentences (both mention auth mode), but the description remains tight and waste-free overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter diagnostic tool with safety annotations, the description fully covers what it does, when to use it, and what it reports. No output schema exists, but the description lists the key pieces of information returned, which is sufficient for an agent to understand the result.
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 tool has zero parameters, so the baseline of 4 applies. The description adds no parameter details, but none are needed since the schema is empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Check') and resource (server configuration, auth mode, Reddit connectivity), making its purpose immediately clear. This tool is obviously distinct from the sibling Reddit data tools, as none relate to server health or auth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use guidance is provided: 'Run this first when anything looks broken.' It does not mention when not to use it or name alternatives, but given the tool's unique diagnostic role and unrelated siblings, this is sufficient.
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-research-agent MCP server](https://glama.ai/mcp/servers/thenavidm/reddit-research-agent/badges/card.svg)](https://glama.ai/mcp/servers/thenavidm/reddit-research-agent)

Score Badge

Copy to your README.md:

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

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/thenavidm/reddit-research-agent'

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