Verfügbare Tools

Der MCP-Server stellt 56 Tools bereit. Jedes Tool bildet genau einen Endpunkt der Zyles REST-API ab und gibt dessen Antwort unverändert zurück.

Sie müssen diese Namen nicht auswendig lernen — Claude wählt das passende Tool selbst aus. Die Liste hilft beim Nachvollziehen, was ein Assistent tatsächlich getan hat, und beim Formulieren präziser Anweisungen.

project_id bei jedem Tool

Alle Tools außer workspaces_list nehmen zusätzlich ein optionales project_id. Ohne Angabe gilt das Standardprojekt der Verbindung; bei API-Key-Verbindungen wird das Feld ignoriert. Siehe Mehrere Projekte.

Verbindung & Projekte

Tool	Endpunkt	Zweck
zyles_whoami	GET /me	Zeigt Projekt und Benutzer zum aktuellen Token. Guter erster Test.
workspaces_list	—	Listet die erreichbaren Projekte mit IDs und das Standardprojekt.

Leads

Tool	Endpunkt	Zweck
leads_create	POST /api/leads/add	Legt Leads als Stapel an. Einzige Pflichtangabe je Lead: phone_number.
leads_list	POST /api/leads	Sucht und filtert Leads; unterstützt filters, search und Paginierung.
leads_get	GET /api/leads/{id}	Liest einen einzelnen Lead.
leads_update	PUT /api/leads/{id}	Ändert Felder. archived: true archiviert, false stellt wieder her.

Kein hartes Löschen

Leads lassen sich nur archivieren. Das ist Absicht — so bleibt die Historie erhalten.

Smart Views

Tool	Endpunkt	Zweck
smart_views_list	GET /api/smart-views	Listet alle Smart Views des Projekts.
smart_views_create	POST /api/smart-views	Legt eine Ansicht an; name und filters sind Pflicht.
smart_views_update	PUT /api/smart-views/{id}	Ändert Name oder Filter.
smart_views_delete	DELETE /api/smart-views/{id}	Löscht eine Ansicht.
smart_views_leads	POST /api/smart-views/{id}/leads	Löst eine Ansicht zu den passenden Leads auf.
custom_fields_list	GET /api/custom-fields	Listet die Zusatzfeld-Definitionen (id, name, field_type, options, external_id). Die id ist die field_id für den Filter custom_field_value.

Filter-Referenz (filters)

Form: {"operator":"AND"|"OR","conditions":[…]}, eine Bedingung ist {"field","operator","value"} oder wieder ein verschachteltes {"operator","conditions"}.

Feld	Operatoren	Wert
first_name, last_name, email, phone_number, notes	equals, not_equals, contains, not_contains, starts_with, ends_with, is_null, is_not_null, in, not_in	Text
status_id	equals, not_equals, in, not_in, is_null, is_not_null	Status-UUID (lead_statuses_list)
created_at, updated_at, last_called_at	equals, greater_than, less_than, greater_than_or_equal, less_than_or_equal, is_null, is_not_null	ISO-Datum oder ein relatives Preset (siehe unten)
call_amount	equals, greater_than, less_than, greater_than_or_equal, less_than_or_equal	Zahl
tag_id	equals, not_equals, in, not_in	Tag-UUID (tags_list)
call_outcome_id	equals, not_equals, in, not_in, is_null, is_not_null	Ergebnis-UUID (call_outcomes_list)
activity_type	equals, not_equals, in, not_in	call, email, note, …
custom_activity_type_id	equals, not_equals, in, not_in, is_null, is_not_null	Typ-UUID (custom_activity_types_list) – „hat (keine) eigene Aktivität dieses Typs“
custom_activity_field_value	equals, not_equals, contains, not_contains, starts_with, ends_with	{"field_id": <Feld-UUID>, "value": <Text>}
custom_field_value	equals, not_equals, contains, not_contains, starts_with, ends_with, is_null, is_not_null, greater_than, less_than, in, not_in	{"field_id": <Zusatzfeld-UUID aus custom_fields_list>, "value": <Text>}

Mehrfachauswahl-Zusatzfelder (z. B. das „Tags“-Feld eines Close.io-Imports) sind als Liste gespeichert; contains mit einer Option bedeutet „hat diese Option“:

{"field":"custom_field_value","operator":"contains","value":{"field_id":"<id aus custom_fields_list>","value":"kampagne-2a-start"}}

contains ist eine Textsuche: newsletter 1 trifft auch newsletter 1 durchlaufen.

Relative Datums-Presets

Statt eines ISO-Datums akzeptieren created_at, updated_at, last_called_at sowie Zusatzfelder vom Typ date eines dieser Presets. Sie werden bei jeder Abfrage serverseitig aufgelöst — die Smart View wandert also mit dem Kalender mit, statt ein Datum einzufrieren.

today · yesterday · this_week · last_week · this_month · last_month · this_quarter · last_quarter · this_year · last_year · last_7_days · last_30_days · last_90_days

Wochen beginnen am Montag. last_7_days ist das Fenster von heute minus 7 Tagen bis heute, jeweils inklusive.

warnung

Ein unbekannter Wert ist kein Fehler. Der Filter wird gespeichert und trifft dann nichts — die Smart View bleibt leer, ohne Meldung. Nutze genau die Schreibweisen aus der Liste; last_14_days oder letzte_woche gibt es nicht.

Power-Dialer

