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

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it states 'REQUIRES AUTHENTICATION' (security requirement), describes the return value ('Returns a Bookmark object'), and explains the default behavior for auto_delete_preference. However, it doesn't mention potential side effects like duplicate bookmarks, error conditions, 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?

The description is well-structured with purpose statement, authentication requirement, parameter explanations, prerequisite, return value, and usage context. While slightly verbose with some repetition of schema information, every section serves a purpose. The front-loaded purpose statement is clear and immediately actionable.

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 mutation tool with no annotations but with comprehensive schema coverage (100%) and an output schema (implied by 'Returns a Bookmark object'), the description provides complete context. It covers authentication requirements, parameter meanings, prerequisites, return values, and usage context - everything needed for an agent to correctly invoke this tool.

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. The description adds minimal value beyond the schema: it repeats the post_id description verbatim and provides a slightly more detailed explanation of auto_delete_preference options. However, it doesn't add meaningful semantic context beyond what's already in the 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 specific action ('Bookmark a post for later reference') and distinguishes it from all sibling tools, which are primarily get/read operations (e.g., get_topic_posts, get_user_summary). It explicitly identifies the resource being acted upon (a post) and the operation (bookmarking).

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 explicit usage guidance: it states 'Must call login() first' as a prerequisite, and 'Use to save interesting posts for later reference' clarifies the intended context. While it doesn't explicitly mention when NOT to use it, the clear purpose and prerequisite make usage context unambiguous compared to read-only sibling tools.

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

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

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: automatic pagination, safety limits with max_posts, and the ability to fetch specific ranges. It mentions the return structure ('Returns the same Post structure as get_topic_posts') and provides practical tips. However, it doesn't cover potential errors, rate limits, or authentication needs, which keeps it from a perfect score.

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 well-structured with clear sections (purpose, args, important notes, use cases, returns, pro tip). It is front-loaded with the core purpose and includes only relevant details. However, it is slightly verbose with repetitive examples, which prevents a perfect score, but every sentence adds value to guide usage.

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

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

Given the tool's complexity (5 parameters, automatic pagination) and the presence of an output schema (which handles return values), the description is complete. It covers purpose, parameters, usage guidelines, behavioral traits, and integration with sibling tools. The output schema means the description doesn't need to explain return values in detail, and it effectively addresses all other aspects needed for correct tool selection and invocation.

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

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

The schema description coverage is 100%, so the baseline is 3. The description adds significant value beyond the schema by explaining parameter interactions and use cases in the 'Args' section and examples. It clarifies how parameters like start_post_number, end_post_number, and max_posts work together, and provides default behaviors. This enhances understanding beyond the schema's basic 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 purpose: 'Fetch all posts from a topic with automatic pagination.' It specifies the verb ('fetch'), resource ('posts from a topic'), and key behavior ('automatic pagination'). It distinguishes from sibling 'get_topic_posts' by emphasizing the automatic pagination for fetching all posts rather than manual pagination.

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 explicit guidance on when to use this tool versus alternatives. It includes an 'IMPORTANT' note for topics with many posts (>100) to use max_posts, advises using 'get_topic_info first to check post_count before deciding whether to fetch all or paginate manually,' and gives specific use cases with examples. It clearly differentiates from 'get_topic_posts' by handling pagination automatically.

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?

With no annotations provided, the description carries full burden and does well by specifying the return type ('CategoryMap object'), scope ('all forum categories'), and structure ('includes both main categories and subcategories'). It doesn't mention rate limits, authentication needs, or potential errors, but provides solid operational context.

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

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

The description is efficiently structured with clear sections: purpose statement, return specification, context examples, and usage scenarios. Every sentence adds value without redundancy, and it's appropriately sized for the tool's complexity.

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

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

Given the tool has no parameters, an output schema exists, and the description thoroughly explains what the tool does, its return format, real-world examples, and use cases, this provides complete contextual understanding for an AI agent to correctly invoke this tool.

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 0 parameters and 100% schema coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, instead focusing on the tool's purpose and output.

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

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

The description clearly states the specific action ('Get a mapping'), resource ('all forum categories'), and output format ('CategoryMap object with category_id to category name mapping'). It distinguishes this tool from siblings like get_hot_topics or get_new_topics by focusing on category metadata rather than topic 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 provides clear context for when to use this tool by listing specific use cases: filtering search results, understanding topic sections, and navigation. However, it doesn't explicitly state when NOT to use it or name alternative tools for related functions.

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?

