          Azure DevOps · KI-Agenten        

Azure DevOps MCP Server einführen, ohne Ihre Pipelines aus der Hand zu geben

Kurz gesagt

Der Azure DevOps MCP Server von Microsoft gibt KI-Agenten Zugriff auf Work Items, Repositories, Pipelines und Wikis. Gedacht für Entwicklungs- und Plattformteams, die ihn einführen wollen, ohne dass ein Agent ungefragt in produktive Abläufe eingreift. Beim gehosteten Server sind sieben der acht Werkzeugsätze voreingestellt aktiv, einschließlich der schreibenden (Microsoft Learn, August 2026). Wir schneiden die Rechte, bevor der erste Zugang vergeben wird, ab 9.500 Euro.

Microsoft Solutions Partner

ISO 27001 zertifiziert

Nur-Lese-Betrieb als Startpunkt

Microsoft Solutions Partner (Digital & App Innovation, Infrastructure Azure, Data & AI Azure), ISO/IEC 27001:2024, Google Cloud Partner, AWS Partner

Jetzt Kontakt aufnehmen
Alle MCP-Themen

Warum der Server mit Standardeinstellungen teuer wird

Der Azure DevOps MCP Server ist in Minuten eingerichtet und seit dem 5. August 2026 allgemein verfügbar. Was dabei untergeht: Voreingestellt sind fast alle Werkzeugsätze aktiv, und darunter sind schreibende Operationen. Ein Agent kann damit Pipelines starten, Pull Requests anlegen und Work Items ändern (Microsoft Learn, Stand 12. August 2026).

Der Standard ist schreibend, nicht lesend

Ohne den Header für den Nur-Lese-Betrieb stehen Werkzeuge wie das Starten einer Pipeline, das Anlegen von Pull Requests und das Aktualisieren von Work Items zur Verfügung. Der Schalter dafür existiert, er ist nur nicht gesetzt.

Nicht jede Organisation kommt an den gehosteten Server

Der von Microsoft gehostete Server verlangt eine Anbindung an Microsoft Entra. Organisationen, die auf einem eigenständigen Microsoft-Konto laufen, werden für den Remote-Betrieb nicht unterstützt und müssen den lokalen Server nehmen.

Ihr Werkzeug spricht vielleicht nicht mit dem Server

Claude Desktop, Claude Code, Cursor und Codex brauchen eine dynamische Registrierung ihrer Anmelde-Kennung, die Microsoft Entra bisher nicht unterstützt. Wer diese Werkzeuge einsetzt, landet zwangsläufig beim lokalen Server, und dort fehlt der Nur-Lese-Schalter.

Welche Stellschrauben es tatsächlich gibt

Die folgenden Angaben stammen aus der Microsoft-Dokumentation und dem Quellcode-Repository, nicht aus Pexon-Projekten. Sie zeigen, welche Stellschrauben es gibt, bevor jemand den Server produktiv schaltet.

8 Werkzeugsätze lassen sich einzeln freigeben

stehen beim gehosteten Server zur Auswahl: Repositories, Work Items, Pipelines, Wiki, Iterationen, Testpläne, Advanced Security und die Migrationswerkzeuge. Über einen Kopfzeilen-Eintrag geben Sie frei, was der Anwendungsfall braucht. Voreingestellt sind sieben davon, nur die Migrationswerkzeuge sind ausgenommen. Die Core-Werkzeuge zur Auflistung von Organisationen, Projekten und Teams bleiben immer aktiv. Advanced Security setzt eine eigene Lizenz voraus. (Microsoft Learn, Remote Azure DevOps MCP Server, Stand 12. August 2026)

1 Kopfzeile schaltet den Nur-Lese-Betrieb, aber nur gehostet

