Uprostred code review otevre vyvojar novou zalozku, prihlasi se do Azure DevOps, proklikne se ke spravnemu sprintu a zkontroluje, jestli prosel build. Pak se vrati zpet. Za den se tento cyklus opakuje mozna tricet nebo ctyricetkrat. Cely ten cas neni prace na produktu. Je to administrativa kolem prace na produktu.
Prace, kterou nikdo nechce delat
Azure DevOps je dobry nastroj. Boards, Pipelines, Repos: vsechno na jednom miste. Problem neni nastroj. Problem je, ze kontext k nemu vzdy lezi jinde. Vyvojar pise v editoru, komunikuje v chatu, sprintove planovani bezi v Boardsech a status buildu je v Pipelines. Kazdy prechod mezi temito misty stoji pozornost.
Kdyz product owner zepta na konci standupu 'jak jsme na tom s US-417?', vyvojar neotvira odpoved z pameti. Otvira zalozku. Klikne na spravny sprint. Najde work item. Precte stav. Zavola zpet. Toto je informacni smycka, ktera by sla zkratit.
Otevrene zalozky nejsou multitasking. Jsou to preklady mezi nastroji, ktere spolu nemluvily.
— Standup poznamka, abridged
Co MCP server pro Azure DevOps skutecne dela
MCP (Model Context Protocol) je standard, ktery definuje, jak muze Claude volat externi nastroje. MCP server pro Azure DevOps je maly program, ktery bezi na vasi infrastrukture a preklada Claudovy pozadavky na Azure DevOps REST API volani. Kdyz se Claude zepta 'ktere work items jsou v aktualnim sprintu blokovane?', server to przelozi na spravny API endpoint, overi vas identitu a vrati odpoved. Claude dostane strukturovana data, ne screenshot.
Klic je v tom, jak server nosi identitu. Kazdy uzivatel ma vlastni token s omezenym scope, ktery si nastavil sam. Server nepouziva sdileny servisni ucet. Claude tedy nikdy nevidi vic, nez by videl vyvojar sam, kdyz by se prihlasil do Azure DevOps ve svem prohlizeci. Tato hranice neni technicka podrobnost. Je to duvod, proc lze systemu duverovat.
Konkretne: Azure DevOps Boards a Pipelines
Azure DevOps nabizi REST API pro work items, pipeline runs i pull requesty. MCP server obaluje tyto endpointy do jednoduchych nastroju, ktere Claude muze pouzivat. Integraci lze sestavit postupne: nejdriv read-only pristup k Boards a Pipelines, pozdeji volitelne pridani pull request kontextu z Repos. Puvodni Azure DevOps portal nikdo neopousti, prijde pouze dalsi vrstva pristupu.
- Zobrazeni vsech work items v aktualnim sprintu vcetne stavu a prirazeneho cloveka.
- Zjisteni stavu posledniho pipeline runu pro konkretni vetev nebo definici.
- Vypis otevrenych pull requestu cekajicich na review od konkretniho cloveka.
- Souhrn blokovanych polozek ve sprintu s komentari k blokatorum.
- Prehled zmen work item stavu za posledni den pro daily standup.
Ilustrativne: tym peti vyvojaru, ktery ma kazdy den ranni standup, by mohl misto rucniho prochazeni Boardsu dostat od Clauda strukturovany prehled stavu sprinu pripraven pred schuzkou. Misto pet minut klikani: jeden dotaz, jedna odpoved.
Co Claude v Azure DevOps neudela, a proc je to dobre
Read-only pristup je zakladni nastaveni z dobreho duvodu. Claude muze precist stav, ale pull request schvaluje vyvojar, ktery kod videl a rozumi kontextu. Deployment do produkce spousti ten, kdo nese odpovednost za stabilitu systemu. Prioritizaci backlogu resi product owner, ktery zna business kontext. MCP server je informacni most, ne automaticky operator.
Write operace jsou mozne, ale vyzaduji vedome rozhodnuti: explicitni nastaveni scope tokenu tak, aby write byl povolen, a explicitni instrukci od uzivatele v kazdem volani. Zadna automaticka akce na pozadi. Toto neni omezeni systemu. Je to navrh, ktery odpovida tomu, jak funguje odpovednost ve vyvojarskych tymech.
Co to obnasi v praxi
MCP server pro Azure DevOps bezi na vasi infrastrukture, ne na nasi. Konfiguruje se jednou: URL vasi Azure DevOps organizace, scope osobnich tokenu pro kazdeho clena tymu, seznam nastroju, ktere chcete zpristupnit. Zadny rocni projekt, zadny velky rollout. Lze zacit s read-only pristupem k Boards a pridat dalsi nastroje, kdyz tym vidi, co funguje.
Mezera je bottleneck, ne model
Claude sam o sobe vasi Azure DevOps data nevidi. Ne proto, ze by nebyl dost schopny, ale proto, ze k nim nema cestu. MCP server tu cestu postavi: jedna spojnice, identity-scoped, na vasi infrastrukture, s auditnim zaznamem. Od te chvile se vyvojar muze zeptat na stav sprintu stejne prirodzene, jako se zepta kolegy.
Pokud vas tym pouziva Azure DevOps a chcete vedet, co by MCP server konkretne resel ve vasem prostredi, napiste nam. Kratky hovor, zadne dlouhe zadani.