Alle reden über MCP: Lektionen von Entwicklern bei Miro, Atlassian und darüber hinaus

Nachfolgend finden Sie ein bearbeitetes Transkript des Gesprächs. Zitate wurden zur besseren Verständlichkeit leicht gekürzt. 

APIs gibt es schon ewig. Was ermöglicht MCP tatsächlich, was APIs nicht konnten?

Gunjan: Früher musste man die API für jedes Tool verstehen, die ohnehin knappen Entwicklerressourcen einsetzen, um diese verschiedenen Integrationen zu bauen, und wenn sich eine Anforderung änderte – zum Beispiel, wenn man statt nur etwas zu lesen auch etwas schreiben musste – ging man zurück, nahm die Änderung vor und wartete sechs Wochen. Das war der Zyklus: langsam und teuer.

Mit MCP werden Server von den Anbietern selbst bereitgestellt, und man drückt einfach seine Absicht aus. Die Geschwindigkeit beim Entwickeln wird dadurch enorm beschleunigt. Man entfernt sich davon, spezifische Aufrufe für eine Aktion zu definieren, und beschreibt stattdessen, was man möchte. Genau dort wird die Agent-Orchestrierung – also die eigentliche Zuweisung von Aufgaben an Agenten – möglich. Ohne das war es schlicht unmöglich.

Kosta: APIs verbinden Tools, aber jemand muss trotzdem noch klicken und alles zusammenführen. MCP ermöglicht es Agenten, Kontext über Tools hinweg zu lesen und darin zu agieren – in einem Ausmaß, das kein Einzelner erreichen könnte.

Was haben Sie konkret mit MCP gebaut, und was leistet es?

Michelle: Ich habe ein Triage-System gebaut, das den Pendo MCP mit den übrigen Organisationsdaten meiner Organisation verbindet. Es ist mein tägliches Morgen-Briefing. Was muss ich wissen, bevor ich mit jemandem spreche? Welche Session-Replays sind am wichtigsten, bevor ich mir überhaupt welche anschaue? Was ist gestern passiert?

Es zeigt mir, was bestimmte Personen getan haben, basierend auf einer Gruppe, die ich rund um unsere Customer-Success-Manager eingerichtet habe. Es markiert Standardaktivitäten, potenzielle Probleme, Datenpitzen, verschiedene Volumina sowie Erfolge, die es zu feiern gilt. Ich kann es auch fragen, welche Sessions ich ansehen sollte, bevor ich mich an CSMs wende. Es hebt Dinge hervor wie: intensive Content-Review-Sessions, viele Rage-Clicks und Dead-Clicks, erhebliche Frustrationsereignisse sowie Power-User in einem kurzen Erstellungsworkflow. Das ist das Morgen-Briefing eines Product Directors – in einem Agenten gebaut und täglich automatisch ausgeführt.

Kosta: Wir haben ein Transkript eines Kundengespräches in Claude eingespeist und direkt auf dem Miro-Board ein PRD generiert. Von dort aus haben wir einen User-Flow erstellt, Referenz-Screenshots hinzugefügt und Notizen festgehalten – alles in einem gemeinsamen Bereich. Nachdem das Team sich abgestimmt hatte, habe ich die Board-URL in Claude Code eingegeben. Der MCP verstand den Kontext und generierte einen funktionierenden Prototypen, der das widerspiegelte, worauf wir uns geeinigt hatten. Wir haben ihn noch am selben Tag den Stakeholdern präsentiert und mit dem Kunden validiert. Vor einem Jahr war diese Art von Geschwindigkeit nicht möglich. Heute kann jeder innerhalb weniger Stunden von einem Kundenproblem zu einer abgestimmten Lösung gelangen.

Gunjan: Als PMs jonglieren wir mit vielem, und eine der wichtigsten Aufgaben ist es zu wissen, was Kunden anfragen: was ihnen gefällt, was nicht, wie sie das Produkt nutzen und was in aktuellen Verkaufsgesprächen passiert. Diese Recherche dauerte früher Stunden. Ich habe einen Agenten in Rovo gebaut. Ich habe ihm Zugriff auf mein Sales-Tool, Google Docs, Kalender, GitHub, Jira-Tickets, Confluence-Seiten, Meeting-Notizen, Hotspot-Leads gegeben. Wenn ich ihn bitte, mir bei der Vorbereitung auf ein bevorstehendes Meeting zu helfen, nutzt er all diese Tools und erstellt in Minuten einen umfassenden Bericht. Dinge, die mich früher Stunden gekostet haben, dauern jetzt Minuten, und ich betrete den Raum deutlich selbstsicherer.

