Pattern MCP - Showcases

11 Patterns

5 Categories

9 Dependency edges

33 Invariants

architecture · 2docs · 2ui · 1jobs · 1ai · 5

Every number on this page is computed live from mcp/patterns.registry.json — the same file the MCP server reads.

Pattern Dependency Graph

The registry's depends_on graph — arrows point dependency → dependent; node color marks DAG layer, not category.

Live projection of mcp/patterns.registry.json. Emulating a pattern means building its ancestors first.

1 of 11 patterns (ui-component-system) have no dependency edges and are not drawn above — the Data tab lists every pattern.

One tool call's journey through the ephemeral, read-only server container.

Kernel-enforced isolation: the server can read the repo and nothing else — no network, no writes, no persistence.

The six read-only tools the server advertises, and the JSON-RPC handshake every session starts with.

search_patterns

Search the pattern library by capability, feature, or concept — the entry point; follow up with get_pattern.

query natural-language or keyword query (required)

limit max results, 1–20, default 5

category optional exact filter: architecture, ai, ui, docs, jobs

get_pattern

Fetch the full curated card for one pattern: docs, code entry points, tests, showcase proof, invariants, emulation notes.

id exact pattern id, e.g. "layered-rag" (required)

get_file_excerpt

Read a bounded, line-numbered excerpt of a referenced repo file. Secret paths and traversal are rejected.

path repo-relative path (required)

start_line 1-based start line, default 1

line_count 1–250 lines, default 100

trace_capability

Trace a capability end-to-end: concept → docs → code → tests → showcase proof, with invariants attached.

capability capability or concept to trace (required)

recommend_emulation_plan

Assemble a dependency-ordered emulation plan — deterministic registry assembly with prerequisites, no inference.

capabilities list of desired capabilities (required)

include_dependencies expand prerequisites via depends_on, default true

validate_snippet

Check a Svelte/TS snippet against v10r conventions (runes, component-first, tokens, Valibot) — loop until clean.

snippet code to validate, at most 20000 chars (required)

language 'svelte' or 'ts', default 'svelte'

The client → server sequence mcp/smoke.ts exercises. Notifications get no reply; tools/call repeats per invocation.

Think this pattern could be better? Tell us how.