Skip to main content
Glama
yishu-ziyu

design-parts

by yishu-ziyu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

design-parts-mcp

把一个「设计零件库」暴露成本地 stdio MCP server：AI 编码工具（Claude Desktop / Cursor / Codex / Trae 等）可以直接检索并取用可打开、可复刻的交互与动效零件。库里每篇笔记是一个自包含的 index.html 活笔记——零件能学能搬，先打开看它正在转的样子。

默认内置一份可分享快照（library/）；如果你本地有自己的 design-notes 库，用 DESIGN_NOTES_PATH 指过去即可，server 会直接读真源。

三个工具

工具

入参

返回

search_parts

query（必填，空字符串 = 全量发明表）

匹配条目：发明表（这页是什么、什么时候用）、零件表（要做哪一块打开哪一页哪一处）、页尾「可拆」锚点、README 命中行；每条含 type / note / anchor / path / description

get_part

id（必填，如 "bento#chart"、"spine#dot" 或笔记名 "bento"）

所在笔记、锚点的「可拆」说明、提取出的关键参数（时长/缓动/尺寸/频率）、该笔记 index.html 的绝对路径（直接打开细读源码）；笔记名形式返回全部可拆锚点列表

get_source

name（必填，如 "bento"）

该笔记 README 全文（来源 URL、原版机制逐条记录、可学/不学/启示）+ 提取出的来源 URL 列表

Related MCP server: Memory Store

接入

Claude Desktop

claude_desktop_config.json（菜单 → Settings → Developer → Edit Config）：

{
  "mcpServers": {
    "design-parts": {
      "command": "npx",
      "args": ["-y", "github:yishu-ziyu/design-parts-mcp"],
      "env": {
        "DESIGN_NOTES_PATH": "/path/to/your/design-notes"
      }
    }
  }
}

Cursor / Codex / 其它 MCP 客户端

mcp.json：

{
  "mcpServers": {
    "design-parts": {
      "command": "npx",
      "args": ["-y", "github:yishu-ziyu/design-parts-mcp"],
      "env": {
        "DESIGN_NOTES_PATH": "/path/to/your/design-notes"
      }
    }
  }
}

本地 clone 运行时把 args 换成：["node", "/path/to/design-parts-mcp/server/index.js"]。

DESIGN_NOTES_PATH

  • 未设置：用仓库内置 library/ 快照（开箱即用）。

  • 设置后：指向你的 design-notes 库根目录（其下有 living/INDEX.md 与 living/<name>/index.html），直接读真源，改动即时生效。

用自己的库

库结构约定：

design-notes/
  living/
    INDEX.md          # 检索入口：## 发明 表 + ## 零件 表
    <name>/
      index.html      # 自包含活笔记；页尾可有 <h3>可拆</h3> + <dl>（#anchor → 参数说明）
      README.md       # 可选：来源 URL、机制记录、可学/不学

INDEX.md 表格行里的链接指向 living/<name>/index.html#anchor；死链行会被自动剔除并打 stderr 警告，不会挡住其余检索。

贡献零件

欢迎把自己复刻的活笔记按上面的结构加进你的库；要合入本仓库内置快照，提 PR 前：

  1. npm run sync（从 DESIGN_NOTES_PATH 刷新 library/，默认 ~/Documents/design-notes）；

  2. 新笔记要有 index.html（页尾写「可拆」锚点段）和 README（来源 URL + 机制记录）；

  3. npm test 全绿（真实 stdio 协议测试，快照与真源两条路径各跑一遍）；

  4. README/快照里不得含本地绝对路径、真名、私有仓库名（sync 会自动清洗，洗不净的会跳过并警告）。

使用纪律

零件可以学、可以搬进你自己的实现，但：

  • 不要原样照抄他人 UI。零件是「机制 + 参数」，不是成品皮：文案、品牌、配色、内容换成你自己的。

  • 不要冒用来源作品。每个零件的 README 记录了来源 URL 与机制考据，引用时注明出处；来源作者的风格签名（logo、签名图、专有插画）一律不抄。

  • 产品落地时先打开活笔记看它正在转的样子，再决定要不要这一块——截图只看得到三分之一。

Available Tools

3 tools
get_partA

取一个设计零件的完整说明。id 传零件锚点（如 "bento#chart"、"spine#dot"、"triage#toolbar"）或笔记名（如 "bento"）。锚点形式返回：所在笔记、锚点的「可拆」说明文本、提取出的关键参数（时长/缓动/尺寸/频率）、该笔记 index.html 的绝对路径（直接打开细读源码）。笔记名形式返回：笔记摘要、全部可拆锚点列表、零件表条目。

ParametersJSON Schema
NameRequiredDescriptionDefault
idYes零件锚点（"note#anchor"，如 "spine#dot"）或笔记名（"bento"）

TDQS

A3.8/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full behavioral burden, and it does so unusually well: it discloses what is returned in each of the two modes (note/anchor text, extracted parameters, absolute index.html path, anchor lists, parts table). It does not state permissions or error behavior, but for a read-style retrieval tool the return-shape disclosure is the substantive trait.

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

Conciseness4/5

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

A single, front-loaded paragraph that leads with the purpose before enumerating the two return modes by input form. No filler, though the enumeration is dense and slightly hard to parse at first read.

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 dual-mode retrieval tool with no output schema, the description is nearly sufficient: it fully explains return values for both input forms, which is the main complexity. It omits any mention of the sibling tools or failure cases, which keeps it short of complete routing context.

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?

Schema coverage is 100% and the schema already documents the id field, but the description adds real meaning beyond the schema by concretely tying each id form to a different return payload ('bento#chart' vs 'bento'). This dual-mode semantics is not derivable from the schema alone.

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