Was haben Sie beim Aufbau Ihres ersten MCP-Servers falsch gemacht?

Francois: Wir haben einen großen Fehler gemacht: Wir haben die Tools als sehr niedrigschwellige Primitive bereitgestellt. Wir sagten: Wenn du eine Frage hast, ruf diesen Endpunkt auf und übergib deine Frage. Wenn du deine Frage umformulieren möchtest, nutze diesen Endpunkt zur Umformulierung. Das Problem war, dass wir dem LLM zu viel Macht gegeben haben. Das Modell entschied dann, wann es welches Tool verwendet, und tatsächlich neigen sie dazu, kein Tool zu verwenden. Wenn die Dinge intelligent sind, sagen sie: "Weißt du was, ich kann das selbst herausfinden."

Wenn du zum Beispiel fragst "Zeig mir meine Top-10-Kunden", ist das sehr vage. Das LLM würde einfach seine eigene Definition finden und Spotter aufrufen, um die Antwort zu erhalten. Und wenn du dieselbe Frage zweimal stellst, bekommst du möglicherweise eine andere Antwort. Es halluzinierte in dem Sinne, dass es "Top" basierend auf dem definierte, was es für einen Bankdatensatz am relevantesten hielt: manchmal Sparkonto, manchmal Kreditkonto. 

Wir stellen jetzt Tools bereit, die die gesamte Intelligenz mitbringen. Wir lassen Claude nicht seine eigene Intelligenz einbringen, weil wir unsere Daten kennen und mehr Kontext haben als das Modell. Wir steuern es über unsere semantische Schicht, sodass du bei jeder Frage dieselbe Antwort erhältst, die auf dem gesamten Kontext basiert, den wir haben.

Michelle: Genau deshalb habe ich alle SQL-Abfragen in meiner Anweisungsschicht verwendet. Das sind die Definitionen. Das bedeutet es, in unseren Daten "Top" zu sein. Die abfragenden Personen wissen nicht immer, welches genaue Wort sie verwenden sollen oder wie der Feldname lautet, daher war dieses Maß an Erklärung für unsere internen Daten notwendig.

Wie haben Sie entschieden, was Sie zuerst bereitstellen – und wie entscheiden Sie, was Sie nicht bereitstellen?

Kosta: Es gibt keine Einheitslösung. Bei Miro haben wir mit validierten Anwendungsfällen begonnen und strategisch eingegrenzt, worauf wir uns konzentrieren wollten. Als wir den MCP-Server aufgebaut haben, waren es vor allem Entwickler, die ihn am meisten nutzten. Also haben wir uns auf Engineering-Workflows konzentriert, insbesondere auf das Problem, dass Agenten Tausende von Codezeilen schreiben und es sehr schwer ist zu visualisieren, was sie tun, um sie zu steuern. Wir haben uns darauf konzentriert und darauf, wie man die Absicht des Teams aufnimmt und an die Code-Generierung weitergibt. Das hat uns davor bewahrt, zu früh zu breit aufzustellen, was sowohl die Agenten als auch unsere Go-to-Market-Botschaft verwirrt hätte.

Michelle: Wir haben mit einem einzigen Agenten begonnen und uns von dort aus weiterentwickelt. Wir haben auch mit dem angefangen, was am einfachsten und vertrauenswürdigsten war. Wir wollten sicherstellen, dass die Nutzer dem Tool vertrauen, bevor wir sagten: "Wir werden das von Anfang bis Ende für Sie übernehmen." Wir möchten, dass der Nutzer weiterhin das Steuer in der Hand hat und Leitplanken vorhanden sind, bevor wir sagen, dass wir all diese Aufgaben automatisch erledigen können. Das war der langsame Wachstumsprozess.

