sprkly_delete_scheduled_postRemove a post from the queue. This is a soft delete. The user can restore it from the Deleted tab for 30 days. Posts that have already published cannot be deleted this way. Always confirm with the user before calling.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | The scheduled post id to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint: true), the description reveals critical behavioral traits: this is a soft delete with a 30-day recovery window, restorable from the Deleted tab. This tells the agent the action is reversible and explains the irreversible boundary ('Posts that have already published cannot be deleted this way'). The confirmation requirement is an additional behavioral context that no annotation captures.
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?
Five concise sentences, each adding distinct value: purpose, delete type, recovery detail, limitation, and safety instruction. The text is front-loaded with the core action and contains zero fluff or redundant restatement of the title or annotations. Perfectly sized for the tool's complexity.
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?
For a simple tool with 1 parameter, no output schema, and rich metadata annotations, the description is complete: it covers the purpose, soft-delete behavior, recovery period, edge-case limitation (published posts), and safety requirement. Without an output schema specified, the description need not explain return values. Nothing material is missing.
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?
With schema description coverage at 100% (the single post_id parameter is fully documented in the schema) and only 1 parameter, the description doesn't need to add much parameter-level detail. The description does not elaborate on the id format or how to obtain it, but does reinforce the parameter's meaning by referencing 'a post' being removed from the queue. Baseline of 3 is appropriate since the schema already handles the heavy lifting.
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 opens with 'Remove a post from the queue', a direct verb+resource statement that clearly conveys the tool's purpose. The title 'Delete a scheduled post' and the description together unambiguously distinguish this from sibling tools like 'sprkly_update_scheduled_post' and 'sprkly_draft_post', leaving no ambiguity about what this tool does.
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 explicit usage guidance: it states when to use this tool ('Remove a post from the queue') and when not to ('Posts that have already published cannot be deleted this way'). Crucially, it includes a mandatory human-safety guardrail: 'Always confirm with the user before calling.' These exclusions and instructions go well beyond a generic usage note, offering clear when-to and when-not-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Every tool targets a distinct action and resource: media ingestion, draft creation, scheduling, deleting, updating, validation, approval, analytics, and account/profile listing. The only slight overlap is between sprkly_list_profiles and sprkly_list_scheduled_posts, but they serve clearly different purposes (target selection vs. queue view).
All 16 tools follow the exact sprkly_verb_noun pattern with lowercase snake_case. Verbs are consistent (add, delete, draft, get, list, request, schedule, update, validate) and nouns are clear (media, scheduled_post, account_summary, analytics, profiles, etc.). No style mixing or vague naming.
16 tools is slightly above the typical 3–15 sweet spot but each tool covers a distinct part of the content-scheduling lifecycle. The count feels justified given the breadth of features (media, drafts, scheduling, approvals, analytics), though a few tools could be merged (e.g., get_account_summary could be part of analytics) without much loss.
The surface covers the core workflows well: draft, schedule, update, delete, approve, validate, and analyze. Minor gaps exist—there's no explicit tool to list drafts or edit a draft after submission, and no direct way to unpublish or cancel an approval—but the domain is well-served for typical scheduling needs.