What can you do with this server?

Refero MCP lets you search, explore, and generate design assets from the styles.refero.design catalog. * Natural-language search (refero_search): Query the catalog with vibe-based plain English (e.g., "dark editorial with serif", "playful neobrutalist saas") using OpenAI embeddings for semantic ranking or BM25-lite keyword scoring as a fallback. Supports filtering by theme (light/dark) and tags. * Fetch full design system (refero_get): Retrieve complete design system details for a style by UUID, hostname/URL (e.g., cursor.com), or site name (e.g., "Cursor"), with fuzzy name matching. * Generate DESIGN.md (refero_design_md): Render a style as a structured markdown file with frontmatter, north star summary, color tables, fonts, and dos/don'ts. Optionally saves the file directly to a project folder in your configured vault. * Find similar styles (refero_similar): Get Refero's own recommendations for styles similar to a given one, useful for exploring alternatives. * Browse catalog (refero_list): Page through the locally mirrored catalog with optional filtering by theme and tags (ordered newest first, then by site name). * Refresh catalog (refero_refresh): Force a full re-fetch of all styles from styles.refero.design, bypassing the default 24-hour cache TTL.

Which integrations are available for this server?

Allows retrieval of design system details (colors, typography, spacing, dos/donts) for Linear from the Refero catalog. Allows retrieval of design system details for Vercel from the Refero catalog.

How do I use Refero MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Refero MCP Find a dark editorial style with a serif font." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

Refero MCP

Official

by fidgetcoding

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Refero MCP

Search styles.refero.design in plain English and drop a DESIGN.md into any project.

npm version License: MIT Node MCP Compatible

Link	Section	What it does	Time
What this is	Overview	The catalog, the gap, the wrap	~1 min
Quick install	Setup	One line into Claude Code	~1 min
Usage	Talk to it	Plain-English prompts	~2 min
Tools	Reference	The six tools, one line each	~1 min
Configuration	Setup	Env vars + JSON config	~1 min
How it works	Reference	Cache, embeddings, DESIGN.md generation	~1 min
Troubleshooting	Reference	The likely first three problems	~1 min
License + Author	Meta	MIT	—

Related MCP server: Design System MCP Server

What this is

Refero Styles is a beta catalog of about 200 curated sites where someone has done the painful work of pulling out the colors, typography, spacing, and per-style do/don't guidance. Each entry ships with a designSystem block that's basically a DESIGN.md waiting to happen.

This MCP wraps that catalog so Claude Code can search it in natural language and drop a generated DESIGN.md straight into whatever project you're scaffolding. No browser-tab JSON copy-paste, no hand-rolled token tables.

It's for anyone using Claude Code to spin up a new app, deck, or client project who wants the design language locked down before the first component renders.

Quick install

One line:

claude mcp add refero -- npx -y fidgetcoding-refero-mcp

Restart Claude Code and start describing the look you want.

