Figma MCP vs design-reference MCP vs component-library MCP

Choose Figma MCP when you have a design to implement. Choose a screenshot-reference MCP when you need to decide what the interface should look like. Choose a component-library MCP when you need reusable implementation pieces. These choices can belong to the same project, but they answer different questions.

The distinction becomes useful when instructions conflict. An agent may receive an approved Figma frame, a screenshot with a different navigation pattern, and a registry block with its own layout. Before asking for code, decide which source defines the result and which sources may inform the implementation.

An approved design makes Figma the starting point

If a designer has approved the account-settings screen, start from that screen. Figma's MCP introduction documents design-context extraction from files, including variables, components, and layout data. It also describes broader capabilities such as writing native Figma content. Here, the relevant job is implementation of the agreed design.

The tool documentation separates get_design_context, get_variable_defs, and get_screenshot. That gives the agent design information alongside a picture of the intended result. Supply a precise frame or layer link and name the framework and existing UI components it should use.

For connected components, Code Connect can add actual codebase implementation details to the agent's context. This overlap matters. Figma can participate in component reuse, so the categories in this comparison describe reader jobs rather than hard product boundaries.

Our recommendation is to keep outside inspiration subordinate to the approved design. A reference with a more dramatic heading gives the agent another option, but your team already chose the heading hierarchy. If the frame leaves mobile behavior or an error state unspecified, identify that gap explicitly and resolve it before treating a borrowed pattern as a requirement.

An open brief calls for reference research

An instruction such as 'build a landing page for a developer tool' leaves the composition open. Before implementation, compare relevant screenshots and choose the visual rules you want to keep. The useful output of this research is a direction you can describe and review.

Mobbin's MCP introduction documents natural-language searches for real-world UI and screen images returned inline to agents. swaggin provides taxonomy-led searches and curated screenshots through its hosted MCP server. You can inspect swaggin's collection in the gallery and connect through the setup guide. Compare the references each tool finds for your actual brief.

A screenshot shows the appearance of a captured state. It does not establish the original component API, the complete interaction model, or the layout rules at unseen widths. Record those as implementation decisions. For example, you might borrow a compact navigation and wide text column while choosing your own accessible mobile menu behavior.

Keep the selection coherent. If one reference uses dense technical copy and another uses sparse editorial sections, decide which density suits your content before asking the agent to combine them. Our analysis of generic agent landing pages explains why vague visual instructions leave too much room for default choices.

A component library answers implementation questions

After choosing the design, you need components that fit the repository. The shadcn MCP documentation describes browsing, searching, and installing items from registries configured in components.json. Sources can include a private company library as well as public registries. This is useful when you need a specific form or dialog implementation.

Start with the code already in the project. If the application has a dialog with the right focus behavior and theme support, tell the agent to reuse it. A registry search becomes useful when the current library leaves a gap. Review the proposed addition before you accept another component that does the same job.

A complete registry block may include a composition you like. That can be a valid starting point for an open brief. For an approved screen, however, evaluate the block against the design. Decide whether to adapt its pieces or choose smaller components. The easiest block to install may require substantial changes to satisfy the agreed layout.

Assign authority before combining sources

Write a short decision order in the task. Product requirements determine content and behavior. An approved design determines visual intent. Repository conventions determine component reuse and code organization. External references fill named gaps. This is our suggested order for an existing product, and your team can change it deliberately.

Consider a pricing page. The approved plan data determines the actual tiers. A screenshot can help with comparison density. A component library can supply the disclosure control for detailed features. If the reference has a recommended-plan badge, the agent still needs an explicit product decision before adding one. Our pricing-page research gives that decision a concrete reference point.

Give the agent a brief that names the source's job

These example briefs separate the decisions so you can review the agent's reasoning before it writes the page:

• For an approved design, implement the linked Figma frame with the repository's existing components. Identify missing responsive states and ask for a decision on those gaps before changing the visual direction.
• For an open brief, find relevant screenshots and propose a composition using the real page content. Name the typography hierarchy, navigation density, and section rhythm you intend to borrow. Choose the direction before implementation.
• For component work, inspect the existing library, then search the configured registry for the missing control. Explain the integration change and preserve the approved layout when adding it.

Review the rendered page against the chosen target

Complete the loop in the browser. Playwright MCP documents screenshots for visual inspection alongside accessibility snapshots for interaction. Review the viewport sizes and states your product actually supports. Exercise the menu, submit the form, and inspect the error response as well as the default view.

For an approved frame, review visual departures from that frame. For an open brief, review whether the implementation follows the direction you selected. For a new component, review its behavior in the surrounding page. Our frontend MCP server shortlist links the official tools for each stage.