Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description discloses that the server is read-only by design, that no posting/commenting/voting code exists, that mode only changes via user editing config.yaml, and that a scheduled mode change may be pending. These are concrete behavioral constraints that materially affect how an agent should reason about policy results.

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 front-loaded with the core content and usage indication, followed by the read-only constraint and policy guidance. Every sentence adds useful context; none is filler or redundant with the annotations.

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 zero-parameter read-only policy tool with an output schema, the description is fully sufficient. It tells the agent what the tool reports, when to consult it, and the behavioral/ethical guardrails applicable to using the policy information. Nothing needed for correct invocation or interpretation is missing.

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?

This tool takes zero parameters, so the schema carries no burden. The description compensates by explaining what the status output covers and how to interpret the policy snapshot, adding meaning beyond the empty input schema.

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?

States a specific verb-resource pairing and enumerates exactly what the tool reports: promotion mode, denied subreddits, per-subreddit roles, scoring weights, and scheduled mode changes. It also gives an explicit use case, reading this when unsure whether something is allowed, which clearly differentiates it from the Reddit action and product profile siblings.

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?

Explicitly tells the agent when to invoke this tool: 'Read this when you are unsure whether something is allowed.' It also clarifies that this server cannot perform Reddit actions, so an agent should not expect to take action through this or related tools. This contrasts cleanly with sibling tools that do Reddit operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description explicitly states the server is read-only, lists forbidden Reddit actions, and reveals that no such code exists. This goes well beyond the readOnlyHint annotation and clearly communicates what the tool cannot do. The promotion-mode gate is also acknowledged, and there is no contradiction with annotations.

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 front-loaded with the tool's purpose and is relatively short. However, the second and third paragraphs contain generic read-only and promotional-policy boilerplate that is not specific to this tool, reducing the tightness of the definition.

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 zero-parameter read-only tool, the description is largely complete: read-only behavior is clearly stated, return semantics are presumably covered by the output schema, and parameter needs are absent. The one gap is that the 'promotion-mode gate' is referenced but not defined, requiring knowledge of product_get_profile.

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 zero parameters, so there is no parameter semantics to document. The baseline score of 4 applies because the description has nothing to add beyond the schema.

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 identifies the resource ('product capabilities') and an added attribute ('verification status'), and the tool name supplies the retrieval verb. It is clear about what is being returned, though it does not explicitly differentiate itself from sibling product_get_* tools beyond mentioning a shared gate.

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 only condition mentioned is a shared 'promotion-mode gate' with product_get_profile, which is a restriction rather than a usage recommendation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the readOnlyHint annotation by explaining confidence levels, how observed/unknown entries must be phrased, and that the tool also lists what the user does not have. It also clarifies the server is read-only and cannot perform Reddit actions.

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 first paragraph is front-loaded and information-dense, but later paragraphs include generic policy guidance about Reddit participation and product promotion that is not specific to this tool. Some sentences repeat what annotations already convey, so not every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema covers return structure, and the description thoroughly explains the meaning and usage of the returned expertise entries. The main completeness gap is the absence of parameter semantics and the lack of explicit differentiation from sibling 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?

Schema description coverage is 0%, and the description never mentions `tags` or `about` or explains how they shape the results. The parameter names are only weakly suggestive, so an agent has little guidance on what values to supply.

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 clearly identifies the tool as exposing the user's first-hand expertise and positions it as the primary source for helping people. It distinguishes itself from product-marketing capabilities, though it never states an explicit action verb like 'retrieves' or 'returns'.

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 strong usage context: this is the primary source for helping people and contains no product marketing. It does not explicitly name sibling tools or state when not to use it, so it stops short of full alternative routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already include readOnlyHint=true, and the description goes further by enumerating the server's exact limitations: it cannot post, comment, vote, edit, delete, follow, or message, and no such code exists. It also discloses the unusual gated behavior where the tool intentionally returns no product data, adding important context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and gating behavior, then adds read-only and participation-policy context. The extra guidance is relevant but goes beyond tool mechanics, making the description slightly longer than strictly necessary.

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 zero-parameter tool with an output schema and safety annotations, the description fully explains the unusual gated behavior, the correct alternative, the read-only nature, and applicable policy constraints. Nothing essential for an agent to call or route around this tool is missing.

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 tool has zero parameters and the schema coverage is effectively 100%, so there is no parameter documentation burden on the description. The baseline for no-parameter tools is 4, and the description appropriately focuses on behavior rather than 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 clearly identifies the resource as the user's product details and uses retrieval language ('returns') around the gated behavior. It also distinguishes itself from a sibling tool by directing to product_get_expertise when promotion mode is 'never', satisfying sibling differentiation.

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?