No annotations are provided, so the description carries the full burden. It describes the return value (Session object with authentication and user info) and the tool's read-only nature (implied by 'Get'), but lacks details on behavioral traits like error handling, rate limits, or permissions required. This is adequate but has gaps for a tool with no 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 well-structured and concise, with three sentences that each add value: stating the purpose, detailing the return object, and providing usage guidance. It's front-loaded with the main action and wastes no words, making it efficient for an AI agent.

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

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

Given the tool's low complexity (0 params, no annotations, but has an output schema), the description is fairly complete. It explains what the tool does and what it returns, and the output schema handles return values. However, it could benefit from more behavioral context like error cases, but it's sufficient for this simple tool.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter info is needed. The description doesn't add param semantics, but that's fine since there are none. Baseline is 4 for 0 params, as it doesn't need to compensate for any gaps.

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 purpose: 'Get information about the current session.' It specifies the verb ('Get') and resource ('current session'), making it easy to understand what the tool does. However, it doesn't differentiate from siblings like 'login' or 'get_user_summary' that might also relate to authentication or user info, keeping it from a perfect score.

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 usage guidance with 'Use to verify authentication status,' indicating when to use this tool. It implies context for checking login status but doesn't explicitly state when not to use it or name alternatives like 'login' for authentication actions, which prevents a score of 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?

With no annotations provided, the description carries full burden and does well by explaining ranking methodology ('engagement metrics like recent replies, views, and likes'), pagination behavior, and response interpretation guidance. It doesn't mention rate limits or authentication requirements, but provides substantial behavioral context beyond basic functionality.

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

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

The description is well-structured with clear sections: purpose statement, usage guidelines, parameters, return format, and interpretation examples. Every sentence adds value, there's no redundancy, and information is front-loaded with the core purpose stated immediately.

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 one parameter and an output schema, the description is complete. It explains what the tool does, when to use it, how results are ranked, includes parameter guidance, documents the return structure, and provides interpretation examples - covering all necessary context despite having no annotations.

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 the single parameter 'page' fully documented in the schema. The description adds minimal value beyond the schema by mentioning 'Use page=1 to get more topics' which slightly clarifies usage but doesn't add significant semantic meaning. Baseline 3 is appropriate when 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 clearly states the specific action ('fetch trending/hot topics'), identifies the resource ('from USCardForum'), and distinguishes it from siblings by specifying it returns 'most actively discussed topics right now, ranked by engagement metrics' - differentiating it from tools like get_new_topics, get_top_topics, or get_categories.

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 explicit usage scenarios with three bullet points explaining when to use this tool ('See what the community is currently discussing', 'Find breaking news or time-sensitive opportunities', 'Discover popular ongoing discussions'), giving clear context for when this tool is appropriate versus alternatives.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it's a read-only fetch operation (implied by 'fetch' and 'returns'), returns sorted results (newest first), and notes that topics may have fewer replies. However, it lacks details on rate limits, authentication needs, or error handling, leaving some gaps.

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 well-structured and front-loaded, starting with the core purpose, followed by usage guidelines, args, returns, and a tip. Each sentence adds meaningful information without redundancy, making it efficient and easy to parse for an AI agent.

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

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

Given the tool's low complexity (1 optional parameter), 100% schema coverage, and the presence of an output schema (detailed in the returns section), the description is complete. It covers purpose, usage, parameters, returns, and additional tips, leaving no significant gaps for the agent to operate effectively.

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 explaining pagination semantics ('page=1 to get more topics') and providing a tip about high view counts, which offers context beyond the schema's technical details. This elevates the score above the baseline.

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

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

The description clearly states the tool's purpose with specific verbs ('fetch', 'returns') and resources ('latest/newest topics from USCardForum'), distinguishing it from siblings like get_hot_topics or get_top_topics by emphasizing recency over popularity or ranking. It explicitly mentions sorting by creation time and targeting fresh information, making the distinction 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 explicit usage scenarios ('Use this to:') with three concrete examples (finding deals, seeing fresh questions, discovering emerging discussions), clearly indicating when to use this tool. It also implicitly distinguishes from siblings by focusing on new topics rather than hot, top, or searched ones, though it doesn't name alternatives directly.

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?

