Wprowadzenie: paradoks MCP

W 2024 roku Anthropic przedstawił Model Context Protocol (MCP) jako standard komunikacji między agentami AI a zewnętrznymi narzędziami. Obietnica była kusząca: jeden protokół, tysiące integracji, bezproblemowa wymiana danych.

Rok później? Nx – jeden z największych użytkowników MCP – usunął większość swoich narzędzi MCP. Google wydał Gemini CLI zamiast pełnej integracji z MCP. Społeczność deweloperska coraz głośniej mówi o "narzucie MCP" (MCP overhead).

Co się stało?

Teza: W większości przypadków zwykłe narzędzia CLI są efektywniejsze, bezpieczniejsze i tańsze tokenowo niż serwery MCP. I nie jest to opinia – są na to twarde dane.

Czym jest MCP i dlaczego powstał?

Model Context Protocol to otwarty standard stworzony przez Anthropic do komunikacji między agentami AI (np. Claude, ChatGPT) a zewnętrznymi systemami.

Architektura MCP

┌─────────────┐         ┌─────────────┐         ┌──────────────┐
│  Agent AI   │◄────────┤ Klient MCP  │◄────────┤  Serwer MCP  │
│  (Claude)   │  JSON   │             │  stdio  │  (GitHub)    │
└─────────────┘         └─────────────┘         └──────────────┘

MCP składa się z trzech elementów:

1. Serwer MCP – proces odpowiedzialny za komunikację z zewnętrznym API (np. GitHub, Slack, system plików)
2. Klient MCP – warstwa pośrednia w aplikacji AI (Claude Desktop, Cursor, Windsurf)
3. Protokół – standardowa wymiana JSON-RPC przez stdio/HTTP/SSE

Ekosystem MCP (2025)

Stan na marzec 2025:

• 8941+ repozytoriów na GitHubie z tagiem "mcp"
• Wsparcie: Claude Desktop, ChatGPT, Cursor, Zed, Windsurf, VSCode (Copilot)
• Oficjalne serwery: GitHub, Google Drive, Slack, Postgres, Puppeteer, Brave Search
• Społeczność: ponad 300 nieoficjalnych integracji

Brzmi imponująco, prawda? Zobaczmy, gdzie tkwi problem.

Problem #1: zużycie tokenów

Największy ból głowy: serwery MCP często zwracają gigantyczne pakiety JSON, które zjadają context window agenta AI.

Przykład: pull requesty w GitHubie

Zapytanie: "Pokaż mi nazwy otwartych PR-ów w repozytorium X"

Wariant z MCP

// Odpowiedź serwera MCP (~500 tokenów)
{
  "pulls": [
    {
      "id": 1234567890,
      "node_id": "PR_kwDOABCD123",
      "number": 42,
      "state": "open",
      "locked": false,
      "title": "Fix authentication bug",
      "user": {
        "login": "devuser",
        "id": 98765,
        "node_id": "MDQ6VXNlcjk4NzY1",
        "avatar_url": "https://...",
        "gravatar_id": "",
        "url": "https://api.github.com/users/devuser",
        "html_url": "https://github.com/devuser",
        // ... 20+ dodatkowych pól
      },
      "body": "This PR fixes a critical authentication bug...",
      "created_at": "2025-03-01T10:00:00Z",
      "updated_at": "2025-03-07T14:30:00Z",
      "closed_at": null,
      "merged_at": null,
      "merge_commit_sha": null,
      "assignee": { /* ... kolejne 20+ pól ... */ },
      "assignees": [ /* ... */ ],
      "requested_reviewers": [ /* ... */ ],
      "labels": [ /* ... */ ],
      "milestone": null,
      "_links": { /* ... */ },
      // ... i tak dalej
    },
    // ... więcej PR-ów
  ]
}

Agent dostaje: Pełne obiekty z dziesiątkami nieużywanych pól. Context window zapełnia się błyskawicznie.

Wariant z CLI

# Komenda CLI (50 tokenów na wyjściu)
gh pr list --state open --json number,title

[
  {"number": 42, "title": "Fix authentication bug"},
  {"number": 43, "title": "Add dark mode"},
  {"number": 44, "title": "Update dependencies"}
]

Agent dostaje: Tylko to, czego potrzebuje. 90% mniej tokenów.