It explicitly explains when this tool returns no product information (promotion mode 'never'), states that this is correct rather than an error, and names the alternative tool to use instead. This gives an agent clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true; the description adds that the server is read-only, cannot perform Reddit actions, and that the user performs actions manually. It also explains the tool should not be used to assert unmeasured numbers. No contradiction with annotations.

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 first paragraph is useful and front-loaded, but the second and third paragraphs contain global policy about Reddit read-only behavior and participation guidelines that are not specific to this tool. This adds unnecessary length.

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 low-complexity tool with an output schema, the trigger and user-facing action are sufficiently explained. However, the undocumented optional `template` parameter is a gap, and the description does not explain what the returned checklist contains beyond being a checklist.

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 coverage is 0% and the description never mentions the `template` parameter or its role. Since the only parameter is optional with a null default, the omission is not fatal, but the description does nothing to help an agent decide whether or how to pass it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as a checklist to run on real hardware before making factual claims, and gives the trigger condition `verification_needed: true`. It is easy to distinguish from sibling tools, though it doesn't explicitly name a sibling or state 'returns a template' as an action.

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?

It gives an explicit condition: 'Use whenever a result carries verification_needed: true' and tells the agent to ask the user to run it and report back. It doesn't discuss alternatives or when not to use it, but siblings don't appear to overlap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the readOnlyHint/openWorldHint/destructiveHint annotations. It discloses the retention cleanup side effect, states that no Reddit write code exists, clarifies that the server is read-only, and notes that it returns only URLs to open, never a ready-to-post body. This is rich, non-redundant 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 core purpose and constraints are front-loaded, and the read-only and policy guidance are relevant for agent behavior. Some redundancy exists ('no such code exists', 'never posts anything') and 'The main tool' is filler, but the description is still efficiently organized and not bloated.

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 description covers return shape, side effects, and constraints, and the tool has an output schema plus optional parameters with defaults. The main gaps are the complete lack of parameter semantics and no routing guidance relative to sibling tools. This is a meaningful hole for a main entry-point tool, but not fatal because it can be invoked with defaults safely.

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 days, max_replies, or max_opportunities at all. The phrase 'one day's work queue' may even obscure the configurable days parameter. Since the schema provides no parameter documentation and the description does not compensate, an agent has no guidance on how these parameters affect 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 clearly states that the tool produces a daily work queue and enumerates its contents: new replies, ranked contribution places, what the user can say, verification needs, rule caveats, and reminders. It explicitly says it never returns a ready-to-post comment body and never posts anything, which distinguishes it from posting or content-generation 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?