Tool	Endpunkt	Zweck
power_dialers_list	POST /api/power-dialer/list	Listet die Dialer-Kampagnen.
power_dialers_create	POST /api/power-dialer	Legt eine Kampagne an (AI oder MANUAL).
power_dialers_get	POST /api/power-dialer/smart-view/{id}	Liest eine Kampagne über Smart View und Modus.
power_dialers_delete	DELETE /api/power-dialer/{id}	Löscht eine Kampagne.
power_dialers_set_status	PUT /api/power-dialer/{id}/status	Setzt idle, running oder finished — startet bzw. stoppt also die Kampagne.
power_dialers_set_schedule	PUT /api/power-dialer/{id}/schedule	Hinterlegt den Anrufzeitplan.

user_id ist hier Pflicht

Das Backend leitet das Projekt aus dem Token ab, nicht aber den Benutzer. Alle Power-Dialer-Tools brauchen daher eine gültige user_id. Claude ermittelt sie in der Regel selbst; andernfalls fragt es nach.

KI-Agenten

Tool	Endpunkt	Zweck
agents_list	GET /api/agents	Listet die Agenten des Projekts.
agents_create	POST /api/agents	Legt einen Agenten an (type standardmäßig caller).
agents_get	GET /api/agents/{id}	Liest einen Agenten samt Konfiguration.
agents_update	PUT /api/agents/{id}	Ändert Name, Typ oder Konfiguration.
agents_delete	DELETE /api/agents/{id}	Löscht einen Agenten.

Aktivitäten

Tool	Endpunkt	Zweck
activities_list	GET /api/activities	Liest die Timeline; alle Parameter optional (lead_id, activity_type, …).
activities_get	GET /api/activities/{id}	Liest eine einzelne Aktivität.
activities_create_note	POST /api/activities/note	Legt eine Notiz an (lead_id + content).
activities_create_call	POST /api/activities/call	Erfasst einen Anruf (lead_id + provider_call_id).

Lead-Status

Tool	Endpunkt	Zweck
lead_statuses_list	GET /api/lead-statuses	Listet die Statuswerte des Projekts.
lead_statuses_create	POST /api/lead-statuses	Legt einen Status an.
lead_statuses_update	PUT /api/lead-statuses/{id}	Ändert einen Status.
lead_statuses_delete	DELETE /api/lead-statuses/{id}	Löscht einen Status.

Anrufergebnisse

Die Beschreibung jedes Ergebnistyps und das Feld configuration.postCallPrompt des Agenten steuern, welches Outcome die KI nach einem Anruf setzt — nicht der Agent-Prompt. Siehe Post-Call-Outcomes.

Tool	Endpunkt	Zweck
call_outcomes_list	GET /api/call-outcomes	Listet die Ergebnistypen.
call_outcomes_create	POST /api/call-outcomes	Legt einen Ergebnistyp an.
call_outcomes_update	PUT /api/call-outcomes/{id}	Ändert einen Ergebnistyp.
call_outcomes_delete	DELETE /api/call-outcomes/{id}	Löscht einen Ergebnistyp.
activity_set_outcome	POST /api/activities/{id}/outcome	Ordnet einer Aktivität ein Ergebnis zu.
activity_clear_outcome	DELETE /api/activities/{id}/outcome	Entfernt die Zuordnung wieder.

Eigene Aktivitäten

Tool	Endpunkt	Zweck
custom_activity_types_list	GET /api/custom-activity-types	Listet die benutzerdefinierten Aktivitätstypen.
custom_activity_type_fields_list	GET /api/custom-activity-types/{id}/fields	Zeigt die Felder eines Typs samt Pflichtangaben.
custom_activities_create	POST /api/activities/custom	Erfasst eine eigene Aktivität an einem Lead.
custom_activities_get	GET /api/activities/custom/{id}	Liest eine eigene Aktivität.
custom_activities_update	PUT /api/activities/custom/{id}	Ändert eine eigene Aktivität.
custom_activities_delete	DELETE /api/activities/custom/{id}	Löscht eine eigene Aktivität.

Workflows

Tool	Endpunkt	Zweck
workflows_list	GET /api/workflows	Listet die Workflows des Projekts.
workflows_get	GET /api/workflows/{id}	Liest einen Workflow samt Definition.
workflows_create	POST /api/workflows	Legt einen Workflow an. name, definition, trigger_config erforderlich; enabled ist standardmäßig false (inaktiv, bis aktiviert).
workflows_update	PUT /api/workflows/{id}	Ändert einen Workflow. definition/trigger_config ersetzen den gespeicherten Wert vollständig — vorher workflows_get lesen.
workflows_delete	DELETE /api/workflows/{id}	Löscht einen Workflow.

definition und trigger_config sind JSON-Objekte. Vor dem Speichern prüft der MCP-Server die Graph-Struktur (bekannte Node-Typen, auflösbare Kanten) und lehnt fehlerhafte Definitionen ab, ohne das Backend aufzurufen. Ausführungs- und Debug-Tools (run, Läufe) sind bewusst nicht enthalten.

Fehlerverhalten

Der MCP-Server verändert Backend-Antworten nicht. Schlägt ein Aufruf fehl, erhält Claude ein Fehlerergebnis mit dem unveränderten HTTP-Status und Antworttext — zum Beispiel:

Backend returned 403: {"success":false,"message":"..."}

Ein solcher Fehler sollte nicht wiederholt, sondern gelesen werden: Er nennt den Grund (fehlende Berechtigung, Tarifgrenze, ungültige Eingabe). Ist das Backend gar nicht erreichbar, meldet der Server stattdessen einen Verbindungsfehler („unreachable").

Das vollständige Fehlermodell steht unter Fehler & Konventionen.