Skip to main content
Glama

ZeroWidth

by ai.zerowidth
OverviewDiscussionsAdmin

Build a designed deck

napkin_deck_compose
Destructive

Builds a designed deck: each slide is a layout with its slots filled, or HTML and CSS you write; a real browser lays it out, and it becomes an ordinary Napkin deck people can edit. Use this whenever a deck should look designed — it's how to get layout, big numbers, color blocks, and pictures right.

LAYOUTS FIRST

  • For ads, posts, carousels and title slides, start from a layout (napkin_layouts_list): give layout and slots instead of html. Layouts adapt to every size, fit their text, keep to each size's safe zones, and use the brand's own logos. A slide made from a layout remembers it, so when someone resizes it, it's laid out again instead of scaled.

  • A set of ads is one slide with sizes: ["1:1","4:5","9:16","1.91:1"] — each size gets its own arrangement.

  • Write HTML only for something no layout does.

HOW TO WRITE A SLIDE

  • html is the inside of one slide: a .slide box 960×540 px (the deck's own size if it has one). Margins are reset; lay out with flexbox or grid, padding and gap. Put each slide's CSS in a block inside its html, or shared CSS in css.

  • Read the brand first (napkin_brand_get). Style ONLY with its variables: var(--brand-ink), var(--brand-muted), var(--brand-background), var(--brand-surface), var(--brand-accent), var(--brand-accent-2), var(--brand-color-), var(--brand-font-heading), var(--brand-font-body), var(--brand-radius). Headings already use the heading face.

  • Pictures from the brand kit: , sized with CSS; object-fit: cover crops to fill, contain fits whole. Any workspace image: src="file:".

  • What carries over: boxes with a solid background, border, and rounded corners; text, including bold, italic, color, and size changes inside a line; pictures. What doesn't: gradients, shadows, background images, inline SVG — use solid color boxes instead.

  • Design like a designer: one idea per slide, a clear hierarchy, big numbers set large in the accent color, generous space, text 18px or larger (never under 14px), and something visual on most slides — a color panel, a photo, the logo. Keep every slide on the brand's own palette and voice.

  • Use the brand's own pictures. Put the logo on the title and closing slides (the reversed one on dark color), and use the kit's photos and icons where they carry the point — the brief lists every file under "Files", by name.

  • Say only what's true. Facts, figures, prices, eligibility, and how things work come from the brand kit and from what the user told you — never invent them. When a slide needs a fact you don't have, leave it out or ask.

HOW TO USE IT

  • New deck: pass name and all slides. Rebuild a deck: pass boardId and all slides (replaces everything on it).

  • Ads, posts and other non-slide pieces: pass size — a key like 1:1 (square post, 1080×1080), 4:5 (portrait post), 9:16 (story or reel), 1.91:1 (LinkedIn or Facebook landscape), og (link preview), 300x250 or 728x90 (display ads). The .slide box is then that shape with its long side 960 px, so type sizes mean what they do on a slide, and the deck exports at the size's real pixels. A single ad is a one-slide deck; a carousel is a deck at 1:1 or 4:5.

  • A set of ads — the same ad at several sizes, or several headlines — is one deck: give each slide its own size. Lay each size out for its own shape rather than squeezing one layout into all of them (a 9:16 story stacks what a 1.91:1 landscape puts side by side), and keep text out of the outer 7% of every edge and the top and bottom 14% of a 9:16. The deck's PNG export names each file by its pixels. Fix one slide: boardId, slide (1-based), and a single slide. Add slides: append: true.

  • The result lists each slide's warnings — text that overflows its box or the slide, overlapping text, text too small, low contrast, pictures that didn't load — and shows you a picture of every slide it made. Fix every warning and anything that reads badly in the pictures by recomposing just that slide. The contrast check is the standard one (4.5:1 for small text, 3:1 for large or bold text), so a contrast warning is real: darken the color, lighten the background, or set the text larger; never explain it away. You don't need napkin_slide_view afterwards: the pictures are the slides.

  • Cite the deck with [[board:ID]] alone on its own line.

Input Schema

NameRequiredDescriptionDefault
cssNoCSS shared by every slide.
nameNoName for a new deck.
sizeNoThe size of every slide, for a new deck or a whole rebuild: 16:9 = Widescreen slide 1920×1080; 16:10 = 16:10 slide 1920×1200; 4:3 = Standard slide 1024×768; 1:1 = Square 1080×1080; 4:5 = Portrait post 1080×1350; 9:16 = Story and reel 1080×1920; 1.91:1 = Landscape post 1200×628; x-post = X post 1600×900; og = Link preview 1200×630; pin = Pin 1000×1500; youtube-thumb = YouTube thumbnail 1280×720; linkedin-page = LinkedIn page cover 1128×191; linkedin-profile = LinkedIn profile banner 1584×396; x-header = X header 1500×500; youtube-banner = YouTube channel banner 2560×1440; facebook-cover = Facebook cover 851×315; 300x250 = Medium rectangle 300×250; 336x280 = Large rectangle 336×280; 728x90 = Leaderboard 728×90; 970x250 = Billboard 970×250; 300x600 = Half page 300×600; 160x600 = Wide skyscraper 160×600; 320x50 = Mobile banner 320×50; 320x100 = Large mobile banner 320×100; email-header = Email header 600×200; letter = Letter page 2550×3300; a4 = A4 page 2480×3508. Omit for a 16:9 deck or to keep a deck's size.
slideNoReplace just this slide (1-based) with the one slide given.
accentNoName of one of the brand's colors to use as var(--brand-accent) for this deck — for a deck about one product or campaign that has its own color in the brand.
appendNoAdd these slides after the existing ones.
slidesYes
boardIdNoDeck to rebuild or change. Omit to make a new deck.
previewsNoDefault true: the result includes a picture of every slide made. Pass false to skip the pictures — the call returns sooner, which helps with long decks; look at slides afterwards with napkin_slide_view.
workspaceNoWorkspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / previews
      Added value: +{
+  "description": "Default true: the result includes a picture of every slide made. Pass false to skip the pictures — the call returns sooner, which helps with long decks; look at slides afterwards with napkin_slide_view.",
+  "type": "boolean"
+}
  2. First observed

TDQS

A4.7/5.0
Behavior4/5

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

The description discloses the destructive path directly: passing boardId with slides 'replaces everything on it', which matches destructiveHint=true, and it explains the response shape (per-slide warnings plus a rendered picture of every slide) despite no output schema. It does not cover permission requirements or what happens to a deck's prior theme/notes on rebuild, but the main mutating risk is stated plainly.

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 content is front-loaded and sectioned (LAYOUTS FIRST, HOW TO WRITE A SLIDE, HOW TO USE IT), and the operational facts each earn their place. Some prescriptive design advice — 'design like a designer,' palette and font-size coaching — is quality guidance rather than invocation guidance and stretches an already long definition.

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 10-parameter composition tool with no output schema, the description covers everything an agent needs: sizing model, layout vs HTML, brand variables and image references, destructive rebuild semantics, warning remediation, and the [[board:ID]] citation convention. The remaining gap is only the absence of a formal return schema, which the prose compensates for.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 90%, yet the description still adds real meaning: layout-vs-html exclusivity, `sizes` producing one arrangement per size, `slide` being 1-based for a single-slide recompose, `append` for adding, and worked examples of size keys and their pixel implications. The slots contract (kit: vs file: references, `points` one item per line) is also explained in prose.

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 concrete verb and artifact ('Builds a designed deck') and immediately defines the two composition modes: a layout with filled slots, or HTML/CSS the caller writes, rendered by a real browser into an editable Napkin deck. That is enough to separate it from the plain drafting/editing siblings like napkin_deck_write or napkin_slide_add, which do not claim designed rendering.

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?

The description explicitly routes between alternatives and modes: start from a layout (napkin_layouts_list) for ads/posts/title slides, write HTML only when no layout fits, and it lists the exact call patterns for new deck, full rebuild, single-slide fix, and append. It also sets the threshold for when a size-specific variant should be used instead of one squeezed layout.

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

All ZeroWidth toolsInspect
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