Connect your agent

The MCP server

The knowledge API ships an MCP stdio entrypoint alongside its HTTP API. The server registers as assembly-knowledge and exposes three tools: search_design_system, get_component_docs, and get_design_tokens — see the full reference.

It runs from services/knowledge-api via uv, so there is nothing to install globally.

Claude Code

Add a .mcp.json at your project root (or merge into an existing one):

{
  "mcpServers": {
    "assembly-knowledge": {
      "command": "uv",
      "args": [
        "run",
        "--directory",
        "/path/to/assembly/services/knowledge-api",
        "python",
        "-m",
        "knowledge_api.mcp_server"
      ]
    }
  }
}

Replace /path/to/assembly with wherever you cloned the repo. Claude Code also supports registering the same command with claude mcp add — the repo documents the exact one-liner in docs/KNOWLEDGE-ENGINE.md.

Cursor

Cursor reads the same shape from .cursor/mcp.json in your project — use the identical command/args block. Any other MCP client that can spawn a stdio server works the same way.

Point it at your database

The server reads the corpus from Postgres, so DATABASE_URL has to point at a database that has been ingested:

Quickstart stack — Postgres on port 5433.
Full dev stack — Postgres on port 5432.

If your client config doesn’t inherit the right environment, set DATABASE_URL in the server’s env block. All variables are listed in Configuration.

What your agent can do now

Once registered, prompts like these stop being guesswork:

“What props does our Switch take?” → the agent calls get_component_docs("switch") and answers from real source and docs.
“How do we build confirmation dialogs here?” → search_design_system("confirmation dialog pattern") returns ranked corpus chunks.
“Use the right spacing tokens” → get_design_tokens() returns the actual token set instead of invented values.