Server Details
Reddit: Reddit Data API offers streamlined access to Reddit’s public data, like posts, comments.
- 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.4/5 across 31 of 31 tools scored.
Each tool targets a distinct resource and action combination (e.g., get_hot vs get_subreddit_hot vs get_user_posts). The scope is clearly delineated by prefixes like 'get_subreddit' and 'get_user', making it easy for an agent to pick the right tool.
All tools follow the consistent 'get_<resource>_<modifier>' pattern using snake_case. Even get_by_id fits the general get_ prefix style. The naming is uniform and predictable across 31 tools.
With 31 tools, the count exceeds the 25+ threshold considered too many. While Reddit has many read endpoints, this server covers only GET operations and still feels bloated, especially with multiple near-duplicate sort variants. It could be consolidated.
The tool surface is entirely read-only (only get_* operations). For a Reddit integration, obvious write operations like posting, commenting, voting, and moderation actions are missing. This creates significant gaps for many use cases and limits the server to exploration only.
Available Tools
31 toolsget_bestBestDInspect
Best Group: Explore. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| show | No | ||
| after | No | ||
| count | No | ||
| limit | No | ||
| before | No | ||
| sr_detail | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It fails to mention what the tool returns, whether it has side effects, or any operational constraints. 'Billing per call: 1 Credits' is a cost note, 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 short, but this is under-specification, not conciseness. It contains no substantive information and does not earn its place. A single vague phrase does not constitute a useful tool 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 six parameters, no output schema, no annotations, and a meaningless description, the tool is entirely underspecified. The agent cannot infer the tool's purpose, input requirements, or return value, making it unusable in practice.
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 0% and the description adds no parameter information. All six parameters are undocumented in both the schema and the description, leaving the agent completely in the dark about what 'show', 'after', 'count', 'limit', 'before', and 'sr_detail' mean.
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 'Best Group: Explore' provides no clear verb or resource. It does not state what the tool does, and 'Explore' is too vague to distinguish it from sibling tools like get_hot or get_top. It reads more like a heading than a functional description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no indication of when to use this tool versus alternatives. There is no mention of scenarios, prerequisites, or exclusions. The agent has no guidance on choosing get_best over similar listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_by_idBy IDDInspect
By ID Group: Explore. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| names | No |
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 only disclosed trait is billing cost, which is not a behavioral guarantee, side effect, return behavior, or access requirement. The tool's actual behavior—such as accepting IDs to fetch records—is not disclosed.
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 this is under-specification, not efficient conciseness. 'By ID Group: Explore.' carries no instructional value, and the billing sentence, while relevant, does not compensate for the lack of semantic 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?
Even for a single-parameter lookup tool, the description is severely incomplete. It lacks the resource being fetched, how the parameter is used, expected output, any constraints, and how this tool differs from the extensive sibling list. Without annotations or output schema, this description does not enable safe or correct agent use.
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 0%, so the description needed to compensate for the undocumented 'names' parameter, but it does not mention it at all. The schema example is the only hint that IDs are comma-separated. The description adds zero meaning about parameter format, meaning, or constraints.
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 'By ID Group: Explore. Billing per call: 1 Credits.' provides no verb, resource, or action statement. It is effectively a category label and billing note, not a statement of what the tool does. The name 'get_by_id' implies fetching by identifier, but the description itself is empty of purposeful intent.
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 about when to use this tool versus its many siblings like get_best, get_search, or get_user_posts. No contextual trigger, no exclusions, and no alternative recommendation are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_commentsGet CommentDInspect
Get Comment Group: Explore. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| comment_id | No |
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, but it only mentions 'Billing per call: 1 Credits' and the vague 'Explore.' It does not disclose whether this is a read-only operation, what data it returns, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not informative; 'Explore' is filler and the billing note belongs in structured metadata rather than the purpose description. Every sentence should add value, but here no sentence meaningfully clarifies the tool's function.
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 simple schema and absence of annotations, the description still fails to explain what a 'Comment Group' is, how to retrieve a comment, or how this differs from the many sibling comment tools. It is insufficient for correct 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 schema has one parameter, comment_id, with no description, and schema description coverage is 0%. The tool description does not compensate by explaining the parameter's format, optionality, or meaning, leaving the agent to infer from the parameter name alone.
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 'Get Comment Group: Explore' restates the tool's name and adds the vague action 'Explore,' which does not clearly explain what the tool does. It fails to distinguish from sibling tools like get_subreddit_comments or get_user_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 guidance on when to use this tool versus alternatives. The description provides no context, prerequisites, or exclusions, leaving the agent to guess among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_controversialControversialDInspect
Controversial Group: Explore. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| t | No | ||
| show | No | ||
| after | No | ||
| count | No | ||
| limit | No | ||
| before | No | ||
| sr_detail | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden. It discloses only billing per call, not whether the operation is read-only, what data shape is returned, what pagination semantics apply, or whether authentication/authorization is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it is under-specified rather than helpfully concise. 'Controversial Group: Explore.' adds almost no operational information, and the billing note does not make the description effective.
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 absent annotations, missing output schema, and 7 unexplained parameters, the description is far from complete. It does not explain the tool's return value, pagination behavior, or sorting semantics, leaving the agent to guess how to invoke 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?
The schema has 7 parameters and 0% coverage, and the description adds no meaning to any of them. Param names like t, show, after, before, sr_detail, count, and limit are left unexplained, which is especially problematic since the description must compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description says only 'Controversial Group: Explore.' This is too vague to state what resource is acted on, what verb is actually performed, or whether it returns posts/comments. It also does not differentiate it from sibling tools like get_subreddit_controversial or get_hot.
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 for when to use this tool versus alternatives. The description provides no context about sorting scope, subreddit-specific usage, or when a sibling such as get_top or get_controversial would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_hotHotDInspect
Hot Group: Explore. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| t | No | ||
| show | No | ||
| after | No | ||
| count | No | ||
| limit | No | ||
| before | No | ||
| sr_detail | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to clarify safety or side effects, the description carries the full burden but only mentions billing per call. It does not disclose read-only behavior, data scope, or any potential impacts, which is insufficient for a 7-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse, but this is under-specification rather than effective conciseness. It front-loads no useful information and wastes the limited space on a vague tagline.
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 7 parameters, no output schema, no annotations, and a completely vague description, the tool is far from adequately documented. The description does not explain the tool's purpose, expected output, or parameter usage, making it nearly impossible for an agent to invoke 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 0%, and the description provides no explanation for any of the 7 parameters like 't', 'show', 'after', 'count', etc. All parameters remain cryptic, and the description fails to compensate for the lack of schema metadata.
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 'Hot Group: Explore' is vague and tautological, reiterating the name without specifying what 'hot' refers to or what actions are performed. It does not differentiate from siblings like get_top, get_rising, or get_controversial.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent without decision-support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_newNewDInspect
New Group: Explore. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| t | No | ||
| show | No | ||
| after | No | ||
| count | No | ||
| limit | No | ||
| before | No | ||
| sr_detail | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but it only mentions billing (1 credit) which is not a behavioral trait. It does not state what data it returns, side effects, or any constraints.
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?
While the description is extremely short (one sentence), it is under-specified rather than concise. It does not earn its place by adding value; it is merely a fragment that could be inferred from the tool name.
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 complexity (7 parameters, no output schema, no annotations), the description is entirely inadequate. It gives no indication of what 'New' means, what the parameters control, or what the expected output is.
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 0%, and the description provides zero information about the 7 parameters (t, show, after, count, limit, before, sr_detail). The description offers no compensation for the undocumented parameters.
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 "New Group: Explore" is a vague label, not a clear statement of what the tool does. It fails to specify a verb and resource, and does not differentiate from siblings like get_hot or get_top, which are also listing 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 its many siblings (e.g., get_best, get_top, get_subreddit_new). No context is provided for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_risingRisingDInspect
Rising Group: Explore. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| t | No | ||
| show | No | ||
| after | No | ||
| count | No | ||
| limit | No | ||
| before | No | ||
| sr_detail | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only mentions billing (1 credit) but does not disclose what the tool does, what it returns, or any side effects. This is insufficient for a tool of this complexity.
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. Every sentence fails to add value beyond the title.
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 7 parameters, no annotations, no output schema, and a 0% coverage, the description is critically incomplete. It does not help an agent understand what the tool does or how to use 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 0% and the description adds no meaning to the 7 parameters (e.g., t, show, after, count, limit, before, sr_detail). There is no explanation of any parameter semantics.
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 'Rising Group: Explore' is vague and does not specify what the tool does beyond the name 'Rising'. It lacks a verb-resource structure and does not distinguish from siblings like get_hot or get_new.
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 vs alternatives. The description gives no contextual cues about appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_searchSearchDInspect
Search Group: Explore. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| t | No | ||
| show | No | ||
| sort | No | ||
| type | No | ||
| after | No | ||
| count | No | ||
| limit | No | ||
| before | No | ||
| category | No | ||
| sr_detail | No | ||
| restrict_sr | No | ||
| include_facets | No |
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 cost rather than behavioral trait. There is no information about side effects, required authentication, or what results are returned.
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, which is concise, but it is under-specified rather than well-structured. The phrase 'Search Group: Explore' is more of a category label than a meaningful description, and the billing note is peripheral. The brevity does not earn its place because it conveys almost no useful 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?
Given the tool's complexity (13 parameters, no output schema, no annotations), the description is grossly inadequate. It does not explain the expected input, output, or any operational context, making it nearly impossible for an agent to use 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?
With 13 parameters and 0% schema description coverage, the description must compensate, but it adds zero parameter information. The parameters like 'q', 't', 'show', 'sort' remain entirely undefined, offering no semantic value beyond their names.
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 'Search Group: Explore' is a tautology that merely restates the tool's name and title without specifying what is being searched or the scope. It fails to distinguish from sibling tools like get_subreddit_search or get_user_search, providing no verb+resource clarity.
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 the many sibling search tools. The description offers no context about intended use cases, filters, or limitations, leaving the agent without actionable direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subreddit_aboutSubreddit AboutDInspect
Subreddit About Group: Subreddit. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| subreddit | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavior. It only mentions billing per call, which is a cost metric, not behavioral information such as read-only nature, return format, or potential side effects. No value is added beyond what the tool name implies.
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. It contains only a category label and billing note, with no substantive content, so it does not earn credit for brevity.
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?
Even for a simple single-parameter tool, the description is wholly inadequate. With no output schema or annotations, the tool's purpose, parameters, and behavior are all undefined, making it impossible for an agent to use 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 0% and the description does not mention the 'subreddit' parameter at all. The schema provides a string type and example, but the description fails to add any meaning, such as what the parameter should represent or how it affects the output.
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 'Subreddit About Group: Subreddit' essentially restates the tool name and title without using a specific verb or clarifying what action is performed. It does not state that the tool retrieves subreddit 'about' information, making it tautological rather than descriptive.
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_posts or get_subreddit_rules. The description lacks any contextual or preferential information, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subreddit_commentsSubreddit CommentsDInspect
Subreddit Comments Group: Subreddit. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| depth | No | ||
| limit | No | ||
| theme | No | ||
| article | No | ||
| comment | No | ||
| context | No | ||
| showmore | No | ||
| threaded | No | ||
| truncate | No | ||
| showedits | No | ||
| showmedia | No | ||
| showtitle | No | ||
| sr_detail | No | ||
| subreddit | No |
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 — and it discloses nothing. The only non-schema content is a billing note ('Billing per call: 1 Credits'), which explains no behavior. There is no indication of what the tool returns, how parameters affect output, or whether it retrieves comments for a subreddit.
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 text is short, but every word spent is non-functional: 'Subreddit Comments Group: Subreddit' is a label, and 'Billing per call: 1 Credits' is billing metadata. Under-specification is not conciseness — a term for the purpose and usage would earn its place. The structure is effectively empty despite being well-formatted as a single sentence.
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 high-complexity tool with 15 parameters, no output schema, no annotations, and no description of return values or parameter effects — yet the description is a one-line label. The agent receives no adequate understanding of input construction or outcome. This provides complete descriptions, unlike the highly deficient one at hand.
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 0% across 15 string parameters, and the description adds no meaning to any of them. Even the central `subreddit` parameter is only hinted at via its schema example 'politics'; the description does not mention it. With the high parameter count, the description heavily needed to compensate, and overwhelmingly failed.
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 merely restates the title as 'Subreddit Comments Group' and adds billing metadata; it contains no verb or functional statement about what the tool does. It also fails to distinguish `get_subreddit_comments` from the sibling `get_comments`, which plausibly overlaps in scope. This is essentially a tautology rather than a purpose definition.
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 its 27 siblings, including closely named alternatives like `get_comments`, `get_subreddit_posts`, or `get_subreddit_about`. The description provides no context, no exclusions, and no conditions. An agent gets no basis for selecting this tool over `get_comments`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subreddit_controversialSubreddit Posts > ControversialDInspect
Subreddit Posts > Controversial Group: Subreddit Posts. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| t | No | ||
| show | No | ||
| after | No | ||
| count | No | ||
| limit | No | ||
| before | No | ||
| sr_detail | No | ||
| subreddit | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description provides no behavioral information. It doesn't mention parameters like 't' for time range, authentication requirements, rate limits, or what happens with invalid subreddits. The agent is left completely in the dark about side effects or data fetching behavior.
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 does not earn its place; it only repeats the title and billing. It's not structured, lacks front-loading of key info, and is essentially a placeholder rather than a concise 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?
Given the complexity of 8 parameters and no output schema or annotations, the description is completely inadequate. It fails to explain what the tool returns, how to specify the subreddit (though a 'subreddit' parameter exists), or how pagination works. The tool is unusable based on this 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?
With 8 parameters at 0% schema description coverage, the description must compensate, but it provides no parameter explanations. The schema only shows names like 't', 'show', 'after', which are cryptic. The description adds zero value for understanding parameters like 'limit' or 'before'.
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 simply repeats the title 'Subreddit Posts > Controversial' and adds billing info, which is not a clear statement of what the tool does. It implies retrieving controversial posts from a subreddit but lacks a specific verb-resource description. The title and group hint at the purpose, but the description itself is 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 is given on when to use this tool versus alternatives like get_subreddit_top or get_controversial. The description does not mention sorting by time period or any usage context. It only states the billing, which is irrelevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subreddit_hotSubreddit Posts > HotDInspect
Subreddit Posts > Hot Group: Subreddit Posts. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| g | No | ||
| show | No | ||
| after | No | ||
| count | No | ||
| limit | No | ||
| before | No | ||
| sr_detail | No | ||
| subreddit | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must fully disclose behavior, but it only contains a group label and billing note. It does not mention read-only semantics, authentication, pagination, or any caveats.
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 text is short, but it is under-specified rather than concisely informative. 'Billing per call: 1 Credits' is operational metadata, and 'Group: Subreddit Posts' is a redundant structure label. No sentence helps the agent select or invoke the tool correctly.
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 tool has 8 parameters, no required fields, no annotations, and no output schema, yet the description gives no context about ordering, default values, pagination behavior, or return payload. The agent would have no basis to understand what the endpoint returns or how to configure the request.
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 0% and the description describes none of the 8 parameters. The schema only lists parameter names and a few examples, with no meaning for g, show, after, before, or sr_detail. The description adds no compensatory clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a restatement of the title: 'Subreddit Posts > Hot Group: Subreddit Posts.' There is no verb or explicit statement like 'retrieves hot subreddit posts,' so the tool name carries the entire meaning. It weakly distinguishes from siblings via 'Hot,' but does not explain what the tool actually does.
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 usage guidance is provided: no 'when to use,' no comparison to alternatives like get_subreddit_new or get_subreddit_top, and no mention of required context. The description gives no direction on selecting this over its many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subreddit_moderatorsSubreddit ModeratorsDInspect
Subreddit Moderators Group: Subreddit. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| subreddit | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses only 'Billing per call: 1 Credits.' It does not mention side effects, permissions, rate limits, or any other behavioral traits. With no annotations, the description carries full burden but fails to address behavior.
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 not concise in a useful way; it repeats the title and adds billing info. It lacks a structured explanation of the tool's function.
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 simple tool and single parameter, the description should at least state what the tool returns or when to use it. It does neither, making the description incomplete for understanding the tool's role.
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 lists a single 'subreddit' parameter with an example, but the description does not clarify its meaning. It merely repeats 'Subreddit.' without explaining that it is the subreddit name or how it is used.
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 title and adds 'Group: Subreddit.' It does not explicitly state that the tool retrieves the list of moderators for a given subreddit, making the purpose unclear.
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 like get_subreddit_about or get_subreddit_comments. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subreddit_newSubreddit Posts > NewDInspect
Subreddit Posts > New Group: Subreddit Posts. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| show | No | ||
| after | No | ||
| count | No | ||
| limit | No | ||
| before | No | ||
| sr_detail | No | ||
| subreddit | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only mentions billing cost, not side effects, rate limits, required permissions, or output format. This is entirely insufficient for a tool that likely makes API 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 it is not appropriately concise—it omits essential functional information. The two sentences (category label and billing) are not structured to help the agent understand the tool; the billing note is tangential and the category label is redundant with the tool name.
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 complexity (7 optional parameters, no output schema, no annotations), the description is grossly incomplete. It does not explain what the tool does, how to use it, or what results to expect, making it virtually unusable for an AI agent.
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 has 7 parameters with 0% description coverage, and the tool description mentions none of them. It fails to explain the meaning of parameters like 'show', 'after', 'limit', or 'subreddit', leaving the agent without any guidance on how to construct valid inputs.
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 category label ('Subreddit Posts > New Group: Subreddit Posts') rather than a clear statement of what the tool does. It implies fetching new subreddit posts but fails to explicitly state an action or resource, making it nearly a tautology of the tool name.
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 its many siblings (e.g., get_hot, get_top, get_controversial). No context, prerequisites, or alternative recommendations are provided, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subreddit_postsSubreddit PostsDInspect
Subreddit Posts Group: Subreddit Posts. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| t | No | ||
| show | No | ||
| type | No | ||
| after | No | ||
| count | No | ||
| limit | No | ||
| before | No | ||
| category | No | ||
| sr_detail | No | ||
| subreddit | No | ||
| restrict_sr | No | ||
| include_facets | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only extra information is 'Billing per call: 1 Credits,' which is a cost detail, not behavioral disclosure. With no annotations provided, the description must explain what the tool does, its side effects, or return behavior, but it does none of that.
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 not effectively concise—it wastes words repeating the title and adding a billing note. It fails to provide any substantive content, so it is under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 13 parameters, zero schema coverage, no annotations, and no output schema, the description is grossly inadequate. It provides no information to help an agent understand what the operation 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 0%, and the description provides no parameter explanations. All 13 parameters (q, t, show, type, after, count, limit, before, category, sr_detail, subreddit, restrict_sr, include_facets) are undocumented, leaving the agent with no semantic guidance.
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 Posts Group: Subreddit Posts.' which merely restates the tool name/title. It uses no verb indicating an action, no resource beyond the name, and doesn't distinguish from sibling tools like get_subreddit_new or get_subreddit_top.
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. No context, no exclusions, no mention of suitable use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subreddit_risingSubreddit Posts > RisingDInspect
Subreddit Posts > Rising Group: Subreddit Posts. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| show | No | ||
| after | No | ||
| count | No | ||
| limit | No | ||
| before | No | ||
| sr_detail | No | ||
| subreddit | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It discloses nothing about return format, pagination behavior, authentication needs, rate limits, or side effects. The description is purely categorical and fails to reveal any behavioral traits.
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 (one line) but is under-specified, not concisely informative. It front-loads only a category and billing note, omitting essential functional details. For a tool with 7 parameters, this is far 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 the tool's complexity (7 parameters, no annotations, no output schema), the description is completely inadequate. It provides no information on what the tool returns, how to use the parameters, or when to choose it over similar subreddit post tools. The description fails to make the tool usable without external knowledge.
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 0%, and the description adds no meaning to the 7 parameters (show, after, count, limit, before, sr_detail, subreddit). The example values in the schema (e.g., 'politics' for subreddit) are the only hints, and the description provides no parameter explanations or usage context.
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 name and title imply it retrieves rising posts from a subreddit, but the description is a categorical label ('Subreddit Posts > Rising') and billing info, restating the title without a clear verb+resource statement. It adds no functional purpose beyond what the name suggests, and does not differentiate it from siblings like get_subreddit_hot or get_subreddit_new.
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 vs alternatives. It does not mention context, prerequisites, or exclusions, leaving the agent to guess based solely on the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subreddit_rulesSubreddit RulesDInspect
Subreddit Rules Group: Subreddit. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| subreddit | No |
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, but it only mentions billing. It does not indicate whether the operation is read-only, what inputs affect results, or what the output might look like. This is a complete lack of 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 this is under-specification rather than effective conciseness. Every word is either redundant with the title or irrelevant to tool usage (billing), so the structure provides no actionable 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?
Given the lack of annotations, output schema, and parameter documentation, the description needed to explain the tool's function and context. It is completely inadequate for an agent to select or invoke this tool correctly, especially alongside many similar subreddit-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single parameter 'subreddit' with 0% schema description coverage, and the description does not explain the parameter's meaning or format. The description adds no semantic value beyond the bare schema property name, leaving the agent without guidance on what value to provide.
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 'Subreddit Rules Group: Subreddit. Billing per call: 1 Credits.' merely restates the tool name and title, providing no verb or clear action. It fails to say that the tool retrieves subreddit rules, making it a tautology rather than a purpose statement.
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 or how it differs from sibling tools. The only non-name information is billing cost, which does not help with usage decisions. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subreddit_searchSubreddit SearchDInspect
Subreddit Search Group: Subreddit. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| t | No | ||
| show | No | ||
| sort | No | ||
| type | No | ||
| after | No | ||
| count | No | ||
| limit | No | ||
| before | No | ||
| category | No | ||
| sr_detail | No | ||
| subreddit | No | ||
| restrict_sr | No | ||
| include_facets | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only mentions billing, not side effects, required permissions, or any operational behavior. Agents cannot infer whether this is a read or write operation, what it returns, or any constraints.
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?
While the description is short, this is under-specification rather than conciseness. It contains no functional content and merely restates the tool name, making it a tautology with no earned sentences.
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 complexity (14 parameters, no output schema, no annotations), the description is critically inadequate. It fails to explain any aspect of the tool's functionality, leaving the agent completely uninformed.
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 0% and the description provides no parameter explanations. The 14 parameters (q, t, show, etc.) are completely undocumented in both the schema and the description, leaving the agent unable to construct valid calls.
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 'Subreddit Search Group: Subreddit. Billing per call: 1 Credits.' essentially repeats the title and adds billing metadata. It does not state what the tool does, lacks a verb+resource structure, and fails to distinguish it from numerous sibling tools like get_search or get_subreddit_posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are over 20 sibling tools with overlapping names (e.g., get_search, get_subreddit_posts, get_subreddit_about), but the description gives zero context about appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subreddits_searchSearch SubredditsCInspect
Search Subreddits Group: Subreddit. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| show | No | ||
| sort | No | ||
| after | No | ||
| count | No | ||
| limit | No | ||
| before | No | ||
| sr_detail | No | ||
| show_users | No | ||
| search_query_id | No | ||
| typeahead_active | No |
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 only mentions billing ('Billing per call: 1 Credits') which is a minor detail, but provides no information about authentication requirements, rate limits, pagination behavior, or what the response contains for this search functionality.
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 not effectively concise - it's under-specified. While 'Search Subreddits' is direct, the additional text about group and billing is low-value. The description doesn't earn its place by providing meaningful information to the agent.
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 search tool with 11 parameters, no annotations, no output schema, and a search-related sibling (get_subreddit_search), this description is severely incomplete. The agent cannot determine which parameters are important (like q for the query), what format values should take, or how results are returned.
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 0%, and the description adds no parameter context. There are 11 parameters with no documentation beyond their parameter names. The description doesn't compensate for the lack of schema information, leaving the agent to guess what many parameters like 'show', 'sr_detail', 'show_users', and 'typeahead_active' do.
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 'Search Subreddits' with the group 'Subreddit' gives a basic idea that this tool searches subreddits. However, it doesn't clearly distinguish itself from siblings like get_subreddit_search or get_subreddit_posts which could also perform searching.
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 usage guidelines are provided. The description doesn't mention when to use this tool versus alternatives like get_search, get_subreddit_search, or other sibling tools. There's no context about preferred use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subreddit_topSubreddit Posts > TopCInspect
Subreddit Posts > Top Group: Subreddit Posts. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| t | No | ||
| show | No | ||
| after | No | ||
| count | No | ||
| limit | No | ||
| before | No | ||
| sr_detail | No | ||
| subreddit | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral transparency at all. It only mentions billing cost ('Billing per call: 1 Credits'), which is a minor operational detail but does not disclose whether this is a read operation, what side effects might occur, or any limitations. With no annotations, the description carries the full burden, and it fails to convey that this is a safe read-like 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 extremely short (one sentence plus billing line), which is concise in word count but under-specifies. It is front-loaded with the title, but the content is nearly useless. This is under-specification, not effective conciseness.
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 complexity (8 parameters, no annotations, no output schema, and many sibling tools), the description is grossly inadequate. It does nothing to help the agent understand the tool's purpose, parameters, or how it differs from similar tools like get_top or get_subreddit_posts.
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 0%, so the description must compensate for the 8 parameters, but it provides zero parameter details. The schema itself has no descriptions or enums, leaving all parameters ambiguous. The description adds no value in explaining what 't', 'show', 'after', 'before', 'sr_detail', etc., mean. This is a significant gap.
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 tautological restatement of the title and name ('Subreddit Posts > Top Group: Subreddit Posts.'), providing no additional information. It fails to state what the tool does beyond the implied 'get top posts from a subreddit,' which is inferred from the name and sibling tools. This is a low but not completely missing purpose clarity.
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 usage guidance is provided in the description. There is no mention of when to use this tool versus alternatives like get_subreddit_hot or get_subreddit_new, nor any prerequisites or context. The agent must infer from the name that it retrieves top posts, but there is no explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subreddit_wiki_indexSubreddit Wiki IndexDInspect
Subreddit Wiki Index Group: Subreddit Wiki. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| subreddit | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not mention what the tool returns, any side effects, or even a basic indication that it is a read 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 extremely short, but this is under-specification rather than conciseness. It lacks a clear sentence structure and fails to convey 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?
For a tool with a single parameter and no output schema, the description should clarify what the index represents and how it differs from similar tools. It provides none of that, making it inadequate for an agent to select or 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?
The schema shows a single 'subreddit' parameter with an example, but the description adds nothing beyond the schema. With 0% schema description coverage, the description should explain the parameter's purpose and format, which it does not.
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 a mere label ('Subreddit Wiki Index') with no verb or explanation of function. It restates the tool name and fails to distinguish from siblings like get_subreddit_wiki_page or get_subreddit_wiki_pages.
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 terse billing note provides no contextual information about appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subreddit_wiki_pageSubreddit Wiki PageDInspect
Subreddit Wiki Page Group: Subreddit Wiki. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| subreddit | No |
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 behavioral transparency. The only potentially useful behavioral detail is 'Billing per call: 1 Credits,' but the description never says whether this is read-only, what the returned page format is, or how errors for missing pages are handled.
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 and front-loaded, but its content is mostly categorical/billing metadata rather than a substantive functional specification. Brevity here is not valuable because the text does not explain what the tool does.
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 very small tool surface, but it is still incomplete: nothing states that it returns a wiki page, what page parameter format is expected, or how this differs from related wiki tools. Without an output schema or annotations, the description needed to provide at least basic return/usage context and it does not.
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 description adds no information at all about the parameters. With 0% schema description coverage, the tool description should have explained that 'page' is a wiki page slug and 'subreddit' indicates the target community; instead, only names and examples in the schema do any work.
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 grouping label and billing note: 'Subreddit Wiki Page Group: Subreddit Wiki. Billing per call: 1 Credits.' It does not state an action, such as retrieving or fetching a wiki page, nor does it explain what the response will contain. It mostly restates the title/name without giving a usable 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?
There is no guidance on when this tool should be used or when it should not be used. This is especially harmful because many sibling tools exist for wiki pages, wiki indexes, wiki revisions, and other subreddit content, and the description provides no way to distinguish this tool from them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subreddit_wiki_page_discussionsSubreddit Wiki Page DiscussionsDInspect
Subreddit Wiki Page Discussions Group: Subreddit Wiki. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| subreddit | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavior, return format, side effects, permissions, rate limits, or pagination. The description entirely fails to explain 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 text is short, but this is under-specification rather than effective conciseness. The first clause restates the title, and the billing note adds no functional value for tool selection or invocation.
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 description that is essentially tautological, the tool definition is severely incomplete. Even a simple two-parameter tool needs at least a one-sentence functional 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 0%, and the description adds no meaning for the 'page' and 'subreddit' parameters beyond the raw schema examples. The description does not compensate for the lack of parameter-level documentation.
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 merely restates the title ('Subreddit Wiki Page Discussions') and adds billing/grouping metadata; it contains no verb or action indicating what the tool does. The tool name suggests retrieving discussions for a wiki page, but the description itself provides no functional meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool or when to prefer a sibling tool. The description only mentions a group label and billing credits, which are not usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subreddit_wiki_page_revisionsSubreddit Wiki Page RevisionsDInspect
Subreddit Wiki Page Revisions Group: Subreddit Wiki. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| subreddit | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It provides none: no mention of return format, required permissions, pagination, or impact. The billing note ('1 Credits') is not behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but not appropriately sized; it omits essential information. The first phrase is a redundant restatement, and the billing note does not earn its place. It is under-specification, not conciseness.
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 two parameters, no annotations, and no output schema, the description fails to communicate basic purpose, expected input, or return value. It is completely inadequate for an agent to select and invoke 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 0%, so the description must compensate for the two parameters ('page' and 'subreddit'). It does not mention them at all, adding zero meaning beyond the bare schema examples.
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's title: 'Subreddit Wiki Page Revisions' with no verb or action. It does not state what the tool does (e.g., lists revisions for a specific wiki page). It only adds billing info, making it tautological and lacking purpose clarity.
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 siblings like get_subreddit_wiki_page or get_subreddit_wiki_revisions. The name hints at page-specific revisions, but the description gives no explicit usage context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subreddit_wiki_pagesSubreddit Wiki PagesDInspect
Subreddit Wiki Pages Group: Subreddit Wiki. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| subreddit | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions billing cost. It does not disclose what the tool returns, whether it requires authentication, or any side effects. The full burden is on the description, and it fails completely.
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 text is very short, but it is under-specified rather than efficiently concise. The sentences provide only a label and billing info, which do not earn their place because they do not help the agent understand the tool.
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?
Even for a simple one-parameter tool, a purpose statement and behavioral description are essential. This description is almost entirely absent, making it impossible to understand what the tool returns or how it differs from sibling wiki tools.
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 has one property (subreddit) with no description, and the description does not mention the parameter at all. With 0% schema description coverage, the description must compensate, but it provides no meaning beyond the parameter's name.
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 does not state a verb or action. It only provides a grouping label ('Subreddit Wiki Pages Group') and billing information, which does not clarify what the tool does. The name suggests 'get wiki pages' but the description fails to confirm that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like get_subreddit_wiki_index or get_subreddit_wiki_page. There is no mention of use cases 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_wiki_revisionsSubreddit Wiki RevisionsDInspect
Subreddit Wiki Revisions Group: Subreddit Wiki. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| subreddit | No |
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. It does not mention behavior, return values, side effects, authentication, or rate limits beyond a billing note. The description is devoid of any functional behavior.
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 text is short but not effectively concise—it conveys almost no useful information. The few words used are mostly metadata, not specification, so this is under-specification rather than efficient communication.
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 no output schema and a single parameter, but the description fails to compensate with any operational details. Given the existence of similar sibling tools and the absence of structured metadata, the description 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 0% and the description does not mention the 'subreddit' parameter at all. While the parameter is self-explanatory, the description adds zero value beyond the schema's example field.
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 fragment: 'Subreddit Wiki Revisions Group: Subreddit Wiki. Billing per call: 1 Credits.' It restates the tool's name without explaining what the tool does. There is no verb, resource, or scope, and it does not distinguish from siblings like get_subreddit_wiki_page_revisions.
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 vs. alternatives. Sibling tools include get_subreddit_wiki_page_revisions and get_subreddit_wiki_page, but the description offers no exclusions or context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_topTopDInspect
Top Group: Explore. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| t | No | ||
| show | No | ||
| after | No | ||
| count | No | ||
| limit | No | ||
| before | No | ||
| sr_detail | No |
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. It only mentions billing per call, which is a minor cost trait, but it does not explain whether this is a read operation, what it returns, or what parameters affect behavior.
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-specification is not true conciseness. It contains almost no useful information and the billing sentence does little to justify the tool.
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 7 undocumented parameters, no output schema, and no annotations, the description is desperately incomplete. The agent cannot realistically infer what this tool does, how to call it, or when to select 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 0%, all 7 parameters lack any definitions, and the description does not compensate. Parameter names like t, show, and before are ambiguous without documentation.
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 'Top Group: Explore' is vague and does not state a specific verb or resource. It does not explain what 'get_top' retrieves or how it differs from the many sibling listing tools. The only concrete statement is a billing note.
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 about when to use this tool versus alternatives like get_best, get_hot, or get_new. The description fails to mention any use case, criteria, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_user_commentsUser CommentsDInspect
User Comments Group: User. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| t | No | ||
| show | No | ||
| sort | No | ||
| type | No | ||
| user | No | ||
| after | No | ||
| count | No | ||
| limit | No | ||
| before | No | ||
| context | No | ||
| sr_detail | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it reveals no behavior: no sort semantics, pagination, data scope, or effects. The only additional fact is billing cost, which is 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 text is short, but this is under-specification rather than conciseness: it omits the operation, parameter meanings, and return behavior. The billing note is the only additional content and does not help an agent select or invoke the tool correctly.
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 an 11-parameter listing/filtering tool with no output schema and many closely related sibling tools, the description is critically incomplete. It fails to explain what the parameters control, what results are returned, or how this tool relates to other user-content tools.
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?
All 11 parameters are undocumented in both the schema and the description, with schema description coverage at 0%. The description adds no meaning to parameters such as t, show, sort, after, before, count, or limit.
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 'User Comments Group: User' and a billing cost, which mostly restates the title without an explicit verb such as 'retrieves' or 'lists.' It does not say what the tool does with user comments and fails to distinguish it from siblings like get_user_overview 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.
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 instead of alternatives such as get_user_posts, get_user_overview, or get_comments. The text gives only a group label and billing note, so the agent cannot infer selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_user_overviewUser OverviewDInspect
User Overview Group: User. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| t | No | ||
| sort | No | ||
| user | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it reveals nothing about side effects, output format, read-only status, or rate limits. The only extra information is billing cost, 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 short, but it is under-specified rather than concise. The two phrases 'User Overview Group: User' and 'Billing per call: 1 Credits' waste the limited space without conveying the tool's function, failing the 'every sentence earns its place' test.
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 3 parameters, no output schema, and no annotations, the description should explain the tool's purpose and parameter semantics. It does neither, making the tool effectively opaque to an AI agent.
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 has 3 parameters with 0% description coverage, and the description adds no meaning to 't', 'sort', or 'user'. Without any explanation of how these parameters affect the query, the agent cannot correctly construct a call.
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 'User Overview Group: User' and a billing note, with no verb or resource indicating what the tool actually does. It does not differentiate from sibling tools like get_user_comments or get_user_posts, and it fails to state that it returns an overview of a user's activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description offers no context about use cases, prerequisites, or exclusions, leaving the agent without any basis for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_user_postsUser PostsDInspect
User Posts Group: User. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| t | No | ||
| show | No | ||
| sort | No | ||
| type | No | ||
| user | No | ||
| after | No | ||
| count | No | ||
| limit | No | ||
| before | No | ||
| context | No | ||
| sr_detail | No |
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 all behavioral traits. It does not mention return behavior, side effects, rate limits, or any operational details. The only additional information is billing cost ('1 Credits'), which is 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 this is under-specification rather than conciseness. It contains only metadata ('Group: User', 'Billing per call') and lacks all functional substance, so it fails the purpose of a 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 11 parameters, 0% schema description coverage, no annotations, no output schema, and no description content, the tool is completely under-specified. An agent cannot infer what the tool does, what parameters mean, or what the response looks like.
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?
With zero schema description coverage and 11 parameters, the description provides no help. Parameters like 't', 'show', 'after', 'before', and 'sr_detail' are ambiguous; the description does not explain any of them or their relationships, leaving the agent to guess.
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 'User Posts Group: User. Billing per call: 1 Credits.' provides no verb or resource statement; it reads as a metadata label rather than a functional description. The name 'get_user_posts' implies retrieving posts for a user, but the description does not clearly state this or differentiate from siblings like 'get_user_comments' or 'get_user_overview.'
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, no context about required inputs, and no mention of prerequisites or typical use cases. The description is entirely silent on usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_user_searchUser SearchDInspect
User Search Group: User. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| t | No | ||
| sort | No | ||
| type | No | ||
| user | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for disclosing behavior. It mentions only billing, not effects, permissions, side effects, or output characteristics, leaving the agent completely uninformed.
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 text is extremely short (one sentence), which could appear concise, but it lacks substantive content. It is under-specified rather than purposefully concise, offering no instructional value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the tool's complexity (5 params), and absence of annotations, the description provides virtually no context. It does not explain return values, parameter usage, or behavioral nuances, making it wholly incomplete.
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 has 5 parameters with zero descriptions and zero schema description coverage. The description provides no information about any parameter, so it fails to add meaning beyond the bare schema properties.
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 restates the tool name ('User Search') and adds billing metadata ('Billing per call: 1 Credits'), providing no actual statement of what the tool does. It does not distinguish itself from sibling search tools like get_search or get_subreddit_search.
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. No context about use cases, prerequisites, or selection criteria is provided.
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
- AlicenseAqualityCmaintenanceProvides read-only access to public Reddit discussions via official OAuth, with tools to list posts, search subreddits, and retrieve posts and comments.4MIT
- 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
- FlicenseAqualityDmaintenanceEnables interaction with Reddit through a comprehensive API interface supporting both read-only operations (browsing posts, comments, user profiles) and authenticated actions (posting, commenting, voting) via OAuth2 authentication.7
- 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