KonbiniAPI MCP

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's job is lighter. It adds useful behavioral context about pagination (fixed batch of 12 per page) and the availability of payload reduction options, which goes 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?

Two sentences, front-loaded with the core purpose and pagination behavior. The second sentence adds relevant parameter guidance without waste. Every word 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?

For a tool with 5 parameters (1 required) and no output schema, the description provides sufficient context: it specifies the resource, the pagination behavior, and payload reduction options. It does not describe error cases or return structure in detail, but the annotations cover safety and the schema covers parameters, making this adequate.

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 parameters are already documented. The description mentions projection_preset, data_fields, and item_fields for payload reduction, but this only restates what the schema already provides. No additional semantic meaning is added 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 clearly states the tool returns a paginated list of reels filtered by a specific audio/music track. It uses a specific verb ('returns') and resource ('reels'), and the audio-based distinction separates it from sibling tools like instagram_get_trending_reels or instagram_get_user_reels.

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 usage (when you have an audio ID) but does not explicitly state when to use this tool over alternatives or when not to use it. It mentions the fixed batch size but lacks explicit routing guidance to other reels tools, leaving the agent to infer the selection criteria.

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 communicate readOnly, idempotent, non-destructive, and openWorld behavior, so the description does not need to re-cover safety. It adds useful context about media content and payload-reduction options, but does not mention pagination, response shape, or rate-limit 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 two sentences and front-loaded with the core behavior. The second sentence adds a prerequisite and a summary of payload-reduction options without unnecessary filler.

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 moderately simple read-only tool, the description covers what is returned and where the required ID comes from. No output schema exists, so a slightly fuller description of the response shape would help, but the overall context is 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 coverage is 100%, so the schema already documents highlightId, projection_preset, data_fields, and item_fields. The description only restates the parameter names and the general purpose of payload reduction, adding limited meaning 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 clearly states a specific verb and resource: 'Returns all story items within a highlight reel, including images and videos.' It does not explicitly name a sibling tool to distinguish from, but the mention that the ID comes from the highlights list endpoint helps separate this from list-style highlight 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?

The description implies the usage flow: obtain a highlight ID from the highlights list endpoint, then pass it here. It does not explicitly name the alternative endpoint/tool or state when not to use this tool, so guidance is present but inferred.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond that: it discloses the fixed page size (21) and single-page limitation, which affects pagination expectations, and explains that projection_preset, data_fields, and item_fields serve payload reduction. This gives the agent a clear picture of what to expect without contradicting annotations.

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

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

Three sentences, each earning its place. The first states the core purpose, the second discloses critical constraints (page size and pagination), and the third mentions the payload-reduction options. There is zero fluff, and the most important information (what it does and its limitations) is front-loaded.

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 read-only retrieval tool with 100% schema coverage and safety annotations, the description covers the essential aspects: purpose, constraints, and parameter purposes. It doesn't detail the return structure, but there is no output schema, and the description's mention of payload reduction implies a structured response. The only minor gap is that it doesn't explicitly state that count is ignored despite being in the schema, but the description and schema both note the fixed page size, so this is not a critical 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%, so every parameter already has a description. The description adds a small amount of meaning by framing projection_preset, data_fields, and item_fields as a group for payload reduction, which is not explicitly stated in the schema. However, it does not go beyond that; the ID type and count behavior are already in the schema. With full coverage, a baseline of 3 is appropriate.

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

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

The description states a clear verb ('Returns') and resource ('posts tagged at a location'), specifying the exact scope. It distinguishes itself from sibling tools like instagram_get_user_posts by focusing on location-based posts, and even clarifies the ID type (numeric Facebook Places ID). No ambiguity.

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 does not provide guidance on when to use this tool versus alternatives. It never mentions when-not-to-use, nor does it reference any sibling tools (e.g., instagram_search_media or instagram_get_user_posts) that might be better suited for different needs. The only context is a platform constraint (fixed page size, single page), which is behavioral, not usage 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 provide readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to restate safety. It does add useful behavioral context about supported media types and payload-reduction options, but it does not disclose failure modes, rate limits, or the exact response shape. 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?

Three focused sentences with no filler: the core purpose is front-loaded, then supported types, then payload options. 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?

For a simple read-only getter with complete parameter schema and strong annotations, the description is nearly sufficient. It covers what is returned, supported media types, and the projection options, though the absence of an output schema leaves some ambiguity about the full response structure.

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 schema fully documents postId, data_fields, and projection_preset. The description reinforces that postId is a shortcode and explains that projection_preset and data_fields reduce payload, but it adds little beyond what the schema already states.

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 verb and resource: 'Returns details for a single post by its shortcode,' and adds useful scope with media types and engagement counts. It is clearly differentiated from sibling tools like instagram_get_post_comments and instagram_get_user_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?

Usage is implied through 'single post by its shortcode' and the supported media formats, but there is no explicit when-to-use versus alternatives guidance. It does not mention exclusions or direct the agent to a sibling tool under specific conditions.

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 cover safety (readOnlyHint=true, idempotentHint=true, destructiveHint=false). The description adds valuable behavioral context: fixed page size of 15 (platform limit), included fields (comment text, author info, like counts, timestamps), and support for projection_preset/data_fields/item_fields for payload reduction. No contradictions 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?

Two sentences with no wasted words. The primary function is stated first, followed by key constraints and options. Highly concise and 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?

For a read-only tool with 6 parameters (1 required) and no output schema, the description covers the return contents, pagination limit, and payload reduction options. Missing details like error handling or authentication are not critical given annotations. The description is 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 coverage is 100%, so all parameters have descriptions. The description adds meaning beyond the schema by explaining that projection_preset, data_fields, and item_fields are for payload reduction, which is not explicit in the individual parameter descriptions. This helps an agent understand their purpose.

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 the tool returns top-level comments on an Instagram post, a specific verb+resource. It distinguishes from siblings like instagram_get_post (which retrieves the post itself) and other platforms' comment tools. No ambiguity.

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 does not explicitly say when to use this tool vs alternatives, nor does it mention exclusions or conditions. The name and context imply it is for Instagram comments, but there is no guidance on when to prefer it over other comment-fetching tools. Only implicit usage context is provided.

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 cover read-only, idempotent, and non-destructive behavior. The description adds pagination context and payload reduction, which are useful beyond annotations, though it doesn't detail pagination mechanics or rate limits.

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 concise sentences, front-loaded with the core purpose, followed by a brief note on parameters. No redundant 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 simple read-only tool with no output schema, the description adequately conveys the main function and parameters. It could mention the response structure or cursor usage, but the schema covers cursor semantics, so it's sufficiently 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 coverage is 100% with detailed parameter descriptions. The description mentions projection_preset, data_fields, and item_fields but adds little beyond summarizing their purpose as payload reduction, which is already implied 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?

Clearly states the verb 'returns' and the specific resource 'public trending reels feed', and mentions the payload reduction parameters. It distinguishes itself from siblings like instagram_get_user_reels by explicitly focusing on trending 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 description implies usage for trending reels but does not explicitly contrast with alternatives such as instagram_get_user_reels or other platform-specific trending tools. No when-not-to-use guidance is provided.

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, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds useful context about public-only access and payload reduction, but does not disclose rate limits, auth requirements, or any edge-case behavior. Given the annotations, this is adequate but not rich.

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 compact sentences front-load the core purpose, then cover lookup alternatives and payload reduction. Every sentence earns its place with no redundant filler or repetition of schema details.

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

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

For a simple read-only profile lookup with a rich schema and comprehensive safety annotations, the description provides enough: output contents, public-scope caveat, lookup modes, and payload options. With no output schema, a slightly more explicit return-format note would make it fully complete, but the current summary is 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 100%, so the schema already documents all four parameters in detail. The description adds a little value by framing projection_preset and data_fields as payload reduction and by mentioning the numeric-ID shortcut, but it does not meaningfully compensate or extend 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 states a specific verb and resource: 'Returns profile information for an Instagram user.' It names concrete output content (bio, follower counts, profile picture, account metadata) and clarifies it covers any public account. This clearly differentiates it from sibling tools focused on posts, reels, tagged content, and highlights.

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 lookup context: use a username, or pass userId for a numeric ID lookup, and optionally reduce payload with projection_preset/data_fields. It does not explicitly name sibling alternatives or state when not to use this tool, but the single-purpose profile resource makes the intended use obvious.

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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds payload-reduction support and the relationship to the highlight endpoint, but does not disclose additional behavioral traits like pagination behavior or potential rate limits.

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 three sentences with no fluff: purpose first, sibling routing second, parameter context third. Every sentence contributes 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?

