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

The description adds extensive behavioral context beyond the sparse annotations: asynchronous execution, immediate return, ~1 minute delay before appearing, failure on duplicate keywords, 90 pending article cap with skipped_over_limit_count reporting, 30 calls/hour rate limit, free scheduling but credit consumption, and subscription/trial requirement. This is rich, non-redundant disclosure.

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 a dense but well-ordered set of sentences, each earning its place: core action first, then async behavior, failure mode, capacity, rate limit, cost, auth, and parameter condition. No fluff or repetition.

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?

The description covers most operational aspects an agent needs: async behavior, failure conditions, capacity, limits, cost, auth, and parameter guidance. The output schema exists, so return values need not be explained. Minor ambiguity remains about whether a duplicate keyword fails the entire call or just the offending keyword, but overall the description is quite complete for a complex 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?

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by clarifying that each keyword_id results in one article, and by providing the conditional rule 'Pass website_id when the account has several websites' with a cross-reference to get_account. This enhances parameter understanding beyond the raw schema descriptions.

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's function with a specific verb+resource: 'Queues one article per keyword in the content calendar.' It is distinguishable from siblings through the explicit 'one article per keyword' wording, though it doesn't name the singular alternative schedule_article, so it lacks explicit sibling differentiation.

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 provides clear context for when to use the tool, such as passing website_id for accounts with several websites and the failure on duplicate keywords. It lacks explicit guidance on when to choose this over the singular schedule_article tool, but the operational constraints and conditional instructions are well covered.

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