Posteady

Create a carousel

create_carousel

Idempotent

Create a carousel (multi-slide image post) in Posteady from a topic, source text, or a link. Posteady writes the slide copy and designs the slides with stock photos, the template's own images, or no photos; each carousel costs 20 credits. This accepts the request and returns a carouselId with status queued; generation takes about 1-3 minutes, and get_carousel reports the status until it is completed or failed. Completed carousels include image mediaIds that publish_post and schedule_post accept (Instagram takes up to 20). Template and brand IDs come from list_carousel_options. Repeating a call with the same requestId returns the same carousel, and a new requestId creates a new one.

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": {
      "requestId": "<requestId>"
    },
    "name": "create_carousel"
  }
}

Input Schema

Name	Required	Description
`url`	No	A public link to use as source material (article, blog post, or a social post). Posteady reads its text and images. Exactly one of topic, text, or url is required.
`text`	No	Source material to turn into a carousel (an article, notes, a script). Posteady plans the slides from this text. Exactly one of topic, text, or url is required.
`topic`	No	What the carousel should be about, in one or a few sentences (max 1000 characters). Exactly one of topic, text, or url is required.
`brandId`	No	Optional brand from list_carousel_options. Its name and logo are placed on the slides. Omit for no brand.
`language`	No	Output language. Defaults to the workspace language.
`imageMode`	No	How photo slots are filled. stock (default): stock photos. none: no photos (not allowed with templateId). preserve: keep the template's own images (templateId only).
`requestId`	Yes	A UUID you generate for this request. Repeating the call with the same requestId and the same input returns the same carousel instead of creating (and charging for) another one.
`slideCount`	No	Number of slides (3-20). Omit to let Posteady decide.
`templateId`	No	Optional template from list_carousel_options. With a template, Posteady keeps the template's design and writes new copy into it; without one, Posteady designs the carousel.
`aspectRatio`	No	Slide aspect ratio. Defaults to 3:4. Not allowed with templateId (the template fixes it).
`workspaceId`	No	Target workspace. Defaults to the token's workspace; list_workspaces lists the others.
`instructions`	No	Extra instructions for the writer, such as tone, audience, or points to emphasize.
`webImageSearch`	No	Search the web for photos of real subjects (products, people, places) named in the content. Not allowed with templateId.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations, it discloses cost (20 credits per carousel), asynchronous behavior (returns carouselId with status queued; 1-3 minutes), and the idempotency contract in concrete terms (same requestId returns the same carousel; a new requestId creates and charges for a new one). The idempotency detail reinforces idempotentHint=true rather than contradicting it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is dense but front-loaded: purpose first, then cost, then async lifecycle, then downstream usage, then idempotency. Every sentence carries operational information an agent would otherwise have to infer.

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?

There is no output schema, yet the description explains the return value (carouselId plus queued status), the polling path, and how the resulting mediaIds are consumed. For a 13-parameter asynchronous generation tool, nothing essential is missing.

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 baseline is 3. The description restates the exactly-one-of topic/text/url choice and points to list_carousel_options for template and brand IDs, but adds little about the interactions the schema already covers, such as imageMode versus templateId restrictions or aspectRatio being fixed by a template.

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 description opens with a specific verb and resource ("Create a carousel (multi-slide image post)") and names the accepted inputs (topic, source text, or link). It also distinguishes itself from siblings by explaining that get_carousel reports status and list_carousel_options supplies template and brand IDs.

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?

It tells the agent exactly when to reach for this tool, what to do afterward (poll get_carousel until completed or failed), where dependent IDs come from (list_carousel_options), and how the resulting mediaIds feed publish_post and schedule_post with the Instagram cap of 20. That is a complete routing story across the sibling set.

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

All Posteady 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?