monday.com bringt inzwischen eine ganze Reihe eigener AI-Funktionen mit – AI Blocks auf Spaltenebene, einen Assistenten im Workspace, Agenten, die Aufgaben übernehmen. Für viele Standardfälle reicht das vollständig aus, und der schnellste Weg ist dann, genau das zu nutzen.
Interessant wird es dort, wo es nicht reicht: wenn ein Ablauf eure eigene Logik braucht, mehrere Systeme berührt oder ein Ergebnis in einer Form liefern muss, die kein fertiger Baustein kennt. Dann gibt es drei Wege, Claude und monday.com zu verbinden. Sie unterscheiden sich stark in Aufwand und Einsatzzweck und werden regelmässig verwechselt.
Weg 1: Der Claude-Connector – der Mensch fragt
Seit 2025 gibt es einen offiziellen Connector, mit dem Claude direkt auf monday.com zugreifen kann. Die Anmeldung läuft über OAuth, bestehende Berechtigungen werden respektiert, und die Freigabe erfolgt durch eure Administration über den Marketplace. Vorausgesetzt wird ein Claude-Plan ab Pro aufwärts.
Im Alltag heisst das: Jemand fragt im Chat «Was ist bei Projekt Meier noch offen?» oder «Fasse mir zusammen, welche Deals diesen Monat auf Verhandlung stehen» – und bekommt die Antwort aus dem Board, ohne selbst durch Ansichten zu klicken.
Aufwand: minimal. Freigabe durch die Administration, Anmeldung durch die Nutzerinnen und Nutzer, fertig. Keine Entwicklung.
Grenzen: Das ist reaktiv. Es passiert nur, wenn jemand fragt. Für wiederkehrende Abläufe bringt es nichts.
Wann sinnvoll: fast immer als Einstieg. Wer monday.com und Claude im Haus hat, sollte diesen Weg aktiviert haben, bevor über irgendeine Entwicklung nachgedacht wird.
Weg 2: Der monday MCP-Server – Claude arbeitet selbst
monday.com betreibt einen offiziellen MCP-Server. Über ihn stehen mehr als sechzig Werkzeuge zur Verfügung – Boards, Items, Spalten, Dokumente, Dashboards, Workflows, Nutzerverwaltung, Suche, bis hin zu direkten Datenbankabfragen.
Der Unterschied zu Weg 1 liegt in der Tiefe. Hier kann Claude eine mehrstufige Aufgabe eigenständig durcharbeiten: relevante Items suchen, Details nachladen, etwas zusammenstellen, ein Dokument anlegen. Das eignet sich für Aufgaben wie «bereite das Wochen-Update für die Geschäftsleitung vor» – ein Ablauf, der in Einzelschritten zerfällt, die vorher niemand exakt festlegen kann.
Aufwand: gering bis mittel. Der Server existiert, muss aber konfiguriert und freigegeben werden. Die eigentliche Arbeit steckt darin, festzulegen, welche Werkzeuge zur Verfügung stehen sollen – und welche bewusst nicht.
Grenzen: Jeder Aufruf zählt auf euer API-Limit. Eine agentische Aufgabe mit dreissig Abfragen ist spürbar. Und der Server arbeitet mit den Rechten der angemeldeten Person: Wenn in eurem Account historisch alle alles sehen, sieht Claude ebenfalls alles.
Wann sinnvoll: sobald regelmässig Aufgaben anfallen, die mehrere Schritte über mehrere Boards brauchen.
Weg 3: Der HTTP-Request-Block – das Board löst aus
Der dritte Weg dreht die Richtung um. Statt dass ein Mensch Claude fragt, löst ein Ereignis im Board die Verarbeitung aus. Dafür gibt es im AI Workflow Builder einen HTTP-Request-Block, der GET-, POST- und PUT-Anfragen an beliebige Adressen schicken kann, mit eigenen Headern und Authentifizierung über die Credentials-Verwaltung.
Damit lässt sich die Anthropic-API direkt aus einem Workflow aufrufen. Beispiel: Ein Item wechselt auf «Prüfen», der Workflow schickt die Beschreibung an die API, das Ergebnis landet als Spaltenwert zurück im Item. Niemand muss etwas anstossen.
Aufwand: mittel. Der Block selbst ist schnell konfiguriert, aber ihr braucht einen API-Zugang, sauberes Fehlerhandling und eine Vorstellung davon, was passiert, wenn die Antwort einmal nicht kommt. Die AI-Workflow-Funktionen setzen ausserdem einen Pro- oder Enterprise-Plan voraus.
Grenzen: Hier entstehen laufende Kosten pro Aufruf, und es gibt keinen Menschen, der zwischendrin schaut. Für Ergebnisse, die direkt nach aussen gehen, ist das die falsche Konstruktion – für interne Vorarbeit die richtige.
Wann sinnvoll: wenn derselbe Handgriff wöchentlich anfällt und das Ergebnis intern weiterverarbeitet wird.
Wo es in der Praxis bricht
Drei Dinge, die in Projekten regelmässig auftauchen und die man vorher wissen sollte.
Rate Limits. Ein Workflow, der bei jeder Statusänderung feuert, produziert bei einem Massen-Import plötzlich hunderte Aufrufe. Baut eine Bedingung ein, die das begrenzt, und rechnet den Spitzenfall durch – nicht den Normalfall.
Fehlende Fehlerbehandlung. Wenn die API einmal nicht antwortet, bleibt das Feld leer und niemand merkt es, weil ein leeres Feld unauffällig ist. Definiert einen sichtbaren Fehlerzustand, etwa einen eigenen Status.
Wartung bei Produktänderungen. monday erweitert seine AI-Funktionen schnell, und Bezeichnungen ändern sich. Was heute ein eigener Workflow ist, kann in sechs Monaten eine Standardfunktion sein. Prüft zweimal jährlich, ob eure Eigenbauten noch nötig sind – das ist gesparter Wartungsaufwand.
Was wir empfehlen
Die Reihenfolge ist fast immer dieselbe. Zuerst die nativen monday-AI-Funktionen nutzen, wo sie passen – sie sind bereits bezahlt und brauchen keine Wartung. Dann den Claude-Connector freigeben, weil er ohne Entwicklungsaufwand sofort Nutzen bringt. Erst wenn beides an Grenzen stösst, lohnt sich der Aufbau eigener Verbindungen über MCP oder den HTTP-Block.
Übrigens setzt monday.com laut eigener Information mehrere Anbieter für seine AI-Funktionen ein, darunter auch Claude-Modelle. Für euch als Anwender ist das vor allem in einem Punkt relevant: Es ist kein Entweder-oder zwischen den beiden Welten.
.svg)