genügt beim gehosteten Server, um schreibende Operationen zu sperren. Das ist dort der sinnvolle Startpunkt: erst lesen lassen, messen, was die Teams abfragen, dann gezielt öffnen. Beim lokalen Server gibt es diesen Schalter nicht, dort sichern Berechtigungen und Token-Rechte ab. (Microsoft Learn, Header X-MCP-Readonly, Stand August 2026)

Node 20 nur beim lokalen Server nötig

ist die Mindestversion für den lokalen Betrieb. Der gehostete Server braucht keine Installation, dafür eine Entra-Anbindung. Welcher Weg für Sie gilt, entscheidet sich an Ihren Werkzeugen, nicht an der Vorliebe. (Microsoft Learn, Vergleich Remote und Local, Stand August 2026)

5. August 2026 allgemein verfügbar

ist der gehostete Server allgemein verfügbar. In Vorschau sind nur noch die Migrationswerkzeuge. Microsoft schreibt zudem, dass der gehostete Server den lokalen langfristig ablösen soll und die Entwicklung sich darauf konzentriert. Wer heute auf den lokalen setzt, plant den Wechsel besser gleich mit ein. (Microsoft, Azure DevOps Blog, GA-Ankündigung vom 5. August 2026)

Ab wann sich eine begleitete Einführung lohnt

Eine begleitete Einführung lohnt sich, sobald mehr als 20 Personen Zugriff bekommen sollen, zwei verschiedene Werkzeuge im Einsatz sind oder auch nur eine produktive Pipeline im Zugriff liegt. Darunter genügt der Nur-Lese-Betrieb und ein Blick in die Dokumentation.

Personen mit Zugriff

Werkzeuge im Team

produktive Pipeline im Zugriff

Vier Anwendungsfälle aus Entwicklung und Plattform

Use Case 01

Der Agent soll den Sprint-Stand berichten

Ein Team will Work Items, Iterationen und Kapazitäten im Chat abfragen, ohne in Azure DevOps zu wechseln. Dafür genügen die Work-Item- und Iterations-Werkzeuge im Nur-Lese-Betrieb, alles andere bleibt gesperrt.

2 Werkzeugsätze freigegeben statt sieben

Use Case 02

Die Code-Review soll vorbereitet werden

Der Agent liest Pull Requests, Änderungen und Kommentarverläufe und fasst sie zusammen. Ob er auch abstimmen und Kommentare schreiben darf, ist eine bewusste Entscheidung und keine Voreinstellung.

1 klare Grenze zwischen Lesen und Eingreifen im Repository

Use Case 03

Fehlgeschlagene Builds sollen analysiert werden

Der Agent holt Build-Status, Protokolle und die zugehörigen Commits. Das Starten und Abbrechen von Pipelines ist ein eigenes, schreibendes Werkzeug und bleibt in der Regel außen vor.

0 Pipeline-Starts durch den Agenten, solange nicht ausdrücklich freigegeben

Use Case 04

Mehrere Werkzeuge im Haus, ein Zugang

Ein Teil der Entwicklung arbeitet mit Visual Studio und Copilot, ein anderer mit Claude Code oder Cursor. Weil die zweite Gruppe den gehosteten Server nicht nutzen kann, braucht sie den lokalen mit eigener Anmeldung.

2 Betriebswege parallel, mit einem gemeinsamen Rechtekonzept

Integration in Ihre Umgebung

Die Frage ist nicht, ob der Server läuft, sondern welcher der beiden Wege zu Ihren Werkzeugen passt und wie eng Sie die Rechte schneiden. Steht dabei die Plattform selbst zur Debatte, also Pipelines, Boards und Rechte im Gesamtbild, gehört das in eine Azure DevOps Beratung.

Die zwei Betriebswege

Gehosteter Server · Keine Installation, Anmeldung über Microsoft Entra, von Microsoft betrieben und aktualisiert. Setzt voraus, dass Ihre Organisation an einen Entra-Tenant angebunden ist.

