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

Annotations only cover the safety profile (readOnly=false, destructive=false, openWorld=true); the description adds the substantive behavior: the record is moved to a scheduled queue and will auto-publish without a second approval gate. That is real value beyond structured data, though error behavior for non-draft input and reversibility (can it be unscheduled?) are not disclosed.

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?

Three short sentences, front-loaded with the action and its effect, then the constraint. Slight redundancy between 'schedule it for publishing at a specific time' and the em-dash clause, but nothing is wasted.

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 an output schema present, return values need no explanation, and the description covers the action, the effect, and the eligibility precondition. Missing only edge-case handling (non-draft post, past timestamps) and whether the scheduling is undoable, which an agent might want before committing.

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 both parameters are already documented (post_id, and scheduled_time as a future ISO 8601 datetime). The description restates that publishing occurs at scheduled_time but adds no syntax, format, or constraint detail beyond the schema, so the baseline 3 applies.

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?

Names a specific verb and resource ('Approve a draft post') and states the resulting state transition ('promotes a draft to the scheduled queue'). This distinguishes it cleanly from create_post, update_post, and list_scheduled_posts, which do not perform a draft→scheduled approval.

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?

Gives a clear precondition — 'Only works on posts with status draft' — plus the consequence of use (publishes at scheduled_time with no further approval), which tells an agent when this is the right step. It stops short of naming alternatives (e.g., use update_post to edit the draft first) or saying what to do for non-draft posts.

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