MCP-Tools: Integrationen

Diese Tools erscheinen in tools/list nur, wenn eine passende Integration verbunden ist (get_calendar_events ist nativ und immer verfügbar).

list_integrations

Aktive Integrations-Verbindungen. read · follower

Keine Parameter. Antwort: { connections[], count } (type, categories, status, connected_at).

get_calendar_events

Native Liza-Kalender-Events (eigene, Teilnahmen, zugängliche Kalender). read · user

Parameter	Typ	Default	Beschreibung
from	string (ISO)	–	Start des Zeitraums
to	string (ISO)	–	Ende des Zeitraums
query	string	–	Suche im Titel
limit	number (max 50)	20	Anzahl

CRM

Tool	Rolle	Parameter
search_crm_contacts	user	query?, limit?=20
get_crm_contact	user	contactId (erforderlich)
list_crm_deals	user	query?, limit?=20
list_crm_companies	user	query?, limit?=20

Tickets

Tool	Rolle	Parameter
list_tickets	user	query?, limit?=20
get_ticket	user	ticketId (erforderlich)

Messaging

Tool	Rolle	Parameter
list_messaging_channels	user	limit?=50
list_messaging_messages	user	limit?=20

Weitere

Tool	Rolle	Parameter
search_files (Storage)	user	query?, limit?=20
list_external_tasks	user	query?, limit?=20

unified_api_call

Generischer Aufruf an eine verbundene Integration (Unified.to) — für Kategorien oder Objekttypen, die kein spezifisches Tool abdeckt. admin

Parameter	Typ	Default	Beschreibung
integration_type	string (erforderlich)	–	z. B. hubspot, salesforce
category	string (erforderlich)	–	crm, ticketing, calendar, messaging, storage, task, …
object_type	string (erforderlich)	–	contact, company, deal, ticket, …
method	enum get|post|put|patch|delete	get	HTTP-Methode
path	string	""	Zusatzpfad (z. B. /{id})
data	object	–	Body oder Query-Parameter

Eigene Konnektoren

Fünf Tools für selbst gebaute Konnektoren — siehe Konnektoren. Sie brauchen den Pro-Tarif; die Funktion muss außerdem für die Umgebung freigegeben sein, sonst antworten sie mit feature_not_released bzw. upgrade_required.

Eine Definition ist JSON, kein Code: Feldzuordnungen, Vorlagen und Request-Beschreibungen. Ausgehende Aufrufe laufen über eine geschützte Fetch-Schicht (kein Zugriff auf private Adressen, Größen- und Zeitlimit).

Tool	Rolle	Zweck
list_connectors	user	Eigene Konnektoren samt Definition auflisten
test_connector	user	Beispiel-Payload durchspielen, ohne zu speichern oder zu senden
create_connector	admin	Konnektor anlegen
update_connector	admin	Definition vollständig ersetzen
call_connector_action	user	Eine Aktion des Konnektors ausführen

Reihenfolge

Die Tools sind aufeinander abgestimmt und in dieser Reihenfolge gedacht:

1. list_connectors — gibt es schon einen für diesen Dienst?
2. test_connector mit definition und sample_payload — welcher Eintrag aus inbound.events greift, und welcher Block entstünde? Eine Definition, die durch die Prüfung kommt, kann trotzdem auf die falschen Felder zeigen.
3. create_connector — legt ihn als Entwurf an. activate: true nur auf ausdrücklichen Wunsch: ein aktiver Konnektor empfängt sofort Ereignisse.

update_connector ersetzt, es führt nicht zusammen

Erst mit list_connectors den aktuellen Stand holen, ihn ändern und vollständig zurückschicken. Wer nur das geänderte Feld schickt, löscht den Rest der Definition.

call_connector_action

Parameter	Typ	Beschreibung
connector	string (erforderlich)	Kurzname (slug) des Konnektors, z. B. statuspage
action	string (erforderlich)	Kurzname der Aktion aus definition.actions
input	object	Werte für die Platzhalter, passend zum input_schema der Aktion
dry_run	boolean	true zeigt nur den Request, ohne ihn abzuschicken

Bei allem, was etwas verändert oder Geld kostet, erst dry_run zeigen und bestätigen lassen.