1Was MCP löst

MCP (Model Context Protocol) ist ein offenes Protokoll, das LLMs Zugriff auf standardisierte Tools, Prompts und Ressourcen erlaubt. (AH 7.3, wörtlich)

Das Problem dahinter: Ein Chatbot kann reden, ein Agent soll handeln — und externe Systeme (CRM, Kalender, Datenbank, Ticketsystem) sind uneinheitlich. Ohne Standard braucht jeder Client für jedes Tool eine Sonderintegration (N×M); MCP macht daraus N+M — das „USB-C der KI-Tools".

2Rollenmodell & AuxData-Einordnung

Die MCP-Spezifikation kennt drei Rollen: Host = Anwendung, mit der der Nutzer interagiert; Client = Protokoll-Komponente im Host, je eine Verbindung zu genau einem Server; Server = stellt Kontext und Fähigkeiten bereit.

AuxData-Einordnung (AH 7.3, wörtlich): „AuxData.ai fungiert als MCP-Client." AuxData verbindet sich also mit externen MCP-Servern, liest deren Fähigkeiten aus und macht ihre Tools in Workflows bzw. im Agent-Tool-Use nutzbar.

3Tools, Resources, Prompts

Drei Bausteine stellt ein MCP-Server bereit — am CRM-Beispiel:

Tools

Aktionen, die das Modell auslösen kann — z. B. customer_lookup.

Resources

lesbarer Kontext — z. B. crm://schema/customer.

Prompts

wiederverwendbare Vorlagen — z. B. support_triage_prompt.

1Protokollformat & Transporte

MCP nutzt JSON-RPC 2.0 als Nachrichtenformat. (MCP-Spec)

Es gibt zwei Standard-Transporte (Revision 2025-11-25): stdio (lokaler Prozess, Standard-Ein/Ausgabe) und Streamable HTTP (entfernter Server, ein HTTP-Endpoint mit POST/GET, optional SSE-Streaming). Für AuxData → externer Server ist Streamable HTTP der relevante Fall.

In Klartext: MCP-Nachrichten sind kleine JSON-Pakete nach einem festen Standard (JSON-RPC). Bei AuxData läuft das über einen normalen HTTPS-Endpoint — AuxData fragt an, der externe Server antwortet im selben Format.

2Die drei Pflichtfelder im Editor

AuxData-Editor-Felder (AH 7.3, wörtlich):

URI

Basis-URL, z. B. https://mcp.example.com.

Endpoint

HTTP-Pfad, Standard /mcp.

Authorization

Bearer-Token oder API-Key.

3Der initialize-Handshake

Bevor ein Tool aufgerufen wird, handeln Client und Server eine Protokollversion und ihre capabilities aus — der initialize-Handshake (MCP-Spec, Lifecycle):

→ initialize                 // protocolVersion: "2025-11-25", clientInfo: AuxData
← result                     // serverInfo + capabilities
→ notifications/initialized  // Session steht
→ tools/list
← result                     // [customer_lookup, ticket_create]

Merksatz: Erst initialize → initialized, dann erst tools/list / tools/call. Keine Tool-Calls vor dem Handshake.

1„Neu laden" & die Listen-Methoden

„Neu laden" (AH 7.3, wörtlich) „fragt den Server nach verfügbaren Tools, Prompts und Resources ab." Auf Protokollebene löst das die Listen-Methoden tools/list, resources/list, prompts/list aus. (MCP-Spec)

Je Tool sichtbar (AH 7.3, wörtlich): Name, Beschreibung, JSON-Schema der erwarteten Argumente. Dieses inputSchema ist zentral, weil AuxData die Argumente aus Workflow-Variablen befüllt — ohne Schema weiß AuxData nicht, welche Felder das Tool erwartet.

2Ein Tool-Schema lesen

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

So liest man es: type: object = das Tool erwartet ein Objekt; properties = die erlaubten Felder mit Typ; required = Pflichtfelder. AuxData mappt customerId später auf eine Workflow-Variable (z. B. die Kundennummer aus der Eingabe).

3Tool, Resource oder Prompt?

customer_lookup

Tool (Aktion).

crm://schema/customer

Resource (lesbarer Kontext).

support_triage_prompt

