idmly-mcp
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@idmly-mcpconvert index.html to an editable InDesign file"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
idmly-mcp
Convert a self-contained HTML design into an editable Adobe InDesign file (.idml) from the AI agent you already use. This is the idmly engine exposed as a Model Context Protocol server, so Claude Code, Cursor, Codex, Windsurf or Claude Desktop can hand a finished design straight to InDesign.
The first two pages of any design convert free, no key needed. A $49 lifetime license unlocks unlimited full-document conversions and covers both the website and this tool.
Install
Node 20 or newer. The server runs with npx, nothing to clone. Start without a key and the free trial just works.
Claude Code
claude mcp add idmly -- npx -y idmly-mcpCursor, Windsurf, Claude Desktop (mcp.json / claude_desktop_config.json)
{
"mcpServers": {
"idmly": { "command": "npx", "args": ["-y", "idmly-mcp"] }
}
}Codex CLI (~/.codex/config.toml)
[mcp_servers.idmly]
command = "npx"
args = ["-y", "idmly-mcp"]With a license, add the key from your purchase email as an environment variable:
claude mcp add idmly -e IDMLY_LICENSE_KEY=<your key> -- npx -y idmly-mcp"env": { "IDMLY_LICENSE_KEY": "<your key>" }env = { IDMLY_LICENSE_KEY = "<your key>" }Related MCP server: idml-mcp
Tools
convert_to_indesign
Give it exactly one of:
argument | what |
| the complete HTML document as a string |
| a local |
| a public https link to a hosted |
Optional: out_dir (where to write; defaults to the source file's folder, or the current directory), name (output base name), platform (mac or win, which InDesign will open the file; picks glyph-fallback fonts, defaults to this machine).
It writes <name>.idml and returns the path, pages converted, the fonts InDesign needs active, and a geometry check. A design with images comes back as a folder holding the .idml and a Links/ directory; keep them together and InDesign finds every image. Trial output is named <name>-trial.idml.
idmly_status
Reports whether the engine is reachable and whether a license key is configured (presence only; the key is validated on the first conversion).
Writing HTML that converts well
Each page is a fixed-size block with class
page(orslide). A two-page reader spread is classspread. Typical sizes: 816×1056px Letter, 794×1123px A4, 1920×1080px slide, withoverflow: hidden. A single fixed-width canvas with no markers converts as one page; a fluidwidth: 100%page has no intrinsic size.Keep the file self-contained: inline CSS and JS, fonts from Google Fonts or embedded, images as data URIs or absolute URLs. A stylesheet or image sitting next to the file is not uploaded.
Draw charts as inline SVG or HTML rather than raster images, so they stay editable.
Avoid scripts that never settle (a MutationObserver or resize handler that re-triggers itself). The engine renders the page once, measures it, and rebuilds it as InDesign frames.
Text becomes editable text frames with paragraph styles, tables stay tables, SVG and CSS shapes become vector objects.
Text a designer can keep editing
How the text is marked up decides how many frames it lands in and what the paragraph styles carry.
Consecutive paragraphs inside one box become one text frame, one paragraph each. Space them with
margin-topormargin-bottom; it arrives as Space Before or Space After on the paragraph that carries the margin. An empty spacer paragraph (<p> </p>) keeps the frame whole too.padding-leftis the left indent andtext-indentthe first-line indent, sopadding-left: 46pt; text-indent: -46ptis a hanging indent.A real tab character (inside
white-space: preorpre-wrap) gets tab stops on the CSS grid: settab-sizeas a length (tab-size: 46pt) to put the stop where you want it.A two-column list (contents, prices, credits) converts best as a
<table>: it becomes a native InDesign table with a paragraph style per cell.Paragraph styles are named from the tag and the element's first class (
<p class="caption">gives "Body · caption"). To name one outright, adddata-idml-style="Cover Dates".Boxes that hold one continuous text can be linked: give each the same
data-idml-thread="cv"and they convert as one threaded story, frame to frame, in document order (ordata-idml-thread-order="1","2", ...). Every frame but the last is fixed at the size of its text, so an added line pushes text on to the next frame. If a box starts mid-paragraph, adddata-idml-thread-continuesand its first paragraph is joined to the last one of the box before. InDesign recomposes a threaded story, so a line can move across a frame boundary compared with the HTML.An inline
display: inline-blockelement inside a paragraph is a box of its own and becomes its own frame. Use a plain<span>for a run that only changes font or colour.
When it fails
result | meaning | what to do |
402 without a key | the free trial is used up for this design or this hour | the result carries the price and checkout link |
402 with a key | the key was not accepted | check the key; if it worked before, delete |
413 | over the size cap (15 MB trial, 50 MB licensed) | downscale or re-encode images, or host them and use absolute URLs |
422 | nothing rendered, or a script never finished | inline the missing assets; remove the runaway script |
429 / 503 | rate limit, or the license service is unreachable | retry after |
Large designs can take a couple of minutes to render. Some clients cut tool calls at 60 seconds by default; raise your client's per-tool timeout (for example MCP_TOOL_TIMEOUT in Claude Code) for big documents.
Environment
variable | default | purpose |
| none (free trial) | your license key from idmly.com |
| next to the source | default output directory |
| the hosted engine | override for a self-hosted engine |
The key is activated on first use. The activation id is kept in ~/.idmly/instances.json under a hash of the key; the key itself is never written to disk by this tool. Each machine that runs the server uses one activation from the license's allowance.
Hosted endpoint
If you would rather not run a local process, the engine also speaks MCP over Streamable HTTP:
https://idmly-production.up.railway.app/mcp
Authorization: Bearer <your key> (omit the header for the free trial)Because a remote tool cannot write to your disk, that endpoint returns a one-time download link instead of a file path: the file is deleted as soon as it is fetched, or after ten minutes unfetched. The same endpoint works with the OpenAI Responses API mcp tool and the Agents SDK.
Plain REST is POST /convert with a multipart file (or url), plus license_key and instance_id. The first licensed response carries an X-Idmly-Instance header; send that value back as instance_id on every later call, or each call activates a new device against the license. The response is the .idml itself, or application/zip (containing converted.idml and Links/) when the design has images.
Privacy
Uploaded designs are deleted from the engine as soon as the converted file has been returned. On the hosted MCP endpoint the converted file waits behind a one-time, unguessable link for up to ten minutes so the agent can fetch it, then it is deleted. No accounts. The engine keeps a first-party usage ledger (counts, outcome, country), never your file or your key.
Development
npm install
npm test # type-checks, bundles, then runs the client against a stub engine (no network)The published package has no runtime dependencies: npm run build bundles the
MCP SDK and zod into dist/index.js, so npx users get exactly the file the
tests ran against. Dependency updates arrive as a weekly Dependabot pull request;
merging it publishes a new patch version from GitHub Actions with provenance.
License
MIT for this client. The idmly engine is a hosted service, see idmly.com/legal.
Available Tools
2 toolsconvert_to_indesignConvert HTML design to InDesign (.idml)A
Convert a self-contained HTML design into an editable Adobe InDesign IDML file and write it to disk. Provide exactly one of: html (the full document as a string), path (a local .html file; only that one file is uploaded, so inline its CSS, fonts and images first), or url (a public link to a hosted .html). Returns the output path plus pages converted, fonts InDesign needs active, and a geometry check. Designs with images come back as an .idml next to a Links/ folder; keep them together. Without a license key only the first pages convert (free trial) and the result includes the purchase link.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Public https URL of a hosted .html design (a direct link, not a share or app link). | |
| html | No | The complete HTML document to convert (self-contained: inline CSS, fonts via Google Fonts or embedded, images as data URIs or absolute URLs). | |
| name | No | Base name for the output (no extension). Defaults to the source file name or 'design'. | |
| path | No | Absolute or relative path to a local .html file to convert. Only this file is uploaded. | |
| out_dir | No | Directory to write the output into. Defaults to IDMLY_OUT_DIR, else the source file's directory, else the current directory. | |
| platform | No | Which platform's InDesign will open the file (picks glyph-fallback fonts). Defaults to this machine; unknown platforms get free Noto/Source Han fallbacks. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (which only say it is a non-readonly, non-idempotent, open-world write). It discloses that output goes to disk, that images produce a sibling Links/ folder that must be kept with the .idml, that fonts may need to be active in InDesign, and that an unlicensed run converts only the first pages and returns a purchase link.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences, each carrying distinct information: what it does, the exactly-one-of input rule, what comes back, and the two important post-conditions (Links/ folder, free-trial limit). The action and its constraints are front-loaded with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description enumerates the return payload (output path, pages converted, fonts to activate, geometry check) and the failure/limitation modes (trial page cap, licensing). For a 6-parameter write tool that produces on-disk artifacts, an agent has everything it needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds the mutual-exclusivity contract among html/path/url and the single-file upload semantics of path that the flat schema does not express. It does not add anything for name, out_dir, or platform beyond what their schema descriptions already say.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (convert), source (self-contained HTML design), and artifact (editable InDesign IDML file written to disk). The sibling idmly_status is clearly a different kind of tool, and nothing about this description overlaps with it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Provide exactly one of: html, path, or url', which is the key selection rule among the input modes, and adds the precondition that path uploads only one file so CSS/fonts/images must be inlined first. The url caveat ('a direct link, not a share or app link') further narrows correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
idmly_statusidmly statusARead-only
Check that the idmly engine is reachable and whether a license key is configured for this MCP server (presence only; the key is validated on conversion).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), so the bar is lower, and the description adds genuinely useful semantics: it probes reachability and reports license-key PRESENCE without validating the key, noting validation happens at conversion time. That prevents the agent from assuming a pass guarantees a licensed conversion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with the primary purpose (reachability) first and the secondary check plus its limitation in a compact parenthetical. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema status tool the description covers what is checked and the key caveat about validation timing. It does not hint at the returned result shape (e.g., a status/boolean payload), which is the only remaining gap in an otherwise adequate definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to clarify about inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (check) against two concrete resources: engine reachability and presence of a license key. It is trivially distinguishable from the only sibling, convert_to_indesign, which performs a conversion rather than a diagnostic probe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical '(presence only; the key is validated on conversion)' implies this is a pre-flight/diagnostic check relative to convert_to_indesign, but it never explicitly says when to call this instead of just attempting a conversion or what a failure means for next steps. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.1.3- First observed
convert_to_indesign - First observed
idmly_status
TDQS
Scored across 2 tools
The two tools have completely distinct purposes: one performs the HTML-to-IDML conversion, the other only reports engine reachability and license presence. There is no plausible overlap or misselection risk between them.
Both names use snake_case, which is consistent, but the verb_noun pattern in 'convert_to_indesign' is not mirrored by 'idmly_status', which is a service-prefixed noun phrase. The deviation is minor and still clearly readable.
Two tools is on the thin side, but the server has a single narrow purpose (converting HTML into IDML) plus a health check, so each tool earns its place. There is little room to add tools without inventing scope.
The surface covers the core workflow (convert from html/path/url, inspect status) and returns useful diagnostics like fonts and geometry. Gaps such as batch conversion, job polling, or reverse IDML-to-HTML export are noticeable but not blocking for the stated purpose.
Related MCP Connectors
Htmlpdf Transform Mcp connects AI agents to real public APIs via MCP. Tools include
Convert files between 110+ document, image, audio, video, archive and ebook formats from AI agents.
Real files for AI assistants: HTML to image/PDF, screenshots, QR, charts, PDF tools, validators.
Document conversion and OCR for AI agents: PDF, Office docs, images to text.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables AI agents to automate Adobe Illustrator, converting bitmap artwork into editable .ai files, running ExtendScript, and capturing the Illustrator window for visual QA.1-
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to parse, summarize, and safely edit Adobe InDesign IDML files without requiring InDesign.1MIT
- AlicenseNot gradedqualityAmaintenanceEnables agents to convert Figma frames into self-contained HTML and then iteratively verify the rendered code in Chromium against the design using pixel diffs and element bounding-box checks until it converges.241 npm1MIT
- FlicenseNot gradedqualityAmaintenanceEnables Claude to create and edit Adobe InDesign documents, including pages, text frames, styles, images, and previews.7 npm-