Socialync

publish_now

Destructive

Publish a post IMMEDIATELY to one or more platforms. PREFERRED tool when the user is interacting with you in chat -- it skips the Socialync drafts page entirely. If the user has switched on the publish confirmation dialog in Socialync settings (off by default) and their client supports MCP elicitation, Socialync shows the user a confirmation dialog with the exact post before publishing: a decline rejects it and comes back as success false with consent "declined" (never retry; ask the user), and no answer within 40 seconds counts as the confirmation the user already gave you in chat. On other clients there is NO dialog and this publishes as soon as you call it. Either way, before calling you MUST show the user the exact caption, platforms, and images you will post, and get their explicit confirmation in the chat. Treat this the same way you would treat sending an email on someone's behalf. If the user uploaded image(s) to you in the conversation, pass them via base64Images (preferred) -- Socialync will host them for you. If the user gave you a public image URL, pass it via imageUrls. Returns per-platform success/failure. Same validation as create_post_draft: text and/or up to 10 images total (URLs + base64 combined), Instagram requires at least one image, no TikTok/YouTube (use publish_scheduled for those), 10/day cap per profile (platform-security mechanism to keep accounts under spam-detection thresholds). ALWAYS run validate_post with these same arguments FIRST and resolve every error it reports before calling this.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "caption": "<caption>"
    },
    "name": "publish_now"
  }
}

Input Schema

Name	Required	Description
`caption`	Yes	Post caption/text content. Will be published as-is.
`imageUrls`	No	Up to 10 publicly fetchable https image URLs. Combined with base64Images cannot exceed 10 total.
`platforms`	No	Platforms to publish to. One or more of: facebook, instagram, linkedin, twitter, threads, bluesky. Pass platforms OR audienceId, not both.
`profileId`	No	The Socialync profile to post from. Call list_profiles to see the profiles you can post to. Required only when this connection is authorized for more than one profile; if exactly one is authorized it is used automatically.
`audienceId`	No	A saved audience id from list_audiences. Expands to the platforms that audience reaches on the target profile; any member it cannot reach (other brand, needs reconnect, secondary account without its primary) is reported back in skippedMembers instead of failing the call. Use INSTEAD of platforms, never together.
`base64Images`	No	Up to 10 images encoded as base64 strings (data URIs like "data:image/png;base64,iVBOR..." are also accepted). Use this when the user has uploaded image(s) to you directly in the conversation -- Socialync hosts them on its own media storage. Per-image cap: 8MB. Supported formats: jpeg, png, webp, gif. Combined with imageUrls cannot exceed 10 total.
`firstComment`	No	Optional "first comment": text Socialync posts as a comment under the post right after it publishes -- the classic home for hashtags and links, keeps the caption clean. One string for all platforms. Supported: instagram, threads, twitter, youtube, linkedin, bluesky. Facebook and TikTok do not support it (they record it as skipped; the post itself is unaffected). Per-platform comment length limits are enforced at draft time: instagram 2200, threads 500, twitter 280, youtube 10000, linkedin 1250, bluesky 300. A failed comment never fails the post.
`exceptPlatforms`	No	Only valid together with audienceId: platforms to leave out of the expanded audience for this one post (e.g. exclude tiktok when the post has no video).
`platformSpecificSettings`	No	Per-platform caption overrides if you want different wording per platform.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 12, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Adds substantial context beyond annotations: the conditional confirmation dialog, decline/40-second-timeout semantics, the no-dialog behavior on other clients, required in-chat confirmation, and the 10/day anti-spam cap. However it does not describe the return shape in detail (only 'per-platform success/failure') and some of the dialog behavior overlaps with what an agent might expect given openWorldHint; the safety framing is consistent with destructiveHint=true, not contradictory. Given annotations already flag destructive and open-world, the description carries extra value but leaves the response contract thin.

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?

Front-loads the critical IMMEDIATE/PREFERRED framing and confirmation obligation. It is dense but each block is purposeful; the 40-second timeout and email-analogy sentences are slightly verbose but earn their place for a destructive publish.

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

Completeness5/5

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

For a destructive, open-world publish tool with 9 params and no output schema, the description covers the full lifecycle: pre-call validation, user confirmation, image handling, quota limits, and per-platform outcomes. Nothing an agent needs to call safely is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents each parameter. The description still adds real guidance: prefer base64Images when the user uploaded images, use imageUrls for public URLs, and the combined 10-image cap with Instagram's image requirement. It doesn't fully restate profileId/audienceId/exceptPlatforms interplay (that lives in the schema), keeping it a notch above baseline.

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

Purpose5/5

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

Opens with a specific verb and resource ('Publish a post IMMEDIATELY to one or more platforms') and immediately distinguishes itself from siblings by noting it 'skips the Socialync drafts page entirely' and that TikTok/YouTube should use publish_scheduled. An agent can route between publish_now and publish_scheduled without opening either schema.

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

Usage Guidelines5/5

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

Explicitly names when to use this tool ('PREFERRED tool when the user is interacting with you in chat'), the prerequisite ('ALWAYS run validate_post with these same arguments FIRST'), and the alternative for excluded platforms. Declined-confirmation handling and the 'never retry; ask the user' rule leave nothing to inference.

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

All Socialync tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.