indesign-layout

Layout in Adobe InDesign

Drives a running Adobe InDesign through the indesign-nutria-mcp server, whose 197 tools — typed, validated and grouped by object — cover documents, pages, text, styles, tables, colour, images, masters, footnotes, cross-references, tables of contents, indexes, data merge, books and export.

Reach for this skill when the user wants work done in InDesign: building or editing a layout, placing a manuscript, typesetting, preparing a press-ready PDF, or automating a folder of documents.

InDesign has no headless mode. Everything here drives the application the user has open, so "just render it in CI" is not an option — and the skill should say so rather than pretend otherwise.

Before the first call

Setup (installing the server, wiring the host, opening the bridge) is in SETUP.md, shipped next to this file.

Three things must be true before any tool works:

1. InDesign is open. Most tools act on an open document; with none open they fail. On the Windows COM bridge the instance must also be visible, otherwise the user is looking at an empty application.
2. One bridge is running — the UXP panel, ./start-bridge.sh, or the COM bridge on Windows. Sending a raw script to InDesign has no cancellation: if it hangs, the host stays busy and every later call queues behind it.
3. The connection is checked once. document_listOpen is the cheap probe: if it returns a document list, the whole path works. If a call fails with bridge_not_connected, stop and tell the user to open InDesign and the bridge. Do not retry in a loop — the bridge cannot appear on its own.

The contract

This server does not just expose tools, it expects to be driven a certain way. Each rule below prevents a specific, common failure.

• Use the typed tools. They validate arguments, wrap ExtendScript and apply timeouts. export_executeScript and script_run push code straight to the bridge with no cancellation — never use them for loops, font enumeration, multi-object probes, or anything touching many DOM objects.
• State before action. Call document_getState before mutating: it returns the front document's geometry, the other open documents, the active layer and the selection in one round-trip. Do not assume geometry.
• Target the document explicitly. Every tool takes document_id — a document name (as document_listOpen reports it) or a 0-based index. Without it a tool acts on the front document, so with several open, pass document_id rather than trusting the front tab.
• Read errors as data. A failed call returns { ok: false, code, message, suggested_next_tool? }. Act on suggested_next_tool instead of guessing.
• Group multi-step edits. Wrap a multi-step call in undo_beginGroup / undo_endGroup so the whole call is one undo step.
• Look at what you made. Call preview_document before reporting success rather than assuming the change landed.
• Never leave a dialog possible. document_close defaults to saveOptions: "no", which cannot prompt. Call document_save first when the work should be kept, and never pass "ask" while acting unattended — a modal save dialog blocks the script until the bridge times out.