Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

Kadal Deck: presentations written in MDX (deck.mdx). Slides split at ---, vertical slides at ----; YAML after a separator is that slide's frontmatter; the YAML at the very top is the headmatter (deck settings + the first slide). Workflow: deck_reference (look up components/layouts/backgrounds before using them) → deck_create or deck_outline → slide_add / slide_update / notes_set → deck_check → slide_render and LOOK at the pictures → fix → deck_export or deck_publish. Edit slides through the slide tools rather than rewriting deck.mdx: they change only that slide's lines and lint the result. A published deck may be edited on the web too (quick edit). Before editing a published deck: deck_sync_status; if the web has newer versions, deck_pull first. Conflicts: deck_conflicts (both sides, per slide) → deck_resolve (prefer keeping both sides' intent; ask the person when the two edits contradict) → deck_check → deck_publish. Never force a publish over web edits unless the person says so. Media: media_search / media_trending find icons, emoji, stickers, GIFs, memes, meme templates, Kadal's own library and Kadal Store (kind store); put a result's mdx into a slide as it is. Add credits: true to the headmatter and every item is credited on a Credits slide automatically. After inserting a KLIPY result, call media_used. Resources: kadal-deck://guide/design-guide (how to make a good talk), kadal-deck://guide/authoring, kadal-deck://reference.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}
prompts
{
  "listChanged": true
}
resources
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
deck_referenceA

Look up what a deck can use: built-in components (props, defaults, examples), layouts, backgrounds, themes, transitions, click effects, code-fence options, deck/slide frontmatter keys, keyboard, routes, the live room, CLI. Give a section (components, layouts, backgrounds, themes, transitions, transitionSpeeds, clickEffects, clickAt, codeMeta, deckFrontmatter, slideFrontmatter, keys, routes, queryParams, live, cli, exitCodes) and optionally a name, or search words. With no arguments, lists the sections. Use it before writing a component or option you have not checked.

deck_frontmatter_schemaA

The JSON Schema for deck frontmatter: $defs.headmatter for the YAML block at the top of deck.mdx (deck settings + first slide), $defs.slide for every other slide.

deck_createA

Scaffold a new Kadal Deck folder from the starter (deck.mdx, deck.config.ts, src/, AGENTS.md) and install its dependencies. The folder must not exist or be empty. Afterwards, pass the same dir to the other tools.

deck_outlineA

Every slide in order: index, column/row (h/v), id, title, layout, hidden, frontmatter, estimated click steps, whether it has notes, an excerpt, and its line range in the file. Start here before editing an existing deck.

deck_read_slideA

One slide's MDX body, frontmatter, speaker notes, and its exact source text with line numbers.

deck_checkA

Lint the deck: invalid YAML, unknown or mistyped frontmatter keys, unknown layouts/backgrounds/themes/transitions, MDX that does not compile (with file:line), JSX components that are not built in / in src/components.tsx / imported, broken src: includes, missing images and videos, glossary problems, code-fence options, and unresolved merge conflicts (code merge-conflict: settle them with deck_resolve). Errors break the deck; fix them before rendering.

slide_addA

Insert a new slide. at is the index it will have (default: the end); vertical puts it beneath the previous slide in the same column. content is the MDX body without separators or frontmatter; put options in frontmatter (e.g. { layout: 'two-cols' }) and speaker notes in notes (use [click] markers to pace them). The deck is linted afterwards.

slide_updateA

Change one slide: content replaces its MDX body (existing speaker notes are kept unless the new content has its own or keepNotes is false); frontmatter replaces its frontmatter; patch merges keys into it (null deletes a key). Only that slide's lines change. On the first slide, the frontmatter is the headmatter: a replace keeps the deck settings.

slide_removeA

Delete one slide (its separator, frontmatter, body and notes). A stack's top slide hands its column to the slide beneath it.

slide_moveB

Move a slide so it ends up at index to; vertical stacks it beneath the slide before its new place.

deck_update_frontmatterA

Merge keys into the headmatter — the YAML at the top of deck.mdx that configures the deck (title, author, theme, transition, colorScheme, slideNumber, glossary, fonts… see deck_reference deck). null deletes a key. Comments and order are kept.

notes_setA

Replace a slide's speaker notes (shown in the presenter view). Put [click] where each click's part begins so the notes follow the reveals. An empty string removes them.

slide_renderA

Pictures of slides as PNG images, exactly as the deck draws them (headless Chromium on the deck's own dev server, kept running between calls). Use it after every round of edits and LOOK: overflow, contrast, crowding, alignment, empty space. Each slide is drawn as a still with every click revealed. Needs the deck's dependencies installed and Playwright + Chromium (the error says how).

deck_previewB

Start (or reuse) the deck's dev server with live reload and return its URLs — the deck, the presenter view, the audience page — for a person to open. Edits made with the slide tools appear live. stop: true shuts it down.

deck_buildA

Build the deck into dist/ (a static site any host can serve). Run deck_check first.

deck_exportA

Export to PDF (default; with bookmarks from the slide titles), PNG (one per printed page), PPTX (images + notes), editable PPTX (native text, lists, shapes, pictures and tables + notes) and/or Markdown (the PNGs with each slide's notes) into export/. Needs Playwright + Chromium.

deck_publishA

Build the deck and publish it to its Kadal Deck host (deck.kadal.cc by default) with a live room; returns the URL. Uses the login saved by kadal-deck login (or KADAL_DECK_TOKEN). If nobody is signed in it returns what the person must run — it never signs in by itself. The deck's editable source goes too (privately), so it can be quick-edited on the web. If the published deck moved since this folder last synced (a web or agent edit, a publish from another copy, a rollback — or the folder never synced), it does NOT publish: it returns {ok:false, reason:"diverged", head, next} — call deck_pull, settle any conflicts, deck_check, then publish again. Use force:true only when the person explicitly says to replace that version. While conflict markers are left it returns {ok:false, reason:"conflicts"}.

deck_sync_statusA

Before editing a published deck, call this. It compares the folder, its last sync (.kadal-deck/) and the web: newer versions made on the web (quick edit, agents), local changes by slide, unresolved conflicts, an unpublished web draft someone is editing, and next — the steps to take (e.g. deck_pull). Works offline for the local half.

deck_pullA

Merge the newest web version (or version) into the deck's files, slide by slide, against the last sync. What only one side changed is taken; the same lines changed both ways become git-style conflict markers (clean: false), which block publishing. Changed files are backed up in .kadal-deck/sync/backup/. strategy "ours"/"theirs" settles every conflict one way — use it only when the person says so; otherwise read them with deck_conflicts and settle each with deck_resolve.

deck_conflictsA

Every unresolved merge conflict in the deck's files, structured: file, slide (counting from 1 in its file), line, kind (content / frontmatter / delete-edit / add-add), and the text of each side — ours (this folder), theirs (the web), base (what both started from). which is the conflict's index in its file, for deck_resolve. Read both sides before choosing.

deck_resolveA

Settle conflicts: choice "ours" keeps this folder's side, "theirs" the web's, "both" keeps both (ours first — then edit the slide to blend them). Scope: path (a file), plus slide (1-based, as deck_conflicts says) or which (the conflict's index in the file); with neither, every conflict in the file; without path, every file. A side that deleted the slide or file removes it when chosen. When the last conflict goes, the pulled version becomes the sync base. Then deck_check and deck_publish.

media_searchA

Find media for a slide — the same sources and the same MDX as the hosted builder's Insert media panel: Iconify icons, emoji, stickers, GIFs and memes (KLIPY), meme templates (Imgflip, with caption boxes placed), Kadal's own stickers, GIF loops and templates, and Kadal Store's shelf (kind store: a pattern, a wallpaper or a shader also comes with frontmatter, the slide's background: that puts it behind the slide — a shader only that way — and a LUT is attributes to add to an or ). Each result has mdx (paste it into the slide unchanged; edit only caption text, size, x/y), preview (a picture URL), attribution and id. Credits are automatic: set credits: true in the headmatter (deck_update_frontmatter) and every item appears on a Credits slide with its licence. KLIPY needs the CLI's sign-in; without it the other sources still answer. Prefer one emoji set per deck; prefer Kadal's own items when they fit.

media_trendingA

What's popular now in a kind, with no query: KLIPY's trending GIFs, stickers and memes, Imgflip's top meme templates, the most-used emoji, a sample of the popular icon sets, Kadal's library in its own order. Same result shape as media_search (mdx, preview, attribution, id); paste the mdx into a slide unchanged. Credits are automatic with credits: true in the headmatter.

media_usedA

Tell the source a result went into the deck. KLIPY requires it (its share trigger is how it counts a use): call it once for every KLIPY result you insert, with the result's id ("gifs/"). Edits made through slide_add / slide_update report KLIPY results from this session on their own, so this is for inserts made any other way; other providers need nothing and the call says so.

Prompts

Interactive templates invoked by user choice

NameDescription
draft_deckTurn a topic or an outline into a finished Kadal Deck: scaffold, write, check, look, fix.
review_deckCheck, render and critique an existing deck, then propose (or make) fixes.

Resources

Contextual data attached and managed by the client

NameDescription
catalogEvery component, layout, background, option and key, as data.
referenceThe catalog as one Markdown reference.
frontmatter-schema
guide-workflowThe agent workflow (the Kadal Deck skill).
guide-authoringThe Kadal Deck skill's authoring reference.
guide-componentsThe Kadal Deck skill's components reference.
guide-design-guideThe Kadal Deck skill's design-guide reference.
guide-layouts-and-backgroundsThe Kadal Deck skill's layouts-and-backgrounds reference.
guide-live-roomThe Kadal Deck skill's live-room reference.

TDQS

A3.8/5.0

Scored across 24 tools

Disambiguation4/5

Most tools have clearly distinct purposes: slide CRUD, deck setup, linting, rendering, preview, export, publishing, and sync/conflict handling are separable. A few pairs are adjacent (deck_check vs. deck_sync_status, deck_preview vs. slide_render, media_search vs. media_trending), but the long descriptions generally make the boundary clear enough for an agent.

Naming Consistency4/5

All names are snake_case and use recognizable domain prefixes (deck_, slide_, media_, notes_), which makes the set readable. However, the convention mixes noun phrases (deck_conflicts, deck_outline, deck_frontmatter_schema) with verb phrases (deck_resolve, slide_add, media_search), and deck_read_slide is prefixed like a deck operation rather than a slide operation.

Tool Count3/5

24 tools is on the heavy side and lands in the borderline 16–25 range. The domain genuinely needs many operations (authoring, media, validation, export, publishing, sync), but a few tools could conceivably be consolidated or made more composite without losing capability.

Completeness5/5

The surface covers the full deck lifecycle: scaffold, outline/read, slide CRUD and move, notes, deck frontmatter, media search/trending/attribution, linting, rendering, preview, build, export, publish, sync status, pull, conflict inspection, and conflict resolution. There are no obvious dead ends for the stated domain.

Maintenance

ActivityMaintained
ResponsivenessNo recent community issues