Ein Chatbot kann antworten. Ein Agent soll zusätzlich Dinge herausfinden, Aktionen auslösen und Daten aus Systemen nutzen.

Ein Workflow kann vor dem LLM-Aufruf Kundendaten holen, danach ein Ticket anlegen oder aus einem externen Fachsystem den aktuellen Status lesen. Das LLM muss die Schnittstelle nicht selbst kennen; es bekommt ein sauber beschriebenes Tool.

Beobachte, wie eine Anfrage von links nach rechts wandert und das Ergebnis zurückfließt.

Wenn jemand „MCP in AuxData" sagt, können zwei sehr verschiedene Dinge gemeint sein. In diesem Tutorial geht es um den dokumentierten Fall: AuxData nutzt externe MCP-Server. Es geht nicht darum, AuxData selbst als MCP-Server für andere Clients zu veröffentlichen.

Laut MCP-Spezifikation macht ein Server diese Fähigkeiten über Listen-Methoden auffindbar (tools/list, resources/list, prompts/list). Laut AuxData-Handbuch löst die Funktion Neu laden genau diese Abfrage aus.

Klicke auf „Fähigkeiten laden" — so füllt der Server seine Capability-Liste, wie es AuxDatas Neu laden tut.

Ein Tool ist nicht nur ein Name. Sein inputSchema beschreibt, welche Eingaben es erwartet — wichtig, weil AuxData diese Argumente aus Workflow-Variablen befüllt.

{
  "name": "customer_lookup",
  "description": "Findet Kundendaten anhand einer Kundennummer",
  "inputSchema": {
    "type": "object",
    "properties": {
      "customerId": { "type": "string" }
    },
    "required": ["customerId"]
  }
}

MCP nutzt JSON-RPC 2.0 als Nachrichtenformat. Die aktuelle Spezifikation (Revision 2025-11-25) nennt zwei Standard-Transporte:

Bevor ein Tool aufgerufen werden darf, handeln Client und Server eine Protokollversion und ihre capabilities aus. Das ist der Pflicht-Einstieg jeder MCP-Session. Spiel ihn ab:

Laut Administrator-Handbuch Kap. 7.3 enthält die Verbindung im MCP-Editor Name, URI, Endpoint und Authorization. Zusätzlich können Umgebungsvariablen mitgegeben werden.

Ein realistischer externer Server könnte so aussehen. Die Namen sind bewusst Demo-Namen, nicht AuxData-Systemfunktionen.

Sobald ein Demo-Zugang und ein Test-MCP-Server bereitstehen, sollten hier echte Screenshots aus deiner AuxData-Instanz ergänzt werden.

Keine echten Tokens, Kundennamen oder internen URLs im Bild lassen. Secrets vor Veröffentlichung schwärzen oder mit Demo-Werten arbeiten.

Im Workflow-Schritt-Editor beschreibt das Administrator-Handbuch Vor- und Nachverarbeitung. Dort lassen sich HTTP-, Function- oder MCP-Aufrufe einbinden. Ein MCP-Service-Aufruf speichert sein Ergebnis in einer Variable, die später in Prompts genutzt wird.

Drücke „Abspielen" — der Supportfall-Workflow läuft Schritt für Schritt, mit echtem tools/call-Request und -Response.

Diese Stellen sind die besten Kandidaten für spätere echte AuxData-Screenshots, weil sie den Praxisnutzen sofort sichtbar machen.

So sieht der eigentliche Aufruf auf Protokollebene aus — Argumente kommen aus den Workflow-Variablen:

→ Request
{
  "jsonrpc": "2.0", "id": 3,
  "method": "tools/call",
  "params": {
    "name": "customer_lookup",
    "arguments": { "customerId": "K-1842" }
  }
}

← Response
{
  "jsonrpc": "2.0", "id": 3,
  "result": {
    "content": [{ "type": "text",
      "text": "{ status: Premium, offeneTickets: 1, vertrag: aktiv }" }],
    "isError": false
  }
}

Tools scheitern auch mal: Timeout, falsche Argumente, Server-Fehler. MCP kennt dafür zwei Ebenen, die du im Workflow unterschiedlich behandelst:

← Tool-Fehler
{
  "jsonrpc": "2.0", "id": 4,
  "result": {
    "content": [{ "type": "text", "text": "Kunde K-9999 nicht gefunden" }],
    "isError": true
  }
}

Die offizielle MCP-Spezifikation betont Zustimmung, Datenschutz und Tool-Sicherheit. Tools können echte Aktionen auslösen. Deshalb sollte der Nutzer sehen können, welche Tools verfügbar sind und wann ein Tool ausgeführt wird.