Skip to main content
Glama

Make a carousel

make_carousel

Turn a website link or a topic into a rendered 9:16 vertical carousel (1080x1920 slides), with a caption and hashtags. Costs 20 credits; insufficient_credits says what is missing. Returns while rendering: poll get_carousel until status is ready, then create_post with plan.caption, plan.hashtags and renderedMediaIds.

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": {
      "source": "<source>"
    },
    "name": "make_carousel"
  }
}

Input Schema

NameRequiredDescriptionDefault
sourceYesA website URL or a topic
languageNoLanguage of the slides and caption; defaults to the brand language
mediaIdsNoImage ids from list_media to use on the slides
ideaIndexNoWhich generated idea to build, starting at 0
textStyleNoclean
slideCountNo
sourceTypeNoInferred from the source when omitted
imagePackIdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing the cost (20 credits), the specific failure signal (insufficient_credits), and the critical async behavior — the call returns while rendering is still in progress. This is exactly the operational context an agent needs before invoking a credit-consuming, open-world, non-read-only tool.

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?

Three dense sentences with zero filler: what it does, what it costs and how it fails, then the exact follow-up sequence. The output/next-step information is front-loaded into the same paragraph rather than buried.

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 supplies the return shape (plan.caption, plan.hashtags, renderedMediaIds) and the full async lifecycle, covering the two things an agent would otherwise be blind to. For an 8-parameter generative tool, this is complete enough to call correctly.

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 coverage is 63%, and the description clarifies that 'source' is either a URL or topic (with sourceType inferred), plus names the returned fields. However, it adds nothing about textStyle, slideCount, ideaIndex, imagePackId, or mediaIds, leaving several schema-level parameters explained only by the schema itself. Adequate but not compensating for the coverage gap.

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?

States a specific verb and resource ('Turn a website link or a topic into a rendered 9:16 vertical carousel') plus concrete output characteristics (1080x1920 slides, caption, hashtags). An agent immediately knows this generates carousel media rather than video, distinguishing it from make_video.

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?

Gives explicit downstream workflow guidance: poll get_carousel until status is ready, then call create_post with the returned fields. It does not state when to prefer this over make_video or make_video_from_my_videos, so the alternative-selection guidance is incomplete, but the post-invocation path is unambiguous.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources