feed_list

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds non-obvious behavior: it does not trigger a fetch (archivist polls on schedule) and is scoped to 'visible to you.' This adds value 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?

Concise and well-structured: a one-sentence purpose, a usage sentence, a behavioral note, and a brief Args block. Every sentence serves a purpose, though the Args section duplicates schema info slightly.

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?

There is an output schema (not shown), and the description mentions the kind of metadata returned (poll interval, last fetch timestamp). With one optional filter and a read-only operation, the description covers what an agent needs 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?

The only parameter, project, is fully documented in the schema ('Filter by project. Omit to list all accessible feeds.') and the description repeats that in the Args section without adding new meaning. Schema coverage is 100%, so baseline 3 is appropriate.

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

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

Clearly states the action (list), the resource (active RSS/Atom feed subscriptions), and scope (visible to you). Also specifies two concrete use cases (check for duplicates, find feed_id for unsubscribe), which distinguishes it from feed_subscribe and feed_unsubscribe.

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

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

Explicitly tells the agent when to use this tool: before subscribing to check duplicates, or to find a feed_id for feed_unsubscribe. Also clarifies it does not trigger a fetch. However, it doesn't explicitly mention alternatives or when NOT to use it, though the sibling names make the contrast implicit.

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