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

Annotations already mark destructiveHint=true and idempotentHint=true, but the description adds significant behavioral detail beyond that: it explains that deleting a category moves feeds to the default category without losing articles, that labels are detached from articles, that FreshRSS prioritizes categories, and that a two-step confirmation token process is required. This goes well beyond the structured metadata and provides critical 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 compact and well-structured, front-loading the primary purpose, then the behavioral details, and finally the two-step mechanism. Every sentence adds necessary information without redundancy or fluff. It is easy to parse and directly 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?

The description covers all essential aspects for correct invocation: what is deleted, consequences for feeds/articles, the naming ambiguity, and the confirmation flow. Since an output schema exists, return values are already documented. There is no missing information that would prevent an agent from calling 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?

Both parameters have descriptions in the schema (100% coverage), so the schema already explains what 'name' and 'confirm_token' mean. The description adds no extra parameter-level semantics beyond restating that the name must match list_categories and that the token comes from the first call, both of which are already in the schema. Thus, a baseline score 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 clearly states the action (deletes a category or label), specifies the exact effects on feeds and articles, and distinguishes between the two entity types. It also explains the two-step process, which is essential for correct usage. This clearly differentiates it from siblings like rename_category_or_label and unsubscribe_feed.

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 about when to use the tool (to delete a category or label) and the two-step flow. However, it does not explicitly name alternatives or state conditions for when not to use it. The caution about categories and labels sharing names is a useful guideline, but no direct comparison with sibling tools is given, so a 4 is appropriate.

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. The description adds value by specifying that ALL subscriptions are exported (scope) and that the output is a portable OPML document, which is beyond what annotations provide. 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?

Two sentences with no redundancy. The first states the core purpose and format, the second provides a routing alternative. Both sentences earn their 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 the tool has no parameters, an output schema exists (so return format is covered), and annotations cover safety/idempotency, the description is complete. It even includes a helpful sibling alternative. Nothing essential is missing for an agent to call this 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?

The tool has zero parameters, so the description does not need to explain them. The schema coverage is 100% (empty schema), and the baseline for no parameters is 4. The description does not add parameter details because none are needed.

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

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

The description clearly states the action ('Exports'), the resource ('all subscriptions'), and the output format ('OPML document'). It also explicitly differentiates from the sibling tool list_feeds by mentioning that list_feeds provides a readable overview, making the tool's distinct 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 a clear alternative ('For a readable overview of the subscriptions use list_feeds instead') and implies a backup/portability use case via 'portable backup format.' While it doesn't explicitly state when NOT to use the tool beyond the alternative, the context is sufficient for an agent to choose correctly.

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 the constraint of at most 20 IDs per call and clarifies the output is plain text, which provides useful behavioral context beyond the annotations.

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

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

The description is a single, tightly-worded sentence that front-loads the core purpose and includes the key constraint. Every word contributes to clarity, with no filler or repetition of schema details beyond the essential limit.

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

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

The tool is simple, read-only, and idempotent, with a complete output schema and full annotation coverage. The description covers the essential facts: fetching by ID, plain text format, and the ID limit. No additional behavioral details (pagination, errors, etc.) are necessary for an agent to call this 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 both parameters (article_ids and max_content_chars) are already well documented in the schema. The description adds no new parameter semantics beyond repeating the 20-ID limit, which is already in the schema (maxItems: 20). It does not clarify the format of max_content_chars or how the default is applied.

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 (fetches), the resource (articles), and the specific selection criteria (by id). It also specifies the output format (plain text), which distinguishes it from list_articles and list_article_ids that likely return metadata or IDs. 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 alternatives like list_articles. It implies that you need article IDs first (from list_articles, as noted in the schema), but this is not stated in the description itself. There is no guidance on when not to use it or which sibling to choose instead.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds behavioral details: sorting by count and filtering to only entries with unread articles. This goes beyond annotations and provides useful context 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 two concise sentences with no redundancy. It front-loads the core purpose and then adds the sorting and filtering details. 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, zero-parameter count tool with an output schema, the description is fully complete. It explains what is returned (counts, totals, per-feed, per-category) and the ordering/filtering. Nothing an agent needs to call it correctly is missing.

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

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