If you want vibe search (semantic ranking against each style's poetic northStar summary), pass an OpenAI key:

claude mcp add refero --env OPENAI_API_KEY=sk-... -- npx -y fidgetcoding-refero-mcp

Without it, search falls back to keyword scoring. Works fine, just less magical.

For claude_desktop_config.json users:

{
  "mcpServers": {
    "refero": {
      "command": "npx",
      "args": ["-y", "fidgetcoding-refero-mcp"],
      "env": {
        "OPENAI_API_KEY": "sk-...",
        "REFERO_MCP_VAULT_DIR": "/absolute/path/to/your/vault"
      }
    }
  }
}

Usage

IMPORTANT

You talk. Claude dispatches. No commands, no syntax, no JSON.

Every tool here is wired to plain-English prompts. You don't memorize tool names or build payloads — Claude picks the tool and fills in the parameters.

A few prompts that route cleanly:

"Find me a dark editorial style with a serif and a warm accent."

"Pull the full breakdown for Linear."

"What's similar to Vercel in the Refero catalog?"

"Render Cursor's DESIGN.md — don't save it yet, just show me."

"Save Cursor's DESIGN.md into my ACME project."

"Show me only dark-mode brutalist styles, top five."

"Refresh the Refero catalog before we start the design pass."

More worked recipes in docs/USAGE.md.

Tools

Tool	What it does
`refero_search`	Natural-language vibe search across the catalog. Embeddings if `OPENAI_API_KEY` is set, BM25-lite fallback if not.
`refero_get`	Fetch the full design system for one style. Accepts a uuid, hostname (e.g. `cursor.com`), or site name (e.g. `"Cursor"`).
`refero_similar`	Refero's own "similar styles" ranking for a given style. Free recommendations from the upstream.
`refero_list`	Browse the local catalog mirror with optional theme/tag filters. Stably ordered.
`refero_facets`	What's actually in the catalog — ranked font stacks, color names, theme counts. Call it before guessing search terms: there is no tag taxonomy, so invented tags match nothing, but every value this returns is already in the search index and can be passed straight to `refero_search`.
`refero_design_md`	Render a style as an agent-friendly DESIGN.md (frontmatter, north star, color table, dos/donts). Optionally writes to disk.
`refero_refresh`	Force a full re-fetch of the catalog and overwrite the local mirror. Skips the 24h TTL.

Configuration

Everything is optional. Defaults are picked so the MCP just runs.

Variable	Required	Default	What it does
`OPENAI_API_KEY`	No	unset	Enables vibe search via `text-embedding-3-small`. Without it, search falls back to keyword scoring.
`REFERO_API_BASE`	No	`https://styles.refero.design`	Override if Refero ever moves the API or you're pointing at a fixture.
`REFERO_CACHE_DIR`	No	`~/.refero-cache`	Where the local catalog mirror, embeddings, and detail cache live.
`REFERO_CACHE_TTL_MS`	No	`86400000` (24h)	How long a cached page is considered fresh.
`REFERO_MCP_VAULT_DIR`	No (required for project writes)	unset	Absolute path to the vault root that `refero_design_md` writes into. If unset, the tool returns the markdown but doesn't write to disk.

A copy-paste .env.example ships in the repo root.

There's no default for REFERO_MCP_VAULT_DIR. The previous draft hardcoded my laptop path, which worked great for exactly one machine on Earth. The reviewer caught it. Now if you don't set it, the tool just refuses to write — rude, but better than dropping files into a folder that doesn't exist on your computer.

How it works

There is no public Refero API doc as of writing — the shape was mapped empirically against the live site. The full breakdown is in docs/api-surface.md so future-me doesn't re-discover it.

Local catalog mirror. Refero exposes ?page=N pagination but silently ignores ?search=, ?q=, and ?colorScheme=. So this MCP walks the pages once, mirrors them locally under REFERO_CACHE_DIR, and runs all filtering and ranking client-side.
Vibe search via northStar. Every Refero style ships with a one-line poetic summary called northStar. With OPENAI_API_KEY set, the MCP embeds those summaries with text-embedding-3-small and ranks by cosine similarity to your query. Without a key, it falls back to keyword scoring on northStar + tags + site name.
DESIGN.md generated locally. Refero does not expose a /design.md endpoint. The MCP synthesizes one from style.fullResult.designSystem (dos, donts, tags, theme, role-tagged colors). Output is compatible with the /stitch-design-taste and /design-taste-frontend skills.

Troubleshooting

"No styles found" / catalog feels empty. First-run hits a cold cache. Ask Claude to "refresh the Refero catalog" once — it walks the ~10 pages with a polite 250ms gap and writes them to REFERO_CACHE_DIR. After that, search is instant.

Search results feel keyword-y rather than semantic. You probably don't have OPENAI_API_KEY set. Add it to your MCP config and restart, or lean harder on the catalog's vocabulary (industries plus tags like editorial, brutalist, glass).

refero_design_md returns markdown but won't write to disk. REFERO_MCP_VAULT_DIR is unset. Set it to your vault root (absolute path) and the tool will write to <vault>/05-Projects/<NAME>/DESIGN.md. Without it, you get the markdown back in conversation and can paste it wherever.

License

MIT — see LICENSE for details.

Author

Built by Nate Davidovich / Lorecraft LLC.

GitHub: lorecraft-io
npm: lorecraft
Sister projects: morgen-mcp, motion-mcp

⤴ back to top

Security: gitleaks scan

This repo ships with a .gitleaks.toml config and a scripts/security-scan.sh helper that scans the working tree for secrets (GitHub tokens, API keys, JWTs, private keys, Anthropic keys, etc.).

bash scripts/security-scan.sh

A .husky/pre-commit hook also runs gitleaks protect --staged on every commit and warn-no-ops if gitleaks isn't installed locally.

If you don't have it yet:

macOS: brew install gitleaks
Linux: https://github.com/gitleaks/gitleaks/releases

Available Tools

6 tools

refero_design_mdA

Render a Refero style as an agent-friendly DESIGN.md (frontmatter, north star, color table, fonts, dos/donts, tags). When save_to_project is set, writes the file to /05-Projects//DESIGN.md.

ParametersJSON Schema

Name	Required	Description	Default
`identifier`	Yes	uuid, hostname/URL, or site name to render.
`save_to_project`	No	Vault project folder name (e.g. "PARZVL"). Sanitized; must be [A-Za-z0-9_.-].

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses the side effect of writing a file when save_to_project is set and specifies the file path. However, it does not detail overwrite behavior, error handling, or permission requirements, leaving some behavioral ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: first states purpose and content, second adds conditional behavior. No superfluous information, efficiently communicates core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with two parameters and no output schema, the description explains the main action and optional save. It could mention that it generates a document without modifying the original style, but overall it is sufficient for an agent to understand what the tool does.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already has 100% coverage with clear descriptions. The tool description adds context by explaining the file path construction from save_to_project, going beyond the schema. Good addition but not essential.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool renders a Refero style as a DESIGN.md file with specified contents (frontmatter, north star, etc.) and optionally writes it to a project folder. This distinguishes it from sibling tools that retrieve, list, or search styles.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the tool does but lacks explicit guidance on when to use it over alternatives like refero_get or refero_search. No when/ when-not or comparison to siblings is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

refero_getA

Fetch the full design system for a single style. Accepts a uuid, a hostname/URL (e.g. cursor.com), or a site name (e.g. "Cursor"). Fuzzy-matches site names within Levenshtein distance 2.

ParametersJSON Schema

Name	Required	Description	Default
`identifier`	Yes	uuid, hostname/URL, or site name.

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses fuzzy matching behavior and acceptable input types. It does not explicitly state the tool is read-only or describe failure modes (e.g., no match found), but the intention is clear and no contradictions exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no redundancy, front-loaded with the primary action. Every word adds value—first sentence states purpose, second sentence details input flexibility and matching algorithm.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description could mention what the tool returns (e.g., JSON object of the design system), but for a simple fetch operation, the description is sufficiently complete. The context of sibling tools helps, and the tool is straightforward.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already describes the 'identifier' parameter as 'uuid, hostname/URL, or site name' (100% coverage). The description adds value by explaining fuzzy matching (Levenshtein distance 2) and giving an example, which goes beyond the schema's basic description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fetches "the full design system for a single style," specifying the verb 'Fetch' and the resource 'full design system for a single style'. It distinguishes itself from sibling tools like refero_list (list all), refero_search (search), and refero_similar (find similar), which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly lists acceptable input formats (uuid, hostname/URL, site name) and provides an example ("Cursor"). It also mentions fuzzy matching with Levenshtein distance 2, giving clear guidance on how the identifier will be resolved, which helps the agent choose correct inputs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

refero_listA

Browse the local catalog mirror with optional theme/tag filters. Returns paginated, stably-ordered results (newest first, then site name).

ParametersJSON Schema

Name	Required	Description
`theme`	No	Filter to light- or dark-themed sites only.
`tags`	No	Filter by tag terms (matched against siteName + northStar in the catalog projection).
`page`	No	1-indexed page number (default 1).
`limit`	No	Items per page (default 20, max 50).

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must cover behavior. It mentions read-like operation ('browse') and stable ordering, but does not disclose caching, rate limits, or whether the mirror is synced. Adequate but minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words. Purpose and key details are front-loaded, making it easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers pagination, ordering, and filters. No output schema exists, but description could mention return structure. Still, given the tool's simplicity and thorough schema descriptions, it is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema already describes all 4 parameters with 100% coverage. Description adds no additional meaning beyond restating 'optional theme/tag filters' and pagination. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool browses a catalog mirror with optional filters and pagination. Verb 'browse' and resource 'local catalog mirror' are specific, and the ordering detail distinguishes it from sibling tools like refero_search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage for browsing/filtering the catalog, but does not explicitly compare with alternatives (e.g., refero_search for full-text search, refero_similar for similar sites). No guidance on when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

refero_refreshA

Force a full re-fetch of the styles.refero.design catalog and overwrite the local mirror. Useful after the catalog has changed and you don't want to wait for the 24h TTL.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses destructive behavior (overwrite local mirror) but lacks details on authorization, side effects, rate limits, or synchronous/asynchronous nature. No annotations to supplement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two efficient sentences: first states action, second provides use case. No fluff, perfectly front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and no output schema, description adequately explains purpose and when to use. Lacks mention of return value or sync/async but sufficient for a simple refresh.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has zero parameters, so description doesn't need to document any. Schema coverage is 100%. Baseline 4 for no parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the action: force full re-fetch and overwrite local mirror. Specifies the resource (styles.refero.design catalog) and implies the verb 'refresh'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use: after catalog changes and wanting to avoid 24h TTL. Implies alternative is waiting or using other tools like refero_get for normal reads.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

refero_searchA

Natural-language search over the styles.refero.design catalog. Returns the top matches scored by an embedding model (when OPENAI_API_KEY is set) or a BM25-lite keyword fallback. The local catalog is mirrored on first call and refreshed automatically every 24 hours.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Natural-language vibe query, e.g. "playful neobrutalist saas".
`theme`	No	Filter to light- or dark-themed sites only.
`tags`	No	Filter to styles whose tags / name / northStar mention any of these terms.
`limit`	No	How many results to return (default 10, max 50).

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but the description discloses the search mechanism (embedding or BM25 fallback), caching behavior (mirrored on first call), and refresh policy (every 24 hours). This explains backend behavior adequately for a read-only search tool, though no side effects are mentioned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences covering purpose, algorithm, and caching. No redundant information; all sentences earn their place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description does not specify the structure of returned results (e.g., fields like name, tags, thumbnail). Also lacks details on how tag filtering interacts with the search. Adequate but has gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear parameter descriptions. The description does not repeat parameter details but adds context about the search algorithm, which is separate from parameter definitions. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly identifies the tool as a natural-language search over a specific catalog (styles.refero.design). It distinguishes from siblings like refero_list (listing) and refero_similar (similarity search) by emphasizing vibe-based search. The mention of embedding vs BM25 fallback adds specificity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies use for natural-language queries but does not explicitly state when to avoid this tool or prefer siblings. No direct comparison with sibling tools, leaving the agent to infer context from names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

refero_similarA

Refero's own "similar styles" recommendation list for a given style. Useful for follow-up exploration once you've found a candidate via refero_search.

ParametersJSON Schema

Name	Required	Description	Default
`identifier`	Yes	uuid, hostname/URL, or site name.
`limit`	No	How many similar styles to return (default 10, max 20).

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description does not disclose read-only nature, required permissions, or any side effects. Minimal behavioral info beyond purpose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no fluff. First sentence states purpose, second gives usage context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema; description does not hint at return format or pagination. However, tool is simple with good sibling context, so adequate but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers both parameters with descriptions; description adds no extra meaning. Baseline 3 due to 100% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'recommendation list for a given style' and distinguishes from siblings by referencing refero_search as a precursor.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Useful for follow-up exploration once you've found a candidate via refero_search', which tells when to use it. Does not explicitly exclude alternatives, but context is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.1.0May 15, 2026
- First observedrefero_design_md
- First observedrefero_get
- First observedrefero_list
- First observedrefero_refresh
- First observedrefero_search
- First observedrefero_similar

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: fetching details, browsing, searching, refreshing, getting recommendations, and generating design docs. No overlap in functionality.

Naming Consistency4/5

All tools share the 'refero_' prefix and use lowercase with underscores, but the suffixes vary between verbs (get, list, refresh, search) and non-verbs (similar, design_md), causing slight inconsistency.

Tool Count5/5

6 tools is well-scoped for interacting with a design system catalog, covering key operations without being too few or too many.

Completeness4/5

The tool set covers browsing, searching, fetching details, getting recommendations, refreshing the catalog, and generating documentation. Minor gaps like filtering by popularity are absent but core workflows are complete.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

SupernovaOAuth
io.supernova
Access and maintain design system docs, tokens, components, skills, and contexts across any project.
Design Tools Documentation Access Developer Tools
1
Tseha AFeatured
io.tseha
Serves your design system and coding standards to coding agents, so they stop guessing.
Developer Tools Documentation Access
93
llmref A
org.llmref
Versioned documentation registry and semantic search for AI tools and coding assistants.
Documentation Access Search Developer Tools
42
ComponecatOAuth
com.shaftware
Software component catalog: search your org's services, docs, APIs, dependencies, and ownership.
Developer Tools Code Analysis Documentation Access
11

Related MCP Servers

knowledgebased
RAG Systems Knowledge & Memory
devkanro
A
license
A
quality
D
maintenance
Provides semantic search and a tag-based knowledge graph for any project, auto-discovering local markdown knowledge bases with YAML frontmatter.
Updated 4 months ago (2026-04-27 07:02 UTC)
10
14
MIT
Design System MCP Server
Design Tools Developer Tools
Thaynah
A
license
Not graded
quality
D
maintenance
Provides resources, tools, and prompts for a Design System via MCP protocol, enabling component search, reading, and related component discovery.
Updated 10 months ago (2025-10-24 20:06 UTC)
225
MIT
mcp-library-docs
Developer Tools Documentation Access
roznet
A
license
Not graded
quality
D
maintenance
Provides AI assistants with access to design documentation across multiple code libraries, enabling discovery of existing utilities and patterns to avoid reimplementation.
Updated 6 months ago (2026-02-27 13:29 UTC)
2
MIT
Documentation MCP
Documentation Access Code Analysis Software Architecture
syamai
A
license
Not graded
quality
D
maintenance
Analyzes codebases to automatically generate README, API docs, architecture diagrams, and CHANGELOG.
Updated 8 months ago (2026-01-12 17:22 UTC)
16
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/fidgetcoding/refero-design-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Refero MCP

Quick Navigation

What this is

Quick install

Usage

Tools

Configuration

How it works

Troubleshooting

License

Author

Security: gitleaks scan

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API