front-design-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FRONT_DESIGN_RRF_K | No | Reciprocal Rank Fusion smoothing constant | 60 |
| FRONT_DESIGN_DB_PATH | No | SQLite database path (default: $DATA_DIR/store/front_design.db) | None |
| FRONT_DESIGN_DATA_DIR | No | Root for fixtures, cache, and store artifacts (default: ./data) | None |
| FRONT_DESIGN_LOG_LEVEL | No | DEBUG | INFO | WARNING | ERROR | INFO |
| FRONT_DESIGN_SEARCH_MODE | No | auto | lexical | vector | hybrid (auto → hybrid when backend + embeddings allow it, else lexical) | auto |
| FRONT_DESIGN_DATABASE_URL | No | Required for postgres (postgresql:// or postgresql+psycopg://) | None |
| FRONT_DESIGN_HTTP_TIMEOUT | No | HTTP timeout (seconds) for network ingest | 30.0 |
| FRONT_DESIGN_STORE_BACKEND | No | sqlite | postgres | sqlite |
| FRONT_DESIGN_EMBEDDING_MODEL | No | Provider default when unset | None |
| FRONT_DESIGN_EMBEDDING_API_KEY | No | Required for openai | None |
| FRONT_DESIGN_EMBEDDING_TIMEOUT | No | Provider timeout (seconds) | 30.0 |
| FRONT_DESIGN_RRF_VECTOR_WEIGHT | No | Vector branch weight (untuned) | 1.0 |
| FRONT_DESIGN_SEARCH_CANDIDATES | No | Per-branch candidate pool before fusion | 50 |
| FRONT_DESIGN_EMBEDDING_BASE_URL | No | OpenAI-compatible base URL override | None |
| FRONT_DESIGN_EMBEDDING_PROVIDER | No | none | openai | fastembed | none |
| FRONT_DESIGN_RRF_LEXICAL_WEIGHT | No | Lexical branch weight (untuned) | 1.0 |
| FRONT_DESIGN_EMBEDDING_BATCH_SIZE | No | Embed batch size | 32 |
| FRONT_DESIGN_EMBEDDING_DIMENSIONS | No | Optional override; must match the model | None |
| FRONT_DESIGN_EMBEDDING_MAX_RETRIES | No | Provider retry count | 3 |
| FRONT_DESIGN_ENABLE_NETWORK_INGEST | No | Allow --online ingest | false |
| FRONT_DESIGN_EMBEDDING_PIPELINE_VERSION | No | Bump to force re-embedding after chunking changes | 1 |
| FRONT_DESIGN_POSTGRES_STATEMENT_TIMEOUT_MS | No | Statement timeout; 0 disables | 15000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| front_design_pingA | Liveness check — package version, runtime mode, and indexed resource count. |
| front_design_healthA | Readiness check — storage backend, effective retrieval mode, and index counts. Reports what the server can actually do right now: which backend is open, whether vector and hybrid search are available, which embedding provider is configured, and how many resources, chunks, and embeddings are indexed. Never returns credentials; database URLs are redacted. |
| discover_frontend_resourcesA | Browse and filter indexed frontend resources (components, patterns, libraries). Supports category/kind, framework, style/tags, license, accessibility, animation, maturity, source_id, limit, and offset. Returns paginated items with provenance. |
| search_frontend_knowledgeA | Search frontend knowledge chunks. Uses BM25 on the SQLite backend and hybrid full-text + pgvector retrieval when PostgreSQL and an embedding provider are configured. Pass query plus optional filters (kind, framework, tags, source_id), limit, and detail_level (brief|standard|full). Returns scores, per-branch ranks, the retrieval mode actually used, citations, and provenance. |
| get_resource_detailsA | Fetch a normalized FrontendResource by id (resource id string, e.g. motion:motion-library), related sanitized documentation chunks, and license/attribution. Parameter name is |
| compare_frontend_optionsA | Compare frontend options by id or name. Primary parameter: |
| recommend_frontend_stackA | Recommend a frontend stack from requirements, target_framework, constraints, aesthetics, accessibility, and performance. Returns recommendation, trade-offs, incompatibilities, plan, sources, with facts vs inferences. |
| find_componentsA | Find components/patterns for an intent string (hero, pricing, navbar, dashboard, onboarding, microinteraction, scroll animation, …) with optional framework filter. |
| find_animation_patternsA | Find animation patterns for a query/use-case. Includes cost notes, accessibility, and prefers-reduced-motion support when known from indexed notes; cites sources. |
| build_frontend_briefA | Build an implementation brief from product_description + constraints: stack, components, motion system, suggested design tokens, responsive behavior, and acceptance criteria. Inferences are marked clearly. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| frontend_implementation_brief | Guide an agent to produce an implementation brief from local frontend knowledge. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| list_sources | List registered source adapters with license metadata. |
TDQS
Scored across 10 tools
Most tools have distinct purposes: health checks separate liveness from readiness, and search vs browse vs find differ in mechanism. However, find_components overlaps somewhat with discover_frontend_resources, and compare/recommend/build are all advisory in nature, which could cause occasional misselection.
All tool names are snake_case and follow a verb_noun pattern. Minor inconsistency: front_design_ping and front_design_health use the front_design_ prefix, while others place 'frontend' in the middle or end (e.g., discover_frontend_resources). Overall still predictable.
10 tools is well-scoped for a frontend design knowledge and advisory server. Each tool covers a distinct part of the workflow: health, discovery, search, details, comparison, recommendation, and brief building. There's no bloat or thinness.
The server provides solid coverage for the core lifecycle of frontend design assistance: discover, search, retrieve details, compare, recommend, and build a brief. Minor gaps exist, such as missing an explicit way to list all available frameworks/categories or a dedicated 'list sources' endpoint, but these are not critical.