Vibeking

Propose a social post

propose_post

Idempotent

Propose a social post as a draft (post_draft) or scheduled (post_schedule) on one or more channels. Nothing is published: an owner or admin approves or rejects it in Vibeking, never through the MCP. Expires after 72 hours. After approval Vibeking creates the draft or scheduled post at once (never publishes immediately); a scheduled time that has passed by then fails. A post cannot be cancelled or undone through Vibeking. Regie and Enterprise plans only (error code plan); every channel needs the posting right (error code rights: use Extend rights).

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": {
      "site_id": "<site_id>",
      "action": "<action>",
      "text": "<text>",
      "channels": "<channels>",
      "reason": "<reason>"
    },
    "name": "propose_post"
  }
}

Input Schema

Name	Required	Description
`text`	Yes	Post text.
`action`	Yes	post_draft or post_schedule.
`reason`	Yes	Why the agent proposes this post.
`site_id`	Yes	The site id, as returned by list_sites.
`channels`	Yes	Channel ids, as returned by get_social.
`media_urls`	No	Optional public https URLs of images or videos to attach.
`scheduled_for`	No	ISO time; required for post_schedule.
`expected_impact`	No	Expected effect, shown to the approver.
`idempotency_key`	No	Optional key; the same key returns the same proposal.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 10, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations (readOnly=false, idempotent=true, destructive=false), it discloses the whole lifecycle: nothing is published, approval happens by an owner/admin in Vibeking and never through the MCP, proposals expire after 72 hours, approval materializes the draft/scheduled post immediately, a stale scheduled time fails, and cancellation/undo is impossible. It also names the plan and rights error codes, which is exactly the kind of operational context annotations cannot carry.

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?

The description is dense but front-loaded, leading with what the tool does and following with constraints and error codes in a logical order. There is mild redundancy between 'Nothing is published' and 'never publishes immediately', which keeps it from a perfect score.

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

Completeness4/5

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

For a 9-parameter, 5-required mutation with no output schema, the description covers approval flow, expiry, timing edge cases, plan/rights gating, and idempotency. The notable gap is what a successful call returns and how the agent should later check a proposal's status, which the description never addresses.

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?

Schema description coverage is 100%, so the schema already documents all nine parameters, including that scheduled_for is required for post_schedule. The description adds the cross-field timing rule (a scheduled time already past at approval time fails), but otherwise restates rather than enriches parameter meaning, so the baseline of 3 applies.

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?

The opening sentence names a specific verb (propose) and resource (social post) plus the two possible action modes (post_draft / post_schedule) and the channel scope. This is clearly distinguishable from siblings such as propose_ad_change or propose_undo because the resource being proposed is stated explicitly.

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

Usage Guidelines4/5

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

The description gives strong preconditions for use: Regie/Enterprise plans only, posting rights required per channel, and the 72-hour approval window. It does not explicitly route the agent away from sibling proposal tools or say what to do instead when the plan/rights check fails beyond citing error codes, so it stops short of full when/when-not guidance.

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

All Vibeking 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.

Resources

Need Help?