Wpływ w prawdziwym świecie: monorepo Nx

Zespół Nx testował swoje narzędzia MCP na różnych zadaniach. Wyniki:

• Proste pytania i odpowiedzi: MCP minimalnie drożej (więcej narzutu JSON)
• Złożone zadania: MCP znacznie drożej (duże pakiety danych × wiele wywołań)
• Kompromis tokenowy: wzorzec Skills konsumuje więcej tokenów na początku (agent czyta dokumentację), ale daje lepsze rezultaty (dokładność, użycie generatorów, weryfikacja)

Kluczowy wniosek: Nie chodzi tylko o surową liczbę tokenów – chodzi o jakość wykonania zadania w proporcji do zużytych tokenów.

Problem #2: bezpieczeństwo i złożoność wdrożenia

MCP = uruchomiony serwer

Każdy serwer MCP to osobny proces działający na stałe w tle:

# Typowy serwer MCP
node mcp-github-server.js
  ↳ Nasłuchuje na porcie 3000...
  ↳ Serwer websocket uruchomiony...
  ↳ Middleware uwierzytelniania aktywny...

Implikacje bezpieczeństwa:

1. Otwarty port (stdio/HTTP/SSE) – dodatkowa powierzchnia ataku
2. Trwały proces – musi być nadzorowany (systemd, pm2, Docker)
3. Zarządzanie danymi uwierzytelniającymi – tokeny/klucze muszą być dostępne dla długo działającego procesu
4. Izolacja sieciowa – trzeba zarządzać komunikacją między serwerami

CLI = izolacja procesów

Narzędzia CLI działają w modelu "wykonaj i zakończ":

# Komenda CLI
gh api /repos/owner/repo/pulls --jq '.[].title'
  ↳ Proces startuje
  ↳ Wykonuje zapytanie HTTP
  ↳ Zwraca JSON
  ↳ Proces kończy pracę (czas całkowity: 0,3s)

Zalety bezpieczeństwa:

1. Brak trwałego procesu – nie ma czego atakować po zakończeniu
2. Uprawnienia na poziomie systemu operacyjnego – OS zarządza dostępem
3. Zarządzanie danymi uwierzytelniającymi – tokeny w systemowym pęku kluczy (macOS Keychain, Linux Secret Service)
4. Sandboxing – łatwo uruchomić w izolowanym środowisku (kontener, VM)

Porównanie wdrożenia

Cytat z Nx: "Dlaczego mielibyśmy utrzymywać 15 serwerów MCP, skoro gh, git, npm są już zainstalowane i działają?"

Narzędzia CLI: naturalna alternatywa

Dlaczego CLI jest naturalne dla agentów AI?

Współczesne agenty AI (Claude Sonnet 4.5, GPT-5, Gemini Pro) są natywnie wytrenowane na używaniu CLI. Nie potrzebują żadnego dodatkowego "tłumacza" – po prostu wiedzą jak:

# Wykonanie przez agenta (prawdziwy przykład z Claude)
$ git log --oneline --since="2 weeks ago" | wc -l
42

$ npm run test -- --changed

$ docker ps --filter "status=running" --format "{{.Names}}"

Duże modele językowe widziały miliardy linii dokumentacji CLI, stron man, przykładów ze StackOverflow podczas treningu. To jest ich język ojczysty.

Ekosystem: co już istnieje

Większość środowisk deweloperskich ma już zainstalowane:

Stabilność API: Te narzędzia mają lata zgodności wstecznej. git z 2015 roku nadal działa identycznie. MCP? Zmiany łamiące co kilka miesięcy.

CLI + jq: precyzyjna ekstrakcja

Kombinacja CLI + jq pozwala na chirurgiczne wyciąganie danych:

# Tylko aktywne pipeline'y CI/CD z ostatnich 24h
gh api /repos/owner/repo/actions/runs \
  --jq '[.workflow_runs[]
    | select(.status == "in_progress")
    | select(.created_at > (now - 86400 | todate))
    | {id, name, status, created_at}]'

Wyjście: Precyzyjnie to, czego potrzebujesz. Zero narzutu. Zero dodatkowych tokenów.

Wzorzec SKILLS.md: uczenie zamiast narzędzi

Kluczowe odkrycie: agenty AI działają lepiej, gdy dostają wiedzę domenową zamiast surowych narzędzi.

Czym jest SKILLS.md?

SKILLS.md to plik dokumentacji dla konkretnego narzędzia stworzony specjalnie dla agentów AI. Zamiast:

"Tu masz funkcję listPullRequests(repo, state) – wywołaj ją"

Mówisz:

"KIEDY chcesz zobaczyć otwarte PR-y, użyj gh pr list --state open --json number,title. JAK filtrować: --author, --label, --search. DLACZEGO: Zwraca minimalny JSON – oszczędza tokeny. PRZYKŁADY: [3 prawdziwe przypadki użycia]"

Skills vs MCP: podejście Anthropic

Pomyśl o tym jak o różnicy między:

• MCP: Podanie komuś klucza (narzędzie)
• Skills: Nauczenie ich, jak być mechanikiem (wiedza)

Dane z testów Nx:

Największa różnica dla mniejszych modeli (Haiku, GPT-5-mini) – wzorzec Skills rekompensuje brak mocy obliczeniowej poprzez lepszą edukację.

Prawdziwy przykład z Nx: umiejętność generatorów

# UMIEJĘTNOŚĆ: Generatory Nx

## Kiedy używać

Gdy użytkownik chce:
- Stworzyć nową bibliotekę/komponent/aplikację
- Wygenerować standardową strukturę kodu
- Postępować zgodnie z konwencjami workspace

## Jak wykonać

```bash
# Lista dostępnych generatorów
nx list

# Pokaż opcje generatora
nx g @nx/react:component --help

# Wykonaj z dry-run najpierw
nx g @nx/react:component mycomp --dry-run

# Wykonaj na prawdę
nx g @nx/react:component mycomp

Dlaczego to działa

• --dry-run zapobiega błędom (AI może zweryfikować przed wykonaniem)
• Nazwy generatorów podążają za wzorcami (AI może wywnioskować)
• Wyjście JSON możliwe do sparsowania: --json | jq '.changes'

Typowe wzorce

1. Moduł funkcji: nx g @nx/react:lib feature-auth --directory=libs/features
2. Komponent UI: nx g @nx/react:component Button --project=shared-ui
3. Test E2E: nx g @nx/cypress:e2e my-app-e2e

Obsługa błędów

Jeśli generator zawiedzie, sprawdź:

• Czy docelowy projekt istnieje? nx show project <nazwa>
• Czy generator jest zainstalowany? nx list @nx/react

**Wynik**: Agent wie **KIEDY**, **JAK**, **DLACZEGO** używać generatora. Nie tylko "że może".

### Ładowanie przyrostowe

Skills są ładowane **na żądanie**:

```bash
# Agent nie widzi WSZYSTKICH umiejętności na początku
# Dopiero gdy potrzebuje:

Agent: "Muszę popracować z PR-ami GitHuba"
  ↓
System: [ładuje github-pr.skills.md]
  ↓
Agent: [czyta 200 tokenów wiedzy domenowej]
  ↓
Agent: "Ah, powinienem użyć `gh pr list --json`"

MCP: Agent dostaje wszystkie dostępne funkcje na start (listowanie zasobów = 1000+ tokenów).

Skills: Agent dostaje tylko to, czego potrzebuje (przyrostowo = 50-200 tokenów per umiejętność).

Studium przypadku: Nx.dev – "Dlaczego usunęliśmy większość naszych narzędzi MCP"

W styczniu 2025 Nx opublikował artykuł "Why We Deleted Most of Our MCP Tools" – najlepsze studium przypadku przejścia MCP → Skills + CLI.

Kontekst: pełne przyjęcie MCP → usunięcie

2024 Q3: Nx zbudował pełną integrację MCP:

• Serwery MCP dla: operacji workspace, grafu projektu, generatorów, migracji, analityki CI
• Integracja w Claude Desktop + Cursor + Windsurf
• Oficjalnie rekomendowany sposób pracy z Nx przez AI

2025 Q1: Nx usunął większość narzędzi MCP.

Co zostało: Tylko 2 serwery MCP dla uwierzytelnionych API i uruchomionych procesów.

Dlaczego? 3 główne powody

1. Zmiana paradygmatu: "pytaj i odpowiadaj" → "planuj i wykonuj"

Stara era (2024): Agenty AI jako "mądry chat" – pytasz, dostajesz odpowiedź, kopiujesz do IDE.

Nowa era (2025): Agenty AI jako "autonomiczni deweloperzy" (Claude Code, Cursor Composer) – planują, wykonują, commitują.

Problem MCP: Zaprojektowany dla "pytaj i odpowiadaj". Nie dla "autonomicznego wykonania".

Rozwiązanie CLI: Agenty mogą natywnie wykonywać komendy – to jest ich główna umiejętność.

2. Ekonomika tokenów nie miała sensu

Nx testował na prawdziwych produkcyjnych codebase'ach (Nx Cloud, duże enterprise monorepo).

Dane testowe:

Zadanie: "Wylistuj wszystkie projekty dotknięte zmianami"

Podejście MCP:
  1. Wywołaj listProjects() → 2400 tokenów (wszystkie projekty z metadanymi)
  2. Wywołaj getGraph() → 1800 tokenów (pełny graf zależności)
  3. Wywołaj listChanges() → 600 tokenów (metadane git diff)
  Razem: 4800 tokenów + przetwarzanie przez agenta

Podejście CLI:
  1. nx show projects --affected → 180 tokenów (tylko nazwy)
  2. (jeśli potrzeba) nx show project <nazwa> --json → 120 tokenów per projekt
  Razem: 180-600 tokenów w zależności od potrzebnej głębokości

Oszczędności: 87-96% mniej tokenów

Cytat z artykułu: "Płaciliśmy za transmisję danych, których nie potrzebowaliśmy."

3. Skills przewyższyły MCP (empirycznie)

Nx przeprowadził kontrolowane eksperymenty porównujące MCP vs Skills:

Konfiguracja testu:

• 50 zadań na podejście (generatory, naprawy CI, refaktoryzacja, testowanie)
• 4 modele: Claude Sonnet, Haiku, GPT-4, Gemini Pro
• Metryki: dokładność (poprawne wyjście), odpowiednie użycie narzędzi, kroki weryfikacji

Wyniki (zagregowane):

Interpretacja:

• Dokładność: Skills wygrywają przez wiedzę domenową (agent rozumie DLACZEGO)
• Użycie generatorów: Skills uczą KIEDY używać generatorów (MCP tylko że "można")
• Weryfikacja: Wzorzec Skills zachęca do --dry-run, podglądu, testowania
• Koszt tokenowy: Proste zadania taniej z MCP (mniej narzutu), złożone drożej ze Skills ale lepsze rezultaty

Kluczowy cytat: "Nie optymalizujemy pod tokeny. Optymalizujemy pod poprawne wykonanie zadania. Skills wygrywają."

Największy wpływ: mniejsze modele

Claude Haiku (szybki, tani model):

• Dokładność MCP: 71%
• Dokładność Skills: 89%
• Delta: +18%

Dlaczego? Haiku ma mniej mocy obliczeniowej – potrzebuje więcej wskazówek. Wzorzec Skills mu to daje.

Sonnet/GPT-4 też lepsze ze Skills, ale delta mniejsza (+5-7%) – silniejsze modele radzą sobie z surowymi narzędziami.

Implikacja biznesowa: Wzorzec Skills pozwala używać tańszych modeli z lepszymi rezultatami.

Co zostało w MCP?

Nx nie usunął wszystkiego. Zostały 2 przypadki użycia:

1. Uwierzytelnione API

// MCP: API Nx Cloud (prywatne, uwierzytelnione)
{
  "command": "node",
  "args": ["nx-cloud-mcp-server.js"],
  "env": {
    "NX_CLOUD_TOKEN": "***"
  }
}

Dlaczego MCP? API Nx Cloud wymaga:

• Przepływ OAuth
• Rate limiting
• Obsługa webhooków
• Aktualizacje w czasie rzeczywistym (SSE)

Alternatywa CLI? Możliwe, ale wymagałoby zbudowania własnego narzędzia CLI od zera. MCP daje to "out of the box".

2. Uruchomione procesy

// MCP: Monitoring serwera deweloperskiego
{
  "command": "node",
  "args": ["nx-dev-server-mcp.js"]
}

