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

Annotations already declare readOnlyHint and openWorldHint, and the description usefully adds the return envelope and, critically, the RSS fallback degradation (max ~25 posts, no score/comment counts, no pagination) — non-obvious behavior an agent would otherwise miss. It omits auth/rate-limit details, keeping it below a 5.

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?

Three tightly-packed sentences, front-loaded with the core action then the safety profile and return shape, then the fallback caveat. Every clause carries information the agent needs.

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, the description correctly supplies the return shape and pagination cursor semantics, and covers the degraded fallback path. It could say more about pagination termination or empty results, but it is sufficient to call the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so sort, after, limit, subreddit and time_filter are all already documented in the schema. The description repeats the sort enum without adding syntax, defaults, or interaction detail beyond what structured fields provide, so baseline 3 applies.

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

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

States a specific verb (browse) and resource (subreddit feed) with the supported sort modes enumerated, so an agent immediately knows the scope. It stops short of naming which sibling to prefer (search_reddit, get_top_posts, get_trending_subreddits), so differentiation is left to inference.

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?

Usage is implied by 'Read-only, anonymous' and the option set, but there is no explicit when-to-use-vs-alternative guidance against the many sibling subreddit/post tools. An agent can guess it is the general feed reader, but nothing states when to reach for search_reddit or get_top_posts instead.

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 and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context by listing the diagnostic signals returned and confirming no arguments are required.

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?

Front-loads 'Diagnostics, no arguments' and then lists the checks in one efficient sentence. The usage cue is a short, well-placed second sentence with no wasted words.

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

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

With no output schema and no annotations beyond safety, the description carries the burden of explaining what is returned. It covers the diagnostic categories well, though it does not specify the exact response structure or field names.

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. The description reinforces this by stating 'no arguments,' which matches the empty schema and leaves no ambiguity.

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 diagnostic purpose, explicitly says it takes no arguments, and enumerates the exact signals it reports (backend, degradation, token expiry, rate limit, cache stats). This clearly distinguishes it from the sibling read/content 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?

Gives a clear trigger: 'Call this first when other tools fail.' This tells the agent when to use it, but it does not name when not to call it or point to an alternative for non-diagnostic needs.

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?

Goes well beyond the readOnlyHint by disclosing that 'more' stubs cannot be expanded (Reddit returns HTTP 403 for anonymous tokens), that no follow-up call will recover them, and that access is read-only/anonymous. This is exactly the kind of operational caveat annotations cannot express.

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?

Front-loaded with the return shape, then the critical 403 limitation, then the recovery action. The embedded return-shape snippet is dense but earns its place given there is no output schema. Minor density cost from the JSON-ish notation.

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, the description compensates fully by describing the response envelope (post/data/more/after), the meaning of 'more' and 'more_replies', the auth model, and the 403 dead end. An agent has everything needed to call it and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description adds real meaning: it ties limit/depth/sort to observable outcomes ('Deeper replies become more stubs', 'larger limit/depth or a different sort' to see more of a thread). That causal link between parameters and result shape is not in 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?