It implies this is the main daily entry point ('The main tool', 'Produces one day's work queue'), and it sets expectations that the user performs Reddit actions manually. However, it does not explicitly say when to prefer this over siblings like reddit_get_replies_to_me or reddit_find_opportunities, nor does it state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the annotations by explicitly stating the server cannot post, comment, vote, edit, delete, follow, or message, and that no such code exists. It also discloses that high-promotion-risk threads are removed entirely, describes result contents, and surfaces the real-device-check flag.

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 front-loaded with the core purpose and structured in clear paragraphs. The final paragraph is somewhat redundant with the opening, restating helpfulness and promotion concerns, but overall the length is justified for the complexity.

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 description thoroughly covers safety, ranking behavior, filtering, and output content, and an output schema exists to document return values. The main gap is parameter semantics, which is not compensated for anywhere.

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 days, topics, subreddits, or max_results. An agent must rely entirely on parameter names and defaults; the description adds no meaning about how these parameters shape the ranking or filtering behavior.

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 first sentence states a specific action (rank recent threads) on a specific resource (Reddit threads) with a clear criterion: how genuinely useful the user could be in them. It adds unique ranking logic around helpfulness and promotion risk, which distinguishes it from sibling tools like reddit_search_posts or reddit_daily_digest.

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 implies the use case through its purpose statement, but it never explicitly says when to prefer this tool over siblings such as reddit_daily_digest or reddit_search_posts. The normative instructions about prioritizing helpful participation are behavioral guidance, not usage routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint and destructiveHint annotations, the description discloses that results are capped and do not page indefinitely, and that the server is read-only with no code path for mutations. This adds meaningful behavioral context an agent needs before calling it.

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 main purpose is front-loaded in the first sentence, and the read-only caveat is useful. The final paragraph contains general policy guidance that is not strictly tool-specific, adding minor noise, but the overall description remains reasonably 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?

For a simple two-optional-parameter tool, the description covers purpose, usage context, cap behavior, and read-only constraints, and an output schema exists. The main gap is parameter semantics, but the parameter names and defaults make the tool reasonably invokable as-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?

The input schema provides no descriptions for days or limit, and the tool description does not explicitly explain either parameter. 'Recent' and 'Results are capped' are only implicit hints, leaving the agent without clear semantics for the two 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 opens with 'Fetch the user's own recent posts and comments,' which is a specific verb plus resource. It also clarifies the tool's purpose by mentioning activity checks and the 9:1 self-promotion ratio, making it distinct from siblings like reddit_get_replies_to_me or reddit_get_thread.

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 explicitly says the tool is used to judge a user's activity in a subreddit and compute the 9:1 ratio, giving clear context for when to call it. It does not explicitly list alternatives or exclusions, but the intended use is clear enough for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the annotations by explaining the diffing implementation, the deliberate avoidance of the privatemessages OAuth scope, the extra request cost, and the absolute read-only nature of the server with a specific list of impossible actions. This gives the agent strong behavioral context and matches the readOnlyHint annotation.

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 first sentence front-loads the core purpose, and the key behavioral notes are concise. The final paragraph about helpful participation and subreddit rules adds behavioral guidance but is somewhat tangential to tool invocation, keeping this from a perfect score.

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?

Annotations, output schema, and the detailed behavioral description cover much of the context. However, the lack of parameter semantics for 'since' is a real gap that affects correct invocation, and there is no explicit routing guidance among sibling 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?

Schema description coverage is 0%, and the description does not explain either parameter. 'limit' and 'since' are somewhat self-explanatory names, but 'since' especially lacks any format, timezone, or semantic details, leaving the agent to guess what value it expects.

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 opens with a specific verb and resource: 'Find new replies to the user's own posts and comments.' This uniquely distinguishes the tool from siblings like reddit_get_my_activity, reddit_get_thread, and reddit_search_posts by scoping it to replies on the user's own content.

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 intended use is implied clearly by the first sentence, but the description does not explicitly state when to prefer this tool over alternatives, nor does it mention exclusions. It explains implementation trade-offs but not usage selection criteria relative to sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description adds valuable behavioral details: the server cannot perform any Reddit actions, results are cached locally, `self_promotion_restricted: null` means UNKNOWN rather than permission, and ambiguous rules should be surfaced. This goes well beyond what the annotations alone provide.

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 main purpose is front-loaded and clearly stated, but the description includes a long policy paragraph about product promotion and thread ranking that is not directly tied to fetching subreddit rules. Some statements also repeat what the annotations already convey, making the description somewhat heavier than necessary.

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 one-parameter schema, the presence of an output schema, and the annotations, the description is largely complete. It explains caching, read-only constraints, and ambiguity handling. It would be fully complete if it specified the expected subreddit argument format or named sibling alternatives.

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 no description for the `subreddit` parameter, and schema description coverage is 0%. The description only refers to 'a subreddit's rules' and does not explain expected format, casing, or whether the value includes 'r/'. It adds little semantic value beyond the parameter name and title.

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 states a specific action and resource: 'Fetch a subreddit's rules and a conservative reading of its self-promotion stance.' This clearly distinguishes it from sibling tools like reddit_search_posts or reddit_get_thread, which serve different purposes.

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 context about the read-only server and instructs the agent to respect subreddit rules and surface ambiguity, which implies when the tool should be used. However, it never explicitly states when to prefer this tool over alternatives or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already indicate a read-only and non-destructive tool, and the description adds concrete behavioral detail: it cannot post, comment, vote, edit, delete, follow, or message on Reddit, and no such code exists. It also discloses non-obvious behaviors such as refusing denied subreddits and deliberately avoiding full comment-tree fetches. These statements go beyond the structured annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The first two sentences are tightly scoped and front-loaded, which is good. However, the third paragraph about helpful participation, product promotion, and subreddit rules reads as general server policy rather than tool-specific call guidance. The description is not bloated, but this tangential policy text prevents it from being optimally 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 read-only annotations and the presence of an output schema, the description covers the key behavioral limits well: bounded comments, denied subreddits, and no user actions performed on behalf of the caller. The major gap is parameter semantics, since an agent is left without guidance on how to construct the url or how max_depth and max_comments shape the request. Overall, it is complete for high-level behavior but not fully sufficient 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?

Schema description coverage is 0%, yet the description does not explain the url, max_depth, or max_comments parameters, their formats, or how they interact. The phrase 'a bounded selection of comments (top-level, high-scoring, and any near the user's own replies)' provides selection behavior but does not map to parameter names or semantics. This is not enough to compensate for the complete absence of schema descriptions.

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 opens with a specific verb and resource: 'Read the minimum necessary context of one Reddit thread,' and then concretely defines what that includes: the post plus a bounded selection of comments. It also sets clear boundaries with 'Does not fetch entire comment trees,' which helps distinguish it from broader thread-fetching or scraping behaviors. Although no sibling tool is named, the scope is specific and non-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?

