The server registers as assembly-knowledge and runs over stdio (python -m knowledge_api.mcp_server, usually via uv run). Setup lives in Connect your agent.
search_design_system
search_design_system(query: string, limit: number = 10)Hybrid vector + full-text search across the whole corpus. limit accepts 1–50.
Returns ranked hits, each with:
| Field | Meaning |
|---|---|
source_path | Corpus file the chunk came from |
component_name | Component the chunk belongs to, when applicable |
doc_type | component_doc · component_source · story · token |
chunk_index | Position of the chunk within its file |
text | The chunk content |
rrf_score | Fused ranking score |
fts_mode | How the full-text side matched |
Use it for open-ended and cross-component questions: patterns, “how do we…”, anything where the component isn’t known yet.
get_component_docs
get_component_docs(component: string)Everything about one component, ordered for reading: component_doc → component_source → story, grouped by file and capped at 100 chunks.
The name is normalized to a kebab-case slug ("Switch", "switch", and "SWITCH" all resolve to switch). If the component doesn’t exist, the response suggests near-matching names instead of failing cold.
Use it when the component is already known — it’s cheaper and more complete than searching.
get_design_tokens
get_design_tokens()No arguments. Returns every chunk tagged doc_type: token, ordered by source_path then chunk_index, behind a 60-second TTL cache.
Use it for any theming or token question — colors, spacing, typography — so values come from the corpus, not the model’s imagination.
Choosing a tool
| Situation | Tool |
|---|---|
| Component name known | get_component_docs |
| Open-ended or cross-component question | search_design_system |
| Theme / token question | get_design_tokens |