With no annotations provided, the description carries full burden and does well: it discloses authentication requirement ('REQUIRES AUTHENTICATION'), specifies prerequisite action ('Must call login() first'), and describes return format. However, it doesn't mention rate limits, pagination behavior, or error conditions that would be helpful for a notification-fetching tool.

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

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

The description is well-structured with clear sections (purpose, authentication requirement, parameters, returns, use cases). While slightly verbose with the parameter repetition, every sentence adds value. The front-loaded purpose statement is clear and followed by important constraints.

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

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

Given the tool has an output schema (implied by the Returns section detailing Notification objects), the description provides excellent contextual completeness. It covers authentication requirements, parameter guidance, return format, and specific use cases - all necessary for a read-only data retrieval tool with authentication needs.

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 all three parameters. The description repeats the parameter information in the 'Args:' section but doesn't add meaningful semantic context beyond what's in the schema. This meets the baseline for high schema coverage.

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

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

The description clearly states the specific verb ('Fetch') and resource ('your notifications'), distinguishing it from siblings like get_user_actions or get_user_replies which focus on different data types. It explicitly identifies what resource is being retrieved.

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 explicit usage guidance: 'Must call login() first' establishes a prerequisite, and the 'Use to:' section gives three concrete scenarios for when to use this tool (checking replies, seeing mentions/likes, tracking topic updates). This clearly distinguishes it from other notification-related tools that don't exist in the sibling list.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it's a read-only operation (implied by 'Get metadata'), returns a TopicInfo object with specific fields, and includes practical advice on handling large topics (e.g., pagination strategies). It doesn't mention rate limits or auth needs, but covers key operational aspects well.

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 well-structured and front-loaded, starting with the core purpose, followed by args, usage guidelines, return values, and strategy. Every sentence adds value—no redundancy or fluff—making it efficient and easy to parse.

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

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

Given the tool's complexity (single parameter, read-only operation) and the presence of an output schema (which covers return values), the description is complete. It explains purpose, usage, parameters, and behavioral context without needing to detail return values, making it sufficient for an agent to use the tool effectively.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description adds value by explaining the parameter's source ('from URLs like /t/slug/12345') and its role in the tool's purpose, enhancing understanding beyond the schema's basic documentation. It doesn't add syntax details, but provides contextual meaning.

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 purpose: 'Get metadata about a specific topic without fetching all posts.' It uses a specific verb ('Get metadata') and resource ('specific topic'), and explicitly distinguishes it from sibling tools like 'get_all_topic_posts' and 'get_topic_posts' by emphasizing it doesn't fetch 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?

The description provides explicit guidance on when to use this tool: 'Use this FIRST before reading a topic' for checking post count, title, timestamps, and deciding on fetching strategy. It distinguishes from alternatives by noting it's for metadata only, not for fetching posts, and offers a strategy for large topics with specific thresholds (<50, 50-200, >200 posts).

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?

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the batch size ('~20 posts per call'), pagination behavior (starting from post_number, continuing until no posts returned), and return format (list of Post objects with detailed fields). It doesn't mention rate limits, authentication needs, or error conditions, but covers the core operational behavior well.

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 appropriately sized and well-structured: it starts with a clear purpose statement, lists parameters with defaults, explains the batch size and usage, details the return format, and provides a practical pagination example. Every sentence serves a purpose, though the parameter section is redundant with 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?

Given the tool's moderate complexity (paginated fetching), no annotations, and an output schema (implied by the detailed return description), the description is complete. It covers purpose, usage, parameters, behavior, and return values thoroughly, leaving no gaps for an agent to understand how to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all parameters fully. The description repeats the parameter explanations verbatim from the schema ('Args:' section) without adding meaningful context beyond what's in the schema. This meets the baseline of 3 since the schema does the heavy lifting, but adds no extra 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 the specific action ('Fetch a batch of posts from a topic') and resource ('posts from a topic'), distinguishing it from siblings like 'get_topic_info' (which likely gets metadata) and 'get_all_topic_posts' (which might fetch all posts at once). The verb 'fetch' combined with the resource specification 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 explicitly states when to use this tool ('Use for paginated reading of topics') and provides a detailed pagination example with steps. It implicitly distinguishes from 'get_all_topic_posts' by emphasizing batch fetching and pagination, though it doesn't name alternatives directly. The guidance is comprehensive for 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?

