Postly MCP

Create Post

postly_create_post

Destructive

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.
`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.
`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.
`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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`code`	No
`data`	No
`prompt`	No
`status`	No
`message`	No
`next_steps`	No
`agent_guidance`	No
`ready_platforms`	No
`blocked_platforms`	No
`requires_user_input`	No
`missing_requirements`	No

TDQS

B3.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already signal a non-read-only, destructive, non-idempotent write, and the description adds genuinely useful behavioral context: three execution modes (create, queue, schedule), same-action media import, and a return payload of mutation result, platform readiness, blockers, and follow-up data. Nothing in the text contradicts 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: core action, accepted input categories, and return semantics. The most important verb phrase is front-loaded, and the length is proportionate to a tool with 29 parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's high complexity and the presence of an output schema, the description adequately covers action modes, input categories, and return characteristics. It is incomplete on routing context (no suggestion to validate first or how to distinguish create from update/queue scenarios), and 'any required follow-up data' is vague without an example.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

At 83% schema description coverage, the input schema carries most of the parameter burden, so the baseline is 3. The description adds only a high-level grouping (content, target selections, schedules, platform settings, media references) rather than parameter-level detail, which is helpful but not essential.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb-resource pair ('Creates, queues, or schedules a Postly post') and scopes the tool to social and email/newsletter targets, which is clear and actionable. It does not explicitly name a sibling tool to distinguish from, but the create-over-update/delete verb contrast is implicit and the accepted-input summary reinforces the tool's role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no explicit when-to-use guidance, exclusions, or alternatives such as postly_validate_post for pre-checking or postly_update_post for modifying an existing post. The only related routing hints ('Call postly_get_channel_schema', 'postly_list_social_accounts' references) live inside the input schema, not in the description itself.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Postly MCP tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0

Disambiguation5/5

Each tool targets a distinct resource and action: posts, analytics, media, schema, validation, targets, and organizational metadata are clearly separated. Even similar getters (post, post_status, post_analytics, publishing_activity) have explicit scopes that prevent misselection.

Naming Consistency5/5

All tools follow the consistent `postly_<verb>_<noun>` pattern in lowercase snake_case. Verbs like create, get, list, update, delete, upload, validate, and resolve are used uniformly, making the API predictable and easy to navigate.

Tool Count4/5

At 18 tools, the set is slightly above the typical 3-15 range, but every tool serves a distinct purpose in the social media publishing lifecycle. The count is justified for a comprehensive MCP, though a few could potentially be consolidated without loss of clarity.

Completeness5/5

The tool surface covers the full post lifecycle (create, read, update, delete, list), scheduling, publishing activity, analytics for both accounts and posts, media upload, channel schema validation, and target resolution. No obvious dead ends or critical missing operations for the intended domain.

Resources

Need Help?