shapeless

Render a carousel

render_carousel

Destructive

Turn HTML/CSS slides into a PDF for LinkedIn documents and per-slide PNGs for Instagram carousels.

Instructions

Render your own HTML and CSS slides to a PDF (a LinkedIn document post) plus one PNG per slide (an Instagram carousel), each a media key. Slides are 1080x1350 unless you pass page; self-contained HTML only, no scripts or external URLs; src="media:" places a library image. A render with clipped or unreadable text is refused with a per-element audit. SPENDS CREDIT: about $0.02 of engine cost a default call, billed with the plan's margin; budgetUsd caps it (default 2, max 10) and chargedUsd says what it cost. Needs the write scope.

Input Schema

TableJSON Schema

Name	Required	Description
`css`	Yes	The deck's one shared stylesheet: palette, type scale, layout classes. Scope everything under .slide-canvas.
`page`	No	The canvas every slide is drawn on, in pixels. Default 1080x1350. Pick the shape the post will live in: 1080x1350 4:5 portrait (LinkedIn documents, Instagram portrait); 1080x1080 1:1 square; 1920x1080 16:9 landscape (slides, X, YouTube thumbnails). Anything between 480 and 2560px per side works; design your type scale for the canvas you chose, not for this default.
`title`	Yes	Short deck title (file naming and accessibility; render it yourself if you want it visible).
`slides`	Yes	1-12 slides in order. Multi-slide: slide 1 is the hook read at thumbnail size; the last slide carries ONE call to action. Exactly 1 slide = a single-page infographic: the rendered PNG is the deliverable, designed to be fully read in-feed without a swipe.
`budgetUsd`	No	Optional: the most this call may spend, in dollars, default 2, max 10.

Output Schema

TableJSON Schema

Name	Required	Description
`tool`	Yes
`media`	Yes
`output`	No	The tool's own result, shaped by the tool.
`chargedUsd`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.4Oct 13, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With annotations only declaring destructiveHint/readOnlyHint, the description carries real behavioral payload: credit spend (~$0.02), budgetUsd cap semantics (default 2, max 10), chargedUsd as the cost readout, the required write scope, and the refusal behavior with a per-element audit when text is clipped or unreadable. That is exactly the destructive/paid context an agent needs before invoking.

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 deliverable and its outputs, then constraints, then cost. Dense and semicolon-heavy, but every clause carries information (sizing, HTML restrictions, media keys, audit refusal, credit, scope) that the schema does not duplicate.

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 complex, nested, credit-spending, non-read-only tool, it covers the risk profile (cost, cap, write scope), input constraints (static HTML, media: keys), sizing defaults, and failure mode. An output schema exists, so it correctly avoids restating return values while still noting chargedUsd.

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 genuine meaning beyond the schema: the default 1080x1350 slide size, the 'src="media:<key>"' convention for embedding a library image (absent from the html property description), and the self-contained-HTML/no-scripts/no-external-URLs constraint that governs what html may contain.

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 ('Render') and resource ('your own HTML and CSS slides') plus the exact outputs: a PDF for a LinkedIn document post and one PNG per slide for an Instagram carousel. This is clearly distinguishable from siblings like render_thumbnail or generate_image, which produce single raster assets rather than an HTML/CSS-driven multi-slide deck.

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 strong usage context: multi-slide decks (hook first, single CTA last) versus a single slide as a standalone infographic, and how canvas shape maps to destination platforms. It does not explicitly name alternatives (e.g. render_thumbnail) or state when NOT to use this tool, so it falls short of a 5.

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

Deploy Server