MCP serwery które realnie używam — przegląd po 6 miesiącach

Pół roku temu napisałem post o MCP jako zjawisku. Teraz mogę napisać post o praktyce: które serwery realnie używam codziennie, a które miały dobry pitch ale zniknęły z mojego config'u. Lista skraca się szybciej niż rośnie.

Aktualny stan: 12 serwerów

Co mam podpięte:

Trzy odpiąłem w ostatnim miesiącu: Slack (nie używam), Notion (przeniosłem do Obsidian), GitHub (zastąpiłem gh CLI w bashu).

Co działa najlepiej

Vikunja

Lokalny task tracker. Agent dodaje taski z konwersacji bezpośrednio do tablicy. Najbardziej wartościowy use case: "rozbij ten brief na taski w project X", agent rozumie strukturę i tworzy 5-10 podzadań z odpowiednimi labelkami i priorytetami.

# Komenda do agenta
> Dodaj do projektu "kamilkaletka.dev" taski z dzisiejszego briefu blogowego.
  Dependencies: pierwszy post musi powstać przed kolejką draftów.

Agent woła vikunja_create_task 6 razy z odpowiednią siatką dependencies. Czas: 10 sekund. Bez MCP byłbym 5 minut w UI.

Home Assistant + ha-mcp

Dwa różne serwery. Oficjalny (REST API) jest powolny, każde zapytanie to HTTP roundtrip. ha-mcp lokalny działa przez WebSocket, czas reakcji < 50ms.

Codzienne użycia:

• "włącz światło w kuchni" (przed kolacją, agent sterowany Telegramem)
• "zostaw jacuzzi włączone do 20:00" (timer setup)
• "pokaż temperatury wszystkich termostatów" (debug ogrzewania)

Pułapka: termostat łazienkowy raportuje temperaturę × 10. Agent ma zapisane jako reguła (memory), inaczej co tydzień by mówił "łazienka 225 stopni".

Gmail / Calendar

Najlepiej działają jako "search and summarize". Pyta się "co mam dzisiaj" → agent woła Calendar list_events i Gmail search_threads, agreguje, wraca z briefem.

Załączniki nie działają w Gmail MCP. Mam workaround, script który odpala raw API z token.json gdy potrzebuję wysłać PDF.

Co działa średnio

Proxmox

Cenne gdy działa. Tygodniowy use case: "zrób snapshot VM przed update'em". Działa.

Problem: lista 30+ tooli (start_vm, stop_vm, clone_lxc, snapshot...) i agent czasem wybiera niewłaściwy. Złe komendy mogą być destrukcyjne. Gard: hook który wymaga potwierdzenia przy proxmox_delete_* i proxmox_stop_*.

Cloudflare

Tunel + DNS + KV. Konfiguracja prosta, działa stabilnie. Używam głównie do dodawania subdomen dla demo-stron i debugowania routing'u.

> Dodaj subdomenę demo-misiura.kamilkaletka.dev,
  która tunneluje do forge:3052

Dwie tool calls, gotowe. Bez MCP, 5 minut w panelu.

n8n

Generowanie workflow przez prompt. Czasami trafia, czasami przesadza ze złożonością. Najlepszy use case: prototypowanie "gdyby ten event przyszedł, co by się stało", agent generuje szkic, ja go ręcznie czyszczę.

Co odpiąłem

Notion

Brzmiało dobrze, w praktyce: lazy loading API zwraca słabe wyniki, agent traci dużo turnów na nawigację. Przeniosłem wszystkie notatki do Obsidian.

Slack

Przestałem używać Slacka prywatnie. Zostawiłem MCP "na wszelki wypadek", po 3 miesiącach nie wykonałem ani jednego call'a. Odpiąłem.

GitHub MCP

Świetny w teorii, w praktyce gh CLI w bashu jest szybsze. Tool calling przez MCP dodaje latency ~200ms per call, gh w pamięci podręcznej < 50ms. Dla przeglądu PR-ów, odpiąłem.

Czego się nauczyłem

1. Liczba MCP nie świadczy o produktywności. Pół roku temu chciałem mieć "wszystko". Teraz wiem, że każdy serwer to koszt, wczytywany schema, dłuższy prompt cache, więcej decyzji dla modelu. Mniej znaczy lepiej.

2. Lokalne MCP > cloud MCP. Latency robi różnicę. Jeśli mogę uruchomić MCP serwer u siebie (jak ha-mcp lokalny) zamiast korzystać z REST API, wybieram lokalny.

3. Hookuj destrukcyjne MCP. Każdy MCP serwer który może coś usunąć (Proxmox, Cloudflare, db serwery) ma hook walidacyjny. To nie jest paranoja, to konieczność.

4. Mierzy się użycie, nie konfigurację. Co kwartał liczę ile razy każdy serwer został wywołany. Te z 0 callami, odpinam. Brutalny audyt.

Setup w pigułce

Mój .mcp.json (skrót):

{
  "mcpServers": {
    "vikunja": { "command": "vikunja-mcp", "args": [...] },
    "ha-mcp": { "command": "node", "args": ["~/ha-mcp/dist/index.js"] },
    "proxmox": { "command": "proxmox-mcp", "args": [...] },
    "cloudflare": { "command": "cloudflare-mcp", "args": [...] }
  }
}

Uwaga: NO_PROXY, wszystkie wewnętrzne serwery muszą być w NO_PROXY, inaczej SOCKS5 łamie DNS Dockera. Kosztowało mnie pół dnia debugowania.

MCP to nie cel sam w sobie. To kabel między agentem a światem. Im krótszy i prostszy ten kabel, tym lepiej. Jak masz wątpliwości czy dany serwer warto trzymać, odepnij na tydzień. Jak nic nie zauważysz, zostaw odpięty.