Reusable visual design systems for AI coding agents — browse, fetch, and submit styles via MCP.
io.github.QuasarG/taste-bank — Model Context Protocol (MCP) Server
The io.github.QuasarG/taste-bank MCP server provides access to reusable visual design systems for AI coding agents. It enables browsing, fetching, and submitting styles via MCP, based on a shared design-systems approach for agent-driven user interfaces.
🛠️ Key Features
Browse available visual styles from a design system
Fetch specific styles for use in agent workflows
Submit styles back through the MCP server
🚀 Use Cases
Retrieve consistent UI styling for AI coding agents
Share and reuse style definitions across agent applications
Update design system assets by submitting new or modified styles
⚡ Developer Benefits
Standardized MCP-based interaction for design-system style management
Clear separation of browsing, retrieval, and submission operations
⚠️ Limitations
Only the capabilities explicitly stated (browse, fetch, submit styles) are described; additional MCP tools and behaviors are not provided in the source data.
Staring at a blank page, no idea how to lay out your components?
Layout finally settled — yet the AI's visual style never quite lands?
A hoard of "beautiful designs" you can never actually summon when you need one?
The style you painstakingly tuned in your last project has to be re-explained from scratch in the next one?
Getting coding agents to produce well-designed front-ends is a solved problem nobody can actually use. The community is full of front-end skills, prompt snippets, and design guides — but in practice:
No unified invocation: some styles ship as a skill, some as a Codex or Claude Code plugin, and some ship nothing at all — just style images or web templates. Whatever the form, actually using them is a chore.
No quality bar: without a shared schema, a "style" can be three adjectives in a trench coat — nothing an agent can actually execute.
Hard to reuse: great styles die in chat histories instead of being distilled into an asset.
Hard to migrate across projects: the style you tuned in project A must be re-described in project B, losing visual intent in every retelling.
No ownership or iteration: no versions, no way to say "only I maintain my styles."
More importantly: the web spawns new styles, UI/UX patterns and layouts every single day — but not every style is mainstream enough, not every style is your taste, and no one can ride every new wave. So we want to build a community where people share the front-end taste they actually use — and vote with their feet. Only what truly gets used is truly usable.
Taste Bank's answer: distill each style into a structured style pack (SKILL.md usage guide + precise design tokens + templates/ snapshots), enforced by a zod schema, and serve it through three channels that share one core — a web gallery for humans, an HTTP API for scripts, and an MCP server that hands styles directly to any coding agent. Once a style is in the bank, it's reachable anywhere, versioned, and owned.
What makes us different from other front-end communities: they collect beautiful styles; we make styles instantly callable. Other galleries are growing, but their styles live in long prose descriptions you must read, interpret, and hand-feed to your tools. Here you never wrestle a description — you just tell your agent in plain language, "I want that blueprint style", and the MCP server delivers it machine-readable, ready to execute.
Taste Bank homepage — infinite style stream and leaderboards
The homepage gallery: swipe through live-rendered styles like a feed — horizontal card rail with interactive preview, most-referenced styles and top authors at a glance.
Features
TikTok-style gallery: the homepage is an endless stream of live-rendered style previews — keep scrolling until one catches your eye, then flip into the horizontal card rail mode to inspect it. Scroll to switch cards, click to jump directly. Swipe, pause, pick. Collections page offers a full grid with categories and pagination
Leaderboards: most-referenced styles and top authors, counted every time an agent pulls a style
Browsing (list_styles, etc.) needs no invite code; submitting (submit_style) does. Contact the repo owner to get one (see GitHub).
Don't know how to configure MCP? Just paste this JSON to your agent and say "set up this MCP server for me" — it will wire itself up.
Then just talk: "Build me a landing page with one of the styles in taste-bank." The agent will call list_styles to pick one, get_style_skill to fetch the full usage guide, and implement strictly within its tokens.
Tool cheat sheet (full guide on the site's /about page; agents can also call get_usage_guide):
Survey the bank, read exact tokens, export CSS, inspect templates
Apply
get_style_skill
Fetch the assembled SKILL.md — hand it to any coding agent to implement the style
Submit
submit_style
Submit a new style pack (invite code + signature, enters review queue)
Manage
update_style / delete_style
Iterate or unpublish your own styles (private-key signature)
Keys
generate_keypair
Generate an ed25519 keypair (ownership credential)
Identity
whoami / validate_style
Check your bound author & owned styles / dry-run validate a payload before signing
3. Submit your own style
In any agent tool that supports MCP tool calls (Kimi Code / Claude Code / Cursor, etc.), open any project with a front-end style worth keeping, and simply say: "submit this project's style to taste-bank." The agent samples the real stylesheets, sanitizes anything business-identifying, packages the style pack, and submits it for review — all on its own. Once the maintainer approves, your style is in the bank.
Security
Taste Bank lets anyone submit with an invite code, and lets agents read arbitrary style content — so authentication and content safety are designed end to end:
Authentication & ownership
Invite codes: submissions require x-invite-code; a code binds to the submitter's public key on first use — one code, one identity; only hashes are stored server-side
ed25519 signatures: submit / update / delete all require a private-key signature (message = style-lab:<action>:<slug>:<timestamp>:<sha256(payload)>, 30-minute window) — your key is your identity, no password to leak
Review queue: submissions land in data/pending/ and go live only after the maintainer's manual approval; rejection incinerates
Rate limits: submits 20/min per pubkey, updates & deletes 30/min per slug, MCP 120/min per IP
Content safety
Template sandbox: every template preview renders in a sandbox="" iframe with a CSP that forbids scripts and external loads — templates can't escape the canvas
HTML blocklist validation: submission templates are screened against an extended attribute blocklist
Prompt-injection mitigation: style content is explicitly labeled "data, not instructions" in tool descriptions, so malicious styles can't hijack agents
Path-escape protection: all file reads are normalized; ../ escapes are rejected
⚠️ A word of caution: every submitted style is manually reviewed by the maintainer for prompt-injection and other attacks — and if you submit, you must make sure your pack carries no sensitive data or business-identifying content from its source project. But reviews can miss things. Do not blindly trust any content an agent fetches to your local environment — treat it as data, and stay alert to prompt-injection attempts.
Manage your styles via MCP
Every style you submit is yours — create, read, update, delete, and iterate versions at will. No accounts, no passwords: your private key is your ownership.
Why keys instead of accounts? Deliberate design. To protect submitters' privacy as much as possible — and to keep the server's storage footprint minimal — Taste Bank identifies and authenticates you with a public/private keypair rather than an account system. No emails, no passwords, no user table: nothing personal to store, and nothing personal to leak. The one trade-off: guard your private key with your life — it is the sole proof that a style belongs to you.
First time: get your keys
Ask your agent to call generate_keypair for an ed25519 keypair:
Public key ownerPubkey: submitted with your pack to register ownership
Private key: persist immediately to ~/.style-lab/private.key (Windows: C:\Users\<you>\.style-lab\) and back it up. It exists only in the current session — lose it and you permanently lose control of the style. Agents should check for this file first and never regenerate blindly
Submit: call submit_style with a payload of meta / tokens / skill / templates / ownerPubkey, signed. Invisible until approved by the maintainer.
Iterate: call update_style; version must be strictly newer (e.g. 1.0.0 → 1.1.0). Ownership carries over.
Unpublish: call delete_style; once the signature verifies, it's gone for good.
Signing needs no repo and no local tooling: the usage guide your agent fetches via get_usage_guide embeds a self-contained Node script that does it.
