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

Annotations already declare readOnlyHint=true, idempotentHint=true, so the core safety is covered. The description adds valuable behavioral context: it never invents facts not in events, never auto-posts (human publish rail), and speaks in a board-style summary first. These are beyond the annotations and align with them; no contradiction.

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 description is concise, with the key purpose and constraints front-loaded. The opening phrase 'Marketing-by-construction:' is a bit jargon-y but efficient. The rest is tightly packed without redundancy, though the 'speak speak_first / board-style summary first' phrasing is slightly awkward.

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?

Given the tool's moderate complexity (3 optional params, no output schema), the description provides key behavioral constraints (no invention, no auto-post) and usage triggers. It doesn't explain what a 'content atom' is or detail the exact output format, but that may be inherently implied by the domain. The lack of output schema is somewhat mitigated by the description of the factories.

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 schema fully documents all three parameters (hours, companyId, max_atoms). The description adds no additional meaning about these parameters, so a baseline of 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?

The description clearly states the tool packs recent CoS telemetry into content atoms, specifying the factories (Proof/Story/Take · Wisdom/Proof). It distinguishes from sibling tools like propose_talk_seeds or promote_corpus_to_content by focusing on atom generation from telemetry, though it doesn't explicitly name those alternatives.

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?

The description gives explicit when-to-use context: after a dogfood call or when the user asks about making posts from CoS work. It mentions never auto-posting and never inventing facts, which implicitly sets boundaries, but it doesn't explicitly name alternative tools or say when NOT to use it.

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