For a read-only list tool with one required parameter and no output schema, the description sufficiently covers purpose, scope, and how to drill into individual stories. Pagination/cursor behavior is not explicitly explained, but the cursor parameter is documented 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 the baseline is 3. The description adds value by explicitly grouping projection_preset, data_fields, and item_fields as payload-reduction controls, clarifying their collective purpose beyond their individual 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 clearly states it returns the list of story highlight reels on a user's profile, with a specific verb and resource. It also distinguishes itself from the sibling tool for individual stories by directing users to the highlight endpoint for nested story retrieval.

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 tells users to use the highlight endpoint for individual stories within a highlight, which serves as a clear alternative. It does not exhaustively compare against all siblings, but the resource and scope are specific enough to guide 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 adds meaningful behavioral context beyond the annotations: it discloses pagination with a maximum of 12 posts per page, enumerates content types included, and mentions support for projection_preset, data_fields, and item_fields for payload reduction. Since annotations already mark the tool as read-only and idempotent, the description appropriately extends that with operational details without 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 concise, with every sentence earning its place: it states the core function, the pagination limit, content types, and the payload-reduction options. The most important information (returns posts) is front-loaded, and there is no filler or redundancy.

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 moderate complexity, the description covers the key aspects an agent needs: pagination behavior, content types, and the available projection options. It does not detail the response structure, but with no output schema and annotations already establishing safety, the description is sufficient for correct invocation. Minor omissions like how to use the cursor are covered by the schema, so the overall completeness is good.

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 100% schema description coverage, the baseline is 3. The description adds value by explaining that projection_preset, data_fields, and item_fields are for payload reduction, which clarifies their purpose beyond the schema's terse descriptions. It does not repeat the schema's parameter details but contextualizes their use, earning a 4.

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 the tool returns a paginated list of posts from an Instagram user's profile feed, specifying content types (photos, videos, carousels) and engagement counts. This distinguishes it from sibling tools like instagram_get_user_reels or instagram_get_user_tagged, though it does not explicitly name alternatives. The verb and resource are precise and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as instagram_get_user_reels or instagram_get_user_tagged. It does not state exclusions or conditions for selecting this tool. The only implicit cue is 'profile feed', but that is not enough to guide an agent in choosing among the many similar Instagram user-related 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?

Discloses pagination behavior, the 8-reel-per-page cap, newest-first ordering, output contents (video URLs, captions, engagement counts), and the payload-reduction capability. This goes well beyond the readOnlyHint/idempotentHint/destructiveHint annotations, adding practical runtime context 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?

Four short, dense sentences front-load the core action and key constraints, then add output details and parameter tips. No filler or repetition; 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?

With no output schema, the description must convey return shape, and it does cover page size, ordering, and output contents. It stops short of describing the pagination envelope (e.g., cursor/nextCursor) or the default count, though the schema's parameter descriptions fill some of that 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?

Schema coverage is 100%, so all six parameters are already documented. The description adds meaning beyond the schema by grouping projection_preset, data_fields, and item_fields under the shared purpose of 'payload reduction', helping an agent understand why to set them.

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: 'Returns a paginated list of reels from an Instagram user's profile' with ordering ('newest first') and page size. This clearly differentiates it from siblings like instagram_get_audio_reels, instagram_get_trending_reels, and instagram_get_user_posts by scope and media type.

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?

Provides clear context for when to use the tool—fetching a specific user's reels—and gives operational guidance on payload reduction via projection_preset, data_fields, and item_fields. It does not explicitly mention alternative tools or exclusion conditions, but the context is unambiguous enough to route correctly among 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 mark the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond that: a hard limit of 12 posts per page and the ability to reduce payload via projection_preset, data_fields, and item_fields.

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 concise sentences with no filler. The main action is front-loaded, followed by the key limit and then the payload controls, each sentence carrying distinct 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?

The description covers the core selection criteria, pagination limit, return content, and payload shaping options. It is adequate for a read-only list tool, though it could have more explicitly clarified how cursor-based pagination connects to the 12-post page limit.

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 100%, so all parameters are described in the schema. The description still adds value by explaining the shared purpose of projection_preset, data_fields, and item_fields as payload-reduction mechanisms, which is not fully evident from the individual parameter 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 states a specific verb ('Returns') and a precise resource: Instagram posts where the user was tagged by other accounts. This clearly distinguishes the tool from siblings like instagram_get_user_posts or instagram_search_media.

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 makes the use case clear: retrieve posts in which a specific user has been tagged. It does not explicitly name alternatives or exclusions, but the distinction from user-created posts is implicit and strong enough for an agent to select the right tool.

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 adds behavioral details beyond the annotations: a maximum of 24 results per page, the possibility of empty results, and the availability of payload-reduction parameters. It does not contradict annotations (read-only, open-world, idempotent, non-destructive). It augments the safety profile with concrete limits and cautions.

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 highly concise: three sentences that front-load the core purpose, then provide the limit and behavioral caveat, and finally mention parameter support. There is no redundancy or filler, and 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?

For a search tool with no output schema, the description covers the essential context: it returns trending content, has a page limit, may return no results, and explains payload reduction. It doesn't explicitly describe the output format, but the data_fields/item_fields schema helps cover that. Minor gaps exist around pagination behavior, but overall it is sufficiently 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 coverage is 100%, so the baseline is 3. The description adds meaning by explaining that projection_preset, data_fields, and item_fields are used for payload reduction, which is not obvious from the schema alone. This clarifies the purpose of these parameters beyond their individual 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 clearly states the tool searches Instagram for trending reels and videos matching a keyword, which is a specific verb, resource, and object. It also distinguishes itself from full-text search by noting it surfaces trending content, differentiating it from sibling tools like instagram_search_popular.

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 implicitly tells when to use this tool: when you want trending reels/videos by keyword, not a full-text search. It cautions that some keywords may yield no results, which helps set expectations. However, it does not explicitly name alternatives like instagram_get_trending_reels or instagram_search_popular, so the 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral details: coverage varies by keyword, always returns 12 posts per page, and supports payload reduction. This goes beyond 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?

Four sentences, front-loaded with the core function, followed by critical caveats and pagination details. No wasted words; every sentence adds necessary 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 search tool with no output schema, the description adequately covers pagination (fixed 12 posts), variability in results, and payload reduction options. It gives the agent enough to know what to expect and how to control the response.

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 100%, so the schema documents all parameters. The description adds context by mentioning that projection_preset, data_fields, and item_fields are used for payload reduction, which helps the agent understand their purpose without needing to infer from names 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 states a specific verb ('Returns') and resource ('posts matching a keyword'), and adds scope ('popular topics', not exact-topic lookup). It clearly distinguishes itself from an exact lookup, which helps differentiate it from sibling search tools like instagram_search_media.

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 coverage variability and not being an exact lookup, but it does not explicitly name alternative tools or state when to prefer this tool over others. The guidance is implied rather than explicit, so it's adequate but not strong.

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe read operation. The description adds that it returns 'public information' and supports 'payload reduction' via projection_preset and data_fields. It does not contradict annotations, and adds incremental value by stating the read-only nature and customization options, though it could mention rate limits or that data is cached.

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 concise, one sentence that states the core purpose, lists included data fields, and mentions the two customization parameters. Every word earns its place, and there is no fluff or repetition.

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

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

Given that it is a simple read operation with annotations covering safety, the description is nearly complete. It explains what is returned and how to reduce payload, but does not specify the output format (e.g., JSON structure) or error cases. However, since there is no output schema, a brief note on return structure could have improved it, but it remains adequate for an agent to call correctly.

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

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

