Catch the wrong UI decision before your agent builds it

Pattern checks a UI component need against real, current evidence before your agent commits to it. It finds a component that fits or shows you when nothing does, so you find out before it's built, not after.

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 }
}
Pattern checks
  • What the component needs to do
  • What existing components actually support
  • How well each option covers the requirements
  • Whether an existing component is the right fit
  • What real references to use when nothing fits

The agent gets a verdict: use an existing component or build it custom from a real reference, with the evidence behind the decision.

Installation

install command
npm install pattern-mcp
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

Requires your own Anthropic API key from the Console, not a Claude subscription. Every call bills your account directly, roughly $0.06 to $0.30 per call depending on whether the boundary-risk ensemble triggers.

Every UI decision is a decision you haven't verified

An agent can pick a component in seconds. If it's wrong, you often don't find out until the component is already wired into your product.

Maybe it misses an important requirement. Maybe it technically works but is far more than your project needs. Maybe your agent builds something generic because it never found a better option.

That's when the real cost shows up: rework, unnecessary dependencies, and more code to maintain.

Pattern adds a check before the agent commits. A call costs a few cents and takes about 30 seconds. The alternative is discovering the mismatch after the build has already started.

How it works

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 UI decision it hasn't verified

This happens in the middle of a real build.

Your agent needs to choose a component, but nothing has checked whether it's actually the right fit. It can pick something loosely related, or build something generic because it never found a better option.

Pattern checks the decision against real evidence before the agent commits to it.

Judgment against requirements, not keywords

Pattern turns each component need into a requirements checklist. It searches shadcn/ui, 21st.dev, and ReUI, then checks each requirement against the evidence it finds.

The server calculates coverage from the checklist itself instead of trusting a percentage the model reports. This isn't a keyword search or a similarity score. It's a check against what the component actually supports.

If a real component fits, use it

A use_existing verdict includes the source, install command, and a description of what the component actually does.

Pattern evaluates the component before recommending it. Your agent shows you the install command before running it.

If nothing fits, build from a real reference

A custom_build verdict returns the requirements checklist along with a grounded reference from Mobbin or Figma Community, so your agent gets a concrete starting point instead of inventing the interaction from scratch. Direct links are verified before they're returned. 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 simple building blocks.

Pattern catches them locally, before making an API request. That means no added cost and no extra wait.

It remembers what this project already decided

record_component_decision saves the component decisions an agent actually acted on, organized by project.

Later, the agent can use similar past decisions as a signal when making a new decision. But past decisions never become rules. The agent still searches for current options and scores them against the requirements every time.

This gives the agent useful project context without locking it into an old choice.

How Pattern saves time

Turns vague needs into clear requirements

Pattern turns a UI need into a specific checklist before it searches.

Your agent gets a clearer definition of what the component needs to do instead of guessing what "pricing" or "a table" actually means.

Finds and checks real components

Pattern searches real component libraries and checks each requirement against the evidence it finds.

It returns a decision your agent can act on immediately: use an existing component or build something custom.

Skips the decisions that don't need checking

Buttons, inputs, badges, and other simple primitives are handled locally.

No API call. No added cost. No extra wait.

Gives custom builds a real starting point

When nothing fits, Pattern returns a grounded reference from Mobbin or Figma Community.

Your agent builds from a real example instead of starting from a blank page.

Keeps decisions consistent within a project

Confirmed decisions can inform future recommendations in the same project.

Pattern uses that history as context without letting old decisions override better evidence.

How Pattern helps avoid costly mistakes

A technical match can still be the wrong choice

A component can satisfy every requirement and still be more than your project needs.

A full data-table library might technically work for a five-row table. That doesn't automatically make it the right decision.

Pattern helps surface the difference between something that qualifies and something that fits the scope of what you're building.

It shows uncertainty instead of hiding it

Some decisions are close. When a result lands near a decision threshold, Pattern runs the judgment again. If the results disagree, Pattern reports that disagreement and returns confidence: low.

Your agent sees that the answer is uncertain instead of getting a confidently wrong recommendation.

"Nothing found" is different from "bad match"

Sometimes there simply isn't a component that fits.

Pattern keeps no_candidates_found separate from low coverage, so your agent knows whether an option is a weak match or whether nothing like it was found at all.

References are verified before they're returned

Pattern checks direct links against pages it actually fetched.

If it can verify the specific screen or file, it returns a direct link. If it only has a browse page, it tells you that clearly.

Every call shows its cost

Pattern makes the cost of each decision visible.

You can see the time, tokens, and estimated API cost instead of working from an opaque usage budget.

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
checkliststring[], optionalSkip internal extraction and score against this instead. Pairs with extract_requirements
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
checklist_sourceextracted | providedWhich path actually produced the checklist that got scored
_meta{ total_ms, breakdown_ms, tokens_used, estimated_cost_usd }Real timing, tokens, and cost for this call. Summed across all 3 runs when the ensemble fires
extract_requirements input — optional, runs extraction on its own
FieldTypeNotes
component_needstring, requiredSame field as recommend_component's input
domainstring, requiredExtraction is grounded in this, not the component name alone
extract_requirements output
FieldValuesNotes
checkliststring[]Exactly 8 items, ranked most-important first, unless the need hit the skip-list
extraction_confidencehigh | medium | lowA word-count heuristic today, not a calibrated signal. Treat low as a prompt to reread the input
_meta{ total_ms, tokens_used, estimated_cost_usd }No search happens here, so this is typically a few seconds and a fraction of a cent
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

Best Practices

Use Pattern for:
A component with unique 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

Avoid using Pattern for:
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

Model judgment can vary: two runs can find the same components through the same searches but judge the same evidence differently. The boundary-risk ensemble exists to detect and surface that uncertainty, reporting it as confidence: "low" rather than hiding it.