Prompt (Vorlage).

1Zwei Nutzungswege

AH 7.3 (wörtlich) nennt zwei Wege: (1) Ein konfigurierter MCP-Server ist im Workflow-Schritt-Editor unter Vorverarbeitung oder Nachverarbeitung als Tool auswählbar. (2) Alternativ nutzen LLMs mit Tool-Use-Capability die Tools autonom, wenn der Administrator dies im Agent-Editor aktiviert hat.

2Beispiel-Workflow (Supportfall)

Eingabe Kundennummer + Frage → Vorverarbeitung customer_lookup(customerId) → Ergebnis in Variable ${customer} → LLM-Schritt „Beantworte die Kundenfrage. Nutze Kundendaten: ${customer}" → optional Nachverarbeitung ticket_create(summary, priority) (nur nach Freigabe).

3tools/call: Request & Response

→ 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
  }
}

Parameter-Mapping: Die arguments kommen aus Workflow-Variablen; das result.content wird in der Ergebnisvariable gespeichert und im Prompt referenziert.

1Voraussetzung & Übersicht

Voraussetzung (AH 7.4): Organisations-Admin oder höher. MCP-Server werden auf Organisationsebene gepflegt und stehen dann allen Agenten der Organisation zur Verfügung.

Die Übersicht (AH 7.3) listet die eingetragenen Server mit Verbindungsstatus und Tool-Zahl.

2MCP-Server-Editor (Reiter Verbindung)

1. Felder ausfüllen.
2. Speichern.
3. „Neu laden" drücken.
4. Tool-/Resource-/Prompt-Liste prüfen (Name, Beschreibung, JSON-Schema).

3Demo-CRM-MCP (Schemas)

Tool      customer_lookup   inputSchema: { customerId: string (required) }
Tool      ticket_create     inputSchema: { summary: string, priority: enum[low,med,high] }
Resource  crm://schema/customer   Feldstruktur des CRM als lesbarer Kontext
Prompt    support_triage_prompt   Vorlage zur Erst-Triage eines Supportfalls

1AuxData-Regeln

AH 7.3 (wörtlich) nennt drei harte Regeln:

HTTPS + Zertifikat

nur HTTPS-Server mit validen Zertifikaten sind zugelassen.

URL-Whitelist

greift ebenfalls (wie bei HTTP-Services/Funktionen, AH 7.2).

Timeout

jede Tool-Ausführung mit 15-Sekunden-Timeout begrenzt.

Secrets (AH 7.5): API-Keys/Tokens gehören in Umgebungsvariablen, nicht in Prompt oder Body — sie liegen verschlüsselt in der Datenbank.

2Risiken aus der MCP-Spezifikation

3Sicherheits-Checkliste

1Versions- und Transport-Grenzen

AH nennt URI/Endpoint, aber keine Protokollversion → Transport (stdio vs. Streamable HTTP), HTTP-Header und Version (2025-11-25 / 2025-06-18 / Legacy HTTP+SSE) sind implementierungsabhängig und vor Produktivbetrieb gegen Instanz + Server zu prüfen. (gegen MCP-Spec & Instanz prüfen)

2Drei Fehler-Ebenen

Protokoll-Fehler

error-Objekt (z. B. -32602 Invalid params) → Aufruf hat das Tool nicht erreicht/akzeptiert; Schritt abbrechen und loggen.

Tool-Fehler

result mit isError: true → Tool lief, meldet aber fachlichen Fehler; Fallback oder Nutzerhinweis.

Timeout

kein Ergebnis in 15 s (AuxData-Limit) → Workflow muss Abbruch/Retry definieren, nicht hängen bleiben.

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

3MCP vs. HTTP-Service vs. Funktion

HTTP-Service

ein einzelner Stecker für einen bekannten REST-Endpunkt mit fester Signatur.

Funktion

eigener ES5.1-Code (SQL/HTTP/Mail/KnowledgeDB) — vertieft in E4.

MCP

ein ganzer Werkzeugkasten, den AuxData entdecken kann (Tools/Resources/Prompts standardisiert).

Merksatz: einzelner REST-Call → HTTP-Service; eigene Logik → Funktion; standardisiertes externes Tool-Ökosystem → MCP.