With no annotations provided, the description carries the full burden and adds valuable behavioral context: it discloses that results are sorted by engagement score, includes pagination details (0-indexed, page=1 for more topics), and specifies default values (e.g., 'monthly' as default period). However, it doesn't mention rate limits, authentication needs, or error handling, leaving some gaps.

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 well-structured and front-loaded with the core purpose, followed by parameter details, usage guidelines, and examples. Every sentence adds value—no wasted words—and it efficiently communicates necessary information in a compact format.

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 (2 parameters, 100% schema coverage, output schema exists), the description is complete: it covers purpose, parameters with examples, usage scenarios, return behavior (TopicSummary objects sorted by engagement), and distinguishes from siblings. The presence of an output schema means return values don't need explanation, and all gaps are adequately filled.

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 meaningful semantics beyond the schema: it explains the purpose of each period option (e.g., 'daily' for today's trends, 'yearly' for impactful discussions) and clarifies pagination usage ('Use page=1 to get more topics'), enhancing understanding without redundancy.

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 specific action ('fetch top-performing topics') and resource ('topics'), distinguishing it from siblings like 'get_hot_topics' or 'get_new_topics' by emphasizing ranking based on performance over a time period. The opening sentence directly answers what the tool does with precision.

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 provides usage scenarios ('Find the most valuable discussions', 'Research historically important threads', 'Identify evergreen popular content') and examples ('Use "yearly" to find the most impactful discussions, or "daily" to see what's trending today'), giving clear context for when to apply this tool versus alternatives like 'get_hot_topics' for trending content without performance ranking.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it fetches an activity feed with optional filtering, returns a list of UserAction objects, and mentions pagination via offset. It doesn't cover potential rate limits, authentication needs, or error conditions, but provides solid operational context.

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

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

The description is well-structured and appropriately sized. It starts with a clear purpose statement, provides parameter details in a readable format, explains the return value, and ends with usage guidance. Every sentence adds value with zero waste.

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, 100% schema coverage, and the presence of an output schema (implied by 'Returns a list of UserAction objects'), the description is complete enough. It covers purpose, parameters, return values, and usage guidelines without needing to duplicate schema information.

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. The description adds minimal value beyond the schema: it provides the same filter mapping as the schema and repeats the offset explanation. Baseline 3 is appropriate when 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 clearly states the tool's purpose with a specific verb ('fetch') and resource ('user's activity feed'), and distinguishes it from siblings by mentioning it's for 'detailed activity analysis beyond just replies' and contrasting with 'get_user_replies' and 'get_user_topics' as simpler alternatives.

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 explicit guidance on when to use this tool vs. alternatives: 'Use this for detailed activity analysis beyond just replies. For most cases, get_user_replies or get_user_topics are simpler.' This clearly defines the context and names specific sibling tools as simpler alternatives.

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?

With no annotations provided, the description carries the full burden. It discloses that this is a read operation ('Fetch'), describes the return structure, and explains the significance of badges. However, it lacks details on error conditions, rate limits, authentication needs, or pagination 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 well-structured with clear sections (purpose, args, returns, badge significance, usage), but includes some redundancy (repeating parameter descriptions already in schema) and could be more front-loaded by moving the usage guidance earlier.

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, 100% schema coverage, and the presence of an output schema (implied by 'Returns a UserBadges object'), the description is mostly complete. It explains the purpose, parameters, return structure, and usage context, though it could benefit from more behavioral details like error handling.

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 both parameters. The description repeats the parameter descriptions verbatim without adding additional meaning, syntax, or format details beyond what the schema provides, 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 specific action ('Fetch badges earned by a user') and resource ('badges'), distinguishing it from sibling tools like 'get_user_summary' or 'list_users_with_badge' by focusing specifically on badge retrieval for a given user.

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 ('Use to assess user experience and trustworthiness'), but does not explicitly mention when not to use it or name specific alternatives among the sibling tools (e.g., 'get_user_summary' might overlap).

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the core behavior (fetching followers with pagination) and return format, but lacks details on permissions, rate limits, error conditions, or whether data is cached. The mention of pagination is helpful but incomplete without explaining page size or total pages.

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 well-structured with clear sections for purpose, arguments, and returns, but includes an unnecessary editorial comment ('A high follower count often indicates...') that doesn't help tool selection. The core information is front-loaded and generally 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 the tool's moderate complexity (2 parameters, pagination), no annotations, but with a detailed output schema (implied by the Returns section), the description is reasonably complete. It covers the basic operation and return structure, though it could better address behavioral aspects like authentication needs or error handling.

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 both parameters. The description repeats the parameter explanations verbatim from the schema ('username: The user's handle', 'page: Page number for pagination') without adding any additional semantic context, such as username format constraints or pagination defaults.

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 specific action ('Fetch the list') and resource ('users following a specific user'), distinguishing it from sibling tools like get_user_following (which fetches users being followed) and get_user_summary (which provides broader user data). The verb 'fetch' precisely indicates a retrieval operation.

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 like get_user_summary (which might include follower count) or get_user_following (which retrieves the inverse relationship). It also doesn't mention prerequisites such as authentication or rate limits, leaving usage context unclear.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns a FollowList object with users and total_count, and mentions pagination via the 'page' parameter. However, it doesn't cover important behavioral aspects like rate limits, authentication requirements, error conditions, or whether it's a read-only operation (though 'fetch' implies reading).

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 well-structured with clear sections (purpose, args, returns, use cases), front-loaded with the core purpose. Every sentence earns its place—no wasted words. It's appropriately sized for a tool with two parameters and clear functionality.

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 an output schema exists (implied by 'Returns a FollowList object'), the description doesn't need to explain return values in detail. It covers the purpose, parameters, and usage context adequately. However, as a read operation with no annotations, it could benefit from more behavioral transparency (e.g., auth needs, rate limits) to be fully complete.

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

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

Schema description coverage is 100%, so the schema already documents both parameters fully. The description repeats the parameter info in the 'Args:' section but adds no additional meaning beyond what's in the schema (e.g., no examples, format details, or constraints). Baseline 3 is appropriate when 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 clearly states the specific action ('Fetch the list of users') and resource ('that a user follows'), distinguishing it from sibling tools like get_user_followers (which fetches followers rather than following). The verb 'fetch' is precise and the scope 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 'Use to:' section provides clear context for when to use this tool (e.g., 'Discover influential users', 'Find related experts'), but it doesn't explicitly state when not to use it or name alternatives (like get_user_followers for the reverse relationship). The guidance is helpful but lacks 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?

No annotations are provided, so the description carries full burden. It mentions pagination ('offset: Pagination offset') and return type ('Returns a UserReactions object'), but lacks critical behavioral details: authentication requirements, rate limits, whether it's read-only (implied but not stated), error conditions, or what happens with invalid usernames. For a tool with no annotation coverage, this is a significant gap.

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

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

The description is well-structured and appropriately sized: purpose statement, parameter documentation, return value, and usage context in four concise sentences. It's front-loaded with the core functionality. Minor redundancy in parameter descriptions slightly reduces efficiency, but overall it's economical.

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 an output schema exists (implied by 'Returns a UserReactions object'), the description doesn't need to detail return values. With 100% schema coverage and clear purpose, it's mostly complete for a read operation. However, the lack of behavioral transparency (auth, errors, limits) for a tool with no annotations prevents a perfect score.

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 both parameters thoroughly. The description adds minimal value beyond the schema: it repeats the parameter descriptions almost verbatim ('username: The user's handle', 'offset: Pagination offset') and doesn't provide additional context about username format, offset units, or pagination behavior. Baseline 3 is appropriate when 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 clearly states the tool's purpose: 'Fetch a user's post reactions (likes, etc.)' - a specific verb ('fetch') and resource ('user's post reactions'). It distinguishes from siblings like 'get_user_badges' or 'get_user_summary' by focusing specifically on reactions, though it doesn't explicitly contrast with similar tools like 'get_user_actions' which might overlap.

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 some usage context: 'Use to see what content a user has reacted to, which can indicate their interests and values.' This implies when to use it (for interest/value analysis), but doesn't explicitly state when NOT to use it or mention alternatives like 'get_user_actions' or 'get_user_summary' that might provide related information. The guidance is helpful but incomplete.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by explaining the pagination behavior ('Paginate with offset in increments of 30') and the return format (list of UserAction objects with specific fields). However, it doesn't mention rate limits, authentication requirements, error conditions, or whether this is a read-only operation (though 'fetch' implies reading).

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 well-structured and appropriately sized. It begins with the core purpose, then provides parameter details, return format, usage guidelines, and pagination instructions. Every sentence earns its place, with no redundant information. The bullet points make the usage guidelines easily 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?

Given the tool's moderate complexity, 100% schema coverage, and the presence of an output schema (implied by the detailed return format description), the description is complete enough. It explains what the tool does, how to use it, what it returns, and how to paginate. The output schema information in the description compensates for any lack of formal output schema documentation.

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 both parameters fully. The description adds value by explaining the pagination pattern ('increments of 30') and providing context about what 'username' represents ('user's handle'), though this is somewhat redundant with the schema. The description doesn't add syntax or format details beyond what the schema provides, but the pagination guidance is helpful.

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 purpose with specific verb ('fetch') and resource ('replies/posts made by a user in other topics'), distinguishing it from sibling tools like get_user_topics (which likely shows topics created by the user) and get_user_actions (which might include broader activity). The description explicitly mentions it's for contributions 'across topics' rather than within a single topic.

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 usage context with three bullet points explaining when to use this tool ('See a user's contributions across topics', 'Find their data points and experiences', 'Evaluate the quality of their participation'). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, though the context implies it's for cross-topic replies rather than topic-specific or other user actions.

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?

With no annotations provided, the description carries full burden and does well by explaining what the tool returns (UserSummary object structure) and its behavioral characteristics (provides quick overview, case-insensitive username handling). It doesn't mention rate limits, authentication requirements, or error conditions, keeping it from a perfect score.

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?

Well-structured with clear sections (Args, Returns, Use cases) and efficient sentences. Slightly verbose with the detailed return structure listing that could be inferred from output schema, but overall earns its place with helpful guidance.

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

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

Given the tool has an output schema (though not shown here, context signals indicate it exists), the description provides excellent contextual completeness by explaining the tool's purpose, usage scenarios, and behavioral characteristics without needing to duplicate return value documentation.

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 the parameter already documented in the schema. The description repeats the parameter documentation verbatim ('username: The user's handle (case-insensitive)') without adding meaningful semantic context beyond what's in the schema, meeting the baseline for high schema coverage.

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

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

The description clearly states the tool's purpose with specific verb ('Fetch') and resource ('comprehensive summary of a user's profile'), distinguishing it from siblings like get_user_badges or get_user_topics by emphasizing it provides a holistic overview rather than specific components.

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

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

The description explicitly states when to use this tool ('Use this to: Evaluate a user's credibility... Find their most valuable contributions... Understand their participation level') and when not to use it ('without fetching individual post histories'), providing clear alternatives to more granular sibling tools.

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

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

With no annotations provided, the description carries full burden and does well by explaining the return format (list of topic objects with specific fields) and pagination behavior. It doesn't mention rate limits, authentication needs, or error conditions, but covers core behavioral aspects adequately.

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?

Well-structured with clear sections: purpose statement, args explanation, return format, and use cases. Every sentence adds value with zero waste. The information is front-loaded with the core purpose stated first.

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 query tool with 100% schema coverage and an output schema (implied by 'Returns a list of topic objects'), the description provides complete context. It explains purpose, usage, parameters, return format, and practical applications without gaps.

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 both parameters fully. The description repeats the parameter explanations but doesn't add meaningful semantic context beyond what's in the schema. Baseline 3 is appropriate when 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 clearly states the verb 'fetch' and resource 'topics created by a specific user', distinguishing it from siblings like get_user_replies or get_user_summary. It specifies that it retrieves user-initiated discussions rather than replies or other user 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 description provides explicit use cases ('See what discussions a user has initiated', 'Find expert users', 'Research interests') and distinguishes from alternatives by focusing on user-created topics only. It also explains pagination usage clearly.

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?

With no annotations provided, the description carries the full burden. It discloses that the tool returns a dictionary with user badge information and mentions pagination via the offset parameter, which adds useful behavioral context. However, it doesn't cover important aspects like rate limits, authentication requirements, error conditions, or the structure of the returned dictionary beyond the high-level mention.

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 well-structured with purpose statement, parameter explanations, return information, and usage context in four concise sentences. Each sentence adds value, though the parameter explanations slightly duplicate schema information. It's appropriately sized for a tool with two parameters.

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

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

Given that there's an output schema (though not shown in the prompt), the description doesn't need to explain return values in detail. With no annotations, 100% schema coverage, and a clear purpose, the description provides adequate context for this read-only listing tool. The main gap is lack of behavioral details like authentication or error handling, but the core functionality is well-covered.

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 both parameters. The description repeats the parameter information from the schema ('badge_id: The numeric badge ID', 'offset: Pagination offset') without adding meaningful semantic context beyond what's in the structured fields. This meets the baseline for high schema coverage.

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

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

The description clearly states the specific action ('List all users who have earned a specific badge') and the resource ('users with badge'), distinguishing it from sibling tools like get_user_badges (which gets badges for a user) or get_user_summary (which provides general user info). The purpose is 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 clear context for when to use this tool ('Use to find community members with specific achievements or recognition levels'), which helps differentiate it from general user listing tools. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the siblings, though the purpose naturally implies alternatives like get_user_badges for different queries.

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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the session remains authenticated for subsequent calls, credentials are used only for this session and not persisted, and it explains the return structure (LoginResult) with specific fields. This covers authentication persistence, security handling, and response format.

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 well-structured with clear sections (purpose, args, usage guidelines, returns, behavioral notes) and appropriately sized. While efficient, the repetition of parameter details in the 'Args' section adds some redundancy since the schema already covers them, preventing a perfect score.

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

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

Given that this is an authentication tool with no annotations but with a detailed output schema (implied by the Returns section), the description provides complete context. It covers purpose, usage guidelines, parameters, return values, session behavior, and security considerations, making it fully adequate for the tool's complexity.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description repeats parameter information in the 'Args' section but adds minimal additional semantic context beyond what's in the schema. The baseline score of 3 is appropriate when 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 clearly states the specific action ('Authenticate with USCardForum credentials') and distinguishes this tool from siblings by explicitly mentioning it's for authentication while most read operations work without it. The verb 'authenticate' is precise and the resource 'USCardForum credentials' 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 provides explicit guidance on when to use this tool ('if you need authenticated features like: Reading notifications, Bookmarking posts, Subscribing to topics') and when not to use it ('Most read operations work without authentication'). It also implicitly suggests alternatives by listing specific authenticated features that would require 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?

With no annotations provided, the description carries the full burden and excels by disclosing key behavioral traits: it explains pagination behavior ('If more results exist, increment page parameter'), details the return format (SearchResult object with nested lists and metadata), and mentions default values (e.g., order defaults to 'relevance'). This goes beyond basic functionality to guide usage effectively.

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 well-structured and front-loaded, starting with the core purpose, followed by organized sections for args, returns, examples, and pagination. Every sentence earns its place by providing essential information without redundancy, making it efficient and easy to parse.

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

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

Given the tool's complexity (3 parameters, no annotations, but with an output schema), the description is complete: it covers purpose, usage, parameters, returns, examples, and behavioral details like pagination. The output schema handles return values, so the description appropriately focuses on operational guidance without redundancy.

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?

Despite 100% schema description coverage, the description adds significant value by elaborating on parameter semantics: it provides detailed examples of query operators (e.g., 'in:title', '@username'), explains page numbering ('starts at 1'), and lists all order options with clarifications like 'relevance' as default. This enhances understanding beyond the schema's brief 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 USCardForum for topics and posts matching a query, using specific verbs ('search') and resources ('topics and posts'). It distinguishes from siblings like get_top_topics or get_new_topics by emphasizing query-based matching rather than retrieving predefined lists.

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 (searching with queries) and includes example queries that illustrate use cases. However, it does not explicitly state when not to use it or name specific alternatives among siblings, such as get_hot_topics for trending content without queries.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes authentication requirements ('REQUIRES AUTHENTICATION'), the mutation nature of setting notification levels, and the return structure. However, it doesn't mention potential side effects like rate limits or error conditions.

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 well-structured with clear sections (purpose, args, prerequisites, returns, use cases). Every sentence adds value without redundancy. It's front-loaded with the core purpose and efficiently organized for quick comprehension.

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 (2 parameters, mutation operation) and the presence of an output schema (returns SubscriptionResult), the description provides complete context. It covers authentication needs, parameter semantics, return values, and practical use cases, leaving no significant gaps for the agent.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the semantic meaning of each level value with clear examples (0=muted, 1=normal, etc.), which goes beyond the schema's basic enumeration. It also clarifies that topic_id is required and level has a default of 2.

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 starts with a specific verb ('Set') and resource ('notification level for a topic'), clearly stating what the tool does. It distinguishes from siblings like get_topic_info or get_topic_posts by focusing on subscription management rather than information 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?

The description explicitly states 'Must call login() first' for authentication prerequisites and provides clear use cases with specific level values (e.g., 'Watch topics for all updates (level=3)', 'Mute noisy topics (level=0)'). It distinguishes when to use this tool versus alternatives by focusing on subscription actions.

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