Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
CESDK_LICENSENoYour own CE.SDK license key. If not set, a 30-day trial license bundled in the package is used.

Instructions

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

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{}
prompts
{}
completions
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
skillA

Load a skill — an instruction document that teaches you how to work with this server. Read the relevant skill BEFORE attempting work it covers. Intended sequence: (1) call with just name to get the entry document — it ends with an index of the bundled files; (2) pass query (a regex, like Grep) to search the bundled files for the rules you need, scoping with path when you know the file; (3) full-read a file via path only when it is small (the index shows line counts) or after a search missed twice — slice large files with offset (skip count: offset=10 starts at line 11) and limit. Entry documents are always returned whole (offset/limit are ignored for them).

Triggered for any task using this server's edit or preview tools. Authoritative TypeScript signatures for the CE.SDK CreativeEngine. Use this skill whenever you need the exact signature, parameter types, or return type of an engine.* method — especially before calling a method you haven't used yet. This is THE source of truth for signatures: generated from the .d.ts shipped with the same @cesdk/node package the engine runs, while prose docs (the guide skill) can drift.

Reading this skill with no path returns the WHOLE edit-code API surface inline — the engine.design facade, the props trees, the attachment unions and the capability matrix. That is one call and it is all edit code needs.

The sub-file "signatures.d.ts" is the same surface plus the upstream CE.SDK core — JSDoc-free signatures with every string-vocabulary type (property names, block types, enum values) flattened to its literal union on the declaring line. It is served a page at a time: search it with query (e.g. query: "saveToArchive"), then slice around the hit with path + offset/limit.

Triggered when you need to verify an engine.block.* or engine.scene.* signature, look up a parameter type, or confirm an enum/string-property name. Use when applying a brand kit / brand style to an existing CoDesign / CE.SDK design — a rules-governed restyle (recolor + refont + logo + treatment by role), not a free-form style change; when a restyled design reads off-brand (free-chosen colors, wrong accent, a second colour used as structure, a coloured button the brand forbids, a headline set in a weight the brand bans, a flat bordered card, or the wrong / recoloured / redrawn logo); when loading a brand's fonts, wordmark SVG, or signature device into a scene; or when turning an external brand (a guidelines PDF, a website / URL, a Figma file, or a raw asset dump) into a reusable brand kit. Use when the user asks to create / generate / make a NEW design from a prompt — a deck or slides, poster, flyer, social post, business card, or a custom-size canvas. Runs the guided intake: derive every brief parameter the prompt already answers (class, format, audience, vibe, brand, content), ask ONLY the missing questions — one round, chip-style options, "Decide automatically" defaults — then echo the design brief and hand off to the handbook Loop. A brief given to the /codesign prompt lands here as the stated input. Canvas-format reference for CoDesign designs — one file per screen/print format (ig-post, ig-square, ig-story, widescreen, linkedin-post, x-post, deck, poster, flyer, business-card): exact W×H, aspect, medium, platform safe zones, print bleed/dpi. Use when picking or setting up a canvas size, checking a platform safe zone, or preparing print dimensions. Re-composing an existing design into a format is the resize skill; new-design intake is the create skill. Look up CE.SDK Node.js reference docs, guides, and configuration pages — prose explanations, recipes, and concept docs for everything the engine can do (text, fills, colors, export, video, templates, asset sources, …).

Use when you need to understand HOW a CE.SDK feature works or want a code recipe; also triggered by "IMG.LY", "CreativeEditor", "CE.SDK", or "cesdk" when the user needs an existing Node.js doc page. For exact TypeScript signatures use the api skill instead.

