build_content_calendar

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

No annotations provided, so description must fully disclose behavior. It outlines rules like pillar-first assignment and weekly shape but fails to explain side effects (e.g., does it save or return data?), authentication needs, or output format.

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?

Two sentences with no filler. The first sentence packs dense jargon, but the second provides clear usage. Could be slightly restructured for readability, but overall efficient.

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?

Missing critical details: what does 'build' entail? Is it a generation, plan output, or database update? No output schema, no annotations, and rules are mentioned without explaining how they apply. Incomplete for a tool with no other structured info.

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?

Input schema has no parameters, so baseline is 4. Description adds valuable context about the calendar's internal rules (e.g., weekly shape, batch-by-task rule), which helps infer the tool's logic without parameters.

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?

Description mentions 'content-calendar system' and 'use to plan a week/month', clearly indicating the tool builds a calendar. It distinguishes from sibling 'get_*' tools but could be more explicit with the verb 'build'.

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?

States to use for planning a week/month for an account, providing basic usage context. However, no explicit when-not-to-use or alternatives are given, leaving guidance incomplete.

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