Pine MCP

A workflow gate for AI-assisted design system adoption.

Pine MCP helps AI assistants detect when Pine is needed, retrieve the right component and token context, and validate generated UI against design system rules. The goal is generated code that starts closer to Pine components, accessibility standards, and implementation patterns.

Problem

AI was speeding up coding, but bypassing the system.

As engineers started using AI assistants to move faster, generated interfaces often came back built with generic markup, Tailwind classes, or patterns from other component libraries. That created a new kind of design system adoption problem: code could drift away from Pine before a human had a chance to review it.

The issue was not that engineers did not value the design system. The issue was that the assistant did not understand the system. Pine needed to be consumable by people and by the tools helping those people write code.

Approach

Expose design system knowledge where generation happens.

Pine MCP exposes design system knowledge to AI-assisted development workflows: available components, design tokens, governing rules, implementation guidance, accessibility requirements, composition advice, and anti-patterns that help course-correct generated output.

Pine MCP In Practice

Three places Pine MCP changes generated UI decisions.

Generic AI assistants generate plausible code. Pine MCP changes the decisions being made during generation by injecting design system knowledge, accessibility guidance, layout constraints, token rules, and component recommendations.

Accessibility

Developer Request: Add an icon-only close button to dismiss a panel.
Generic AI Output: The assistant generated a button with only an aria-hidden icon, leaving the control without an accessible name.
Pine MCP Guidance: Icon-only interactive controls need a programmatic label, and decorative icons should stay hidden from assistive technology.
Final Pine-Compliant Result: The final output uses the Pine button pattern with a clear accessible name and a decorative icon that does not pollute the screen reader experience.
Why It Matters: A screen reader user can understand and operate the close action without guessing.

Layout constraints

Developer Request: Build a responsive settings layout with a main form and supporting panel.
Generic AI Output: The assistant reached for a generic Bootstrap or Tailwind-style grid instead of Pine's layout primitives.
Pine MCP Guidance: Pine layout starts with container, then row, then box, with mobile-first sizing and spacing handled through system props.
Final Pine-Compliant Result: The generated layout follows the Pine container, row, and box workflow so spacing, breakpoints, and composition match the system.
Why It Matters: Teams get a layout that behaves consistently across product surfaces and screen sizes.

Token usage

Developer Request: Style a warning message with the right text and background colors.
Generic AI Output: The assistant used hardcoded colors or core token names that described values instead of product meaning.
Pine MCP Guidance: Use semantic tokens that map intent to theme-aware values instead of raw colors or low-level primitives.
Final Pine-Compliant Result: The final output uses semantic Pine tokens, so the warning adapts across light mode, dark mode, and future themes.
Why It Matters: The UI stays readable and theme-compatible without one-off color fixes.

Validation Artifact

Generated UI moves through Pine before it reaches review.

The core shift is timing. Instead of waiting for a design system reviewer to catch generic layout patterns in a PR, Pine MCP moves the correction into the generation loop.

Before AI output

Plausible web code

Generated layout used Bootstrap-style columns, raw div wrappers, inline flexbox, and hardcoded spacing that looked reasonable in chat but did not follow Pine layout primitives.

Pine MCP guidance

System context at generation time

Pine MCP retrieved the layout rule: start with pds-container, compose with pds-row and pds-box, use mobile-first sizing, and avoid raw layout divs inside Pine UI.

Correct output

Pine-compliant layout

The final layout used Pine components, system spacing props, semantic tokens, and structure that could pass layout validation before review.

Component Decision Artifact

Pine MCP turns raw tabs into the Pine tabs component.

This is the clearest version of the problem Pine MCP solves: generic AI output can look plausible while missing the actual component, semantics, keyboard behavior, and accessibility contract.

Before: generic AI output

The assistant generated a tab-like interface from spans and a panel. It looked like UI, but it was not an interactive tabs pattern.

<div>
  <span>Sturdy</span>
  <span>Growth</span>
  <span>Pro</span>
  <div class="panel">...</div>
</div>

After: Pine-compliant direction

Pine MCP detects the tab pattern and routes generation toward the documented Pine component instead of raw markup.

<pds-tabs>
  <!-- Pine tab items and panels follow the documented pds-tabs API -->
</pds-tabs>

Why it matters

The important change is the component decision: unstructured spans become a design system component with the expected API, interaction behavior, and accessibility contract.

What Pine MCP Actually Changes

It replaces the most common answer with the system answer.

Across all examples, Pine MCP collapses a fork in the road into a single correct answer. Instead of selecting patterns based on what is most common on the web, Pine MCP applies the current design system's rules at generation time.

Accessibility
Component Selection
Layout
Tokens
Semantic HTML

These are the same decisions a senior design system engineer would normally catch during code review. Pine MCP moves them earlier into the generation process.

MCP Tools

Tools for components, docs, review, and repair.

get_pine_component
list_pine_components
list_pine_icons
get_pine_design_doc
ask_pine_agent
review_generated_layout
fix_layout_issues

Read the article Talk design systems and AI Back to work