The tool has zero parameters, and schema coverage is 100% (trivially, since there are no parameters). With 0 params, the baseline is 4 per the rubric. The description does not need to add parameter semantics as there are none.

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 unread article counts (total, per feed, per category) sorted by count, and only includes entries with unread articles. This is a specific verb+resource with distinct scope, easily differentiated from siblings like list_articles or mark_articles.

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 checking unread counts, and its read-only nature is clear. It does not explicitly name alternatives or exclusions, but the sibling context (e.g., mark_all_as_read, list_articles) makes it obvious when this tool is appropriate. Lacks explicit 'use when' guidance but is sufficiently clear.

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 indicate read-only, idempotent, non-destructive behavior. The description adds that it returns account info, which is consistent and sufficient; no additional side effects 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 two sentences, direct and free of unnecessary detail, 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?

With no parameters and a simple return value, the description provides enough context for an agent to use the tool effectively, even without an explicit output 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?

The tool has no parameters, and the empty schema is fully covered. There is nothing to explain, so the description is perfectly adequate.

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 the authenticated FreshRSS account, distinguishing it from sibling tools that handle feeds, articles, or 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?

It explicitly positions the tool as a connection and credential check to be used before other operations, providing clear when-to-use guidance.

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

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

Annotations already flag destructiveHint=true, but the description goes beyond by explaining the nature of the destructiveness (no bulk undo), the time cost (minutes on large files), and the two-step confirmation mechanism. This adds substantial behavioral context not present in 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 with no waste. It front-loads the core action, then adds cautions and the two-step procedure. Every sentence contributes essential information without 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 tool with an output schema and strong annotations, the description covers all critical aspects: the action, side effects (refreshing), performance implication, undo limitation, and the required two-step call pattern. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100% with clear parameter descriptions, so baseline is 3. The description adds meaning by explaining the confirm_token's role in the two-step process and clarifying that opml is processed to subscribe to every feed, enhancing the semantic 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 states a specific verb ('Subscribes to every feed') and resource (OPML document), and adds distinctive details (creating categories, refreshing all feeds, two-step process). It clearly distinguishes itself from siblings like subscribe_feed (single feed) and export_opml (export) without 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 gives a clear context: it's for bulk import via OPML, and it warns about the lack of bulk undo, implying caution. It does not explicitly reference alternatives, but the purpose is so specific that usage is obvious. The two-step instruction also guides the invocation sequence.

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 indicate readOnly, idempotent, and non-destructive behavior. The description adds useful context with 'cheap way' and 'only the ids', but does not mention pagination or continuation details, which are implied by 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 short sentences with the main point upfront. No filler or redundancy; the description is lean 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?

The tool is simple and an output schema exists, so return values need not be explained. The description covers the essential purpose and relationship to list_articles, though it could mention pagination via continuation for extra completeness.

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 descriptions cover all parameters at 100%, so parameters are well documented. The description adds little beyond 'Same selectors and filters as list_articles', which is helpful but not essential given the complete 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 'Lists', resource 'only the ids of matching articles', and scope. It also distinguishes itself from list_articles by emphasizing 'cheap way' and 'Same selectors and filters as list_articles', 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?

Provides direct guidance by mentioning 'cheap way to collect a set for mark_articles' and noting 'Same selectors and filters as list_articles'. However, it does not explicitly state when to prefer the full list_articles, leaving a small gap.

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

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

The annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral details such as returning short excerpts by default, default filter of unread, default stream of reading-list, and continuation handling. It does not contradict the annotations, but it could have explicitly stated that no changes are made to articles.

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, using three sentences to cover purpose, defaults, and limitations. Every sentence adds value, and it is well-structured without 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 complexity (12 optional parameters, multiple enums, pagination), the description is remarkably complete. It explains default behaviors, the trade-off between excerpts and full content, pagination via continuation, and the lack of full-text search. No important usage context is missing.

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

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

