AdaptlyPost
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ADAPTLYPOST_API_TOKEN | Yes | Your AdaptlyPost API token from https://adaptlypost.com/api-tokens |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_accountsA | List the social accounts connected to the token's workspace across all nine platforms. Returns { accounts } with id, platform, displayName, username, avatarUrl, and pageId for Facebook pages. Call this before create_post, update_post, or bulk_schedule_posts: they take these ids, never usernames. Put each id in the array for its platform (linkedinConnectionIds, tiktokConnectionIds, and so on); Facebook page accounts go in pageIds. Not for post history or publishing status: use list_posts or list_post_results for those. Takes no arguments. |
| upload_mediaA | Upload images or videos to AdaptlyPost storage and return public URLs for the mediaUrls of create_post, update_post, or bulk_schedule_posts. Two sources, combinable in one call: urls (public URLs the server downloads and re-hosts) and files (base64 data, for media attached in the conversation). Omitting both returns an error. Accepts image/jpeg, image/png, image/webp, video/mp4, video/quicktime. Stored files are public immediately, post or no post. Prefer this over get_upload_urls, which only mints URLs and leaves the PUT to you. Returns uploaded ({ publicUrl, key } per file) and mediaUrls; pass mediaUrls straight into the post. |
| get_upload_urlsA | Get presigned upload URLs for direct file uploads. Returns uploadUrl (PUT your file here) and publicUrl (use in create_post mediaUrls). This only mints a URL — you MUST PUT the file to uploadUrl and confirm a 2xx response before using publicUrl, otherwise create_post/bulk rejects it with "Media file(s) not found in storage". Prefer the upload_media tool, which performs the upload for you. For each file, provide fileName and mimeType. Supported types: image/jpeg, image/png, image/webp, video/mp4, video/quicktime. |
| create_postA | Create one post for one or more platforms: publish now, schedule, or save a draft. Omit scheduledAt to publish immediately; a future scheduledAt sets status SCHEDULED; saveAsDraft stores it as DRAFT and defers validation to publish_draft. Publishing runs asynchronously per platform, so the response ({ postId, queuedPlatforms, isScheduled, scheduledAt }) is not the outcome; read list_post_results, where each platform succeeds or fails on its own. Call list_accounts first: each platform in platforms needs its connection-id array (linkedinConnectionIds, pageIds for Facebook, and so on), one account per platform. TikTok needs tiktokConfigs with privacyLevel; Pinterest needs pinterestConfigs with boardId. mediaUrls must come from upload_media, or the call fails with "Media file(s) not found in storage". Use bulk_schedule_posts for many posts on the same accounts, and update_post or publish_draft for an existing post. |
| get_postA | Get one post's full record by id: text, contentType, status, scheduledAt, timezone, and a platforms array with each target's connection, status, errorMessage, and media. Visible only within the token's workspace; any other id returns "Post not found or access denied". Use this to inspect content before update_post or publish_draft. Use list_post_results instead when you only need per-platform publishing outcomes and the platformIds for retry_failed_platforms, and list_posts to find ids by status, platform, or date. Post ids come from create_post, bulk_schedule_posts, or list_posts. |
| list_postsA | List posts in the token's workspace, any status, newest first by default. Returns { posts, total, hasMore }; each post carries its status and a platforms array with per-platform status. Filters: statuses, platforms (posts targeting any of them), and startDate/endDate, which bound scheduledAt, or createdAt for posts never scheduled. limit is 1 to 100 (default 20); page with offset while hasMore is true. Use this to find post ids or check what is already queued. Use get_post for one post's full record and list_post_results for one post's per-platform outcomes and retry ids. |
| update_postA | Update a DRAFT or SCHEDULED post in place; any other status fails with "Cannot edit post in current state", so published posts cannot be changed. Updates are partial: text, contentType, scheduledAt, timezone, and thumbnail fields you omit keep their values. The exception is platforms: sending it rebuilds the post's target set from this request alone, so include every connection-id array and platform config you want to keep (TikTok with privacyLevel, Pinterest with boardId); omitting platforms leaves accounts, configs, and media untouched. mediaUrls only take effect together with platforms; use publicUrl values from upload_media. On SCHEDULED posts new media is verified in storage. Returns the updated post record. Use publish_draft to change a draft's status, delete_post to cancel, and create_post for a new post. |
| delete_postA | Delete a post record from AdaptlyPost by id. Use it to cancel a DRAFT or SCHEDULED post before it goes out; a deleted scheduled post will not publish. Deleting never removes content already on a network: for a COMPLETED or PARTIAL_FAILURE post this only drops AdaptlyPost's record, and the live posts stay up until removed on each platform. Prefer update_post to change a post instead of deleting and recreating it. Only posts in the token's workspace can be deleted; others return "Post not found or access denied". Returns { deleted: true }. Irreversible. |
| publish_draftA | Publish a DRAFT post now or schedule it; SCHEDULED posts are accepted too, to reschedule or push live. Other statuses fail with "Post is not a draft". Without scheduledAt (or with a past one) the post moves to PENDING and a publishing job is queued per platform: content reaches the networks within moments and cannot be recalled. A future scheduledAt sets SCHEDULED and queues nothing yet. Fails if an account was disconnected or a TikTok entry lacks privacyLevel; fix with update_post first. Not for new content, use create_post. Check list_post_results afterwards for per-platform outcomes. |
| list_post_resultsA | Get one post's per-platform publishing outcomes: { postId, status, results[] } where each result has platformId, platform, accountName, status (PENDING, PUBLISHING, PUBLISHED, or FAILED), platformPostId, errorMessage, and publishedAt. Each platform reports separately, so read every row instead of treating the post as one pass or fail. Call this after create_post, publish_draft, or retry_failed_platforms, since publishing is asynchronous and their responses only confirm queueing; poll until no row is PENDING or PUBLISHING. Take platformId from FAILED rows for retry_failed_platforms. Use get_post when you also need the content and schedule. |
| retry_failed_platformsA | Re-queue publishing for a post's FAILED platforms. Only rows with status FAILED whose id is in platformIds are reset to PENDING and retried with the same content; other ids are ignored, and with none matching the call fails with "No failed platforms to retry". The post moves to PUBLISHING and the retry is asynchronous, so check list_post_results for the outcome. Get platformIds (not platform names) and each errorMessage from list_post_results first; retry once the cause is fixed (reconnected account, replaced media), not for a platform-side restriction, which will just fail again. Content cannot change on retry. |
| bulk_schedule_postsA | Schedule up to 100 posts in one call to the same platforms and accounts. Each item supplies its own text, contentType, scheduledAt, and optional media; platforms, connection-id arrays, timezone, and platform configs are shared by every item. Items are processed independently: each is validated and created like create_post, so one bad item fails alone while the rest are scheduled. Returns { totalScheduled, totalFailed, results[] } with a postId or errorMessage per item, in input order; read every row. An item with a past scheduledAt publishes immediately rather than being rejected. Call list_accounts first; TikTok needs tiktokConfigs with privacyLevel and Pinterest needs pinterestConfigs with boardId. Use create_post for a single post or a draft; this tool has no draft mode. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Each tool owns a distinct resource/action (accounts, media, posts, results, retries), and descriptions include cross-references to route to the right tool. The only mild overlap is upload_media vs get_upload_urls, since both can produce mediaUrls, but the descriptions clearly position one as the preferred path and the other as a lower-level alternative. create_post vs bulk_schedule_posts is also clearly differentiated by single vs batch.
All tools follow a consistent snake_case verb_noun pattern: list_accounts, upload_media, create_post, get_post, list_posts, update_post, delete_post, publish_draft, list_post_results, retry_failed_platforms, bulk_schedule_posts, get_upload_urls. There are no mixed naming conventions or vague verbs. Even the batch and URL tools fit the same predictable pattern.
12 tools is well within the ideal range for a social media posting and scheduling server. Each tool covers a necessary part of the workflow: account lookup, media handling, single/bulk post creation, read/update/delete, publishing, and result/retry management. None feel redundant enough to cut, even the two media tools serve different upload methods.
The post lifecycle is fully covered: create (single and bulk), read by ID or list, update, delete, draft publishing, scheduling, asynchronous result monitoring, and failed-platform retries. Media upload and account discovery are provided as prerequisites. There are no obvious dead-end operations that would prevent an agent from completing a standard posting workflow.