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

Annotations already flag this as non-read-only and open-world, so the description focuses on what matters: that runs take about a minute and that the results should be surfaced to the user in full. It does not say whether the key points are persisted or what happens on regeneration, which is the main remaining gap.

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?

Sentences are front-loaded with the core action, then source requirements, then timing and output handling. Slightly longer than strictly necessary but every sentence carries operational information.

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 full schema coverage and no output schema, the description covers source resolution, grounding, latency, and output handling. Only persistence/return structure is left implicit, which is minor for this tool shape.

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%, so the baseline is 3, but the description adds real value by clarifying that url and draftId are alternatives and by instructing the agent to resolve a missing source with the user rather than guessing.

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?

States a specific verb and resource ('writes the key points of one piece of content') and defines what key points are (short quotable statements grounded in content, Brand Truth, and guidelines), which distinguishes it from sibling generators like create_faqs or create_content_brief.

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 requires a source and names both acceptable forms (draftId from create_draft/list_drafts, or a page URL), plus a concrete fallback: ask the user which draft or page if neither was given. This removes nearly all selection ambiguity.

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