Kollabe
Rückschauen
Planungspoker
Standups
Eisbrecher
Preise
Armaturenbrett

Beiträge

Was ist MCP? Das Model Context Protocol erklärt für agile Teams

Moderne redaktionelle Illustration eines Entwicklers am Laptop mit durchscheinenden Verbindungslinien, die von einem Chatfenster zu stilisierten Symbolen für ein Backlog-Board, ein Planning-Poker-Deck und ein Retro-Board fließen und einen KI-Assistenten darstellen, der echte Tools über einen Sprint-Workflow hinweg orchestriert
Kelly Lewandowski

Kelly Lewandowski

Zuletzt aktualisiert am 27/04/20269 Min. Lesezeit

Wenn du Claude, Cursor oder ChatGPT in den letzten Monaten benutzt hast, ist dir MCP wahrscheinlich in den Einstellungen aufgefallen, ohne dass es groß erklärt wurde. Anthropic hat die Spezifikation Ende 2024 veröffentlicht, die großen Coding-Assistenten haben 2025 nach und nach Support eingebaut, und Anfang 2026 rast jedes SaaS-Tool mit einer API darum, einen MCP-Server zu veröffentlichen. Die Kurzfassung: MCP ist der Weg, wie ein KI-Assistent aufhört, ein Chatbot zu sein, und anfängt, ein Teammitglied zu werden, das echte Arbeit in deinen Tools erledigt. Für agile Teams, die ohnehin den ganzen Tag in Jira, GitHub, Linear und Slack stecken, ist das ein größerer Sprung, als es klingt.

Was MCP wirklich ist

Das Model Context Protocol (MCP) ist ein offener Standard, ursprünglich von Anthropic veröffentlicht, der definiert, wie ein KI-Assistent mit einem externen System spricht. Statt dass jeder KI-Anbieter eine Einzellösung für jedes SaaS-Tool baut, veröffentlicht das Tool einen einzigen MCP-Server, und jeder kompatible Client kann ihn nutzen. Du kannst es dir wie USB-C für KI-Tools vorstellen. Der Host (Claude Desktop, Cursor, ChatGPT, deine IDE) spricht dasselbe Protokoll mit jedem MCP-Server, auf den er gerichtet ist – so wie jedes USB-C-Kabel mit jedem USB-C-Port funktioniert.
MCP-Server
Ein Programm (üblicherweise vom SaaS-Anbieter betrieben), das eine Liste von Tools bereitstellt, die eine KI aufrufen kann, plus Auth und Transport für diese Aufrufe.
MCP-Client
Die KI-App, die den Server konsumiert. Claude Desktop, Cursor, Zed, ChatGPT und Claude Code bringen heute alle MCP-Clients mit.
Tool
Eine einzelne benannte Aktion mit einem JSON-Schema. Dinge wie retro_create_item, planning_poker_cast_vote oder standup_submit_answers.
Resource
Ein Stück Kontext, das der Server zurückgeben kann, etwa eine Datei, ein Board oder eine Sprint-Zusammenfassung. Das Modell kann diese lesen, ohne eine Aktion auszulösen.
Wenn ein Nutzer den Assistenten anspricht, entscheidet das Modell, welche Tools aufgerufen werden, der Client führt diese Aufrufe über MCP aus, der Server lässt sie gegen die zugrundeliegende API laufen, und die Ergebnisse fließen zurück in die Konversation. Der Nutzer sieht eine einzige Antwort. Im Hintergrund sind irgendwo zwischen einem und ein paar Dutzend Tool-Aufrufen passiert.

Wie sich MCP von einer REST API oder einem Webhook unterscheidet

Agile Tools haben seit über einem Jahrzehnt REST APIs und Webhooks. Warum braucht es also MCP überhaupt? Die Antwort: REST APIs und Webhooks sind für Entwickler gedacht, nicht für Modelle. Sie setzen voraus, dass ein Mensch die Doku liest, entscheidet, was aufzurufen ist, Code schreibt und das Ganze ausliefert. MCP ist dafür gebaut, dass eine KI ein Tool zur Laufzeit entdeckt und benutzt, ohne dass vorher jemand Integrationscode schreibt. Redaktionelle Illustration, die drei Ansätze in drei vertikalen Spuren vergleicht: ein Entwickler tippt Code, beschriftet REST API, ein automatisierter Pfeil löst bei einem Ereignis aus, beschriftet Webhook, und eine Chat-Oberfläche, in der eine KI Tools aus einem Menü auswählt, beschriftet MCP, alles in flachen, lebendigen Farben
AspektREST APIWebhookMCP
RichtungDu rufst sie aufEr ruft dich aufDas Modell ruft es in deinem Namen auf
Wer schreibt die IntegrationEin Entwickler, im VorausEin Entwickler, im VorausDas Modell, zur Laufzeit, aus einer Tool-Liste
DiscoveryLies die DokuLies die DokuServer gibt eine typisierte Liste von Tools zurück
Auth-ModellAPI-Keys, OAuthSignierte PayloadsOAuth 2.1 + PKCE + Dynamic Client Registration
Am besten geeignet fürApps und SkripteAuf Events reagierenKonversations- und Agent-Workflows
Ein Webhook ist Push. Eine REST API ist Pull. MCP ist ein Modell, das zum Hörer greift, fragt: „Was kannst du gerade für mich tun?", und nur die Aufrufe macht, die es für genau diesen Prompt braucht. Was außerdem zählt: Es liefert typisierte Tool-Definitionen, sodass das Modell weiß, welche Argumente erforderlich sind, welche optional, und wie die Antwort aussehen wird. Kein Raten mehr aus einer Doku-Seite.