Opens with a precise resource statement, 'The comment tree of a post,' which is unmistakably distinct from siblings like get_reddit_post (the post itself) and get_user_comments (a user's comment history). An agent can select this tool without opening the schema.

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 what to do when it wants deeper coverage: 'call get_post_comments again with a larger limit/depth or a different sort.' It lacks when-not-to-use guidance or direct naming of competing siblings, but the re-invocation rule is clear and actionable.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the bar is lower, yet the description adds value: it clarifies the call needs no authentication ('anonymous') and discloses that body text is 'truncated if very long' — a real behavioral trait not present in the schema or annotations. It does not discuss error behavior for missing/deleted posts.

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?

Two sentences, zero waste. The identity of the tool and its returned fields come first, and the disambiguation pointer is placed last where it belongs.

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, the description compensates by enumerating the returned fields and flagging body truncation, so the agent knows what to expect. Parameter detail is fully carried by the schema. Nothing needed to invoke this read-only 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?

Schema description coverage is 100%: both post_id (base36, fullname, or permalink) and the optional subreddit parameter are fully documented, including accepted prefixes. The description only reinforces 'by id' and adds nothing about parameter formats, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Fetch a single Reddit post by id') and enumerates the returned fields (title, author, subreddit, score, comment count, created time, permalink, link URL, body). It explicitly differentiates itself from get_post_comments, so an agent can pick it without opening either schema.

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 routing guidance to a sibling: 'Use get_post_comments for the discussion.' That is a clear when-to-use-this-instead signal. It stops short of covering other plausible alternatives (search_reddit, get_top_posts) or exclusions such as multi-post retrieval, so it is not full 5-level 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 and openWorldHint=true, so 'Read-only' largely restates structured data. However, 'anonymous' adds genuine context (no authentication required), and the field list hints at the response shape. What is missing is failure behavior for nonexistent, private, or banned subreddits, which is meaningful for an open-world read 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?

A single compact sentence with zero filler; the field list is front-loaded and immediately useful. Nothing could be removed without losing information.

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

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

With no output schema, listing the returned fields is exactly the right compensation and makes the return value predictable. The only gap is error/edge-case behavior (missing or private subreddit), which for a simple anonymous read tool is a minor omission.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single parameter documents the 'no r/ prefix' convention with an example, so the schema carries the load. The description adds nothing about the parameter, which is acceptable here but earns only the baseline.

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 enumerates exactly what the tool returns (title, public description, subscribers, active users, creation time, NSFW flag, submission type) which is a concrete, specific resource statement. It is a noun phrase rather than a verb+resource, and it does not explicitly distinguish itself from nearby siblings such as get_subreddit_rules or browse_subreddit, so it stops short of a 5.

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 statement of when to use this tool versus the alternatives. With siblings like get_subreddit_rules, browse_subreddit, and get_trending_subreddits in the set, the agent gets no routing guidance; the name alone carries the selection burden.

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 and openWorldHint=true, so restating 'read-only' adds nothing. 'Anonymous' does add a small piece of behavioral context — no authentication/credentials required — which is not covered by the annotations. Beyond that it says nothing about failure modes (e.g. nonexistent or private subreddit) or response behavior, so with the annotation bar already met this is a modest addition.

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?

Extremely tight: one clause stating the resource and its returned fields, then a two-word qualifier. Nothing is padded, and the resource scope is front-loaded. The trailing 'Read-only, anonymous' fragment is slightly clipped but still parses cleanly.

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 present, the description steps in to sketch the returned content, which is exactly the right compensation. For a single-parameter read tool with annotation coverage, nothing essential is missing; only the routing question versus sibling tools remains open.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single parameter is fully documented in the schema (name without the r/ prefix, with an example), so the schema carries the burden. The description adds no parameter-level detail, which is fine but yields the baseline 3.

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

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

The description names a specific resource (a subreddit's posting rules) and even sketches the shape of the result: short name, description, and applicable content kinds. That makes the tool's output distinguishable from generic subreddit metadata. It does not, however, differentiate itself from close siblings like get_subreddit_info or browse_subreddit, so it stops short of a 5.

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 explicit when-to-use statement and no mention of the alternative tools (e.g. get_subreddit_info) that an agent might confuse this with. Usage is only inferable from the name and one-line purpose. 'Read-only, anonymous' describes the call's nature, not the conditions under which it should be selected.

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

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

Goes well past the annotations (readOnlyHint/openWorldHint) by disclosing that access is anonymous (no auth needed), the exact return shape {'data': [...], 'after': cursor|null}, and a degraded fallback mode with concrete limits (~25 posts, no score/comment counts, no pagination). This is precisely the kind of behavior an agent cannot derive from structured fields, especially with no output schema.

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?

Three dense sentences: purpose and scope first, then the auth/read posture, then return shape and fallback caveats. Nothing is redundant and the inline JSON return literal replaces a missing output schema economically.

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 4-param, enumeration-heavy tool with no output schema, the description supplies the return contract and fallback limitations, which is most of what an agent needs. It does not cover failure/rate-limit behavior or ordering guarantees, so it stops short of fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including cursor semantics, limit range and the time_filter enum, so the schema already carries parameter meaning. The description only restates the time-window default and does not add format or interaction detail beyond it, making 3 the correct baseline.

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 ('Top posts of a subreddit'), plus scope ('or the anonymous front page') and a default time window. It is clearly not the same as get_trending_subreddits or get_post_comments, but it never names or contrasts with a sibling such as browse_subreddit, so differentiation is inferred rather than stated.

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?

Usage context is implied by the description ('top posts ... over a time window (default week)') and the RSS fallback note flags an operational mode, but there is no explicit when-to-use vs. when-not-to-use guidance and no alternative tool is named. An agent must infer that browse_subreddit covers non-'top' listings.

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, but the description adds genuinely new context: the operation is anonymous (no auth needed) and it returns a {"data": [...], "after": cursor|null} envelope, which tells the agent how to paginate. It stops short of noting rate limits or throttling.

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?

Three terse fragments with zero filler; the identity of the resource is front-loaded and the return shape follows. Every clause carries information.

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

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

With no output schema present, the description steps in to describe the return envelope and the cursor, which is exactly what an agent needs for pagination. It omits secondary details like rate limits or ordering semantics, keeping it just short of complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters (after, limit) are already fully documented with defaults and bounds. The mention of the "after" cursor confirms how pagination works but adds no detail 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?

States a specific verb+resource ("Currently popular subreddits") and anchors it to Reddit's /subreddits/popular listing, so an agent knows exactly what content comes back. It doesn't explicitly name a sibling it is not, but its listing/discovery role is distinct from browse_subreddit and get_subreddit_info.

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 when-to-use guidance and no named alternative. The agent must infer that this is a discovery tool rather than, say, search_reddit or browse_subreddit; no conditions for choosing between them are given.

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, so the 'Read-only' claim is redundant, but 'anonymous' adds genuine context about authentication needs. More importantly, the description discloses the return envelope and pagination contract ({"data": [...], "after": cursor|null}), which no annotation or output schema provides.

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?

Two short sentences, front-loaded with the resource and scope, then the safety and return-shape facts. Every clause carries information and nothing is padded.

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, the description usefully compensates by describing the response envelope and cursor pagination. The only gap is that it never contrasts itself with the close siblings get_post_comments or get_user_posts, which an agent selecting among 11 tools would benefit from.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so sort, after, limit, username and time_filter are already fully documented in the schema, including enum meanings and defaults. The description adds no parameter-level detail beyond that, so the baseline 3 applies.

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

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

The description names a specific verb and resource ('comments written by a user') and adds the scoping detail that each comment carries its post title, which is enough to separate it from get_post_comments. It stops short of explicitly naming that sibling, so the differentiation is implied rather than stated.

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?

Usage is implied by the phrasing 'written by a user', which tells the agent this is a user-scoped listing rather than a post-scoped or search-based one. However, no alternative tool is named and no condition (e.g., when to prefer get_post_comments or get_user_posts) is given.

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 provide readOnlyHint=true and openWorldHint=true, so 'Read-only' largely repeats the safety profile. However, 'anonymous' (no auth needed) and 'private account data is never available' add genuine behavioral context the annotations do not carry, telling the agent the call is safe and non-privileged.

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?

Two short sentences, front-loaded with the payload contents and followed by scope constraints; there is little waste. The 'Read-only' clause is mildly redundant with readOnlyHint, which keeps it 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?

With no output schema, the description does the right thing by enumerating what the profile returns. It is nearly complete for a simple read tool; it doesn't mention behavior for nonexistent, suspended, or deleted accounts, which is the main remaining gap.

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?

There is a single parameter and schema description coverage is 100% — the schema already specifies the username format and the 'no u/ prefix' rule. The description adds nothing about parameter syntax or validation, so the baseline 3 applies given the schema does the 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 names a specific resource (Reddit user profile) and enumerates the returned fields — karma, account age, employee/mod/verified flags, profile description. This distinguishes it implicitly from siblings like get_user_posts and get_user_comments. It stops short of explicitly routing against those siblings, so it is clear but not fully differentiated.

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?

Usage is implied rather than stated: an agent can infer this is the tool for a user's profile, but no when-to-use, prerequisites, or named alternatives (e.g. get_user_posts for a user's submissions) appear. The clause 'private account data is never available' sets a useful scope boundary, which lifts it above bare absence of 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 and openWorldHint=true, so 'Read-only' is partly redundant, but 'anonymous' adds genuinely new context (no auth needed) and the description discloses the return envelope and pagination shape — valuable since there is no output schema. Minor gap: no note on rate limits or ordering defaults.

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?

Three terse sentences with zero padding; the core purpose leads and the behavioral and return-shape facts follow. Every clause 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?

With no output schema, the description compensates by stating the return shape ({data, after}), and annotations cover the safety profile while 'anonymous' covers auth. Only marginal omissions remain (ordering semantics, defaults), so it is nearly complete for this tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all five parameters (username, sort, limit, after, time_filter) are already documented in the schema. The description's mention of an 'after' cursor lightly reinforces pagination but adds no syntax or default details beyond structured data — baseline 3.

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

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

States a specific verb+resource: 'Posts submitted by a user,' which an agent can distinguish from the comments-oriented sibling get_user_comments. It does not, however, explicitly name that sibling or clarify boundaries against get_user_info/get_post_comments, so differentiation is implicit rather than stated.

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 when-to-use guidance, no prerequisites, and no alternatives named. The agent must infer that get_user_comments is the counterpart for comments and that this tool requires a username; nothing in the text routes between siblings.

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 and openWorldHint=true, so safety is covered; the description still adds real value by stating access is anonymous and by documenting the return shape ({data, after cursor}) and cursor-based pagination, which matters since no output schema exists. It omits rate-limit or auth-token context, keeping it short of a 5.

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?

Two compact sentences with zero waste: purpose and scope first, then the read-only/anonymous property and return shape. Front-loaded and appropriately sized for an 8-parameter search 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 8 params at full schema coverage and no output schema, the description supplies the missing return-shape and pagination context. The one gap is that it never says a query (or its 'q' alias) is effectively required for a meaningful search despite zero required params in the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter (q/query alias, sort, type, after, limit, subreddit, time_filter) is already documented inline. The description adds only the 'type' and subreddit framing already present in the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ("Search Reddit posts") and immediately extends scope to subreddits/users via the 'type' parameter, plus an optional subreddit restriction. An agent can distinguish it from browse_subreddit or get_top_posts by the search semantics, though no sibling is named explicitly.

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?

Usage context is implied ('optionally restricted to one subreddit') but there is no explicit when-to-use/when-not guidance and no routing to alternatives like browse_subreddit for listing, or get_top_posts for rankings. An agent must infer selection from the 'type' enum alone.

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