reddit-com
Server Details
Reddit COM: Real-time data, unofficial API reddit.com. On the JoJ API marketplace.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 1.8/5 across 10 of 10 tools scored.
Several tools are easily confused: get_posts_comments, get_subreddit_comments, and get_search_comments all involve comments but target different scopes; similarly, get_subreddit_search, get_posts_search_posts, and get_search_* tools overlap in search functionality. Without detailed descriptions, an agent might select the wrong endpoint for a given intent.
All tools start with 'get_', providing a consistent verb prefix. However, the structure after the prefix varies: some use entity-first (get_subreddit_comments), some action-first (get_search_comments), and one is awkward (get_posts_search_posts). This mixed pattern reduces predictability.
Ten tools is a reasonable and well-scoped number for a Reddit read-only API server. It covers search across multiple entities and basic content retrieval without feeling bloated or too sparse.
The tool surface is heavily read-focused, covering search and content fetch, but omits many core Reddit operations such as creating posts, commenting, voting, or retrieving user profiles and subreddit details. Some endpoints like get_subreddit_awarding_totals seem niche, while more common ones (e.g., get_subreddit_info) are absent.
Available Tools
10 toolsget_auto_completeauto-completeCInspect
auto-complete Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| nsfw | No | - Whether to retrieve content that is not safe for work (e.g., 18+ content) - Default: `false` - The `true` is yes, the `false` is no | |
| limit | No | - Limit - Default: `5` - The `limit` has a value from 1 to 10 | |
| query | No | - Required: true - Ex: `gaming` |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for disclosing behavior. It only mentions billing cost per call, but omits output shape, side effects, authentication needs, or whether this is a read-only 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 short but under-specified: 'auto-complete Billing per call: 1 Credits.' contains no functional explanation. This is not effective conciseness; it omits essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain return values and use context. It does not. The input schema is helpful, but the overall description is incomplete for an agent to know what get_auto_complete returns or when to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with parameter descriptions for nsfw, limit, and query providing defaults, examples, and ranges. The tool description itself adds no parameter semantics, but the schema already does the heavy lifting, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'auto-complete Billing per call: 1 Credits' adds only a billing note and essentially repeats the tool title. It does not state a clear verb, resource, or what the tool actually does beyond implying autocomplete functionality.
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?
There is no guidance on when to use this tool versus sibling tools like get_search_media or get_posts_search_posts. The description provides no context, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_posts_commentsposts/commentsDInspect
posts/comments Group: Posts. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | - Sort by - Default: `CONFIDENCE` - Choose one of the values below - `confidence`: Best - `top`: Top - `new`: New - `controversial`: Controversial - `old`: Old - `qa`: Q&A | |
| postId | No | - Required: true - The `postId` can be retrieved from /posts/search-posts (data->id) - Ex: `t3_178zwq0` |
Tool Definition Quality
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 does not state whether this is a read operation, what it returns, or any rate limits or auth requirements. The billing note is a cost context, not a behavioral trait.
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 brief but under-specified. It does not earn its length as conciseness; it lacks substantive content that would help an agent, resembling an under-specified placeholder rather than a concise, informative description.
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 output schema and no annotations, the description is severely incomplete. It does not explain what the tool does, how it behaves, or why an agent would need it, despite the schema covering parameters. The description fails to provide essential context for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with detailed descriptions for both parameters (sort and postId), including defaults and examples. The description itself adds no parameter information, but the schema already does the heavy lifting, so the 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 restates the title 'posts/comments' and adds only grouping and billing details. It lacks a verb or explanation that this tool retrieves comments for a post, so it is essentially a tautology.
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 sibling tools like get_subreddit_comments or get_search_comments. The description only mentions group and billing, with no context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_posts_search_postsposts/search-postsDInspect
posts/search-posts Group: Posts. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| nsfw | No | - Whether to retrieve content that is not safe for work (e.g., 18+ content) - Default: `false` - The `true` is yes, the `false` is no | |
| sort | No | - Sort by - Default: `relevance` - Choose one of the values below - `relevance`: Relevance - `hot`: Hot - `top`: Top - `new`: New - `comments`: Comment count | |
| time | No | - Time - Default: `all` - Choose one of the values below - `all`: All time - `year`: Past year - `month`: Past month - `week`: Past week - `day`: Today - `hour`: Past hour | |
| query | No | - Required: true - Ex: `gaming` | |
| nextPage | No | - The page index, for paging purpose - Leave it blank for the first time - The `nextPage` can be retrieved from response of this endpoint(meta->nextPage) - Ex: `MjQ=` |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits such as side effects, permissions, rate limits, or return behavior. The description only mentions billing and group, offering zero transparency about what the tool does or any consequences of invoking it. This is a significant gap for a tool that presumably performs a search.
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 only 8 words: 'posts/search-posts Group: Posts. Billing per call: 1 Credits.' While concise, it is under-specified to the point of being non-informative. It does not front-load any useful information for an AI agent deciding whether to use this tool. This is not conciseness but severe under-description.
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 5 parameters, no output schema, and no annotations, the description should explain the tool's purpose, typical usage, and paging behavior. The description fails to provide any of this. The schema handles parameter details, but the overall context—what the tool does, when to call it, how pagination works—is missing. The tool is completely under-specified for its complexity.
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 provides descriptions for all 5 parameters (100% coverage), including defaults and enum options for sort and time, plus details on nextPage. Thus, the description does not need to add much. The schema already explains the purpose of each parameter. The description adds nothing extra, but given high schema coverage, a 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 only states 'posts/search-posts Group: Posts. Billing per call: 1 Credits.' It does not explicitly state that this tool searches posts, nor does it distinguish it from sibling tools like get_search_people or get_search_communities. The verb 'search_posts' is implied in the name, but the description provides no explicit purpose. This is clearer than a pure tautology but still vague.
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?
There is no guidance on when to use this tool versus alternatives. Sibling tools like get_auto_complete, get_posts_comments, and get_search_* tools exist, but the description gives no context for selecting this specific tool. No mentions of prerequisites, exclusions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_search_commentssearch-commentsDInspect
search-comments Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| nsfw | No | - Whether to retrieve content that is not safe for work (e.g., 18+ content) - Default: `false` - The `true` is yes, the `false` is no | |
| sort | No | - Sort by - Default: `relevance` - Choose one of the values below - `relevance`: Relevance - `top`: Top - `new`: New | |
| query | No | - Required: true - Ex: `gaming` | |
| nextPage | No | - The page index, for paging purpose - Leave it blank for the first time - The `nextPage` can be retrieved from response of this endpoint(meta->nextPage) - Ex: `MjU=` |
Tool Definition Quality
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, but it only mentions billing credits. It does not disclose return values, pagination behavior, required authorization, or any side effects. The schema mentions nextPage from meta, but this is in structured fields, not the description.
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 short, but this is under-specification rather than effective conciseness. The phrase 'search-comments' is redundant with the title, and the billing note is the only additional piece of information. There is no meaningful structural 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?
This is a search tool with four parameters, no output schema, and no annotations. The description provides none of the context needed to understand what the tool returns, how pagination works, or how it differs from the many sibling search tools. This is far from 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 description coverage is 100%, and each parameter in the input schema has a meaningful description, including defaults, examples, and enum options. The tool description itself adds no parameter information, but the baseline of 3 applies because the schema already documents the parameters well.
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 is just 'search-comments', which restates the tool's title/name and provides no verb or resource to explain what the tool does. It does not clarify the scope of the search or distinguish it from sibling tools like get_posts_comments or get_subreddit_comments.
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?
There is no usage guidance at all. The description does not mention when to use this tool versus alternatives, nor does it provide context such as typical use cases or prerequisites. This qualifies as 'no guidance'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_search_communitiessearch-communitiesDInspect
search-communities Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| nsfw | No | - Whether to retrieve content that is not safe for work (e.g., 18+ content) - Default: `false` - The `true` is yes, the `false` is no | |
| query | No | - Required: true - Ex: `gaming` | |
| nextPage | No | - The page index, for paging purpose - Leave it blank for the first time - The `nextPage` can be retrieved from response of this endpoint(meta->nextPage) - Ex: `MjQ=` |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description carries the full burden of behavioral disclosure. The description only repeats the tool name and billing rate, providing zero information about side effects, authentication, rate limits, or response behavior. This is completely inadequate for a search tool that likely makes network calls.
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 short, but this is under-specification rather than conciseness. The billing note adds no tool-usage value and is better suited for metadata. It lacks any substantive content, so it cannot be credited for being 'tight' when it fails to convey 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 lack of annotations, no output schema, and no description of return structure or behavior, the description is completely inadequate. A search tool with three parameters and pagination is non-trivial, yet the description ignores all of this. The tool is unusable for an AI agent relying on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed parameter descriptions for nsfw, query, and nextPage. Although the main description adds no parameter guidance, the schema already explains each parameter sufficiently. Per the rubric, the baseline is 3 when schema coverage is high, and the description does not need to add more.
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 is essentially a restatement of the tool name ('search-communities') plus billing information ('Billing per call: 1 Credits'). It does not explain what the tool does with the search or what resources it acts on. At best it's a tautology, offering no new semantic content about the tool's purpose.
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 about when to use this tool versus its siblings such as get_search_comments or get_search_media. The description lacks any context for when this tool is appropriate, prerequisites, or exclusions. No alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_search_mediasearch-mediaDInspect
search-media Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| nsfw | No | - Whether to retrieve content that is not safe for work (e.g., 18+ content) - Default: `false` - The `true` is yes, the `false` is no | |
| sort | No | - Sort by - Default: `relevance` - Choose one of the values below - `relevance`: Relevance - `hot`: Hot - `top`: Top - `new`: New - `comments`: Comment count | |
| time | No | - Time - Default: `all` - Choose one of the values below - `all`: All time - `year`: Past year - `month`: Past month - `week`: Past week - `day`: Today - `hour`: Past hour | |
| query | No | - Required: true - Ex: `gaming` | |
| nextPage | No | - The page index, for paging purpose - Leave it blank for the first time - The `nextPage` can be retrieved from response of this endpoint(meta->nextPage) - Ex: `MjQ=` |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It does not mention any outcomes, side effects, return format, or constraints. The tool could be a read or mutation; nothing is disclosed. This is a complete gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but not helpfully concise. It contains a single sentence about billing that provides no functional information. This is under-specification rather than conciseness, similar to the 'Process' example, which earned a 2 for being too terse to be useful.
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 tool has 5 parameters, no annotations, and no output schema. Given this complexity, the description is wholly inadequate. It must explain the tool's purpose, typical use cases, and possibly pagination, but states only billing. The agent cannot determine what the tool does or how to invoke it 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?
Schema description coverage is 100% with detailed parameter descriptions, examples, and defaults. The tool description adds nothing beyond the schema. Per the rubric, a high-coverage schema sets a baseline of 3, and the description does not need to add parameter semantics. However, it also does not add any extra context, so a neutral 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 is just 'search-media Billing per call: 1 Credits.' It does not state what the tool does, beyond the title. The name 'get_search_media' hints it searches media, but the description provides no verb, resource, or scope. It is essentially a tautology, failing to distinguish from sibling search tools.
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 about when to use this tool versus alternatives like get_search_comments, get_search_communities, etc. There are no context cues, prerequisites, or exclusions. The single sentence about billing offers no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_search_peoplesearch-peopleDInspect
search-people Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| nsfw | No | - Whether to retrieve content that is not safe for work (e.g., 18+ content) - Default: `false` - The `true` is yes, the `false` is no | |
| query | No | - Required: true - Ex: `gaming` | |
| nextPage | No | - The page index, for paging purpose - Leave it blank for the first time - The `nextPage` can be retrieved from response of this endpoint(meta->nextPage) - Ex: `MjQ=` |
Tool Definition Quality
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 fails to disclose whether this is a read-only operation, what data is returned, or any side effects. The only extra detail is billing per call, which is not behavioral 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 extremely short, but it is under-specification rather than concise. It lacks essential information and simply repeats the title. The billing note is irrelevant to tool usage, so the content does not earn 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 that there is no output schema and no annotations, a complete description is critical. This tool is a search endpoint with paging and filtering, yet the description provides zero context about response format, pagination handling, or use cases. It is completely inadequate.
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%, meaning the schema itself documents all three parameters (nsfw, query, nextPage). The tool description adds no additional parameter context, so the baseline of 3 applies.
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 is essentially the title 'search-people' plus billing info, repeating the tool name without adding any verb or resource detail. It does not state what the tool does beyond the name, making it tautological.
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 like get_search_comments or get_search_communities. The description provides no context about 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.
get_subreddit_awarding_totalssubreddit/awarding-totalsDInspect
subreddit/awarding-totals Group: Subreddit. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| groupId | No | - Required: true - Ex: `t3_54z4f7` |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention any effects, authorization needs, rate limits, or return handling. It only indicates a billing cost, which is not behavioral. The description fails to inform the agent about what happens when the tool is invoked.
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, but it is not concise in the sense of delivering useful information. It includes irrelevant billing details and a generic group label. It is under-specified, but it is not verbose. The structure is minimal and does not front-load the 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 tool's simplicity (only one parameter) and lack of output schema, the description could be minimal but still should state what the tool returns or does. It does not describe the function, and with no output schema, the agent has no idea what the response will be. The description is inadequate for selecting this tool over siblings.
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 the parameter (groupId), and the description adds no extra meaning, but the schema already provides a description and an example. Since schema coverage is complete, the baseline is 3, and the description does not need to compensate. However, it could have added context about the group ID type, but it is not required.
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 is 'subreddit/awarding-totals Group: Subreddit. Billing per call: 1 Credits.' It repeats the tool name and provides only a high-level group designation. It does not state what the tool does with a specific verb and resource, and it does not clarify the distinction from sibling tools.
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?
There is no guidance on when to use this tool versus alternatives. The description only mentions the group and billing, which is not relevant for usage decisions. Siblings exist with similar names, but no differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subreddit_commentssubreddit/commentsCInspect
subreddit/comments Group: Subreddit. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | - Sort by - Default: `confidence` - Choose one of the values below - `confidence`: Best - `top`: Top - `new`: New - `controversial`: Controversial - `old`: Old - `qa`: Q&A | |
| groupId | No | - Required: true - Ex: `t3_54z4f7` | |
| nextPage | No | - The page index, for paging purpose - Leave it blank for the first time - The `nextPage` can be retrieved from response of this endpoint(meta->nextPage) - Ex: `dDNfZXJ4dXdt` |
Tool Definition Quality
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. The description is nearly empty, lacking any information about side effects, access requirements, rate limits, or pagination behavior. The schema hints at paging via nextPage, but the description does not mention any behavioral traits. It does not even state that it is a read operation, but since the tool name implies fetching comments, it may be read-only; however, without explicit disclosure, it's 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?
The description is extremely short, but it is under-specification, not conciseness. It contains a single sentence that repeats the name and adds billing info, which is not useful. It does not front-load important information; it is essentially a placeholder. The description is too sparse to be considered well-structured.
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 that the tool has 3 parameters, no output schema, and no annotations, the description is severely incomplete. It lacks any explanation of what the tool returns, how pagination works, or how it relates to similar tools. The complexity is moderate, but the description provides virtually no context. This is far below the minimum 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 schema description coverage is 100%, meaning each parameter is documented in the schema with explanations and examples. The description adds no additional semantic meaning beyond the schema. For instance, the description does not clarify that groupId is the subreddit post ID or that sort options are for comment ordering. Since the schema already covers parameter semantics, the baseline is 3, and the description does not enhance it.
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 is merely a repetition of the tool name and title, stating 'subreddit/comments Group: Subreddit. Billing per call: 1 Credits.' It does not state what the tool does, such as retrieving comments from a subreddit. It fails to mention that it fetches comments for a given subreddit post identifier. The verb and resource are not explicit, and it does not distinguish from sibling tools like get_posts_comments or get_search_comments. Therefore, it is a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only indicates billing cost, which is irrelevant for selecting the tool. There is no mention of context, prerequisites, or exclusions. The tool name suggests it is for subreddit comments, but the description doesn't clarify when to choose it over siblings like get_posts_comments or get_search_comments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subreddit_searchsubreddit/searchCInspect
subreddit/search Group: Subreddit. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | - Sort by - Default: `top` - Choose one of the values below - `hot`: Hot - `new`: New - `top`: Top - `controversial`: Controversial - `rising`: Rising | |
| time | No | - Time - Default: `all` - Choose one of the values below - `all`: All time - `hour`: Past hour - `day`: Past 24 hours - `week`: Past week - `month`: Past month - `year`: Past year | |
| query | No | - Required: true - Ex: `gaming` | |
| nextPage | No | - The page index, for paging purpose - Leave it blank for the first time - The `nextPage` can be retrieved from response of this endpoint(meta->nextPage) - Ex: `dDNfZXJ4dXdt` |
Tool Definition Quality
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 disclosing behavior. It only mentions billing per call, which is a minor operational detail. It does not clarify what the search returns, whether it requires authentication, rate limits, or any side effects. Given no annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short ('subreddit/search Group: Subreddit. Billing per call: 1 Credits.'), but this is under-specification, not conciseness. It omits essential purpose and usage information. There is no useful structure or front-loading of key details.
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, no annotations, and a non-trivial 4-parameter tool with pagination, the description is incomplete. The schema handles parameters well, but the tool's purpose and return format are undocumented, making it difficult for an agent to understand what the tool accomplishes.
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 already covers 100% of parameter descriptions, including defaults, enums, examples, and paging via nextPage. The description adds nothing beyond that. Per the baseline for high schema coverage, this scores a 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 only repeats the tool name and a generic billing note: 'subreddit/search Group: Subreddit. Billing per call: 1 Credits.' It does not state what the tool does (e.g., search within a subreddit) and does not differentiate from sibling search tools like get_search_posts or get_subreddit_comments. This is effectively a tautology of the name/title.
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?
There is no guidance on when to use this tool versus alternatives. The sibling tools include multiple search variants, but the description provides no context about the tool's scope (e.g., searching within a subreddit) or when it should be preferred. This is misleading because the name suggests subreddit search, but no details support that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- Alicense-qualityDmaintenanceEnables access to Reddit data including posts, comments, user profiles, and subreddit information through a unified API interface with token-efficient TOON format output.10MIT
- Alicense-qualityCmaintenanceEnables AI agents to access public Reddit data via JSON endpoints, including subreddit trending posts, keyword search, and post details with comments, without authentication.10MIT
- AlicenseAqualityCmaintenanceProvides read-only access to public Reddit discussions via official OAuth, with tools to list posts, search subreddits, and retrieve posts and comments.4MIT
- AlicenseAqualityBmaintenanceEnables AI assistants to browse Reddit, search posts, analyze user activity, and fetch comments without requiring API keys. Features smart caching, clean data responses, and optional authentication for higher rate limits.851,883798MIT