This MCP server enables AI coding assistants to accurately understand and work with private, in-house component libraries by providing structured metadata via AST-level static analysis.
Confirmed available tools:
search_components — Scan a local directory for .vue component files, with an optional keyword filter to narrow results by file name.
get_component_detail — Parse a specific .vue component file to extract structured metadata including Props (names, types, defaults, required fields), Events (emitted event names and payloads), Slots, comments, and imports.
Additional tools described in the README (may not be exposed in all versions of the server schema):
Find component usages across the project (auto-import aware).
Search & get store detail — supports Pinia, Vuex, Zustand, Redux Toolkit, Jotai; extracts state, getters, and actions.
Search & get composable/hook detail — full signatures with param types, defaults, return fields, and JSDoc.
Analyze page — recursively resolve all component dependencies of a page file (component tree).
Search & get type detail — extract interface, type alias, and enum definitions with member types, optionality, and JSDoc.
Query AST — high-performance, language-aware AST pattern matching across .vue, JSX/TSX, HTML, and JS/TS files.
Both confirmed tools support alias paths.
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., "@local-component-mcp search for table components in D:/projects/my-app/src"
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.
An MCP Server that gives AI coding assistants accurate knowledge of your private, in-house component libraries.
When you use Cursor or Claude on an enterprise codebase, the AI has never seen your internal components. It knows el-table from Element Plus — but it has no idea what <ProTable>, <BizSelect>, or <OrgTreePicker> accept as props. So it guesses. It hallucinates prop names, skips required parameters, and passes wrong event names.
The root cause: default RAG retrieves raw source files, which are full of business logic noise. The AI has to infer the public API from hundreds of lines of internals.
This MCP solves that. It uses AST-level static analysis to extract only the public interface — Props, Events, Slots, and comments — and serves it to the AI as clean structured JSON. The AI gets the same quality of information it would have from official documentation.
AST-based extraction via vue-docgen-api and react-docgen — no raw source code sent to the model
Up to 80% token savings compared to sending full component files
Zero hallucinations on prop names, types, defaults, and required fields
Store analysis for Pinia, Vuex, Zustand, Redux Toolkit, and Jotai
Composables / Hooks analysis — extracts useXxx signatures, param types, return shapes, and JSDoc
Page component tree — recursively resolves all component dependencies of a page file
Auto-import awareness — detects unplugin-vue-components config, finds template usages without explicit imports
TypeScript type indexing — extracts interface, type alias, and enum definitions from type files
Reverse usage lookup — find every file that imports a given component
Path alias support — reads tsconfig.json, vite.config.ts, vue.config.js automatically
In-memory Watch mode — file watcher keeps the import index hot; queries read from memory, not disk
Zero maintenance — code is the source of truth; no JSON configs or wikis to keep updated
No local install needed. Configure directly in your AI client using npx.
Claude Desktop — add to claude_desktop_config.json:
{
"mcpServers": {
"local-component-mcp": {
"command": "npx",
"args": ["-y", "@wllcyg001/local-component-mcp"]
}
}
}Cursor — Settings → Features → MCP Servers → Add New MCP Server:
Mode: command
Name: local-component-mcp
Command: npx -y @wllcyg001/local-component-mcp
Claude Code:
claude mcp add local-component-mcp -- npx -y @wllcyg001/local-component-mcpFor local development: clone the repo, run
npm install && npm run build, then start withnode build/index.js.
Tool | Description |
| Scan a directory for |
| AST-parse a component and return its Props, Events, Slots, comments, and imports |
| Find every file that imports or uses a given component, with line numbers. Auto-import aware. |
| Scan a workspace for Pinia / Vuex / Zustand / Redux / Jotai store files |
| Parse a store file and return its state fields, getters, and actions |
| Scan |
| Parse a composable file and return full signatures: param types, defaults, return fields, JSDoc |
| Recursively resolve all component dependencies of a page file and return the full component tree |
| Scan |
| Parse a type file and return all member definitions with types, optionality, and JSDoc |
| High-performance, language-aware AST pattern matching search across workspaces. Natively parses |
All tools support alias paths (e.g., @/components/ProTable.vue).
Find a component:
"Search
/home/user/projects/my-app/src/componentsfor anything related to 'organization' or 'user picker'."
Use a component correctly:
"Parse
@/components/ProTable.vue, then write a User List page with name and employee ID columns. Use only the props and pagination events that ProTable actually exposes."
Safe refactoring:
"I'm changing the
sizeprop ofMyButton.vuefrom a string to an enum. Find every file in the project that uses this component and show me what value they're passing tosize."
Understand a page before editing:
"Run
analyze_pageon@/views/OrderDetail.vueand show me which components it uses and how they nest."
Reuse existing business logic:
"Search composables in
@/composables, find anything related to permissions or auth, then show me the full signature of that hook."
Type-safe code generation:
"Look up the
OrderDetailtype in@/types/order.ts, then generate a function that processes it correctly without making up any fields."
Semantic AST Pattern Matching:
"Use
query_astto find every place whereElMessage.successis called with a specific variable pattern, and show me the exact arguments."
Related MCP server: SigmaUI DS MCP Server
一个专门为企业内部二次封装组件库设计的 MCP Server，让 AI 编码助手准确理解你的私有组件。
在企业项目中使用 Cursor 或 Claude 时，AI 了解 Element Plus，但它从未见过你们项目里的 <ProTable>、<BizSelect>、<OrgTreePicker>。它只能猜测。结果是：乱填 prop 名、漏传必填参数、写错事件名——幻觉严重。
根本原因：默认的 RAG 检索拿到的是原始源文件，充满了业务逻辑噪音。AI 要从几百行内部代码里反推组件的公开接口。
这个 MCP 解决的就是这个问题。 通过 AST 静态分析，只提取公开接口（Props、Events、Slots、注释），以干净的结构化 JSON 提供给 AI。效果等同于给 AI 提供了一份官方 API 文档。
AST 级别提取：基于 vue-docgen-api 和 react-docgen，不向模型发送原始源码
节省高达 80% Token：相比直接发送完整组件文件
零幻觉：prop 名称、类型、默认值、必填项全部精准
状态管理分析：支持 Pinia、Vuex、Zustand、Redux Toolkit、Jotai
Composables / Hooks 分析：提取 useXxx 函数签名、参数类型、默认值、返回值字段及 JSDoc
页面组件树：递归解析页面文件的完整组件依赖树
Auto-import 感知：自动检测 unplugin-vue-components 配置，识别无显式 import 的模板引用
TypeScript 类型索引：提取 interface、type alias、enum 定义的完整成员信息
逆向引用查找：全项目扫描某组件被哪些文件引用
路径别名支持：自动读取 tsconfig.json、vite.config.ts、vue.config.js；别名配置带 mtime 缓存，修改后自动重载无需重启
内存 Watch 模式：文件监听器保持导入索引热更新，查询直接读内存而非磁盘
零维护成本：代码即文档，AI 每次查询都是最新状态
无需本地安装，直接通过 npx 在 AI 客户端中配置。
Claude Desktop — 编辑 claude_desktop_config.json：
{
"mcpServers": {
"local-component-mcp": {
"command": "npx",
"args": ["-y", "@wllcyg001/local-component-mcp"]
}
}
}Cursor — 设置 → Features → MCP Servers → Add New MCP Server：
模式选 command
Name：local-component-mcp
Command：npx -y @wllcyg001/local-component-mcp
Claude Code：
claude mcp add local-component-mcp -- npx -y @wllcyg001/local-component-mcp本地开发调试： 克隆仓库后执行
npm install && npm run build，再用node build/index.js启动。
工具 | 说明 |
| 扫描指定目录下的 |
| AST 解析组件，返回 Props、Events、Slots、注释及 imports |
| 全项目查找某组件的所有引用位置，含行号。支持 Auto-import 感知。 |
| 扫描工作区下所有 Pinia / Vuex / Zustand / Redux / Jotai store 文件 |
| 解析 store 文件，返回 state 字段、getters、actions 列表 |
| 扫描 |
| 解析 composable 文件，返回完整函数签名：参数类型、默认值、返回值字段、JSDoc |
| 递归解析页面文件的所有组件依赖，返回完整组件树 |
| 扫描 |
| 解析类型文件，返回所有成员的字段名、TS 类型、是否可选及 JSDoc 注释 |
| 高性能的跨语言 AST 模式匹配查询工具。突破正则局限，深度支持解析 |
所有工具均支持别名路径（如 @/components/ProTable.vue）。
寻找组件：
"帮我扫描
@/components目录，找找有没有跟'人员选择'或'组织架构'相关的组件。"
精准调用（零幻觉）：
"解析
@/components/ProTable.vue，然后帮我写一个用户列表页，包含姓名和工号两列，严格使用 ProTable 实际暴露的属性和分页事件。"
安全重构：
"我要把
MyButton.vue的sizeprop 从字符串改为枚举，帮我查整个项目里哪些文件引用了它，分别传了什么值。"
修改页面前先了解架构：
"用
analyze_page分析@/views/OrderDetail.vue，告诉我这个页面用了哪些组件、层级关系是什么。"
复用现有业务逻辑：
"搜索
@/composables下的所有 hooks，找跟权限或登录相关的，然后给我看那个 hook 的完整参数签名。"
类型安全的代码生成：
"查一下
@/types/order.ts里的OrderDetail类型定义，然后帮我写一个处理它的函数，不要自己捏造字段。"
AST 语义级代码搜索（突破正则局限）：
"用
query_ast帮我在整个项目中找出所有形如const $VAR = ref($VAL)的变量声明，或者寻找匹配ElMessage.success($MSG)的所有函数调用。"
MIT
Parse a Vue component file to extract its Props, Events, Slots, and other metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | The absolute path of the .vue file to parse. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits such as read-only nature, required permissions, error conditions, or side effects. The agent cannot infer what happens for invalid file paths or non-Vue files.
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?
Extremely concise single sentence that communicates the core purpose without any redundancy. Every word adds value.
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 simplicity (1 param, no output schema, no annotations), the description is adequate but could be improved by mentioning what 'other metadata' includes or potential error scenarios. It misses cues for complete understanding.
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 for the only parameter 'filePath'. The tool description adds no additional meaning beyond the schema, meeting the baseline for high 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 action (parse), the resource (Vue component file), and the extracted elements (Props, Events, Slots, and other metadata). It distinguishes from the sibling tool 'search_components' which likely searches for components rather than parsing a specific file.
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?
No explicit guidance on when to use this tool versus the sibling 'search_components'. The description implies it is for parsing a known .vue file path but lacks context like prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Vue components (.vue files) in a specified local directory workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| workspacePath | Yes | The absolute path of the workspace or components directory to scan. | |
| keyword | No | Keyword to filter component file names. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the search function, but does not mention that it is a read-only operation, whether it scans recursively, what happens with invalid paths, or any rate limits. Minimal transparency beyond the obvious.
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?
Single sentence, no wasted words, directly states purpose. Perfectly 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?
No output schema exists, but the description does not indicate what the tool returns (e.g., list of file paths). For a search tool, the return format is important for downstream use. Incomplete for an agent to fully understand the tool's behavior.
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% (both parameters have descriptions in the schema). The tool description adds no extra meaning beyond 'search in a specified local directory workspace'. Baseline of 3 is appropriate as the schema already explains the parameters.
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 it searches for Vue components (.vue files) in a directory. The verb 'search' and resource 'Vue components' are specific. It implicitly differentiates from sibling get_component_detail (which likely shows details of a single component), but does not explicitly contrast them.
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?
No guidance on when to use this tool vs get_component_detail. There is no mention of preconditions, workspace requirements, or when not to use it. The agent has no context for choosing between siblings.
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.1.2get_component_detailsearch_componentsBoth tools have clearly distinct purposes: one searches for component files, the other parses a specific component's metadata. No overlap in functionality.
Both tool names follow a consistent verb_noun pattern (get_component_detail, search_components), making it easy to predict their actions.
With only 2 tools, the server feels minimal. While they cover basic search and detail retrieval, the scope is thin for a component management server.
The server lacks essential operations for a complete component workflow, such as listing all components, creating, updating, or deleting. Users can only search and get details, which is a notable gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Serves your design system and coding standards to coding agents, so they stop guessing.
Give your AI assistant access to real Helm chart data. No more hallucinated values.yaml files.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/wllcyg/local-component-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
