Uprostřed code review otevře vývojář novou záložku, přihlásí se do Azure DevOps, proklikne se ke správnému sprintu a zkontroluje, jestli prošel build. Pak se vrátí zpět. Za den se tento cyklus opakuje možná třicet nebo čtyřicetkrát. Celý ten čas není práce na produktu. Je to administrativa kolem práce na produktu.
Práce, kterou nikdo nechce dělat
Azure DevOps je dobrý nástroj. Boards, Pipelines, Repos: všechno na jednom místě. Problém není nástroj. Problém je, že kontext k němu vždy leží jinde. Vývojář píše v editoru, komunikuje v chatu, sprintové plánování běží v Boardsech a status buildu je v Pipelines. Každý přechod mezi těmito místy stojí pozornost.
Když se product owner na konci standupu zeptá 'jak jsme na tom s US-417?', vývojář neodpovídá z paměti. Otevírá záložku. Klikne na správný sprint. Najde work item. Přečte stav. Zavolá zpět. Toto je informační smyčka, kterou by šlo zkrátit.
Otevřené záložky nejsou multitasking. Jsou to překlady mezi nástroji, které spolu nemluvily.
— Poznámka ze standupu, zkráceno
Co MCP server pro Azure DevOps skutečně dělá
MCP (Model Context Protocol) je standard, který definuje, jak může Claude volat externí nástroje. MCP server pro Azure DevOps je malý program, který běží na vaší infrastruktuře a překládá Claudovy požadavky na volání Azure DevOps REST API. Když se Claude zeptá 'které work items jsou v aktuálním sprintu blokované?', server to přeloží na správný API endpoint, ověří vaši identitu a vrátí odpověď. Claude dostane strukturovaná data, ne screenshot.
Klíč je v tom, jak server nosí identitu. Každý uživatel má vlastní token s omezeným scope, který si nastavil sám. Server nepoužívá sdílený servisní účet. Claude tedy nikdy nevidí víc, než by viděl vývojář sám, kdyby se přihlásil do Azure DevOps ve svém prohlížeči. Tato hranice není technická podrobnost. Je to důvod, proč lze systému důvěřovat.
Konkrétně: Azure DevOps Boards a Pipelines
Azure DevOps nabízí REST API pro work items, pipeline runs i pull requesty. MCP server obaluje tyto endpointy do jednoduchých nástrojů, které Claude může používat. Integraci lze sestavit postupně: nejdřív read-only přístup k Boards a Pipelines, později volitelně přidání kontextu pull requestů z Repos. Původní Azure DevOps portál nikdo neopouští, přijde pouze další vrstva přístupu.
- Zobrazení všech work items v aktuálním sprintu včetně stavu a přiřazeného člověka.
- Zjištění stavu posledního pipeline runu pro konkrétní větev nebo definici.
- Výpis otevřených pull requestů čekajících na review od konkrétního člověka.
- Souhrn blokovaných položek ve sprintu s komentáři k blokátorům.
- Přehled změn stavu work items za poslední den pro daily standup.
Ilustrativně: tým pěti vývojářů, který má každý den ranní standup, by mohl místo ručního procházení Boardsů dostat od Clauda strukturovaný přehled stavu sprintu připravený před schůzkou. Místo pěti minut klikání: jeden dotaz, jedna odpověď.
Co Claude v Azure DevOps neudělá, a proč je to dobře
Read-only přístup je základní nastavení z dobrého důvodu. Claude může přečíst stav, ale pull request schvaluje vývojář, který kód viděl a rozumí kontextu. Deployment do produkce spouští ten, kdo nese odpovědnost za stabilitu systému. Prioritizaci backlogu řeší product owner, který zná business kontext. MCP server je informační most, ne automatický operátor.
Write operace jsou možné, ale vyžadují vědomé rozhodnutí: explicitní nastavení scope tokenu tak, aby write byl povolen, a explicitní instrukci od uživatele v každém volání. Žádná automatická akce na pozadí. Toto není omezení systému. Je to návrh, který odpovídá tomu, jak funguje odpovědnost ve vývojářských týmech.
Co to obnáší v praxi
MCP server pro Azure DevOps běží na vaší infrastruktuře, ne na naší. Konfiguruje se jednou: URL vaší Azure DevOps organizace, scope osobních tokenů pro každého člena týmu, seznam nástrojů, které chcete zpřístupnit. Žádný roční projekt, žádný velký rollout. Lze začít s read-only přístupem k Boards a přidat další nástroje, když tým vidí, co funguje.
Mezera je bottleneck, ne model
Claude sám o sobě vaše Azure DevOps data nevidí. Ne proto, že by nebyl dost schopný, ale proto, že k nim nemá cestu. MCP server tu cestu postaví: jedna spojnice, identity-scoped, na vaší infrastruktuře, s auditním záznamem. Od té chvíle se vývojář může zeptat na stav sprintu stejně přirozeně, jako se zeptá kolegy.
Pokud váš tým používá Azure DevOps a chcete vědět, co by MCP server konkrétně řešil ve vašem prostředí, napište nám. Krátký hovor, žádné dlouhé zadání.