1-line summary: This server bridges Figma and Adobe XD to MCP clients, exposing design context and read/write tools for agents to inspect, extract, and modify designs.
Host & capability discovery: List connected design hosts (design.list_hosts), list recent events (design.list_events), and check host capabilities (design.get_capabilities).
Read design context: Get current selection (design.get_selection_context), a specific screen/artboard (design.get_screen_context), visual PNG renders (design.get_visual_context), and full DesignIR exports (design.export_ir).
Combined context for agents: design.get_design_context returns structured DesignIR properties, a visual PNG, and optionally generated target code together.
Generated code: design.generate_code produces starter implementations for web, React, Vue, Flutter, SwiftUI, or Jetpack Compose.
Write operations: Create screens (design.create_screen) and components (design.create_component), update the current selection with a normalized patch (design.update_selection).
Health check: design.ping verifies whether a host plugin can receive requests.
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.
Free, local-first Figma MCP for AI coding agents — read, create and edit designs without a Figma API token or paid MCP access.
DesignPort gives Codex, Claude Code and Cursor both a PNG visual reference and structured design context: hierarchy, layout, typography, tokens, components and interactions. One MCP process connects to the Figma Plugin API through a local WebSocket bridge. DesignPort does not generate framework code; the agent implements the design using the target repository's own stack.
Codex / Claude Code / Cursor
│ MCP over stdio
DesignPort
│ WebSocket on localhost:5514
Figma plugin
│ Figma Plugin API
Open design fileRequires Node.js 22 or later and Figma desktop to import the development plugin.
npm ci
npm run buildIn Figma, choose Plugins → Development → Import plugin from manifest…, select plugins/figma/manifest.json, and run DesignPort Figma in the document you want the agent to use. Keep the plugin running.
Register the built server with one command from the repository root:
codex mcp add designport -- node "$PWD/dist/src/index.js"Codex MCP setup. For Claude Code:
claude mcp add --transport stdio designport -- node "$PWD/dist/src/index.js"For Cursor, add this to .cursor/mcp.json, replacing the path:
{
"mcpServers": {
"designport": {
"command": "node",
"args": ["/absolute/path/to/designport/dist/src/index.js"]
}
}
}The MCP client starts the server and bridge together. Use one client process on port 5514 at a time. Call figma.status to check the connection. Multiple open Figma documents require an explicit sessionId from that response.
The npm package and Community listing are release pending. Once the npm package is published, the equivalent Codex setup is codex mcp add designport -- npx -y designport@1.0.0. The package includes the Figma plugin files.
Related MCP server: figmad-mcp
Tool | Purpose |
| Connections, capabilities, bounded recent events and limits. |
| DesignIR, tokens, layout, component properties and overrides, internal audit/graph and matching PNG. |
| Bounded original or rendered asset bytes from a capture. |
| Native frame, text, rectangle, component and local instance trees with Auto Layout. |
| A distinct patch per node: text, typography, geometry, parent, layout, fills, strokes and exposed instance text properties. |
| Explicit captured subtree deletion. |
| Subtree cloning with destination parent, name and position. |
| Bounded instant on-click navigation and named flow starts. |
There are no legacy tool aliases. Version 1.0 removes Adobe XD, provider adapters, design.* tools and delta responses. Audit and graph remain part of context, without separate tools. FigJam connectors, remote component imports, variant authoring and annotation workflows are outside the current scope.
Use figma.get_context for selection, screen, page or document. PNG is included by default for non-document scopes; use includeVisual: false for properties alone.
Inspect properties.snapshot.complete, coverage and omissions. A paginated or budget-incomplete capture cannot authorize a write.
Pass properties.snapshot.id as expectedSnapshotId and properties.snapshot.identity.sessionId as captureSessionId. The separate sessionId selects the bridge connection.
Send explicit node IDs. Update targets and destination parents must be captured; delete and clone require all descendants in scope. Selection changes do not redirect a write.
Read fresh context after each write or mutation failure. Writes are serialized and invalidate the previous snapshot immediately.
Creation is limited to 256 specifications, 32 roots and depth 12. Update and delete accept at most 100 targets; clone accepts 32 roots. Expanded instance creation and subtree operations are limited to 2000 native nodes. PNG/JPEG input is limited to 4 MB per image, 4096 pixels per side and 16 million pixels. Prepared write requests are capped at 8 MB.
Create and clone clean up task-created nodes on failure. Update and prototype operations attempt native rollback. Unexpected deletion failures report exactly which IDs were removed; deletion is not a database transaction. Figma's normal Undo remains available.
See examples, the DesignIR guide and the security boundaries.
Variable | Default |
|
|
|
|
|
|
|
|
The plugin's WebSocket URL and pairing value must match the server; edit plugins/figma/ui.html, code.js and the manifest together for a custom port or pairing value. The bundled pairing value is public, not a secret. No Figma REST token is involved. Design data stays between the plugin, local server and your configured coding agent; that agent may send context to its model provider.
The plugin uses Figma's required dynamic-page manifest and async APIs. It explicitly loads all pages before subscribing to document changes so external edits invalidate snapshots. Large files can take longer to initialize.
npm test
npm run typecheck
npm run build
node --check plugins/figma/code.js
npm run test:package
npm run package:plugintest:package creates artifacts/designport-1.0.0.tgz, installs it in a clean temporary directory without development dependencies, checks the real stdio tool surface and shutdown, then removes the temporary install. package:plugin prepares artifacts/figma/; supply -- --id FIGMA_ASSIGNED_NUMERIC_ID when preparing an actual Community submission. Release instructions distinguish local verification from publication.
npm run smoke:figma -- --document-name "Your scratch document" runs the create/image/clone/edit/delete scenario in a named scratch file and saves PNG evidence. npm run fixture:avia -- --port 5514 exercises the three-screen fixture in its explicitly named scratch document. Run npm run visual:compare -- reference.png candidate.png --json for local PNG comparison.
DesignPort is licensed under GPL-3.0-or-later. This implementation uses no copied Grab source.
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.
A design agent in your coding agent's loop: briefs each screen, reviews UX and visual quality.
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.
UX Pilot's design agent for your AI tools: on-brand UI, design systems and React prototypes