Schema description coverage is 100%, with descriptions for company ('Company vanity name') and optional projection_preset/data_fields. The description adds no new parameter details beyond what 'payload reduction' implies, but the schema already provides sufficient documentation. Since coverage is high, a baseline of 3 is appropriate; the description does not introduce any confusing or missing 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 clearly states the tool returns public information for a LinkedIn company page, listing specific fields (description, location, employee count, logo). It is distinct from siblings like linkedin_get_company_posts, which focus on posts rather than page details. The purpose is unambiguous.

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 does not explicitly state when to use this tool versus alternativestons. However, the context of retrieving company page information is inherently clear, and the sibling list shows obvious distinctions like company_posts for post feeds. There is no exclusions or alternatives specified, but the use case is straightforward enough to imply when to use.

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 establish that this is read-only, idempotent, open-world, and non-destructive. The description adds behavioral details beyond those annotations: newest-first ordering, iterative paging via cursor, and payload reduction through projection params. It does not cover error cases or rate limits, but for a safe read operation that is a minor gap.

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

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

Three short sentences, with the core behavior front-loaded, then pagination, then payload options. Every sentence earns its place and there is no filler or restating of 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?

For a moderate-complexity list operation with rich annotations and a fully described input schema, the description is nearly complete: it states the output, ordering, pagination, and payload controls. Because there is no output schema, a bit more detail about the response envelope would have fully closed the loop, but the data_fields/item_fields enums partially reveal the return shape.

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 100%, so the baseline is 3, but the description adds value by telling the agent what cursor is for ('page through further results') and by grouping projection_preset, data_fields, and item_fields as payload-reduction controls. This goes slightly beyond the schema's bare parameter 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: 'Returns recent posts from a LinkedIn company page, newest first.' This clearly distinguishes it from sibling tools like linkedin_get_user_posts or linkedin_get_post by limiting scope to company pages and stating ordering.

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 'LinkedIn company page' scoping gives clear context for when to select this tool over the many user/post getters in the sibling list, though it does not explicitly name alternatives or state when not to use it. The mention of cursor-based paging also hints at long result sets, which is useful usage context.

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, idempotentHint, and non-destructive behavior, so the bar for added value is lower. The description adds useful behavioral context beyond annotations: the return payload is scoped to author, engagement counts, and up to ~5 inline comments, and payload reduction is possible via projection_preset/data_fields. No contradictions 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?

Two sentences with no filler. The main purpose and content scope are front-loaded, followed by a concise note on payload reduction. 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?

For a 3-parameter read-only tool with full schema coverage and no output schema, the description covers the essential return contents and the payload control options. It could add a note about error behavior for invalid/non-public post IDs, but nothing critical is missing for a correctly-made call.

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 schema already fully documents postId, data_fields, and projection_preset. The description's mention of 'payload reduction' summarizes but does not add new meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Returns'), a clear resource ('public LinkedIn post'), and key content (author, engagement counts, inline comments), which distinguishes it from siblings like linkedin_get_post_transcript or linkedin_get_user_posts. It doesn't explicitly name a sibling, but the scope and detail are sufficient for most routing decisions.

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 explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives such as linkedin_get_post_comments or linkedin_get_post_transcript. The 'public' qualifier and mention of inline comments imply some context, but the agent is left to infer when this tool is preferred over its 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, openWorldHint, idempotentHint, and destructiveHint=false, covering safety. The description adds value beyond these by disclosing the 404 error case and the support for projection_preset and data_fields for payload reduction. It does not contradict 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 two sentences with zero filler. It front-loads the primary purpose, states the error condition, and mentions the optional payload reduction features—all in a compact, scannable structure. 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?

Given the tool's simplicity (3 params, 1 required, no output schema), the description covers the essential aspects: what it returns, when it fails, and how to reduce payload. It does not describe the exact response structure, but the data_fields enum includes 'content', which hints at the output. For a read-only tool with annotations already covering safety, this is adequately 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 the schema already documents all parameters thoroughly, including postId formats and enum choices. The description only briefly mentions that projection_preset and data_fields support payload reduction, which adds marginal context but does not significantly compensate for what the schema already provides. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Returns') and resource ('caption/transcript for a video post'), and clearly distinguishes from sibling tools like linkedin_get_post by focusing on the transcript. It also specifies the error condition (404 if no video or captions), making the tool's purpose unambiguous.

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 on when the tool succeeds (post carries captions) and when it fails (no video or captions), which helps an agent decide whether to invoke it. It does not explicitly name alternatives or say 'use X instead', but the conditionality is useful guidance. A 4 is appropriate for clear context without exclusions.

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, idempotentHint=true, and destructiveHint=false, covering safety. The description adds behavioral context beyond that: it notes that restricted fields are omitted and that the profile must be public. This informs the agent about privacy-related behavior and access scope, which is meaningful and not redundant 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 two sentences with no fluff. The first sentence front-loads the purpose and return contents; the second adds the privacy caveat and parameter note. Every word earns its place, and the structure is efficient and scannable.

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 read-only profile fetch with three parameters and no output schema, the description covers the essential facets: what is returned, the public-profile scope, omission of restricted fields, and payload-reduction options. It does not mention error handling or behavior for private/not-found users, but given the simplicity and annotation coverage, this is nearly 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%, with each parameter described (username, data_fields, projection_preset, including enum values and defaults). The description only reiterates that projection_preset and data_fields support payload reduction, adding no new semantics beyond the schema. Baseline 3 is appropriate because the schema does the heavy lifting.

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 uses a specific verb ('Returns') and resource ('profile information for a public LinkedIn member') and enumerates the exact content: headline, location, job titles, school/employer names. It also clarifies that restricted fields are omitted, distinguishing it from LinkedIn post/article tools. This is precise and unambiguous, with no room for confusion.

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 usage by its content—profile data versus posts or articles—but it does not explicitly state when to prefer this tool over siblings like linkedin_get_user_posts or linkedin_get_user_articles. No alternatives are named, and there is no when-not-to-use guidance. The purpose is clear enough to infer, but explicit routing is absent.

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, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond these: 'This endpoint is not paginated — everything available is returned in a single response.' It also mentions payload reduction options, which is useful but not strictly behavioral.

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 with zero waste. Purpose is front-loaded, followed by the key behavioral note and then the parameter support mention. No redundant 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 simple read-only tool with full schema coverage and no output schema, the description covers the essential points: purpose, non-pagination, and payload reduction. It might benefit from mentioning alternatives or when to use this over linkedin_get_user_posts, but it is largely 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 all parameters (username, data_fields, item_fields, projection_preset) are already documented in the schema. The description only restates that these are for payload reduction, adding no new semantics 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 states 'Returns a public LinkedIn member's published articles' – a specific verb and resource that clearly distinguishes this from sibling tools like linkedin_get_user_posts. It also adds the non-pagination behavior, further clarifying scope.

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 clearly identifies the target resource (articles) and gives a usage-relevant detail (non-paginated single response). It does not explicitly name alternatives or exclusions, but the purpose is distinct enough that an agent can infer when 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?

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable context beyond annotations: the endpoint is not paginated and returns everything available in one response, plus it notes the public-data access constraint. 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?

