schedule_draftSchedule a podcast draft for automatic release at a specified ISO 8601 date and time, enabling planned publishing without manual dashboard actions.
Schedule a draft for release.
| Name | Required | Description | Default |
|---|---|---|---|
| at | Yes | ISO 8601 formatted datetime string (e.g., "2024-01-01T12:00:00Z"). | |
| draft_id | Yes | target draft identifier. |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, yet it discloses nothing about side effects: whether the draft auto-publishes at the given time, what permissions are required, whether scheduling an already-scheduled draft overwrites or errors, or whether the time must be in the future. For a mutation tool this is a substantial 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?
A single front-loaded sentence with no filler, which is efficient. Its brevity reflects under-specification more than careful economy, but on this dimension alone it is well-formed.
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?
Although an output schema exists and parameters are fully documented, the description leaves the core behavior of a scheduling mutation unexplained (auto-publish semantics, preconditions, interaction with prepublish_draft). An agent could invoke it but could not predict its consequences.
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 description coverage is 100% — both draft_id and the ISO 8601 format of `at` are documented in the schema — so the baseline of 3 applies. The description adds no meaning beyond it, notably omitting whether `at` must be in the future or which timezone assumptions apply.
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 verb-and-resource pair ("schedule" + "draft") is identifiable, but "for release" is ambiguous — it does not say whether this queues automatic publishing, marks a prepublish date, or merely records intent. It also does not distinguish itself from close siblings such as publish_draft, prepublish_draft, and unschedule_draft.
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?
No guidance on when to schedule rather than publish_draft or prepublish_draft, and no mention of unschedule_draft as the inverse operation. An agent must infer the workflow entirely from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.