Trackdolphin

German This text is available in German only for now. The site around it is in English, the text itself is not.

MCP-Server

Der MCP-Server macht Trackdolphin für Sprachmodelle bedienbar. Statt ein Dashboard zu öffnen, fragst du:

Läuft das Tracking bei meinshop.de sauber?

Welche Kanäle haben letzten Monat am meisten Umsatz gebracht?

Starte den Historienimport für das neue Projekt.

Es gibt zwei Wege, ihn anzubinden: lokal per npx oder gehostet über eine URL. Beide sprechen dieselben Werkzeuge, aus derselben OpenAPI-Beschreibung abgeleitet; der Unterschied ist nur, wo der Prozess läuft.

Lokal (stdio)

Passt für Desktop-Clients, die selbst einen Prozess starten können: Claude Desktop, Claude Code, Cursor, Windsurf, Zed. Einen Schlüssel im Dashboard unter Einstellungen → API & MCP erzeugen, dann in die Konfiguration des Clients eintragen. Für Claude Desktop (claude_desktop_config.json):

json
{
  "mcpServers": {
    "trackdolphin": {
      "command": "npx",
      "args": ["-y", "@trackdolphin/mcp"],
      "env": { "TRACKDOLPHIN_TOKEN": "td_live_…" }
    }
  }
}

Gehostet (Streamable HTTP)

Passt, wenn dein Client keinen lokalen Prozess starten kann oder soll: ein Browser-Agent, ChatGPT, ein Server-zu-Server-Aufruf. Statt eines Kommandos trägst du eine URL ein und schickst den Schlüssel als Kopfzeile mit, so wie bei der Kommandozeile:

text
URL:     https://mcp.trackdolphin.com/mcp
Kopf:    Authorization: Bearer td_live_…

Für Clients, die ein JSON statt eines Formulars erwarten:

json
{
  "mcpServers": {
    "trackdolphin": {
      "url": "https://mcp.trackdolphin.com/mcp",
      "headers": { "Authorization": "Bearer td_live_…" }
    }
  }
}

Ehrlich gesagt: Lokal ist der Normalfall. Der gehostete Weg lohnt sich vor allem dort, wo kein Prozess laufen darf oder soll. Der Grund liegt im Sicherheitsmodell: Der gehostete Server merkt sich deinen Schlüssel nicht: Jede einzelne Anfrage bringt ihren eigenen mit und er reicht ihn nur zur API durch, ohne ihn zu speichern oder zu protokollieren. Ein Dienst, der fremde API-Schlüssel dauerhaft hielte, wäre selbst ein lohnendes Ziel; das umgeht dieser Aufbau von vornherein. Ohne Schlüssel antwortet die URL mit HTTP 401.

Was er kann

Der Server pflegt keine eigene Werkzeugliste. Er lädt beim Start die OpenAPI-Beschreibung und macht daraus Werkzeuge. Ein neuer Endpunkt ist damit sofort ein neues Werkzeug, und es gibt keine zweite Liste, die veraltet.

Heute sind das unter anderem:

  • listShops: welche Projekte gibt es
  • getShopTrackingHealth: offene Störungen, letzter Prüflauf, letztes Event
  • getShopKpis, getShopChannels, getShopTopPages, getShopFunnel
  • getShopImportStatus: Erkennungsquote
  • startShopImport

Was er nicht kann

Anmeldevorgänge auslösen. Passwort-Reset, SSO-Anmeldung, E-Mail-Bestätigung und Einladungen annehmen stehen bewusst nicht in der Werkzeugliste. Für ein Sprachmodell wäre das reines Rauschen, im schlimmsten Fall gefährlich: Ein Agent könnte sonst ungewollt einen Passwort-Reset für einen fremden Zugang auslösen. Erkannt werden diese Endpunkte an ihrer Kennzeichnung in der OpenAPI-Beschreibung, nicht an einer Namensliste, die veralten könnte.

Die Schlüsselverwaltung. Ein Modell soll keine neuen Zugänge ausstellen können: Sonst wäre ein Widerruf wertlos, weil der widerrufene Schlüssel sich längst einen Nachfolger angelegt hat. Schlüssel erstellst und widerrufst du im Dashboard, siehe Einstellungen: API & MCP.