This server is a read-only MCP tool that lets AI coding agents discover, explore, and install React components from the encode-ui registry (352 components). It provides:
Search: find components by name, alias, natural language, or keywords, with filters for group, type, motion, and dependency‑free status; multiple search engines (web, catalog, db) are available.
Metadata: retrieve detailed component info (description, group, categories, dependencies, license, byte sizes, install command) without fetching code.
Source code: fetch full TSX source (all shipped files) or demo usage examples.
Similar components: discover related components based on shared groups, categories, or composition.
Registry browsing: list groups with component counts and enumerate all components in a group (optional dependency‑free filter).
Install command: generate a single npx shadcn@latest add command for one or more components.
Icons: search, verify, resolve legacy aliases for Lucide icon names, and browse by category.
Guidance: access long‑form prompts (use-registry, setup-project) for workflow and project setup.
Token support: optional ENCODE_UI_TOKEN for gated components.
Provides verified Lucide icon name lookup, including concept search, category browsing, and legacy alias resolution, so agents can reference correct lucide-react imports.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@encode-ui search for a responsive navbar component"
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.
Component lookup over the encode-ui registry — 389 shadcn
registry items (336 components + 53 OKLCH palettes), served to AI coding agents over MCP. Your agent searches the catalog, reads any
component's source, and hands back the exact npx shadcn@latest add command.
It also validates a brand theme of your own: validate_theme runs the WCAG-AA clamp and
the uniqueness math the registry's 48 themes each passed, and hands back paste-ready CSS
variables.
Read-only by design. This server tells an agent what to install; installing stays on your own shadcn path, and nothing here touches your project.
One stdio command. npx fetches it on first run — nothing to install or keep current:
npx -y encode-uiZero flags gives you the zero-setup web engine: it fetches the catalog from the deployed registry at startup, caches it, and falls back to a bundled copy, so startup never fails offline. Only three runtime dependencies are required — the native stack behind the semantic engine is optional, so a machine that can't build it still installs and still runs.
The -- is required; without it claude reads the server's flags as its own.
claude mcp add encode-ui -- npx -y encode-uiVerify with claude mcp list (→ ✔ Connected) or /mcp in a session.
Or install the plugin instead, which brings the server plus a brand-theme designer — see Plugin below. Pick one: the plugin registers the server itself, so doing both runs it twice.
The same JSON block works anywhere that speaks stdio MCP — Claude Desktop's
Settings → Developer → Edit Config, or ~/.gemini/settings.json:
{
"mcpServers": {
"encode-ui": {
"command": "npx",
"args": ["-y", "encode-ui"]
}
}
}Prefer this form when passing flags: they arrive as discrete args that no wrapper can
reinterpret. Restart the host completely after editing. If the server never appears in a
GUI-launched app, it likely didn't inherit your shell's PATH — use an absolute npx path.
ChatGPT is not supported: its connectors accept only remote HTTPS MCP servers, and this one is stdio.
A few items need an account. Sign in at encode-ui.com, copy the
token from any gated item's Install tab, and put it in the registration's env block —
not on the command line, where ps can read it:
{ "env": { "ENCODE_UI_TOKEN": "eyJ…" } }Everything else works without it.
Related MCP server: @jpisnice/shadcn-ui-mcp-server
Tool | What it does |
| Component search — natural language or names |
| Metadata for one component, plus the byte size of its source and demo |
| The full TSX source, or the demo |
| Related components |
| The taxonomy with per-group counts |
| Full membership of one group — the enumeration search can't be |
| One |
| Verified lucide icon names — by concept, or to check a spelling ( |
| Your own brand theme, checked: AA clamp, per-pair contrast, distance from 48 palettes, plus paste-ready |
Every search and list hit carries pure: true when the item's whole install tree adds no
npm packages beyond the shadcn substrate you already have. search_components and
list_components take a dependencyFree filter.
Two behaviours worth knowing. Search is not an oracle of absence — for "does the registry
have X?" or "list everything in Y", enumerate with list_groups then list_components and
judge the descriptions. And a misspelt name is an error, not an empty result: it comes
back carrying the closest matches, so the agent self-corrects in one turn.
Two slash commands carry the long-form guidance, at zero token cost until invoked:
Prompt | Slash form |
|
|
|
|
use-registry is the recurring workflow (discover → assess → install → customize);
setup-project is the one-time consumer init — the components.json namespace, the OKLCH
token contract, tw-animate-css, and a smoke test.
Claude Code only. The plugin bundles this server together with a
brand-theme-designer agent, the two skills it drives, a slash-command shortcut that
dispatches it, slash forms of the server's two prompts, and a typed command for every
tool — so one install gives you both component lookup and a way to brand your app, all
under the /encode-ui:* umbrella:
/plugin marketplace add reuvenaor/encode-ui
/plugin install encode-ui@encode-ui-theme-genWhat you get | How you reach it |
the MCP server | registered automatically — see the caveat below |
| the shortcut: hand it a brief, it runs the agent end to end |
| designs a full brand from a brief, validates it, writes your CSS, and leaves a brand guide |
| the method: personality tuple, OKLCH role mapping, dark re-derivation, shadow knobs, uniqueness floors |
| where the tokens go in a stock |
| the component workflow — the |
| one-time consumer setup — the |
the nine tools, typed | one command per tool: |
Skills and commands are slash commands; agents are not. The agent is reached by the
shortcut above, by @agent-encode-ui:brand-theme-designer, or by just describing what
you want — there is no / form for an agent in Claude Code. The two prompt wrappers
mirror src/mcp/prompts.ts verbatim, and the command set tracks
the tool surface one-to-one; test/plugin-naming.test.ts goes red if either drifts.
Caveat — do not do both. The plugin registers the server itself. If you already ran
claude mcp add encode-ui, remove it first (claude mcp remove encode-ui), or the server
runs twice and its tools appear under two names (bare, and
mcp__plugin_encode-ui_registry__*). Under the plugin the server shows in /mcp as
plugin:encode-ui:registry, so it sorts under p — it is renamed, not missing.
Not on Claude Code? Plugins are a Claude Code format, but the pieces are not locked to
it. validate_theme is a plain MCP tool that works in any host. And the skills are
plain Agent Skills folders — copy
plugin/skills/brand-design and plugin/skills/theme-tokens into wherever your tool
reads skills from (Cursor, Codex, Copilot and others support the format). The agent
definition and its dispatcher skill are the Claude-Code-specific pieces.
--registry-engine <web|catalog|db> picks how search works. The default is fine for most
people; the other two trade setup for better ranking.
web (default) — no model, no index. Fetches the catalog from the registry, and source
bodies per call. Its search is a plain filter over names, aliases and keywords, so
behaviour-style discovery works best by reading the encode-ui://catalog resource once
and letting the model judge the descriptions.
catalog — offline lexical ranking over the bundled index. Ranking never touches the network; source bodies still come from the origin (or a registry checkout, if one surrounds the package).
db — hybrid semantic + lexical retrieval over each component's description, full
source, and demo. The strongest for vague, behaviour-style queries. Served from the
index.db shipped in the package; the first query downloads ~1.2 GB of ONNX weights once
per machine (--lexical-only skips the model entirely).
Every install-time property is a flag; --help prints this to stderr. The only
configuration environment variable is ENCODE_UI_TOKEN.
Flag | Engine | Effect |
| — | Which engine serves the tools. Unset = |
| db | Path to |
| web, catalog | Origin bodies are fetched from. Default |
| catalog | Registry checkout to read source bodies from. |
| db | Where ONNX weights are cached. Default |
| db | Skip the model; FTS5-only. Results flagged |
| — | Print usage / version to stderr and exit. |
A flag the selected engine would ignore is a usage error (exit 2), same as a malformed
value — the server never warn-and-ignores something you typed deliberately. Path flags
expand ~ and resolve relative values against the server's cwd.
Rebuilding the index means restarting every running server. The build replaces
index.db with a new file, while the server opens it once and holds the handle — so a
long-lived server keeps serving the deleted snapshot, silently. After a rebuild, reconnect
and check that the startup banner's item count matches.
Icons are data, not components. The registry ships no icon components; find_icons
answers from vendored lucide metadata at the exact tag the registry pins for
lucide-react. Ask it rather than guessing an import.
MIT, Copyright (c) 2026 Reuven Naor — see LICENSE. This package ships a prebuilt
index carrying component source, some of it adapted from other MIT-licensed projects; their
notices travel with it in NOTICE.md. The bundled agent-index.json is generated
from the registry, so regenerating it is a maintainer task rather than something a clone can
reproduce.
Questions, licensing or otherwise: info@reuvenaor.com.
Verified lucide-react icon names — never guess an icon import. Two modes (at least one of query/names/category is required): query searches names, curated tags, and categories by what the icon should depict ("shopping cart", "danger warning"); names verifies exact spellings and resolves legacy aliases (Home → House, with the deprecation flagged). category filters or browses. Hits carry the canonical name, the import identifier, and tag/category context; the registry itself ships no icon components — lucide-react 0.511.0 is the icon layer, auto-installed with any icon-using item.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many results to return. | |
| names | No | Exact names to VERIFY — kebab (house), PascalCase (House), an Icon suffix (HouseIcon), or a legacy alias (Home). Wins over query/category. | |
| query | No | What the icon should depict, e.g. "shopping cart" or "warning about danger". | |
| category | No | Restrict to one lucide category (e.g. navigation). Alone = browse it. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| icons | Yes | |
| usage | Yes | |
| install | Yes | |
| unknown | Yes | |
| lucideVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses alias resolution with deprecation flags, the output fields (canonical name, import identifier, tag/category context), and the registry's role (no icon components; lucide-react is the icon layer). This adds substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two dense sentences with no filler. It front-loads the core promise, then covers modes, output, and dependency information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only lookup tool, the description covers required mode constraints, output characteristics, alias behavior, and ecosystem context (lucide-react version). No important information appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all parameters thoroughly (100% coverage). The description adds value by clarifying how the modes interact (at least one required, names wins over query/category) and what query searches (name, tags, categories).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds or verifies lucide-react icon names, with specific modes (query, names, category). The title and description align, and the focus on icon names distinguishes it from sibling tools like search_components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the value proposition 'never guess an icon import' and the description of three modes. However, it does not explicitly state when to use this tool over the sibling tools or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Components related to a given one — same group, shared categories, and composition edges, computed from the fetched registry index. Useful for "what else is like this" and for finding variants. score is a structural heuristic (scoreKind "lexical"), comparable only within one result set; these are not embedding-space neighbours.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | How many results to return. | |
| name | Yes | Component to find neighbours of. |
| Name | Required | Description |
|---|---|---|
| seed | Yes | |
| count | Yes | |
| engine | Yes | |
| neighbours | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, so the description doesn't need to restate that. It adds useful behavioral context: results are computed from the fetched registry index, and the score is a structural heuristic comparable only within one result set. These details prevent misuse and set expectations beyond what the schema or annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tightly written sentences, front-loaded with the core purpose and followed by use cases and a caveat. Every sentence adds value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With simple parameters, existing annotations, and an output schema, the description provides enough context: it explains the basis of relatedness, the nature of the score, and when to use the tool. The only minor gap is that it doesn't mention whether the registry index needs to be pre-fetched, but this is a small omission for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (name and k) have clear descriptions in the schema, so the baseline is 3. The description doesn't add per-parameter semantics, but given the 100% schema coverage, it is not necessary for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it finds components related to a given one via same group, shared categories, and composition edges. It also frames specific use cases ('what else is like this', finding variants), which distinguishes it from siblings like search_components or get_component.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool (finding related components and variants) and adds a caveat that scores are structural heuristics, not embedding similarities. However, it does not explicitly name alternatives or state when not to use this tool, so it lacks explicit exclusions but provides sufficient situational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Metadata for one component by name: description, group, dependencies, provenance/license, and the install command. Reports the byte size of the source and demo without sending them — fetch those from get_component_source once you know what they cost.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Component slug, e.g. magnetic-button. A leading scope prefix is accepted and ignored. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| type | Yes | |
| gated | Yes | |
| group | Yes | |
| setup | Yes | |
| title | Yes | |
| docUrl | Yes | |
| motion | Yes | |
| license | Yes | |
| filePath | Yes | |
| demoBytes | Yes | |
| pureReact | Yes | |
| sourceUrl | Yes | |
| categories | Yes | |
| installCmd | Yes | |
| provenance | Yes | |
| description | Yes | |
| sourceBytes | Yes | |
| dependencies | Yes | |
| partsFilePath | Yes | |
| qualifiedName | Yes | |
| registryDependencies | Yes | |
| transitiveDependencies | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses that it reports byte size without sending source/demo content, clarifying a potentially surprising behavior. It also lists the metadata fields returned. This adds useful context about what the tool does and doesn't do.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, first front-loads the core purpose and deliverables, second adds behavioral detail and points to a sibling. No redundancy; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single parameter, an output schema, and readOnly annotation, the description is complete. It covers what the tool returns, notes the size-only behavior, and directs users to the source-fetching sibling, leaving no important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the 'name' parameter. The description only reinforces 'by name' without adding new semantics, aligning with the baseline for complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Metadata for one component by name' and enumerates specific fields returned (description, group, dependencies, provenance/license, install command). It distinguishes itself from siblings like get_component_source by noting it reports byte size without sending the source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use get_component_source for actual source: 'fetch those from get_component_source once you know what they cost.' This gives clear when-to-use guidance. However, it doesn't explicitly contrast with search_components or list_components for finding components, though 'by name' implies exact lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every TSX file one component ships, or its demo usage example, in fenced code blocks. A multi-file component returns ALL of its files — the public module plus every sibling it imports (.parts.tsx pairs, block modules) — because the entry file alone does not compile. Check sourceBytes/demoBytes on get_component first if size matters. Returns code as text rather than a JSON field, so it stays readable.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Component slug, e.g. magnetic-button. A leading scope prefix is accepted and ignored. | |
| part | No | Which payload: the component source, or its demo usage example. | source |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say read-only/open-world. The description adds valuable behavioral details: output is fenced code blocks, multi-file components return ALL sibling files, and it returns text rather than JSON for readability. This goes beyond the annotations and sets correct expectations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: what is returned, why multi-file works, and a caution about size plus output format. No wasted words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description sufficiently explains the return format (fenced code blocks, text) and the notable multi-file behavior. The size check tip provides operational context. It could mention error handling or whether file paths are included, but for a simple read operation it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters with 100% description coverage (name as slug, part enum with source/demo). The description only loosely references the demo payload and doesn't add parameter-specific semantics beyond what the schema provides, so it stays at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title 'Get a component's source' and description make clear that this tool returns the TSX source files for a component or its demo example. It also distinguishes itself from sibling get_component by referencing sourceBytes/demoBytes and noting it returns actual code as fenced blocks, not a JSON field.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives actionable guidance: 'Check sourceBytes/demoBytes on get_component first if size matters' explicitly directs when to use the alternative tool. It also explains why multi-file components return all files (entry alone won't compile), implying a use case for full source retrieval. However, it doesn't explicitly state when NOT to use this tool beyond the size consideration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One npx shadcn@latest add command installing all the named components at once. Duplicates collapse; names with no such component come back under unknown.
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes | Component names to install. |
| Name | Required | Description |
|---|---|---|
| command | Yes | |
| unknown | Yes | |
| components | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavior beyond the annotations: duplicates are collapsed and unknown names are returned under 'unknown'. Since readOnlyHint and openWorldHint are already provided, this disclosure of edge-case handling is strong and non-contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and no filler. Every word contributes to understanding the tool's behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the presence of an output schema, and read-only annotations, the description covers all essential aspects: purpose, bulk behavior, duplicate handling, and unknown-name handling. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% coverage with descriptions for the 'names' parameter and its items. The description adds meaning by explaining how the parameter values are processed (duplicates collapse, unknown names grouped), which goes beyond raw schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool produces a single `npx shadcn@latest add` command for the named components. This specific verb+resource combination distinguishes it from sibling tools like search_components or get_component.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys clear context: use this when you want a bulk install command for specific component names. It does not explicitly name alternatives or exclusions, but the purpose is unambiguous in the context of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every component in one group — full membership, not a ranked sample. Search always returns its top k, so "list ALL X" and "does the registry have X?" need this instead: enumerate, then judge the descriptions yourself. Returns name, title, and description per item; get_component has the details.
| Name | Required | Description | Default |
|---|---|---|---|
| group | Yes | Group slug to enumerate, e.g. forms. Call list_groups for the taxonomy. | |
| dependencyFree | No | true = only pure React + Tailwind members; false = only dep-carrying ones. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| group | Yes | |
| engine | Yes | |
| components | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true, so the read-only nature is already known. The description adds valuable behavioral context: it returns full membership (not a sample), includes name/title/description per item, and notes that get_component holds detailed data. This goes beyond annotation declarations without overclaiming.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, with the core purpose front-loaded in the first sentence. Each subsequent sentence adds distinct value—usage guidance and output summary—without fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required param, two total), the description covers what it does, when to use it, and what it returns. The output schema and parameter descriptions fill remaining gaps, so the overall context is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are fully documented in the schema (group slug and dependencyFree filter). The description does not add new parameter-level semantics beyond the schema's own explanations, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enumerates every component in a group, specifying 'full membership, not a ranked sample.' It also distinguishes itself from search_components by explicitly contrasting with search's top-k results, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool over alternatives: 'Search always returns its top k, so "list ALL X" and "does the registry have X?" need this instead.' It also points to get_component for details, giving clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The registry taxonomy with a component count per group. Use a slug from here as the group filter on search_components, or enumerate a group in full with list_components.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| engine | Yes | |
| groups | Yes | |
| totalItems | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and closed-world semantics. The description adds useful context about the output structure (taxonomy with counts) and how it relates to sibling tools, without contradicting the annotations. It slightly exceeds minimal additions by explaining the semantic content of the result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. Every clause adds value: the first describes the output, the second directs the user to related tools. The structure is clean and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with no parameters and an output schema, so the description's coverage of the tool's purpose and usage is sufficient for an agent to select and invoke it correctly. The relationship to sibling tools is clearly articulated, covering all necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; the schema is empty with 100% coverage. The description doesn't need to explain parameters, and the baseline for zero-param tools is 4. The description adds no param-specific info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as listing the registry taxonomy with per-group component counts, and explicitly distinguishes it from list_components and search_components by explaining how the output is used. The specific resource (registry taxonomy) and scope (component count per group) are stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: to get a slug for filtering search_components or to identify a group to enumerate with list_components. This provides clear alternatives and usage context, going beyond mere statement of purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find React components in the encode-ui registry by name, alias, or keyword. Web engine: a plain substring filter over the index fetched from the deployed registry (name, aliases, curated keywords, title, description) — exact names and aliases ("modal", "toast") work best; loose behaviour phrasing may miss. Terms split on punctuation and single characters are dropped, so "toast?" and "a dialog." behave like the bare words. For discovery and planning, read the catalog resource encode-ui://catalog (≈20k tokens) once and judge the descriptions yourself. Every hit carries the exact install command. score is rank-derived (scoreKind "lexical"), comparable only within one result set, and cosine is always null — no score here is calibrated. A filter cannot prove absence: for "find ALL X" or "does the registry have X?" use list_groups + list_components and judge the descriptions yourself.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | How many results to return. | |
| type | No | Restrict to a registry type: registry:ui, registry:hook, registry:lib. | |
| group | No | Restrict to a group slug, e.g. buttons, forms, charts, overlays. | |
| query | Yes | What the component should do, in natural language. | |
| motion | No | Only animated (true) or only static (false) components. | |
| dependencyFree | No | true = only items whose whole install tree adds zero npm packages (pure React + Tailwind); false = only dep-carrying items. |
| Name | Required | Description |
|---|---|---|
| hits | Yes | |
| count | Yes | |
| query | Yes | |
| engine | Yes | |
| degraded | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=true, openWorldHint=false), the description reveals key behavioral traits: it's a 'plain substring filter' over an index, drops single characters and splits on punctuation, and clarifies that 'score' is rank-derived and not calibrated while 'cosine' is always null. This adds significant context about matching limitations and output semantics, fully earning a high score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average, but every sentence serves a purpose: purpose, engine mechanics, query quirks, alternative discovery method, install-command note, and absence limitation. It is front-loaded with the core purpose and then expands logically. However, some phrasing could be tightened (e.g., the 'Web engine' sentence packs many ideas), so it's not maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, output schema, multiple siblings), the description is remarkably complete. It covers what the tool does, how it works, its limitations, when to use alternatives, and even advises reading a catalog resource for better judgment. The output schema exists, so no need to detail return values; the description handles all critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining behavior of the query parameter: 'Terms split on punctuation and single characters are dropped, so "toast?" and "a dialog." behave like the bare words.' It also notes that 'exact names and aliases... work best,' which directly aids parameter usage. Other parameters are already well-described in the schema, so the description provides a modest but valuable increment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource+scope: 'Find React components in the encode-ui registry by name, alias, or keyword.' This clearly distinguishes it from siblings like list_components (which lists everything) and get_component (which fetches a single component). The mention of alternatives in the latter half further reinforces differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs. alternatives: 'For discovery and planning, read the catalog resource... once and judge the descriptions yourself' and 'A filter cannot prove absence: for "find ALL X" or "does the registry have X?" use list_groups + list_components.' It also warns about exact-name matching versus loose behavior phrasing, giving clear context for effective use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.4.0find_iconsfind_similarget_componentget_component_sourceget_install_commandlist_componentslist_groupssearch_componentsEach tool has a clearly distinct purpose: searching, finding similar, fetching metadata, fetching source, listing groups, listing components, getting install commands, and finding icons. The descriptions explicitly clarify differences (e.g., search_components vs list_components), so there is no ambiguity.
Most tools follow a verb_noun pattern (search_components, get_component, list_groups, list_components, find_icons). Minor deviations include find_similar (verb + adjective) and compound nouns like get_component_source and get_install_command, but these are still readable and predictable.
With 8 tools, the set is well-scoped for a component registry server. Each tool covers a distinct aspect of discovery and installation without redundancy, fitting the typical 3-15 tool sweet spot.
The tool surface covers the full read/install workflow: searching, browsing by group, enumerating, getting metadata, getting source, getting install commands, and verifying icons. No obvious gaps exist for the server's stated purpose of exploring and installing components.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
Search, vet & assemble MCP servers from your agent: verified tools, risk labels, and trust scores.
AI agent registry — search, discover, register, and connect agents via MCP.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/reuvenaor/encode-ui'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