The schema has 100% coverage with descriptions for all 12 parameters. The description adds extra context for a few parameters (e.g., continuation for next page, include_content for full text) and clarifies relationships (e.g., max_content_chars applies to article text). It does not drastically augment the schema descriptions but provides some additional 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 action (lists articles), the resource (articles from feed, category, label, or built-in stream), and the default ordering (newest first). It also distinguishes itself from get_articles by noting that get_articles fetches single articles, helping the agent choose correctly.

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 mentions the lack of full-text search, advises using feed_id/category and since/until to narrow results, and suggests get_articles for single articles. This gives clear when-to-use guidance and points to 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context: it returns unread counts for each item and that names are used as identifiers in other tools. This goes beyond what annotations provide, so it earns a 4.

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 action and content; the second clarifies the naming significance. Information is front-loaded and every word adds 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?

For a read-only enumeration tool with an output schema (though not shown), the description adequately covers what the tool returns, the distinction between categories and labels, and how results are used elsewhere. There is nothing an agent needs to decide to call it correctly that is missing.

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

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

The tool has zero parameters, so schema coverage is 100% by definition. The baseline for 0 parameters is 4, and the description doesn't need to explain parameter semantics. It correctly focuses on the output and purpose instead.

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 lists categories and labels, clarifies what they are (folders vs. tags), and notes they come with unread counts. This distinguishes it from siblings like list_feeds (which lists feeds) and get_unread_counts (which likely aggregates unread counts differently). The verb 'lists' and specific resource ('categories and labels') make 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 by noting both are 'addressed by name in the other tools', indicating you should call this to get the names needed elsewhere. It doesn't explicitly mention alternatives or when not to use it, but the context of sibling tools makes the intended use clear. A brief explicit exclusion (e.g., 'not for listing feeds') would push it to 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?

The description does not contradict the readOnly and idempotent annotations, and it adds context about being a starting point, though it doesn't explicitly restate side-effect freedom.

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 convey all essential information without 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?

The description explains what is returned (feeds with category and unread count) and its role in the workflow, making it complete for a zero-parameter read-only 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?

There are no parameters, so this dimension is trivially satisfied. The description's mention of feedId as an output is helpful but not parameter-related.

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 lists every subscribed feed with its category and unread count, making 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?

It explicitly says to start here before listing articles and notes that the feedId is used by other tools, giving clear when-to-use guidance.

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

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

Annotations already indicate destructive and idempotent behavior; the description adds the irreversible nature and the confirm-token mechanism, making side effects clear.

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 cover purpose, action scope, confirmation requirement, and consequence without unnecessary detail.

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?

Provides sufficient context for a bulk mark-as-read operation, including token flow and irreversibility, though it does not elaborate on what the confirmation token payload looks like beyond 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?

All parameters are described with concrete details like exact source names, enum meanings, and default streams; however, interaction constraints between scope parameters are not spelled out.

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 tool marks every article as read across a feed, category, label, or built-in stream, and distinguishes this bulk action from other 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?

Explains the two-step confirmation flow and optional older_than filter, but does not explicitly mention mutual exclusivity of scope parameters or when to prefer this tool over sibling mark_articles.

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

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

The description goes well beyond the annotations by explaining real behavioral nuances: read changes are irreversible, starring/labelling are reversible, the tool always responds 'OK' regardless of whether ids were recognized, and confirmation requires get_unread_counts. This is exactly the kind of side-effect detail an agent needs.

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 dense but every sentence carries necessary operational guidance, and the most important action and constraints are front-loaded. No filler or redundant explanation is present.

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 output schema exists, the description covers the essential behavioral context: idempotency, destructive irreversibility, the confirmation token, the OK-response ambiguity, and the recommended follow-up via get_unread_counts. An agent has enough context to invoke this tool correctly and safely.

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

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