The entry document is an index; every doc page is a sub-file — read one with path (e.g. path: "text/add.md"), or search them all with query. Use to quality-gate a design before reporting it done — the mandatory step 5 of the handbook Loop; when the user asks for a design review, score, audit, or QA; or when a design needs remediation after a failed review. The axes, the gate, the scorecard format, and the remediation loop are defined in this skill's body — read it before scoring; do not judge from memory of this description. Use when creating or fixing translated / localized variants of an existing CoDesign / CE.SDK design (e.g. de/ja/ru/ar editions); when a localized edition's text blocks or decorative elements have drifted, re-centered, or resized away from the source layout; when translated copy is tofu, overflowing, mis-tracked, or the wrong font after a language swap; or when loading a non-Latin script (Cyrillic / CJK / Arabic RTL / Vietnamese) font into a scene. Use when the user is new here or asks what this server is / what it can do ("what is CoDesign", "what can you make", "show me"). A guided, plain-language introduction for a HUMAN: explain what CoDesign is in everyday terms, put the six jobs it does on the table, let the user pick one, then run it either on the bundled demo design or on the user's own idea — closing with the optional (never required) IMG.LY sign-in and the ways to earn more credits. Not a design manual: the handbook remains the required read before any edit. Use when resizing or reformatting a CoDesign / CE.SDK design to a new size or aspect ratio (ig-post ↔ ig-square ↔ ig-story ↔ widescreen, or a custom W×H); when building the size/format editions of a design from an existing design or from a brief; or when a reformatted edition has a dead void / letterboxed empty band, drifted or broken margins, off-canvas or clipped elements, mis-scaled decoration, or a stretched / squished layout.

editA

Edit the CE.SDK canvas by running JavaScript against the live CreativeEngine, then commit the result as a new revision.

⚠ Call skill({ name: 'handbook' }) BEFORE your first edit. It documents the design loop, the typeface schema, and the engine recipes; on cryptic errors, query its quirks.md.

REQUIRED: parent is a revision id (returned by a previous edit), or the JSON null literal (no quotes) to start a new design. Omitting it is an error — there is no implicit 'continue from wherever'. In a fresh conversation, a request for a new design means parent: null — never resume a workspace design the user didn't reference.

Returns: the first content part is JSON { revision, parent, names? } — store revision so you can pass it as parent on the next edit. names lists every named block in the committed scene: those are exactly the strings engine.design.findByName(name) resolves in your NEXT edit, so name what you build and re-find it instead of matching copy. When the edit changed the scene, the result also ends with a downscaled render of the (first) changed page — verify your work from it instead of spending a preview call. preview remains required for full-size judging (the judge loop) and multi-page review; set render: false to skip the image on read-only/diagnostic edits.

code return contract (STRICT): return undefined (no message back), { type: "text", text }, { type: "image", data: "<base64>", mimeType }, or an array of those. Anything else (raw strings, Blobs, plain objects) is rejected.

DIALECT (enforced): mutations go through engine.design (create/build/setProps/…). Code that mutates via engine.block.* is rejected before execution with the equivalent calls; // engine.block: <reason> opts out for calls the facade lacks.

code scope: engine (with engine.design), plus findText(copy) / findAllText(copy) for reaching a block by its text. Use them instead of comparing text strings with === — the copy on the page routinely carries a trailing space or an NBSP (before a /%), which is what makes hand-rolled lookups throw. Matching folds those space variants and trims; a miss lists the copy actually on the page.

Dirty-on-throw: if your code throws, the engine slot is marked dirty and the next edit pays one engine reload (regardless of parent). Do not catch-and-swallow errors that should propagate — let them throw so this safety contract kicks in.