Lokaler Server · Läuft auf dem Rechner der Entwicklerin, braucht Node.js in Version 20 oder neuer. Anmeldung über ein persönliches Zugriffstoken oder Entra. Der Weg für Werkzeuge, die den gehosteten Server nicht ansprechen können.

Wer welchen Weg braucht · Visual Studio Code mit GitHub Copilot, Visual Studio, Microsoft Foundry, Copilot Studio sowie GitHub Copilot CLI und App können den gehosteten Server nutzen. Claude Desktop, Claude Code, Cursor und Codex derzeit nicht: sie brauchen eine dynamische Registrierung ihrer Anmelde-Kennung, die Microsoft Entra bisher nicht unterstützt.

Womit Sie die Rechte schneiden

Werkzeugsätze begrenzen · Statt der voreingestellten sieben geben Sie nur die frei, die der Anwendungsfall braucht, etwa Repositories und Work Items. Die Core-Werkzeuge bleiben immer erreichbar, die Migrationswerkzeuge sind ohnehin gesondert freizuschalten.

Nur-Lese-Betrieb · Beim gehosteten Server sperrt eine Kopfzeile die schreibenden Operationen. Für den Einstieg die sicherste Einstellung. Beim lokalen Server existiert dieser Schalter nicht: dort lassen sich nur ganze Domains abwählen, und Lese- wie Schreibwerkzeuge liegen in derselben Domain.

Bestehende Berechtigungen · Der Server arbeitet mit den Rechten der angemeldeten Person und der Projektmitgliedschaft. Wer in Azure DevOps nichts sieht, sieht es auch über den Agenten nicht. Das ist die Grundsicherung, aber keine vollständige.

Wie die Einführung funktioniert

1

Anwendungsfälle sammeln

Welche Fragen sollen Agenten an Azure DevOps stellen dürfen. Aus dieser Liste ergibt sich, welche Werkzeugsätze überhaupt nötig sind, meist zwei oder drei.

2

Betriebsweg festlegen

Gehostet oder lokal, entschieden anhand Ihrer Entra-Anbindung und der Werkzeuge, die Ihre Teams tatsächlich nutzen. Arbeiten beide Gruppen im Haus, planen wir beide Wege.

3

Rechte schneiden

Werkzeugsätze eingrenzen, Nur-Lese-Betrieb setzen, Berechtigungen in Azure DevOps prüfen. Erst danach bekommt jemand einen Zugang.

4

Im Nur-Lese-Betrieb starten

Eine Pilotgruppe arbeitet mit den engstmöglichen Rechten, wir werten aus, welche Werkzeuge tatsächlich gerufen werden. Das ist die Grundlage für jede spätere Freigabe.

5

Schreibrechte gezielt öffnen

Wenn ein Anwendungsfall es begründet, wird gezielt geöffnet. Beim gehosteten Server geht das entweder über Werkzeugsätze oder über eine Einzelwerkzeug-Liste, Microsoft rät davon ab, beides zu kombinieren. Jede Freigabe wird dokumentiert.

6

Betrieb übergeben

Konfiguration, Rechtekonzept und die Liste der freigegebenen Werkzeuge gehen an Ihr Team. Microsoft ergänzt laufend Werkzeuge, ein Blick auf die Änderungen gehört deshalb zum Betrieb dazu.

Erfahren Sie mehr über die Absicherung von Agenten-Pipelines gegen manipulierte Werkzeugbeschreibungen

Warum Pexon statt selbst einrichten

Selbst einrichten

-Die Verbindung steht in Minuten, die Rechtefrage stellt sich erst danach.

-Die Voreinstellung gibt alle Werkzeugsätze frei, auch die schreibenden.

-Dass zwei Betriebswege nötig sein können, merkt man erst beim zweiten Werkzeug.

Warten, bis es fertig ist

-Der Server ist seit dem 5. August 2026 allgemein verfügbar, Werkzeuge kommen laufend dazu.

-Die Teams richten ihn in der Zwischenzeit selbst ein, unkoordiniert.