Francois: Man muss wirklich darüber nachdenken, wo man Intelligenz einsetzen möchte. Möchte man an das LLM delegieren? In manchen Fällen ist das perfekt. Aber in unserem Fall, weil die Daten so sensibel sind, mussten wir es andersherum gestalten. Es geht um viel mehr als MCP an sich. Es geht wirklich darum, die agentische Seite davon einzubetten.

Was das Nicht-Bereitstellen betrifft, führt das zurück zur semantischen Schicht. Dort legen Sie fest, welche Tabellen Sie bereitstellen möchten und wer das Recht hat, was zu tun. In der alten Welt war das Dashboard die Leitplanke. Ein Analyst kontrollierte, welche Visualisierungen auf das Dashboard kamen. Da Dashboards nun verschwinden und die Menschen direkt mit den Daten sprechen möchten, wird die semantische Schicht zum neuen Kontrollpunkt.

Wie bringen Sie Ihr Team dazu, seine Arbeitsweise tatsächlich zu ändern?

Kosta: Es läuft auf zwei Dinge hinaus. Erstens das Mandat: Es liegt nicht einmal nur an mir. Die Unternehmensführung muss entscheiden, dass es wichtig ist. Bei Miro ist allgemein bekannt, dass wir die Akzeptanz beschleunigen wollen, besonders angesichts der Geschwindigkeit, mit der sich der Markt bewegt. Aber ein Mandat allein reicht nicht aus. Deshalb investieren wir auch viel in Enablement. Wir haben KI-Produktgilden, Slack-Kanäle, in denen Menschen voneinander lernen können, und Live-Sessions. Als Führungskräfte müssen wir auch das Verhalten vorleben. Ich code mal eben einen Prototyp und bespreche ihn mit meinen direkten Mitarbeitern. Sie lassen sich inspirieren – und oft sind sie diejenigen, die mich inspirieren. Sie sind nah am Geschehen. Sie bauen wirklich erstaunliche Dinge.

Gunjan: Wir müssen diesen Tools wirklich eine Chance geben. Erklären, was wir von ihnen wollen, und glauben, dass sie es schaffen werden. Die Modelle von heute schaffen es vielleicht nicht vollständig, aber die Modelle von morgen werden es definitiv tun. Also war ein Vertrauensvorschuss, das Ausprobieren ohne den Anspruch auf Perfektion, das Ziel. Und man muss immer wieder zurückkehren und es versuchen. Heute ist Claude Code wirklich gut. Morgen könnte etwas anderes besser sein. Alle sechs Monate sollte man zu diesen Tools zurückkehren und sie ausprobieren, weil sie vielleicht etwas freigeschaltet haben, was sie vorher nicht konnten.

Wie sieht Erfolg für Ihr MCP-Tooling aus? Was ist die Nordstern-Metrik?

Gunjan: Sehr bald, denke ich, werden wir aufhören, zwischen einem Benutzer und einem KI-Benutzer zu unterscheiden. Es geht hauptsächlich um Workflows. Wie viele Sie betreiben und wie sie sich beschleunigen. Ein Team, das 100 Tickets abarbeitet und fünf Scrums pro Monat abhält, wobei Agenten täglich 100 PRs schreiben, möchte wahrscheinlich täglich einen Scrum, um zu verwalten und zu kontrollieren, was passiert. Ihr KPI wird: Anzahl der in Ihren Systemen orchestrierten Workflows, unabhängig davon, wo das Frontend dieser Erfahrung liegt.

Kosta: Wir betrachten es wie jedes andere Produkt. Wir sehen nichtlineares Wachstum bei der MCP-Akzeptanz, sowohl in Bezug auf die Anzahl der Nutzer als auch auf die Nutzungsintensität. Aber wir versuchen wirklich, die Workflows zu verstehen. Wofür nutzen die Leute es? Sind sie erfolgreich? Kehren sie zurück, um es für diese Workflows erneut zu nutzen? Wir sehen jetzt echte Bindung, besonders bei Dingen wie der Code-Visualisierung. Wir schauen uns immer noch an, wie die Leute Miro insgesamt nutzen, nicht nur MCP. Es ist beides.

