MCP pro vývojářské týmy: jak napojit AI agenty na vaše nástroje

AI asistent, který jen povídá, je hezký, ale limitovaný. Zeptáte se ho na bug a on hádá, protože nevidí váš kód, vaše logy ani vaše tickety. MCP (Model Context Protocol) tohle mění — je to standardní způsob, jak napojit agenta na reálné nástroje a data vašeho týmu. Místo asistenta, který chatuje, dostanete agenta, který umí jednat.

Co je MCP a proč vzniklo

MCP je otevřený protokol, který definuje, jak AI asistent komunikuje s externími nástroji a zdroji dat. Představte si ho jako USB-C pro AI: jeden standard, přes který se agent napojí na repo, dokumentaci, ticketing systém, databázi nebo monitoring. Bez MCP musel každý nástroj psát vlastní integraci pro každého asistenta. S MCP napíšete server jednou a použije ho jakýkoliv MCP-kompatibilní klient.

Architektura je jednoduchá. Na jedné straně je klient (Claude Code, Cursor, váš IDE nebo desktop asistent), na druhé straně MCP server, který zpřístupňuje konkrétní schopnosti. Server nabízí tři typy věcí: tools (akce, které agent může provést), resources (data, která může číst) a prompts (předpřipravené šablony). Agent si při startu vyžádá seznam dostupných nástrojů a pak je volá podle potřeby.

• Tools — akce: 'vytvoř ticket', 'spusť query', 'restartuj deployment'
• Resources — data ke čtení: soubory, řádky z DB, obsah dokumentace
• Prompts — šablony: předpřipravené workflow, které si tým sdílí
• Klíčová myšlenka: agent nevidí nic, co mu server explicitně nezpřístupní

Proč to pro dev tým znamená rozdíl

Rozdíl mezi 'agent, který chatuje' a 'agent, který jedná' je stejný jako mezi kolegou přes telefon a kolegou u vašeho monitoru. Agent bez kontextu vám dá obecnou radu. Agent s MCP přístupem si přečte konkrétní ticket, podívá se do logu, zkontroluje schéma databáze a navrhne fix, který sedí na váš reálný stav — ne na průměr internetu.

Reálné use case pro dev tým

Kontext z Jiry / Lineáru

Nejčastější první krok. Agent se napojí na ticketing a přečte zadání přímo ze zdroje — popis, komentáře, acceptance criteria. Místo 'implementuj PROJ-431' (kde agent netuší, co to je) dostanete agenta, který si ticket sám načte, pochopí požadavek a začne pracovat. Write přístup (vytvoření a update ticketu) přidejte až později, opatrně.

Read-only dotazy do databáze

Extrémně užitečné a zároveň riskantní — proto read-only. Agent si umí sám zjistit schéma, spočítat, kolik řádků má tabulka, ověřit, jestli migrace prošla. Nikdy nedávejte agentovi write přístup k produkční databázi. Používejte read-only replicu nebo dedikovaného DB uživatele s právy jen na SELECT.

Čtení logů a monitoring

Agent napojený na logy (Sentry, Grafana, ELK) dokáže korelovat chybu s časovou osou deploymentů a najít pravděpodobnou příčinu. Tady se nejvíc projeví hodnota: debugging, který by vám zabral 20 minut proklikávání dashboardů, agent zvládne za pár sekund čtení.

Vyhledávání v interní dokumentaci

Confluence, Notion, interní wiki. Agent, který umí prohledat vaše ADR (architecture decision records) a runbooky, přestane vymýšlet konvence a začne se řídit těmi vašimi. To je rozdíl mezi kódem, který musíte přepsat, a kódem, který sedí do projektu.

Jak začít

Nemusíte nic psát od nuly. Většina velkých nástrojů už oficiální MCP server má — GitHub, Sentry, Linear, Notion, Slack, řada databází. Začnete tím, že server přidáte do konfigurace svého klienta a nastavíte přihlašovací údaje (typicky přes OAuth nebo API token v proměnné prostředí).

// Příklad: konfigurace MCP serverů pro klienta
// (např. .mcp.json ve vašem projektu)
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
    },
    "postgres-readonly": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": { "DATABASE_URL": "${READONLY_DB_URL}" }
    }
  }
}

Praktický postup: začněte s jedním read-only serverem (třeba docs nebo logy), ověřte, že agent chápe, co má k dispozici, a teprve pak přidávejte další. Nepřipojujte deset serverů najednou — agent se v příliš mnoha nástrojích ztrácí a vy ztratíte přehled o tom, kam vlastně sahá.

Bezpečnost a governance

Tady se odděluje hračka od produkčního nasazení. MCP server běží s oprávněními, která mu dáte — a agent přes něj může udělat cokoliv, co server dovolí. Proto k tomu přistupujte jako k jakémukoliv jinému přístupu do systému, ne jako k neškodné AI funkci.

• Scope minimalisticky — každý server dostane jen ta oprávnění, která reálně potřebuje
• Read vs write — začněte read-only; write akce zapínejte vědomě a po jedné
• Secrets — nikdy v promptu ani v konfiguraci; jen přes secret manager a env proměnné
• Audit — logujte, které nástroje agent volal a s jakými parametry
• Human-in-the-loop — u destruktivních akcí (delete, deploy, write do DB) vyžadujte potvrzení

Kde začít v praxi

Nezačínejte tím nejambicióznějším scénářem. Vyberte jednu bolest, kterou tým řeší denně — třeba dohledávání kontextu z ticketů nebo čtení logů při incidentu — a nasaďte na ni jeden read-only MCP server. Ověřte hodnotu na reálné práci, získejte důvěru týmu a teprve pak rozšiřujte na write akce a další systémy.

MCP neudělá z průměrného agenta zázrak. Udělá z něj člena týmu, který vidí to, co vidíte vy — a to je většina rozdílu mezi radou od nezúčastněného a řešením od kolegy.

Za pár týdnů zjistíte, že nejvíc hodnoty nedávají nejmohutnější integrace, ale ty nejnudnější: přečti ticket, podívej se do logu, najdi to v docs. Přesně to, co byste jinak proklikávali sami.