Hosted MCP endpoint for AI agents to plan, adapt, review, schedule, and batch-publish social media content across connected channels.
Scored across 20 tools
Each tool has a clearly distinct purpose, with interactive UI tools (compose_post, view_*) explicitly differentiated from programmatic APIs (create_post, list_*). Potential overlaps like get_analytics vs view_analytics are well-described as raw data vs dashboard. The descriptions provide strong guidance for selection.
All tool names follow a consistent verb_noun pattern in snake_case (compose_post, list_channels, upload_media). Verbs are clear and each noun identifies the resource. No mixing of camelCase or arbitrary styles.
20 tools is slightly above the ideal 3-15 range but still reasonable for a social media management server covering posts, media, analytics, channels, and queue operations. The inclusion of many view_* interactive counterparts inflates the count but they serve a distinct UX purpose.
Core CRUD for posts (create, get, list, update, delete) plus publishing, retry, media upload/list, analytics, and channel views are covered. Minor gaps include no delete/update for media and no explicit approval tool, though publish_post and create/update handle approval behavior implicitly.
Open an interactive composer to draft or schedule a social media post. Shows the user's connected channels to pick from and pre-fills any provided text. The user finishes in the UI; on submit it creates the post via create_post. Use this when the user wants to compose a post interactively in a UI — prefer this over create_post when they'd review before posting.
| Name | Required | Description | Default |
|---|---|---|---|
| content | No | Optional initial text to pre-fill the composer with. |
| Name | Required | Description |
|---|---|---|
| media | No | |
| channels | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses an important side effect: 'on submit it creates the post via create_post.' However, this directly contradicts the annotation readOnlyHint: true. Because the description claims a write behavior while the annotations mark the tool read-only, this dimension scores 1 as an annotation contradiction.
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?
The description is short and front-loaded with the purpose and user flow. The final sentence repeats the idea of interactive UI/composing somewhat, but overall every sentence adds useful routing or behavior context with little waste.
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 one-optional-parameter tool with an output schema and low complexity, the description gives enough invocation context: it explains the interactive UI, channel selection, pre-fill behavior, and delegation to create_post. It could add more about scheduling-edge behavior, but the schema and output schema cover the rest.
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?
There is only one optional parameter, content, and the schema already describes it fully as 'Optional initial text to pre-fill the composer.' The description restates pre-filling in prose, but adds no format, length, or behavior details beyond the schema. With 100% schema coverage, the baseline 3 is 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 names a specific action ('Open an interactive composer') and resource ('social media post'), and clarifies the flow up to creating the post via create_post. It also distinguishes itself from the sibling create_post by being the interactive, review-first path.
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?
It gives explicit usage guidance: 'Use this when the user wants to compose a post interactively in a UI' and 'prefer this over create_post when they'd review before posting.' This directly tells an agent when to choose this tool over its closest sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reserve a presigned upload URL for a direct browser upload (used by the composer UI). For scripted uploads use upload_media instead. Use this when you need a presigned URL for a large direct upload (advanced; prefer upload_media for normal files).
| Name | Required | Description | Default |
|---|---|---|---|
| sizeBytes | Yes | File size in bytes. | |
| contentType | Yes | File MIME type, e.g. image/png or video/mp4. |
| Name | Required | Description |
|---|---|---|
| r2Key | No | |
| expiresIn | No | |
| uploadUrl | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only mark the tool as non-readonly/non-idempotent and don't describe the side effect. The description adds meaningful behavior: it reserves a URL rather than uploading bytes, and frames it as a large direct browser upload path. It doesn't go into URL expiry or a required finalize step, but the core mutation is clear enough that agents won't assume bytes are sent in this call.
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?
The purpose is front-loaded in the first sentence and the alternative is named in the second. It is concise overall, though the second and third sentences partly repeat the same routing advice ('use upload_media instead' and 'prefer upload_media for normal files'), keeping it just below a perfect score.
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 two-parameter tool with a full input schema, an output schema, and an annotation block, the description gives enough selection and invocation guidance. It names the sibling alternative and the conditions that choose between them, so nothing critical is missing for calling this tool correctly.
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% and both parameters have descriptions, so the schema already defines sizeBytes and contentType. The description adds the 'large direct upload' context but no syntax or format details beyond the schema, so baseline 3 is 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 and resource: 'Reserve a presigned upload URL for a direct browser upload'. It also scopes the tool to the composer UI and explicitly distinguishes it from upload_media, so an agent can identify what this tool does without opening the schema.
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?
It gives explicit routing: scripted uploads should use upload_media, and presigned large direct uploads should use this tool, with 'advanced' and 'prefer upload_media for normal files' as guardrails. These are concrete when/when-not conditions, not implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new social media post. Can be saved as a draft or scheduled for a specific time. Supports platform-specific content overrides, media attachments, labels, and thread format. IMPORTANT: YouTube and TikTok REQUIRE video — do not include them when posting images only. Instagram defaults to feed_photo — set postTypeOverrides for video content (reel, feed_video). Use this when the user wants to draft or schedule one new post (do not publish immediately unless asked).
| Name | Required | Description | Default |
|---|---|---|---|
| labels | No | Array of label IDs to tag the post with. | |
| status | No | Post status. "draft" (default) or "scheduled". | |
| content | No | The post text content. Optional — defaults to empty for media-only posts. LinkedIn mentions: write @[Display Name](urn:li:organization:ID) for a Page or @[Display Name](urn:li:person:ID) for a person; search_mentions on a LinkedIn channel returns ready-made Page tokens. The token publishes as a real mention on LinkedIn and as plain @Display Name on other channels. | |
| channels | Yes | Array of channels to post to. Get channel IDs from list_channels. | |
| timezone | No | Timezone for scheduling (e.g. "America/New_York"). Defaults to UTC. | |
| postFormat | No | Post format. "post" (default), "video", "reel", "story", "carousel", or "thread" for multi-part threads. | |
| scheduledAt | No | ISO 8601 datetime for scheduling (e.g. 2025-01-15T10:00:00Z). Required when status is scheduled. | |
| threadParts | No | Thread parts array. Required when postFormat is thread (min 2 parts). EVERY part is measured against the character limit of every platform the post targets, not only the first — an over-long part is rejected with 400 VALIDATION_ERROR naming the part number, the platform and its limit. URLs count as 23 characters on X and Mastodon, their real length elsewhere. | |
| mediaFileIds | No | Array of media file IDs to attach. Upload media first with upload_media. | |
| platformContent | No | Per-platform content overrides, e.g. { "x": "Short tweet", "linkedin": "Longer LinkedIn post" }. | |
| requestApproval | No | Optional (default false). Set true to hold a scheduled post for team approval (approvalStatus becomes 'pending'). Forced on server-side for API keys of roles without post:publish (contributors), regardless of this flag. | |
| platformSpecific | No | Platform-specific settings, e.g. { "youtube": { "title": "…", "privacyStatus": "public" } }. Reddit, Discord, Tumblr and Snapchat nest their options under the BulkPublish channel id, e.g. { "reddit": { "12": { "subreddit": "webdev" } } }. Telegram takes no options. | |
| postTypeOverrides | No | Per-platform post type override. E.g. { "instagram": "reel", "youtube": "short" }. | |
| publishWhenApproved | No | Optional (default false). Set true on a post that waits for approval when it should go out as soon as it is approved, even if that is after its scheduled time. This is how someone who needs approval says 'publish now': status 'scheduled', scheduledAt = now, requestApproval true (or a contributor key), publishWhenApproved true. An approval arriving more than 15 minutes late then publishes immediately; with false it is approved but returned to draft for a new time. Stored only when the post ends up approvalStatus 'pending'; otherwise saved as false. | |
| linkTrackingOverride | No | Optional per-post override for link tracking (bulkpubli.sh). true forces links in this post to be shortened and their clicks counted, false forces them to publish as written, and null/omitted (the default) inherits the organization's Link Tracking setting. Shortening happens at publish time, per channel, so two accounts on the same platform get distinct codes; it is skipped for a channel when the rewrite would push the post past that platform's character limit (a short URL is 28 characters and can be longer than the link it replaces). |
| Name | Required | Description |
|---|---|---|
| id | No | |
| author | No | Who wrote the post: { id, name, image }. Null when that account is gone. |
| labels | No | |
| status | No | draft, scheduled, processing, published, partial or failed. |
| content | No | |
| approver | No | Who approved it: { id, name, image }. Null unless approvalStatus is approved. |
| assignee | No | Who is expected to act on it next: { id, name, image }. Null when nobody is. |
| timezone | No | |
| createdAt | No | |
| mediaFiles | No | |
| publishedAt | No | |
| scheduledAt | No | |
| postPlatforms | No | |
| approvalStatus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, and the description adds valuable context: YouTube and TikTok require video, Instagram defaults to feed_photo, and it supports draft/schedule. No contradictions with annotations.
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?
The description is compact and front-loaded: it states the purpose, lists features, then gives important platform warnings. It is not bloated and each sentence adds value.
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 complex tool with 15 parameters and nested objects, the description provides a clear overview and key constraints, while the schema and output schema cover the rest. It omits some details like approval flow, but those are captured in parameter descriptions.
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% – every parameter is documented in the schema. The description adds little beyond schema (e.g., mentions overrides and media generally) but that is acceptable given high coverage. Baseline 3 is 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 clearly states 'Create a new social media post' – a specific verb and resource. It distinguishes from siblings like publish_post by explicitly noting it is for drafting or scheduling, and says 'do not publish immediately unless asked', which differentiates it from immediate-publish tools.
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?
It explicitly says 'Use this when the user wants to draft or schedule one new post' and clarifies not to publish immediately unless asked, steering the agent away from publish_post. It does not name alternatives directly, but the context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a post by ID. Only draft and failed posts can be deleted. Use this when the user wants to permanently remove a post.
| Name | Required | Description | Default |
|---|---|---|---|
| postId | Yes | The post ID to delete. |
| Name | Required | Description |
|---|---|---|
| success | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint: true, so the destructive nature is known. The description adds the eligibility constraint (draft/failed only), which is behavioral context beyond the annotation. It also reinforces permanence with 'permanently remove,' adding a nuance not present in the annotation.
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?
Two short sentences with zero redundancy. The action and constraint are front-loaded, and every word serves a purpose. It is efficient and easy to parse.
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 delete operation with one parameter, annotations cover destructiveness, an output schema exists, and the description provides the essential eligibility rule and usage trigger. Nothing needed for correct invocation 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?
Schema coverage is 100% and the postId parameter is already described as 'The post ID to delete.' The tool description adds no additional semantic detail beyond that, so the baseline of 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?
The description states a specific verb ('delete') and resource ('post'), identifies the identifier (postId), and clarifies the scope by limiting eligible posts to draft and failed ones. This clearly distinguishes it from sibling tools like publish_post or update_post.
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?
It explicitly says 'Use this when the user wants to permanently remove a post,' which provides a direct usage condition. It also adds an eligibility constraint ('Only draft and failed posts can be deleted'), implicitly excluding published posts. However, it does not name alternative tools explicitly, so the guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record an uploaded file as a media file after the browser PUT (pairs with create_media_upload; used by the composer UI). Use this when a presigned direct upload finished and the file must be registered (advanced).
| Name | Required | Description | Default |
|---|---|---|---|
| r2Key | Yes | The r2Key returned by create_media_upload. | |
| width | No | Pixel width (images/video). | |
| height | No | Pixel height (images/video). | |
| duration | No | Duration in seconds (video). | |
| fileName | Yes | Original file name. | |
| mimeType | Yes | File MIME type. | |
| sizeBytes | Yes | File size in bytes. |
| Name | Required | Description |
|---|---|---|
| file | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state the tool is not read-only and not destructive, leaving the mutation nature clear. The description adds that it pairs with create_media_upload and is used by the composer UI, but does not disclose potential side effects (like what happens if called twice) or any authentication requirements. With annotations covering the basic safety profile, a 3 is appropriate.
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?
The description is concise, with two sentences that front-load the core action and then provide usage guidance. No unnecessary words or repetition.
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 tool has an output schema, so return values are assumed to be documented there. The description clarifies the step in the upload flow and the advanced nature, which is sufficient for a well-defined tool in a pipeline. Minor missing detail: preconditions like having a valid presigned upload, but this is implied by pairing with create_media_upload.
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?
The schema has 100% coverage, so all parameters are described there. The description specifically mentions r2Key as returned by create_media_upload, which adds useful context, but does not explain the optional nature of width, height, and duration, or when they should be provided. This is adequate but not exhaustive.
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 clearly states the tool records an uploaded file as a media file after a browser PUT, and explicitly pairs it with create_media_upload. This makes the tool's purpose specific and distinguishes it from the sibling create_media_upload and upload_media, which are likely for different stages of the upload process.
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 guidance: 'Use this when a presigned direct upload finished and the file must be registered (advanced).' This tells the agent exactly when to invoke this tool and indicates it is for advanced scenarios, complementing create_media_upload which is the first step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an analytics summary for a date range. Returns total posts, status breakdown (published, failed, scheduled), per-platform stats, and daily post counts. Optional filters narrow every figure to matching posts; compare adds the equal-length previous window under previous (available for windows of 15 days or fewer — the 30-day statistics-retention cap applies). Use this when the user asks how their content performed overall, across channels and over a date range.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | End date in ISO format (e.g. 2025-01-31). | |
| from | Yes | Start date in ISO format (e.g. 2025-01-01). | |
| compare | No | Also return the previous equal-length window as `previous` / `previousWindow`. | |
| labelIds | No | Comma-separated label ids; a post matches when it carries ANY of them. | |
| mediaType | No | By the post's first media file: text (no media), image or video. | |
| platforms | No | Comma-separated platform keys to include, e.g. "x,linkedin". | |
| channelIds | No | Comma-separated channel ids to include, e.g. "12,15". | |
| postFormat | No | Only single posts or only threads. |
| Name | Required | Description |
|---|---|---|
| to | No | |
| from | No | |
| byDay | No | |
| failed | No | |
| partial | No | |
| previous | No | |
| published | No | |
| scheduled | No | |
| byPlatform | No | |
| totalPosts | No | |
| previousWindow | No | |
| publishedTimes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint=true, destructiveHint=false, idempotentHint=true). The description adds useful behavioral details beyond that, such as the effect of filters ('narrow every figure to matching posts'), the behavior of 'compare' (adds equal-length previous window under `previous`), and the 30-day statistics-retention cap for windows of 15 days or fewer. This adds context that helps the agent anticipate constraints and return shapes without contradicting annotations.
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?
The description is front-loaded with the core purpose and return contents in the first sentence, then efficiently explains filters, compare behavior, and the usage trigger in a few dense sentences. Every clause carries meaning; there is no filler or redundancy. It strikes a good balance between detail and brevity for an 8-parameter tool.
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?
Given the tool's complexity (8 parameters, several optional filters) and that an output schema exists, the description covers the essential aspects: what it returns, how filters affect results, the compare feature with its constraints (15-day limit, 30-day retention), and when to use it. Combined with the annotations and output schema, an agent has sufficient context to call the tool correctly without further documentation.
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?
The schema descriptions cover 100% of parameters, so the baseline is 3. However, the description adds semantic value by explaining the collective effect of optional filters ('narrow every figure to matching posts') and the specific behavior of the `compare` flag, including the retention cap constraint. This goes beyond the schema's individual parameter definitions and clarifies the aggregate impact, so a 4 is justified.
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 ('Get'), resource ('an analytics summary'), and the exact contents returned ('total posts, status breakdown... per-platform stats, and daily post counts'). The final sentence clarifies the intended use case ('how their content performed overall, across channels and over a date range'), which together with the specificity differentiates it from siblings like get_post_metrics or view_analytics even without naming them.
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 an explicit usage condition: 'Use this when the user asks how their content performed overall, across channels and over a date range.' This clearly describes when to use the tool, but it does not explicitly mention alternative tools or describe when not to use it, so it doesn't earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single post by ID with full details including platform statuses, labels, media files, recurring schedule info, and metrics. For a thread post, threadParts holds the parts and threadMediaFiles resolves the media they reference: that media is NOT in mediaFiles, which carries only the media on the post itself. Use this when the user references one specific post by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| postId | Yes | The post ID. |
| Name | Required | Description |
|---|---|---|
| id | No | |
| author | No | Who wrote the post: { id, name, image }. Null when that account is gone. |
| labels | No | |
| status | No | draft, scheduled, processing, published, partial or failed. |
| content | No | |
| approver | No | Who approved it: { id, name, image }. Null unless approvalStatus is approved. |
| assignee | No | Who is expected to act on it next: { id, name, image }. Null when nobody is. |
| timezone | No | |
| createdAt | No | |
| mediaFiles | No | |
| publishedAt | No | |
| scheduledAt | No | |
| postPlatforms | No | |
| approvalStatus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable behavioral nuance about thread posts: threadParts and threadMediaFiles behave differently from mediaFiles, which is not inferable from annotations or the schema.
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 sentences, each earning its place: the core purpose, the thread nuance, and the usage trigger. The most important information is front-loaded, and there is no redundant filler.
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 single-parameter read tool with a full output schema, the description covers the needed call context and clarifies a non-obvious data placement behavior. Nothing essential is missing for an agent to invoke it correctly.
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% and the only parameter, postId, is already documented as 'The post ID.' The description reinforces that the ID selects a single post but adds no additional format or constraint details beyond the schema.
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 action ('Get a single post by ID') and resource, with an explicit enumeration of what 'full details' includes. It clearly distinguishes this from sibling tools like list_posts and get_post_metrics by anchoring on a single post ID.
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 final sentence gives an explicit trigger: 'Use this when the user references one specific post by its ID.' It does not name alternatives such as list_posts for multiple posts, so there is a clear usage context but no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get engagement metrics for a published post. Returns likes, comments, shares, impressions, and other platform-specific metrics. IMPORTANT: every platform entry carries metricsSupported and supportedMetrics — a metric key NOT in supportedMetrics is stored as 0 because that platform's API has no such field, so report it as unavailable rather than as zero. X reports impressions/likes/comments/shares/saves (bookmarks); Bluesky and Mastodon report no impressions; Pinterest reports no reach; YouTube reports no shares or reach; Reddit reports likes (score), comments and shares (crossposts); Discord reports likes (reaction counts) and comments (thread replies); Google Business, Telegram, Tumblr and LinkedIn personal profiles report nothing readable at all. Each platform entry also carries linkClicks (summed in totals.linkClicks): clicks on bulkpubli.sh short links in this post, measured by BulkPublish rather than reported by the platform. It sits OUTSIDE latest and is distinct from the platform's own clicks — one visit can register in both, so never add them together. It is therefore available even for the platforms that report nothing, and supportedMetrics always includes it. Bot and link-preview traffic is excluded; it is 0 for organizations without Link Tracking enabled. Use this when the user asks how a specific post performed (likes, views, engagement).
| Name | Required | Description | Default |
|---|---|---|---|
| postId | Yes | The post ID to get metrics for. |
| Name | Required | Description |
|---|---|---|
| postId | No | |
| totals | No | |
| platforms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint annotation: it explains that unsupported metrics appear as zero, that linkClicks are computed by BulkPublish and may be present even when platforms report no metrics, that bot traffic and link-preview traffic are excluded, and that organizations without Link Tracking see zero. This prevents common misinterpretations that annotations alone would not.
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?
The description is long but information-dense and front-loaded with the core purpose. The detailed per-platform metric notes and the zero-value warning are essential for correct use, though some redundancy exists around linkClicks being included in totals. Overall, each section 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 description covers the full semantics an agent needs: what metrics exist, which platforms report which metrics, how missing values are represented, how linkClicks differ from platform clicks, exclusions for bot traffic, and the exact user-request scenario that should trigger this tool. This is especially valuable given the rich output schema and potentially confusing zero values.
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?
The only parameter is postId, which the schema already documents. The description adds only that the post should be published and that the tool answers questions about a specific post's performance, which is minor extra context. It does not explain postId format, lookup semantics, or errors, so it provides little beyond the schema.
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 a clear verb and resource: 'Get engagement metrics for a specific post.' It explicitly names the returned data (likes, comments, shares, views) and closes with an explicit use case. This distinguishes it from siblings like get_analytics or list_posts by fixing scope to a single post.
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 gives an explicit trigger: 'Use this when the user asks how a specific post performed.' It does not explicitly name alternative tools such as get_analytics or view_analytics for aggregate/cross-post analytics, so it misses the top bar for exclusion guidance. Still, the context for when this tool is appropriate is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the organization's next available queue slot. Useful for finding the next optimal scheduling time. Use this when the user asks when the next available scheduling slot is, or wants a post moved to the top or bottom of the queue (then update_post with the returned scheduledAt).
| Name | Required | Description | Default |
|---|---|---|---|
| position | No | "next" (default): the next free slot. "end": the slot after the last pending scheduled post, i.e. the bottom of the queue. | |
| timezone | No | IANA timezone for the slot calculation (e.g. "America/New_York"). Defaults to UTC. | |
| excludePostId | No | When the slot is for rescheduling an existing post, its ID — so its current slot is not counted as booked. |
| Name | Required | Description |
|---|---|---|
| dayLabel | No | Human label, e.g. "Today" or "Wed, Feb 14". |
| scheduledAt | No | ISO timestamp of the next free slot. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint, covering the safety profile. The description adds useful behavioral context beyond those annotations: the tool returns a scheduledAt value intended to be passed to update_post for queue repositioning, and it frames the result as the next available or end-of-queue slot. No contradiction with annotations.
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 with no filler. The tool's core action is front-loaded, followed by the use-case guidance and the companion-tool workflow. Every sentence contributes to selection or invocation.
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 read-only, idempotent tool with zero required parameters, full schema parameter coverage, and an output schema present, the description is complete. It explains when to reach for the tool and what to do with its result, while the structured data handles parameter details and return shape.
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?
The input schema already provides 100% coverage with detailed descriptions for all parameters, including the position enum, timezone format, and excludePostId semantics. The description adds only general context about 'top or bottom of the queue,' which maps loosely to the position parameter but does not materially improve on the schema. Baseline 3 is 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 uses a specific verb-resource pair: "Get the organization's next available queue slot." It also clarifies the purpose as finding the next optimal scheduling time, and it implicitly distinguishes itself from the content-management siblings by framing the tool as a scheduling-position query rather than a post creation or editing operation.
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 explicitly states when to use the tool: when the user asks for the next available scheduling slot or wants a post moved to the top/bottom of the queue. It even names the follow-up action, update_post with the returned scheduledAt, which gives the agent a clear invocation path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all connected social media channels (X/Twitter, Instagram, LinkedIn, Facebook, TikTok, etc.). Returns channel ID, platform, account name, and token status, plus a capabilities object saying whether the caller may create, publish or approve posts. Check that before attempting a write rather than discovering the permission from a 403. Use this when the user wants to see which social accounts are connected.
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | Filter by active status. Defaults to true (only active channels). |
| Name | Required | Description |
|---|---|---|
| channels | No | |
| capabilities | No | Whether the caller may create, publish or approve posts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by explaining that the tool returns a `capabilities` object that indicates whether the caller may create, publish, or approve posts, and advises checking it before a write to avoid a 403. This goes beyond the annotations and helps the agent understand the tool's role in the workflow.
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?
The description is compact and front-loaded: it states the core purpose first, then the return fields, then the capabilities warning, then the usage trigger. Every sentence earns its place, and the structure is logical for an agent scanning for when to use the tool.
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 tool has an output schema, so return values are documented elsewhere. The description covers the key behavioral aspect (capabilities check) and the usage context. It doesn't mention pagination or rate limits, but for a simple list tool with one optional parameter and an output schema, the description is sufficiently complete. A 4 is appropriate because it adds the capabilities context that is crucial for the agent's decision-making.
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 single parameter `active` is fully documented in the schema. The description doesn't add extra parameter semantics beyond what the schema provides, but it does mention the default behavior ('Defaults to true') which is already in the schema. Baseline 3 is appropriate since the schema carries the parameter documentation.
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 ('List') and resource ('all connected social media channels'), enumerates the platforms, and lists the returned fields. It distinguishes itself from sibling tools like view_channels by focusing on the channel listing with token status and capabilities, making it clear 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 explicitly says 'Use this when the user wants to see which social accounts are connected.' It also provides a clear directive to check the `capabilities` object before attempting a write, which guides the agent on when to use this tool versus attempting a write operation directly. This is strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List uploaded media files with optional search and pagination. Returns file metadata including URLs, dimensions, and labels. Use this when the user wants a list of their uploaded media files.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1). | |
| type | No | Filter by media kind (matches the MIME type prefix). The response's `total` counts matches across all pages. | |
| limit | No | Results per page (default 20, max 100). | |
| search | No | Search by filename. |
| Name | Required | Description |
|---|---|---|
| page | No | |
| files | No | |
| limit | No | |
| total | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, idempotent, non-destructive behavior, so the description does not need to repeat those. It adds some context about the return metadata, URLs, dimensions, and labels, and optional search/pagination, but it does not go beyond the schema for behavior like pagination or total counts.
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?
The description is concise, front-loaded with the core action, and contains no filler. All three sentences earn their place: what the tool does, what it returns, and when to use it.
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 read-only list tool, the description plus a 100%-covered schema and output schema is sufficient for correct invocation. It covers purpose, triggers, and result kinds, and there are no required parameters or special prerequisites to explain.
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 parameters already have meaningful descriptions. The tool description additionally notes that search/pagination exist but does not add notable parameter semantics beyond what the schema already documents.
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 a specific verb and resource: 'List uploaded media files with optional search and pagination'. It clearly identifies the tool's task and return content, and is easily distinguishable from list_posts/list_channels, though it does not explain how it differs from the similarly named view_media sibling.
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 has an explicit usage trigger: 'Use this when the user wants a list of their uploaded media files.' This is strong contextual guidance, but it lacks when-not-to-use guidance or references to alternatives such as view_media or list_posts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List posts with optional filters for status, search text, date range, channel, and label. Returns paginated results with platform statuses and metrics, ordered newest-first by publishedAt if the post is live, else scheduledAt, else createdAt. Use this when the user wants to browse, filter, or check the status of existing posts as raw data (not the visual dashboard).
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Filter posts created on or before this ISO date. | |
| from | No | Filter posts created on or after this ISO date. | |
| page | No | Page number (default 1). | |
| limit | No | Results per page (default 20, max 500). | |
| order | No | Direction of the timeline sort (published, else due, else created). 'desc' is the default and returns the most recent first. Use 'asc' to read what is coming NEXT — with a limit, 'desc' returns the posts scheduled furthest out, not the soonest. | |
| search | No | Search post content (case-insensitive). | |
| status | No | Filter by post status. | |
| labelId | No | Filter by label ID. | |
| channelId | No | Filter by channel ID. | |
| assignedTo | No | Filter by who the post is assigned to: a user id, 'me' for the caller, or 'unassigned'. Orthogonal to status — a post can be scheduled AND assigned. | |
| scheduledTo | No | Filter posts scheduled on or before this ISO date. | |
| scheduledFrom | No | Filter posts scheduled on or after this ISO date. | |
| approvalStatus | No | Filter by team approval state (e.g. 'pending' for the approval queue). |
| Name | Required | Description |
|---|---|---|
| page | No | |
| limit | No | |
| posts | No | |
| total | No | |
| totalPages | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds genuine behavioral context beyond annotations: pagination, platform statuses and metrics in results, and the exact ordering rule (publishedAt if live, else scheduledAt, else createdAt). This is useful operational detail not present in the annotations.
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 sentences with no wasted words. It front-loads the core purpose and filters, then gives return/ordering behavior, then a usage context. Every sentence 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?
For a complex 13-parameter list tool, the description covers what the tool returns, how results are ordered, pagination, and when to use it, while the schema and output schema cover parameter details. No critical aspect needed to invoke the tool correctly 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?
Schema description coverage is 100%, so the schema already documents all 13 parameters in detail. The description adds a helpful high-level summary of filter categories and clarifies the ordering semantics, but it does not meaningfully add parameter-level meaning beyond what the schema already provides.
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 and resource ('List posts') and immediately enumerates the optional filter dimensions: status, search text, date range, channel, and label. It also distinguishes itself from visual-dashboard siblings by explicitly positioning this tool as returning raw data, so an agent can tell list_posts from view_posts.
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 gives a clear trigger: 'Use this when the user wants to browse, filter, or check the status of existing posts as raw data.' It also implies a boundary with 'not the visual dashboard,' but it does not explicitly name alternative tools or state when not to use them, so it stops short of full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish a draft or scheduled post immediately. The post will be queued for publishing to all its target channels. Requires a role with post:publish — contributors get 403 APPROVAL_REQUIRED and must submit the post for approval instead (create/update with requestApproval, then a teammate approves). To 'publish now' with approval, create_post with status 'scheduled', scheduledAt = now, requestApproval true and publishWhenApproved true, so it goes out the moment it is approved. Publishing a pending/rejected post as an approver implicitly approves it. Use this when the user wants to publish an existing draft or scheduled post right now.
| Name | Required | Description | Default |
|---|---|---|---|
| postId | Yes | The post ID to publish. |
| Name | Required | Description |
|---|---|---|
| id | No | |
| author | No | Who wrote the post: { id, name, image }. Null when that account is gone. |
| labels | No | |
| status | No | draft, scheduled, processing, published, partial or failed. |
| content | No | |
| approver | No | Who approved it: { id, name, image }. Null unless approvalStatus is approved. |
| assignee | No | Who is expected to act on it next: { id, name, image }. Null when nobody is. |
| timezone | No | |
| createdAt | No | |
| mediaFiles | No | |
| publishedAt | No | |
| scheduledAt | No | |
| postPlatforms | No | |
| approvalStatus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant context beyond the annotations: the post is queued to all target channels, requires a post:publish role, and publishing a pending/rejected post as an approver implicitly approves it. These side effects and permission boundaries are not conveyed by readOnlyHint, destructiveHint, or idempotentHint.
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?
The description is longer than minimal, but each sentence earns its place: action and effect, permission requirement, contributor failure mode, approval workaround, implicit approval behavior, and final use-case summary. It could be tightened slightly, but there is no filler.
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 single-parameter mutating tool, this covers when to use it, who can use it, the failure mode, the workaround, and the queuing side effect. An output schema exists, so return-value details are not needed, and nothing essential is missing for correct invocation.
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?
The input schema already documents the single parameter postId at 100% coverage, so the description does not need to restate it. It usefully implies the post must already be a draft or scheduled post, but adds no format or validation detail beyond the schema.
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?
Opens with a specific verb and resource: 'Publish a draft or scheduled post immediately.' Closes with the precise use case ('existing draft or scheduled post right now'), which clearly differentiates it from create, update, retry, and delete siblings.
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?
Explicitly tells when to use this tool and when not to: contributors get 403 APPROVAL_REQUIRED and must instead use create/update with requestApproval. It even provides the exact create_post parameters for the approval-based 'publish now' path, leaving no ambiguity about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retry publishing a failed or partially failed post. Only retries the platforms that failed, not the ones that already succeeded. Platforms in status 'unconfirmed' (the publish request may have reached the platform but its response was lost — the post may already be live) are NOT retried unless republish is true; if the post has unconfirmed platforms and no failed ones, the call fails with a 400 and code UNCONFIRMED_REQUIRES_REPUBLISH — ask the user to check the account on the platform, and only pass republish: true after they confirm the post is not live. Use this when a post failed on some platforms and the user wants to retry just those.
| Name | Required | Description | Default |
|---|---|---|---|
| postId | Yes | The post ID to retry. | |
| republish | No | Explicit opt-in to also retry platforms in status 'unconfirmed'. Their publish may have already gone through, so this can DUPLICATE the post — only pass true after the user has checked the account and confirmed the post is not live. Defaults to false. |
| Name | Required | Description |
|---|---|---|
| id | No | |
| author | No | Who wrote the post: { id, name, image }. Null when that account is gone. |
| labels | No | |
| status | No | draft, scheduled, processing, published, partial or failed. |
| content | No | |
| approver | No | Who approved it: { id, name, image }. Null unless approvalStatus is approved. |
| assignee | No | Who is expected to act on it next: { id, name, image }. Null when nobody is. |
| timezone | No | |
| createdAt | No | |
| mediaFiles | No | |
| publishedAt | No | |
| scheduledAt | No | |
| retriedCount | No | How many destinations were retried. |
| postPlatforms | No | |
| approvalStatus | No | |
| skippedMaxRetries | No | Destinations skipped for hitting the retry ceiling. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructive and non-idempotent behavior, but the description adds critical context: it explains that only failed platforms are retried, that unconfirmed platforms are excluded unless republish=true, and that using republish can duplicate posts. It also discloses the exact error behavior (400 with code UNCONFIRMED_REQUIRES_REPUBLISH) and instructs how to handle it. This goes well beyond the annotations and is essential for safe invocation.
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?
The description is thorough and slightly long, but every sentence contributes necessary details: purpose, platform scoping, unconfirmed handling, error guidance, and usage condition. It is front-loaded with the core action and then elaborates logically. No redundancy is present; it earns its length, though it could be trimmed slightly without losing value.
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?
Given the tool's complexity (subtle platform statuses, error handling, user interaction) and the presence of an output schema, the description covers everything an agent needs: purpose, scope, parameter semantics, error behavior, and actionable guidance. The output schema handles return values, so no gaps are apparent. This is a complete, self-sufficient description.
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 documented. The description adds significant meaning for republish: clarifying the exact condition for passing true (after user confirmation), the risk of duplication, and the error scenario. It also reinforces the purpose of postId. While the baseline for full schema coverage is 3, the added semantic depth for republish justifies a 4.
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 a specific verb and resource: 'Retry publishing a failed or partially failed post.' It immediately clarifies scope by stating it only retries failed platforms, not successful ones, which distinguishes it clearly from sibling tools like create_post or publish_post. The purpose is unmistakable and precise.
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 explicitly states when to use the tool: 'Use this when a post failed on some platforms and the user wants to retry just those.' It also provides detailed conditions for the republish parameter, explains the UNCONFIRMED_REQUIRES_REPUBLISH error case, and advises how to interact with the user. This is exemplary usage guidance, including both when-to-use and when-not-to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing post. Can change content, schedule, media, labels, status, and platform-specific settings. Only draft, scheduled, failed, or partial posts can be edited; editing a failed post resets it to draft, a partial post stays partial. Set status to 'draft' or 'scheduled' to move the post between those states — scheduling a partial post re-queues only its failed channels; use publish_post to publish immediately. Use this when the user wants to edit an existing post.
| Name | Required | Description | Default |
|---|---|---|---|
| postId | Yes | The post ID to update. | |
| status | No | Move the post between draft and scheduled. 'scheduled' requires a future scheduledAt (in this call or already stored) and at least one channel; 'draft' unschedules it. Any other value is rejected. Omit to leave the status unchanged. To publish immediately, use publish_post instead. | |
| content | No | New post text content. | |
| labelIds | No | Replace label IDs on the post. | |
| timezone | No | Timezone for scheduling. | |
| scheduledAt | No | New ISO 8601 scheduled datetime. | |
| mediaFileIds | No | Replace attached media file IDs. | |
| requestApproval | No | Optional (default false). Set true to hold a scheduled post for team approval (approvalStatus becomes 'pending'). Forced on server-side for API keys of roles without post:publish (contributors), regardless of this flag. | |
| platformSpecific | No | Platform-specific settings, e.g. { "youtube": { "title": "…", "privacyStatus": "public" } }. Reddit, Discord, Tumblr and Snapchat nest their options under the BulkPublish channel id, e.g. { "reddit": { "12": { "subreddit": "webdev" } } }. Telegram takes no options. | |
| ifUnmodifiedSince | No | Optional precondition: the post's updatedAt exactly as the last read returned it. The update is refused with 409 CONFLICT if a teammate has changed the post since, rather than overwriting their version. Pass it whenever you read a post before editing it; omit it to keep the previous last-write-wins behaviour. | |
| postTypeOverrides | No | Per-platform post type override. E.g. { "instagram": "reel", "youtube": "short" }. | |
| publishWhenApproved | No | Optional. Set true to have the post go out as soon as it is approved, even after its scheduled time (see create_post). An explicit value is stored while the post waits for approval. Omitted, it is kept, except that sending a different scheduledAt clears it to false, and it is always false once the post is no longer approvalStatus 'pending'. | |
| linkTrackingOverride | No | Optional per-post override for link tracking (bulkpubli.sh). true forces links in this post to be shortened and their clicks counted, false forces them to publish as written, and null clears the override so the post inherits the organization's Link Tracking setting again. Omit to leave it unchanged. |
| Name | Required | Description |
|---|---|---|
| id | No | |
| author | No | Who wrote the post: { id, name, image }. Null when that account is gone. |
| labels | No | |
| status | No | draft, scheduled, processing, published, partial or failed. |
| content | No | |
| approver | No | Who approved it: { id, name, image }. Null unless approvalStatus is approved. |
| assignee | No | Who is expected to act on it next: { id, name, image }. Null when nobody is. |
| timezone | No | |
| createdAt | No | |
| mediaFiles | No | |
| publishedAt | No | |
| scheduledAt | No | |
| postPlatforms | No | |
| approvalStatus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey the mutation (readOnlyHint=false) and destructive/destructiveHint=true nature. The description adds valuable behavioral nuance beyond that: failed posts reset to draft, partial posts stay partial, scheduling a partial post re-queues only failed channels, and status transitions between draft and scheduled. It does not contradict any annotation and explains outcomes that annotations don't cover. A 4 is appropriate because it supplements rather than replaces the annotations.
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?
The description is a single, well-organized paragraph that front-loads the purpose and key rules. It is longer than many descriptions but justified by the tool's complexity, and every sentence carries useful information (editable statuses, status transitions, and sibling routing). It makes efficient use of ~4 sentences and avoids fluff, earning a 4 rather than a 3.
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 tool with 13 parameters and deeply nested platform-specific options, the description provides a solid overview: it names the editable fields, the status constraints, and the alternative publish path. It does not enumerate each platform's details, but the schema covers those thoroughly. Given the output schema exists and annotations cover safety, the description is sufficiently complete for an agent to decide when to invoke it and what it will do. It could mention the ifUnmodifiedSince precondition or approval parameters, but these are already described in the schema, so the description's brevity is acceptable.
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 baseline is 3. The description adds a high-level mapping to 'content, schedule, media, labels, status, and platform-specific settings' but does not go into the meaning of individual parameters beyond that – that detail is already in the schema. It does clarify the behavior of the status parameter (only draft/scheduled allowed, and the effects on failed/partial posts), which is a modest extra. Overall, it meets the baseline without adding much beyond what the schema already states.
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 'Update an existing post' – a specific verb and resource – and lists the exact fields it can change (content, schedule, media, labels, status, platform-specific settings). It also implicitly distinguishes itself from publish_post by noting 'use publish_post to publish immediately.' This clearly sets it apart from siblings like delete_post or compose_post.
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 gives explicit when-to-use guidance ('Use this when the user wants to edit an existing post') and concrete exclusions: only draft, scheduled, failed, or partial posts can be edited. It also names the alternative (publish_post) for immediate publishing and explains status-transition rules. This is strong routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a media file (image or video) from a URL or local file path. The file is stored in BulkPublish for use in posts. Supported formats: JPEG, PNG, WebP, GIF, MP4, MOV, WebM. Max 100MB. Provide either url OR filePath, not both. Use this when the user provides an image/video to attach to a post.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Public URL of the media file to upload. | |
| filePath | No | Absolute path to a local file to upload (e.g. /Users/me/photo.png). | |
| filename | No | Optional filename. If omitted, derived from the URL or file path. |
| Name | Required | Description |
|---|---|---|
| id | No | |
| url | No | |
| file | No | |
| filename | No | |
| mimeType | No | |
| sizeBytes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (write operation) and openWorldHint=true (side effects). The description discloses the storage side effect ('The file is stored in BulkPublish'), supported formats, size limit, and the exclusivity constraint. It does not mention potential error scenarios or sync/async behavior, but it adds meaningful behavioral context beyond the annotations, such as the storage location and format/limit constraints.
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 concise sentences: first states the action and purpose, second lists supported formats and size, third gives the either/or constraint and usage guidance. No redundant phrasing, information is front-loaded, and every sentence contributes to understanding the tool.
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?
Given the presence of an output schema (for return values), the description covers purpose, input constraints, formats, and usage context. It does not detail the relationship with sibling tools like create_media_upload and finalize_media_upload, which might be part of a multi-step upload workflow. This is a slight gap for an agent deciding whether this tool is sufficient or if those steps are needed. Overall, it is largely complete but missing that orchestration context.
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 all parameters are documented in the schema. The description adds the exclusive-or constraint (url OR filePath) and reinforced the meaning of filename derivation from URL/path, which is partially in the schema. It also conveys format and size constraints that affect parameter choices, adding value beyond the schema.
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 ('Upload') and resource ('media file'), elaborates the input sources (URL or local path), and clarifies the file is stored in BulkPublish for later posts. It clearly differentiates from siblings like create_media_upload and finalize_media_upload by describing the entire upload action, and it explicitly ties to the use case of attaching media to a post.
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 a clear when-to-use condition: 'Use this when the user provides an image/video to attach to a post.' It also gives an explicit constraint ('Provide either url OR filePath, not both'). However, it does not mention alternatives or the specific workflow involving create_media_upload and finalize_media_upload, which could be relevant for multipart uploads or larger files, leaving some ambiguity about when to choose this tool over those.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open an interactive analytics dashboard for a date range — totals, status breakdown, per-platform stats, and daily post counts. Use this when the user wants an interactive analytics dashboard — prefer over get_analytics for a visual view.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End date (ISO). Defaults to today. | |
| from | No | Start date (ISO, e.g. 2025-01-01). Defaults to 30 days ago. |
| Name | Required | Description |
|---|---|---|
| to | No | |
| from | No | |
| summary | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering risks. The description additionally clarifies the tool's behavior (interactive dashboard) and what the view contains, which goes beyond the structured annotations. It does not mention any auth/rate constraints, but these are not necessary given the pervasive read-only safety profile and the annotation coverage.
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?
Two tight sentences that lead with the precise action, list the dashboard content, and give selection guidance. There is no filler and each sentence 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 description gives sufficient context for a tool that already has an output schema and annotations for side-effect behavior. It clearly conveys what the dashboard includes and when to use it. The 'interactive' nature is described with enough clarity for typical agent invocation; a slightly deeper note about return format would be a minor embellishment, but output schema covers that.
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?
The input schema fully describes both parameters with dates and defaults (100% coverage), so the description adds no new parameter semantics; it only repeats the concept of a date range. With the schema doing the heavy lifting, baseline 3 is right.
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 explicitly says 'Open an interactive analytics dashboard' and lists the contents: totals, status breakdown, per-platform stats, daily post counts. It also distinguishes itself from get_analytics by noting that this is the visual alternative. This fully disambiguates it from sibling tools without ambiguity.
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?
It provides a clear decision rule: 'Use this when the user wants an interactive analytics dashboard — prefer over get_analytics for a visual view.' This explicitly states when to select it and names the actual alternative, so an agent can decide without inspecting other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open an interactive view of connected social channels with platform, account, and connection/token status. Use this when the user wants an interactive view of their connected channels.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| channels | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile of the tool. The description adds the 'interactive' nature and the data content shown, but it does not describe how interaction works, whether there are any side effects or state changes, or any other behaviors beyond what the structured annotations imply. The 'interactive' wording is a valuable addition, but the overall disclosure is modest.
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?
The description is two short sentences, the first stating the action and content, the second giving the trigger condition. No fluff or repetition; every sentence earns its place and the key verb and resource are front-loaded.
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 barrier-less, parameterless tool with a read-only and idempotent annotation set and an output schema, the description is sufficiently complete for an agent to know why and when to use it. A slight gap is the lack of a suggested contrast with 'list_channels' to make the selection fully unambiguous, but that mostly affects usage differentiation rather than invocation correctness.
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 0 parameters, the schema covers 100% of the interface by definition, so the description does not need to explain any parameter. It correctly omits parameter details and instead focuses on the action, which is the right baseline for a parameterless tool.
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 clearly states the action ('Open an interactive view') and the resource ('connected social channels'), and it enumerates the visible content (platform, account, connection/token status). It differentiates from siblings through the 'interactive view' phrasing, but it never names the natural alternative 'list_channels', so the distinction remains implicit rather than explicit.
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?
It gives a direct usage cue: 'Use this when the user wants an interactive view of their connected channels.' This communicates the intended scenario, but it does not mention when not to use it or point to an alternative like 'list_channels', which would be the analogous non-interactive read tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open an interactive gallery of uploaded media files with thumbnails and metadata. Use this when the user wants to browse their media library visually.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max items to show (default 30). |
| Name | Required | Description |
|---|---|---|
| media | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent, and non-destructive. The description adds relevant behavior beyond that: it opens an interactive gallery with thumbnails and metadata, clarifying the experience the user will get. No contradiction with annotations.
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?
Two short sentences that immediately state the action and the intended use case. No redundant filler or schema repetition.
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 read-only gallery tool with one optional parameter and an output schema, the description provides sufficient context. It could be slightly stronger by explaining the role of the limit parameter or by distinguishing itself from list_media, but it is not a major gap.
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?
The input schema fully describes the only parameter (limit) with a default value, so the description doesn't need to add much. It adds no extra detail about how the limit applies to the gallery, but the schema coverage is complete.
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 clearly states the action ('Open an interactive gallery') and the resource ('uploaded media files'). It also conveys the visual browsing purpose, which differentiates it from a plain data-returning list tool like list_media.
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?
It explicitly says to use this when the user wants to visually browse their media library. It does not explicitly contrast it with sibling tools like list_media, but the visual-gallery framing gives enough direction for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open an interactive list of posts with their status, schedule, and channels. Optionally filter by status. Use this when the user wants to see their posts as an interactive dashboard — prefer over list_posts for a visual view.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max posts to show (default 20). | |
| status | No | Filter by post status. |
| Name | Required | Description |
|---|---|---|
| posts | No | |
| total | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds the behavioral nuance of being 'interactive' and 'visual,' which goes beyond the annotations. It doesn't contradict them, and it provides useful context about the nature of the UI.
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?
The description is a single, tightly written sentence that leads with the primary purpose and includes routing advice. Every word earns its place; there is no filler.
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 read-only, non-destructive tool with only two optional parameters, a clear purpose, and an existing output schema, the description fully covers what an agent needs: what it does, when to use it, and how to differentiate it. Nothing essential 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?
Schema description coverage is 100%, so both parameters (limit and status) are already well-documented. The description merely reiterates that status filtering is optional, which is already implied by the schema's non-required status. It adds no new meaning beyond the schema, so the baseline of 3 is 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 ('Open'), a resource ('interactive list of posts'), and the key attributes (status, schedule, channels). It explicitly differentiates from sibling list_posts by saying 'prefer over list_posts for a visual view,' making the tool's distinct purpose unmistakable.
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?
It provides direct when-to-use guidance: 'Use this when the user wants to see their posts as an interactive dashboard.' It also names the alternative (list_posts) and the selection criterion (visual vs. non-visual), leaving no ambiguity about tool choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_post24 fields changedInput schema / properties / content / descriptionPrevious value: -"The post text content. Optional — defaults to empty for media-only posts."New value: +"The post text content. Optional — defaults to empty for media-only posts. LinkedIn mentions: write @[Display Name](urn:li:organization:ID) for a Page or @[Display Name](urn:li:person:ID) for a person; search_mentions on a LinkedIn channel returns ready-made Page tokens. The token publishes as a real mention on LinkedIn and as plain @Display Name on other channels."Input schema / properties / platformSpecific / properties / bluesky / properties / repostIdAdded value: +{
+ "description": "With postTypeOverrides.bluesky = 'repost': the bsky.app post URL (or at:// URI) to repost.",
+ "type": "string"
+}Input schema / properties / platformSpecific / properties / facebook / properties / thumbnailUrlAdded value: +{
+ "description": "Cover image URL for a video or Reel. Facebook only accepts a cover once the video exists, so it is applied after the video publishes and appears a moment after the post; a cover that cannot be fetched or that Facebook rejects leaves the video published with Facebook's own chosen frame rather than failing the post.",
+ "type": "string"
+}Input schema / properties / platformSpecific / properties / instagram / properties / collaborators / descriptionAdded value: +"Comma-separated Instagram usernames (no leading @) tagged as co-authors. Applies with postTypeOverrides.instagram of 'feed_photo', 'feed_video', 'reel' or 'carousel' — on a carousel the co-authors are set on the carousel itself, not on its individual items. Ignored on 'story', which has no co-author concept."Input schema / properties / platformSpecific / properties / instagram / properties / coverUrlAdded value: +{
+ "description": "Cover image URL for a video or Reel. Takes precedence over thumbnailTimestamp: Instagram accepts one or the other and rejects a request carrying both, so only this one is forwarded when both are sent.",
+ "type": "string"
+}Input schema / properties / platformSpecific / properties / instagram / properties / graduationStrategy / descriptionAdded value: +"How a trial reel becomes a normal one: 'manual' (the creator releases it) or 'auto' (released automatically if it performs well). Default 'manual'. Ignored unless trialReel is true."Input schema / properties / platformSpecific / properties / instagram / properties / thumbnailTimestamp / descriptionAdded value: +"Cover frame for a video or Reel, in seconds from the start. Applies to postTypeOverrides.instagram of 'feed_video' or 'reel'. Ignored when coverUrl is also set."Input schema / properties / platformSpecific / properties / instagram / properties / trialReel / descriptionAdded value: +"Publish as a trial reel, shown to people who do not follow the account first. Only takes effect with postTypeOverrides.instagram of 'reel' — a 'feed_video' publishes as an ordinary reel and this is ignored, even though both use the same underlying reel container."Input schema / properties / platformSpecific / properties / mastodon / properties / repostIdAdded value: +{
+ "description": "With postTypeOverrides.mastodon = 'repost': the status URL or ID to boost.",
+ "type": "string"
+}Input schema / properties / platformSpecific / properties / threads / properties / locationIdAdded value: +{
+ "description": "Numeric place ID from get_channel_options with a `q` search on a Threads channel. Only works once the channel has granted location tagging.",
+ "type": "string"
+}Input schema / properties / platformSpecific / properties / threads / properties / repostIdAdded value: +{
+ "description": "With postTypeOverrides.threads = 'repost': the numeric ID of the Threads post to repost (Threads links cannot be used; the ID of a post published through BulkPublish is in get_post's platforms[].platformPostId).",
+ "type": "string"
+}Input schema / properties / platformSpecific / properties / threads / properties / topicTagAdded value: +{
+ "description": "One topic tag for the post, without a leading '#'. Must not contain periods or ampersands.",
+ "type": "string"
+}Input schema / properties / platformSpecific / properties / tiktok / properties / thumbnailTimestamp / descriptionAdded value: +"Cover frame for the video, in seconds from the start."Input schema / properties / platformSpecific / properties / tumblr / descriptionPrevious value: -"Tumblr options, nested under the BulkPublish channel id: { \"12\": { \"blogName\": \"myblog\", \"tags\": [\"art\"] } }. A flat object applies to every Tumblr channel on the post. Up to 30 images OR exactly one video per post."New value: +"Tumblr options, nested under the BulkPublish channel id: { \"12\": { \"blogName\": \"myblog\", \"tags\": [\"art\"] } } (tags: array of strings or one comma-separated string). A flat object applies to every Tumblr channel on the post. Up to 30 images OR exactly one video per post."Input schema / properties / platformSpecific / properties / x / properties / repostIdAdded value: +{
+ "description": "With postTypeOverrides.x = 'repost': the X post URL or ID to repost (retweet).",
+ "type": "string"
+}Input schema / properties / postTypeOverrides / properties / bluesky / enumPrevious value: -[
- "post",
- "video"
-]New value: +[
+ "post",
+ "video",
+ "thread",
+ "repost"
+]Input schema / properties / postTypeOverrides / properties / mastodon / enumPrevious value: -[
- "post"
-]New value: +[
+ "post",
+ "thread",
+ "repost"
+]Input schema / properties / postTypeOverrides / properties / threads / enumPrevious value: -[
- "text",
- "image",
- "video",
- "carousel"
-]New value: +[
+ "text",
+ "image",
+ "video",
+ "carousel",
+ "repost"
+]Input schema / properties / postTypeOverrides / properties / x / enumPrevious value: -[
- "tweet",
- "video",
- "thread"
-]New value: +[
+ "tweet",
+ "video",
+ "thread",
+ "repost"
+]Input schema / properties / publishWhenApprovedAdded value: +{
+ "description": "Optional (default false). Set true on a post that waits for approval when it should go out as soon as it is approved, even if that is after its scheduled time. This is how someone who needs approval says 'publish now': status 'scheduled', scheduledAt = now, requestApproval true (or a contributor key), publishWhenApproved true. An approval arriving more than 15 minutes late then publishes immediately; with false it is approved but returned to draft for a new time. Stored only when the post ends up approvalStatus 'pending'; otherwise saved as false.",
+ "type": "boolean"
+}Input schema / properties / threadParts / descriptionPrevious value: -"Thread parts array. Required when postFormat is thread (min 2 parts)."New value: +"Thread parts array. Required when postFormat is thread (min 2 parts). EVERY part is measured against the character limit of every platform the post targets, not only the first — an over-long part is rejected with 400 VALIDATION_ERROR naming the part number, the platform and its limit. URLs count as 23 characters on X and Mastodon, their real length elsewhere."Output schema / properties / approverAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Who approved it: { id, name, image }. Null unless approvalStatus is approved."
+}Output schema / properties / assigneeAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Who is expected to act on it next: { id, name, image }. Null when nobody is."
+}Output schema / properties / authorAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Who wrote the post: { id, name, image }. Null when that account is gone."
+}get_analytics6 fields changedInput schema / properties / channelIdsAdded value: +{
+ "description": "Comma-separated channel ids to include, e.g. \"12,15\".",
+ "type": "string"
+}Input schema / properties / compareAdded value: +{
+ "description": "Also return the previous equal-length window as `previous` / `previousWindow`.",
+ "type": "boolean"
+}Input schema / properties / labelIdsAdded value: +{
+ "description": "Comma-separated label ids; a post matches when it carries ANY of them.",
+ "type": "string"
+}Input schema / properties / mediaTypeAdded value: +{
+ "description": "By the post's first media file: text (no media), image or video.",
+ "enum": [
+ "text",
+ "image",
+ "video"
+ ],
+ "type": "string"
+}Input schema / properties / platformsAdded value: +{
+ "description": "Comma-separated platform keys to include, e.g. \"x,linkedin\".",
+ "type": "string"
+}Input schema / properties / postFormatAdded value: +{
+ "description": "Only single posts or only threads.",
+ "enum": [
+ "post",
+ "thread"
+ ],
+ "type": "string"
+}get_post3 fields changedOutput schema / properties / approverAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Who approved it: { id, name, image }. Null unless approvalStatus is approved."
+}Output schema / properties / assigneeAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Who is expected to act on it next: { id, name, image }. Null when nobody is."
+}Output schema / properties / authorAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Who wrote the post: { id, name, image }. Null when that account is gone."
+}get_queue_slot2 fields changedInput schema / properties / excludePostIdAdded value: +{
+ "description": "When the slot is for rescheduling an existing post, its ID — so its current slot is not counted as booked.",
+ "type": "number"
+}Input schema / properties / positionAdded value: +{
+ "description": "\"next\" (default): the next free slot. \"end\": the slot after the last pending scheduled post, i.e. the bottom of the queue.",
+ "enum": [
+ "next",
+ "end"
+ ],
+ "type": "string"
+}list_posts3 fields changedInput schema / properties / assignedToAdded value: +{
+ "description": "Filter by who the post is assigned to: a user id, 'me' for the caller, or 'unassigned'. Orthogonal to status — a post can be scheduled AND assigned.",
+ "type": "string"
+}Input schema / properties / orderAdded value: +{
+ "description": "Direction of the timeline sort (published, else due, else created). 'desc' is the default and returns the most recent first. Use 'asc' to read what is coming NEXT — with a limit, 'desc' returns the posts scheduled furthest out, not the soonest.",
+ "enum": [
+ "asc",
+ "desc"
+ ],
+ "type": "string"
+}Output schema / properties / posts / anyOfPrevious value: -[
- {
- "items": {
- "additionalProperties": {},
- "properties": {
- "approvalStatus": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "content": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "createdAt": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "id": {
- "anyOf": [
- {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "string"
- }
- ]
- },
- {
- "type": "null"
- }
- ]
- },
- "labels": {
- "anyOf": [
- {
- "items": {
- "additionalProperties": {},
- "properties": {},
- "type": "object"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ]
- },
- "mediaFiles": {
- "anyOf": [
- {
- "items": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "string"
- },
- {
- "additionalProperties": {},
- "properties": {},
- "type": "object"
- }
- ]
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ]
- },
- "postPlatforms": {
- "anyOf": [
- {
- "items": {
- "additionalProperties": {},
- "properties": {
- "platform": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "status": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ]
- },
- "publishedAt": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "scheduledAt": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "status": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "draft, scheduled, processing, published, partial or failed."
- },
- "timezone": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "approvalStatus": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "approver": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Who approved it: { id, name, image }. Null unless approvalStatus is approved."
+ },
+ "assignee": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Who is expected to act on it next: { id, name, image }. Null when nobody is."
+ },
+ "author": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Who wrote the post: { id, name, image }. Null when that account is gone."
+ },
+ "content": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "createdAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "labels": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "mediaFiles": {
+ "anyOf": [
+ {
+ "items": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ }
+ ]
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "postPlatforms": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "platform": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "publishedAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "scheduledAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "draft, scheduled, processing, published, partial or failed."
+ },
+ "timezone": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+]publish_post3 fields changedOutput schema / properties / approverAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Who approved it: { id, name, image }. Null unless approvalStatus is approved."
+}Output schema / properties / assigneeAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Who is expected to act on it next: { id, name, image }. Null when nobody is."
+}Output schema / properties / authorAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Who wrote the post: { id, name, image }. Null when that account is gone."
+}retry_post3 fields changedOutput schema / properties / approverAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Who approved it: { id, name, image }. Null unless approvalStatus is approved."
+}Output schema / properties / assigneeAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Who is expected to act on it next: { id, name, image }. Null when nobody is."
+}Output schema / properties / authorAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Who wrote the post: { id, name, image }. Null when that account is gone."
+}update_post23 fields changedInput schema / properties / ifUnmodifiedSinceAdded value: +{
+ "description": "Optional precondition: the post's updatedAt exactly as the last read returned it. The update is refused with 409 CONFLICT if a teammate has changed the post since, rather than overwriting their version. Pass it whenever you read a post before editing it; omit it to keep the previous last-write-wins behaviour.",
+ "type": "string"
+}Input schema / properties / platformSpecific / properties / bluesky / properties / repostIdAdded value: +{
+ "description": "With postTypeOverrides.bluesky = 'repost': the bsky.app post URL (or at:// URI) to repost.",
+ "type": "string"
+}Input schema / properties / platformSpecific / properties / facebook / properties / thumbnailUrlAdded value: +{
+ "description": "Cover image URL for a video or Reel. Facebook only accepts a cover once the video exists, so it is applied after the video publishes and appears a moment after the post; a cover that cannot be fetched or that Facebook rejects leaves the video published with Facebook's own chosen frame rather than failing the post.",
+ "type": "string"
+}Input schema / properties / platformSpecific / properties / instagram / properties / collaborators / descriptionAdded value: +"Comma-separated Instagram usernames (no leading @) tagged as co-authors. Applies with postTypeOverrides.instagram of 'feed_photo', 'feed_video', 'reel' or 'carousel' — on a carousel the co-authors are set on the carousel itself, not on its individual items. Ignored on 'story', which has no co-author concept."Input schema / properties / platformSpecific / properties / instagram / properties / coverUrlAdded value: +{
+ "description": "Cover image URL for a video or Reel. Takes precedence over thumbnailTimestamp: Instagram accepts one or the other and rejects a request carrying both, so only this one is forwarded when both are sent.",
+ "type": "string"
+}Input schema / properties / platformSpecific / properties / instagram / properties / graduationStrategy / descriptionAdded value: +"How a trial reel becomes a normal one: 'manual' (the creator releases it) or 'auto' (released automatically if it performs well). Default 'manual'. Ignored unless trialReel is true."Input schema / properties / platformSpecific / properties / instagram / properties / thumbnailTimestamp / descriptionAdded value: +"Cover frame for a video or Reel, in seconds from the start. Applies to postTypeOverrides.instagram of 'feed_video' or 'reel'. Ignored when coverUrl is also set."Input schema / properties / platformSpecific / properties / instagram / properties / trialReel / descriptionAdded value: +"Publish as a trial reel, shown to people who do not follow the account first. Only takes effect with postTypeOverrides.instagram of 'reel' — a 'feed_video' publishes as an ordinary reel and this is ignored, even though both use the same underlying reel container."Input schema / properties / platformSpecific / properties / mastodon / properties / repostIdAdded value: +{
+ "description": "With postTypeOverrides.mastodon = 'repost': the status URL or ID to boost.",
+ "type": "string"
+}Input schema / properties / platformSpecific / properties / threads / properties / locationIdAdded value: +{
+ "description": "Numeric place ID from get_channel_options with a `q` search on a Threads channel. Only works once the channel has granted location tagging.",
+ "type": "string"
+}Input schema / properties / platformSpecific / properties / threads / properties / repostIdAdded value: +{
+ "description": "With postTypeOverrides.threads = 'repost': the numeric ID of the Threads post to repost (Threads links cannot be used; the ID of a post published through BulkPublish is in get_post's platforms[].platformPostId).",
+ "type": "string"
+}Input schema / properties / platformSpecific / properties / threads / properties / topicTagAdded value: +{
+ "description": "One topic tag for the post, without a leading '#'. Must not contain periods or ampersands.",
+ "type": "string"
+}Input schema / properties / platformSpecific / properties / tiktok / properties / thumbnailTimestamp / descriptionAdded value: +"Cover frame for the video, in seconds from the start."Input schema / properties / platformSpecific / properties / tumblr / descriptionPrevious value: -"Tumblr options, nested under the BulkPublish channel id: { \"12\": { \"blogName\": \"myblog\", \"tags\": [\"art\"] } }. A flat object applies to every Tumblr channel on the post. Up to 30 images OR exactly one video per post."New value: +"Tumblr options, nested under the BulkPublish channel id: { \"12\": { \"blogName\": \"myblog\", \"tags\": [\"art\"] } } (tags: array of strings or one comma-separated string). A flat object applies to every Tumblr channel on the post. Up to 30 images OR exactly one video per post."Input schema / properties / platformSpecific / properties / x / properties / repostIdAdded value: +{
+ "description": "With postTypeOverrides.x = 'repost': the X post URL or ID to repost (retweet).",
+ "type": "string"
+}Input schema / properties / postTypeOverrides / properties / bluesky / enumPrevious value: -[
- "post",
- "video"
-]New value: +[
+ "post",
+ "video",
+ "thread",
+ "repost"
+]Input schema / properties / postTypeOverrides / properties / mastodon / enumPrevious value: -[
- "post"
-]New value: +[
+ "post",
+ "thread",
+ "repost"
+]Input schema / properties / postTypeOverrides / properties / threads / enumPrevious value: -[
- "text",
- "image",
- "video",
- "carousel"
-]New value: +[
+ "text",
+ "image",
+ "video",
+ "carousel",
+ "repost"
+]Input schema / properties / postTypeOverrides / properties / x / enumPrevious value: -[
- "tweet",
- "video",
- "thread"
-]New value: +[
+ "tweet",
+ "video",
+ "thread",
+ "repost"
+]Input schema / properties / publishWhenApprovedAdded value: +{
+ "description": "Optional. Set true to have the post go out as soon as it is approved, even after its scheduled time (see create_post). An explicit value is stored while the post waits for approval. Omitted, it is kept, except that sending a different scheduledAt clears it to false, and it is always false once the post is no longer approvalStatus 'pending'.",
+ "type": "boolean"
+}Output schema / properties / approverAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Who approved it: { id, name, image }. Null unless approvalStatus is approved."
+}Output schema / properties / assigneeAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Who is expected to act on it next: { id, name, image }. Null when nobody is."
+}Output schema / properties / authorAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Who wrote the post: { id, name, image }. Null when that account is gone."
+}create_post1 field changedOutput schema / properties / mediaFiles / anyOfPrevious value: -[
- {
- "items": {
- "additionalProperties": {},
- "properties": {},
- "type": "object"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "items": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ }
+ ]
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+]get_post1 field changedOutput schema / properties / mediaFiles / anyOfPrevious value: -[
- {
- "items": {
- "additionalProperties": {},
- "properties": {},
- "type": "object"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "items": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ }
+ ]
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+]list_posts1 field changedOutput schema / properties / posts / anyOfPrevious value: -[
- {
- "items": {
- "additionalProperties": {},
- "properties": {
- "approvalStatus": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "content": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "createdAt": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "id": {
- "anyOf": [
- {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "string"
- }
- ]
- },
- {
- "type": "null"
- }
- ]
- },
- "labels": {
- "anyOf": [
- {
- "items": {
- "additionalProperties": {},
- "properties": {},
- "type": "object"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ]
- },
- "mediaFiles": {
- "anyOf": [
- {
- "items": {
- "additionalProperties": {},
- "properties": {},
- "type": "object"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ]
- },
- "postPlatforms": {
- "anyOf": [
- {
- "items": {
- "additionalProperties": {},
- "properties": {
- "platform": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "status": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ]
- },
- "publishedAt": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "scheduledAt": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "status": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "draft, scheduled, processing, published, partial or failed."
- },
- "timezone": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "approvalStatus": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "content": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "createdAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "labels": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "mediaFiles": {
+ "anyOf": [
+ {
+ "items": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ }
+ ]
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "postPlatforms": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "platform": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "publishedAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "scheduledAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "draft, scheduled, processing, published, partial or failed."
+ },
+ "timezone": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+]publish_post1 field changedOutput schema / properties / mediaFiles / anyOfPrevious value: -[
- {
- "items": {
- "additionalProperties": {},
- "properties": {},
- "type": "object"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "items": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ }
+ ]
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+]retry_post1 field changedOutput schema / properties / mediaFiles / anyOfPrevious value: -[
- {
- "items": {
- "additionalProperties": {},
- "properties": {},
- "type": "object"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "items": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ }
+ ]
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+]update_post1 field changedOutput schema / properties / mediaFiles / anyOfPrevious value: -[
- {
- "items": {
- "additionalProperties": {},
- "properties": {},
- "type": "object"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "items": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ }
+ ]
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+]create_media_upload1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "expiresIn": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "r2Key": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "uploadUrl": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+}create_post1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "approvalStatus": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "content": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "createdAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "labels": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "mediaFiles": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "postPlatforms": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "platform": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "publishedAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "scheduledAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "draft, scheduled, processing, published, partial or failed."
+ },
+ "timezone": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+}delete_post1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "success": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+}finalize_media_upload1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "file": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {
+ "filename": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "url": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+}get_analytics1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "byDay": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "byPlatform": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "failed": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "from": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "partial": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "previous": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "previousWindow": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "published": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "publishedTimes": {
+ "anyOf": [
+ {
+ "items": {},
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "scheduled": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "to": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "totalPosts": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+}get_post1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "approvalStatus": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "content": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "createdAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "labels": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "mediaFiles": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "postPlatforms": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "platform": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "publishedAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "scheduledAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "draft, scheduled, processing, published, partial or failed."
+ },
+ "timezone": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+}get_post_metrics1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "platforms": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "platform": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "postId": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "totals": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+}get_queue_slot1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "dayLabel": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Human label, e.g. \"Today\" or \"Wed, Feb 14\"."
+ },
+ "scheduledAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "ISO timestamp of the next free slot."
+ }
+ },
+ "type": "object"
+}list_channels1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "capabilities": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Whether the caller may create, publish or approve posts."
+ },
+ "channels": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "accountName": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "active": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "channelId": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "platform": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+}list_media1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "files": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "filename": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "mimeType": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "sizeBytes": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "url": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "limit": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "page": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "total": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+}list_posts1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "limit": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "page": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "posts": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "approvalStatus": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "content": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "createdAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "labels": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "mediaFiles": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "postPlatforms": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "platform": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "publishedAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "scheduledAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "draft, scheduled, processing, published, partial or failed."
+ },
+ "timezone": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "total": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "totalPages": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+}publish_post1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "approvalStatus": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "content": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "createdAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "labels": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "mediaFiles": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "postPlatforms": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "platform": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "publishedAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "scheduledAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "draft, scheduled, processing, published, partial or failed."
+ },
+ "timezone": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+}retry_post1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "approvalStatus": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "content": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "createdAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "labels": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "mediaFiles": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "postPlatforms": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "platform": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "publishedAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "retriedCount": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "How many destinations were retried."
+ },
+ "scheduledAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "skippedMaxRetries": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Destinations skipped for hitting the retry ceiling."
+ },
+ "status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "draft, scheduled, processing, published, partial or failed."
+ },
+ "timezone": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+}update_post1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "approvalStatus": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "content": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "createdAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "labels": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "mediaFiles": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "postPlatforms": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "platform": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "publishedAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "scheduledAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "draft, scheduled, processing, published, partial or failed."
+ },
+ "timezone": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+}upload_media1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "file": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "filename": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "mimeType": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "sizeBytes": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "url": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+}abort_multipart_uploadapprove_postbulk_postscomplete_multipart_uploadcreate_channel_setcreate_labelcreate_multipart_uploadcreate_rss_feedcreate_scheduledelete_channel_setdelete_labeldelete_mediadelete_rss_feeddelete_scheduleget_channel_healthget_channel_optionsget_mediaget_quota_usagelist_channel_setslist_labelslist_platformslist_rss_feedslist_schedulespublish_storyreject_postsearch_mentionsupdate_channel_setupdate_labelupdate_rss_feedupdate_scheduleview_quotaabort_multipart_uploadapprove_postbulk_postscomplete_multipart_uploadcompose_postcreate_channel_setcreate_labelcreate_media_uploadcreate_multipart_uploadcreate_postcreate_rss_feedcreate_scheduledelete_channel_setdelete_labeldelete_mediadelete_postdelete_rss_feeddelete_schedulefinalize_media_uploadget_analyticsget_channel_healthget_channel_optionsget_mediaget_postget_post_metricsget_queue_slotget_quota_usagelist_channel_setslist_channelslist_labelslist_medialist_platformslist_postslist_rss_feedslist_schedulespublish_postpublish_storyreject_postretry_postsearch_mentionsupdate_channel_setupdate_labelupdate_postupdate_rss_feedupdate_scheduleupload_mediaview_analyticsview_channelsview_mediaview_postsview_quota
Add one secure layer between your agents and this server.