The primary use case is clearly implied: retrieve a bounded read of a single Reddit thread. However, the description never explicitly states when to prefer this tool over siblings like reddit_search_posts, reddit_get_replies_to_me, or reddit_daily_digest, nor does it provide exclusion criteria beyond denied subreddits. The 'minimum necessary context' phrasing hints at efficiency, but the routing guidance is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Even though annotations already declare readOnlyHint=true, the description adds concrete behavioral detail: the server cannot post/comment/vote/etc., actions are manual, and competitor-only matches are returned separately. This is useful context beyond the structured annotations, with no contradiction.

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 more verbose than necessary but front-loads the core purpose and each paragraph adds a distinct type of guidance (scope, read-only behavior, participation norms). Some repetition of the annotation is present, but it is still reasonably tight.

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 five parameters and no schema parameter descriptions, the description covers scope and result-category behavior well but leaves input semantics and tool-selection guidance under-specified. The output schema presumably covers return shape, so that gap is not penalized here.

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 explain sort, limit, queries, subreddits, or time_window parameter semantics. It only implies scope and result-category behavior, which is not enough to compensate for the total lack of parameter 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 opening sentence names a specific action ('Search recent posts') on a specific resource ('subreddits the user has designated as places to contribute'), and the listening_only distinction adds scope. It does not, however, explicitly differentiate this tool from siblings like reddit_find_opportunities or reddit_daily_digest.

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 clear context about when results should be used (contribution subreddits, not listening_only) and mentions excluded subreddit types, but it never states when to prefer this tool over sibling tools or vice versa. Guidance is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/destructive annotations, the description reveals that the tool never returns secrets or tokens, that no write code exists in the server, and that the user performs all Reddit actions manually. This gives an agent concrete expectations about side effects and data exposure, and it aligns with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The identity statement, no-secrets guarantee, and call-first instruction are front-loaded and each earn their place. The final policy paragraph is broader than the tool's function and could arguably live at a higher level, but it is not wasted because it explains the promotion-policy context mentioned in the first 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?

For a no-argument status tool with an output schema, the description covers authentication status, policy mode, safety guarantees, and when to use it. Nothing an agent needs to call this tool correctly is missing.

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 tool has zero parameters, so the baseline is 4. There are no parameter semantics to clarify in the description, and none are needed.

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 states a clear verb and resource: it shows which Reddit account the server is authenticated as and the current promotion policy mode. This is unambiguous and not tautological, but it does not explicitly contrast itself with siblings such as policy_status, so it stops one step short of full differentiation.

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?

It gives explicit when-to-use guidance: call this first when unsure whether authentication is set up. It does not state when not to use it or name alternatives, but for a zero-parameter identity/status check, no obvious alternative is needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.