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

Annotations already flag destructiveHint=true, idempotentHint=false and openWorldHint=true, and the description adds real context beyond them: regeneration overwrites the existing output file including files already pulled by channels, and API feeds may auto-submit after export. It also discloses the async queue behavior and the 'queued' vs 'done' status values, which annotations cannot express. Nothing here contradicts 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?

Purpose is front-loaded and every sentence carries operational content, including the return shape. A few clauses are packed into long parenthetical sentences (the export-queue aside), making it denser than it needs to be, but nothing is 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?

With no output schema, the description usefully spells out the return object and the status lifecycle, and it covers the full call-and-poll workflow, so an agent can execute it correctly. Residual gaps are the meaning of project_id and any concurrency or permission prerequisites for re-exporting a feed that is already generating.

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 0%, so the description must carry parameter meaning. It explains feed_id's provenance and that project_id is optional, which is genuinely useful, but never says what project_id scopes or what happens if it is omitted while the feed belongs to a different project.

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 first sentence gives a specific verb+resource: trigger a (re)generation of the feed file, which clearly separates it from read-side siblings like get_feed_output and get_feed_status. It does not explicitly contrast itself with submit_feed or pause_feed/resume_feed, so an agent must infer the boundary rather than being told it.

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 states the trigger condition (after saving feed changes), the required follow-up (poll get_feed_status until 'generated'), where feed_id comes from (list_feeds / create_feed), that project_id is optional, and an explicit pre-flight instruction to confirm the destructive effect with the user. When-to-use, sequencing, and alternatives are all covered.

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