Skip to main content
Glama

ZeroWidth

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

TableJSON 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.
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. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructiveHint=true, and the description earns that by disclosing the destructive semantics directly: passing boardId with all slides 'replaces everything on it'. It goes well beyond annotations with the carry-over contract (solid backgrounds/borders/radius/text/pictures survive; gradients, shadows, background images and inline SVG do not), the size/shape model, and the returned per-slide warnings plus rendered previews.

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 purpose, then organized under clear headers (LAYOUTS FIRST / HOW TO WRITE A SLIDE / HOW TO USE IT), and nearly every line is actionable. It is nonetheless very long for a tool description and repeats the size-set idea twice ('a set of ads is one slide with sizes' and again in HOW TO USE IT), which costs a point.

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?

No output schema exists, and the description compensates: it explains that the result lists per-slide warnings (overflow, overlap, too-small text, low contrast, failed images) and returns a picture of every slide, plus the exact contrast thresholds. For a 9-parameter composition tool with destructive rebuild semantics, an agent has everything needed to call it correctly.

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 high (89%), so the schema already documents size keys, layout, slots and slide addressing. The description still adds real semantics the schema does not: layout-vs-html as an either/or decision, how `sizes` produces one arrangement per shape, how per-slide `size` composes a multi-size ad set, and the meaage that `css` is shared across slides. It leaves `accent`, `notes` and `picture` to the schema, hence not 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?

States a specific verb+resource ('Builds a designed deck') and then defines what a slide actually is (a layout with slots filled, or HTML/CSS laid out by a browser, becoming an editable Napkin deck). The opening line 'Use this whenever a deck should look designed' plus the layouts-vs-HTML framing cleanly separates it from sibling tooling like napkin_layouts_list and the slide-level tools.

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?

Gives explicit routing rules: start from a layout for ads/posts/carousels/title slides, write HTML only for something no layout does, read the brand first via napkin_brand_get, and it explicitly says 'You don't need napkin_slide_view afterwards'. It also defines when to pass name vs boardId vs slide vs append, which covers new/replace/append/single-slide-fix paths.

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