The server exposes MCP tools to connect to Figma/XD design hosts, inspect and render design context, export DesignIR, generate starter code, and apply design changes.
List connected Figma/XD hosts and recent host events.
Read the current selection or a specific screen as normalized DesignIR nodes.
Render a selection or screen as PNG visual context with metadata.
Export DesignIR for the whole document, current selection, or a specific screen.
Get combined design context: structural properties, visual PNG, and optional generated target code.
Generate semantic starter implementations for HTML/web, React, Vue, Flutter, SwiftUI, or Jetpack Compose.
Create screens and components/symbols with size, position, background, fill, and text options.
Apply a normalized patch to the current selection (name, text, fills, bounds, opacity, visibility, typography).
Check host connectivity with ping and inspect each host's capabilities.
Provides tools for reading Figma designs, including selections, screens, and normalized design context, rendering visual previews as PNGs, exporting design IR, generating starter code for web and native frameworks, and creating or updating screens and components in Figma.
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., "@DesignPort Generate React starter code for the selected screen in Figma."
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.
DesignPort is a local MCP bridge that lets coding agents understand and work with designs in Figma and Adobe XD.
It gives an agent both the visual reference and the structured design context needed to implement a screen. A designer can keep working in the tool they know, while an agent can read selections and screens, render them as PNG context, and export a host-neutral design model that it can adapt to the application stack already present in the target repository.
DesignPort is an early, local-first project. It is intentionally small enough to run on a designer's computer and clear enough to extend with more hosts and agent harnesses.
Design files contain valuable implementation decisions: hierarchy, spacing, typography, colors, component boundaries, and screen relationships. A screenshot alone hides those decisions; a host-specific API dump hides the visual result. DesignPort keeps both evidence types together.
DesignPort separates the problem into three parts:
A Figma or XD development plugin reads and renders the open document.
The local bridge normalizes the document into DesignIR, a shared design
representation, and carries PNG previews when requested.
MCP tools make properties, visual context, and carefully scoped design operations available to coding agents.
The result is a common path from design to implementation:
Figma / Adobe XD
|
| host plugin over localhost WebSocket
v
DesignPort bridge + MCP server
|
| DesignIR properties + visual reference
v
Codex / Claude / another MCP client
|
v
The repository's own UI stackThe shared model is the important part. Figma-specific and XD-specific details stay at the edge, so adding another host does not require rewriting the agent integration.
Related MCP server: figmad-mcp
Connect a Figma development plugin and an Adobe XD UXP development plugin.
Read the current selection or a screen/artboard.
Render the current selection or a screen/artboard as PNG visual context.
Export a full document or a scoped DesignIR snapshot.
Export local styles and variables as tokens and preserve node style bindings.
Expose component properties, variants/states, text ranges, interactions, annotations, and accessibility signals when the host provides them.
Paginate large documents and cap embedded asset bytes so an agent can request context in deliberate chunks.
Return session/document/scope-stable capture identities and explicit full,
delta, not-modified, or resync-required responses so an agent can cache
evidence without treating an omission as proof of absence.
Offer summary, structure, and full context detail modes for deliberate
context budgeting.
Return bounded asset descriptors and retrieve their original/rendered bytes
independently with design.get_asset.
Run deterministic semantic audits for layout, accessibility, interaction, component, and token evidence.
Expose a component/instance and prototype-interaction graph alongside the node-level IR.
Report connected hosts, capabilities, and recent host events.
Create screens and basic components through host adapters.
Apply a normalized patch to the current selection.
Return properties and visual context together for agent review.
Compare implementation screenshots with a deterministic local PNG diff.
Keep the bridge on loopback (127.0.0.1) by default.
The available MCP tools are:
Tool | Purpose |
| List connected Figma and XD plugins. |
| Read recent selection, document, and write events. |
| Inspect what a connected host supports. |
| Read the current selection as normalized nodes. |
| Read one screen/artboard and its descendants. |
| Render a selection or screen as PNG image content. |
| Export document, selection, or screen context. |
| Retrieve one bounded asset from a captured export. |
| Read the status of a queued host write. |
| Check exported context for deterministic semantic issues. |
| Read reusable-component and prototype-interaction relationships. |
| Return DesignIR properties and the visual PNG together. |
| Create an artboard/screen. |
| Create a basic component or symbol where supported. |
| Apply a normalized patch to the current selection. |
| Check that a host can receive requests. |
See EXAMPLES.md for ready-to-copy tool arguments and common workflows, and DESIGN_IR.md for the normalized contract and layout interpretation guide.
design.get_design_context is the normal implementation entry point. Its
response contains three complementary evidence layers:
properties: the scoped DesignIR data — hierarchy, host-neutral node
kinds, bounds and render bounds, fills, typography, assets, effects, corner
radii, transforms, constraints, layout metadata, tokens, component
properties/variants, text ranges, accessibility signals, and prototype
links.
A PNG image content block: the visual truth of the selected screen or component.
audit: deterministic diagnostics for semantic, accessibility, interaction,
component, and token gaps (included by default; disable with
includeAudit: false).
The MCP server supplies evidence; the LLM decides component boundaries, behavior, accessibility, and the correct primitives for the destination stack. DesignPort intentionally does not emit framework code. This keeps React, Vue, HTML, Flutter, SwiftUI, Compose, and future stacks under the target repository's own conventions and current dependency versions. No framework imports or stale UI-library choices are hidden in this project; the agent should inspect the target repository before choosing its current web, Flutter, SwiftUI, or Compose APIs.
DesignIR is the source of truth for agent harnesses. Coordinates are retained
for visual comparison and genuinely free-form placement, while explicit
layout metadata describes the intended structure: horizontal/vertical/grid
flow, gap, padding, fixed/hug/fill sizing, alignment, wrapping, absolute
positioning, constraints, and grid placement. Tokens and style references keep
the design system visible; component properties and variant values preserve
state decisions; text ranges preserve mixed typography; and prototype links,
annotations, and accessibility fields expose behavior and implementation
signals. Figma and XD vector/image assets are carried as local data when the
host can export them, so an agent does not have to redraw icons or substitute
screenshots.
The visual PNG remains mandatory evidence. An agent should use the two layers together: the IR explains what the design is made of, and the image verifies what it looks like. Neither layer is treated as an instruction supplied by the design file.
For large screens, pass maxNodes, includeAssets, maxAssetBytes,
includeTokens, maxTextBytes, maxTokenRecords, maxResponseBytes, and
detail (summary, structure, or full) to the context/export tools. The
response contains pagination, exportStats, a captureId, a snapshot, and
an explicit responseType. Continue with the returned opaque
pagination.nextCursor; cursors address a stored capture and never trigger an
unchanged shortcut. Omitted evidence includes a machine-readable reason.
To avoid sending a complete context on every loop, reuse the exact
snapshot.id with knownSnapshotId. An unchanged capture returns
responseType: "not-modified" and no nodes. After a change, set changedOnly: true with the previous snapshot ID to receive whole-node upserts and
removedNodeIds; merge those fields into the cached complete capture. If the
baseline is unknown, evicted, incomplete, or incompatible, DesignPort returns
responseType: "resync-required" with an actionable resyncReason instead of
guessing a delta. tokenState distinguishes replacement, unchanged, omitted,
and failed token evidence. Snapshot identity includes the plugin session,
document, page/scope roots, selected IDs, normalization version, and evidence
shape; old v1 snapshots are not compatible.
Every write requires expectedSnapshotId. Selection updates also require
explicit targetIds, so a queued or delayed operation cannot silently apply to
a later selection. XD writes remain user-applied and expose a pendingId for
design.get_operation_status.
Node.js 20 or newer and npm.
Figma Desktop for the Figma adapter.
Adobe XD and Adobe UXP Developer Tool for the XD adapter.
An MCP client that can launch a local stdio server, such as Codex or Claude.
The XD adapter is development-plugin based. It is not distributed through the Adobe XD Marketplace.
git clone https://github.com/MarlonJD/figma-design-mcp-plugin.git
cd figma-design-mcp-pluginnpm install
npm test
npm run typecheck
npm run buildThe build output is written to dist/ and is intentionally ignored by Git.
npm startThe process exposes MCP over stdin/stdout and opens the host-plugin bridge at
ws://127.0.0.1:5514.
Host registration requires the pairing token in DESIGNPORT_PAIRING_TOKEN.
The development plugins use designport-local-pairing by default; if you
change the server token, update the matching plugin constant before connecting.
To use a different local port or request timeout, set environment variables before starting the process:
DESIGNPORT_PORT=5515 DESIGNPORT_REQUEST_TIMEOUT_MS=30000 npm startThe available variables are documented in .env.example. The
server reads them from the process environment; it does not load .env files
automatically.
Build the project first, then point the MCP client at the compiled entrypoint. Use an absolute path:
{
"mcpServers": {
"designport": {
"command": "node",
"args": [
"/absolute/path/to/figma-design-mcp-plugin/dist/src/index.js"
]
}
}
}The MCP client starts one server process for its session. Start the DesignPort process manually only when you are connecting a design plugin for a direct development test; otherwise configure the MCP client and let it launch the server.
The bridge must be running before the plugin connects.
Open Figma Desktop.
Open Plugins → Development → Import plugin from manifest….
Select plugins/figma/manifest.json from this repository.
Run DesignPort Figma from Plugins → Development.
The plugin uses a hidden UI iframe for the localhost WebSocket connection, so
no permanent panel is expected. Ask the MCP client to call
design.list_hosts; it should report a connected figma host.
Install and open Adobe UXP Developer Tool.
Add the plugins/xd folder as a development plugin.
Launch Adobe XD and load the DesignPort command or panel.
Keep the DesignPort bridge running while using the panel.
XD read operations are available immediately. XD write requests are queued and must be applied from the panel inside a user-initiated edit context.
With the bridge and one plugin connected, ask the MCP client to:
Call design.get_design_context for the selected screen/artboard.
Compare the returned PNG with properties.nodes and its layout metadata.
Ask the LLM to identify reusable components, responsive structure, states, interactions, and accessibility requirements.
Have the agent implement the result using the target repository's existing components and current framework conventions.
After the first render, run the local visual check against the same viewport:
npm run visual:compare -- reference.png candidate.pngThe command reports similarity, mean pixel error, changed-pixel ratio, and the smallest bounding box containing the difference. It can also emit a red heatmap, a reference/candidate overlay, and a grid of regional metrics:
npm run visual:compare -- reference.png candidate.png \
--regions=8x8 \
--heatmap-output=artifacts/diff-heatmap.png \
--overlay-output=artifacts/diff-overlay.png \
--jsonIt returns a non-zero exit code when the configured visual thresholds fail.
Use design.get_selection_context, design.get_screen_context, and
design.get_visual_context separately when you want a smaller response or a
different stage of the workflow. See the agent-harness examples in
EXAMPLES.md.
Run the TypeScript entrypoint directly during development:
npm run devBefore opening a pull request, run:
npm test
npm run typecheck
npm run build
git diff --checkThe project layout is intentionally simple:
src/core/ DesignIR, audits, graph, and protocol contracts
src/bridge/ Local WebSocket host bridge
src/mcp/ MCP tool registration
src/eval/ Deterministic PNG visual comparison
scripts/ Local evaluation commands
plugins/figma/ Figma development plugin
plugins/xd/ Adobe XD UXP development plugin
test/ Protocol, IR, and bridge testsRead CONTRIBUTING.md before changing the protocol or adding a host adapter.
The server listens on loopback by default and is designed for a trusted local machine. A connected plugin can send design context to the local MCP process, and write tools can modify the active design document. Do not bind the bridge to a public interface without adding authentication and an explicit threat model.
See SECURITY.md for reporting guidance and operational rules.
Copyright (C) 2026 Burak Karahan.
DesignPort is licensed under the GNU General Public License v3.0 or any later version. See LICENSE.
Create a component or symbol through the active host adapter.
| Name | Required | Description | Default |
|---|---|---|---|
| fill | No | ||
| host | No | ||
| kind | No | component | |
| name | Yes | ||
| text | No | ||
| width | No | ||
| height | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Create' implies a mutation, but the description does not disclose potential side effects, permission requirements, reversibility, failure modes, or how the 'active host adapter' behaves. It also omits what happens to existing components or what the response looks like, leaving critical behavioral aspects undisclosed.
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?
The description is a single terse sentence with no redundant words, which is concise in length. However, it is so minimal that it lacks informative structure; there is no separation of core purpose from additional constraints or context. It is not verbose, but it is under-specified, falling between acceptable conciseness and insufficient detail.
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?
Given the tool's complexity—7 parameters, a nested object, two enums, and no output schema—the description is grossly incomplete. It fails to explain the purpose of parameters like fill, host, kind, text, width, and height, does not describe the returned value or errors, and does not clarify the meaning of 'active host adapter.' An agent would have almost no guidance on how to construct a valid call.
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 schema has 0% description coverage and the tool description provides no parameter explanations whatsoever. Despite seven parameters including a nested fill object and enums for host and kind, the description does not even mention that a name is required, nor does it clarify the meaning or constraints of any parameter. The agent is left entirely to the schema's raw types and defaults.
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?
The description states a clear verb ('Create') and resource ('component or symbol'), and adds context with 'through the active host adapter.' It distinguishes itself from sibling create_screen, though 'component or symbol' is somewhat generic and the adapter concept is not elaborated. Still, it conveys the core action without being a tautology.
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?
There is no guidance on when to use this tool versus alternatives like create_screen or update_selection. It does not mention prerequisites, conditions, or exclusions. The phrase 'active host adapter' hints at a dependency but does not explain how or when that matters, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an artboard/screen through the active design host adapter.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | ||
| y | No | ||
| host | No | ||
| name | Yes | ||
| width | No | ||
| height | No | ||
| background | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It reveals that the operation creates a screen via the active host, but it does not disclose side effects, permission or host-availability requirements, name-uniqueness behavior, or what happens if no active host is available.
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?
The description is a single sentence with no filler and is front-loaded with the core action. However, for a 7-parameter create operation with no schema descriptions, this brevity comes at the cost of necessary detail.
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?
Given no annotations, no output schema, 0% schema description coverage, and a rich sibling set, the one-line description is not sufficient. It does not explain return values, active-host prerequisites, relationship to design.create_component, or the semantics of the nested background object.
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 description coverage is 0%, and the description does not compensate. None of the seven parameters (x, y, host, name, width, height, background) are explained beyond what the bare schema names imply, leaving the agent to infer geometry units, coordinate origin, and host meaning.
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?
The description states a specific verb and resource: 'Create an artboard/screen'. The qualifier 'through the active design host adapter' adds context and helps distinguish this from siblings like create_component, though it does not explicitly name the alternative.
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 description gives no when-to-use guidance, prerequisites, or exclusions. The only context hint is 'active design host adapter', but it does not explain how to verify or select a host, nor when to choose this tool over design.create_component or other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the document, current selection, or one screen as DesignIR.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | ||
| scope | No | document | |
| screenId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Export' without describing what the export produces, whether it is a file, data blob, or stream, or any side effects. There is no mention of authentication, permissions, or reversibility. The behavior is opaque beyond the basic action.
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?
The description is a single, direct sentence that starts with the action verb and covers the core resource and output. It is efficient with zero waste, and the structure is appropriate for a simple export tool.
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?
The tool has 3 parameters, none required, but the interaction between scope and screenId is not explained. An agent would not know that selecting scope 'screen' necessitates screenId. There is no output schema, so the description should clarify the return format, but it does not. Given the absence of annotations and output schema, this description is incomplete for correct invocation.
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 description coverage is 0%, so the description must compensate. It does not explain the parameters at all. It mentions 'one screen' but does not connect it to the screenId parameter, nor does it clarify when host is needed or the meaning of the scope enum. The description adds no semantic value beyond the schema's enum values.
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?
The description clearly states the action (Export) and the resource (document, current selection, or one screen) and the output format (DesignIR). It distinguishes the three scopes via the enum, making the tool's purpose unambiguous and differentiating it from the sibling context-getting tools.
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?
No guidance on when to use this tool versus alternatives. It does not mention that it is for exporting DesignIR data rather than getting context, nor does it reference any sibling tools like get_design_context or get_visual_context. The usage context is only implied by the action verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export DesignIR from a host and generate a semantic starter implementation for web, React, Vue, Flutter core widgets, SwiftUI, or Jetpack Compose. Layout metadata maps to flex, Row/Column, stacks, and fill-sized children where possible.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | ||
| scope | No | document | |
| target | No | web | |
| screenId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions exporting DesignIR and translating layout metadata to framework constructs, which is useful, but it does not disclose whether the host is modified, how or where generated code is delivered, whether this is a read-only operation, or any output format.
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?
Two sentences with no filler; the core generation behavior is front-loaded and the layout-mapping detail justifies itself. It loses a point because 'Export DesignIR from a host' is an extra operational detail that could be clarified or moved after the primary purpose.
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 four-parameter code generation tool with no output schema and no annotations, this description is underspecified. It does not explain how results are returned, whether files are written, what screenId means for scoped generation, or what happens when no screen is selected.
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 description coverage is 0%, and the description only partially compensates. It names supported framework targets and mentions 'from a host', which maps to target and host, but it says nothing about scope or screenId selection semantics, nor does it explain the relationship between screenId and scope.
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 action: generate a semantic starter implementation in named frameworks, with mapping details for layout metadata. It is distinguishable from sibling design.export_ir because it generates code, not just exports IR, though the opening 'Export DesignIR from a host' creates some overlap.
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 description implies code generation use but gives no explicit when-to-use guidance, exclusions, or mention of sibling tools such as design.export_ir or design.get_selection_context. An agent must infer when this tool is appropriate rather than being told.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the active plugin capabilities for a design host.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It only says 'Return' without disclosing whether the operation is side-effect free, what 'active' means, whether host can be omitted, or how errors are handled.
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?
The description is one front-loaded sentence with no filler or repetition. Every word contributes to identifying the operation.
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 simple one-parameter query, the description is adequate but minimal: it names the return concept but not its shape or granularity, and without an output schema an agent cannot predict exactly what the response looks like. The lack of annotations and usage guidance also leaves some context missing.
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 single 'host' parameter is documented only by its enum values, and the description's 'for a design host' connects the parameter to the tool's purpose. It does not explain what happens when host is omitted, but the enum makes valid invocation clear.
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?
The description states a specific action ('Return') and resource ('active plugin capabilities for a design host'), which separates it from sibling list/get/export tools. 'Capabilities' remains somewhat abstract and there is no explicit contrast with sibling getters, so it stops short of a 5.
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 intended use is implied: call this when you need the active plugin capabilities of a Figma or XD host. However, there is no explicit guidance about when to prefer this over related context getters or whether it should be called before other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return design properties, a visual PNG, and generated target code together so an agent can reason from structure, appearance, and implementation.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | ||
| scope | No | screen | |
| target | No | web | |
| screenId | No | ||
| includeVisual | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does state what is returned and frames the purpose, and the title indicates a read operation. However, it does not disclose side effects, authorization needs, defaults, or caveats around generating target code.
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?
The description is a single front-loaded sentence that names the returned artifacts and the reason for using the tool. There is no filler, repetition, or unnecessary detail.
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?
With five parameters, no annotations, no output schema, and closely related sibling tools, one sentence is not enough. It omits parameter interactions such as selection vs. screen, output shape, and when to choose this combined tool over the more granular siblings.
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 description coverage is 0%, so the description needed to compensate. It only implicitly hints at 'target' via 'target code' and 'includeVisual' via 'visual PNG'; host, scope, and screenId are left unexplained, leaving the agent to guess how parameters relate.
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?
The description uses a specific verb ('Return') and names the exact contents: design properties, a visual PNG, and generated target code. This bundle clearly distinguishes the tool from narrower siblings like get_selection_context, get_visual_context, and generate_code.
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 description gives a clear usage context: use this tool when an agent needs structure, appearance, and implementation together. It does not explicitly name alternatives or exclusions, but the stated rationale is strong enough to signal when this combined read is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one screen/artboard and its normalized descendants.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | ||
| screenId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining behavior. It only says 'Return one screen/artboard and its normalized descendants', but it does not disclose whether this is a read-only operation, what 'normalized' means, what the output structure looks like, or any limitations. This falls far short of what an agent needs to anticipate tool behavior.
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?
The description is a single, direct sentence with no filler or redundant words. The core purpose is front-loaded and the use of 'Return' and 'screen/artboard' makes the action and resource immediately clear. This is an appropriately sized description for a simple tool.
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 tool with no annotations, no output schema, and only a few parameters, the description leaves too much unstated. It does not explain what the returned data contains, what the role of 'host' is, how to choose the correct screen ID, or how this differs from other context-related tools. More contextual detail is needed for correct use.
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 description coverage is 0% and the description adds no parameter-specific meaning. It does not explain what the 'host' enum errors or how 'screenId' should be formatted. The description mentions 'screen/context' but never ties it to the actual parameters, so the agent gains little beyond the raw schema.
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?
The description uses a specific verb ('Return') and names a clear resource ('one screen/artboard and its normalized descendants'). It conveys the primary purpose, and 'screen/context' suggests a distinct scope among sibling tools. However, it does not explicitly distinguish this from tools like get_design_context or get_selection_context, leaving some ambiguity in tool selection.
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?
No usage guidance is provided. The description does not state when to use 'get_screen_context' versus alternatives like 'get_design_context', 'get_selection_context', or 'get_visual_context'. There are no conditions, exclusions, or examples to help an agent decide which tool to call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current host selection normalized as DesignIR nodes.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool returns normalized DesignIR nodes but does not disclose what 'normalized' means, whether the operation is read-only (though 'Return' implies it), what happens if no selection exists, or any side effects. The description is minimal and leaves important behavioral aspects unspecified.
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?
The description is a single, concise sentence that front-loads the core action and output. It is appropriately sized for a simple tool, though it could have added a brief note about the host parameter or usage context without becoming verbose.
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?
Given the tool has no annotations, no output schema, and a single parameter with 0% schema description coverage, the description is too sparse. It does not explain what 'host selection' means, how the host parameter affects the result, or what DesignIR nodes are. An agent would need to infer or experiment to understand the tool's full behavior, especially in the context of many sibling tools.
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 description coverage is 0%, so the description must compensate for the undocumented parameter. The description does not mention the 'host' parameter at all, but the schema provides an enum with 'figma' and 'xd', which gives the agent the necessary values. The description adds no meaning beyond the schema, so a baseline score of 3 is appropriate given the single parameter is well-constrained by the enum.
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?
The description states a specific verb ('Return') and resource ('current host selection normalized as DesignIR nodes'), which clearly identifies what the tool does. It does not explicitly distinguish itself from sibling tools like get_screen_context or get_visual_context, but the mention of 'host selection' and 'DesignIR nodes' provides enough specificity to infer its purpose.
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 description provides no guidance on when to use this tool versus alternatives such as get_screen_context or get_visual_context. It does not mention any conditions, prerequisites, or exclusions, leaving the agent to infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render the selected node or screen as PNG image content and return its visual metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | ||
| scope | No | screen | |
| screenId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does reveal that the output is PNG image content plus visual metadata, and 'render' implies a read-only operation. However, it does not explicitly state side effects, failure behavior, auth needs, or prerequisites like a live host or valid selection.
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?
The description is a single, tight sentence with no filler. It front-loads the core action and output type, making it easily parseable. Every phrase contributes meaning.
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?
With no annotations and no output schema, the description is the only contextual source. It is too sparse for a tool with three parameters and many sibling alternatives: no explanation of host/screenId, no mention of selection prerequisites, and no guidance on result format beyond 'PNG' and 'visual metadata.'
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 description coverage is 0%, so the description must compensate for the lack of parameter documentation. It only maps 'selected node or screen' to the scope enum, but never explains the host parameter (figma vs xd) or screenId. An agent has to infer the meaning of key parameters from names alone.
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?
The description clearly states the action ('Render the selected node or screen as PNG image content') and the result ('return its visual metadata'). It specifies the resource and output type, making the tool's purpose understandable. It does not explicitly differentiate from sibling context tools like get_selection_context or get_screen_context, but the PNG/metadata angle provides enough distinction.
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?
No guidance is given about when to use this tool versus alternatives. There is no mention of when to choose get_visual_context over get_selection_context, get_screen_context, or export_ir. The usage context is only implied by the phrase 'visual context' and 'PNG image content.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read recent selection, document, and write status events from plugins.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. The verb 'Read' implies a non-destructive operation, but the description does not mention prerequisites (e.g., whether a plugin context is required), side effects, or the format of returned events. It adds some clarity about event types but lacks depth on behavior beyond the basic read nature.
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?
The description is a single, tightly worded sentence that directly states the tool's purpose with no redundant phrasing. It front-loads the core action and resource, making it easy to scan. Every word earns its place.
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?
Given the tool's low complexity (one optional parameter, no output schema), the description is somewhat sufficient but misses key details: the structure of the returned events, whether the host parameter filters results, and any assumptions about plugin context. The description covers the 'what' but not the 'how' of results or the meaning of the parameter, leaving gaps that could lead to mis-invocation.
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 schema has one optional parameter `host` with enum values, but the description makes no mention of it. With schema description coverage at 0%, the description fails to explain how the host parameter affects the tool's behavior (e.g., filtering events by host). The parameter is self-documenting in terms of allowed values, but its semantic effect is unclear, and the description adds no value beyond the schema.
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?
The description uses a specific verb 'Read' and identifies the resource as 'recent selection, document, and write status events from plugins.' It clearly states what events are covered, distinguishing it from sibling tools that handle contexts or exports. However, it does not explicitly differentiate from any sibling that might also read events, so a slight deduction for lack of explicit differentiation.
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 description provides no guidance on when to use this tool versus alternatives, no conditions for selection, and no exclusions. It simply states what it does, leaving the agent to infer usage context. Given the lack of any usage direction, this is a minimal score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List connected Figma and Adobe XD DesignPort plugins.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It states the tool lists connected hosts, which is a read-only operation, but doesn't disclose details like whether it returns live status, whether it includes disconnected hosts, or any authentication requirements. The description is accurate but minimal.
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?
The description is a single, clear sentence that front-loads the action ('List connected design hosts') and specifies the scope (Figma and Adobe XD DesignPort plugins). 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 list tool, the description is mostly complete. However, it doesn't mention what the output looks like (e.g., host names, connection status) or whether there are any prerequisites for hosts to appear. The sibling tools suggest a design context, but the description alone doesn't fully explain when this is useful.
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 has zero parameters, so the description doesn't need to explain parameter semantics. The schema is empty and coverage is 100%, meaning there's nothing undocumented. The description correctly implies no input is needed.
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?
The description clearly states the tool lists connected design hosts, specifically naming Figma and Adobe XD DesignPort plugins. This distinguishes it from sibling tools like design.list_events or design.get_capabilities, though it doesn't explicitly name a sibling alternative.
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 description implies this is the tool to use when you need to see connected design hosts, and the sibling list shows alternatives like design.get_capabilities for capabilities. However, it doesn't explicitly state when to use this vs. alternatives or provide context on when listing hosts is relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check that the selected plugin can receive bridge requests.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a 'check' (likely non-mutating) but does not explicitly state that it has no side effects, what the response indicates on success/failure, or whether it depends on a selected plugin state. The phrase 'selected plugin' suggests a dependency on external state that is not explained.
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?
The description is a single sentence with no wasted words, front-loading the purpose. It is appropriately concise for a simple ping operation, though the absence of parameter details reduces its overall usefulness.
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?
Given the tool's simplicity (1 optional parameter, no output schema), the description is incomplete. It fails to explain the role of the 'host' parameter, the meaning of a successful response, or any relationship to the selected plugin. An agent cannot fully determine correct usage without additional context.
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 description coverage is 0%, so the description must compensate for the undocumented 'host' parameter. However, the description does not mention the parameter at all, leaving the agent to infer its meaning from the enum values ('figma' and 'xd'). The description adds no semantic value beyond the schema's enum.
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?
The description states a clear verb ('Check') and a specific resource ('that the selected plugin can receive bridge requests'), which conveys the tool's purpose as a connectivity test. It is distinct from the sibling design tools, which focus on listing hosts, events, capabilities, and context retrieval. However, it does not explicitly differentiate itself from siblings, and the title 'Ping a design host' slightly conflicts with the description's focus on plugin connectivity.
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 description provides no guidance on when to use this tool versus the sibling tools, no prerequisites (e.g., whether a host must be selected first), and no alternatives. It does not indicate whether this should be called before other operations or in what scenarios it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply a normalized patch to the current host selection.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | ||
| patch | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior, but it only hints at mutation through 'apply' and cross-host normalization through 'normalized'. It does not state whether the patch merges or replaces properties, whether the operation is reversible, or what side effects might occur.
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?
The description is a single sentence with no filler or redundant phrasing. It is appropriately sized, but the unclear jargon 'normalized patch' prevents it from being a truly excellent concise definition.
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 mutation tool with a complex nested patch object, an optional host parameter, and no output schema, this description is too minimal. An agent would be unable to determine what properties the patch should contain, how the selection is identified, or what the result of the operation will be. It also fails to reference related tools that could provide selection context.
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 description coverage is 0%, so the description should compensate, but it does not explain the 'patch' object structure or the optional 'host' parameter. The schema itself is detailed, yet the description fails to clarify how to build a valid patch or how 'host' influences the call.
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?
The description uses a clear action verb ('apply') and identifies the target ('patch to the current host selection'), distinguishing it from the sibling getters and creators. However, the terms 'normalized patch' and 'host selection' are not defined, which leaves some ambiguity about exactly what is being changed.
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 description provides no guidance on when to use this tool versus alternatives like get_selection_context or create_screen. There is no mention of prerequisites, typical workflows, or conditions that would make this tool the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0design.create_componentdesign.create_screendesign.export_irdesign.generate_codedesign.get_capabilitiesdesign.get_design_contextdesign.get_screen_contextdesign.get_selection_contextdesign.get_visual_contextdesign.list_eventsdesign.list_hostsdesign.pingdesign.update_selectionScored across 13 tools
Several tools overlap: get_selection_context and export_ir both return DesignIR, get_visual_context and get_design_context both include PNG, and get_design_context duplicates generate_code's code output. Descriptions clarify some boundaries, but an agent could easily struggle to choose between the composite get_design_context and the more specific tools.
All tools share a consistent design. prefix and use a clear verb-first snake_case pattern: list, get, export, generate, create, update, ping. The naming is predictable and easy to navigate.
13 tools is a well-scoped set for a design bridge covering host discovery, context retrieval, IR export, code generation, and mutation actions. Each tool serves a distinct workflow step without unnecessary bloat.
The surface covers the core design-to-code journey: reading selection/screen context, getting visuals, exporting IR, generating code, and creating/updating design artifacts. Some operations like listing all screens/components or deleting/updating components are missing, but agents can still complete primary workflows.
Give your AI agents a design superpower. Generate, edit, and publish publication-grade decks, reports, landing pages, resumes, and marketing visuals directly within your agent workflow. Delivering frontier-level design quality at 3× the speed and 53× lower cost -from conversational prompt to live link or vector PDF in minutes.
UI design from prompts, screenshots, and URLs for AI coding agents and theme tokens.
Serves your design system and coding standards to coding agents, so they stop guessing.
Agent-Native design tool - create and edit visual designs with agent assistance