-Ein Rechtekonzept nachträglich durchzusetzen ist teurer als es vorher zu setzen.

Mit Pexon

✓Pexon Consulting schneidet die Rechte, bevor der erste Zugang vergeben wird.

✓Auf dem gehosteten Weg starten wir im Nur-Lese-Betrieb, auf dem lokalen über eingeschränkte Berechtigungen.

✓Passt der gehostete Server nicht zu Ihren Werkzeugen, sagen wir das in Woche eins.

Woher wir das kennen

Pexon Consulting ist Microsoft Solutions Partner, AWS Advanced Tier Partner und Google Cloud Partner sowie nach ISO 27001 zertifiziert. MCP-Server bauen und betreiben wir seit dem Erscheinen des Protokolls, unter anderem für SAP, SonarQube und Google Drive, und haben die Absicherung von Agenten-Pipelines gegen manipulierte Werkzeugbeschreibungen offen dokumentiert. Projektzahlen zu diesem Anwendungsfall nennen wir erst nach Freigabe des Kunden.

In vier Phasen zur produktiven Lösung

Woche 1

Anwendungsfälle und Betriebsweg

Ein Termin mit Entwicklung und Plattformteam. Ergebnis ist die Liste der nötigen Werkzeugsätze und die Entscheidung zwischen gehostetem und lokalem Server.

Woche 2

Aufsetzen und Rechte schneiden

Konfiguration mit begrenzten Werkzeugsätzen und Nur-Lese-Betrieb, Prüfung der Berechtigungen in Azure DevOps. Ergebnis ist ein Zugang, der nur kann, was vorgesehen ist.

Woche 3

Pilotbetrieb

Eine Gruppe arbeitet damit, wir werten die tatsächlich gerufenen Werkzeuge aus. Ergebnis ist eine belegte Nutzungsliste statt einer Vermutung.

Woche 4

Freigaben und Übergabe

Begründete Schreibfreigaben, Dokumentation der Konfiguration, Übergabe an Ihr Team. Ergebnis ist ein Betrieb, den Sie ohne uns weiterführen.

Einführung zum Festpreis

Ein Festpreis von der Anwendungsfall-Aufnahme bis zum übergebenen Betrieb. Der lokale Server ist quelloffen unter MIT-Lizenz, der gehostete ein Microsoft-Dienst. Beide sind in der Nutzung kostenfrei, bezahlt wird die Einführung.

Ihre Investition

ab 9.500 EUR

Festpreis · 4 Wochen

Enthält:

Umfang · Eine Azure-DevOps-Organisation, ein Betriebsweg, bis zu drei Werkzeugsätze, eine Pilotgruppe bis 20 Personen. Zweiter Betriebsweg oder weitere Organisationen nach Vorgespräch.

Was Sie beisteuern · Etwa vier Tage über vier Wochen: eine Person aus der Entwicklung, eine mit Administrationsrechten in Azure DevOps, plus die Freigabe für die Pilotgruppe.

Was Sie bekommen · Eine dokumentierte Konfiguration, ein Rechtekonzept und die belegte Liste der tatsächlich genutzten Werkzeuge. Abnahme gilt, wenn ein Zugriff auf einen nicht freigegebenen Werkzeugsatz nachweislich fehlschlägt und die Pilotgruppe ihre Anwendungsfälle im Nur-Lese-Betrieb abdecken kann.

Jetzt Kontakt aufnehmen

100 % unverbindlich, ohne Verpflichtung

Häufige Fragen

Kann ein Agent damit unsere Pipelines starten?

In der Voreinstellung ja. Das Werkzeug zum Starten einer Pipeline gehört zum Pipeline-Satz, und der ist voreingestellt aktiv. Beim gehosteten Server sperrt die Kopfzeile für den Nur-Lese-Betrieb die schreibenden Operationen, dort richten wir jede Einführung zuerst so ein. Beim lokalen Server fehlt dieser Schalter: dort begrenzen wir über die Azure-DevOps-Berechtigungen des verwendeten Kontos und die Rechte des Zugriffstokens.