Przypadek użycia: Agent monitoruje wyjście nx serve, restart przy błędzie, koordynacja hot reload.

Dlaczego MCP? Komunikacja z długo działającym procesem – CLI kończy pracę po wykonaniu, MCP utrzymuje połączenie.

Zasada Nx: "Skills dla wiedzy, MCP dla łączności"

Finalna architektura:

┌─────────────────────────────────────────────┐
│         Agent AI (Claude/GPT)               │
└───────────┬────────────────────┬────────────┘
            │                    │
    ┌───────▼───────┐    ┌──────▼──────────┐
    │  Skills.md    │    │  MCP (minimal)  │
    │  (wiedza)     │    │  (łączność)     │
    └───────┬───────┘    └──────┬──────────┘
            │                    │
    ┌───────▼───────┐    ┌──────▼──────────┐
    │ Narzędzia CLI │    │  API Nx Cloud   │
    │  nx, git, jq  │    │  Serwery dev    │
    └───────────────┘    └─────────────────┘

Reguła decyzyjna:

1. Czy da się zrobić w CLI? → Użyj Skills + CLI
2. Potrzebne uwierzytelnianie/długo działający? → Użyj MCP
3. Przypadek graniczny? → Domyślnie CLI (prostsze)

Kiedy czego użyć: framework decyzyjny

Na podstawie studium przypadku Nx + danych społeczności, oto drzewo decyzyjne:

Użyj CLI + Skills gdy:

1. Narzędzie już istnieje (gh, docker, kubectl, npm, git)
2. Dane można filtrować (wystarczy jq, grep, awk)
3. Brak potrzeby uwierzytelniania LUB standardowy auth (pęk kluczy OS)
4. Krótkotrwałe operacje (sekundy do minut)
5. Proste parsowanie (JSON, CSV, zwykły tekst)

Przykłady:

• Operacje GitHuba → użyj CLI gh
• Operacje git → użyj poleceń git
• Zarządzanie pakietami → użyj npm/yarn
• Operacje na kontenerach → użyj CLI docker
• Operacje w chmurze → użyj CLI aws/gcloud/az

Użyj MCP gdy:

1. Złożone uwierzytelnianie (OAuth, SAML, wieloetapowe)
2. Potrzebne aktualizacje w czasie rzeczywistym (webhooki, SSE, websockets)
3. Wymagane połączenie stanowe (pooling bazy danych, sesje)
4. Długo działające procesy (monitoring, serwery dev)
5. Narzędzie CLI nie istnieje I budowanie go jest złożone

Przykłady:

• Prywatne uwierzytelnione API (Nx Cloud, narzędzia wewnętrzne)
• Monitoring w czasie rzeczywistym (serwery dev, pipeline'y CI/CD)
• Połączenia z bazą danych (pooling połączeń ważny)
• Złożone przepływy API (bot Slack, formularze wieloetapowe)

Macierz porównawcza

Wynik: CLI 9 – MCP 2

Podejście hybrydowe (rekomendowane)

Nie "CLI vs MCP" – raczej "CLI + MCP".

Przykład Gemini CLI:

# Hybrydowe podejście Google
gemini-cli configure
  ↓
Używa: CLI dla operacji lokalnych (odczyt plików, git)
       MCP dla API Gemini (uwierzytelnione, czas rzeczywisty)
       Skills dla wiedzy domenowej (kiedy czego użyć)

Architektura Nx:

// nx-workspace.skills.md uczy agentów:
// "Użyj CLI `nx` dla 99% operacji"
// "Użyj MCP tylko dla uwierzytelnionego API Nx Cloud"

Wynik: Najlepsze z obu światów – efektywność gdzie możliwe, łączność gdzie potrzebna.

Przewodnik implementacji: dodawanie wsparcia CLI dla agentów AI

Masz istniejące narzędzie CLI i chcesz je zrobić "przyjaznym dla agentów AI"? Oto jak.

1. Flaga wyjścia JSON

Dodaj flagę --json dla każdej komendy:

// Przed (czytelne dla człowieka)
$ moje-narzedzie list-items
✓ Item 1: Aktywny
✓ Item 2: Oczekujący
✓ Item 3: Zakończony

// Po (czytelne dla maszyny)
$ moje-narzedzie list-items --json
[
  {"id": 1, "name": "Item 1", "status": "active"},
  {"id": 2, "name": "Item 2", "status": "pending"},
  {"id": 3, "name": "Item 3", "status": "completed"}
]

Implementacja (przykład Node.js):

import { Command } from "commander";

const program = new Command();

program
  .command("list-items")
  .option("--json", "Wyjście jako JSON")
  .action(async (options) => {
    const items = await fetchItems();

    if (options.json) {
      console.log(JSON.stringify(items, null, 2));
    } else {
      items.forEach((item) => {
        console.log(`✓ ${item.name}: ${item.status}`);
      });
    }
  });

Dlaczego to ważne: Agenty AI mogą natywnie parsować JSON – nie potrzeba zewnętrznych zależności.

2. Minimalne wyjście domyślnie

Problem: Narzędzia CLI często zrzucają wszystko.

# Źle: Zwraca wszystko (3000 tokenów)
$ gh api /repos/owner/repo/pulls

# Dobrze: Zwraca tylko to, co potrzebne (200 tokenów)
$ gh pr list --json number,title,author

Zasada: Domyślne wyjście powinno być minimalne – użytkownik może dodać --verbose jeśli potrzebuje więcej.

3. Komponowanie z jq/grep/awk

Zaprojektuj wyjście CLI żeby działało z pipeline:

# Komponowalność
$ moje-narzedzie list --json | jq '.[] | select(.status=="active")'
$ moje-narzedzie list --json | grep "ważne"
$ moje-narzedzie stats | awk '{sum += $2} END {print sum}'

Antywzorzec: Własny język zapytań wewnątrz CLI – niepotrzebne, użyj jq.

4. Obsługa błędów dla agentów

Standardowy format błędów:

// Wyjście błędu (JSON) - zawsze do stderr
{
  "error": "Uwierzytelnianie nieudane",
  "code": "AUTH_ERROR",
  "hint": "Uruchom `moje-narzedzie login` aby się uwierzytelnić"
}

// Wyjście sukcesu (JSON) - zawsze do stdout
[{ "id": 1, "name": "Item 1" }]

Dlaczego osobne strumienie? Agent może:

# Przechwyć wyjście
result=$(moje-narzedzie list --json 2>/dev/null)

# Przechwyć błędy
errors=$(moje-narzedzie list --json 2>&1 >/dev/null)

5. Utwórz SKILLS.md

Struktura pliku:

# UMIEJĘTNOŚĆ: [Nazwa narzędzia]

## Kiedy używać

[Opisz przypadki użycia - KIEDY agent powinien użyć tego narzędzia]

## Komendy

### [nazwa-komendy]

**Cel**: [Co robi]
**Użycie**: `moje-narzedzie [komenda] [flagi]`
**Wyjście**: [Przykład struktury JSON]

**Flagi**:
- `--json`: Wyjście JSON
- `--filter`: Filtruj wyniki

**Przykłady**:
[3-5 prawdziwych przykładów]

## Typowe wzorce

[Częste kombinacje, pipeline'y, przepływy pracy]

## Rozwiązywanie problemów

[Typowe błędy + jak naprawić]

Gdzie umieścić: docs/SKILLS.md w repozytorium narzędzia CLI – agenty będą mogły przeczytać przez GitHuba.

6. Bezpieczeństwo: wykonanie w sandboxie

Agenty AI wykonują dowolne komendy – potrzeba zabezpieczeń:

// Wrapper: Bezpieczne wykonanie CLI
import { exec } from "child_process";
import { promisify } from "util";

const execAsync = promisify(exec);

async function executeCliSafely(command: string) {
  // Whitelist dozwolonych komend
  const allowedCommands = ["gh", "git", "npm", "moje-narzedzie"];
  const cmd = command.split(" ")[0];

  if (!allowedCommands.includes(cmd)) {
    throw new Error(`Komenda niedozwolona: ${cmd}`);
  }

  // Ochrona przed timeoutem
  const timeout = 30000; // 30s

  // Wykonaj w izolowanym env
  const result = await execAsync(command, {
    timeout,
    env: {
      // Przekaż tylko niezbędne zmienne env
      PATH: process.env.PATH,
      HOME: process.env.HOME,
    },
    maxBuffer: 1024 * 1024, // max 1MB wyjścia
  });

  return result.stdout;
}

Checklista bezpieczeństwa:

• Whitelist dozwolonych komend
• Limity timeoutu (zapobieganie zawieszeniu)
• Limity rozmiaru wyjścia (zapobieganie wyczerpaniu pamięci)
• Izolacja środowiska (minimalne zmienne env)
• Brak ekspansji shella (użyj exec, nie eval)

7. Testowanie przyjazności dla AI

Scenariusze testowe:

// Test 1: Wyjście JSON możliwe do sparsowania
const output = await executeCliSafely("moje-narzedzie list --json");
const parsed = JSON.parse(output); // Nie powinno rzucić błędu
assert(Array.isArray(parsed));

// Test 2: Komponowalność
const filtered = await executeCliSafely(
  "moje-narzedzie list --json | jq '.[] | select(.status==\"active\")'"
);
assert(filtered.length > 0);

// Test 3: Obsługa błędów
try {
  await executeCliSafely("moje-narzedzie list --invalid-flag");
} catch (err) {
  const error = JSON.parse(err.stderr);
  assert(error.code === "INVALID_FLAG");
}

Integracja CI: Uruchom te testy w GitHub Actions – każdy PR musi je przejść.

Przyszłość: konwergencja, nie konkurencja

Teza: CLI i MCP nie konkurują – zbiegają się w architekturę hybrydową.

Trend #1: MCP staje się lżejszy

Rekomendacja Anthropic (grudzień 2024):

"Zamiast zwracać pełne obiekty, rozważ zwracanie minimalnych danych i pozwól agentom wykonywać komendy CLI po szczegóły."

Przykład: Serwer MCP GitHub nowa wersja (v2.0):

// Stara (v1.0): Zwróć wszystko
{
  "tool": "github_list_prs",
  "returns": [/* 50+ pól per PR */]
}

// Nowa (v2.0): Zwróć wskaźniki + CLI
{
  "tool": "github_list_prs",
  "returns": [
    {"number": 42, "cli_command": "gh pr view 42 --json"}
  ]
}

Wynik: MCP jako katalog + wskaźniki, CLI jako warstwa wykonania.

Trend #2: Narzędzia CLI dodają endpointy MCP

Odwrotny ruch: Narzędzia CLI dodają opcjonalne serwery MCP dla zaawansowanych przypadków użycia.

Przykład: AWS CLI v3 (roadmap 2025):

# Tradycyjne CLI
$ aws s3 ls

# Nowe: Tryb serwera MCP
$ aws mcp-server start --port 3000
  ↳ Ekspozycja: Zdarzenia S3 w czasie rzeczywistym (PutObject, DeleteObject)
  ↳ Utrzymanie: Streaming logów CloudWatch
  ↳ Zapewnienie: Uwierzytelniona sesja (bez ponownego auth per zapytanie)

Przypadek użycia: Długotrwałe operacje gdzie CLI execute-and-exit nie wystarcza.

Trend #3: SKILLS.md jako standard

Rosnący ruch: SKILLS.md jako standard dokumentacji dla agentów AI.

Repozytoria już przyjmujące (marzec 2025):

• Nx (nx-workspace.skills.md)
• GitHub CLI (gh-cli.skills.md)
• Docker CLI (docker.skills.md utrzymywany przez społeczność)
• Kubernetes (kubectl.skills.md w k8s/website)

Propozycja: Standard W3C "Agent Skills Specification" (etap draftu) – standardowy format dla SKILLS.md.

Trend #4: Integracja z IDE

VSCode Copilot (insider builds 2025):

• Automatyczne odkrywanie SKILLS.md (w katalogu głównym workspace)
• Wykonanie CLI w zintegrowanym terminalu (Copilot może wykonywać)
• Fallback MCP dla API bez CLI

Cursor / Windsurf: Podobna architektura – CLI najpierw, MCP dla uwierzytelnionych.

Wynik: Doświadczenie dewelopera nie wymaga ręcznej konfiguracji – wszystko auto-wykrywane.

Przewidywanie: stan w 2026

Do końca 2026:

1. 80% operacji agentów AI przez CLI + Skills
2. 20% przez MCP (uwierzytelnione API, czas rzeczywisty)
3. SKILLS.md szeroko przyjęty (de-facto standard)
4. Protokół MCP ustabilizowany (v2.0 z zakończonymi zmianami łamiącymi)
5. Hybrydowe domyślnie w głównych IDE (VSCode, Cursor, Zed)

Zwycięzca: Deweloperzy – mniej narzutu, więcej kontroli, lepsze rezultaty.

Podsumowanie: najważniejsze wnioski

1. CLI + Skills > MCP w większości przypadków

Dane empiryczne (Nx):

• 88% dokładność vs 81% (Skills)
• 80-95% mniej tokenów (CLI)
• Lepsze bezpieczeństwo (izolacja procesów)
• Prostsze wdrożenie (już zainstalowane)

2. MCP nie jest zły – jest nadużywany

MCP ma sens dla:

• Uwierzytelnionych API (OAuth, wieloetapowe)
• Komunikacji w czasie rzeczywistym (SSE, websockets)
• Długo działających procesów (serwery dev, monitoring)

MCP nie ma sensu dla:

• Operacji GitHub → użyj CLI gh
• Operacji git → użyj poleceń git
• Operacji w chmurze → użyj CLI aws/gcloud/az
• Zarządzania pakietami → użyj npm/yarn

3. Wzorzec Skills = game changer

Dlaczego Skills wygrywają:

• Uczą KIEDY używać narzędzia (MCP tylko "że można")
• Ładowanie przyrostowe (tylko co potrzebne)
• Lepsze dla mniejszych modeli (+18% dokładność Haiku)
• Wiedza domenowa > surowe narzędzia

4. Podejście hybrydowe to droga

Nie "vs" ale "+":

Skills.md → CLI → Wykonanie (99% przypadków)
                ↓
              MCP → Uwierzytelnione API (1% przypadków)

Zasada Nx: "Skills dla wiedzy, MCP dla łączności"

5. Twoje punkty akcji

Jeśli budujesz narzędzie CLI:

1. Dodaj flagę --json
2. Minimalne wyjście domyślnie
3. Utwórz SKILLS.md
4. Testuj z agentami AI

Jeśli używasz MCP:

1. Sprawdź czy CLI nie wystarczy
2. Jeśli tak – przejdź na CLI + Skills
3. Jeśli nie – zostań przy MCP ale opt-in

Jeśli konfigurujesz agenty AI:

1. Preferuj CLI over MCP (gdzie możliwe)
2. Użyj MCP tylko gdzie niezbędne
3. Utwórz SKILLS.md dla niestandardowych narzędzi

Zasoby

Oficjalna dokumentacja

1. Model Context Protocol (MCP)

   • Oficjalna dokumentacja
   • Organizacja GitHub
   • Specyfikacja

2. Badania Anthropic

   • Blog ogłoszeniowy MCP
   • Najlepsze praktyki wykonywania kodu

3. GitHub CLI

   • Dokumentacja gh
   • Przewodnik wyjścia JSON

Studia przypadków i artykuły

4. Nx.dev: "Why We Deleted Most of Our MCP Tools"

   • Pełny artykuł
   • Must-read – najlepsze studium przypadku przejścia MCP → CLI
   • Zawiera: testy porównawcze, wykresy dokładności, dane produkcyjne

5. Google Gemini CLI

   • Ogłoszenie
   • Podejście hybrydowe: CLI + MCP

Społeczność i narzędzia

6. Ekosystem MCP

   • Awesome MCP – lista 300+ serwerów społeczności
   • MCP Hub – oficjalne serwery

7. Przykłady SKILLS.md

   • Umiejętności workspace Nx
   • Umiejętności GitHub CLI

8. Narzędzia CLI dla agentów AI

   • jq – procesor JSON
   • fx – interaktywny JSON
   • glow – renderer Markdown

Dalsza lektura

9. Badania efektywności tokenowej

   • Anthropic: Redukcja użycia kontekstu
   • Analiza użycia tokenów MCP vs CLI (własne badanie w tym artykule)

10. Najlepsze praktyki bezpieczeństwa

    • OWASP: Bezpieczeństwo agentów AI
    • Sandboxing wykonania CLI

11. Przyszłość agentów AI

    • Ogłoszenie Claude Code
    • Cursor Composer
    • Era autonomicznych agentów (paradygmat planuj i wykonuj)