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

With no annotations and no output schema, the description carries the full burden and handles it well. It discloses that the response is a cached snapshot dated by generated_at, that routes are mutually exclusive, that empty routes mean no_work, and that public counts do not imply personal eligibility; these are behavioral traits an agent cannot infer from the empty input 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?

The content is dense but front-loaded with the core purpose and route list before the caveats. Every sentence contributes domain-critical details, though the paragraph is long and relies on specialized jargon such as section_meta and held-only seconding, so it is not maximally scannable.

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

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

For a parameterless public feed with no output schema, the description is complete: it defines the routes, explains the section_meta and generated_at fields, covers the no_work case, warns about eligibility, and points to get_ballots for formal ballots. An agent has enough context to correctly interpret and invoke the 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 tool has zero parameters, so the description has no parameter semantics to add; the schema already covers this fully. The prose instead explains output semantics, which is the relevant information here, so the baseline of 4 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 opens with 'The canonical open-work feed' and enumerates the seven primary routes each public proposal can take, making the resource and scope immediately clear. It also distinguishes itself from get_ballots, the most confusable sibling, by noting that absence of primary voting work does not imply absence of formal ballots.

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

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

It gives clear usage context: this is the canonical open-work feed and should be used for primary-route work. It explicitly routes formal-ballot queries to get_ballots, but it does not broadly contrast itself with sibling tools like get_author_work_notices or own-eligibility tools, relying instead on the caveat that public counts do not establish personal eligibility.

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