MCP-Server

Lithic bringt einen hauseigenen MCP-Server mit. Damit kann ein Assistent — Claude, eine Agenten-CLI, alles, was das Protokoll spricht — die Dokumente und Pläne eines Workspace lesen, ohne dass jemand Klebecode schreiben muss.

Es gibt nichts zu installieren. Der Server läuft auf Ihrer Lithic-Instanz und antwortet unter https://app.lithicapp.io/mcp; Sie richten den Assistenten auf diese Adresse und geben ihm ein Token.

Er ist eine dünne Schicht über der öffentlichen API: Der Endpunkt hat keine eigene Rechtelogik, sondern stellt gewöhnliche API-Anfragen mit Ihrem Zugangsdatum. Ein Assistent sieht damit genau das, was Sie sehen. Dokumente gehen als kanonisches Markdown über die Leitung.

Er ist bewusst nur lesend: Der Server bietet keine Schreibwerkzeuge an, und es gibt nichts zu konfigurieren, damit das so bleibt. Ein Dokument zu ändern gehört dem gemeinsamen Editor, wo Änderungen mit denen der anderen zusammenlaufen.

Einrichtung

Zuerst ein Token anlegen: Einstellungen → Tokens, im Workspace, den der Assistent lesen soll. content:read genügt. Das Geheimnis wird einmal angezeigt.

Ein hier erstelltes Token gilt hier — es liest, was Lithic Ihnen zeigt, und nichts, was in den anderen Apps liegt. Deshalb müssen Sie dem Assistenten auch nicht sagen, welchen Workspace er nehmen soll: Das Token nennt einen, und der Endpunkt liest ihn dort ab.

In der Konfigurationsdatei eines MCP-Hosts:

{
  "mcpServers": {
    "lithic": {
      "type": "http",
      "url": "https://app.lithicapp.io/mcp",
      "headers": {
        "Authorization": "Bearer lithic_pat_…"
      }
    }
  }
}

Die Hosts schreiben das unterschiedlich; gebraucht werden überall dieselben zwei Dinge: die Adresse und der Authorization-Header. In Claude Code etwa:

claude mcp add --transport http lithic https://app.lithicapp.io/mcp \
  --header "Authorization: Bearer lithic_pat_…"

Wenn Ihr Konto in mehreren Workspaces ist und Sie einen ausdrücklich nennen möchten, verwenden Sie stattdessen https://app.lithicapp.io/mcp/w/<Workspace-ID>. Ein Token kann immer nur seinen eigenen Workspace nennen, die beiden müssen also übereinstimmen.

Als Connector hinzufügen

Hosts ohne Header-Feld — claude.ai gehört dazu — fügen den Endpunkt als Connector hinzu und melden Sie stattdessen an. Tragen Sie dieselbe Adresse https://app.lithicapp.io/mcp in den Connector-Dialog ein; der Rest ist eine Anmeldung und ein Bildschirm mit der Frage, ob Sie verbinden möchten. Nichts zu kopieren, kein Token, das Sie aufbewahren müssen.

Ein Connector reicht weiter als ein Token, und der Bildschirm sagt das, bevor Sie zustimmen:

• Er gilt für jeden Workspace, in dem Sie Mitglied sind, nicht für einen.
• Er liest, was Sie können. Lithic bietet überhaupt keine Schreibwerkzeuge an, ein Connector kann hier also nichts ändern, was immer ihm gewährt wurde.
• Er sieht weiterhin nur Lithic, und er hört auf zu funktionieren, wenn Ihr Zugriff endet.

Weil ein Connector mehrere Workspaces umfasst, muss der Assistent sagen, welchen er meint: https://app.lithicapp.io/mcp/w/<Workspace-ID>.

Was der Assistent bekommt

• get_workspace — Name und Zuschnitt des Workspace, den das Token öffnet.
• list_outlines / get_outline — die Dokumente, und ein Dokument als kanonisches Markdown.
• get_agenda — was geplant ist: die geplanten Zeilen eines Tages oder einer Woche, mit und ohne Uhrzeit.
• search — Volltext über die Dokumente des Workspace.

Was der Assistent nicht darf, dürfte auch das Token nicht: Rechte und Sichtbarkeit sind Sache des Servers, nicht der MCP-Schicht.

Wenn etwas abgelehnt wird

Der Endpunkt antwortet wie die API, eine Ablehnung sagt also, welcher der drei Fälle vorliegt:

• 401 — kein Zugangsdatum, oder eines, das unbekannt, widerrufen oder abgelaufen ist.
• 403 — ein Zugangsdatum, das das nicht darf: ein Token ohne content:read, oder eines, das zu einem anderen Workspace gehört als dem, den die Adresse nennt.
• Alles andere ist die gewöhnliche Antwort der API, mit ihrem eigenen Wortlaut durchgereicht.