publish_draftPublish a draft post immediately or schedule it for later.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Draft post ID | |
| timezone | No | IANA timezone | UTC |
| scheduledAt | No | Schedule time (ISO 8601). Omit to publish now |
| Name | Required | Description | Default |
|---|---|---|---|
| result | No | The published or scheduled post record with its updated status as returned by the AdaptlyPost API. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only, not destructive, and open-world, so the basic mutation profile is clear. The description adds the immediate-vs-scheduled distinction but does not disclose additional behavioral context such as external side effects, irreversibility of publishing, or validation rules around scheduledAt.
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?
One concise sentence with no filler. It front-loads the core action and includes the key behavioral distinction. Every word earns its place.
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 output schema and annotations cover return values and the basic safety profile. Still, the description does not address scheduling edge cases such as requiring a future scheduledAt or how timezone is applied, and it does not mention when to prefer bulk_schedule_posts. For a mutating external-world tool, a bit more context would be expected.
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%, so the parameters are already fully documented. The description adds no new parameter-level meaning beyond what the schema provides, making the baseline 3 appropriate.
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 states a specific verb ('publish'), a specific resource ('draft post'), and the two modes: immediate or scheduled. The word 'draft' differentiates it from siblings like create_post and update_post, making the operation unambiguous even without naming an alternative.
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 implies the tool should be used when you have an existing draft and want to publish it, whether now or later. However, it gives no explicit guidance on when to choose this over bulk_schedule_posts or how it relates to update_post and create_post.
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.
Most tools are clearly separated by resource and action, but get_post and list_post_results both expose per-platform publishing status/errors, which could cause misselection. create_post and bulk_schedule_posts are closely related, though the descriptions make the single-vs-bulk distinction clear.
All tools follow a consistent verb_noun pattern: create_post, list_posts, upload_media, retry_failed_platforms, etc. Even multi-word actions like bulk_schedule_posts preserve the same style, making the naming predictable and easy to navigate.
With 12 tools, the set is well-scoped for a social media scheduling server. It covers post lifecycle management, bulk operations, media handling, account discovery, and retries without feeling bloated or sparse.
The tool surface covers the full publishing workflow: account listing, media upload, post creation, scheduling, listing, retrieval, updating, deletion, draft publishing, retry, and per-platform result inspection. Limitations like not updating published posts reflect expected platform constraints rather than missing server functionality.