Luia MCP Server
Enables Claude to access and update a team's design knowledge stored in a local Markdown folder, including searching decisions and recording new conventions.
README
<img src="docs/preview.jpg" alt="The Luia graph: team knowledge at the centre, project work fanning out around it, with one node selected to show its connections" width="100%">
Luia
A knowledge graph for design teams.
Design teams accumulate knowledge faster than they can organise it. A spacing rule agreed in March, a carousel pattern that tested badly, the reason a component was built one way and not another. It ends up scattered across docs, threads, and people's memory, and by the time someone needs it nobody can find it.
Luia has two halves:
- An MCP server that plugs into Claude. Designers and developers install it once, and from then on Claude reads the team's conventions before answering and writes new decisions back as they are made.
- A graph viewer that renders the same knowledge spatially, so you can see how decisions connect instead of scrolling a folder tree.
Both read the same plain Markdown folder. There is no database, no backend, and no service to sign up for — which means a team shares its knowledge by putting that folder in git.
Install the MCP server
Requires Node.js 20.19+ or 22.12+.
git clone https://github.com/gustavocambareri/Luia_MCP.git
cd Luia_MCP
npm install
Point Claude at it. LUIA_KNOWLEDGE_DIR is the folder your team's Markdown
lives in — anywhere you like:
claude mcp add luia --scope user \
--env LUIA_KNOWLEDGE_DIR="$HOME/luia-knowledge" \
-- node "$PWD/server/index.mjs"
Verify it connected:
claude mcp list # luia: … - ✔ Connected
For Claude Desktop, add the same thing to claude_desktop_config.json:
{
"mcpServers": {
"luia": {
"command": "node",
"args": ["/absolute/path/to/luia/server/index.mjs"],
"env": { "LUIA_KNOWLEDGE_DIR": "/absolute/path/to/your-knowledge" }
}
}
}
That's the whole setup. Ask Claude "what's our spacing rule?" and it searches the store before answering.
What Claude can do with it
| Tool | When Claude reaches for it |
|---|---|
search_knowledge |
Before answering anything about how your team designs or builds — so the answer matches decisions you already made |
get_document |
When a search excerpt looks relevant and it needs the full rule |
record_decision |
The moment you settle a convention, so it survives the session |
list_documents |
To see everything the team has written down |
The two that matter are search and record. Search is described so Claude calls it unprompted at the start of design work — nobody remembers to ask for their own conventions. Record is a single call with no ceremony, because a capture step with friction is a capture step that doesn't happen.
Using it with your team
The knowledge store is a folder of Markdown files, so sharing it is just git:
cd ~/luia-knowledge
git init && git add . && git commit -m "Team knowledge"
git remote add origin git@github.com:your-team/design-knowledge.git
git push -u origin main
Teammates clone that repo and point their own LUIA_KNOWLEDGE_DIR at it. Pull
to get everyone's decisions; push to share yours. Decisions arrive as readable
diffs you can review like any other change.
Each document is plain Markdown with frontmatter — editable by hand, no tool required:
---
title: Spacing System
project: atlas # optional; omit for team-wide knowledge
author: your-name # or 'team' for collectively-owned decisions
tags: [spacing, layout]
created: 2026-03-09
---
8px base unit, with a 4px step for tight UI.
**Why:** the ratio between gaps carries more meaning than absolute values.
[!TIP] Always write the why. A decision without its rationale is one the team relitigates in six weeks — and the rationale is what makes Claude apply the rule correctly to a case you didn't anticipate.
The graph viewer
- Spatial navigation — a 3D force-directed graph you can pan, zoom, and explore, with hand-composed positions so the layout reads deliberately rather than like a hairball.
- Four ways to filter — by scope, project, author, or free-text search across titles, tags, descriptions, and section headings.
- The author lens — dim everything except one person's contributions to see who holds which knowledge, and where a single point of failure is forming.
- Typed relationships —
foundation,reference, andsiblingedges are drawn differently, so how two documents relate is legible at a glance. - Readable content — every node carries full Markdown, a description, and a section outline; click any node to read it without leaving the graph.
Running the viewer
npm run dev
Open the address Vite prints (usually http://localhost:5173) and the demo
graph loads immediately.
npm run build # production build to dist/
npm run preview # serve that build locally
npm run lint # eslint
[!NOTE] The bundled graph is entirely fictional. Meridian, Lumen, Atlas, Cadence, Harbor, and Verso are invented engagements, and every person credited in them is made up. Nothing here is real client work.
Viewer data format
The viewer reads src/data/graph-data.json. Replace it with your own and the
app is yours.
A node looks like this:
{
"id": "projects/atlas/block-library",
"name": "Atlas — Block Library",
"slug": "block-library",
"scope": "project",
"project": "atlas",
"author": "your-name",
"tags": ["atlas", "blocks", "templates"],
"created": "Mon Mar 16 2026 01:00:00 GM",
"fileSize": 8200,
"description": "Reusable blocks and page templates for the Atlas redesign.",
"body": "# Atlas — Block Library\n\n## Navigation\n\nSticky header that…",
"sections": ["Atlas — Block Library", "Navigation"],
"connections": ["_team/design-system-patterns"]
}
And an edge connects two of them:
{
"source": "_team/design-system-patterns",
"target": "projects/atlas/block-library",
"type": "reference",
"label": "informs",
"description": "Team patterns applied in the Atlas block library."
}
The full shape is defined in src/lib/types.ts.
Fields worth understanding
| Field | What it does |
|---|---|
scope |
team for shared knowledge, project for engagement work. Drives colour and grouping. |
project |
Required when scope is project. Becomes a filter chip automatically. |
author |
Powers the author lens. Use team for collectively-owned documents. |
fileSize |
Controls node radius. Scale your values into roughly 2600–19500 so sizes stay differentiated. |
body |
Markdown, rendered in the detail panel. |
sections |
Heading list, included in search. |
type |
Edge weight and curvature: foundation arcs through the centre, sibling hugs the perimeter. |
Adding a project
- Add your nodes to
graph-data.jsonwith a newprojectvalue. - Add a colour for it in
src/lib/colors.ts→PROJECT_COLORS. Without one it falls back to the default ink, and becomes indistinguishable from team nodes. - Optionally place its nodes in
MANUAL_POSITIONSinsrc/components/graph3d/useForceLayout.ts. Nodes without coordinates are positioned automatically, but hand-placing them keeps clusters legible.
The filter chips read the project list straight from your data, so step 1 is enough to make it appear in the UI.
[!TIP] Keep
idvalues path-like (projects/<project>/<slug>). Nothing enforces it, but it keeps the file browsable and makesconnectionseasy to write by hand.
Design decisions
A few choices are deliberate and worth knowing before you extend it:
- Positions are authored, not simulated. A pure force layout drifts on every
reload and buries the structure. Coordinates live in
useForceLayout.tsso the composition is stable and intentional. - Colour is a system, not decoration. Every hue in
colors.tsis derived from a five-colour palette and tuned to a narrow contrast band, so no project reads as visually heavier than another. - Uppercase titles, explicit weights. Type rules are applied consistently
across the canvas and panel; if you add UI, set
fontWeightexplicitly rather than inheriting it.
Project structure
server/ # the MCP server
├── index.mjs # tool definitions + stdio transport
└── knowledge.mjs # Markdown store: read, write, search
src/ # the graph viewer
├── data/graph-data.json # demo content — replace this with yours
├── lib/
│ ├── types.ts # GraphNode, GraphEdge, GraphData
│ └── colors.ts # palette, scope/project/author colour maps
├── hooks/useGraphData.ts # filtering, search, selection state
└── components/
├── FilterBar.tsx # scope/project/author filters, search
├── DecisionLog.tsx # per-node detail panel
└── graph3d/ # the 3D scene
├── useForceLayout.ts # hand-placed node coordinates
├── GraphNode3D.tsx # node + label rendering
└── GraphEdge3D.tsx # typed, curved edges
Built with
React 19 · TypeScript · Vite · Three.js via React Three Fiber · Tailwind CSS
推荐服务器
Baidu Map
百度地图核心API现已全面兼容MCP协议,是国内首家兼容MCP协议的地图服务商。
Playwright MCP Server
一个模型上下文协议服务器,它使大型语言模型能够通过结构化的可访问性快照与网页进行交互,而无需视觉模型或屏幕截图。
Audiense Insights MCP Server
通过模型上下文协议启用与 Audiense Insights 账户的交互,从而促进营销洞察和受众数据的提取和分析,包括人口统计信息、行为和影响者互动。
Magic Component Platform (MCP)
一个由人工智能驱动的工具,可以从自然语言描述生成现代化的用户界面组件,并与流行的集成开发环境(IDE)集成,从而简化用户界面开发流程。
VeyraX
一个单一的 MCP 工具,连接你所有喜爱的工具:Gmail、日历以及其他 40 多个工具。
Kagi MCP Server
一个 MCP 服务器,集成了 Kagi 搜索功能和 Claude AI,使 Claude 能够在回答需要最新信息的问题时执行实时网络搜索。
graphlit-mcp-server
模型上下文协议 (MCP) 服务器实现了 MCP 客户端与 Graphlit 服务之间的集成。 除了网络爬取之外,还可以将任何内容(从 Slack 到 Gmail 再到播客订阅源)导入到 Graphlit 项目中,然后从 MCP 客户端检索相关内容。
Exa MCP Server
模型上下文协议(MCP)服务器允许像 Claude 这样的 AI 助手使用 Exa AI 搜索 API 进行网络搜索。这种设置允许 AI 模型以安全和受控的方式获取实时的网络信息。
mcp-server-qdrant
这个仓库展示了如何为向量搜索引擎 Qdrant 创建一个 MCP (Managed Control Plane) 服务器的示例。
e2b-mcp-server
使用 MCP 通过 e2b 运行代码。