Wenn Nutzer Mehrwert aus Ihrem Produkt ziehen, ohne jemals Ihre Benutzeroberfläche zu öffnen, was bedeutet das für Ihr Unternehmen?

Kosta: Ich würde das umdrehen. Wenn Agenten die Arbeit erledigen, wohin gehen Teams, um sie zu verstehen und zu steuern? Die meisten KI-Tools sind eine Black Box. Wir denken viel darüber nach, wo man hingeht, um diese Agenten auszurichten, wie man sicherstellt, dass sie das Richtige tun. Für uns ist das eine Chance, keine Bedrohung. Miro wurde für die Zusammenarbeit im Team entwickelt. Das ändert sich nicht. Das Team ist nur größer geworden.

Gunjan: Ihr Burggraben ist das, was Sie aufbauen. Wenn jemand anderes Ihr Produkt schneller neu aufbauen kann, als Sie es verteidigen können, dann ja, überdenken Sie es. Aber wenn Sie Ihren Burggraben verdoppeln und sagen können: "Das ist der Grund, warum die Leute unser Produkt nutzen, und das ist das beste Ergebnis für sie", können Sie sich wirklich fokussieren. Kundenorientierung gibt Ihnen das Recht, Ihre Kunden zu bitten, bei Ihnen zu bleiben. Wenn sie mit dem zufrieden sind, was Sie bieten, werden sie es tun.

Francois: Für uns als Analyse-Tool ist die Benutzererfahrung äußerst wichtig. Man muss in der Lage sein, tiefer zu gehen, zu visualisieren, Dinge zu ändern. Das Schöne an MCP-Apps ist, dass man nicht mehr wählen muss. Power-User können immer noch tief in das Produkt eintauchen. Business-User können eine Frage stellen und direkt in ihrem Agenten ein Diagramm erhalten. Es ist Koexistenz, kein Wettbewerb.

Wie entwickelt sich die Produktmanagement-Funktion tatsächlich?

Michelle: Ich würde gerne aufhören, Jira-Stories zu schreiben – und tatsächlich schreibt KI inzwischen viele davon für mich. Aber man braucht immer noch das Denkvermögen. Was besser wird: weniger Nacharbeit, weniger Bugs, weil der Kontext erhalten bleibt und was man beim letzten Mal übersehen hat, wird man beim nächsten Mal nicht übersehen. Wir verbringen nicht mehr so viel Zeit mit Spikes. Wie viel Zeit haben wir damit verbracht, API-Dokumentation zu lesen, um herauszufinden, ob etwas überhaupt möglich ist? Innerhalb von fünf Minuten bekommt man diese Antwort. Vielleicht keine Spikes mehr.

Kosta: Agenten übernehmen immer mehr die Ausführung und die kleinteilige Arbeit. Aber das eigentliche PM-Handwerk (die Problemformulierung, die Abstimmung, die Kommunikation) ist wichtiger denn je. Man möchte nicht, dass Agenten unkontrolliert agieren und entscheiden, was gebaut wird. Niemand will diese Welt. Daher müssen Produktverantwortliche mehr Verantwortung übernehmen und stärker über das Handwerk nachdenken: Problemformulierung, Kontextkuration. Die Rolle verlagert sich weg von der Ausführung hin zu Aktivitäten mit größerem Hebel.

Gunjan: Die Hürden, die Menschen früher zurückgehalten haben: „Ich kann keinen Code schreiben", „Ich verstehe die Syntax nicht" – die sind verschwunden. Daher ist die Problemidentifikation in der neuen Ära von großer Bedeutung. Das Verbinden von Punkten ist ebenfalls entscheidend. KI wird diese Punkte nicht für Sie verbinden. Sie müssen erkennen, welches Problem gelöst werden soll, welches Problem existiert. Und Geschmack ist eine sehr schwer zu entwickelnde Fähigkeit, die sich nicht verändert hat. Es spielt keine Rolle, welche Technologie kommt und geht. Zeit damit zu verbringen zu verstehen, was gut ist – in einer Erfahrung oder einem Produkt – das ist nach wie vor von großer Bedeutung.

Bereit, mit Pendo MCP loszulegen? Schauen Sie sich an unsere Prompt-Bibliothek, und kostenlos einrichten.