Empower your agents to ship great products with taste

Pattern gives coding agents better design judgment by searching real component libraries, checking options against your framework, product domain, and requirements, then giving them a recommendation they can act on while they build

install command
npm install pattern-mcp
one call, mid-build
The agent asks
recommend_component({
  component_need: "price breakdown with fees and taxes",
  domain: "Airbnb-style rental marketplace",
  framework: "React + Tailwind",
  existing_stack: "already using shadcn/ui",
  project_id: "my-booking-app"
})
Pattern answers
{
  "verdict": "custom_build",
  "confidence": "high",
  "reason": "scored",
  "coverage": "2/8 (25%)",
  "computed_at": "2026-08-25",
  "recommendation": {
    "source": null,
    "reference": {
      "source": "Mobbin",
      "url_type": "deep_link",
      "flow_name": "Booking, price details"
    }
  },
  "ensemble": { "triggered": false }
}
Tell your coding agent

Use recommend_component before picking a UI component: pass the specific need, my domain, and framework, then act on the verdict. Install what it recommends, or build from the reference it returns

install, any MCP client
claude mcp add pattern \
  -e ANTHROPIC_API_KEY=sk-ant-... \
  -- node /absolute/path/to/pattern-mcp/dist/index.js
Build the price breakdown for the booking checkout: nightly rate, cleaning fee, service fee, taxes.
recommend_component({ component_need: "price breakdown with fees and taxes", … })
recommend_componentscoring
Itemized line rows (rate, fees, taxes)
Nightly rate × nights subtotal
Collapsible fee explanation
Currency + locale formatting
Total row with emphasis
Discount / long-stay line
Tooltip on service fee
Mobile bottom-sheet layout

The agent reaches a design decision

Mid-build, in a real project. This is where an agent needs to choose a component, but it has little context for what good looks like. It can grab something loosely related or invent a generic solution

Judgment against requirements, not keywords

Pattern turns the component need into a requirements checklist, searches shadcn/ui and 21st.dev, and scores each requirement against the evidence it finds. The server recounts coverage from the checklist instead of trusting a stated percentage

If a real component fits, it installs it

A use_existing verdict includes the source, install command, and a description of what the component actually does. The description is based on the component Pattern found before anything is installed. The install command is untrusted text, so your agent shows it to you before running it

If nothing fits, it builds from a real reference

A custom_build verdict returns the checklist plus a grounded Mobbin or Figma Community reference. Deep links are verified server-side against a page that was actually fetched. When only a browse page exists, Pattern says so

Some needs don't need a call

Buttons, inputs, checkboxes, badges, spinners, tooltips, avatars, and icons are trivial primitives. A local skip-list catches them before any API request, so they add no API cost or latency

It remembers what this project already decided

record_component_decision logs decisions the agent actually acted on, per project. A later call can use a similar past decision as a signal, never as a rule and never instead of searching and scoring again

Capabilities

The design judgment happens here, and every part is visible in the output

Requirement coverage, scored against evidence

Each requirement is checked against something the search actually found, then recounted in code and thresholded into a verdict. This is not a similarity ranking

Zero candidates stays its own answer

no_candidates_found stays distinct from low coverage, so "nothing exists for this" never gets turned into a bad match

References that are verified, not implied

A deep link survives only if it appears on a page the server fetched. Otherwise you get the browse page and a note saying exactly what it is

Per-project decision memory

Confirmed decisions become a consistency signal on later calls. Coverage is still recomputed every time, and verdicts are never cached

Disagreement is disclosed, not smoothed

Near a verdict threshold, the judgment runs again and takes the majority. A genuine 2/3 split returns confidence: low with the runs attached

Costs you can see

A local call log for each API-reaching call, a 40-call session cap, prompt caching, and a bounded search budget. Skip-listed primitives never reach the API

For agent users

You already build with Claude Code, Cursor, or Codex CLI

One config block, any MCP client. It's a standard server, not a plugin for one tool
Your agent stops inventing generic UI when something real already fits
Every verdict is readable: the checklist, coverage, evidence, and timestamp
Five validated test cases let you sanity-check the tool before trusting it on your own work

Reference

recommend_component input
FieldTypeNotes
component_needstring, requiredSpecific, not a category. "price breakdown with fees and taxes", not "pricing"
domainstringThe product context the component lives in
frameworkstringe.g. React + Tailwind
existing_stackstringe.g. already using shadcn/ui
project_idstring, optionalEnables per-project decision memory. Omit to skip memory entirely
recommend_component output
FieldValuesNotes
verdictuse_existing | custom_buildThresholded in code from the recounted coverage
confidencehigh | medium | lowForced to low on a genuine 2/3 ensemble split
reasonscored | no_candidates_found | skip_listZero candidates stays distinct from low coverage
coverage"5/7 (71%)"Recomputed from requirements_checked, not taken from the model
requirements_checked[]requirement, met, evidenceThe checklist, with the evidence behind each judgment
recommendation.referenceobject | array | nullBoth sources grounded → array. One → object. Neither → null
reference.url_typedeep_link | entry_pointWhether the URL is the actual screen or a browse page
ensemble{ triggered, runs, agreement }Present on every response; runs and agreement only when it fired
past_decision_signal{ considered, note }Only when project_id was passed and a real past decision applied
Configuration
Env varDefaultNotes
ANTHROPIC_API_KEYrequiredYour own Console key. Every call bills your account
PATTERN_MODELclaude-sonnet-5Swap models without a code change. Re-run the five test cases first
PATTERN_SESSION_CAP40Per-process call cap, a runaway-agent guard, not a usage budget
PATTERN_MEMORY_PATH~/.pattern/memory.jsonWhere confirmed decisions are stored, local only
PATTERN_LOG_PATH~/.pattern/calls.logOne JSON line per API-reaching call, local only
The five validated cases
Component needWhat it tests
price breakdown with fees and taxesclean commodity match
cancellation policy displayfalse-positive-prone
host earnings dashboardboundary / near-tie
image gallery for a property listingflips even with the ensemble, reported as low confidence
host-guest messaging inboxwent stale as libraries shipped new components

All five sit in one Airbnb-style rental-marketplace domain and cover the full range of outcomes. Run them before trusting the pipeline unattended, and again after changing models

Using it well

When to let the agent call this, and when it's overkill

A component with real requirements

Fee breakdowns, policy displays, dashboards, inboxes. Anything where fit requires judgment

Before the agent starts writing UI

The verdict is useful while there's still a decision to make

Trivial primitives

Buttons, inputs, badges, spinners. The skip-list already answers these for free

Anything you'd cache and reuse

Coverage is a snapshot with a computed_at date. Keep caching session-scoped, never across builds

One limitation is worth knowing before you start: the model can judge the same evidence differently between runs on identical input. The ensemble catches cases where that could flip a verdict and reports them as confidence: "low" instead of hiding the disagreement.