Optional: title (set on parent=null only — the design's display name) and note (a one-liner describing what this edit accomplished — purely descriptive, helps you re-ground after a rewind).

Refused parents: if the user saved changes in the browser editor between your parent and the design head, this edit would discard them, so it is rejected — call changes to see what they did and which revision to build on.

previewA

Render blocks (almost always pages) to inline images so you can see the result.

revision is REQUIRED — pass the revision the blocks belong to, the id edit returned. blockIds is a LIST, rendered in the order you give it: [pageId] for one page, [a, b] for a subset, or OMIT it entirely to preview every page of the design in document order.

The given revision is loaded before rendering, so the ids always resolve against the right scene — never against a different design another agent may have loaded on a shared server.

Preview several blocks at once when REVIEWING or capturing a finished design — a whole deck in one call, or just the pages a fix touched. While BUILDING a multi-page design, keep previewing each page right after you build it: batching there does not avoid the bugs, it only delays finding them.

Output is always PNG (lossless — thin lines render exactly). EACH block gets the full 0.25 megapixel budget, adjusted to its own aspect ratio — a square page renders 512×512, a 1:4 page 256×1024. There are no size or format knobs, and at most 10 blocks render per call.

To eyeball fine detail, preview the suspect BLOCK directly — the pixel budget concentrates on it (an effective zoom). For native-resolution certainty, export the page and open its httpUrl.

exportA

Export a revision to a final deliverable — format picks it: pdf (print PDF), png/jpeg/webp (image), svg (vector SVG), pdfx (print-ready PDF/X), html (responsive HTML5), imgly (editable design file). Renders blockId — or the whole document when blockId is omitted — and writes the result into the workspace under exports/<shard>/<rev>/ (revision-pinned, deterministic).

Returns JSON: { uri, httpUrl, bytes, format, revision } (plus path when you pass outPath). uri (a workspace:// URI) is the durable handle. httpUrl is a fetch link tied to this process — fetch it to download the bytes to disk, or hand it to the user.

outPath (optional, absolute path including the filename): ALSO write the artifact to that local path — the workspace copy is still written, and the response then carries path. Use it when the file is wanted on disk, and always when your environment cannot fetch localhost URLs (sandboxed harnesses, e.g. Claude Cowork — target your session's outputs folder there).

format=svg is the engine's vector export: text is outlined into paths (renders identically everywhere, but is not editable text in the SVG), and raster images are embedded in the file at source resolution — an SVG of a photo-heavy design can be much larger than its source images.

format=imgly writes a portable, self-contained .imgly design file (scene + all asset bytes bundled) — the inverse of import, and the only format that stays editable. Whole-design only: blockId is not accepted. Every edit already auto-persists to the workspace, so you never need this to keep your work — use it to take an editable copy OUT: hand it to a human, back it up, move it between servers.

format=pdfx runs the print PDF through a PDF/X conversion (Ghostscript): CMYK with an embedded ICC profile and PDF/X conformance markers, ready for a print shop. Tune it via the optional pdfx object — conformance standard (X-4 default / X-3), output profile (fogra39/gracol/srgb/custom), transparency flattening, OutputIntent metadata. Conversion adds a few seconds.

format=html renders ONE page (blockId required — pass a page id) to responsive HTML5. Default is a single self-contained .html (assets inlined; animated designs get a CDN GSAP player injected so the file plays as-is); html: { assets: "external" } delivers html + separate image/font files as one .zip.

importA

Import a design FILE as a NEW design root revision — a native CE.SDK .imgly design file (also the legacy .scene and .zip forms); a foreign design file: Photoshop (.psd/.psb), InDesign (.idml), PowerPoint (.pptx), or PDF; or a plain image (PNG/JPEG/WebP/GIF) or SVG, which becomes a one-page design sized to the image (format: "image"/"svg"). The inverse of export({ format: 'imgly' }). To make a media file (image/font/video/audio) available for use INSIDE a design instead of becoming one, use asset_add.

Source: { url } (http/https), { demo } (a design bundled with this server — ids: "cybernews") or { path } (absolute local file path; Local only). Archives are ingested: bundled asset bytes are extracted into the workspace as content-addressed assets/<sha>.<ext> files, so the loaded design is durable and behaves exactly like a natively-built one.

Returns JSON { revision, title, format } — continue with edit({ parent: revision, … }). Foreign-format imports may add warnings (importer notes about what did not survive — substituted fonts, unsupported features): treat them as your touch-up list — preview the pages, then repair with edit; find replacement fonts via asset_search. Bare scene-file loads (no bundled assets) additionally return assets: a classification of every referenced asset URI by scheme (workspace / external / bundle / transient / other). External URLs are NOT fetched; transient entries WILL be lost on the next save — replace or relocate them before committing further work.

Engine caveat: InDesign and PDF import need the WASM engine (IMGLY_CESDK_ENGINE=wasm) — on the native engine import errors cleanly for those two formats; Photoshop and PowerPoint import work on both.

listA

List designs in the workspace. Returns an array of { rootRevision, title, latestLeaf, updatedAt, headOrigin?, headNote? } sorted newest-first; the head* fields describe latestLeaf. headOrigin: "editor" means the last hand on that design was the user's, in the browser editor — read headNote (the engine-computed diff of their save) before you change anything, and build from latestLeaf so their work is not discarded. Use when the user asks what designs exist or wants to resume earlier work. Seeing a design here is never by itself a reason to continue it — for a new design request pass parent: null to edit.

historyA

Walk back from revision to the root, returning the chain (root first). Each entry has { revision, parent, note?, origin?, createdAt }origin: "editor" marks a revision the user saved from the browser editor. Use this to re-ground after a rewind: read the notes, pick the revision you want to continue from, pass it as parent to your next edit. Continue a prior design only when the user asked for it — never because it is the newest entry.

changesA

Check whether the user changed a design in the browser editor since you last touched it.

Pass the revision you believe is current — normally the one your last edit returned. The reply says whether it is still the design head and lists what was written since, oldest first, with each revision's diff note and whether it came from the editor (origin: "editor") or from your own edit.

Call this before your first edit of a design whenever the user may have had the view page open: edit REJECTS a parent whose path to the head contains one of the user's editor saves, so this is how you find the parent to build on.

inspectA

Read one revision in full: parent, note, createdAt, title (root only), and the JS code that produced it (when written via edit).

Use this after history when you've picked a revision and want to know HOW it got there — the code is the precise operation; note is the agent's summary.

Returns JSON { revision, parent, note?, origin?, createdAt, title?, code? }origin: "editor" marks a revision the user saved from the browser editor. code is omitted for revisions not produced by edit (e.g. future import paths).

⚠ Past code reveals the PATTERN of an edit (which APIs were called, what kind of block was targeted), NOT the block ids. Block ids are session-scoped — re-discover them in the current engine; don't replay the literal numeric ids.

renameA

Rename a design. revision may be any revision in the lineage; the root's title is updated. Use this when the title set at design creation no longer fits.

scorecardA

Record the verdict of a judge loop you have COMPLETED for a revision — the final step of the judge skill. Recording is a claim about work already done: never call this without having scored the axes against actual preview renders of this exact revision's content.

verdict: 'pass' — every applicable axis scored ≥ 8; the design may be delivered. verdict: 'fail' — you are stopping with an axis below 8 (e.g. the user cut remediation short); the failure stays on record.

The latest scorecard is what export checks: delivering a revision it does not cover (content changed since, or no scorecard at all) adds a reminder to its result. Judging again after further edits? Record a new scorecard for the re-judged revision.

checklistA

Register the brief's ACCEPTANCE CHECKLIST for a design — the machine-checkable claims that must hold before the work counts as done. Do this right after intake, before the first edit: extract from the brief every required output file, every string of approved copy that must land verbatim, and note the constraints only you can check.

Item kinds:

  • { kind: 'output', path } — a file that must exist when the design is delivered (absolute path, e.g. every variant the brief orders exported).

  • { kind: 'copy', text } — approved copy that must appear VERBATIM in the design's text (whitespace variants are folded before comparing; wording, case and punctuation are exact).

  • { kind: 'note', text } — a self-check the server cannot verify (e.g. "layout structure unchanged from master"). Kept on record; never machine-checked.

Every export verifies the current checklist against the deliverable and lists unmet items in its result — treat an unmet item exactly like a failing test: finish the work, or re-register the checklist without the item if it is genuinely obsolete. Calling checklist again REPLACES the whole list for this design.

Returns: { ok, itemCount, rootRevision } — or the current checklist when called with only revision (no items).

viewA

Get a URL the human can open to view and edit the design in CE.SDK. Returns the design's stable URL — the viewer keeps it live, re-rendering as you edit, so print it ONCE and don't re-emit a fresh URL every turn. Add pin: true for a frozen permalink to that exact revision (for 'look at exactly this' or comparing revisions). The page is a full editor; when the human clicks 'Save', their edits land as a new revision whose note carries an engine-computed change summary — continue from that revision.

asset_searchA

Discover the asset sources registered on the CreativeEngine and search the assets they contain. Read-only — never creates a revision.

Without sourceId: lists every source id with its supported MIME types.

With sourceId: returns one page of assets as JSON { total, currentPage, nextPage, assets: [{ id, label, groups, uri, thumbUri, width, height, uploadedAt }] }. Typeface assets (e.g. the ly.img.gfonts Google Fonts source) additionally carry a compact typeface: { name, weights, styles } summary. query fuzzy-matches labels and tags.

The ly.img.workspace.images source is this workspace's own image store: every image the agent generated or imported AND every image the human uploaded in the browser editor, newest first. Uploads carry their original filename as label (the human will refer to it — "use logo-final.png" — so search that name), plus groups: ["uploads"] and an uploadedAt timestamp. "The image the user just uploaded" = the uploads-group asset with the newest uploadedAt.

⚠ Asset sources are deployment configuration — where their content lives (IMG.LY CDN, a customer host) is the server's business. NEVER fetch asset manifests (content.json) or hardcode cdn.img.ly URLs yourself; this tool and engine.asset.* are the only correct path. A source missing from the no-arg listing is not available on this server — say so instead of working around it.

To USE a result, apply it inside edit code — re-find it there, then either: (A) new block: const id = await engine.asset.apply(sourceId, (await engine.asset.findAssets(sourceId, { query, page: 0, perPage: 1 })).assets[0]) — then, if you resize the frame, set engine.block.setContentFillMode(id, "Cover") (resizing does NOT update the crop; without Cover a portrait photo forced into a landscape frame gets squished); (B) existing block: const fill = engine.block.createFill("image"); engine.block.setString(fill, "fill/image/imageFileURI", asset.meta.uri); engine.block.setFill(blockId, fill); engine.block.setContentFillMode(blockId, "Cover"). (C) fonts: re-find the family inside edit code and pass the payload straight to setFont — const { assets } = await engine.asset.findAssets("ly.img.gfonts", { query: name, page: 0, perPage: 20 }); const tf = assets.map((a) => a?.payload?.typeface).find((t) => t?.name === name); if (!tf) throw new Error("font lookup missed: " + assets.map((a) => a?.payload?.typeface?.name).join(", ")); engine.block.setFont(id, tf.fonts[0].uri, tf); engine.block.setTextFontWeight(id, "normal"). Take the EXACT name out of a page of results — fuzzy ranking can put it behind longer names (query "Lora" returns Explora first), so perPage: 1 fetches the wrong family. And always set the weight: tf.fonts[0] is the family's LIGHTEST declared weight (Thin/100 on Inter, Roboto, …), so setFont alone renders hairline text with no error. Never copy font URIs out of this tool into edit code. Do NOT use engine.asset.applyToBlock — on this server it silently no-ops (the block keeps its old fill, no error).

asset_addA

Add a local image or font file to the workspace so it can be used in a design. Copies the file bytes into the content-addressed asset store at assets/<sha>.<ext>. The bring-your-own arm of the asset family: asset_search finds an existing asset, asset_generate makes one, asset_add takes one off your disk — all three return a workspace:// uri to embed in edit. (To turn a design FILE into a new design, use import.)

Returns JSON: { uri, httpUrl, mimeType, kind, bytes, note? }. uri (a workspace:// URI) is the durable handle — embed it in a subsequent edit (image fill, or engine.asset.apply; for a font, as both setFont's uri and typeface.fonts[].uri), NEVER httpUrl and NEVER the original file:// path, so the design stays loadable after a restart or rewind. httpUrl is a fetch link for opening the asset now.

Files are classified by content (magic bytes) first, extension second: a misnamed file is stored under its actual type, and note explains any correction, rescue, or unverifiable content.

Make-available only: it never edits a scene and never creates a revision — do the placement in edit.

Source: { path } — an absolute path to a file the server can read. Local-only (this backend shares your disk); on a hosted server this arm is not offered.

asset_generateA

Generate images (text-to-image, image-to-image) via the IMG.LY AI gateway.

Call with NO arguments first: returns the model catalog — pick a model, then call again with model + prompt (+ optional format aspect like "16:9").

For image-to-image, pass image_uris with workspace:// URIs (from import or earlier generations).

The first content part is JSON: { uri, httpUrl, mimeType, bytes }. uri (a workspace:// URI) is the durable handle — embed it in subsequent edit calls. httpUrl opens the asset directly. The parts after it are a labeled thumbnail of each generated image — look at them; the JSON alone does not tell you what was drawn.

Multi-output models (layerize-class: decompose an input image into layers) add an assets array to that JSON — one entry per image, { index, uri, httpUrl, mimeType, bytes }, in stack order (residual background first, then cutout layers). The top-level fields mirror assets[0]. Single-output results carry no assets array. Any non-image output the model produced is passed through VERBATIM under metadata — read it, it binds semantics to the assets (layerize, for example, ships a layers list in assets order with names, z order and bounding boxes in source pixels; cutouts are cropped to content, so place them by their bounding box).

Requires a free IMG.LY sign-in (the login tool); all other design tools work without an account.

diagnosticsA

Inspect this codesign MCP server: status (default) reports what is running (build id, CE.SDK engine version, non-secret config); summary returns a bounded digest of recent activity (counts, recent errors, slowest calls); open returns a clickable local viewer URL with a Download-ZIP button to send diagnostics to IMG.LY.

loginA

Sign in with your IMG.LY account (opens the system browser). The session saves automatically once the user finishes in the browser; call login again anytime to confirm — safe to repeat, it does not restart the flow or invalidate the open link. Pass switch_account=true to sign in as a different user.

logoutA

Sign out of your IMG.LY account (revokes the session and clears local credentials).

Prompts

Interactive templates invoked by user choice

NameDescription
codesignStart a design session with the FULL context preloaded in one message — handbook, design rules, API surface, judge + copy rules, quirks, fonts — so no reference reads are needed before the first edit. Optional brief: what to design.

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.2/5.0

Scored across 19 tools

Disambiguation5/5

Each tool targets a distinct concern: revision lifecycle, asset management, auth, skills, export, or diagnostics. The asset_search/asset_add/asset_generate trio is clearly separated by operation (find/add/generate), and list/history/changes/inspect are differentiated by scope. No two tools appear to overlap in a way that would cause misselection.

Naming Consistency3/5

Bare verbs (edit, export, preview, import, list, view) coexist with prefixed names (asset_search, asset_add, asset_generate) and noun-only names (skill, history, checklist, scorecard, diagnostics). While the core verbs are recognizable and readable, there is no single predictable pattern across the set.

Tool Count3/5

At 19 tools, the server sits in the 16-25 range that feels heavy. However, the broad scope (design editing, assets, auth, skills, diagnostics, quality gates) justifies most of them, so it is borderline rather than bloated.

Completeness4/5

The design lifecycle is well covered: create (edit, import), read (inspect, preview, history, list), update (edit, rename), and export, plus asset management and quality gates. The main gap is the absence of delete/remove operations for designs or assets, and asset management lacks update/delete, but agents can work around these.

Maintenance

ActivityMaintained
ResponsivenessNo issues