Lab · Projekt
Productive-Daten als Gespräch: der MCP Connector
Zwei Wochen · vom dokumentierten Zeitfresser bis Produktion
Ausgangslage: Die Antworten stecken im System, nur kommt niemand dran
Mit jedem neuen Kunden wuchs in Productive das, was irgendwann niemand mehr überblickt: Budgets je Kunde, offene Tickets, Kunden, die auf Antwort warten, fällige Follow-ups, geleistete Stunden, Upsell-Chancen. Jede dieser Fragen war beantwortbar – über eine eigene Klickstrecke durch Reports und Ansichten. Zusammen ergaben sie einen Zeitfresser, der jeden Tag zurückkam.
Der erste Schritt war deshalb kein Code. Ich habe den Zeitfresser dokumentiert und analysiert: Welche Fragen stellt das Team wirklich, wie oft, und wie viele Klicks kosten jede Antwort? Erst aus dieser Liste entstand das Werkzeug.
Konzept: bauen statt Tarif hochkaufen
Productive bietet einen eigenen MCP-Server an – allerdings erst im Ultimate-Tarif für 33 $ pro Person und Monat. Das Team arbeitete im Essential-Tarif für 10 $ (beides bei jährlicher Zahlung). Allein für den MCP-Zugang hätte das Upgrade 23 $ pro Platz und Monat gekostet – bei zehn Mitarbeitern 230 $ pro Monat.
Ich habe den Connector gebaut, statt den Tarif zu kaufen. Und der Eigene kann etwas, das ein Standard-Connector nicht kann: Er kennt unsere Fragen.
Architektur
Der Connector ist ein eigener MCP-Server, der als Cloudflare Worker läuft: TypeScript, neun rein lesende Werkzeuge gegen die JSON:API von Productive. Nichts wird installiert – der Worker läuft gehostet, die Anmeldung geht über den Browser, keine API-Keys auf einzelnen Rechnern.
Die Authentifizierung hat zwei getrennte Seiten. Nach außen ist der Worker sein eigener OAuth-Provider: Claude registriert sich über Dynamic Client Registration selbst, es gibt keine Client-ID zum Einfügen. Der Zugang der Agentur ist ein gemeinsames Team-Passwort auf dem Consent-Screen; die OAuth-Grants liegen in Cloudflare KV. Nach innen spricht der Worker mit einem read-only Servicetoken zu Productive – dieses Token verlässt den Server nie und ist für Claude nie sichtbar.
Rein lesend heißt: Der Connector schreibt nichts an Productive zurück und kann es auch nicht – im Code existiert schlicht kein einziger Schreib-Endpunkt. Eine versehentliche Änderung an Stunden, Tickets oder Budgets ist damit technisch ausgeschlossen. Gepflegt wird in Productive, nicht hier. Kein Upgrade, keine Lizenz, kein Anbieter dazwischen.
Der Weg einer Frage
Was das Team den Connector fragt
Der Nutzen hängt von der Rolle ab. Im Vertrieb lautet die häufigste Frage: „Womit hat dieser Kunde Schwierigkeiten?“ Die Antwort steckt längst in den Tickets. Zieht ein Kunde die Umsetzung seit Monaten hin, weil im Haus niemand weiß, wie die Änderungen auf die Website kommen, ist das kein Projektproblem – es ist ein Upsell. IT-Dienstleistung anbieten, Blocker auflösen.
Im Projektmanagement ersetzt der Connector die tägliche Klickstrecke durch vier Fragen: Welche Kunden haben geschrieben und warten auf eine Antwort und seit wann? Bei wem steht ein Follow-up aus, weil er sich nicht meldet? Was sind meine Aufgaben der Woche über alle Kunden hinweg? Und wie viele Stunden liefen diesen Monat pro Kunde auf? Auch der Monatsbericht entsteht so – mit konkreter Anbindung an die Tickets, als Audit: Was ist wirklich abgeschlossen, was nicht.
Zusammenfassung der Productive-Kommentare der letzten vier Wochen — Tickets, bei denen der Kunde zuletzt geschrieben hat und noch keine Antwort erfolgt ist:
Kunde A — 3 Tickets
- „Review Website-Analyse" · vor 4 Tagen: Rückfrage zu indexierten Subdomains; wartet auf konkrete Angaben.
- „Wettbewerbs-Vergleich" · vor 3 Tagen: Priorisierung der Vergleichsseiten geschickt.
- „Prompt-Optimierung" · vor 20 Tagen: eher abschließender Kommentar, keine dringende Frage.
Kunde B — 1 Ticket
- „Schema + Entitäten" · vor 11 Tagen: informiert über den Website-Relaunch, wartet auf Bestätigung.
Kunde C — 4 Tickets, seit 12 Tagen offen: Feedback zu Anpassungen, Brand-Voice-Guide, Stundenaufteilung und Kampagnenstart — alle warten auf Rückmeldung.
Am längsten offen ist der Block von Kunde C (12 Tage). Soll ich Antwortentwürfe vorbereiten?
Und für alle, die mit Kunden arbeiten: ein Daily Briefing. Eine Frage am Morgen: Was steht heute bei welchem Kunden an? Auch der wöchentliche Auslastungstermin läuft über dieselben Daten: Wer ist nächste Woche wie verplant, welches Budget kippt, wo fehlen Stunden.
Die neun Werkzeuge
Jedes Werkzeug ist ein rein lesender Aufruf gegen einen JSON:API-Endpunkt von Productive (https://api.productive.io/api/v2). Die Namen und Filter sind so geschnitten, dass ein Sprachmodell sie ohne Doku trifft.
| Werkzeug | Endpunkt | Wesentliche Filter |
|---|---|---|
list_projects | /projects | company_id, status |
get_project | /projects/{id} | ein Projekt inkl. Firma und Projektleitung |
list_tasks | /tasks | project_id, assignee_id, status, due_date |
list_time_entries | /time_entries | project_id, person_id, after, before (Zeit in Minuten) |
list_people | /people | company_id, status |
list_companies | /companies | status |
list_deals | /deals | company_id, project_id (Deals und Budgets) |
list_comments | /comments | task_id, project_id, company_id, since, full_text |
list_bookings | /bookings | person_id, project_id, after, before (Kapazitätsplanung) |
Die Beschreibung, die jedes Werkzeug mitliefert, ist selbst schon Anleitung. list_comments trägt sie im Klartext: „newest first … um Tickets zu finden, die auf eine Antwort warten: nimm den neuesten Kommentar je Task und behalte die, bei denen author_is_client true ist.” Die Logik steckt im Werkzeug, nicht in einem separaten Systemprompt.
Kontext sparen: aus 90.000 Tokens werden Kilobytes
Productive liefert je Ressource rund 40 Attribute per Default – Navigationseinstellungen, Custom-Field-IDs, Avatar-URLs, Sync-Flags. Eine einzige ungefilterte Seite Kommentare kam so auf rund 90.000 Tokens: langsam, und es treibt das Modell in Überlauf-Fehler.
Drei Schnitte lösen das, alle im Code, keiner am Modell:
- Sparse Fieldsets. Mitgeladene Relationen werden auf das reduziert, was als Kontext reicht – eine Firma braucht ihren Namen, nicht ihr halbes Profil. Die Ressource, um die es in der Frage geht, behält alle Felder.
- Kommentar-Preview. Kommentar-Bodies sind ProseMirror-HTML mit inline-eingebetteten @-Mentions als JSON-Blobs. Der Connector macht daraus reinen Text (
@Michael Luustatt Blob), wirft die Auszeichnung weg und kürzt auf 600 Zeichen – genug, um zu sehen, wer auf eine Antwort wartet. Der längste Kommentar im Live-Datenbestand hat 12.000 Zeichen; voll braucht ihn fast nie jemand. - Seitengröße 30. Der Default hält die CPU-Zeit des Workers unter den 10 ms des Free-Tiers.
// Relationen tragen nur Kontext – ein Name genügt.
const RELATION_FIELDS = {
people: 'first_name,last_name,email,title,company',
companies: 'name',
projects: 'name,number,archived_at',
tasks: 'title,due_date,closed_at,task_number,project',
}
// Achtung: fields[type] filtert auch Relationen, nicht nur Attribute.Wer ist Kunde, wer ist Kollege
Productive markiert nicht, wer Kunde und wer Kollege ist. Die Felder external, employee und person_type sind bei allen 148 Personen im System leer. Der einzige verlässliche Marker ist die Firma, zu der eine Person gehört. Der Connector leitet die Unterscheidung deshalb daraus ab – jeder Kommentar bekommt ein author_is_client:
// external/employee/person_type sind alle null – die Firma ist der einzige Marker.
author_is_client: company ? String(company.id) !== ownCompanyId : nullDamit wird aus „alle Kommentare” die eigentliche Frage beantwortbar: Wo hat zuletzt der Kunde geschrieben und wartet auf uns?
Kommentare ohne Datumsfilter
Kommentare lassen sich über die API nicht nach Datum filtern – Productive nimmt den Filter nicht an. Der Connector blättert deshalb von neu nach alt (sort=-created_at), schneidet das Zeitfenster (since) selbst und stoppt, sobald er unter die Grenze fällt. Gedeckelt ist das bei fünf Seiten – ein normaler Tag hat etwa 17 Kommentare, und der Free-Tier-Worker hat 10 ms CPU, um sie zu verarbeiten. Genau daraus ergibt sich die Frage, die vorher niemand beantworten konnte: Wo wartet ein Kunde seit gestern auf uns?
Übergreifend fängt der Client die üblichen Störungen ab: Auf 429 und 5xx wartet er die vom Server genannte Retry-After-Zeit ab (sonst exponentiell) und versucht es bis zu viermal erneut, statt die Session abreißen zu lassen.
Sicherheit: was garantiert ist – und was nicht
Nur Prüfbares, jedes an den Code gebunden:
- Read-only by construction. Schreiben ist nicht „per Einstellung verboten”, sondern es existiert kein Schreibcode. Auch eine manipulierte oder per Prompt-Injection gekaperte Session kann nichts ändern, anlegen oder löschen.
- Zero Retention. Geschäftsdaten werden nirgends gespeichert – nicht in KV, nicht in Logs, nicht im Cache. In KV liegen nur die OAuth-Grants; die Antwort geht als Durchreiche direkt zurück.
- Kill switch beim Kunden. Wird das read-only Servicetoken in Productive widerrufen, ist der Connector im selben Moment blind – ohne uns.
- Secrets außerhalb des Codes. Token und Passwort liegen im Cloudflare-Secret-Store, nicht im Repository und nicht in Logs. Gehostet auf Cloudflare (SOC 2, ISO 27001), TLS auf jedem Schritt.
Was ich nicht verspreche: Das KI-Modell verarbeitet die Antworten unter den Bedingungen des jeweiligen Anbieters. Auf Claude Team/Enterprise und den Business-Plänen von ChatGPT trainieren die Anbieter nicht auf euren Daten – die Wahl des Plans ist eure Seite des Vertrags.
Selbst bauen vs. Productive-Ultimate-MCP
| Kriterium | Eigener Connector | Productive Ultimate |
|---|---|---|
| Preis | ~0–5 $/Monat gesamt (Cloudflare Worker) | 33 $ pro Person / Monat |
| Auf die eigenen Fragen zugeschnitten | ja (author_is_client, Zeitfenster, Kontext-Schnitt) | generischer Funktionsumfang |
| Kontext-/Token-Kosten | aktiv reduziert (Sparse Fields, 600-Zeichen-Preview) | volle Payloads |
| Hosting | selbst, Cloudflare Worker | beim Anbieter |
| Schreibzugriff | keiner (read-only by construction) | vom Anbieter definiert |
| Kontrolle | Kill switch über das Servicetoken | Anbieterkonto |
Was es kostet
Der Bau ersetzt eine laufende Tarifgebühr durch fast fixe Infrastruktur. Der Worker läuft im Free-Tier; Workers Paid für 5 $ im Monat nimmt den 10-ms-CPU-Deckel weg – für das ganze Team, nicht pro Platz.
| Teamgröße | Ultimate-Upgrade (23 $/Platz) | Eigener Connector | Ersparnis / Monat |
|---|---|---|---|
| 5 | 115 $ | ~5 $ | ~110 $ |
| 10 | 230 $ | ~5 $ | ~225 $ |
| 25 | 575 $ | ~5 $ | ~570 $ |
| 50 | 1.150 $ | ~5 $ | ~1.145 $ |
Wann der Connector nicht passt
- Wer schreiben will. Stunden loggen, Tasks anlegen oder ändern – das geht hier bewusst nicht. Dafür ist Productive selbst da.
- Echtzeit-Benachrichtigungen. Der Connector antwortet auf Fragen (Pull), er schickt keine Push-Meldungen.
- Teams ohne LLM im Alltag. Das Werkzeug ist nur so nützlich wie die Fragen, die jemand stellt. Ohne Claude oder ein anderes Modell im Tagesgeschäft bringt es nichts.
Warum erst nur lesen – und wann geschrieben wird
Read-only war kein Zwischenschritt, sondern die stärkste verfügbare Garantie: Was es nicht gibt, kann nicht missbraucht werden. Deshalb existiert im Code kein Schreibpfad, statt einen zu bauen und abzusichern.
Ein späterer Schreibzugriff hat eine klare Bedingung: einen menschlichen Freigabeschritt. Denkbar sind Antwortentwürfe für Tickets, die ein Mensch prüft und absendet – nie ein autonomes Schreiben. Bis das mit derselben Sorgfalt steht wie die Lese-Seite, bleibt der Connector, was er ist: ein Leser.
Vom internen Werkzeug zum Produkt
Von der Analyse des Zeitfressers bis zum Produktionsbetrieb vergingen zwei Wochen, Test inklusive. Für das Agenturteam läuft der Connector seitdem kostenlos als internes Werkzeug.
Inzwischen ist daraus ein Produkt geworden, das auch anderen Agenturen offensteht, die mit Productive zusammenarbeiten. In der Produktfassung bringt jeder Kunde sein eigenes read-only Servicetoken mit: Der Umfang, den der Connector sieht, wird von der Rolle dieses Servicenutzers in Productive bestimmt – der Kunde behält die Kontrolle, ohne je ein Mitarbeiterpasswort herauszugeben.
Am meisten bringt der Connector Teams, die so arbeiten wie wir damals: 10 bis 30 Leute im Essential- oder Professional-Tarif, und Claude ist bereits im Alltag. Wer vor allem Stunden loggen oder Tasks anlegen will, braucht ein anderes Werkzeug – dieses hier liest nur.
Am Anfang stand eine dokumentierte Liste von Fragen, die täglich Klicks kosteten. Zählen Sie Ihre eigenen: Welche Frage beantworten Sie jede Woche von Hand, obwohl die Daten längst im System liegen? Schreiben Sie mir.