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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, yet the description adds substantial behavior the annotations cannot express: nothing is stored, the call is free, the 1.5 MB cap, the exact user agent string, one GET per call, and that robots.txt is not read. It also warns that feed titles and summaries are untrusted data rather than instructions, which is exactly the kind of safety context an agent needs before ingesting third-party content.

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

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

Front-loaded with what the tool returns, then constraints, then limits — dense and mostly waste-free. Minor deductions for the fragmentary opening sentence that duplicates the title and for the slightly clipped limit sentences, but no padding or repetition.

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

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

There is no output schema, and the description compensates fully by describing the return shape (feed title, up to 50 items with named fields, signed observation containing address, fingerprint, time). Combined with the size cap and fetch limits, an agent has everything needed to call it and interpret the result.

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

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

Schema coverage is 100% and there is only one parameter, so the baseline is 3; the description earns an extra point by constraining that URL meaningfully — public http(s) only, restricted to ports 80 and 443, 1.5 MB response cap. That narrows what values are valid beyond the schema's generic 'Public http(s) URL of an RSS or Atom feed.'

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

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

The description names a specific verb+resource ('Read an RSS or Atom feed') and goes further by enumerating what comes back: feed title, up to 50 items with title/link/date/200-char summary, plus a signed observation. The opening sentence is a fragment that largely restates the title, and no sibling (e.g. sitemap_read) is named for differentiation, which keeps it short of a 5.

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

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

Usage context is implied through hard constraints (public http(s) only, ports 80/443, 1.5 MB cap, one GET per call) rather than stated as when-to-use. There is no explicit routing to an alternative such as sitemap_read or list_clean, so an agent must infer which read tool fits.

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