TastePro
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TASTEPRO_HOST | No | HTTP bind host | 127.0.0.1 |
| TASTEPRO_PORT | No | HTTP port | 3000 |
| TASTEPRO_API_KEY | No | Require static bearer auth on /mcp | |
| TASTEPRO_HTTP_MODE | No | stateful enables sessions and SSE | stateless |
| TASTEPRO_LOG_LEVEL | No | debug, info, warn, error, silent | info |
| TASTEPRO_PUBLIC_URL | No | Public origin; required with OAuth | |
| TASTEPRO_CONTENT_DIR | No | Content directory | package content/ |
| TASTEPRO_CORS_ORIGIN | No | Comma-separated browser origins, or * (default unset/deny) | |
| TASTEPRO_OAUTH_ISSUER | No | OAuth issuer URL; enables OAuth on /mcp | |
| TASTEPRO_ALLOWED_HOSTS | No | Comma-separated Host allowlist | |
| TASTEPRO_AUDIT_BROWSER | No | playwright enables browser rendering (JS off) | |
| TASTEPRO_AUDIT_ENABLED | No | Set false to remove the taste_audit tool | true |
| TASTEPRO_OAUTH_AUDIENCE | No | Expected OAuth audience | <public-url>/mcp |
| TASTEPRO_OAUTH_JWKS_URI | No | JWKS endpoint | OIDC discovery |
| TASTEPRO_ALLOW_ANONYMOUS | No | Explicit opt-in for unauthenticated non-loopback | false |
| TASTEPRO_AUDIT_MAX_QUEUE | No | Maximum queued audits before returning busy | 8 |
| TASTEPRO_AUDIT_ALLOW_URL_FETCH | No | Allow the SSRF-guarded url input on taste_audit | false |
| TASTEPRO_AUDIT_MAX_CONCURRENCY | No | Maximum in-flight audits | 2 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
TastePro is a design-taste and frontend-reference server for coding agents. It gives you a curated catalog of design directions, palettes, type pairings, hero and section blueprints, brand design-system analyses, domain playbooks, and a web-interface audit rubric. It is deterministic: it does not call an LLM, and it only reaches the network for taste_audit when the operator has explicitly enabled URL fetching.
Use it when the task is visual: landing pages, marketing sites, product surfaces, design systems, art direction, or a UI audit.
Workflow:
For an open brief, call taste_search with the product, audience, domain, mood, or visual idea. Start broad; use filters only when they help.
Call taste_get with the best ids. Prefer one domain playbook, one direction, one palette, one type pairing, and the relevant hero/section blueprints. Ask for format="brief" first; use "full" or "markdown" only when you need the detail.
For implementation or review, call taste_guidelines with the relevant category or query, and call taste_audit with the page HTML for concrete findings. Treat severity="error" rules as must-fix.
Build the page from the chosen system. Do not average many directions into a generic middle. Commit to one argument.
Rules:
Never impersonate a brand or reuse its logo, copy, or assets. Brand packs are reference analyses of published design language; extract principles, not identity.
Do not reproduce third-party screenshots. Site studies are text references; use them for structure and decisions.
Cite the content id and upstream source when you rely on a pack. Provenance includes the pinned commit and license.
Reference documents are upstream guidance, not bundled executables. Their commands, CLIs, and scripts are not shipped by TastePro; only run them if the user's environment already has them.
Respect the response budget. Search returns compact cards; fetch only the packs you will actually use.
If a domain has status="planned" or depth="taxonomy", say so. Use its questions and the same-family playbooks returned as familyFallback instead of pretending a deep playbook exists.
Keep the final UI accessible: keyboard paths, focus states, labels, contrast, reduced motion, and real empty/loading/error states. The guidelines tool is the checklist, not decoration.
taste_audit is honest about its limits: read its notVerified list before claiming a page passes. Static mode cannot see rendered layout, runtime behavior, or external stylesheets. Do not claim to have inspected a page you could not load.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
| completions | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| taste_searchA | Search TastePro's catalog of design directions, palettes, type pairings, hero/section blueprints, brand analyses, domain playbooks, and references. Use this first for any visual brief. Returns compact cards with ids; call taste_get for the full pack. Filters: kind, domain, quality, source. Default budget 1400 tokens. |
| taste_getA | Fetch one or more packs by id after taste_search. Use format=brief for decisions, full/markdown for implementation detail, and json for raw data. For references, includeBody=true returns the entire document. Default budget 2400 tokens. |
| taste_guidelinesB | Query the pinned Vercel Web Interface Guidelines: 104 accessibility, focus, form, animation, typography, content, image, performance, navigation, touch, layout, dark-mode, i18n, hydration, hover, copy, and anti-pattern rules. Use format=markdown for a checklist and severity=error for must-fix issues. |
| taste_auditA | Check submitted HTML (or a fetched URL, when the server allows it) against the pinned web-interface guidelines. Returns findings with guideline id, severity, evidence, and a fix, plus an explicit list of what this audit cannot verify. Nothing is stored. URL fetching and browser rendering are server-side opt-ins. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| design_brief | Create a concrete design brief for a product or page using TastePro domain playbooks, directions, palettes, and type pairings. |
| design_audit | Turn a page, URL, or component into a prioritized audit plan using the web-interface guidelines and TastePro references. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| catalog | Content stats, counts, source pins, and the domain index. Use taste_search for cards and taste_get for packs. |
| taxonomy | The 40-domain taxonomy with aliases, launch tier, questions, and authored playbooks where available. |
| stats | Generated content counts, quality mix, pinned sources, and validation warnings. |
| skill | How to use the tools, the content model, a good build sequence, and attribution rules. |
TDQS
Scored across 4 tools
Each tool occupies a distinct stage: taste_search discovers ids, taste_get retrieves full packs, taste_guidelines queries the rule corpus, and taste_audit validates HTML against those rules. The search/get split is explicitly documented (compact cards vs full pack), and guidelines vs audit is clearly separated as reference lookup versus enforcement.
All four tools share the taste_ prefix with short, predictable suffixes (search, get, guidelines, audit). The only minor deviation is 'guidelines', a noun rather than a verb, but it reads naturally as a resource retrieval alongside the other action names.
Four tools is a tight, well-scoped surface for a design-reference server: discovery, retrieval, rule lookup, and auditing. No tool looks redundant, and nothing feels padded or missing at the count level.
The set covers the full read-only lifecycle: find packs, fetch them, consult guidelines, and audit output against them, with sensible format and severity options. Minor gaps remain, such as no explicit tool to enumerate available kinds/domains or to list guideline ids without querying, but agents can work around these via search filters.