Purpose4/5

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

The description names a specific verb (take/get) and resource (a design part's complete description), and goes beyond the name by enumerating exactly what a part entry contains. However, it never distinguishes itself from siblings search_parts or get_source, so an agent cannot tell where this tool's boundary lies from the description alone.

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?

Usage is implied through the two documented id forms (anchor vs note name) and what each returns, which guides the agent on which input to pass. But there is no explicit when-to-use/when-not guidance, no mention of search_parts as the discovery alternative, and no note on when get_source should be preferred.

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

get_sourceA

取某篇设计笔记的来源信息：README.md 全文（来源 URL、原版机制逐条记录、可学/不学/启示）、提取出的来源 URL 列表。用于查看零件学自哪个原版作品及其机制考据。

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes笔记目录名，如 "bento"、"triage"、"spine"

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the return contents (full README, URL list) in the absence of an output schema, and '取' implies a read, but it says nothing about permissions, safety, or side effects for this operation.

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

Conciseness4/5

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

A single well-structured sentence that front-loads the action and then details the returned contents and the purpose. No redundant or wasted phrasing; slightly dense but efficient.

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 simple one-parameter getter with no annotations and no output schema, the description adequately describes the result shape (README full text plus extracted URL list) and the reason to call it. It is complete enough for correct invocation, though it could clarify its relationship to get_part.

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 description coverage is 100% and the single `name` parameter is fully documented in the schema. The description only reiterates that it targets a design note (某篇), adding little beyond the structured field, so the baseline 3 applies.

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

Purpose4/5

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

States a specific verb+resource (取...来源信息) for a design note and enumerates what that source info contains (README 全文, 来源 URL 列表), so the agent knows exactly what it returns. It does not explicitly differentiate itself from the sibling get_part, which could also return note content, leaving the boundary somewhat implicit.

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 clause 用于查看零件学自哪个原版作品及其机制考据 gives a clear intended use case, but there is no explicit when-to-use-vs-when-not guidance and no mention of the sibling alternatives (get_part, search_parts). Usage is implied rather than directed.

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

search_partsA

检索设计零件库：发明表（每篇活笔记是什么、什么时候用）+ 零件表（要做哪一块 UI，打开哪一页哪一处）+ 各笔记页尾「可拆」锚点 + 各笔记 README。query 为空字符串时返回全量发明表；否则返回匹配条目（type: invention/part/detachable/readme，含 note、anchor、path、description）。示例 query："镜头"、"工具栏"、"tooltip"、"批量选择"、"手风琴"。中文关键词效果最好。

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes检索词（中文/英文关键词，空格分隔多个词）；传空字符串返回全量发明表

TDQS

A4/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 and does meaningful work: it discloses the returned entry categories (type: invention/part/detachable/readme) and the fields returned (note, anchor, path, description), plus the empty-query fallback behavior. It omits result-size limits, ordering, and pagination behavior, which matters for a search tool.

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

Conciseness4/5

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

One dense paragraph, front-loaded with the searched corpus and immediately followed by the empty-query rule and examples. Every clause carries information, though the run-on corpus enumeration is slightly heavy for scanning.

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?

No output schema exists, and the description compensates by naming the returned type values and fields, plus the empty-query behavior. For a single-parameter search tool this is close to complete; only pagination/result-cap behavior is unaddressed.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real value: five domain-specific example queries (镜头, 工具栏, tooltip, 批量选择, 手风琴) and the tip that Chinese keywords work best, which tells the agent how to phrase input rather than just its type.

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

Purpose4/5

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

States a specific verb (检索/search) and a specific resource (设计零件库), then enumerates exactly what corpus is covered: invention table, parts table, per-note 「可拆」 anchors, and READMEs. That enumeration implicitly separates it from get_part/get_source, but it never names those siblings, so differentiation is inferential rather than explicit.

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?

Gives a clear routing rule for the one parameter: empty query returns the full invention table, non-empty returns matching entries, backed by five concrete example queries. It does not state when to prefer this over get_part or get_source, so the alternative-selection guidance is absent.

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.

  1. 3 tool updatesv0.1.0
    • First observedget_part
    • First observedget_source
    • First observedsearch_parts
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored across 3 tools

Disambiguation5/5

The three tools have clearly distinct purposes: search_parts discovers/retrieves matching entries, get_part retrieves a specific part's details, and get_source retrieves provenance/README information. There is no meaningful overlap in their intended use.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: search_parts, get_part, get_source. The plural/singular distinction is natural and predictable.

Tool Count5/5

Three tools are well-scoped for a read-only design parts reference library: discovery, part detail, and source provenance. Each tool earns its place without excess.

Completeness4/5

The surface covers search, part retrieval, and source lookup well. A minor gap is that empty search returns only the full invention table, not a direct bulk list of all parts/anchors, though these can be reached by iterating notes.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Bruin

    sawzhang
    A
    license
    Not graded
    quality
    C
    maintenance
    MCP server for AI agents to read, write, and organize notes in a local-first, human-in-the-loop note-taking app.
    0
    2
    MIT

  • Zero Brain MCP Server

    miru-zero
    A
    license
    A
    quality
    A
    maintenance
    MCP server for managing a local, domain-agnostic knowledge base using Markdown notes with frontmatter. Enables AI agents to capture, read, search, link, and maintain notes with atomic writes and privacy controls.
    13
    MIT

  • notes-mcp

    sheimaz
    A
    license
    A
    quality
    C
    maintenance
    MCP server for a personal notes/knowledge base that enables AI assistants to create, search, and retrieve notes using natural language. It exposes tools like create_note and search_notes, resources for each note, and a summarize_tag prompt.
    6
    MIT