Although the schema already covers all parameters, the description adds critical semantics not present in the schema: unknown labels are created, confirm_token comes from the first call, and article_ids must use the short form returned by list_articles. These clarifications materially improve correct parameter usage.

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 ('Sets') and a specific resource ('read state, the star and user labels of specific articles'), making the tool's purpose unmistakable. It also distinguishes itself from related operations by noting the 100-article limit and pointing to get_unread_counts for confirmation.

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 explicit when-to-use guidance: marking individual articles, using exact ids from list_article_ids, and confirming with get_unread_counts when the outcome matters. It also explains the token flow for read=true, which is essential for correct invocation.

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 carry destructiveHint=true and idempotentHint=true. The description adds valuable context: the resolution order and that feeds/articles keep their assignment, which clarifies what is and is not affected. 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: the first states the action, the second explains the resolution behavior, and the third notes the side-effect. Every sentence adds value with no 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?

The tool is simple, has only 2 well-documented parameters, an output schema exists, and annotations cover safety and idempotency. The description covers behavior and side-effects, leaving nothing essential missing.

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

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

Schema coverage is 100% and both parameters are described with concrete details (e.g., 'exactly as in list_categories'). The description adds no new parameter-specific information beyond the schema, so the 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 clearly states the verb 'Renames' and the resource 'category (folder) or user label', and specifies the resolution order (categories first, then labels). This distinguishes it from sibling tools like delete_category_or_label and clarifies the single-tool coverage.

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 explains that one tool covers both categories and labels, implying it is the sole rename operation. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to decide 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?

The description discloses side effects: it creates a category if it does not exist, and it performs network operations that may be slow. This aligns with the annotations (readOnlyHint false, openWorldHint true, idempotentHint false) and does not contradict them. It does not mention all possible side effects but covers the key ones.

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, front-loading the main purpose and then providing necessary behavioral details. No fluff or repetition. It is well-structured 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?

The description sufficiently covers the purpose, input flexibility, side effects, and latency. It does not describe the return value, but an output schema is indicated, so that is not required. Overall, it gives enough context for an agent to decide when and how to use it.

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

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

The input schema already covers all three parameters (url, title, category) with descriptions. The description adds meaning to the 'category' parameter by explaining that a missing category is created. It does not add extra detail for 'url' or 'title' beyond the schema, but the coverage is complete.

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 primary purpose: 'Subscribes to a feed.' It also clarifies the input flexibility (URL may be a feed or website) and that a category is created if needed, which distinguishes it from read-only or management tools like list_feeds or update_feed.

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 provides practical guidance on when to use this tool: when you have a URL that might be a website or feed, and it warns that the call can take a while due to discovery and download. It does not explicitly contrast with sibling tools but the context is sufficient.

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 destructive nature (deletes feed and associated data), irreversibility ('cannot be undone'), and the two-step behavior, going beyond the annotations by specifying exactly what will be removed.

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 (three sentences) and front-loads the core action before explaining the two-step process and consequences. No unnecessary words or redundancies.

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?

It covers the essential context: what is deleted, how to confirm, and the irreversible outcome. Since the output schema exists and is not described, that omission is acceptable. The description leaves no critical gaps 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?

Both parameters (feed_id and confirm_token) are described with sources: 'Numeric feedId from list_feeds' and 'Token from the first call of this tool.' This fully clarifies their meaning and usage, achieving 100% 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 action ('Deletes a feed') and the scope ('together with all of its stored articles, read state and stars'), making it distinct from sibling operations like subscribe or update feed.

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 explains the two-step confirmation process explicitly: 'first call returns a confirmation token, the second call with that token performs the deletion.' This gives clear guidance on how to use the tool correctly.

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 annotations (destructive, idempotent), the description discloses important behaviors: automatic category creation and partial updates (fields not given remain unchanged), which are not captured elsewhere.

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 pack the main purpose and key behaviors. No fluff, well-structured, 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?

With an output schema present and annotations for idempotency/destructive effects, the description covers all necessary operational details (what it does, partial updates, category creation). Nothing essential is missing.

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

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

Schema descriptions already cover each parameter's meaning (title, feed_id, category). The description adds value by explaining that absent fields are left unchanged and that category creation happens automatically, enriching the parameter semantics.

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

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

The description clearly states the tool renames a feed and/or moves it to another category, which is specific and distinct from sibling tools like rename_category_or_label or subscribe_feed.

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 clearly describes the action but does not explicitly contrast with alternatives (e.g., rename_category_or_label for category renames). The purpose is so clear that guidance is implied rather than stated.

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