Three sentences with no filler: purpose first, then the key pagination behavior, then the optional payload-reduction parameters. Every sentence earns its place and the most important facts are front-loaded.

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 read-only tool with fully described parameters and rich enum values for item_fields, the description is nearly complete. It lacks an explicit description of the response envelope beyond 'single response', but the schema fields and item_fields already reveal the expected output shape.

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 100%, so the baseline is 3. The description adds extra value by framing projection_preset, data_fields, and item_fields as payload-reduction controls, giving the agent a reason to use them beyond the raw 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 uses a specific verb ('Returns') and a precise resource ('a public LinkedIn member's recent posts and shares'). It clearly distinguishes from sibling tools such as linkedin_get_user and linkedin_get_user_articles without requiring schema inspection.

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 clear context: use this when you need a public member's recent posts and shares, and expect a single non-paginated response. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds return content details but no additional behavioral context like rate limits, error handling, or authentication requirements. It adds some value beyond annotations but not rich detail.

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 a single sentence that front-loads the primary purpose and then mentions payload reduction. Every word earns its place, with no fluff or redundancy.

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 read-only getter, the description explains what is returned (author info, scores, reply presence, media) and mentions payload reduction. With no output schema, this is sufficient for an agent to understand the return value. It lacks details on error cases or authentication, but openWorldHint covers public access. The description is complete enough for the tool's simplicity.

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

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

Schema description coverage is 100%, with each parameter fully described including examples and enums. The description reinforces that projection_preset and data_fields are for payload reduction, but this is already implied by the schema's descriptions. No additional semantic meaning is added 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 clearly states the action (returns a public Reddit comment) and the resource (a single comment). It distinguishes itself from siblings like reddit_get_comment_replies and reddit_get_comments_batch by focusing on one comment's data. The specific mention of author info, scores, reply presence, and media makes the purpose unambiguous.

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 usage for retrieving a single comment but does not explicitly state when to choose this over alternatives such as reddit_get_post_comments or reddit_get_comment_replies. No exclusion or alternative guidance is provided, leaving the selection to inference.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond those flags: it returns only direct (not nested) replies, uses cursor-based pagination, and supports projection/payload reduction. These are operational traits the agent would not otherwise know.

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 with no wasted words. The primary behavior and pagination concept are front-loaded, and the projection capability is summarized in a single clause. 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?

For a read-only tool with 100% schema coverage and no output schema, the description is reasonably complete: it defines the result scope ('direct replies'), pagination style, and payload-control options. It could be more explicit about how the cursor is passed/returned, but the schema's cursor and nextCursor field descriptions mostly fill that 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?

Schema description coverage is 100%, so the schema already documents all seven parameters and their enums. The description adds minimal extra meaning beyond linking projection_preset, data_fields, and item_fields to 'payload reduction,' which is useful but does not individually explain any parameter 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 opens with a precise verb+resource: 'Returns direct replies to a Reddit comment.' It also states the pagination mechanism and the projection options, so the tool's scope is unmistakable and it is clearly distinguished from sibling tools like reddit_get_comment or reddit_get_post_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?

The phrase 'direct replies' establishes a clear scenario where this tool applies, and cursor-based pagination hints at iterative fetching. However, it does not name any sibling alternatives or state when not to use this tool, leaving the agent to infer trade-offs versus reddit_get_post_comments or reddit_get_comments_batch.

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 discloses the rate limit behavior (up to 100 comments per request) and cost (1 credit per ID), which are not in the annotations. The annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to repeat those. It adds useful context: the batch limit and the credit cost, which an agent should know before calling.

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 concise (two sentences) and front-loads the most important facts: the batch nature, limit, and cost. It does not waste words on trivial details and is easy to scan.

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

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

Given that this is a straightforward batch retrieval tool with a clear read-only purpose, the description covers the essential facts: limit, cost, and the optional payload reduction parameters. There is no output schema, but the tool returns Reddit comments, which is implied. It does not mention that the response follows a standard structure (e.g., includes items with comment data), but for a simple tool this is adequate. It is slightly incomplete in not specifying the default projection_preset behavior (though the schema says default is minimal, the description doesn't reinforce it).

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

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

Schema description coverage is 100%, so all parameters are documented in the schema. The description adds the note that projection_preset and data_fields allow payload reduction, which is helpful but not essential because the schema defines the enum values and their purpose. The description does not clarify the difference between projection_preset and data_fields or how they interact (e.g., whether data_fields adds to the preset), but this is a minor gap given the schema's explicit enum 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 clearly states the tool's function: retrieving up to 100 Reddit comments by ID in a single request. It distinguishes it from the sibling tool 'reddit_get_comment' (singular, presumably one comment at a time) through the 'batch' in the name and the explicit 'in a single request' and 'up to 100' details, though it does not explicitly name the sibling.

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 usage for batch retrieval of multiple comments by ID, and mentions cost (1 credit per ID), which helps an agent understand the trade-offs. However, it does not explicitly specify when to use this tool versus alternatives like `reddit_get_comment_replies` for replies or `reddit_get_subreddit_comments` for recent comments without IDs. It also doesn't state that this is for fetching comments by known IDs, implying that usage with unknown IDs would be inappropriate.

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, idempotentHint=true, and destructiveHint=false, covering safety. The description adds that it supports projection_preset, data_fields, and item_fields for payload reduction, which is a useful capability but not a behavioral trait like side effects or auth. It does not contradict annotations. Given the annotations cover the main safety profile, this is a 3.

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 with no fluff. The primary function and feed types are front-loaded, and the payload reduction mention is a concise secondary note. Every word 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?

For a read-only feed tool with all parameters documented in the schema and annotations covering safety, the description is sufficient. It does not explain return format or pagination, but the schema includes cursor and count parameters, and the absence of an output schema means the description need not detail returns. It covers the key distinguishing features (feed types and payload reduction).

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 100% – every parameter has a description. The description mentions projection_preset, data_fields, and item_fields and adds the purpose 'payload reduction', which clarifies their intent beyond the schema's listing. However, it does not add format or usage details beyond that, 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?

The description states a specific verb ('Returns posts') and a specific resource ('top-level Reddit feed') with an enumerated list of feed kinds (best, hot, new, top, rising, controversial). This clearly distinguishes it from sibling tools like reddit_get_subreddit_posts or reddit_get_user_posts, which target different scopes.

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 tool is for global/top-level feeds (as opposed to subreddit or user feeds) by using 'top-level Reddit feed', but it does not explicitly name alternatives or provide exclusions. An agent can infer when to use it from the scope, but the guidance is not as explicit as naming sibling tools or conditions.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that it supports projection_preset and data_fields for payload reduction, which is useful but not deep (e.g., no mention of rate limits, auth, or error behavior). It doesn't contradict 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?

Two sentences with no fluff. The purpose is front-loaded, and the mention of projection/data_fields is relevant. Each sentence earns its place, though the second sentence could arguably be inferred from the schema.

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 read-only retrieval tool with 100% schema coverage and no output schema, the description is adequate. The main missing pieces are whether the tool requires authentication or has rate limits, but given annotations cover safety, this is not critical. The sibling landscape is complex, but the tool's scope (single post vs. batch) is clear.

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 schema already documents postId format, projection_preset defaults and enum values, and data_fields semantics. The description adds a high-level summary of what the parameters achieve (payload reduction) but doesn't go beyond the schema details. 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 clearly states it returns a Reddit post with specific content (title, body, author info, engagement counts, attachments). It distinguishes from siblings like reddit_get_post_comments and reddit_get_post_duplicates by focusing on the post itself. However, it doesn't explicitly name the siblings it is not, which keeps it from 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?

The description implies use when you need a single post's data, but it doesn't provide explicit when-to-use vs. when-not-to-use or mention alternatives like reddit_get_posts_batch for multiple posts or reddit_get_post_comments for comments. The presence of reddit_get_post_duplicates suggests a related tool, but no comparison 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 cover safety (readOnlyHint, idempotentHint, destructiveHint). The description adds useful behavioral context beyond those: top-level-only scope, support for ordering and cursor-based pagination, and the purpose of projection parameters for payload reduction. It stops short of describing response format or edge cases, but the annotations lower the burden.

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 focused sentences with no filler. The core action is front-loaded in the first sentence, and the remaining sentences each add distinct capability information (ordering, pagination, payload reduction).

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 read-only, well-annotated tool with a fully documented schema, the description covers the essential behavioral aspects: scope, ordering, pagination, and projection purpose. No output schema exists, but the item_fields enum and the description's references to top-level comments give an agent enough context to call the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds a slight semantic layer by grouping projection_preset, data_fields, and item_fields as 'payload reduction,' but it does not add meaning beyond the parameter descriptions already present 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?

The description uses a specific verb with a clear resource: 'Returns top-level comments on a Reddit post.' It distinguishes itself from siblings like reddit_get_comment_replies by explicitly limiting scope to top-level comments, so an agent can tell this tool apart 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?

The phrase 'top-level comments' provides clear context about when this tool is appropriate and implicitly excludes reply chains, but it does not explicitly name alternatives such as reddit_get_comment_replies or reddit_get_comments_batch. This is clear context rather than full when/when-not 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, idempotentHint=true, and destructiveHint=false, covering safety. The description adds that it supports payload reduction via projection_preset, data_fields, and item_fields, which is useful context. However, it does not disclose pagination behavior (despite cursor/count params) or the exact return format, so the added behavioral detail is modest.

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 two sentences with zero fluff. The primary function is front-loaded, and the secondary mention of payload reduction is concise. Every sentence earns its place, making it appropriately sized and 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 there is no output schema, the description does not explain the return format or pagination details. It mentions the resource type (duplicates/crossposts) but not the structure (e.g., array of items). The presence of cursor/count in the schema hints at pagination, but the description lacks explicit guidance. This is adequate but not fully complete for an agent to anticipate all response aspects.

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 parameters are documented. The description groups projection_preset, data_fields, and item_fields as 'payload reduction,' which adds a high-level semantic summary beyond individual schema descriptions. However, the schema already explains these fields in detail, so the description adds marginal value—meeting the baseline for high 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?

The description clearly states the tool returns duplicate submissions and crossposts for a given Reddit post, with a specific verb ('Returns') and resource ('duplicate submissions and crossposts'). This distinguishes it from sibling tools like reddit_get_post or reddit_get_post_comments, making its purpose unambiguous.

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 when to use the tool (when needing duplicates/crossposts) but provides no explicit guidance on when not to use it or alternatives. It does not contrast with siblings like reddit_get_post, though the unique function makes selection intuitive. No exclusions or alternative mentions are present.

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 cover read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations by disclosing the credit cost per ID and the 100-post limit, which are not visible in the structured metadata.

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 dense sentences, each earning its place: the first states the core function and limit, the second covers cost and parameter purpose. No filler or repetition of annotation data.

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 provides the essential facts an agent needs: what it returns, the maximum batch size, cost, and how to reduce payload. It could mention output format or explicitly contrast with reddit_get_post, but the schema and annotations cover most operational details.

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 100%, so the baseline is 3. The description adds meaning by explaining that projection_preset and data_fields exist for 'payload reduction', which clarifies their purpose beyond the raw enum names. It does not redundantly restate schema details.

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 verb and resource: returns Reddit posts by ID. It clearly distinguishes this batch tool from the singular reddit_get_post and from comment-batch variants by emphasizing 'up to 100' and 'in a single request'.

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 its use case—fetching many posts by ID in one request—through the word 'batch' and 'single request'. However, it does not explicitly say when to prefer this over reddit_get_post or any exclusions, leaving the routing decision somewhat implicit.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the data is public and that projection_preset/data_fields support payload reduction, which is useful behavioral context beyond the annotations. However, it does not disclose edge behaviors like missing subreddits or response shape, so it stops at adequate rather than rich.

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 with no filler. The first sentence states the core return value and examples; the second covers the optional payload controls. Information is front-loaded and 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?

For a simple read-only metadata getter, the description covers what the tool returns and how to reduce payload. The input schema fully documents parameters, and annotations cover safety. With no output schema, a bit more detail about the response envelope or error behavior would be ideal, but the current description is 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 coverage is 100%, so the baseline is 3. The description adds semantic value by explaining that projection_preset and data_fields exist 'for payload reduction,' which clarifies their purpose beyond the schema's individual descriptions. This is a modest but genuine addition.

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 uses a specific verb ('Returns') and resource ('public subreddit metadata') and enumerates concrete fields (title, description, icon, banner, subscriber count). This clearly distinguishes it from sibling tools like reddit_get_subreddit_posts or reddit_get_subreddit_rules, which target different data.

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 phrase 'public subreddit metadata' gives clear context for when to use this tool: when you need the subreddit's profile-level information rather than its posts, comments, or rules. It does not explicitly name alternatives or exclusions, but the metadata framing is enough to route an agent correctly among the reddit_get_subreddit* 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 cover safety with readOnlyHint, idempotentHint, and destructiveHint=false, lowering the burden. The description adds useful behavioral context: time windows only apply to top and controversial ordering, and projection_preset/data_fields/item_fields are for payload reduction. It does not disclose pagination cursor behavior, but that is partially present in the 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?

Two tight sentences: the first front-loads the core result, and the second summarizes supported options. There is no filler or redundant restatement of 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?

Given the rich input schema, the strong safety annotations, and the description covering ordering, time windows, and payload reduction, an agent can call this tool correctly. There is no output schema, but the return concept is clear enough; pagination details are hinted by the cursor parameter and are not a blocker.

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 individual parameter descriptions already explain enums, defaults, and field-selection behavior. The description's mention of projection_preset, data_fields, and item_fields for payload reduction adds only a modest high-level label rather than meaningful new 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 uses a specific verb ('Returns') and a clear resource ('public comments from a subreddit'), and it lists ordering options that narrow the behavior. It is distinguishable from siblings like reddit_get_subreddit_posts and reddit_get_post_comments by the resource phrase, though it does not explicitly name any sibling.

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 prefer this tool over alternatives such as reddit_get_post_comments, reddit_get_comments_batch, or reddit_get_feed. The description states what it does but provides no conditions or exclusions for selecting 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds public scope and sorting/projection behavior, but it does not disclose pagination details, rate limits, or error behavior. This is moderate added 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?

Three front-loaded sentences with no filler. The opening sentence identifies the core function, and the following sentences concisely capture the most important behavioral options. 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?

For a read-only list tool with rich annotations and a fully described schema, the description covers the main capabilities. It does not explicitly explain the pagination workflow, but the schema's cursor and data_fields enums hint at nextCursor and orderedItems. A short note about pagination would make it 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 coverage is 100%, so the baseline is 3. The description adds value by grouping projection_preset, data_fields, and item_fields as payload-reduction controls and by clarifying that time windows apply to top and controversial ordering. This goes slightly beyond the per-field 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 clearly states the action ('Returns public posts') and the resource ('from a subreddit'), which distinguishes it from subreddit-comment and subreddit-info tools. However, it does not explicitly contrast with sibling tools like reddit_search_posts or reddit_get_posts_batch.

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: call this when you need public posts from a specific subreddit. It gives useful parameter context such as ordering options and time windows, but it does not provide explicit when-to-use vs. when-not-to-use guidance or mention alternative 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?

Annotations already cover read-only and idempotent behavior, so the description does not need to restate those. It adds useful context about returning structured rules and supporting payload reduction, but does not disclose additional behavioral details such as output shape or any limitations.

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 core purpose and followed by a concise mention of relevant parameters. Every word earns its place, and there is no redundant restatement of the tool name or 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?

For a simple read-only tool with one required parameter and fully documented optional parameters, the description is largely complete. The only minor gap is the absence of an output shape description, especially since no output schema is provided, though 'structured community rules' and the field enums give a reasonable picture.

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 schema already documents all four parameters including the subreddit prefix rule, projection presets, and field arrays. The description adds modest value by noting that projection_preset, data_fields, and item_fields serve payload reduction, but it does not explain parameter semantics beyond that.

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 uses a specific verb and resource: 'Returns structured community rules for a subreddit.' This clearly identifies what the tool does and distinguishes it from sibling Reddit tools like post, comment, or sticky retrieval without requiring the schema to be opened.

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 by the stated purpose: use it when you need a subreddit's rules. However, it does not explicitly mention when to prefer this over sibling tools, nor does it provide exclusions or alternative routing 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 cover readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds meaningful behavioral context: the per-ID credit cost and the payload reduction options (projection_preset, data_fields). These go beyond the annotations and help the agent anticipate resource usage and response size. No contradictions found.

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 two concise sentences with no filler. The core capability, limit, and cost are front-loaded in the first sentence, and the second sentence adds useful payload control info. Every word 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?

For a batch read tool with clear schema and annotations, the description covers the essential operational details: max count, cost, and output reduction options. It does not mention return format or error behavior, but since there is no output schema and the tool is simple, the lack of these is not a significant gap. The description is sufficient for an agent to call 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 coverage is 100%, with each parameter (entityIds, data_fields, projection_preset) having a description. The description adds a high-level purpose ('payload reduction') but does not elaborate beyond what the schema already provides (e.g., enums, default values). The description's mention of 'projection_preset and data_fields' is redundant with the schema, so it adds limited incremental value.

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 a specific verb ('Returns') and resource ('Reddit subreddits') with a batch scope ('up to 100... in a single request'). It distinguishes itself from single-subreddit and batch-post/comment tools by focusing on subreddit IDs, and the 'batch' keyword aligns with 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?

The description implies usage for retrieving multiple subreddits at once and explicitly notes the credit cost, which is useful for deciding when to call it. However, it does not mention alternatives (e.g., reddit_get_subreddit for single calls) or provide explicit when-not-to-use guidance. The context signals show many sibling tools, but the description leaves selection entirely to the agent's inference.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the agent knows this is a safe, read-only, non-destructive call. The description adds that it returns sticky posts across 'all available slots' and mentions payload reduction, which is useful but does not elaborate on slot semantics or any rate limits.

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 two concise sentences, front-loading the core purpose and then the payload reduction options. No waste, though it could be slightly more structured with a clearer subject-verb-object order.

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 read-only tool with full schema coverage and clear annotations, the description is sufficient for basic invocation. It could be enhanced by clarifying the 'all available slots' behavior (e.g., typically 2 stickies) and specifying the default response shape, but these are minor gaps given the tool's simplicity.

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 each parameter is documented in the schema. The description mentions projection_preset, data_fields, and item_fields by name but does not add meaning beyond the schema's own documentation, such as examples or how they interact.

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 the tool returns sticky posts for a subreddit and mentions payload reduction options. It is distinct from sibling tools like reddit_get_subreddit_posts (which lists posts) and reddit_get_post (single post), though it does not explicitly differentiate itself from related subreddit 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?

The description implies use for retrieving sticky posts but does not explain when to prefer this over reddit_get_subreddit_posts or other Reddit tools. No exclusions or alternative routing is provided, leaving the agent to infer the purpose from the name and description.

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, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds that it returns public info and supports payload reduction, but does not address error behavior (e.g., nonexistent user), authentication requirements, or rate limits. With annotations covering the core safety, this is adequate but not rich.

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 with zero redundancy. The primary action and key fields are front-loaded, and the payload reduction capability is mentioned without elaboration. Every word 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?

For a simple read-only tool with one required parameter and well-documented schema, the description covers the core functionality and mentions key fields. It does not specify the exact return structure, but given the absence of an output schema, the listed fields provide a reasonable preview. Error handling or auth is not mentioned, but annotations already indicate safety.

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 100%, so both data_fields and projection_preset are already documented. The description adds functional purpose – 'payload reduction' – which explains why these parameters exist and how they affect output. This goes beyond the schema's basic field descriptions, adding meaningful 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 description states a clear verb ('Returns') and resource ('public Reddit user profile information'), and enumerates specific fields (bio, avatar, verification flags, account creation date). It clearly differentiates from sibling tools like reddit_get_user_posts and reddit_get_user_comments by focusing on profile metadata rather than 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 description implies usage by specifying what it returns – profile information – which implicitly distinguishes it from siblings that handle posts or comments. However, it does not explicitly name alternatives or state when not to use this tool. The context is clear enough for an agent to infer, but explicit guidance would be stronger.

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, idempotentHint=true, and destructiveHint=false, so the bar is lower. The description adds useful behavioral context: only 'public' comments are returned, and ordering/time-window options are disclosed. It does not mention pagination behavior, rate limits, or empty-user edge cases, but the additional context is meaningful.

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, purpose front-loaded. The first sentence states exactly what the tool does; the second enumerates supported ordering and payload-reduction options. No wasted words, no repetition of schema details.

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

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

For a read-only, idempotent tool with a fully documented 8-parameter schema, the description plus schema provide enough to invoke the tool correctly. It explains the core result and available options. It does not describe the response shape or cursor mechanics, but with no output schema and robust annotations this is a minor 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?

Schema description coverage is 100%, so the schema already documents every parameter including enums, defaults, and the count constraint. The description merely restates 'projection_preset, data_fields, and item_fields for payload reduction' without adding format or syntax detail. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Returns public comments made by a Reddit user.' This unambiguously identifies what the tool does and distinguishes it from sibling tools like reddit_get_user_posts by resource type. However, it does not explicitly name or contrast with close siblings such as reddit_get_user_overview, so it doesn't reach 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?

Usage is implied through 'comments made by a Reddit user', which tells the agent this is the tool for user comment history. But it provides no explicit context on when to choose this over alternatives like reddit_get_user_overview, reddit_get_user_posts, or reddit_get_post_comments, and no exclusions are stated.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the description need not repeat safety. The description adds that it supports multiple orderings and payload reduction, which is parameter-related rather than behavioral. No contradictions.

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, front-loaded with the core purpose, then lists options. No fluff, efficient.

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 no output schema, the description states what is returned (mixed feed) and mentions ordering and payload reduction. It doesn't describe pagination behavior, but the schema covers cursor and count. It's adequate for an agent to understand the tool's function, though not exhaustive.

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 parameters are documented. The description mentions projection_preset, data_fields, and item_fields for payload reduction, which aligns with schema but adds little beyond it. No additional semantics beyond what schema provides.

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 it returns a mixed Reddit user activity feed including posts and comments, distinguishing it from siblings like reddit_get_user_posts and reddit_get_user_comments. The verb 'Returns' is specific and the resource is well-defined.

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 usage for combined activity but doesn't explicitly name alternatives or when to use them. It provides clear context that it includes both posts and comments, but no exclusions or guidance on when to prefer the specialized 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?

Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds the constraint that only public posts are returned and mentions payload reduction, but does not disclose pagination behavior, error handling, or rate limits. The additional context is minimal, so a 3 is appropriate.

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 concise sentences, with the core purpose front-loaded and key options listed without repetition. No filler or redundant phrasing, making it easy for an agent to quickly grasp 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?

For a read-only retrieval tool with a fully described schema, the description covers the essential purpose and main features. It lacks explicit mention of response format or pagination details, but given the absence of an output schema, it is still reasonably complete 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 100%, so all parameters are documented. The description's mention of ordering and time windows mirrors the schema, and the phrase 'for payload reduction' summarizes the projection parameters without adding significant new meaning. The baseline of 3 applies.

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

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

The description clearly states the verb 'Returns' and the resource 'public posts submitted by a Reddit user', immediately distinguishing this from sibling tools like reddit_get_user_comments or reddit_get_user_overview. It also mentions specific features (ordering, time windows, payload reduction) that further define its scope.

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 choose this tool over alternatives such as reddit_get_user_comments or reddit_get_user_overview. The description merely lists capabilities without any contextual exclusions or selection criteria, leaving the decision entirely to the agent.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety and idempotency profile is fully covered without the description. The description adds that results are 'public' posts and mentions sorting/time-window capability, which is modest added context but not deep behavioral disclosure such as rate limits or pagination semantics.

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 short sentences with the core purpose front-loaded, followed by capability and payload-reduction notes. No filler, though the sorting list inherently duplicates enum values and could be trimmed.

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 8-parameter search tool with no output schema, the description is adequate but not rich: it never explains what a result item contains, how cursor pagination advances, or why one projection_preset should be chosen over another. The annotations carry the safety profile and the schema carries the parameters, so the remaining gap is response shape and pagination behavior.

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 100%, so all eight parameters are documented in the schema itself, establishing a baseline of 3. The description restates the sort orders, time windows, and the projection/data_fields/item_fields parameters without adding syntax, defaults, or interaction 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?

The description names a specific verb and resource ('Searches public Reddit posts') and scopes it to platform-wide coverage, which implicitly separates it from the sibling reddit_search_subreddit_posts. It stops short of explicitly naming that alternative, so an agent still has to infer the distinction rather than being told it.

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 'across the platform' versus the subreddit-scoped sibling, but there is no explicit when-to-use/when-not statement and no mention of prerequisites or fallbacks. An agent can guess the right case but is given no routing rule.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the payload-reduction capability (projection_preset/data_fields/item_fields), which is behaviorally useful context, but says nothing about auth, rate limits, or pagination behavior beyond what annotations/schema already imply.

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 front-loaded sentences with no filler; the core scope arrives first, followed by sorting and payload options. Efficient and easy to scan.

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 9 params, full schema coverage, no nested objects, and no output schema, the description covers the essential search behavior (scope, sorting, time windows, projection). The only real gap is that pagination via cursor goes unmentioned, but it is documented 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 the baseline is 3. The description restates the order and time options already enumerated in the schema and adds only the purpose ('payload reduction') behind the projection fields, which is a modest value-add over the schema text.

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+scope: 'Searches public Reddit posts within a subreddit.' The 'within a subreddit' scope implicitly separates it from the global reddit_search_posts and from the listing-style reddit_get_subreddit_posts, but it never names a sibling to make the distinction explicit.

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 when-to-use guidance relative to alternatives such as reddit_get_subreddit_posts or reddit_search_posts. It lists supported sorting modes but offers no conditions, exclusions, or routing advice, leaving selection to inference.

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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety and idempotency profile is fully covered. The description adds a modest amount of context (results are limited to public subreddits), but says nothing about pagination behavior or result shape beyond the projection parameters.

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 with the core purpose front-loaded and no filler. The second sentence is slightly parameter-listing rather than pure guidance, but it is compact and does not bloat 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 read-only search tool with a fully documented schema and annotations covering safety, the description is minimally sufficient. Given the large sibling set of reddit_search_* and reddit_get_subreddit* tools, it could do more to route the agent, but nothing critical is missing for a correct call.

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 six parameters including count limits, cursor, and the enum values for projection_preset/data_fields/item_fields are documented in the schema itself. The description only restates that projection_preset, data_fields, and item_fields exist "for payload reduction," adding a small hint of intent but no syntax or defaults 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 states a specific verb and resource ("Searches... subreddits") plus scope ("public Reddit subreddits across the platform"), which clearly separates it from siblings like reddit_search_posts and reddit_search_users. It does not, however, explicitly name those alternatives to sharpen the distinction.

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 exclusions, and no mention of alternatives such as reddit_get_subreddits_batch or reddit_search_subreddit_posts. The agent must infer the appropriate context entirely from the name.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description's only extra behavioral detail is the scope qualifier 'public Reddit users', which is mildly useful but thin; no pagination, rate-limit, or result-shape context is provided.

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, front-loaded sentences with no filler. The second sentence borders on restating the schema parameters, which slightly dilutes its 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?

With no output schema, the description should hint at the return shape or pagination behavior (the cursor parameter exists), but it omits both. Safety behavior is adequately covered by annotations, so the gap is moderate rather than severe.

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

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

Schema description coverage is 100% with 6 well-documented parameters, so the schema carries the burden. The description names projection_preset, data_fields, and item_fields but adds no meaning about what presets contain or how the fields interact with them.

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 gives a specific verb and resource ('Searches public Reddit users') and implicitly separates itself from reddit_search_posts and reddit_search_subreddits, which target different entities. It stops short of explicitly naming those siblings, so it lacks 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?

There is no guidance on when to use this search versus reddit_get_user or the other reddit_search_* tools, nor any prerequisites or context. The only usage-ish statement is about which payload-reduction parameters are supported.

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 cover read-only, idempotent, non-destructive behavior, so the description's job is lighter. It adds useful behavioral context: the operation is an ID-based metadata lookup and it supports projection_preset/data_fields to reduce payload. No statement contradicts 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?

Three sentences, each earning its place: what the tool returns, the lookup key, and the optional payload-reduction feature. The key information is front-loaded 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 simple read-only ID lookup with a fully covered schema, the description is largely complete: it names the resource, the lookup key, and return highlights. Although there is no output schema, the data_fields enum documents available output keys, so an agent can infer the response shape sufficiently; the exact full shape is not a major 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?

With 100% schema description coverage, the baseline is 3. The description adds meaning above the schema by explaining audioId's lookup role and the purpose of projection_preset/data_fields as payload reduction, which helps an agent select parameters. It does not need to restate schema details because they are fully documented.

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: it returns metadata for a TikTok audio track keyed by audio ID, listing representative fields (title, artist, duration, usage count, cover image). This clearly separates it from sibling tools like tiktok_get_audio_videos, which concern videos rather than audio metadata.

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 a clear use context: look up any sound by its audio ID, implying the tool is appropriate when an agent already has an audio ID and needs metadata. It does not explicitly name alternatives or exclusion conditions, so it falls short of full routing guidance, but the intended use case is unambiguous.

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, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds useful behavioral context: paginated results, a maximum of 30 per page, and payload-reduction options. It does not contradict 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?

Three short sentences with no wasted words. The core function is front-loaded, followed by the pagination limit, a usage hint, and the payload-reduction feature. 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?

For a paginated read-only list endpoint, the description provides the essential orientation: what is returned, the page-size limit, and projection options. Cursor mechanics and defaults are already in the schema. It does not explain the response shape, but no output schema exists and the domain is simple enough that this is a minor 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?

The schema already covers all parameters, giving a baseline of 3. The description adds extra meaning by naming projection_preset, data_fields, and item_fields and explaining their purpose ('for payload reduction'), which goes beyond the raw field 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 states a specific verb-resource pair: 'Returns a paginated list of TikTok videos using a specific audio track.' This clearly differentiates it from siblings like tiktok_get_audio (which fetches the audio track itself) and tiktok_get_trending_videos or tiktok_get_tag_videos (which use different discovery mechanisms).

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 phrase 'Discover trending content by sound or music' gives an explicit use case, making the audio-based discovery intent clear. It does not name alternatives or state when not to use this tool, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral context: pagination, a maximum page size of 35, inclusion of full video details and engagement counts, and payload-reduction options. 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?

Three concise sentences, front-loaded with the core purpose, followed by constraints and payload-reduction capabilities. Every sentence adds value and there is no filler.

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 read-only paginated list tool, the description is largely complete: it states the resource, pagination behavior, and output richness. The schema covers parameters and annotations cover safety. It could mention cursor-based pagination more explicitly, but this is not a significant 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?

Schema description coverage is 100%, so the schema already documents all parameters. The description adds context for projection_preset, data_fields, and item_fields as payload-reduction controls, but it does not explain cursor semantics or defaults beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Returns a paginated list of videos in a TikTok collection (playlist or mix).' It clearly distinguishes this from sibling tools like tiktok_get_user_collections by indicating it returns the contents of a collection, not the collection list itself.

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 clear context for when to use this tool: when retrieving videos from a TikTok collection. It does not explicitly name alternatives or exclusions, but the resource scope is unambiguous enough that an agent can infer the intended use case.

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, idempotentHint, and destructiveHint=false. The description adds useful behavioral context beyond annotations: pagination behavior, 50-per-page cap, and the response contents (author info, like counts, timestamps). It does not discuss cursor semantics, but the schema covers the cursor parameter.

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 sentences, with the core behavior first, followed by the most important constraint (max 50 per page), then response contents and payload reduction options. Every sentence earns its place with no filler.

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 no output schema, the description helpfully states key return contents and pagination limits. It is mostly complete for a read-only, idempotent tool, though it could have explicitly described cursor-based navigation or pointed to tiktok_get_video_comments for top-level comments.

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 100%, so the baseline is 3. The description adds value by explaining that projection_preset, data_fields, and item_fields are used for payload reduction, giving the agent a purpose for those parameters beyond their schema definitions.

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 ('Returns') and resource ('replies to a TikTok comment'), which clearly distinguishes it from sibling tools like tiktok_get_video_comments. It also adds useful scope details: paginated, max 50 per page.

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 when to use the tool: when you need replies to a specific comment. However, it does not explicitly contrast it with tiktok_get_video_comments or mention when not to use it, leaving the routing decision to inference.

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 establish the tool is read-only, idempotent, and non-destructive. The description adds meaningful behavioral details beyond those annotations: automatic tag-to-ID resolution, inclusion of video details and engagement counts, and support for projection presets with payload reduction. This gives the agent useful insight into how the tool behaves without contradicting the annotations.

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

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

The description is three sentences, front-loaded with the main purpose, and every sentence contributes useful information. It avoids redundancies and does not pad with generic filler.

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 the tool's purpose, core result content, and payload-reduction options, which is adequate given the rich schema and safety annotations. It does not explicitly describe pagination behavior or the return envelope, but the schema's cursor parameter and data_fields enum provide enough cues that this is not a critical 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?

Input schema covers all parameters, so the baseline is 3. The description adds value by explaining that tagName is auto-resolved to an internal ID and that projection_preset, data_fields, and item_fields serve a payload-reduction purpose, which supplements the schema descriptions meaningfully.

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 uses a specific verb ('Returns') and resource ('TikTok videos associated with a hashtag or challenge'), clearly distinguishing this from sibling tools like tiktok_get_trending_videos or tiktok_get_audio_videos. It explains that the tool resolves a tag to an internal ID, which further clarifies its unique function.

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 clearly implies the tool is for retrieving videos by tag or challenge, giving the agent enough context to choose it for hashtag-based requests. However, it does not explicitly mention when not to use it or name an alternative tool for related but different use cases, such as searching videos or getting a specific video.

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, idempotentHint, and openWorldHint annotations, the description adds meaningful behavioral detail: calls are not paginated, each call returns an independent batch, and results are sourced from the For You feed. These are not inferable from annotations or schema and materially affect how an agent should interpret 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?

Three concise sentences with no filler. The core behavior is front-loaded, followed by the important non-pagination caveat and the payload-reduction note. 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 description is largely complete for a read-only feed tool with full schema coverage and annotations: it states purpose, source, pagination behavior, and payload options. Since there is no output schema, a slightly more explicit statement about the response shape would make it fully complete, but the item_fields schema already hints at the orderedItems structure.

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 100%, so the input schema already documents all five parameters. The description adds only a modest semantic note that projection_preset, data_fields, and item_fields support 'payload reduction', which is useful but not a significant addition over the schema's own 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 states a specific verb and resource: it 'returns a feed of popular TikTok videos' and clarifies the source is TikTok's For You feed since there is no separate curated trending ranking. This distinguishes it from sibling tools that return tag, audio, user, or collection videos.

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 for when to use the tool: when you need broad 'trending' videos and no curated ranking exists. It also provides an important operational guideline (not paginated, independent batches). However, it does not explicitly name alternatives or state when not to use this tool.

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 the operation as read-only, idempotent, open-world, and non-destructive. The description adds useful behavioral context by specifying what profile data is returned and that it works for any public account, without contradicting the annotations.

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

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

The description is three short sentences, each earning its place: what is returned, when to use it, and how to reduce payload. It is front-loaded with the core behavior and contains no filler.

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 read-only lookup tool with no output schema, the description adequately covers purpose, scope, and return contents. It does not discuss edge cases like nonexistent or private accounts, but the 'public' qualifier and annotation hints keep it reasonably 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 coverage is 100%, so the baseline is 3. The description adds value by explaining that projection_preset and data_fields exist for 'payload reduction,' which clarifies their intent beyond the schema's optional or defaulting notes.

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 ('Returns profile information for a TikTok user') and lists distinguishing content fields such as bio, follower counts, verification status, and profile picture. This clearly separates it from sibling tools like tiktok_get_user_videos or tiktok_get_user_followers.

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: 'Look up any public TikTok account by username.' This tells an agent when the tool is appropriate, though it does not explicitly contrast it with alternatives or state when another tool should be used 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 establish read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond annotations by disclosing pagination and the specific included fields (name, cover image, video count) and by noting payload reduction options. This meaningfully helps the agent predict tool 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?

Three concise sentences, each carrying distinct information: what is returned, what data is included, and how payload can be reduced. The description is front-loaded with the core purpose and contains no filler or redundancy.

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 annotations cover safety and idempotency, and the schema covers all parameters at 100%, the description is largely complete. It explains the result type, pagination, and payload controls. It does not describe the exact response structure, but the absence of an output schema is partially offset by the parameter enums and the description's field list.

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 baseline is 3. The description adds semantic value by explaining that projection_preset, data_fields, and item_fields are used for payload reduction, and by summarizing the returned collection attributes. This goes beyond the raw schema definitions.

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 the verb ('Returns'), the resource ('video collections... on a TikTok user's profile'), and disambiguates the content type ('playlists and mixes'). This is sufficiently distinct from sibling tools like tiktok_get_collection_videos, making the tool's purpose immediately understandable.

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 use when a user's profile collections are needed, and it specifies the context ('on a TikTok user's profile'). However, it does not provide explicit guidance on when to prefer this tool over related siblings such as tiktok_get_collection_videos, nor does it mention exclusions or prerequisites.

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 establish readOnly/idempotent/non-destructive behaviorikuha. The description adds valuable behavior beyond annotations: it's paginated, max 30 per page, includes profile details, and supports payload reduction. A 4 reflects this added context; a 5 would require disclosure of rate limits or auth requirements, which are absent.

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 succinct sentences with no filler. The primary function is front-loaded, followed by the pagination constraint and then the projection flexibility. 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?

For a read-only list tool with a well-described schema and no output schema, the description covers the key operational details: pagination, page size, payload reduction, and profile details. It doesn't explain cursor mechanics explicitly, but the schema's cursor and count descriptions handle that. A 4 is fair; it's not missing anything critical for a simple read operation.

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 100% and every parameter is described at least brieflyasia. The description adds semantic meaning by connecting projection_preset, data_fields, and item_fields to 'payload reduction' and stating the 30-per-page limit tied to the count parameter. This exceeds 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 opens with a specific verb ('Returns') and a clear resource ('accounts following a TikTok user'), which precisely differentiates this from the sibling tool tiktok_get_user_following. It also avoids confusion with tiktok_get_user or other list-type tools by specifying 'followers' 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?

The description provides clear context: this is for fetching a paginated list of followers. It doesn't explicitly name alternatives or say 'when not to use' (e.g., for following lists use tiktok_get_user_following), but the tool name and description make the use case obvious. A 4 is appropriate for clear context without explicit exclusions.

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 cover read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond those: it is paginated, has a maximum of 30 per page, and returns profile details for each account. It does not mention rate limits or auth requirements, but given the annotation coverage, this is not a major gap.

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

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

Two succinct sentences front-load the core behavior and constraints: paginated list, 30-per-page max, profile details, and payload reduction options. There is no filler or repetition of schema details beyond what is useful.

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

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

Given the rich annotations and complete schema, the description covers the essential behavioral contract: what is returned, the pagination ceiling, and the projection mechanism. It does not describe cursor semantics or response structure in detail, but those are either implied by 'paginated' or documented in the schema. With no output schema, the high-level response shape it provides is adequate.

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 parameters are already documented in the schema. The description adds only a high-level grouping of projection_preset, data_fields, and item_fields as payload-reduction options. This is mildly helpful but does not significantly improve on the schema's own 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 states a specific verb ('Returns'), a concrete resource ('a paginated list of accounts a TikTok user follows'), and clarifies that profile details are included. This distinguishes it clearly from sibling tools like tiktok_get_user_followers and tiktok_get_user_videos without requiring an agent to infer from the name alone.

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 case is clear: fetching the accounts a given user follows. It does not explicitly name alternatives or say when not to use this tool, but the phrasing and the 'following' vs 'followers' distinction in sibling names provide strong contextual guidance. It lacks an explicit exclusion or comparison, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description's safety profile is covered. The description adds meaningful behavioral context beyond annotations: pagination, the empty-list-when-private edge case, and the ability to reduce payload via projection_preset/data_fields/item_fields. This is valuable but not exhaustive; no rate limits or auth details are mentioned.

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 compact: main purpose first, then an important edge case, then a brief mention of payload options. Every sentence earns its place, and there is no fluff or repetition. The structure front-loads the most critical information for an agent deciding to invoke 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?

For a read-only list tool with no output schema, the description covers the key operational aspects: what data is returned, pagination, privacy edge behavior, and payload reduction. The schema already documents parameters like cursor and count. Slightly more detail about the response shape would help, but it is not essential given the clear mention of pagination and adjustable fields.

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. The description adds some value by grouping projection_preset, data_fields, and item_fields as payload-reduction mechanisms, which reinforces their purpose. However, it does not provide any additional semantics beyond what the schema already documents for count, cursor, or username.

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 verb ('Returns') and resource ('paginated list of videos liked by a TikTok user'), making the tool's purpose unambiguous. It also includes a note about private likes, which distinguishes this from other tiktok_get_user_* tools that return different content types. The resource is clearly differentiated from siblings like tiktok_get_user_videos or tiktok_get_user_reposts.

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 tool should be used when a user's liked videos are needed, but it does not explicitly contrast it with sibling tools or state when not to use it. The privacy caveat gives context for interpreting empty results but does not serve as an exclusion or alternative recommendation. 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.