Der Auth-Flow: OAuth 2.1, PKCE und DCR in einfachen Worten

Das ist der Teil, den die meisten überfliegen, und es ist genau der Teil, der MCP innerhalb eines Unternehmens überhaupt brauchbar macht. Vier Bausteine greifen ineinander, jeder löst ein bestimmtes Problem.
  1. Dynamic Client Registration (DCR, RFC 7591)
    Klassisches OAuth verlangte, dass jeder Client von Hand vorregistriert wurde: Ein Entwickler loggt sich ins SaaS-Admin-Panel ein, füllt ein Formular aus, kopiert eine Client-ID und ein Secret und fügt sie irgendwo ein. Das skaliert nicht, wenn „der Client" jede Claude-Installation auf der Welt ist. DCR lässt den MCP-Client sich beim Server programmatisch vorstellen („Ich bin Claude Desktop auf dem Laptop dieses Nutzers, hier ist meine Redirect-URI") und der Server gibt eine frische Client-ID zurück. Kein Admin nötig.
  2. OAuth 2.1 Authorization Code Flow
    Sobald eine Client-ID vorliegt, öffnet der Assistent deinen Browser, leitet auf die Anmeldeseite des SaaS-Anbieters weiter und bittet dich, die Verbindung freizugeben. Das ist derselbe Flow, den du beim „Sign in with Google" auf einer Drittanbieter-Seite nutzt. Du siehst genau, mit welcher Org du dich verbindest und welche Scopes (lesen, schreiben) der Assistent verlangt. Der SaaS-Anbieter gibt einen Authorization Code zurück, den der Client gegen ein Access Token tauscht.
  3. PKCE (Proof Key for Code Exchange)
    PKCE verhindert, dass der Authorization Code unterwegs gestohlen wird. Der Client erzeugt ein Einmal-Geheimnis, hasht es mit SHA-256 und schickt den Hash zuerst los. Wenn er später den Code einlöst, muss er das ursprüngliche Geheimnis mitsenden. Ein Angreifer, der den Code abfängt, kann ihn ohne dieses Geheimnis nicht einlösen. Die MCP-Spezifikation schreibt PKCE mit der Methode S256 vor, ohne Fallback auf schwächere Varianten.
  4. Resource Indicators (RFC 8707)
    Die MCP-Spezifikation 2026 verlangt außerdem, dass der Client beim Anfordern eines Tokens den konkreten Server nennt, den er aufrufen will. Das verhindert, dass ein Token, das für einen MCP-Server ausgestellt wurde, gegen einen anderen wiederverwendet wird. Das Token ist an eine einzige Audience gebunden.
Aus Nutzersicht ist das Ergebnis ein einziger Klick im Browser. Aus Sicht des Security-Teams ist es OAuth richtig gemacht: pro Nutzer, gescopet, an eine Audience gebunden, widerrufbar und ohne geteilte Geheimnisse, die in Config-Dateien herumliegen.

Warum gerade agile Teams das interessieren sollte

Die meisten frühen MCP-Berichte konzentrieren sich auf Entwickler, die KI nutzen, um Code zu lesen oder Datenbanken abzufragen. Das wird dem Ganzen nicht gerecht. Agile Teams sitzen an einer einzigartigen Stelle: Ein großer Teil deiner Meeting-Vorbereitung besteht darin, Kontext aus fünf Tools zusammenzutragen (PRs, Tickets, Incidents, Releases, Kundenfeedback) und ihn dann in ein Tool zu schreiben (das Standup, das Retro-Board, den Planning-Poker-Raum). Genau diese Form von Arbeit liegt MCP gut.
🌅Standups schreiben sich von selbst

Dein Assistent zieht die PRs und Ticket-Aktivitäten von gestern aus deinen Dev-Tools, formatiert deine drei Antworten und reicht sie heute beim Standup ein, bevor du Slack überhaupt öffnest.

🃏Planning Poker direkt aus dem Backlog

„Zieh die nächsten 10 nicht geschätzten Tickets, öffne einen Planning-Poker-Raum namens Sprint 47 und füge jedes Ticket als Runde hinzu." Ein Prompt, Sprint-Raum steht.

🪞Retros mit echten Daten vorbereitet

Geh ins Retro mit den Incidents, Releases und Kundenmeldungen dieses Sprints schon auf dem Board, sortiert nach Spalte. Das Team diskutiert, statt zu transkribieren.

✅Action Items mit Kontext

Der Assistent macht aus der Retro-Diskussion Action Items, weist Verantwortliche zu und verlinkt jedes Item mit dem Quell-Thread oder Ticket. Keine Copy-Paste-Steuer.