Gehosteter oder lokaler Server, was passt zu uns?

Das entscheiden Ihre Werkzeuge. Visual Studio Code mit GitHub Copilot, Visual Studio, Microsoft Foundry, Copilot Studio sowie GitHub Copilot CLI und App können den gehosteten Server nutzen. Claude Desktop, Claude Code, Cursor und Codex derzeit nicht, weil Microsoft Entra die von ihnen benötigte Anmeldeform nicht unterstützt. Läuft Ihre Organisation auf einem eigenständigen Microsoft-Konto ohne Entra, bleibt ebenfalls nur der lokale Server.

Was kostet die Einführung?

Ab 9.500 Euro als Festpreis über vier Wochen: eine Organisation, ein Betriebsweg, bis zu drei Werkzeugsätze, Pilotgruppe bis 20 Personen. Der Server selbst ist in der Nutzung kostenfrei, es gelten weiterhin Ihre Azure-DevOps-Lizenzen, und die Kosten Ihres KI-Assistenten kommen separat dazu. Ein zweiter Betriebsweg oder weitere Organisationen kalkulieren wir nach dem Vorgespräch.

Sieht der Agent mehr als die angemeldete Person?

Nein. Der Server arbeitet mit den Rechten des angemeldeten Kontos und der Projektmitgliedschaft. Was jemand in Azure DevOps nicht sehen darf, bekommt er auch über den Agenten nicht. Das ist die Grundsicherung, ersetzt aber keine Eingrenzung der Werkzeuge: Innerhalb seiner Rechte kann ein Agent sonst mehr auslösen, als beabsichtigt war.

Wovon sollten wir vorerst die Finger lassen?

Von schreibenden Werkzeugen in produktionsnahen Pipelines, solange kein Protokoll und keine Freigabekette dahinterstehen. Ebenso von den Migrationswerkzeugen, die in einer geschlossenen Vorschau sind und für die meisten Organisationen ohnehin nicht freigeschaltet. Und wenn Ihre Teams auf den lokalen Server angewiesen sind: Dort fehlt der Nur-Lese-Schalter, die Absicherung läuft dann allein über Berechtigungen und Token-Rechte.

Was passiert, wenn Microsoft den lokalen Server einstellt?

Microsoft schreibt, dass der gehostete Server den lokalen langfristig ablösen soll und die Entwicklung sich darauf konzentriert. Ein Termin steht nicht fest. Wir planen den Wechsel deshalb von Anfang an mit: Das Rechtekonzept wird so geschnitten, dass es auf beiden Wegen trägt, und die Konfiguration ist dokumentiert statt gewachsen.

Erst die Rechte, dann die Zugänge

Solange nur wenige Teams damit arbeiten, ist ein Rechtekonzept schnell gesetzt. Sind die Zugänge erst verteilt, wird es zur Nacharbeit. Ein Gespräch von 30 Minuten reicht für die Einschätzung, welcher Betriebsweg bei Ihnen überhaupt in Frage kommt.

Jetzt Kontakt aufnehmen

Nachricht senden

Schreiben Sie uns, was bei Ihnen ansteht. Wir melden uns innerhalb von 24 Stunden.

Antwort innerhalb von 24 Stunden

Unverbindliches Erstgespräch

Persönlicher Ansprechpartner

Phillip Pham

CEO @ Pexon Consulting

Aktualisiert am 16. August 2026

Sie suchen einen Partner für Ihr Projekt?

Wir analysieren Ihren individuellen Bedarf, geben erste Empfehlungen zu Umsetzungsstrategien und bieten Ihnen transparente Einblicke in unsere Methoden, Technologien und Referenzen.

Vertrieb kontaktieren

400+Projekte seit 2020

100+Kunden im DACH-Raum

ISO27001 zertifiziert

3Hyperscaler Partner