Skip to main content
Glama
Sign In
Adobe XD MCP

Adobe XD MCP

by srayan-uxd
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

xd_render_artboard

Render an XD artboard or single layer to PNG to visually verify a rebuild, including linked components, masks, gradients, images, shadows and text as one full-fidelity export.

Instructions

Render one artboard (or one layer via nodeId) to a PNG so you can SEE the result and verify a rebuild. Renders the full-fidelity export (linked components, masks, gradients, images, shadows, text) as one SVG and screenshots it in a local headless Chrome/Edge. Set XD_MCP_CHROME if the browser isn't found automatically. Nothing is uploaded.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "file": "<file>",
      "artboard": "<artboard>"
    },
    "name": "xd_render_artboard"
  }
}

Input Schema

NameRequiredDescriptionDefault
fileYesAbsolute path to a .xd file
scaleNoPixel scale; automatically reduced so the longest edge stays within maxEdge
nodeIdNoRender only this layer id
maxEdgeNoLongest allowed output edge in pixels
artboardYesArtboard id or name

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A3.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does meaningful work: it discloses the rendering pipeline (single SVG + headless Chrome/Edge screenshot), that nothing is uploaded, and the XD_MCP_CHROME environment fallback. The main omission is what the call returns (file path, inline image, dimensions), plus any permission or browser-missing failure behavior.

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?

Three tight sentences with the purpose front-loaded and no redundant restatement of the name. The environment-variable note is placed after the core behavior, so the essential information is readable immediately. Nothing is padding, though the pipeline detail could be condensed slightly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema and no annotations, the description should clarify the return shape, but it never says whether a PNG path, image data, or a URL comes back or how large the response may be. The pipeline and local-browser dependency are well covered, but the missing return-value detail leaves a real gap for a rendering tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all five parameters, including scale bounds, maxEdge, and nodeId, are already documented in the schema. The only added semantic is that nodeId renders a single layer, which the schema already states. Baseline 3 applies since the description adds nothing beyond structured fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('Render one artboard (or one layer via nodeId) to a PNG') and states the intent ('so you can SEE the result and verify a rebuild'). That distinguishes it from export-oriented siblings like xd_export_artboard or xd_export_svg by framing it as visual verification, though it never names those alternatives explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'verify a rebuild' implies a use case, so an agent can infer this is the visual-check tool rather than the asset-export tool. However, it never states when to prefer it over xd_export_artboard or xd_get_preview, and offers no explicit exclusions or prerequisites beyond the Chrome fallback note.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools