Social Post Flow

Create Bulk Posts Tool

create-bulk-posts-tool

Destructive

Create and schedule multiple social media posts in a single call. Each item in posts is a full post payload matching the single-post create schema.

IMPORTANT:

Bulk is best-effort: the response has both data (successful posts) and errors (per-item failures with the original index). A 200 does not mean every item succeeded — always check errors.
Per-request cap is set by the server (default 50 items). Split larger batches client-side.
Always call list-profiles-tool first to get valid profile_ids for each item.
Same per-item rules as create-post-tool apply: text required except for stories, media_urls required for image/story/pin/tiktok, etc.

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": {
      "posts": "<posts>"
    },
    "name": "create-bulk-posts-tool"
  }
}

Input Schema

Name	Required	Description	Default
`posts`	Yes	Array of post payloads. Each item matches the create-post-tool schema.

Output Schema

Name	Required	Description	Default
`data`	No
`errors`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

changedInput schema / properties / posts / description

Previous value: -"Array of post payloads. Each item matches the create_post schema."New value: +"Array of post payloads. Each item matches the create-post-tool schema."

First observedOct 30, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false, destructiveHint=true and openWorldHint=true; the description goes well beyond by disclosing best-effort partial failure semantics and warning that a 200 does not mean every item succeeded. The server-side cap (default 50) and the need to inspect `errors` are exactly the behavioral traits an agent cannot infer 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.

Conciseness4/5

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

Front-loaded with the purpose, then a clearly delineated IMPORTANT block for the caveats, so a reader can stop after one sentence if they only need the gist. The final bullet restating text/media_urls requirements partially duplicates the schema, which is the only wasted line.

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 batch mutation tool with an output schema, this covers everything an agent needs: what it does, the prerequisite lookup, the batch-size limit, and how to interpret a partially successful response. The mention of `data` and `errors` is compatible with the output schema rather than a substitute for it.

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 baseline is 3, but the description adds meaning the schema cannot express: that each array element is a full post payload matching the single-post create schema, and that a server-side cap limits batch size. The per-item field rules it cites largely duplicate existing schema descriptions, which keeps it from a 5.

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 gives a specific verb (create and schedule), resource (social media posts), and scope (multiple in a single call), which cleanly separates it from create-post-tool. An agent can tell from the first line that this is the batch variant rather than the single-item one.

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?

It states prerequisites explicitly ('Always call list-profiles-tool first') and gives a concrete handling rule for oversized batches ('Split larger batches client-side'). It defers per-item rules to create-post-tool rather than restating them, which is good routing, though it never says outright 'use create-post-tool for a single post' as an exclusion.

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

All Social Post Flow 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?