AI agents can create, schedule, publish, and analyze social content through Postly.
Scored across 21 tools
Most tools target a clearly distinct resource+action (get_post vs get_post_status vs get_post_analytics are well-separated). A few pairs overlap: list_posts vs list_scheduled_posts, list_social_accounts vs resolve_publishing_targets, and list_analytics_sources vs list_social_accounts could be confused, though descriptions help distinguish them.
Every tool follows the postly_verb_noun pattern with a consistent prefix and snake_case throughout (list_posts, create_post, upload_media, get_post_analytics). No mixed conventions or casing deviations.
21 tools is on the heavier side, but each maps to a distinct facet of a social/email publishing platform (posts, scheduling, analytics, media, targets, workspaces). The surface is well-scoped rather than padded, though a couple of pairs could be consolidated.
Strong coverage: full post CRUD, scheduling, validation, channel schemas, target resolution, media upload (single and batch), and multiple analytics/activity endpoints. Minor gaps exist—no media deletion or engagement/comment management—but core publishing workflows are complete.
Turns a user-written Postly question into a safe, explicit plan of existing MCP tools and identifies any missing context. Use this first for free-form requests; then call the planned tools. It never runs raw database or SQL queries.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The user's own natural-language question or requested outcome. | |
| post_id | No | Optional known Postly post ID. | |
| platform | No | Optional analytics platform. | |
| channel_id | No | Optional analytics channel/source ID. | |
| workspace_id | No | Optional known Postly workspace ID. | |
| relative_range | No | Optional date phrase such as today, this_week, or last_30_days. |
| Name | Required | Description |
|---|---|---|
| query | No | |
| intent | No | |
| tool_plan | No | |
| missing_context | No | |
| safety_boundary | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the agent knows this is a safe, non-mutating operation. The description adds that it 'never runs raw database or SQL queries' and that it produces a 'safe' plan—useful context reinforcing the read-only nature and output type. However, it doesn't describe what happens on missing context (does it return a list of required fields? does it fail?). Annotations cover the safety profile well, so the description adds moderate value.
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 exactly two sentences: the first states purpose and usage, the second states a key limitation. It is front-loaded with the main purpose and immediately instructs the agent on next steps. No wasted words; every phrase carries information.
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 is a planner used before other calls; its behavior is inherently simple (take a question, output a plan). With an output schema present (not shown in this prompt but implied by 'Has output schema: true'), the agent likely sees the plan structure elsewhere. The description covers safety, purpose, usage, and key limitations. It might benefit from stating what 'missing context' looks like in the output, but given the output schema and annotations, what's here is sufficient 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?
Schema description coverage is 100%; every parameter, including all five optional ones, has a brief description. The description of the 'query' parameter ('The user's own natural-language question or requested outcome') adds meaning beyond just a generic 'text' field, clarifying that it's the raw user input. The optional parameters are clearly contextual hints. Given high schema coverage, the description's parameter handling is adequate and not redundant.
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 ('Craft'), a resource ('Postly query'), and an outcome: converting a free-form user question into a plan of existing MCP tools, while identifying missing context. It clearly distinguishes itself from the sibling tools (which are all direct operations), and states what it does NOT do—run raw database or SQL queries.
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 first for free-form requests; then call the planned tools.' This gives clear when-to-use guidance. It doesn't explicitly say when NOT to use it (e.g., when a direct tool call is already obvious), but the instruction to use it first for free-form requests, plus its role as a planner, provides strong context for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates, queues, or schedules a Postly post for social or email/newsletter targets. Accepts content, target selections, schedules, platform settings, and client-provided media references for import in the same action. Returns the mutation result, platform readiness, blockers, and any required follow-up data.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| media | No | Already-hosted media objects for the post. Use the media_file fields instead for attached, generated, selected, local, base64, or temporary media that Postly must import during the create or update action. | |
| labels | No | ||
| media_file | No | Client-provided file reference or temporary URL for the first attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object. | |
| campaign_id | No | Optional campaign ID in the same workspace. Campaign content approval and workspace post approval still apply. Omit to preserve the association on update. | |
| media_file_2 | No | Client-provided file reference or temporary URL for the number 2 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object. | |
| media_file_3 | No | Client-provided file reference or temporary URL for the number 3 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object. | |
| media_file_4 | No | Client-provided file reference or temporary URL for the number 4 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object. | |
| media_file_5 | No | Client-provided file reference or temporary URL for the number 5 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object. | |
| media_file_6 | No | Client-provided file reference or temporary URL for the number 6 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object. | |
| media_file_7 | No | Client-provided file reference or temporary URL for the number 7 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object. | |
| media_file_8 | No | Client-provided file reference or temporary URL for the number 8 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object. | |
| media_file_9 | No | Client-provided file reference or temporary URL for the number 9 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object. | |
| workspace_id | Yes | Postly workspace ID. | |
| email_subject | No | Subject line required when targeting email/newsletter channels. | |
| first_comment | No | ||
| media_file_10 | No | Client-provided file reference or temporary URL for the number 10 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object. | |
| media_uploads | No | Optional inline upload specs for agents that can supply public URLs, temporary URLs, base64, or data URLs. Postly imports these assets and appends them to media before creating or updating the post. | |
| workspace_ids | No | Optional list of Postly workspace IDs. Use instead of workspace_id when creating the same post in multiple workspaces. | |
| audience_group | No | Audience group ID or IDs. Do not combine with target_platforms. You may also pass a single string on clients that support that shorthand. | |
| custom_replies | No | Shared first comment or follow-up sequence for supported selected platforms. Text and links only. Platform custom replies replace shared replies. Omit on update to preserve; [] clears shared replies. | |
| platform_posts | No | Platform-specific overrides. Each item should include identifier and settings. Call postly_get_channel_schema for each selected platform to see required settings and simple capture guidance. | |
| email_targeting | No | Optional advanced email targeting map keyed by email integration ID. Each value is a resource ID, a resource object with id, or an array of those. Usually not needed when using email channel_id values returned by postly_list_social_accounts. Property values may use multiple equivalent input shapes; the server normalizes them. | |
| media_alt_texts | No | Optional alt text values aligned with media_file, media_file_2, and later media_file fields. | |
| one_off_schedule | No | ||
| target_platforms | No | Social platform names, email/newsletter, provider names, or channel IDs. Use "all" to target all connected publishing targets in the workspace. Email targets require email_subject and text. You may also pass a single string on clients that support that shorthand. | |
| publishing_preset | No | Optional workspace publishing preset name. Use instead of publishing_preset_id. | |
| custom_reply_modes | No | Per-platform reply selection: shared, custom, or off. Omit to preserve existing behavior. Custom settings replace rather than append. Property values may use multiple equivalent input shapes; the server normalizes them. | |
| email_preview_text | No | Optional short preview text for email/newsletter delivery. | |
| recurring_schedule | No | ||
| publishing_preset_id | No | Optional workspace publishing preset ID. When omitted, Postly uses the preset named Default or the oldest saved preset. | |
| use_publishing_presets | No | Apply the workspace publishing preset. Defaults to true. Set false only when the user explicitly wants platform defaults instead. |
| Name | Required | Description |
|---|---|---|
| code | No | |
| data | No | |
| prompt | No | |
| status | No | |
| message | No | |
| next_steps | No | |
| post_mutated | No | |
| agent_guidance | No | |
| ready_platforms | No | |
| blocked_platforms | No | |
| requires_user_input | No | |
| retry_after_seconds | No | |
| media_upload_results | No | |
| missing_requirements | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety bar is covered. The description adds genuine value beyond that by noting it 'returns the mutation result, platform readiness, blockers, and any required follow-up data' – signalling that a call can partially succeed with blockers rather than being all-or-nothing. It stops short of stating that retries create duplicates or that workspace post approval may gate publication (both only appear buried in 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, front-loaded with the verb and modes, with no boilerplate or repetition. The middle sentence is a partial parameter enumeration that adds some value (batch media import) but is the least essential part.
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?
An output schema exists and annotations cover the safety profile, so much is legitimately offloaded. However, for a 32-parameter destructive, non-idempotent, open-world mutation with nested platform overrides, the description omits the workflow context an agent most needs: whether to validate or fetch channel schemas first, and that publication may be blocked by approvals.
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 84%, so the schema already carries most parameter meaning, and this is the correct baseline. The description adds light framing – 'content, target selections, schedules, platform settings, and client-provided media references for import in the same action' – which conveys the media-import-in-one-call behaviour, but it does not clarify the media vs. media_file vs. media_uploads distinction or the workspace_id vs. workspace_ids choice, which are the highest-risk ambiguities in this 32-param surface.
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?
States a specific verb set (creates, queues, schedules) and a specific resource (Postly post) with the target domain (social, email/newsletter). It's clearly distinguishable from read-side siblings like postly_get_post or postly_list_scheduled_posts, but it never names the nearest alternative (postly_update_post) or states the create-vs-update boundary explicitly.
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?
Usage is only implied by the verb 'creates' – there is no explicit when-to-use/when-not guidance, no statement of prerequisites (connected accounts, approval flows), and no pointer to postly_validate_post or postly_get_channel_schema, even though those siblings exist and the schema itself references the latter. The agent must infer the workflow from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently removes only the post in Postly. Does not delete or recall live content on any social platform. For live removal, use Delete on Platforms in the dashboard where supported before deleting the post, or remove content directly on the platform. Requires a Postly post ID, not a provider post ID.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | Postly post ID. |
| Name | Required | Description |
|---|---|---|
| code | No | |
| data | No | |
| prompt | No | |
| status | No | |
| message | No | |
| next_steps | No | |
| post_mutated | No | |
| agent_guidance | No | |
| ready_platforms | No | |
| blocked_platforms | No | |
| requires_user_input | No | |
| retry_after_seconds | No | |
| media_upload_results | No | |
| missing_requirements | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is largely covered structurally. The description adds genuinely useful scope context — that deletion is Postly-only and does not recall live platform content — but a 'destination' scope note is the main addition beyond the annotation set.
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 doing distinct work: what gets deleted, what does not, and what ID is required. The scope constraint and alternative path are front-loaded rather than buried.
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?
Output schema exists, so return values need no explanation. For a destructive single-parameter tool, the description covers scope, irreversibility implication, prerequisite ID type, and the alternative path — nothing an agent needs to invoke 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 coverage is 100% with a single clearly described parameter, so the baseline is 3. The description earns above baseline by disambiguating the identifier: 'Requires a Postly post ID, not a provider post ID,' which prevents an agent from passing the wrong ID namespace.
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?
States a specific verb (delete) and resource (post), and immediately scopes it: 'Permanently removes only the post in Postly.' This separates it from siblings like postly_update_post and from any platform-level removal, so an agent can distinguish it without opening schemas.
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 the agent when not to expect this tool to work (live platform content is untouched) and routes to alternatives ('use Delete on Platforms in the dashboard... or remove content directly on the platform'). It also states the required prerequisite ID type, which prevents a common wrong invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches analytics for a connected Postly source such as a social account, page, profile, location, or channel. Returns metrics for the requested source and date range.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | Optional ISO-8601 start date/time for platforms that support ranges. | |
| until | No | Optional ISO-8601 end date/time for platforms that support ranges. | |
| platform | Yes | Analytics platform identifier returned by postly_list_analytics_sources, such as instagram, facebook, linkedin, pinterest, youtube, googleMyBusiness, google_my_business, or x. | |
| channel_id | Yes | Analytics source channel_id returned by postly_list_analytics_sources. | |
| workspace_id | Yes | Postly workspace ID. |
| Name | Required | Description |
|---|---|---|
| code | No | |
| data | No | |
| message | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, idempotent, and non-destructive behavior. The description adds context that it supports date ranges and returns metrics for various source types, but does not disclose additional behaviors like pagination, rate limits, or platform-specific nuances. This is consistent with annotations and adds some value, but not significantly beyond them.
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 sentences, front-loaded with 'Fetches analytics', and every word earns its place. It is efficient and easy to scan.
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 that annotations cover safety and an output schema exists to document return values, the description is adequately complete. It covers the core purpose, source types, and date range support. It does not mention optional parameters or platform variations, but these are handled in the schema, so no significant gaps remain.
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 provides examples of source types ('social account, page, profile, location, or channel') that loosely map to platform and channel_id, but these are already elaborated in the schema's parameter descriptions. The description does not add substantive 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 clearly states a specific verb ('Fetches') and resource ('analytics for a connected Postly source'), and it distinguishes from sibling tools like postly_get_post_analytics by specifying 'social account, page, profile, location, or channel' rather than a post. It also implies a contrast with postly_list_analytics_sources by returning metrics rather than listing sources.
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 clear context about the intended input (a connected Postly source) and mentions date range filtering, which helps an agent understand when to use it. However, it does not explicitly state exclusions or alternatives (e.g., 'for post-level analytics, use postly_get_post_analytics'), so it stops short of fully explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns platform rules, character and media limits, required settings, safe defaults, and capture requirements for a supported Postly publishing channel. Use it before creating or scheduling content when the channel requirements are not already known.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Platform identifier such as x, linkedin, instagram, telegram, facebook, threads, bluesky, pinterest, youtube, tiktok, or google_my_business. |
| Name | Required | Description |
|---|---|---|
| schema | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds substantive behavioral context by enumerating the categories of information returned (platform rules, limits, settings, defaults, capture requirements), which goes beyond the abstract 'Get Channel Schema' title and 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 two sentences, front-loaded with the action and resource, and every clause adds value. The first sentence states functionality, the second sentence provides usage guidance. There is no fluff 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 is simple (one parameter), has a rich output schema, and annotations cover safety. The description fully covers the return content categories and the appropriate use case. There is no missing information that would prevent an agent from using 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?
The single parameter 'platform' is fully documented in the input schema, including a list of allowed identifier values (x, linkedin, etc.). The description does not add any additional meaning or context about the parameter beyond what the schema already provides, so the schema carries the full burden. 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 begins with a specific verb ('Returns') and clearly identifies the resource (platform rules, character and media limits, required settings, safe defaults, capture requirements) as well as the target ('supported Postly publishing channel'). This distinguishes it from sibling tools like create/delete/update/validate, which perform different actions.
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 it before creating or scheduling content when the channel requirements are not already known.' It provides clear context but does not mention when not to use it or name alternative tools (e.g., postly_validate_post), so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves sanitized details for a specific Postly post.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | Postly post ID. |
| Name | Required | Description |
|---|---|---|
| post | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds 'sanitized' which indicates the returned details are filtered, providing additional behavioral context beyond the annotations. It does not contradict 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 clear sentence, front-loaded with the action and object, with no unnecessary words.
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 is simple with one parameter and an output schema, so the description need not explain return values. It adequately states the purpose and the key qualifier 'sanitized,' but it doesn't mention error conditions or permission requirements; however, these are less critical given the read-only annotations. Overall it is sufficient for the tool's simplicity.
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 single parameter post_id, and the description does not add syntax or format details beyond that. Since schema coverage is 100%, the baseline is 3.
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 the specific verb 'Retrieves' and the resource 'sanitized details for a specific Postly post.' It distinguishes from sibling tools like postly_get_post_analytics and postly_get_post_status by focusing on post details rather than analytics or status.
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 no explicit guidance on when to use this tool instead of alternatives like get_post_analytics or get_post_status. The intent is implied through the word 'details,' but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches analytics for a published Postly post on a supported platform. Returns metrics for the requested post and analytics source.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | Postly post ID. | |
| platform | Yes | Analytics platform identifier returned by postly_list_analytics_sources, such as instagram, facebook, linkedin, pinterest, youtube, googleMyBusiness, google_my_business, or x. | |
| channel_id | Yes | Analytics source channel_id returned by postly_list_analytics_sources. | |
| workspace_id | Yes | Postly workspace ID. |
| Name | Required | Description |
|---|---|---|
| code | No | |
| data | No | |
| message | No |
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 minimal behavioral context: it specifies the post must be published and the platform must be supported. It does not discuss rate limits, auth, or error conditions, but given annotations, the bar is lower and this mild addition is acceptable.
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 concise sentences with no redundant information. It front-loads the core action and result, making it easy to scan. 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 read-only analytics tool with a full output schema and complete parameter documentation, the description is sufficiently complete. It identifies the post-level scope and supported platforms, which helps selection. It could add a note about needing prior setup via list_analytics_sources, but the schema parameter descriptions already cover that linkage, so the overall context is adequate.
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 does not add additional parameter-level meaning beyond what the schema already provides; it only mentions 'analytics source' which loosely references channel_id and platform. Since the schema already documents parameters thoroughly, the description adds little extra value.
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 fetches analytics for a published Postly post, using a specific verb ('Fetches') and resource ('analytics for a published Postly post'). It also mentions returning metrics, and the title 'Get Post Analytics' aligns with this. This distinguishes it from sibling tools like account analytics or publishing activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for post-level analytics but does not explicitly contrast with alternatives like postly_get_account_analytics. It states 'for a published Postly post on a supported platform,' giving context, but lacks explicit when-to-use or when-not-to-use guidance. Sibling names help, but the description itself offers only implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves the current publishing status and delivery counts for a specific Postly post.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | Postly post ID. |
| Name | Required | Description |
|---|---|---|
| status | No | |
| post_id | No | |
| delivery_results | No | |
| effective_status | No | |
| draft_delivery_count | No | |
| failed_delivery_count | No | |
| published_delivery_count | 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 the 'delivery counts' detail, but it does not disclose any additional behavioral traits such as response shape, latency, or relationship to analytics data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence states exactly what is retrieved and for which resource. No filler or redundant restating of the title.
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?
With one well-documented parameter, strong annotations, and an output schema present, the description is sufficient for an agent to invoke the tool. Nothing essential to the call itself 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% and the post_id parameter is already documented as 'Postly post ID.' The description adds no extra 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 uses a clear verb ('Retrieves') with a specific resource ('current publishing status and delivery counts for a specific Postly post'). It conveys what the tool does, but it does not explicitly distinguish it from siblings like postly_get_post or postly_get_post_analytics, leaving some potential 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?
There is no guidance on when to use this tool versus alternatives. It does not mention scenarios like checking after publishing, polling for delivery, or why one would choose this over postly_get_post_analytics or postly_get_publishing_activity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns publishing activity for a requested date or time range, with actual published delivery counts separated from queued and processing posts.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Optional exact local date in YYYY-MM-DD format. The timezone argument determines the local day. | |
| skip | No | ||
| limit | No | ||
| timezone | No | Optional IANA timezone for relative_range or date, for example Africa/Lagos or America/New_York. Defaults to the account timezone or UTC. | |
| workspace_id | No | Optional workspace ID. Omit to search accessible workspaces. | |
| activity_from | No | Optional inclusive ISO-8601 activity start boundary. Must be used with activity_until. | |
| activity_until | No | Optional exclusive ISO-8601 activity end boundary. Must be used with activity_from. | |
| published_from | No | Alias for activity_from when the user asks about published posts. | |
| relative_range | No | Natural date window. Use "today" or "yesterday" when a user asks how many posts were published on a local day. Defaults to next_7_days when no date or range is provided. | |
| scheduled_from | No | Optional inclusive ISO-8601 start boundary. Must be used with scheduled_until. | |
| organization_id | No | Optional organization ID. Use this to limit the search before choosing a workspace. | |
| published_until | No | Alias for activity_until when the user asks about published posts. | |
| scheduled_until | No | Optional exclusive ISO-8601 end boundary. Must be used with scheduled_from. |
| Name | Required | Description |
|---|---|---|
| posts | No | |
| window | No | |
| summary | No | |
| total_count | No | |
| returned_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that this is a safe, read-only, idempotent operation. The description adds a useful behavioral detail about separating published counts from queued/processing posts, but it does not disclose pagination behavior, default time range, or timezone handling, so it only partially adds value beyond 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, front-loaded sentence that immediately states the purpose and adds a key detail about output composition. It is concise, with no unnecessary words, and is 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?
Given the tool's 13 optional parameters, a more detailed description could clarify the various filtering dimensions. However, the rich input schema (with detailed property descriptions) and the presence of an output schema largely compensate, and the description captures the core purpose adequately for an agent to formulate a request.
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 has 85% parameter description coverage, with detailed descriptions for options like relative_range and timezone. The tool description itself adds no parameter-specific meaning, so it earns the baseline 3 for relying on the schema to document parameters.
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 ('Returns') and clearly identifies the resource ('publishing activity'), further specifying that it separates published delivery counts from queued/processing posts. This distinguishes it from sibling tools like postly_get_post_status or postly_list_posts, which focus on individual post states rather than aggregate activity counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving activity summaries over a date/time range, but it does not explicitly state when to prefer this tool over alternatives or mention exclusions. It lacks direct guidance on choosing between this and related tools such as postly_get_account_analytics or postly_list_scheduled_posts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists connected accounts, pages, profiles, locations, and channels that support analytics for one workspace or every accessible workspace. Returns sources grouped by workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | No | Optional Postly workspace ID. Omit to scan all accessible workspaces. | |
| organization_id | No | Optional organization ID to limit the workspace scan. |
| Name | Required | Description |
|---|---|---|
| workspaces | 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 the safety profile. The description adds context about the scope (one workspace vs all) and grouping, but these are largely reflected in the schema and output schema. It does not disclose additional behavioral traits beyond 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 concise: two sentences, front-loaded with 'Lists', and every sentence adds value without unnecessary 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 is simple with two optional parameters and has a full output schema and comprehensive annotations. The description, together with the schema and annotations, provides a complete understanding of the tool's purpose, scope, and safety.
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?
Both parameters are fully described in the input schema (100% coverage). The description aligns with the schema's parameter meanings but does not add extra semantic detail 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 clearly states the tool lists connected accounts, pages, profiles, locations, and channels that support analytics, for one or all accessible workspaces. It distinguishes from siblings like list_social_accounts by explicitly focusing on analytics sources and mentions grouping by workspace.
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 clear context for usage: it lists analytics sources and supports workspace filtering or scanning all workspaces. However, it does not explicitly mention when not to use this tool or name alternative tools, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists durable stored media, or recovers one upload by idempotency_key. Recovery distinguishes processing, completed, and unknown. Respect retry_after_seconds; use media only when storage confirms completion. Requires media.read.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of files to return. | |
| offset | No | Number of stored files to skip. | |
| idempotency_key | No | Recover a specific upload using its returned key instead of listing files. An unknown result may still be in progress; retry uploads only with this same key. |
| Name | Required | Description |
|---|---|---|
| code | No | |
| files | No | |
| status | No | |
| message | No | |
| pagination | No | |
| media_library | No | |
| idempotency_key | No | |
| retry_after_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description still adds real value: the recovery state vocabulary (processing/completed/unknown), retry_after_seconds behavior, and the 'unknown may still be in progress' nuance. The media.read permission requirement is also disclosed, which annotations do not cover.
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?
Four tight sentences with the primary list behavior and the recovery mode front-loaded, and no wasted words. The telegraphic 'Respect retry_after_seconds' phrase is slightly compressed but still 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?
With an output schema present, return values need not be explained, and the description covers both modes, recovery states, retry behavior, and the auth requirement. Pagination semantics for limit/offset are left to the schema, a minor gap for a list tool.
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 limit, offset, and idempotency_key are already documented in the schema, setting the baseline at 3. The description echoes the idempotency_key recovery semantics and references retry_after_seconds (an output field) but adds no format or syntax detail 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?
States a specific verb and resource ('Lists durable stored media') and adds a clearly distinct second mode ('recovers one upload by idempotency_key'). This separates it from the upload siblings (postly_upload_media, postly_upload_media_batch), though no sibling is named explicitly, so it falls just short of a 5.
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?
'use media only when storage confirms completion' and the idempotency_key recovery path give conditional usage rules beyond the schema. However there is no explicit when-to-use-vs-alternatives statement (e.g. vs postly_get_post or the upload tools), so guidance is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists Postly organizations available to the authenticated connection. Returns organization identifiers and metadata for workspace selection.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| organizations | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint, and openWorldHint. The description adds useful context about the return value ('organization identifiers and metadata') and the scope ('authenticated connection'), but does not go into details like pagination or data volume. Since annotations cover the safety profile, this is adequate but not rich.
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, front-loaded with the primary action ('Lists Postly organizations') and no filler. Every word contributes to understanding the tool's function and output.
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 parameterless list operation with an output schema and comprehensive annotations, the description fully covers what the tool does, what it returns, and why it is useful. There are no gaps in 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?
There are zero parameters and schema coverage is 100%, so the description need not explain any inputs. Baseline for 0 params is 4; the description adds value by stating what the list contains and its purpose, which is sufficient.
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 ('Lists') and resource ('Postly organizations available to the authenticated connection'), and adds the purpose 'for workspace selection'. This clearly distinguishes it from siblings like list_workspaces by the level of the resource (organizations vs. workspaces).
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 states the context 'available to the authenticated connection' and implies usage for workspace selection, but does not explicitly name alternatives or exclusions. However, the purpose is clear enough that an agent can infer when to use this over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists recent Postly posts, optionally filtered by workspace and status. Returns sanitized post summaries for the authenticated connection.
| Name | Required | Description | Default |
|---|---|---|---|
| skip | No | ||
| limit | No | ||
| status | No | Optional status such as draft, scheduled, queued, processing, pending_approval, or unknown. | |
| workspace_id | No | Optional Postly workspace ID. |
| Name | Required | Description |
|---|---|---|
| posts | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only and idempotent. Description adds that results are sanitized and scoped to the authenticated connection, providing useful behavioral context 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?
A single sentence that is front-loaded with the action, then states optional filters and return type. No unnecessary words, perfectly concise.
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?
With an output schema present and strong annotations, the description covers purpose, filters, and the scope of results. It's complete for a list operation, and the mention of sanitized summaries adds useful 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 covers status and workspace_id with descriptions. Description reinforces these as filters but does not clarify skip/limit semantics; however, their names and defaults are self-explanatory. With 50% schema coverage, the description partially compensates but not fully.
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 lists recent Postly posts with optional filters, using a specific verb and resource. It distinguishes from siblings like postly_get_post and postly_list_scheduled_posts by emphasizing 'recent' and 'sanitized summaries'.
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?
Provides clear context: use for listing posts with optional workspace/status filters. However, it doesn't explicitly mention alternatives or when not to use it, such as for retrieving a single post or scheduled posts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists scheduled posts for a requested workspace, date, relative date window, or explicit time range. Returns the resolved window, counts, and matching post summaries.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Optional exact local date in YYYY-MM-DD format. The timezone argument determines the local day. | |
| skip | No | ||
| limit | No | ||
| timezone | No | Optional IANA timezone for relative_range or date, for example Africa/Lagos or America/New_York. Defaults to the account timezone or UTC. | |
| workspace_id | No | Optional workspace ID. Omit to search accessible workspaces. | |
| relative_range | No | Natural date window. Use "tomorrow" for requests like "How many posts do I have lined up for tomorrow?" Defaults to next_7_days when no date or range is provided. | |
| scheduled_from | No | Optional inclusive ISO-8601 start boundary. Must be used with scheduled_until. | |
| organization_id | No | Optional organization ID. Use this to limit the search before choosing a workspace. | |
| scheduled_until | No | Optional exclusive ISO-8601 end boundary. Must be used with scheduled_from. |
| Name | Required | Description |
|---|---|---|
| posts | No | |
| window | No | |
| total_count | No | |
| returned_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint false, establishing a safe read operation. The description adds value by stating the return includes the resolved window, counts, and matching post summaries, clarifying what the agent will receive. This goes beyond the annotations, though it doesn't discuss pagination or ordering.
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, front-loaded sentence that states the action, lists the key filtering options, and summarizes the output. There is no redundant or filler content, and it is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 optional parameters and an output schema, the description covers the core behavior and return concept adequately. It doesn't explain filter exclusivity or default behavior, but these are inferable from the schema and the output schema handles return details. A compact but sufficient description for a read-only listing tool.
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 78%, with detailed descriptions for most parameters (date, timezone, relative_range, scheduled_from, scheduled_until, workspace_id, organization_id). The description offers a concise high-level synthesis of the filter modes but doesn't add extra meaning for skip/limit or parameter interactions. Since the schema carries the bulk of parameter semantics, a 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 the tool lists scheduled posts and specifies multiple filtering dimensions: workspace, date, relative date window, or explicit time range. It distinguishes itself from sibling tools like postly_list_posts by targeting scheduled posts and from postly_get_post_status by indicating it returns summaries and counts.
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 makes it apparent when to use this tool: whenever you need to list scheduled posts with flexible time windows. It doesn't explicitly mention alternatives like postly_list_posts or provide exclusions, but the scope is clear enough to guide selection. Missing explicit when-not-to-use guidance prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists connected social channels and email/newsletter targets for a Postly workspace. Returns publishing target identifiers and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | Postly workspace ID. |
| Name | Required | Description |
|---|---|---|
| social_accounts | No | Connected publishing targets, including social channels and email/newsletter targets. Email targets use platform=email and can be passed by channel_id to target_platforms. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint, so the safety profile is covered. The description adds that only 'connected' targets are listed and that output includes 'identifiers and metadata,' but it does not disclose potential caveats such as pagination, ordering, or authorization requirements.
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 sentences, front-loads the primary purpose, and contains no redundant or filler content. Every phrase 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?
Given the simple one-parameter schema and the presence of an output schema, the description adequately covers the tool's behavior. It states what is listed and what is returned, so no critical information is missing for this straightforward list operation.
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 provides 100% coverage for the single parameter workspace_id with a description. The tool description does not add further meaning or context about the parameter beyond what the schema already gives, 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 clearly states it 'Lists connected social channels and email/newsletter targets for a Postly workspace' and specifies the return type. This distinguishes it from sibling tools like postly_list_posts and postly_list_workspaces by identifying the exact resource (publishing targets).
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 no guidance on when to use this tool versus alternatives, nor does it mention any exclusion scenarios or prerequisites. It simply states what the tool does, so usage context is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists Postly workspaces available to the authenticated connection, optionally filtered by organization. Returns workspace identifiers and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| organization_id | No | Optional Postly organization ID to filter by. |
| Name | Required | Description |
|---|---|---|
| workspaces | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds useful context about the authenticated connection and states that it returns workspace identifiers and metadata, which clarifies the scope. It does not mention pagination or rate limits, but for a simple list tool this is acceptable.
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 only two sentences, front-loads the action, and contains no redundant information. Every clause adds value: the authenticated connection, the optional filter, and the return type.
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 simplicity (one optional parameter, full schema coverage, and an output schema), the description adequately covers purpose, scope, and filtering. It does not need to explain return values because the output schema exists. There are no obvious gaps for an agent to correctly invoke this tool.
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 fully describes the only parameter (organization_id) with a clear description, and schema coverage is 100%. The tool description merely echoes 'optionally filtered by organization' without adding new details about format, behavior, or relationships. Therefore, 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 clearly states the action ('Lists Postly workspaces') and the resource ('workspaces available to the authenticated connection'). It also mentions the optional organization filter, which adds specificity and distinguishes it from sibling tools like list_organizations and list_social_accounts.
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 context about the authenticated connection and optional filtering, but it does not explicitly state when to use this tool over alternatives such as postly_list_organizations or postly_list_social_accounts. No exclusions or alternative tool names are mentioned, leaving the agent to infer the appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolves publishing targets by platform, organization, workspace, or name before a post is created or scheduled. Returns matching channels and workspace context.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | Optional channel/workspace/organization name fragment to match. | |
| platform | No | Optional platform identifier such as telegram, x, linkedin, instagram, facebook, threads, or bluesky. | |
| workspace_id | No | Optional workspace ID to search within. | |
| organization_id | No | Optional organization ID to search within. |
| Name | Required | Description |
|---|---|---|
| targets | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide strong safety signals: readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds minimal context about behavior beyond that, such as 'Returns matching channels and workspace context' and the pre-creation use case. It does not add details like pagination or result limits, but with annotation coverage and an output schema, the description is adequate though not particularly rich.
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 concise sentences, front-loaded with the primary action and purpose. No redundant words, and it earns its place with specific detail on resolution dimensions and output. Excellent structure and length for the complexity of 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 5 optional parameters, no required args, comprehensive annotations, and an output schema (not shown but present). The description provides a high-level summary of the output ('matching channels and workspace context') and the usage context. It does not explain default behavior with no filters (e.g., does it return all targets?), but given the output schema and annotations, the description is sufficiently complete for an agent to select and invoke the tool.
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 high (80%) since 4 of 5 parameters have descriptions. The description reinforces the parameter purposes by mentioning 'by platform, organization, workspace, or name', aligning with the query, platform, workspace_id, and organization_id fields. The 'limit' parameter lacks a description in the schema and the description does not compensate, but the name is self-explanatory. Overall, the description adds modest 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 clearly states the tool 'Resolves publishing targets by platform, organization, workspace, or name' with a specific verb and resource. It also positions the tool relative to the post lifecycle ('before a post is created or scheduled') and distinguishes it from sibling tools like create_post or list_social_accounts by focusing on resolution of targets rather than creation or general listing.
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 this tool: 'before a post is created or scheduled' and what it does (resolves targets). It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to understand this is the pre-publication target resolver, distinct from general list or creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates editable content, media, labels, social or email/newsletter targets, and schedules for an existing Postly post. Accepts client-provided media references for import in the same action and returns the mutation result, platform readiness, blockers, and any required follow-up data.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| media | No | Already-hosted media objects for the post. Use the media_file fields instead for attached, generated, selected, local, base64, or temporary media that Postly must import during the create or update action. | |
| labels | No | ||
| post_id | Yes | Postly post ID. | |
| media_file | No | Client-provided file reference or temporary URL for the first attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object. | |
| campaign_id | No | Optional campaign ID in the same workspace. Campaign content approval and workspace post approval still apply. Omit to preserve the association on update. | |
| media_file_2 | No | Client-provided file reference or temporary URL for the number 2 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object. | |
| media_file_3 | No | Client-provided file reference or temporary URL for the number 3 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object. | |
| media_file_4 | No | Client-provided file reference or temporary URL for the number 4 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object. | |
| media_file_5 | No | Client-provided file reference or temporary URL for the number 5 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object. | |
| media_file_6 | No | Client-provided file reference or temporary URL for the number 6 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object. | |
| media_file_7 | No | Client-provided file reference or temporary URL for the number 7 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object. | |
| media_file_8 | No | Client-provided file reference or temporary URL for the number 8 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object. | |
| media_file_9 | No | Client-provided file reference or temporary URL for the number 9 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object. | |
| email_subject | No | Subject line required when targeting email/newsletter channels. | |
| first_comment | No | ||
| media_file_10 | No | Client-provided file reference or temporary URL for the number 10 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object. | |
| media_uploads | No | Optional inline upload specs for agents that can supply public URLs, temporary URLs, base64, or data URLs. Postly imports these assets and appends them to media before creating or updating the post. | |
| audience_group | No | Audience group ID or IDs. Do not combine with target_platforms. You may also pass a single string on clients that support that shorthand. | |
| custom_replies | No | Shared first comment or follow-up sequence for supported selected platforms. Text and links only. Platform custom replies replace shared replies. Omit on update to preserve; [] clears shared replies. | |
| platform_posts | No | Platform-specific overrides. Each item should include identifier and settings. Call postly_get_channel_schema for each selected platform to see required settings and simple capture guidance. | |
| email_targeting | No | Optional advanced email targeting map keyed by email integration ID. Each value is a resource ID, a resource object with id, or an array of those. Usually not needed when using email channel_id values returned by postly_list_social_accounts. Property values may use multiple equivalent input shapes; the server normalizes them. | |
| media_alt_texts | No | Optional alt text values aligned with media_file, media_file_2, and later media_file fields. | |
| one_off_schedule | No | ||
| target_platforms | No | Social platform names, email/newsletter, provider names, or channel IDs. Use "all" to target all connected publishing targets in the workspace. Email targets require email_subject and text. You may also pass a single string on clients that support that shorthand. | |
| publishing_preset | No | Optional workspace publishing preset name. Use instead of publishing_preset_id. | |
| custom_reply_modes | No | Per-platform reply selection: shared, custom, or off. Omit to preserve existing behavior. Custom settings replace rather than append. Property values may use multiple equivalent input shapes; the server normalizes them. | |
| email_preview_text | No | Optional short preview text for email/newsletter delivery. | |
| recurring_schedule | No | ||
| publishing_preset_id | No | Optional workspace publishing preset ID. When omitted, Postly uses the preset named Default or the oldest saved preset. | |
| use_publishing_presets | No | Apply the workspace publishing preset. Defaults to true. Set false only when the user explicitly wants platform defaults instead. |
| Name | Required | Description |
|---|---|---|
| code | No | |
| data | No | |
| prompt | No | |
| status | No | |
| message | No | |
| next_steps | No | |
| post_mutated | No | |
| agent_guidance | No | |
| ready_platforms | No | |
| blocked_platforms | No | |
| requires_user_input | No | |
| retry_after_seconds | No | |
| media_upload_results | No | |
| missing_requirements | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is carried. The description adds little beyond that: it does not say whether omitted fields are preserved, whether media/targets are replaced wholesale, or that updates can invalidate platform readiness — the omission-preserves semantics live only in individual schema fields.
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 sentences, front-loaded with the mutation scope and zero filler. The second sentence leans on return-value content that the output schema already provides, which is the only marginally wasteful clause.
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?
With an output schema and rich annotations, the description needn't spell out returns, and it correctly signals that this is a broad multi-facet update rather than a single-field patch. What is missing is the critical update-semantics contract (omitted fields preserved, lists replaced, empty list clears) for a 31-parameter destructive tool.
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 84%, so parameter meaning is largely documented in the schema itself. The description contributes one useful distinction — media references imported in the same action — but does not clarify the base-media vs media_file vs media_uploads relationship, target_platforms vs audience_group exclusivity, or schedule replacement behavior.
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?
States a specific verb and resource with enumerated editable facets (content, media, labels, targets, schedules) scoped to 'an existing Postly post', which implicitly separates it from create/delete siblings. It does not name postly_create_post or postly_delete_post, so boundary routing is inferred 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?
'for an existing Postly post' implies when to use it, and the mention of client-provided media import covers one usage nuance. But there is no guidance on when not to use it (e.g., new posts, validation via postly_validate_post, channel schema lookup) despite postly_get_channel_schema being referenced throughout the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Imports media into Postly storage independently of a post mutation. Accepts a client-provided file reference, URL, data URL, or base64 payload. Returns a durable Postly media object only when complete; a 202 processing result requires a later list_media check with its idempotency_key before creating or scheduling a post.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Public or temporary URL to import into Postly storage when no file reference is available. | |
| data | No | Base64 content or a data URL for agents that can provide bytes instead of a URL. | |
| file | No | Client-provided file reference for an attached, selected, or generated file. | |
| type | No | Optional MIME type such as image/png, video/mp4, or application/pdf. | |
| alt_text | No | Optional alt text to carry forward into the returned Postly media object. | |
| file_name | No | Optional file name. Required when using data/base64 without a file reference. | |
| workspace_id | No | Destination Media Library workspace ID. Omit to use the oldest available writable workspace within this connection. Check media_library in the result for its workspace_id and registration status. | |
| idempotency_key | No | Optional stable key for safely retrying the same upload. Postly derives one automatically for file references and URLs. |
| Name | Required | Description |
|---|---|---|
| code | No | |
| media | No | |
| usage | No | |
| status | No | |
| message | No | |
| next_step | No | |
| raw_upload | No | |
| media_library | No | |
| idempotency_key | No | |
| retry_after_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations only declaring write/idempotency/open-world hints, the description adds substantive behavior: the call returns a durable media object only on completion, and a 202 means deferred processing that must be polled via list_media. The idempotency_key note coexists with idempotentHint=false because the schema explains Postly derives a key automatically for file references and URLs, so this is additive rather than contradictory.
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, front-loaded with purpose then input modes then the async caveat; nothing is filler. The final sentence is long and packs two ideas (polling requirement and the gating of post creation), which slightly reduces scanability.
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?
An output schema exists so return values need not be explained, and the description covers the non-obvious async case and scoping. Missing details an agent might want are practical limits (file size/type constraints) and how this differs from the batch sibling, but the core call path is complete.
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 eight parameters and the baseline is 3. The description restates the accepted input modes (file reference, URL, data URL, base64) but adds no format, precedence, or size guidance 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?
Specific verb+resource ('Imports media into Postly storage') with the key scope qualifier 'independently of a post mutation', which routes the agent away from postly_create_post. It does not, however, distinguish itself from the close sibling postly_upload_media_batch, so it stops short of full sibling differentiation.
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?
Gives a clear condition for the async path: a 202 result requires a later list_media check with the idempotency_key before creating or scheduling a post. That is real operational context. It does not state when to prefer this over postly_upload_media_batch or what the alternatives are, so it is context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Uploads up to 50 files with bounded concurrency and a 30-second overall deadline. Returns completed, processing, failed, not_started, or unknown for every item with its stable idempotency key. Unknown uploads may still complete; reconcile stored media or retry with the same key.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | No | Destination Media Library workspace ID. Omit to use the oldest available writable workspace within this connection. Check media_library in the result for its workspace_id and registration status. | |
| media_uploads | Yes |
| Name | Required | Description |
|---|---|---|
| code | No | |
| failed | No | |
| message | No | |
| results | No | |
| unknown | No | |
| completed | No | |
| elapsed_ms | No | |
| processing | No | |
| not_started | No | |
| all_succeeded | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare idempotency and an open-world, non-destructive profile. The description goes well beyond that by disclosing bounded concurrency, a 30-second overall deadline, the full set of per-item terminal states (completed/processing/failed/not_started/unknown), and the fact that 'unknown' uploads may still land server-side. That is exactly the partial-failure semantics an agent needs and cannot get from structured fields.
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, zero filler, and the most decision-relevant facts (batch limit, deadline, per-item statuses, retry rule) are front-loaded in that order. Every clause carries information an agent acts on.
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?
An output schema exists, so the description is not obligated to explain return values, yet it still summarizes the status vocabulary and the reconciliation path, which is helpful. The main gap is the absence of any statement about auth/permission needs or how this relates to the single-file upload tool, which matters for a write operation with openWorldHint.
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 50%, and the schema itself already documents workspace_id, url, data, file, and file_name in detail. The description only reinforces the idempotency_key concept ('stable idempotency key'), adding little about the media_uploads item shape or the workspace_id fallback. This is the baseline case where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Uploads up to 50 files') and quantifies the batch scope, so an agent immediately understands this is the bulk variant. It never names the sibling postly_upload_media, so the batch-vs-single distinction is left for the agent to infer from the tool name alone.
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 real recovery guidance for the 'unknown' outcome ('reconcile stored media or retry with the same key'), which is genuinely useful. However, it never states when to choose this batch tool over the single-file postly_upload_media sibling, nor any precondition such as the workspace requirement, so routing between the two is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks proposed post text, media, platform settings, schedules, and targets against Postly and platform-specific requirements. Returns validation status, errors, warnings, platform readiness, and applicable limits.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Post text or caption to validate. | |
| media | No | Optional media objects that will be attached to the post. | |
| workspace_id | Yes | Postly workspace ID. | |
| email_subject | No | Required when validating a post for email/newsletter targets. | |
| custom_replies | No | Shared first comment or follow-up sequence for supported selected platforms. Text and links only. Platform custom replies replace shared replies. Omit on update to preserve; [] clears shared replies. | |
| platform_posts | No | Optional platform-specific overrides. Use postly_get_channel_schema for the selected platform before supplying settings. | |
| one_off_schedule | No | ||
| target_platforms | No | Optional platform names, email/newsletter, provider names, or channel IDs. Use "all" or omit to validate against all connected workspace publishing targets. You may also pass a single string on clients that support that shorthand. | |
| custom_reply_modes | No | Per-platform reply selection: shared, custom, or off. Omit to preserve existing behavior. Custom settings replace rather than append. Property values may use multiple equivalent input shapes; the server normalizes them. | |
| recurring_schedule | No |
| Name | Required | Description |
|---|---|---|
| No | ||
| valid | No | |
| errors | No | |
| limits | No | |
| warnings | No | |
| platforms | No | |
| schedules | No | |
| agent_guidance | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/true, idempotent, non-destructive, so safety is covered. The description adds genuine value by naming the outputs an agent can expect: validation status, errors, warnings, platform readiness, and applicable limits — telling the agent this is a diagnostic call with structured feedback.
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 with no waste: the first states what is validated, the second states what is returned. Scope and result are front-loaded, which is ideal for a diagnostic 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 an output schema exists and annotations cover the safety profile, the description is nearly complete. A minor gap is the absence of prerequisites (e.g. that target platforms must be connected or that channel schema should be consulted first), which siblings like postly_get_channel_schema handle, but nothing critical 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?
Schema coverage is 80% and the schema is highly detailed (enums, nested media, schedules), so it already carries most parameter meaning. The description mostly restates the input categories (text, media, settings, schedules, targets) rather than adding new syntax or constraints beyond the schema, matching the baseline-3 rule.
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?
States a specific verb ('checks...against requirements') and enumerates exactly what is validated: text, media, platform settings, schedules, targets. The verb 'validate' plus the returned fields clearly distinguish it from mutating siblings like postly_create_post. It stops short of explicitly naming those siblings, keeping it at 4.
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 framing implies a pre-flight check before creating/updating a post, but there is no explicit 'use this before calling create_post' guidance nor any when-not condition. A capable agent can infer the purpose, but the description leaves the workflow relationship to inference.
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.
postly_create_post7 fields changedInput schema / properties / media / items / properties / cover_image_urlAdded value: +{
+ "description": "Alias for thumbnail; the canonical thumbnail field takes priority.",
+ "type": "string"
+}Input schema / properties / media / items / properties / thumbnailAdded value: +{
+ "description": "Video cover image (thumbnail). Use only for destinations and post types that accept a custom cover. The server also accepts equivalent compatible shapes on some clients.",
+ "properties": {
+ "remote_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "remote_url"
+ ],
+ "type": "object"
+}Input schema / properties / media / items / properties / thumbnail_offsetAdded value: +{
+ "description": "Video-frame position in milliseconds, where the destination supports it.",
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / platform_posts / items / properties / media_override / items / properties / cover_image_urlAdded value: +{
+ "description": "Alias for thumbnail; the canonical thumbnail field takes priority.",
+ "type": "string"
+}Input schema / properties / platform_posts / items / properties / media_override / items / properties / thumbnailAdded value: +{
+ "description": "Video cover image (thumbnail). Use only for destinations and post types that accept a custom cover. The server also accepts equivalent compatible shapes on some clients.",
+ "properties": {
+ "remote_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "remote_url"
+ ],
+ "type": "object"
+}Input schema / properties / platform_posts / items / properties / media_override / items / properties / thumbnail_offsetAdded value: +{
+ "description": "Video-frame position in milliseconds, where the destination supports it.",
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / platform_posts / items / properties / settings / properties / custom_replies / descriptionPrevious value: -"Custom replies for facebook, instagram, linkedin, youtube, x, threads, bluesky. Minutes after parent publication. X/Threads/Bluesky allow media; other platforms text and links only. Do not also supply legacy reply fields."New value: +"Custom replies for facebook, instagram, linkedin, youtube, x, threads, bluesky, slack. Minutes after parent publication. X/Threads/Bluesky allow media; other platforms text and links only. Do not also supply legacy reply fields."postly_update_post7 fields changedInput schema / properties / media / items / properties / cover_image_urlAdded value: +{
+ "description": "Alias for thumbnail; the canonical thumbnail field takes priority.",
+ "type": "string"
+}Input schema / properties / media / items / properties / thumbnailAdded value: +{
+ "description": "Video cover image (thumbnail). Use only for destinations and post types that accept a custom cover. The server also accepts equivalent compatible shapes on some clients.",
+ "properties": {
+ "remote_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "remote_url"
+ ],
+ "type": "object"
+}Input schema / properties / media / items / properties / thumbnail_offsetAdded value: +{
+ "description": "Video-frame position in milliseconds, where the destination supports it.",
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / platform_posts / items / properties / media_override / items / properties / cover_image_urlAdded value: +{
+ "description": "Alias for thumbnail; the canonical thumbnail field takes priority.",
+ "type": "string"
+}Input schema / properties / platform_posts / items / properties / media_override / items / properties / thumbnailAdded value: +{
+ "description": "Video cover image (thumbnail). Use only for destinations and post types that accept a custom cover. The server also accepts equivalent compatible shapes on some clients.",
+ "properties": {
+ "remote_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "remote_url"
+ ],
+ "type": "object"
+}Input schema / properties / platform_posts / items / properties / media_override / items / properties / thumbnail_offsetAdded value: +{
+ "description": "Video-frame position in milliseconds, where the destination supports it.",
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / platform_posts / items / properties / settings / properties / custom_replies / descriptionPrevious value: -"Custom replies for facebook, instagram, linkedin, youtube, x, threads, bluesky. Minutes after parent publication. X/Threads/Bluesky allow media; other platforms text and links only. Do not also supply legacy reply fields."New value: +"Custom replies for facebook, instagram, linkedin, youtube, x, threads, bluesky, slack. Minutes after parent publication. X/Threads/Bluesky allow media; other platforms text and links only. Do not also supply legacy reply fields."postly_validate_post7 fields changedInput schema / properties / media / items / properties / cover_image_urlAdded value: +{
+ "description": "Alias for thumbnail; the canonical thumbnail field takes priority.",
+ "type": "string"
+}Input schema / properties / media / items / properties / thumbnailAdded value: +{
+ "description": "Video cover image (thumbnail). Use only for destinations and post types that accept a custom cover. The server also accepts equivalent compatible shapes on some clients.",
+ "properties": {
+ "remote_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "remote_url"
+ ],
+ "type": "object"
+}Input schema / properties / media / items / properties / thumbnail_offsetAdded value: +{
+ "description": "Video-frame position in milliseconds, where the destination supports it.",
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / platform_posts / items / properties / media_override / items / properties / cover_image_urlAdded value: +{
+ "description": "Alias for thumbnail; the canonical thumbnail field takes priority.",
+ "type": "string"
+}Input schema / properties / platform_posts / items / properties / media_override / items / properties / thumbnailAdded value: +{
+ "description": "Video cover image (thumbnail). Use only for destinations and post types that accept a custom cover. The server also accepts equivalent compatible shapes on some clients.",
+ "properties": {
+ "remote_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "remote_url"
+ ],
+ "type": "object"
+}Input schema / properties / platform_posts / items / properties / media_override / items / properties / thumbnail_offsetAdded value: +{
+ "description": "Video-frame position in milliseconds, where the destination supports it.",
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / platform_posts / items / properties / settings / properties / custom_replies / descriptionPrevious value: -"Custom replies for facebook, instagram, linkedin, youtube, x, threads, bluesky. Minutes after parent publication. X/Threads/Bluesky allow media; other platforms text and links only. Do not also supply legacy reply fields."New value: +"Custom replies for facebook, instagram, linkedin, youtube, x, threads, bluesky, slack. Minutes after parent publication. X/Threads/Bluesky allow media; other platforms text and links only. Do not also supply legacy reply fields."postly_create_post3 fields changedInput schema / properties / platform_posts / items / properties / identifier / enumPrevious value: -[
- "facebook",
- "fb",
- "fb_page",
- "fbpage",
- "facebook_page",
- "facebookpage",
- "meta_page",
- "metapage",
- "instagram",
- "insta",
- "ig",
- "linkedin",
- "linked_in",
- "linked",
- "lnkd",
- "linkdin",
- "linkedin_page",
- "linkedinpage",
- "x",
- "twitter",
- "x_twitter",
- "xtwitter",
- "googleMyBusiness",
- "google_my_business",
- "google_business",
- "googlebusiness",
- "google_business_profile",
- "googlebusinessprofile",
- "business_profile",
- "businessprofile",
- "google_maps",
- "googlemaps",
- "gmb",
- "gbp",
- "reddit",
- "pinterest",
- "pin",
- "youtube",
- "you_tube",
- "yt",
- "youtu",
- "yt_channel",
- "ytchannel",
- "youtube_channel",
- "youtubechannel",
- "youtube_shorts",
- "youtubeshorts",
- "tiktok",
- "tik_tok",
- "tik",
- "tok",
- "wordpress",
- "word_press",
- "wp",
- "ghost",
- "hashnode",
- "hash_node",
- "devto",
- "dev_to",
- "dev.to",
- "forem",
- "blogger",
- "blogspot",
- "threads",
- "thread",
- "bluesky",
- "blue_sky",
- "bsky",
- "telegram",
- "tg",
- "tme",
- "whatsapp",
- "whats_app",
- "whats",
- "wa"
-]New value: +[
+ "facebook",
+ "fb",
+ "fb_page",
+ "fbpage",
+ "facebook_page",
+ "facebookpage",
+ "meta_page",
+ "metapage",
+ "instagram",
+ "insta",
+ "ig",
+ "linkedin",
+ "linked_in",
+ "linked",
+ "lnkd",
+ "linkdin",
+ "linkedin_page",
+ "linkedinpage",
+ "x",
+ "twitter",
+ "x_twitter",
+ "xtwitter",
+ "googleMyBusiness",
+ "google_my_business",
+ "google_business",
+ "googlebusiness",
+ "google_business_profile",
+ "googlebusinessprofile",
+ "business_profile",
+ "businessprofile",
+ "google_maps",
+ "googlemaps",
+ "gmb",
+ "gbp",
+ "pinterest",
+ "pin",
+ "youtube",
+ "you_tube",
+ "yt",
+ "youtu",
+ "yt_channel",
+ "ytchannel",
+ "youtube_channel",
+ "youtubechannel",
+ "youtube_shorts",
+ "youtubeshorts",
+ "tiktok",
+ "tik_tok",
+ "tik",
+ "tok",
+ "wordpress",
+ "word_press",
+ "wp",
+ "ghost",
+ "hashnode",
+ "hash_node",
+ "devto",
+ "dev_to",
+ "dev.to",
+ "forem",
+ "blogger",
+ "blogspot",
+ "threads",
+ "thread",
+ "bluesky",
+ "blue_sky",
+ "bsky",
+ "telegram",
+ "tg",
+ "tme",
+ "whatsapp",
+ "whats_app",
+ "whats",
+ "wa"
+]Input schema / properties / platform_posts / items / properties / settings / properties / identifier / enumPrevious value: -[
- "facebook",
- "fb",
- "fb_page",
- "fbpage",
- "facebook_page",
- "facebookpage",
- "meta_page",
- "metapage",
- "instagram",
- "insta",
- "ig",
- "linkedin",
- "linked_in",
- "linked",
- "lnkd",
- "linkdin",
- "linkedin_page",
- "linkedinpage",
- "x",
- "twitter",
- "x_twitter",
- "xtwitter",
- "googleMyBusiness",
- "google_my_business",
- "google_business",
- "googlebusiness",
- "google_business_profile",
- "googlebusinessprofile",
- "business_profile",
- "businessprofile",
- "google_maps",
- "googlemaps",
- "gmb",
- "gbp",
- "reddit",
- "pinterest",
- "pin",
- "youtube",
- "you_tube",
- "yt",
- "youtu",
- "yt_channel",
- "ytchannel",
- "youtube_channel",
- "youtubechannel",
- "youtube_shorts",
- "youtubeshorts",
- "tiktok",
- "tik_tok",
- "tik",
- "tok",
- "wordpress",
- "word_press",
- "wp",
- "ghost",
- "hashnode",
- "hash_node",
- "devto",
- "dev_to",
- "dev.to",
- "forem",
- "blogger",
- "blogspot",
- "threads",
- "thread",
- "bluesky",
- "blue_sky",
- "bsky",
- "telegram",
- "tg",
- "tme",
- "whatsapp",
- "whats_app",
- "whats",
- "wa"
-]New value: +[
+ "facebook",
+ "fb",
+ "fb_page",
+ "fbpage",
+ "facebook_page",
+ "facebookpage",
+ "meta_page",
+ "metapage",
+ "instagram",
+ "insta",
+ "ig",
+ "linkedin",
+ "linked_in",
+ "linked",
+ "lnkd",
+ "linkdin",
+ "linkedin_page",
+ "linkedinpage",
+ "x",
+ "twitter",
+ "x_twitter",
+ "xtwitter",
+ "googleMyBusiness",
+ "google_my_business",
+ "google_business",
+ "googlebusiness",
+ "google_business_profile",
+ "googlebusinessprofile",
+ "business_profile",
+ "businessprofile",
+ "google_maps",
+ "googlemaps",
+ "gmb",
+ "gbp",
+ "pinterest",
+ "pin",
+ "youtube",
+ "you_tube",
+ "yt",
+ "youtu",
+ "yt_channel",
+ "ytchannel",
+ "youtube_channel",
+ "youtubechannel",
+ "youtube_shorts",
+ "youtubeshorts",
+ "tiktok",
+ "tik_tok",
+ "tik",
+ "tok",
+ "wordpress",
+ "word_press",
+ "wp",
+ "ghost",
+ "hashnode",
+ "hash_node",
+ "devto",
+ "dev_to",
+ "dev.to",
+ "forem",
+ "blogger",
+ "blogspot",
+ "threads",
+ "thread",
+ "bluesky",
+ "blue_sky",
+ "bsky",
+ "telegram",
+ "tg",
+ "tme",
+ "whatsapp",
+ "whats_app",
+ "whats",
+ "wa"
+]Input schema / properties / platform_posts / items / properties / settings / properties / title / descriptionPrevious value: -"Optional title metadata. Provide it for YouTube, WordPress, Reddit, or Blogger when those platforms are selected."New value: +"Optional title metadata. Provide it for YouTube, WordPress, or Blogger when those platforms are selected."postly_update_post3 fields changedInput schema / properties / platform_posts / items / properties / identifier / enumPrevious value: -[
- "facebook",
- "fb",
- "fb_page",
- "fbpage",
- "facebook_page",
- "facebookpage",
- "meta_page",
- "metapage",
- "instagram",
- "insta",
- "ig",
- "linkedin",
- "linked_in",
- "linked",
- "lnkd",
- "linkdin",
- "linkedin_page",
- "linkedinpage",
- "x",
- "twitter",
- "x_twitter",
- "xtwitter",
- "googleMyBusiness",
- "google_my_business",
- "google_business",
- "googlebusiness",
- "google_business_profile",
- "googlebusinessprofile",
- "business_profile",
- "businessprofile",
- "google_maps",
- "googlemaps",
- "gmb",
- "gbp",
- "reddit",
- "pinterest",
- "pin",
- "youtube",
- "you_tube",
- "yt",
- "youtu",
- "yt_channel",
- "ytchannel",
- "youtube_channel",
- "youtubechannel",
- "youtube_shorts",
- "youtubeshorts",
- "tiktok",
- "tik_tok",
- "tik",
- "tok",
- "wordpress",
- "word_press",
- "wp",
- "ghost",
- "hashnode",
- "hash_node",
- "devto",
- "dev_to",
- "dev.to",
- "forem",
- "blogger",
- "blogspot",
- "threads",
- "thread",
- "bluesky",
- "blue_sky",
- "bsky",
- "telegram",
- "tg",
- "tme",
- "whatsapp",
- "whats_app",
- "whats",
- "wa"
-]New value: +[
+ "facebook",
+ "fb",
+ "fb_page",
+ "fbpage",
+ "facebook_page",
+ "facebookpage",
+ "meta_page",
+ "metapage",
+ "instagram",
+ "insta",
+ "ig",
+ "linkedin",
+ "linked_in",
+ "linked",
+ "lnkd",
+ "linkdin",
+ "linkedin_page",
+ "linkedinpage",
+ "x",
+ "twitter",
+ "x_twitter",
+ "xtwitter",
+ "googleMyBusiness",
+ "google_my_business",
+ "google_business",
+ "googlebusiness",
+ "google_business_profile",
+ "googlebusinessprofile",
+ "business_profile",
+ "businessprofile",
+ "google_maps",
+ "googlemaps",
+ "gmb",
+ "gbp",
+ "pinterest",
+ "pin",
+ "youtube",
+ "you_tube",
+ "yt",
+ "youtu",
+ "yt_channel",
+ "ytchannel",
+ "youtube_channel",
+ "youtubechannel",
+ "youtube_shorts",
+ "youtubeshorts",
+ "tiktok",
+ "tik_tok",
+ "tik",
+ "tok",
+ "wordpress",
+ "word_press",
+ "wp",
+ "ghost",
+ "hashnode",
+ "hash_node",
+ "devto",
+ "dev_to",
+ "dev.to",
+ "forem",
+ "blogger",
+ "blogspot",
+ "threads",
+ "thread",
+ "bluesky",
+ "blue_sky",
+ "bsky",
+ "telegram",
+ "tg",
+ "tme",
+ "whatsapp",
+ "whats_app",
+ "whats",
+ "wa"
+]Input schema / properties / platform_posts / items / properties / settings / properties / identifier / enumPrevious value: -[
- "facebook",
- "fb",
- "fb_page",
- "fbpage",
- "facebook_page",
- "facebookpage",
- "meta_page",
- "metapage",
- "instagram",
- "insta",
- "ig",
- "linkedin",
- "linked_in",
- "linked",
- "lnkd",
- "linkdin",
- "linkedin_page",
- "linkedinpage",
- "x",
- "twitter",
- "x_twitter",
- "xtwitter",
- "googleMyBusiness",
- "google_my_business",
- "google_business",
- "googlebusiness",
- "google_business_profile",
- "googlebusinessprofile",
- "business_profile",
- "businessprofile",
- "google_maps",
- "googlemaps",
- "gmb",
- "gbp",
- "reddit",
- "pinterest",
- "pin",
- "youtube",
- "you_tube",
- "yt",
- "youtu",
- "yt_channel",
- "ytchannel",
- "youtube_channel",
- "youtubechannel",
- "youtube_shorts",
- "youtubeshorts",
- "tiktok",
- "tik_tok",
- "tik",
- "tok",
- "wordpress",
- "word_press",
- "wp",
- "ghost",
- "hashnode",
- "hash_node",
- "devto",
- "dev_to",
- "dev.to",
- "forem",
- "blogger",
- "blogspot",
- "threads",
- "thread",
- "bluesky",
- "blue_sky",
- "bsky",
- "telegram",
- "tg",
- "tme",
- "whatsapp",
- "whats_app",
- "whats",
- "wa"
-]New value: +[
+ "facebook",
+ "fb",
+ "fb_page",
+ "fbpage",
+ "facebook_page",
+ "facebookpage",
+ "meta_page",
+ "metapage",
+ "instagram",
+ "insta",
+ "ig",
+ "linkedin",
+ "linked_in",
+ "linked",
+ "lnkd",
+ "linkdin",
+ "linkedin_page",
+ "linkedinpage",
+ "x",
+ "twitter",
+ "x_twitter",
+ "xtwitter",
+ "googleMyBusiness",
+ "google_my_business",
+ "google_business",
+ "googlebusiness",
+ "google_business_profile",
+ "googlebusinessprofile",
+ "business_profile",
+ "businessprofile",
+ "google_maps",
+ "googlemaps",
+ "gmb",
+ "gbp",
+ "pinterest",
+ "pin",
+ "youtube",
+ "you_tube",
+ "yt",
+ "youtu",
+ "yt_channel",
+ "ytchannel",
+ "youtube_channel",
+ "youtubechannel",
+ "youtube_shorts",
+ "youtubeshorts",
+ "tiktok",
+ "tik_tok",
+ "tik",
+ "tok",
+ "wordpress",
+ "word_press",
+ "wp",
+ "ghost",
+ "hashnode",
+ "hash_node",
+ "devto",
+ "dev_to",
+ "dev.to",
+ "forem",
+ "blogger",
+ "blogspot",
+ "threads",
+ "thread",
+ "bluesky",
+ "blue_sky",
+ "bsky",
+ "telegram",
+ "tg",
+ "tme",
+ "whatsapp",
+ "whats_app",
+ "whats",
+ "wa"
+]Input schema / properties / platform_posts / items / properties / settings / properties / title / descriptionPrevious value: -"Optional title metadata. Provide it for YouTube, WordPress, Reddit, or Blogger when those platforms are selected."New value: +"Optional title metadata. Provide it for YouTube, WordPress, or Blogger when those platforms are selected."postly_validate_post3 fields changedInput schema / properties / platform_posts / items / properties / identifier / enumPrevious value: -[
- "facebook",
- "fb",
- "fb_page",
- "fbpage",
- "facebook_page",
- "facebookpage",
- "meta_page",
- "metapage",
- "instagram",
- "insta",
- "ig",
- "linkedin",
- "linked_in",
- "linked",
- "lnkd",
- "linkdin",
- "linkedin_page",
- "linkedinpage",
- "x",
- "twitter",
- "x_twitter",
- "xtwitter",
- "googleMyBusiness",
- "google_my_business",
- "google_business",
- "googlebusiness",
- "google_business_profile",
- "googlebusinessprofile",
- "business_profile",
- "businessprofile",
- "google_maps",
- "googlemaps",
- "gmb",
- "gbp",
- "reddit",
- "pinterest",
- "pin",
- "youtube",
- "you_tube",
- "yt",
- "youtu",
- "yt_channel",
- "ytchannel",
- "youtube_channel",
- "youtubechannel",
- "youtube_shorts",
- "youtubeshorts",
- "tiktok",
- "tik_tok",
- "tik",
- "tok",
- "wordpress",
- "word_press",
- "wp",
- "ghost",
- "hashnode",
- "hash_node",
- "devto",
- "dev_to",
- "dev.to",
- "forem",
- "blogger",
- "blogspot",
- "threads",
- "thread",
- "bluesky",
- "blue_sky",
- "bsky",
- "telegram",
- "tg",
- "tme",
- "whatsapp",
- "whats_app",
- "whats",
- "wa"
-]New value: +[
+ "facebook",
+ "fb",
+ "fb_page",
+ "fbpage",
+ "facebook_page",
+ "facebookpage",
+ "meta_page",
+ "metapage",
+ "instagram",
+ "insta",
+ "ig",
+ "linkedin",
+ "linked_in",
+ "linked",
+ "lnkd",
+ "linkdin",
+ "linkedin_page",
+ "linkedinpage",
+ "x",
+ "twitter",
+ "x_twitter",
+ "xtwitter",
+ "googleMyBusiness",
+ "google_my_business",
+ "google_business",
+ "googlebusiness",
+ "google_business_profile",
+ "googlebusinessprofile",
+ "business_profile",
+ "businessprofile",
+ "google_maps",
+ "googlemaps",
+ "gmb",
+ "gbp",
+ "pinterest",
+ "pin",
+ "youtube",
+ "you_tube",
+ "yt",
+ "youtu",
+ "yt_channel",
+ "ytchannel",
+ "youtube_channel",
+ "youtubechannel",
+ "youtube_shorts",
+ "youtubeshorts",
+ "tiktok",
+ "tik_tok",
+ "tik",
+ "tok",
+ "wordpress",
+ "word_press",
+ "wp",
+ "ghost",
+ "hashnode",
+ "hash_node",
+ "devto",
+ "dev_to",
+ "dev.to",
+ "forem",
+ "blogger",
+ "blogspot",
+ "threads",
+ "thread",
+ "bluesky",
+ "blue_sky",
+ "bsky",
+ "telegram",
+ "tg",
+ "tme",
+ "whatsapp",
+ "whats_app",
+ "whats",
+ "wa"
+]Input schema / properties / platform_posts / items / properties / settings / properties / identifier / enumPrevious value: -[
- "facebook",
- "fb",
- "fb_page",
- "fbpage",
- "facebook_page",
- "facebookpage",
- "meta_page",
- "metapage",
- "instagram",
- "insta",
- "ig",
- "linkedin",
- "linked_in",
- "linked",
- "lnkd",
- "linkdin",
- "linkedin_page",
- "linkedinpage",
- "x",
- "twitter",
- "x_twitter",
- "xtwitter",
- "googleMyBusiness",
- "google_my_business",
- "google_business",
- "googlebusiness",
- "google_business_profile",
- "googlebusinessprofile",
- "business_profile",
- "businessprofile",
- "google_maps",
- "googlemaps",
- "gmb",
- "gbp",
- "reddit",
- "pinterest",
- "pin",
- "youtube",
- "you_tube",
- "yt",
- "youtu",
- "yt_channel",
- "ytchannel",
- "youtube_channel",
- "youtubechannel",
- "youtube_shorts",
- "youtubeshorts",
- "tiktok",
- "tik_tok",
- "tik",
- "tok",
- "wordpress",
- "word_press",
- "wp",
- "ghost",
- "hashnode",
- "hash_node",
- "devto",
- "dev_to",
- "dev.to",
- "forem",
- "blogger",
- "blogspot",
- "threads",
- "thread",
- "bluesky",
- "blue_sky",
- "bsky",
- "telegram",
- "tg",
- "tme",
- "whatsapp",
- "whats_app",
- "whats",
- "wa"
-]New value: +[
+ "facebook",
+ "fb",
+ "fb_page",
+ "fbpage",
+ "facebook_page",
+ "facebookpage",
+ "meta_page",
+ "metapage",
+ "instagram",
+ "insta",
+ "ig",
+ "linkedin",
+ "linked_in",
+ "linked",
+ "lnkd",
+ "linkdin",
+ "linkedin_page",
+ "linkedinpage",
+ "x",
+ "twitter",
+ "x_twitter",
+ "xtwitter",
+ "googleMyBusiness",
+ "google_my_business",
+ "google_business",
+ "googlebusiness",
+ "google_business_profile",
+ "googlebusinessprofile",
+ "business_profile",
+ "businessprofile",
+ "google_maps",
+ "googlemaps",
+ "gmb",
+ "gbp",
+ "pinterest",
+ "pin",
+ "youtube",
+ "you_tube",
+ "yt",
+ "youtu",
+ "yt_channel",
+ "ytchannel",
+ "youtube_channel",
+ "youtubechannel",
+ "youtube_shorts",
+ "youtubeshorts",
+ "tiktok",
+ "tik_tok",
+ "tik",
+ "tok",
+ "wordpress",
+ "word_press",
+ "wp",
+ "ghost",
+ "hashnode",
+ "hash_node",
+ "devto",
+ "dev_to",
+ "dev.to",
+ "forem",
+ "blogger",
+ "blogspot",
+ "threads",
+ "thread",
+ "bluesky",
+ "blue_sky",
+ "bsky",
+ "telegram",
+ "tg",
+ "tme",
+ "whatsapp",
+ "whats_app",
+ "whats",
+ "wa"
+]Input schema / properties / platform_posts / items / properties / settings / properties / title / descriptionPrevious value: -"Optional title metadata. Provide it for YouTube, WordPress, Reddit, or Blogger when those platforms are selected."New value: +"Optional title metadata. Provide it for YouTube, WordPress, or Blogger when those platforms are selected."postly_create_post2 fields changedInput schema / properties / custom_repliesAdded value: +{
+ "description": "Shared first comment or follow-up sequence for supported selected platforms. Text and links only. Platform custom replies replace shared replies. Omit on update to preserve; [] clears shared replies.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "delay_minutes": {
+ "maximum": 525600,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "text"
+ ],
+ "type": "object"
+ },
+ "maxItems": 50,
+ "type": "array"
+}Input schema / properties / custom_reply_modesAdded value: +{
+ "additionalProperties": true,
+ "description": "Per-platform reply selection: shared, custom, or off. Omit to preserve existing behavior. Custom settings replace rather than append. Property values may use multiple equivalent input shapes; the server normalizes them.",
+ "type": "object"
+}postly_update_post2 fields changedInput schema / properties / custom_repliesAdded value: +{
+ "description": "Shared first comment or follow-up sequence for supported selected platforms. Text and links only. Platform custom replies replace shared replies. Omit on update to preserve; [] clears shared replies.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "delay_minutes": {
+ "maximum": 525600,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "text"
+ ],
+ "type": "object"
+ },
+ "maxItems": 50,
+ "type": "array"
+}Input schema / properties / custom_reply_modesAdded value: +{
+ "additionalProperties": true,
+ "description": "Per-platform reply selection: shared, custom, or off. Omit to preserve existing behavior. Custom settings replace rather than append. Property values may use multiple equivalent input shapes; the server normalizes them.",
+ "type": "object"
+}postly_validate_post2 fields changedInput schema / properties / custom_repliesAdded value: +{
+ "description": "Shared first comment or follow-up sequence for supported selected platforms. Text and links only. Platform custom replies replace shared replies. Omit on update to preserve; [] clears shared replies.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "delay_minutes": {
+ "maximum": 525600,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "text"
+ ],
+ "type": "object"
+ },
+ "maxItems": 50,
+ "type": "array"
+}Input schema / properties / custom_reply_modesAdded value: +{
+ "additionalProperties": true,
+ "description": "Per-platform reply selection: shared, custom, or off. Omit to preserve existing behavior. Custom settings replace rather than append. Property values may use multiple equivalent input shapes; the server normalizes them.",
+ "type": "object"
+}postly_create_post1 field changedInput schema / properties / platform_posts / items / properties / settings / properties / custom_repliesAdded value: +{
+ "description": "Custom replies for facebook, instagram, linkedin, youtube, x, threads, bluesky. Minutes after parent publication. X/Threads/Bluesky allow media; other platforms text and links only. Do not also supply legacy reply fields.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "delay_minutes": {
+ "maximum": 525600,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "media": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "text": {
+ "description": "Plain links remain text; explicit [image](URL) or [video](URL) markers attach media.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "maxItems": 50,
+ "type": "array"
+}postly_update_post1 field changedInput schema / properties / platform_posts / items / properties / settings / properties / custom_repliesAdded value: +{
+ "description": "Custom replies for facebook, instagram, linkedin, youtube, x, threads, bluesky. Minutes after parent publication. X/Threads/Bluesky allow media; other platforms text and links only. Do not also supply legacy reply fields.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "delay_minutes": {
+ "maximum": 525600,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "media": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "text": {
+ "description": "Plain links remain text; explicit [image](URL) or [video](URL) markers attach media.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "maxItems": 50,
+ "type": "array"
+}postly_validate_post1 field changedInput schema / properties / platform_posts / items / properties / settings / properties / custom_repliesAdded value: +{
+ "description": "Custom replies for facebook, instagram, linkedin, youtube, x, threads, bluesky. Minutes after parent publication. X/Threads/Bluesky allow media; other platforms text and links only. Do not also supply legacy reply fields.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "delay_minutes": {
+ "maximum": 525600,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "media": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "text": {
+ "description": "Plain links remain text; explicit [image](URL) or [video](URL) markers attach media.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "maxItems": 50,
+ "type": "array"
+}postly_list_media1 field changedOutput schema / properties / media_libraryAdded value: +{
+ "type": "object"
+}postly_upload_media2 fields changedInput schema / properties / workspace_idAdded value: +{
+ "description": "Destination Media Library workspace ID. Omit to use the oldest available writable workspace within this connection. Check media_library in the result for its workspace_id and registration status.",
+ "type": "string"
+}Output schema / properties / media_libraryAdded value: +{
+ "type": "object"
+}postly_upload_media_batch2 fields changedInput schema / properties / media_uploads / items / properties / workspace_idAdded value: +{
+ "description": "Destination Media Library workspace ID. Omit to use the oldest available writable workspace within this connection. Check media_library in the result for its workspace_id and registration status.",
+ "type": "string"
+}Input schema / properties / workspace_idAdded value: +{
+ "description": "Destination Media Library workspace ID. Omit to use the oldest available writable workspace within this connection. Check media_library in the result for its workspace_id and registration status.",
+ "type": "string"
+}postly_create_post3 fields changedOutput schema / properties / media_upload_resultsAdded value: +{
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / post_mutatedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / retry_after_secondsAdded value: +{
+ "type": "integer"
+}postly_delete_post3 fields changedOutput schema / properties / media_upload_resultsAdded value: +{
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / post_mutatedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / retry_after_secondsAdded value: +{
+ "type": "integer"
+}postly_list_media1 field changedOutput schema / properties / retry_after_secondsAdded value: +{
+ "type": "integer"
+}postly_update_post3 fields changedOutput schema / properties / media_upload_resultsAdded value: +{
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / post_mutatedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / retry_after_secondsAdded value: +{
+ "type": "integer"
+}postly_upload_media4 fields changedOutput schema / properties / idempotency_keyAdded value: +{
+ "type": "string"
+}Output schema / properties / next_stepAdded value: +{
+ "type": "string"
+}Output schema / properties / retry_after_secondsAdded value: +{
+ "type": "integer"
+}Output schema / properties / statusAdded value: +{
+ "type": "string"
+}postly_upload_media_batch1 field changedOutput schema / properties / processingAdded value: +{
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+}postly_create_post1 field changedInput schema / properties / campaign_idAdded value: +{
+ "description": "Optional campaign ID in the same workspace. Campaign content approval and workspace post approval still apply. Omit to preserve the association on update.",
+ "type": "string"
+}postly_update_post1 field changedInput schema / properties / campaign_idAdded value: +{
+ "description": "Optional campaign ID in the same workspace. Campaign content approval and workspace post approval still apply. Omit to preserve the association on update.",
+ "type": "string"
+}postly_create_post4 fields changedInput schema / properties / platform_posts / items / properties / settings / properties / recurring_schedule / properties / expression / descriptionPrevious value: -"Cron or rate expression describing the recurring schedule."New value: +"AWS six-field cron or rate expression. rate(4 weeks) and every 4 weeks normalize to rate(28 days): elapsed duration, so local clock time may shift across daylight saving changes. Use cron for named-timezone wall-clock recurrence. recurring=true is inferred."Input schema / properties / platform_posts / items / properties / settings / properties / recurring_schedule / properties / timezone / descriptionPrevious value: -"IANA timezone used to interpret the recurring schedule."New value: +"IANA timezone for cron wall-clock times and local start/end dates. Rate intervals remain elapsed duration across daylight saving changes."Input schema / properties / recurring_schedule / properties / expression / descriptionPrevious value: -"Cron or rate expression describing the recurring schedule."New value: +"AWS six-field cron or rate expression. rate(4 weeks) and every 4 weeks normalize to rate(28 days): elapsed duration, so local clock time may shift across daylight saving changes. Use cron for named-timezone wall-clock recurrence. recurring=true is inferred."Input schema / properties / recurring_schedule / properties / timezone / descriptionPrevious value: -"IANA timezone used to interpret the recurring schedule."New value: +"IANA timezone for cron wall-clock times and local start/end dates. Rate intervals remain elapsed duration across daylight saving changes."postly_list_media3 fields changedInput schema / properties / idempotency_keyAdded value: +{
+ "description": "Recover a specific upload using its returned key instead of listing files. An unknown result may still be in progress; retry uploads only with this same key.",
+ "type": "string"
+}Output schema / properties / idempotency_keyAdded value: +{
+ "type": "string"
+}Output schema / properties / statusAdded value: +{
+ "type": "string"
+}postly_update_post4 fields changedInput schema / properties / platform_posts / items / properties / settings / properties / recurring_schedule / properties / expression / descriptionPrevious value: -"Cron or rate expression describing the recurring schedule."New value: +"AWS six-field cron or rate expression. rate(4 weeks) and every 4 weeks normalize to rate(28 days): elapsed duration, so local clock time may shift across daylight saving changes. Use cron for named-timezone wall-clock recurrence. recurring=true is inferred."Input schema / properties / platform_posts / items / properties / settings / properties / recurring_schedule / properties / timezone / descriptionPrevious value: -"IANA timezone used to interpret the recurring schedule."New value: +"IANA timezone for cron wall-clock times and local start/end dates. Rate intervals remain elapsed duration across daylight saving changes."Input schema / properties / recurring_schedule / properties / expression / descriptionPrevious value: -"Cron or rate expression describing the recurring schedule."New value: +"AWS six-field cron or rate expression. rate(4 weeks) and every 4 weeks normalize to rate(28 days): elapsed duration, so local clock time may shift across daylight saving changes. Use cron for named-timezone wall-clock recurrence. recurring=true is inferred."Input schema / properties / recurring_schedule / properties / timezone / descriptionPrevious value: -"IANA timezone used to interpret the recurring schedule."New value: +"IANA timezone for cron wall-clock times and local start/end dates. Rate intervals remain elapsed duration across daylight saving changes."postly_upload_media_batch4 fields changedOutput schema / properties / elapsed_msAdded value: +{
+ "type": "integer"
+}Output schema / properties / not_startedAdded value: +{
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / resultsAdded value: +{
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / unknownAdded value: +{
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+}postly_validate_post5 fields changedInput schema / properties / one_off_scheduleAdded value: +{
+ "additionalProperties": true,
+ "properties": {
+ "one_off_date": {
+ "description": "Local calendar date for the one-time post, normally YYYY-MM-DD.",
+ "type": "string"
+ },
+ "time": {
+ "description": "Local time of day in 24-hour format, for example 09:00 or 18:30:00.",
+ "type": "string"
+ },
+ "timezone": {
+ "description": "IANA timezone used to interpret the local date and time, for example Africa/Lagos or America/New_York.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "one_off_date",
+ "time",
+ "timezone"
+ ],
+ "type": "object"
+}Input schema / properties / platform_posts / items / properties / settings / properties / recurring_schedule / properties / expression / descriptionPrevious value: -"Cron or rate expression describing the recurring schedule."New value: +"AWS six-field cron or rate expression. rate(4 weeks) and every 4 weeks normalize to rate(28 days): elapsed duration, so local clock time may shift across daylight saving changes. Use cron for named-timezone wall-clock recurrence. recurring=true is inferred."Input schema / properties / platform_posts / items / properties / settings / properties / recurring_schedule / properties / timezone / descriptionPrevious value: -"IANA timezone used to interpret the recurring schedule."New value: +"IANA timezone for cron wall-clock times and local start/end dates. Rate intervals remain elapsed duration across daylight saving changes."Input schema / properties / recurring_scheduleAdded value: +{
+ "additionalProperties": true,
+ "properties": {
+ "day_of_month": {
+ "maximum": 31,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "end_date": {
+ "type": "string"
+ },
+ "expression": {
+ "description": "AWS six-field cron or rate expression. rate(4 weeks) and every 4 weeks normalize to rate(28 days): elapsed duration, so local clock time may shift across daylight saving changes. Use cron for named-timezone wall-clock recurrence. recurring=true is inferred.",
+ "type": "string"
+ },
+ "rate_unit": {
+ "enum": [
+ "minute",
+ "minutes",
+ "hour",
+ "hours",
+ "day",
+ "days",
+ "week",
+ "weeks"
+ ],
+ "type": "string"
+ },
+ "rate_value": {
+ "minimum": 1,
+ "type": "integer"
+ },
+ "start_date": {
+ "type": "string"
+ },
+ "time": {
+ "type": "string"
+ },
+ "timezone": {
+ "description": "IANA timezone for cron wall-clock times and local start/end dates. Rate intervals remain elapsed duration across daylight saving changes.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "expression",
+ "timezone"
+ ],
+ "type": "object"
+}Output schema / properties / schedulesAdded value: +{
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+}postly_create_post1 field changedInput schema / properties / platform_posts / items / properties / settings / descriptionPrevious value: -"Optional platform-specific settings. Set only fields relevant to the selected platform. identifier is optional; when provided it must match platform_posts[].identifier. Call postly_get_channel_schema for exact platform guidance."New value: +"Optional platform-specific settings. Set only fields relevant to the selected platform. identifier is optional; when provided it must match platform_posts[].identifier. Blog connectors support posts only: Page/page_type/post_type requests are rejected. Call postly_get_channel_schema for exact platform guidance."postly_list_mediapostly_update_post1 field changedInput schema / properties / platform_posts / items / properties / settings / descriptionPrevious value: -"Optional platform-specific settings. Set only fields relevant to the selected platform. identifier is optional; when provided it must match platform_posts[].identifier. Call postly_get_channel_schema for exact platform guidance."New value: +"Optional platform-specific settings. Set only fields relevant to the selected platform. identifier is optional; when provided it must match platform_posts[].identifier. Blog connectors support posts only: Page/page_type/post_type requests are rejected. Call postly_get_channel_schema for exact platform guidance."postly_upload_media1 field changedInput schema / properties / idempotency_keyAdded value: +{
+ "description": "Optional stable key for safely retrying the same upload. Postly derives one automatically for file references and URLs.",
+ "type": "string"
+}postly_upload_media_batchpostly_validate_post1 field changedInput schema / properties / platform_posts / items / properties / settings / descriptionPrevious value: -"Optional platform-specific settings. Set only fields relevant to the selected platform. identifier is optional; when provided it must match platform_posts[].identifier. Call postly_get_channel_schema for exact platform guidance."New value: +"Optional platform-specific settings. Set only fields relevant to the selected platform. identifier is optional; when provided it must match platform_posts[].identifier. Blog connectors support posts only: Page/page_type/post_type requests are rejected. Call postly_get_channel_schema for exact platform guidance."postly_get_post_status2 fields changedOutput schema / properties / delivery_resultsAdded value: +{
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / draft_delivery_countAdded value: +{
+ "type": "integer"
+}postly_create_post3 fields changedInput schema / properties / publishing_presetAdded value: +{
+ "description": "Optional workspace publishing preset name. Use instead of publishing_preset_id.",
+ "type": "string"
+}Input schema / properties / publishing_preset_idAdded value: +{
+ "description": "Optional workspace publishing preset ID. When omitted, Postly uses the preset named Default or the oldest saved preset.",
+ "type": "string"
+}Input schema / properties / use_publishing_presetsAdded value: +{
+ "description": "Apply the workspace publishing preset. Defaults to true. Set false only when the user explicitly wants platform defaults instead.",
+ "type": "boolean"
+}postly_update_post3 fields changedInput schema / properties / publishing_presetAdded value: +{
+ "description": "Optional workspace publishing preset name. Use instead of publishing_preset_id.",
+ "type": "string"
+}Input schema / properties / publishing_preset_idAdded value: +{
+ "description": "Optional workspace publishing preset ID. When omitted, Postly uses the preset named Default or the oldest saved preset.",
+ "type": "string"
+}Input schema / properties / use_publishing_presetsAdded value: +{
+ "description": "Apply the workspace publishing preset. Defaults to true. Set false only when the user explicitly wants platform defaults instead.",
+ "type": "boolean"
+}postly_craft_querypostly_create_post2 fields changedInput schema / properties / platform_posts / items / properties / identifier / enumPrevious value: -[
- "facebook",
- "fb",
- "fb_page",
- "fbpage",
- "facebook_page",
- "facebookpage",
- "meta_page",
- "metapage",
- "instagram",
- "insta",
- "ig",
- "linkedin",
- "linked_in",
- "linked",
- "lnkd",
- "linkdin",
- "linkedin_page",
- "linkedinpage",
- "x",
- "twitter",
- "x_twitter",
- "xtwitter",
- "googleMyBusiness",
- "google_my_business",
- "google_business",
- "googlebusiness",
- "google_business_profile",
- "googlebusinessprofile",
- "business_profile",
- "businessprofile",
- "google_maps",
- "googlemaps",
- "gmb",
- "gbp",
- "reddit",
- "pinterest",
- "pin",
- "youtube",
- "you_tube",
- "yt",
- "youtu",
- "yt_channel",
- "ytchannel",
- "youtube_channel",
- "youtubechannel",
- "youtube_shorts",
- "youtubeshorts",
- "tiktok",
- "tik_tok",
- "tik",
- "tok",
- "wordpress",
- "word_press",
- "wp",
- "blogger",
- "blogspot",
- "threads",
- "thread",
- "bluesky",
- "blue_sky",
- "bsky",
- "telegram",
- "tg",
- "tme",
- "whatsapp",
- "whats_app",
- "whats",
- "wa"
-]New value: +[
+ "facebook",
+ "fb",
+ "fb_page",
+ "fbpage",
+ "facebook_page",
+ "facebookpage",
+ "meta_page",
+ "metapage",
+ "instagram",
+ "insta",
+ "ig",
+ "linkedin",
+ "linked_in",
+ "linked",
+ "lnkd",
+ "linkdin",
+ "linkedin_page",
+ "linkedinpage",
+ "x",
+ "twitter",
+ "x_twitter",
+ "xtwitter",
+ "googleMyBusiness",
+ "google_my_business",
+ "google_business",
+ "googlebusiness",
+ "google_business_profile",
+ "googlebusinessprofile",
+ "business_profile",
+ "businessprofile",
+ "google_maps",
+ "googlemaps",
+ "gmb",
+ "gbp",
+ "reddit",
+ "pinterest",
+ "pin",
+ "youtube",
+ "you_tube",
+ "yt",
+ "youtu",
+ "yt_channel",
+ "ytchannel",
+ "youtube_channel",
+ "youtubechannel",
+ "youtube_shorts",
+ "youtubeshorts",
+ "tiktok",
+ "tik_tok",
+ "tik",
+ "tok",
+ "wordpress",
+ "word_press",
+ "wp",
+ "ghost",
+ "hashnode",
+ "hash_node",
+ "devto",
+ "dev_to",
+ "dev.to",
+ "forem",
+ "blogger",
+ "blogspot",
+ "threads",
+ "thread",
+ "bluesky",
+ "blue_sky",
+ "bsky",
+ "telegram",
+ "tg",
+ "tme",
+ "whatsapp",
+ "whats_app",
+ "whats",
+ "wa"
+]Input schema / properties / platform_posts / items / properties / settings / properties / identifier / enumPrevious value: -[
- "facebook",
- "fb",
- "fb_page",
- "fbpage",
- "facebook_page",
- "facebookpage",
- "meta_page",
- "metapage",
- "instagram",
- "insta",
- "ig",
- "linkedin",
- "linked_in",
- "linked",
- "lnkd",
- "linkdin",
- "linkedin_page",
- "linkedinpage",
- "x",
- "twitter",
- "x_twitter",
- "xtwitter",
- "googleMyBusiness",
- "google_my_business",
- "google_business",
- "googlebusiness",
- "google_business_profile",
- "googlebusinessprofile",
- "business_profile",
- "businessprofile",
- "google_maps",
- "googlemaps",
- "gmb",
- "gbp",
- "reddit",
- "pinterest",
- "pin",
- "youtube",
- "you_tube",
- "yt",
- "youtu",
- "yt_channel",
- "ytchannel",
- "youtube_channel",
- "youtubechannel",
- "youtube_shorts",
- "youtubeshorts",
- "tiktok",
- "tik_tok",
- "tik",
- "tok",
- "wordpress",
- "word_press",
- "wp",
- "blogger",
- "blogspot",
- "threads",
- "thread",
- "bluesky",
- "blue_sky",
- "bsky",
- "telegram",
- "tg",
- "tme",
- "whatsapp",
- "whats_app",
- "whats",
- "wa"
-]New value: +[
+ "facebook",
+ "fb",
+ "fb_page",
+ "fbpage",
+ "facebook_page",
+ "facebookpage",
+ "meta_page",
+ "metapage",
+ "instagram",
+ "insta",
+ "ig",
+ "linkedin",
+ "linked_in",
+ "linked",
+ "lnkd",
+ "linkdin",
+ "linkedin_page",
+ "linkedinpage",
+ "x",
+ "twitter",
+ "x_twitter",
+ "xtwitter",
+ "googleMyBusiness",
+ "google_my_business",
+ "google_business",
+ "googlebusiness",
+ "google_business_profile",
+ "googlebusinessprofile",
+ "business_profile",
+ "businessprofile",
+ "google_maps",
+ "googlemaps",
+ "gmb",
+ "gbp",
+ "reddit",
+ "pinterest",
+ "pin",
+ "youtube",
+ "you_tube",
+ "yt",
+ "youtu",
+ "yt_channel",
+ "ytchannel",
+ "youtube_channel",
+ "youtubechannel",
+ "youtube_shorts",
+ "youtubeshorts",
+ "tiktok",
+ "tik_tok",
+ "tik",
+ "tok",
+ "wordpress",
+ "word_press",
+ "wp",
+ "ghost",
+ "hashnode",
+ "hash_node",
+ "devto",
+ "dev_to",
+ "dev.to",
+ "forem",
+ "blogger",
+ "blogspot",
+ "threads",
+ "thread",
+ "bluesky",
+ "blue_sky",
+ "bsky",
+ "telegram",
+ "tg",
+ "tme",
+ "whatsapp",
+ "whats_app",
+ "whats",
+ "wa"
+]postly_update_post2 fields changedInput schema / properties / platform_posts / items / properties / identifier / enumPrevious value: -[
- "facebook",
- "fb",
- "fb_page",
- "fbpage",
- "facebook_page",
- "facebookpage",
- "meta_page",
- "metapage",
- "instagram",
- "insta",
- "ig",
- "linkedin",
- "linked_in",
- "linked",
- "lnkd",
- "linkdin",
- "linkedin_page",
- "linkedinpage",
- "x",
- "twitter",
- "x_twitter",
- "xtwitter",
- "googleMyBusiness",
- "google_my_business",
- "google_business",
- "googlebusiness",
- "google_business_profile",
- "googlebusinessprofile",
- "business_profile",
- "businessprofile",
- "google_maps",
- "googlemaps",
- "gmb",
- "gbp",
- "reddit",
- "pinterest",
- "pin",
- "youtube",
- "you_tube",
- "yt",
- "youtu",
- "yt_channel",
- "ytchannel",
- "youtube_channel",
- "youtubechannel",
- "youtube_shorts",
- "youtubeshorts",
- "tiktok",
- "tik_tok",
- "tik",
- "tok",
- "wordpress",
- "word_press",
- "wp",
- "blogger",
- "blogspot",
- "threads",
- "thread",
- "bluesky",
- "blue_sky",
- "bsky",
- "telegram",
- "tg",
- "tme",
- "whatsapp",
- "whats_app",
- "whats",
- "wa"
-]New value: +[
+ "facebook",
+ "fb",
+ "fb_page",
+ "fbpage",
+ "facebook_page",
+ "facebookpage",
+ "meta_page",
+ "metapage",
+ "instagram",
+ "insta",
+ "ig",
+ "linkedin",
+ "linked_in",
+ "linked",
+ "lnkd",
+ "linkdin",
+ "linkedin_page",
+ "linkedinpage",
+ "x",
+ "twitter",
+ "x_twitter",
+ "xtwitter",
+ "googleMyBusiness",
+ "google_my_business",
+ "google_business",
+ "googlebusiness",
+ "google_business_profile",
+ "googlebusinessprofile",
+ "business_profile",
+ "businessprofile",
+ "google_maps",
+ "googlemaps",
+ "gmb",
+ "gbp",
+ "reddit",
+ "pinterest",
+ "pin",
+ "youtube",
+ "you_tube",
+ "yt",
+ "youtu",
+ "yt_channel",
+ "ytchannel",
+ "youtube_channel",
+ "youtubechannel",
+ "youtube_shorts",
+ "youtubeshorts",
+ "tiktok",
+ "tik_tok",
+ "tik",
+ "tok",
+ "wordpress",
+ "word_press",
+ "wp",
+ "ghost",
+ "hashnode",
+ "hash_node",
+ "devto",
+ "dev_to",
+ "dev.to",
+ "forem",
+ "blogger",
+ "blogspot",
+ "threads",
+ "thread",
+ "bluesky",
+ "blue_sky",
+ "bsky",
+ "telegram",
+ "tg",
+ "tme",
+ "whatsapp",
+ "whats_app",
+ "whats",
+ "wa"
+]Input schema / properties / platform_posts / items / properties / settings / properties / identifier / enumPrevious value: -[
- "facebook",
- "fb",
- "fb_page",
- "fbpage",
- "facebook_page",
- "facebookpage",
- "meta_page",
- "metapage",
- "instagram",
- "insta",
- "ig",
- "linkedin",
- "linked_in",
- "linked",
- "lnkd",
- "linkdin",
- "linkedin_page",
- "linkedinpage",
- "x",
- "twitter",
- "x_twitter",
- "xtwitter",
- "googleMyBusiness",
- "google_my_business",
- "google_business",
- "googlebusiness",
- "google_business_profile",
- "googlebusinessprofile",
- "business_profile",
- "businessprofile",
- "google_maps",
- "googlemaps",
- "gmb",
- "gbp",
- "reddit",
- "pinterest",
- "pin",
- "youtube",
- "you_tube",
- "yt",
- "youtu",
- "yt_channel",
- "ytchannel",
- "youtube_channel",
- "youtubechannel",
- "youtube_shorts",
- "youtubeshorts",
- "tiktok",
- "tik_tok",
- "tik",
- "tok",
- "wordpress",
- "word_press",
- "wp",
- "blogger",
- "blogspot",
- "threads",
- "thread",
- "bluesky",
- "blue_sky",
- "bsky",
- "telegram",
- "tg",
- "tme",
- "whatsapp",
- "whats_app",
- "whats",
- "wa"
-]New value: +[
+ "facebook",
+ "fb",
+ "fb_page",
+ "fbpage",
+ "facebook_page",
+ "facebookpage",
+ "meta_page",
+ "metapage",
+ "instagram",
+ "insta",
+ "ig",
+ "linkedin",
+ "linked_in",
+ "linked",
+ "lnkd",
+ "linkdin",
+ "linkedin_page",
+ "linkedinpage",
+ "x",
+ "twitter",
+ "x_twitter",
+ "xtwitter",
+ "googleMyBusiness",
+ "google_my_business",
+ "google_business",
+ "googlebusiness",
+ "google_business_profile",
+ "googlebusinessprofile",
+ "business_profile",
+ "businessprofile",
+ "google_maps",
+ "googlemaps",
+ "gmb",
+ "gbp",
+ "reddit",
+ "pinterest",
+ "pin",
+ "youtube",
+ "you_tube",
+ "yt",
+ "youtu",
+ "yt_channel",
+ "ytchannel",
+ "youtube_channel",
+ "youtubechannel",
+ "youtube_shorts",
+ "youtubeshorts",
+ "tiktok",
+ "tik_tok",
+ "tik",
+ "tok",
+ "wordpress",
+ "word_press",
+ "wp",
+ "ghost",
+ "hashnode",
+ "hash_node",
+ "devto",
+ "dev_to",
+ "dev.to",
+ "forem",
+ "blogger",
+ "blogspot",
+ "threads",
+ "thread",
+ "bluesky",
+ "blue_sky",
+ "bsky",
+ "telegram",
+ "tg",
+ "tme",
+ "whatsapp",
+ "whats_app",
+ "whats",
+ "wa"
+]postly_validate_post2 fields changedInput schema / properties / platform_posts / items / properties / identifier / enumPrevious value: -[
- "facebook",
- "fb",
- "fb_page",
- "fbpage",
- "facebook_page",
- "facebookpage",
- "meta_page",
- "metapage",
- "instagram",
- "insta",
- "ig",
- "linkedin",
- "linked_in",
- "linked",
- "lnkd",
- "linkdin",
- "linkedin_page",
- "linkedinpage",
- "x",
- "twitter",
- "x_twitter",
- "xtwitter",
- "googleMyBusiness",
- "google_my_business",
- "google_business",
- "googlebusiness",
- "google_business_profile",
- "googlebusinessprofile",
- "business_profile",
- "businessprofile",
- "google_maps",
- "googlemaps",
- "gmb",
- "gbp",
- "reddit",
- "pinterest",
- "pin",
- "youtube",
- "you_tube",
- "yt",
- "youtu",
- "yt_channel",
- "ytchannel",
- "youtube_channel",
- "youtubechannel",
- "youtube_shorts",
- "youtubeshorts",
- "tiktok",
- "tik_tok",
- "tik",
- "tok",
- "wordpress",
- "word_press",
- "wp",
- "blogger",
- "blogspot",
- "threads",
- "thread",
- "bluesky",
- "blue_sky",
- "bsky",
- "telegram",
- "tg",
- "tme",
- "whatsapp",
- "whats_app",
- "whats",
- "wa"
-]New value: +[
+ "facebook",
+ "fb",
+ "fb_page",
+ "fbpage",
+ "facebook_page",
+ "facebookpage",
+ "meta_page",
+ "metapage",
+ "instagram",
+ "insta",
+ "ig",
+ "linkedin",
+ "linked_in",
+ "linked",
+ "lnkd",
+ "linkdin",
+ "linkedin_page",
+ "linkedinpage",
+ "x",
+ "twitter",
+ "x_twitter",
+ "xtwitter",
+ "googleMyBusiness",
+ "google_my_business",
+ "google_business",
+ "googlebusiness",
+ "google_business_profile",
+ "googlebusinessprofile",
+ "business_profile",
+ "businessprofile",
+ "google_maps",
+ "googlemaps",
+ "gmb",
+ "gbp",
+ "reddit",
+ "pinterest",
+ "pin",
+ "youtube",
+ "you_tube",
+ "yt",
+ "youtu",
+ "yt_channel",
+ "ytchannel",
+ "youtube_channel",
+ "youtubechannel",
+ "youtube_shorts",
+ "youtubeshorts",
+ "tiktok",
+ "tik_tok",
+ "tik",
+ "tok",
+ "wordpress",
+ "word_press",
+ "wp",
+ "ghost",
+ "hashnode",
+ "hash_node",
+ "devto",
+ "dev_to",
+ "dev.to",
+ "forem",
+ "blogger",
+ "blogspot",
+ "threads",
+ "thread",
+ "bluesky",
+ "blue_sky",
+ "bsky",
+ "telegram",
+ "tg",
+ "tme",
+ "whatsapp",
+ "whats_app",
+ "whats",
+ "wa"
+]Input schema / properties / platform_posts / items / properties / settings / properties / identifier / enumPrevious value: -[
- "facebook",
- "fb",
- "fb_page",
- "fbpage",
- "facebook_page",
- "facebookpage",
- "meta_page",
- "metapage",
- "instagram",
- "insta",
- "ig",
- "linkedin",
- "linked_in",
- "linked",
- "lnkd",
- "linkdin",
- "linkedin_page",
- "linkedinpage",
- "x",
- "twitter",
- "x_twitter",
- "xtwitter",
- "googleMyBusiness",
- "google_my_business",
- "google_business",
- "googlebusiness",
- "google_business_profile",
- "googlebusinessprofile",
- "business_profile",
- "businessprofile",
- "google_maps",
- "googlemaps",
- "gmb",
- "gbp",
- "reddit",
- "pinterest",
- "pin",
- "youtube",
- "you_tube",
- "yt",
- "youtu",
- "yt_channel",
- "ytchannel",
- "youtube_channel",
- "youtubechannel",
- "youtube_shorts",
- "youtubeshorts",
- "tiktok",
- "tik_tok",
- "tik",
- "tok",
- "wordpress",
- "word_press",
- "wp",
- "blogger",
- "blogspot",
- "threads",
- "thread",
- "bluesky",
- "blue_sky",
- "bsky",
- "telegram",
- "tg",
- "tme",
- "whatsapp",
- "whats_app",
- "whats",
- "wa"
-]New value: +[
+ "facebook",
+ "fb",
+ "fb_page",
+ "fbpage",
+ "facebook_page",
+ "facebookpage",
+ "meta_page",
+ "metapage",
+ "instagram",
+ "insta",
+ "ig",
+ "linkedin",
+ "linked_in",
+ "linked",
+ "lnkd",
+ "linkdin",
+ "linkedin_page",
+ "linkedinpage",
+ "x",
+ "twitter",
+ "x_twitter",
+ "xtwitter",
+ "googleMyBusiness",
+ "google_my_business",
+ "google_business",
+ "googlebusiness",
+ "google_business_profile",
+ "googlebusinessprofile",
+ "business_profile",
+ "businessprofile",
+ "google_maps",
+ "googlemaps",
+ "gmb",
+ "gbp",
+ "reddit",
+ "pinterest",
+ "pin",
+ "youtube",
+ "you_tube",
+ "yt",
+ "youtu",
+ "yt_channel",
+ "ytchannel",
+ "youtube_channel",
+ "youtubechannel",
+ "youtube_shorts",
+ "youtubeshorts",
+ "tiktok",
+ "tik_tok",
+ "tik",
+ "tok",
+ "wordpress",
+ "word_press",
+ "wp",
+ "ghost",
+ "hashnode",
+ "hash_node",
+ "devto",
+ "dev_to",
+ "dev.to",
+ "forem",
+ "blogger",
+ "blogspot",
+ "threads",
+ "thread",
+ "bluesky",
+ "blue_sky",
+ "bsky",
+ "telegram",
+ "tg",
+ "tme",
+ "whatsapp",
+ "whats_app",
+ "whats",
+ "wa"
+]postly_create_post12 fields changedInput schema / properties / email_subject / descriptionPrevious value: -"Required when targeting email/newsletter channels. Generate a concise subject line if the user asks to publish to email and enough context is available."New value: +"Subject line required when targeting email/newsletter channels."Input schema / properties / media / descriptionPrevious value: -"Already-hosted media objects for the post. If the source is a ChatGPT-generated image, selected file, local file, base64 data, or temporary URL, prefer the media_file fields so Postly imports the asset inside this same create/update action."New value: +"Already-hosted media objects for the post. Use the media_file fields instead for attached, generated, selected, local, base64, or temporary media that Postly must import during the create or update action."Input schema / properties / media_file / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the first attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."New value: +"Client-provided file reference or temporary URL for the first attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_10 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 10 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."New value: +"Client-provided file reference or temporary URL for the number 10 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_2 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 2 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."New value: +"Client-provided file reference or temporary URL for the number 2 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_3 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 3 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."New value: +"Client-provided file reference or temporary URL for the number 3 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_4 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 4 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."New value: +"Client-provided file reference or temporary URL for the number 4 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_5 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 5 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."New value: +"Client-provided file reference or temporary URL for the number 5 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_6 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 6 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."New value: +"Client-provided file reference or temporary URL for the number 6 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_7 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 7 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."New value: +"Client-provided file reference or temporary URL for the number 7 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_8 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 8 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."New value: +"Client-provided file reference or temporary URL for the number 8 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_9 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 9 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."New value: +"Client-provided file reference or temporary URL for the number 9 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."postly_update_post12 fields changedInput schema / properties / email_subject / descriptionPrevious value: -"Required when targeting email/newsletter channels. Generate a concise subject line if the user asks to publish to email and enough context is available."New value: +"Subject line required when targeting email/newsletter channels."Input schema / properties / media / descriptionPrevious value: -"Already-hosted media objects for the post. If the source is a ChatGPT-generated image, selected file, local file, base64 data, or temporary URL, prefer the media_file fields so Postly imports the asset inside this same create/update action."New value: +"Already-hosted media objects for the post. Use the media_file fields instead for attached, generated, selected, local, base64, or temporary media that Postly must import during the create or update action."Input schema / properties / media_file / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the first attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."New value: +"Client-provided file reference or temporary URL for the first attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_10 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 10 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."New value: +"Client-provided file reference or temporary URL for the number 10 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_2 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 2 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."New value: +"Client-provided file reference or temporary URL for the number 2 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_3 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 3 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."New value: +"Client-provided file reference or temporary URL for the number 3 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_4 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 4 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."New value: +"Client-provided file reference or temporary URL for the number 4 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_5 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 5 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."New value: +"Client-provided file reference or temporary URL for the number 5 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_6 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 6 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."New value: +"Client-provided file reference or temporary URL for the number 6 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_7 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 7 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."New value: +"Client-provided file reference or temporary URL for the number 7 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_8 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 8 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."New value: +"Client-provided file reference or temporary URL for the number 8 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_9 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 9 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."New value: +"Client-provided file reference or temporary URL for the number 9 attached, selected, or generated media file. Postly imports it during the create or update action. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."postly_upload_media1 field changedInput schema / properties / file / descriptionPrevious value: -"ChatGPT/OpenAI file reference for an attached, selected, or generated file. ChatGPT supplies this when the tool metadata marks file as an openai/fileParams field."New value: +"Client-provided file reference for an attached, selected, or generated file."postly_create_post52 fields changedInput schema / properties / audience_group / descriptionPrevious value: -"Audience group ID or IDs. Do not combine with target_platforms."New value: +"Audience group ID or IDs. Do not combine with target_platforms. You may also pass a single string on clients that support that shorthand."Input schema / properties / audience_group / itemsAdded value: +{
+ "type": "string"
+}Input schema / properties / audience_group / oneOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
-]Input schema / properties / audience_group / typeAdded value: +"array"Input schema / properties / email_targeting / additionalPropertiesPrevious value: -{
- "oneOf": [
- {
- "type": "string"
- },
- {
- "additionalProperties": true,
- "properties": {
- "id": {
- "description": "Email list, audience, publication, segment, or target ID.",
- "type": "string"
- },
- "name": {
- "type": "string"
- }
- },
- "required": [
- "id"
- ],
- "type": "object"
- },
- {
- "items": {
- "oneOf": [
- {
- "type": "string"
- },
- {
- "additionalProperties": true,
- "properties": {
- "id": {
- "description": "Email list, audience, publication, segment, or target ID.",
- "type": "string"
- },
- "name": {
- "type": "string"
- }
- },
- "required": [
- "id"
- ],
- "type": "object"
- }
- ]
- },
- "type": "array"
- }
- ]
-}New value: +trueInput schema / properties / email_targeting / descriptionPrevious value: -"Optional advanced email targeting map keyed by email integration ID. Each value is a resource ID, a resource object with id, or an array of those. Usually not needed when using email channel_id values returned by postly_list_social_accounts."New value: +"Optional advanced email targeting map keyed by email integration ID. Each value is a resource ID, a resource object with id, or an array of those. Usually not needed when using email channel_id values returned by postly_list_social_accounts. Property values may use multiple equivalent input shapes; the server normalizes them."Input schema / properties / media / items / properties / url / formatRemoved value: -"uri"Input schema / properties / media_file / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the first attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post."New value: +"ChatGPT/OpenAI file reference for the first attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file / oneOfRemoved value: -[
- {
- "additionalProperties": true,
- "properties": {
- "download_url": {
- "description": "Temporary download URL supplied by the MCP client.",
- "format": "uri",
- "type": "string"
- },
- "file_id": {
- "type": "string"
- },
- "file_name": {
- "type": "string"
- },
- "mime_type": {
- "type": "string"
- }
- },
- "required": [
- "download_url",
- "file_id"
- ],
- "type": "object"
- },
- {
- "description": "Compatibility fallback for clients that can only provide an http(s) URL. ChatGPT file params should normally provide the object shape.",
- "format": "uri",
- "pattern": "^https?://",
- "type": "string"
- }
-]Input schema / properties / media_file / typeAdded value: +"string"Input schema / properties / media_file_10 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 10 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post."New value: +"ChatGPT/OpenAI file reference for the number 10 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_10 / oneOfRemoved value: -[
- {
- "additionalProperties": true,
- "properties": {
- "download_url": {
- "description": "Temporary download URL supplied by the MCP client.",
- "format": "uri",
- "type": "string"
- },
- "file_id": {
- "type": "string"
- },
- "file_name": {
- "type": "string"
- },
- "mime_type": {
- "type": "string"
- }
- },
- "required": [
- "download_url",
- "file_id"
- ],
- "type": "object"
- },
- {
- "description": "Compatibility fallback for clients that can only provide an http(s) URL. ChatGPT file params should normally provide the object shape.",
- "format": "uri",
- "pattern": "^https?://",
- "type": "string"
- }
-]Input schema / properties / media_file_10 / typeAdded value: +"string"Input schema / properties / media_file_2 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 2 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post."New value: +"ChatGPT/OpenAI file reference for the number 2 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_2 / oneOfRemoved value: -[
- {
- "additionalProperties": true,
- "properties": {
- "download_url": {
- "description": "Temporary download URL supplied by the MCP client.",
- "format": "uri",
- "type": "string"
- },
- "file_id": {
- "type": "string"
- },
- "file_name": {
- "type": "string"
- },
- "mime_type": {
- "type": "string"
- }
- },
- "required": [
- "download_url",
- "file_id"
- ],
- "type": "object"
- },
- {
- "description": "Compatibility fallback for clients that can only provide an http(s) URL. ChatGPT file params should normally provide the object shape.",
- "format": "uri",
- "pattern": "^https?://",
- "type": "string"
- }
-]Input schema / properties / media_file_2 / typeAdded value: +"string"Input schema / properties / media_file_3 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 3 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post."New value: +"ChatGPT/OpenAI file reference for the number 3 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_3 / oneOfRemoved value: -[
- {
- "additionalProperties": true,
- "properties": {
- "download_url": {
- "description": "Temporary download URL supplied by the MCP client.",
- "format": "uri",
- "type": "string"
- },
- "file_id": {
- "type": "string"
- },
- "file_name": {
- "type": "string"
- },
- "mime_type": {
- "type": "string"
- }
- },
- "required": [
- "download_url",
- "file_id"
- ],
- "type": "object"
- },
- {
- "description": "Compatibility fallback for clients that can only provide an http(s) URL. ChatGPT file params should normally provide the object shape.",
- "format": "uri",
- "pattern": "^https?://",
- "type": "string"
- }
-]Input schema / properties / media_file_3 / typeAdded value: +"string"Input schema / properties / media_file_4 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 4 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post."New value: +"ChatGPT/OpenAI file reference for the number 4 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_4 / oneOfRemoved value: -[
- {
- "additionalProperties": true,
- "properties": {
- "download_url": {
- "description": "Temporary download URL supplied by the MCP client.",
- "format": "uri",
- "type": "string"
- },
- "file_id": {
- "type": "string"
- },
- "file_name": {
- "type": "string"
- },
- "mime_type": {
- "type": "string"
- }
- },
- "required": [
- "download_url",
- "file_id"
- ],
- "type": "object"
- },
- {
- "description": "Compatibility fallback for clients that can only provide an http(s) URL. ChatGPT file params should normally provide the object shape.",
- "format": "uri",
- "pattern": "^https?://",
- "type": "string"
- }
-]Input schema / properties / media_file_4 / typeAdded value: +"string"Input schema / properties / media_file_5 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 5 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post."New value: +"ChatGPT/OpenAI file reference for the number 5 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_5 / oneOfRemoved value: -[
- {
- "additionalProperties": true,
- "properties": {
- "download_url": {
- "description": "Temporary download URL supplied by the MCP client.",
- "format": "uri",
- "type": "string"
- },
- "file_id": {
- "type": "string"
- },
- "file_name": {
- "type": "string"
- },
- "mime_type": {
- "type": "string"
- }
- },
- "required": [
- "download_url",
- "file_id"
- ],
- "type": "object"
- },
- {
- "description": "Compatibility fallback for clients that can only provide an http(s) URL. ChatGPT file params should normally provide the object shape.",
- "format": "uri",
- "pattern": "^https?://",
- "type": "string"
- }
-]Input schema / properties / media_file_5 / typeAdded value: +"string"Input schema / properties / media_file_6 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 6 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post."New value: +"ChatGPT/OpenAI file reference for the number 6 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_6 / oneOfRemoved value: -[
- {
- "additionalProperties": true,
- "properties": {
- "download_url": {
- "description": "Temporary download URL supplied by the MCP client.",
- "format": "uri",
- "type": "string"
- },
- "file_id": {
- "type": "string"
- },
- "file_name": {
- "type": "string"
- },
- "mime_type": {
- "type": "string"
- }
- },
- "required": [
- "download_url",
- "file_id"
- ],
- "type": "object"
- },
- {
- "description": "Compatibility fallback for clients that can only provide an http(s) URL. ChatGPT file params should normally provide the object shape.",
- "format": "uri",
- "pattern": "^https?://",
- "type": "string"
- }
-]Input schema / properties / media_file_6 / typeAdded value: +"string"Input schema / properties / media_file_7 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 7 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post."New value: +"ChatGPT/OpenAI file reference for the number 7 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_7 / oneOfRemoved value: -[
- {
- "additionalProperties": true,
- "properties": {
- "download_url": {
- "description": "Temporary download URL supplied by the MCP client.",
- "format": "uri",
- "type": "string"
- },
- "file_id": {
- "type": "string"
- },
- "file_name": {
- "type": "string"
- },
- "mime_type": {
- "type": "string"
- }
- },
- "required": [
- "download_url",
- "file_id"
- ],
- "type": "object"
- },
- {
- "description": "Compatibility fallback for clients that can only provide an http(s) URL. ChatGPT file params should normally provide the object shape.",
- "format": "uri",
- "pattern": "^https?://",
- "type": "string"
- }
-]Input schema / properties / media_file_7 / typeAdded value: +"string"Input schema / properties / media_file_8 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 8 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post."New value: +"ChatGPT/OpenAI file reference for the number 8 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_8 / oneOfRemoved value: -[
- {
- "additionalProperties": true,
- "properties": {
- "download_url": {
- "description": "Temporary download URL supplied by the MCP client.",
- "format": "uri",
- "type": "string"
- },
- "file_id": {
- "type": "string"
- },
- "file_name": {
- "type": "string"
- },
- "mime_type": {
- "type": "string"
- }
- },
- "required": [
- "download_url",
- "file_id"
- ],
- "type": "object"
- },
- {
- "description": "Compatibility fallback for clients that can only provide an http(s) URL. ChatGPT file params should normally provide the object shape.",
- "format": "uri",
- "pattern": "^https?://",
- "type": "string"
- }
-]Input schema / properties / media_file_8 / typeAdded value: +"string"Input schema / properties / media_file_9 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 9 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post."New value: +"ChatGPT/OpenAI file reference for the number 9 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_9 / oneOfRemoved value: -[
- {
- "additionalProperties": true,
- "properties": {
- "download_url": {
- "description": "Temporary download URL supplied by the MCP client.",
- "format": "uri",
- "type": "string"
- },
- "file_id": {
- "type": "string"
- },
- "file_name": {
- "type": "string"
- },
- "mime_type": {
- "type": "string"
- }
- },
- "required": [
- "download_url",
- "file_id"
- ],
- "type": "object"
- },
- {
- "description": "Compatibility fallback for clients that can only provide an http(s) URL. ChatGPT file params should normally provide the object shape.",
- "format": "uri",
- "pattern": "^https?://",
- "type": "string"
- }
-]Input schema / properties / media_file_9 / typeAdded value: +"string"Input schema / properties / one_off_schedule / properties / one_off_date / formatRemoved value: -"date"Input schema / properties / one_off_schedule / properties / time / patternRemoved value: -"^\\d{1,2}:\\d{2}(:\\d{2}(\\.\\d{1,6})?)?$"Input schema / properties / platform_posts / items / properties / media_override / items / properties / url / formatRemoved value: -"uri"Input schema / properties / platform_posts / items / properties / settings / properties / one_off_schedule / properties / one_off_date / formatRemoved value: -"date"Input schema / properties / platform_posts / items / properties / settings / properties / one_off_schedule / properties / time / patternRemoved value: -"^\\d{1,2}:\\d{2}(:\\d{2}(\\.\\d{1,6})?)?$"Input schema / properties / platform_posts / items / properties / settings / properties / recurring_schedule / properties / end_date / formatRemoved value: -"date"Input schema / properties / platform_posts / items / properties / settings / properties / recurring_schedule / properties / start_date / formatRemoved value: -"date"Input schema / properties / platform_posts / items / properties / settings / properties / recurring_schedule / properties / time / patternRemoved value: -"^\\d{1,2}:\\d{2}(:\\d{2}(\\.\\d{1,6})?)?$"Input schema / properties / recurring_schedule / properties / end_date / formatRemoved value: -"date"Input schema / properties / recurring_schedule / properties / start_date / formatRemoved value: -"date"Input schema / properties / recurring_schedule / properties / time / patternRemoved value: -"^\\d{1,2}:\\d{2}(:\\d{2}(\\.\\d{1,6})?)?$"Input schema / properties / target_platforms / descriptionPrevious value: -"Social platform names, email/newsletter, provider names, or channel IDs. Use \"all\" to target all connected publishing targets in the workspace. Email targets require email_subject and text."New value: +"Social platform names, email/newsletter, provider names, or channel IDs. Use \"all\" to target all connected publishing targets in the workspace. Email targets require email_subject and text. You may also pass a single string on clients that support that shorthand."Input schema / properties / target_platforms / itemsAdded value: +{
+ "type": "string"
+}Input schema / properties / target_platforms / oneOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
-]Input schema / properties / target_platforms / typeAdded value: +"array"postly_update_post52 fields changedInput schema / properties / audience_group / descriptionPrevious value: -"Audience group ID or IDs. Do not combine with target_platforms."New value: +"Audience group ID or IDs. Do not combine with target_platforms. You may also pass a single string on clients that support that shorthand."Input schema / properties / audience_group / itemsAdded value: +{
+ "type": "string"
+}Input schema / properties / audience_group / oneOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
-]Input schema / properties / audience_group / typeAdded value: +"array"Input schema / properties / email_targeting / additionalPropertiesPrevious value: -{
- "oneOf": [
- {
- "type": "string"
- },
- {
- "additionalProperties": true,
- "properties": {
- "id": {
- "description": "Email list, audience, publication, segment, or target ID.",
- "type": "string"
- },
- "name": {
- "type": "string"
- }
- },
- "required": [
- "id"
- ],
- "type": "object"
- },
- {
- "items": {
- "oneOf": [
- {
- "type": "string"
- },
- {
- "additionalProperties": true,
- "properties": {
- "id": {
- "description": "Email list, audience, publication, segment, or target ID.",
- "type": "string"
- },
- "name": {
- "type": "string"
- }
- },
- "required": [
- "id"
- ],
- "type": "object"
- }
- ]
- },
- "type": "array"
- }
- ]
-}New value: +trueInput schema / properties / email_targeting / descriptionPrevious value: -"Optional advanced email targeting map keyed by email integration ID. Each value is a resource ID, a resource object with id, or an array of those. Usually not needed when using email channel_id values returned by postly_list_social_accounts."New value: +"Optional advanced email targeting map keyed by email integration ID. Each value is a resource ID, a resource object with id, or an array of those. Usually not needed when using email channel_id values returned by postly_list_social_accounts. Property values may use multiple equivalent input shapes; the server normalizes them."Input schema / properties / media / items / properties / url / formatRemoved value: -"uri"Input schema / properties / media_file / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the first attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post."New value: +"ChatGPT/OpenAI file reference for the first attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file / oneOfRemoved value: -[
- {
- "additionalProperties": true,
- "properties": {
- "download_url": {
- "description": "Temporary download URL supplied by the MCP client.",
- "format": "uri",
- "type": "string"
- },
- "file_id": {
- "type": "string"
- },
- "file_name": {
- "type": "string"
- },
- "mime_type": {
- "type": "string"
- }
- },
- "required": [
- "download_url",
- "file_id"
- ],
- "type": "object"
- },
- {
- "description": "Compatibility fallback for clients that can only provide an http(s) URL. ChatGPT file params should normally provide the object shape.",
- "format": "uri",
- "pattern": "^https?://",
- "type": "string"
- }
-]Input schema / properties / media_file / typeAdded value: +"string"Input schema / properties / media_file_10 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 10 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post."New value: +"ChatGPT/OpenAI file reference for the number 10 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_10 / oneOfRemoved value: -[
- {
- "additionalProperties": true,
- "properties": {
- "download_url": {
- "description": "Temporary download URL supplied by the MCP client.",
- "format": "uri",
- "type": "string"
- },
- "file_id": {
- "type": "string"
- },
- "file_name": {
- "type": "string"
- },
- "mime_type": {
- "type": "string"
- }
- },
- "required": [
- "download_url",
- "file_id"
- ],
- "type": "object"
- },
- {
- "description": "Compatibility fallback for clients that can only provide an http(s) URL. ChatGPT file params should normally provide the object shape.",
- "format": "uri",
- "pattern": "^https?://",
- "type": "string"
- }
-]Input schema / properties / media_file_10 / typeAdded value: +"string"Input schema / properties / media_file_2 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 2 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post."New value: +"ChatGPT/OpenAI file reference for the number 2 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_2 / oneOfRemoved value: -[
- {
- "additionalProperties": true,
- "properties": {
- "download_url": {
- "description": "Temporary download URL supplied by the MCP client.",
- "format": "uri",
- "type": "string"
- },
- "file_id": {
- "type": "string"
- },
- "file_name": {
- "type": "string"
- },
- "mime_type": {
- "type": "string"
- }
- },
- "required": [
- "download_url",
- "file_id"
- ],
- "type": "object"
- },
- {
- "description": "Compatibility fallback for clients that can only provide an http(s) URL. ChatGPT file params should normally provide the object shape.",
- "format": "uri",
- "pattern": "^https?://",
- "type": "string"
- }
-]Input schema / properties / media_file_2 / typeAdded value: +"string"Input schema / properties / media_file_3 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 3 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post."New value: +"ChatGPT/OpenAI file reference for the number 3 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_3 / oneOfRemoved value: -[
- {
- "additionalProperties": true,
- "properties": {
- "download_url": {
- "description": "Temporary download URL supplied by the MCP client.",
- "format": "uri",
- "type": "string"
- },
- "file_id": {
- "type": "string"
- },
- "file_name": {
- "type": "string"
- },
- "mime_type": {
- "type": "string"
- }
- },
- "required": [
- "download_url",
- "file_id"
- ],
- "type": "object"
- },
- {
- "description": "Compatibility fallback for clients that can only provide an http(s) URL. ChatGPT file params should normally provide the object shape.",
- "format": "uri",
- "pattern": "^https?://",
- "type": "string"
- }
-]Input schema / properties / media_file_3 / typeAdded value: +"string"Input schema / properties / media_file_4 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 4 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post."New value: +"ChatGPT/OpenAI file reference for the number 4 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_4 / oneOfRemoved value: -[
- {
- "additionalProperties": true,
- "properties": {
- "download_url": {
- "description": "Temporary download URL supplied by the MCP client.",
- "format": "uri",
- "type": "string"
- },
- "file_id": {
- "type": "string"
- },
- "file_name": {
- "type": "string"
- },
- "mime_type": {
- "type": "string"
- }
- },
- "required": [
- "download_url",
- "file_id"
- ],
- "type": "object"
- },
- {
- "description": "Compatibility fallback for clients that can only provide an http(s) URL. ChatGPT file params should normally provide the object shape.",
- "format": "uri",
- "pattern": "^https?://",
- "type": "string"
- }
-]Input schema / properties / media_file_4 / typeAdded value: +"string"Input schema / properties / media_file_5 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 5 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post."New value: +"ChatGPT/OpenAI file reference for the number 5 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_5 / oneOfRemoved value: -[
- {
- "additionalProperties": true,
- "properties": {
- "download_url": {
- "description": "Temporary download URL supplied by the MCP client.",
- "format": "uri",
- "type": "string"
- },
- "file_id": {
- "type": "string"
- },
- "file_name": {
- "type": "string"
- },
- "mime_type": {
- "type": "string"
- }
- },
- "required": [
- "download_url",
- "file_id"
- ],
- "type": "object"
- },
- {
- "description": "Compatibility fallback for clients that can only provide an http(s) URL. ChatGPT file params should normally provide the object shape.",
- "format": "uri",
- "pattern": "^https?://",
- "type": "string"
- }
-]Input schema / properties / media_file_5 / typeAdded value: +"string"Input schema / properties / media_file_6 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 6 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post."New value: +"ChatGPT/OpenAI file reference for the number 6 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_6 / oneOfRemoved value: -[
- {
- "additionalProperties": true,
- "properties": {
- "download_url": {
- "description": "Temporary download URL supplied by the MCP client.",
- "format": "uri",
- "type": "string"
- },
- "file_id": {
- "type": "string"
- },
- "file_name": {
- "type": "string"
- },
- "mime_type": {
- "type": "string"
- }
- },
- "required": [
- "download_url",
- "file_id"
- ],
- "type": "object"
- },
- {
- "description": "Compatibility fallback for clients that can only provide an http(s) URL. ChatGPT file params should normally provide the object shape.",
- "format": "uri",
- "pattern": "^https?://",
- "type": "string"
- }
-]Input schema / properties / media_file_6 / typeAdded value: +"string"Input schema / properties / media_file_7 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 7 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post."New value: +"ChatGPT/OpenAI file reference for the number 7 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_7 / oneOfRemoved value: -[
- {
- "additionalProperties": true,
- "properties": {
- "download_url": {
- "description": "Temporary download URL supplied by the MCP client.",
- "format": "uri",
- "type": "string"
- },
- "file_id": {
- "type": "string"
- },
- "file_name": {
- "type": "string"
- },
- "mime_type": {
- "type": "string"
- }
- },
- "required": [
- "download_url",
- "file_id"
- ],
- "type": "object"
- },
- {
- "description": "Compatibility fallback for clients that can only provide an http(s) URL. ChatGPT file params should normally provide the object shape.",
- "format": "uri",
- "pattern": "^https?://",
- "type": "string"
- }
-]Input schema / properties / media_file_7 / typeAdded value: +"string"Input schema / properties / media_file_8 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 8 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post."New value: +"ChatGPT/OpenAI file reference for the number 8 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_8 / oneOfRemoved value: -[
- {
- "additionalProperties": true,
- "properties": {
- "download_url": {
- "description": "Temporary download URL supplied by the MCP client.",
- "format": "uri",
- "type": "string"
- },
- "file_id": {
- "type": "string"
- },
- "file_name": {
- "type": "string"
- },
- "mime_type": {
- "type": "string"
- }
- },
- "required": [
- "download_url",
- "file_id"
- ],
- "type": "object"
- },
- {
- "description": "Compatibility fallback for clients that can only provide an http(s) URL. ChatGPT file params should normally provide the object shape.",
- "format": "uri",
- "pattern": "^https?://",
- "type": "string"
- }
-]Input schema / properties / media_file_8 / typeAdded value: +"string"Input schema / properties / media_file_9 / descriptionPrevious value: -"ChatGPT/OpenAI file reference for the number 9 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post."New value: +"ChatGPT/OpenAI file reference for the number 9 attached, selected, or generated media file. Prefer this over calling postly_upload_media separately when creating or updating a post. Pass an HTTP(S) or temporary URL here. Some clients may also send a file-reference object."Input schema / properties / media_file_9 / oneOfRemoved value: -[
- {
- "additionalProperties": true,
- "properties": {
- "download_url": {
- "description": "Temporary download URL supplied by the MCP client.",
- "format": "uri",
- "type": "string"
- },
- "file_id": {
- "type": "string"
- },
- "file_name": {
- "type": "string"
- },
- "mime_type": {
- "type": "string"
- }
- },
- "required": [
- "download_url",
- "file_id"
- ],
- "type": "object"
- },
- {
- "description": "Compatibility fallback for clients that can only provide an http(s) URL. ChatGPT file params should normally provide the object shape.",
- "format": "uri",
- "pattern": "^https?://",
- "type": "string"
- }
-]Input schema / properties / media_file_9 / typeAdded value: +"string"Input schema / properties / one_off_schedule / properties / one_off_date / formatRemoved value: -"date"Input schema / properties / one_off_schedule / properties / time / patternRemoved value: -"^\\d{1,2}:\\d{2}(:\\d{2}(\\.\\d{1,6})?)?$"Input schema / properties / platform_posts / items / properties / media_override / items / properties / url / formatRemoved value: -"uri"Input schema / properties / platform_posts / items / properties / settings / properties / one_off_schedule / properties / one_off_date / formatRemoved value: -"date"Input schema / properties / platform_posts / items / properties / settings / properties / one_off_schedule / properties / time / patternRemoved value: -"^\\d{1,2}:\\d{2}(:\\d{2}(\\.\\d{1,6})?)?$"Input schema / properties / platform_posts / items / properties / settings / properties / recurring_schedule / properties / end_date / formatRemoved value: -"date"Input schema / properties / platform_posts / items / properties / settings / properties / recurring_schedule / properties / start_date / formatRemoved value: -"date"Input schema / properties / platform_posts / items / properties / settings / properties / recurring_schedule / properties / time / patternRemoved value: -"^\\d{1,2}:\\d{2}(:\\d{2}(\\.\\d{1,6})?)?$"Input schema / properties / recurring_schedule / properties / end_date / formatRemoved value: -"date"Input schema / properties / recurring_schedule / properties / start_date / formatRemoved value: -"date"Input schema / properties / recurring_schedule / properties / time / patternRemoved value: -"^\\d{1,2}:\\d{2}(:\\d{2}(\\.\\d{1,6})?)?$"Input schema / properties / target_platforms / descriptionPrevious value: -"Social platform names, email/newsletter, provider names, or channel IDs. Use \"all\" to target all connected publishing targets in the workspace. Email targets require email_subject and text."New value: +"Social platform names, email/newsletter, provider names, or channel IDs. Use \"all\" to target all connected publishing targets in the workspace. Email targets require email_subject and text. You may also pass a single string on clients that support that shorthand."Input schema / properties / target_platforms / itemsAdded value: +{
+ "type": "string"
+}Input schema / properties / target_platforms / oneOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
-]Input schema / properties / target_platforms / typeAdded value: +"array"postly_upload_media1 field changedInput schema / properties / file / properties / download_url / formatRemoved value: -"uri"postly_validate_post11 fields changedInput schema / properties / media / items / properties / url / formatRemoved value: -"uri"Input schema / properties / platform_posts / items / properties / media_override / items / properties / url / formatRemoved value: -"uri"Input schema / properties / platform_posts / items / properties / settings / properties / one_off_schedule / properties / one_off_date / formatRemoved value: -"date"Input schema / properties / platform_posts / items / properties / settings / properties / one_off_schedule / properties / time / patternRemoved value: -"^\\d{1,2}:\\d{2}(:\\d{2}(\\.\\d{1,6})?)?$"Input schema / properties / platform_posts / items / properties / settings / properties / recurring_schedule / properties / end_date / formatRemoved value: -"date"Input schema / properties / platform_posts / items / properties / settings / properties / recurring_schedule / properties / start_date / formatRemoved value: -"date"Input schema / properties / platform_posts / items / properties / settings / properties / recurring_schedule / properties / time / patternRemoved value: -"^\\d{1,2}:\\d{2}(:\\d{2}(\\.\\d{1,6})?)?$"Input schema / properties / target_platforms / descriptionPrevious value: -"Optional platform names, email/newsletter, provider names, or channel IDs. Use \"all\" or omit to validate against all connected workspace publishing targets."New value: +"Optional platform names, email/newsletter, provider names, or channel IDs. Use \"all\" or omit to validate against all connected workspace publishing targets. You may also pass a single string on clients that support that shorthand."Input schema / properties / target_platforms / itemsAdded value: +{
+ "type": "string"
+}Input schema / properties / target_platforms / oneOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
-]Input schema / properties / target_platforms / typeAdded value: +"array"postly_create_post8 fields changedOutput schema / properties / agent_guidanceAdded value: +{
+ "type": "string"
+}Output schema / properties / blocked_platformsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / missing_requirementsAdded value: +{
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / next_stepsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / promptAdded value: +{
+ "type": "string"
+}Output schema / properties / ready_platformsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / requires_user_inputAdded value: +{
+ "type": "boolean"
+}Output schema / properties / statusAdded value: +{
+ "type": "string"
+}postly_delete_post8 fields changedOutput schema / properties / agent_guidanceAdded value: +{
+ "type": "string"
+}Output schema / properties / blocked_platformsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / missing_requirementsAdded value: +{
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / next_stepsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / promptAdded value: +{
+ "type": "string"
+}Output schema / properties / ready_platformsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / requires_user_inputAdded value: +{
+ "type": "boolean"
+}Output schema / properties / statusAdded value: +{
+ "type": "string"
+}postly_update_post8 fields changedOutput schema / properties / agent_guidanceAdded value: +{
+ "type": "string"
+}Output schema / properties / blocked_platformsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / missing_requirementsAdded value: +{
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / next_stepsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / promptAdded value: +{
+ "type": "string"
+}Output schema / properties / ready_platformsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / requires_user_inputAdded value: +{
+ "type": "boolean"
+}Output schema / properties / statusAdded value: +{
+ "type": "string"
+}
Add one secure layer between your agents and this server.