Die tieferliegende Verschiebung ist, dass die Rolle des Scrum Masters anders aussieht. Ein Großteil der Meeting-Logistik (Updates einsammeln, Nachzügler finden, den letzten Sprint zusammenfassen) ist Arbeit, die eine KI bei richtiger Tool-Oberfläche zuverlässig erledigt. Die menschliche Zeit fließt zurück in die Gespräche, die wirklich einen Menschen brauchen: das schwierige Retro moderieren, das Team bei einem wiederkehrenden Hindernis coachen, einem neuen Teammitglied helfen, bessere Stories zu schreiben. Mehr dazu, wie das in der Praxis aussieht, findest du in unserem Beitrag zu KI-Agenten verändern, wie wir schätzen und KI-gestütztes Backlog Refinement.

Was du heute tatsächlich tun kannst

Die aktuellen MCP-fähigen Clients sind Claude Desktop, Claude Code, Cursor, Zed, ChatGPT und eine wachsende Liste von Agent-Frameworks. Auf der Server-Seite haben GitHub, Linear, Sentry, PagerDuty, Notion, Slack, Atlassian und die meisten modernen SaaS-Tools entweder einen MCP-Server am Start oder einen in der Beta-Phase. Redaktionelle Illustration eines Sprint-Boards, das im Vordergrund schwebt, mit stilisierten Sprechblasen, die von links hineinströmen, jede mit einem kleinen Symbol für Code, Ticket, Incident oder Nachricht, in lebendigen flachen Farben auf einem weichen Farbverlauf Kollabe bringt ebenfalls einen MCP-Server mit. Verbinde ihn mit dem KI-Client deiner Wahl, und du bekommst das volle Set an Standup-, Retro-, Planning-Poker- und Action-Item-Tools, mit demselben Auth-Modell wie oben beschrieben, gescopet auf eine Organisation und mit einem Ein-Klick-Widerruf, falls du es dir anders überlegst. Das Ganze gibt es unter kollabe.com/mcp, zusammen mit Copy-Paste-Config-Snippets für jeden Client. Wenn du lieber etwas Maßgeschneiderteres als eine Chat-Sitzung bauen willst, sind dieselben Endpunkte über Kollabes öffentliche REST API per Personal Access Token verfügbar. Gleiches Auth-Modell, gleiche Strukturen, kein MCP-Client nötig. Praktisch für ein Claude Skill, das das exakte Standup-Format deines Teams fährt, einen CI-Job, der bei Sprint-Start einen Planning-Poker-Raum öffnet, oder einen Cron, der jeden zweiten Freitag ein Retro schließt.

Ein vernünftiger Einstieg

Wenn dein Team MCP noch nicht angefasst hat, ist der risikoärmste Einstieg, dir ein Ritual auszusuchen, das du lästig findest, und einen MCP-Server anzubinden. Standups sind meistens der erste Treffer, weil der Wert innerhalb eines einzigen Morgens sichtbar wird. Ab da findet sich der nächste Use Case meist schon im darauffolgenden Sprint von selbst. Probier unseren Generator für Retrospektive-Vorlagen als nicht-MCP-Einstieg aus, wenn du sehen willst, wie KI in agile Rituale passt, bevor du einen Server verkabelst – und komm dann zurück zu diesem Beitrag, wenn du bereit bist, einen Assistenten an deine echten Tools zu hängen.

Nein. Anthropic hat die Spezifikation veröffentlicht, aber sie ist offen. OpenAI, Google und mehrere Open-Source-Clients implementieren sie, und jedes Modell kann hinter einem konformen Client sitzen. Das Protokoll ist es egal, welches Modell auf der anderen Seite ist.

Um es zu benutzen, nein. Einen MCP-Server an Claude Desktop oder Cursor anzuschließen sind ein paar Klicks in den Einstellungen plus eine OAuth-Freigabe. Um einen Server zu bauen, ja; das ist immer noch Entwicklergebiet, aber die meisten Teams werden nur die Server konsumieren, die ihre Anbieter veröffentlichen.

Function Calling ist ein Feature eines einzelnen Modells. ChatGPT-Plugins waren OpenAI-spezifisch. MCP ist ein Transport- und Auth-Standard, den jedes Modell und jedes Tool implementieren kann, sodass ein einmal veröffentlichter Server in jedem konformen Client funktioniert. Die Interoperabilität ist der Punkt.

Sie funktionieren weiter. MCP sitzt meistens auf derselben internen API, die deine Web-App nutzt. Du migrierst nichts; du legst nur eine neue Oberfläche für KI-Clients frei, während deine Dashboards und Skripte weiter wie gewohnt die API ansprechen.

Mit OAuth 2.1, PKCE, gescopten Tokens und einem klaren Widerrufsweg ist die Sicherheitslage dieselbe wie beim Anbinden jeder anderen Drittanbieter-App. Das größere Risiko sind schlechte Prompts, nicht schlechtes Protokoll-Design. Fang mit Read-only-Scopes an, schau einen Sprint lang zu, was der Assistent macht, und gib Schreibzugriff frei, sobald du dem Workflow vertraust.