Quest 2 – Jak ogarnąć Postman MCP?

Przez /

Postman MCP w praktyce: gdy AI aktualizuje Twoją kolekcję w Postmanie.

Wyobraź sobie, że dodajesz nowy endpoint do API… i w tym samym momencie Twoja kolekcja w Postmanie aktualizuje się sama. Bez klikania. Bez kopiuj-wklej. Bez chaosu. Tylko Ty, VS Code i AI.

Brzmi jak marketing? A jednak. Postman MCP pozwala podejść do Postmana jak do living documentation, którą da się utrzymywać (prawie) tak szybko, jak zmienia się kod.

W tym wpisie pokażę Ci:

  • czym jest MCP i co realnie zmienia w pracy z API,
  • jak dodać Postman MCP do VS Code na dwa sposoby,
  • jak skonfigurować mcp.json (region, toolset, token),
  • jak ułożyć workflow dev + QA w jednym workspace,
  • oraz jakie są realne ograniczenia tej technologii.

TL;DR – moje obserwacje po testach

Działa bardzo dobrze, gdy:

  • masz ściśle określone zadanie,
  • pracujesz z mniejszym API lub kolekcją,
  • importujesz OpenAPI,
  • tworzysz nową kolekcję,
  • budujesz prosty flow z kilku requestów.

Bywa problematyczne, gdy:

  • API jest duże i produkcyjne,
  • agent ma zidentyfikować właściwą kolekcję w rozbudowanym workspace,
  • dodajesz bardziej złożone skrypty testowe.

Najważniejszy wniosek:
👉 Lepiej konfigurować serwer przez mcp.json niż polegać wyłącznie na wtyczce. Daje to większą kontrolę i przewidywalność.

Czym jest MCP?

MCP (Model Context Protocol) to sposób, w jaki model językowy komunikuje się z zewnętrznymi narzędziami.

Dzięki MCP model nie tylko generuje tekst.
Może również wykonywać operacje — jeśli ma dostęp do odpowiednich narzędzi.

W kontekście Postmana oznacza to, że agent może:

  • pobierać kolekcje,
  • aktualizować requesty,
  • tworzyć nowe kolekcje,
  • dodawać testy,
  • pracować na workspace.

To przestaje być „AI jako autocomplete”, a zaczyna być „AI jako operator narzędzi”.

Oczywiście — im więcej narzędzi udostępnisz agentowi, tym większa odpowiedzialność po Twojej stronie.

Jak działa Postman MCP (mental model)

Warto rozumieć, co dzieje się pod maską:

  1. VS Code + agent (np. Copilot/AI) – tu wpisujesz polecenia
  2. MCP Server – pośrednik, który wystawia narzędzia
  3. Postman API – miejsce, gdzie faktycznie wykonywane są operacje
  4. Twój Workspace – gdzie lądują zmiany

MCP to nie „magiczna chmura”.
To zwykły proces/endpoint, który pozwala agentowi wykonywać operacje przez API.

Jak dodać Postman MCP do VS Code?

Masz dwie drogi.

Opcja 1 – Oficjalna wtyczka Postmana

Najprostsza opcja:

  • szybka instalacja
  • działa „out of the box”
  • nie musisz ręcznie konfigurować tokena

Dobra opcja na start i eksperymenty.

Minus? Masz mniejszą kontrolę nad konfiguracją (region, tryb narzędzi itp.).

Opcja 2 – Ręczna konfiguracja przez mcp.json

To podejście polecam, jeśli chcesz używać MCP świadomie.

Dlaczego lepsze?

  • pełna kontrola nad konfiguracją,
  • wybór regionu (EU/US),
  • wybór toolsetu,
  • jawne zarządzanie tokenem,
  • większa przewidywalność.

Przykładowa struktura wpisu w mcp.json:

{
  "servers": {
    "postman": {
      "command": "npx",
      "args": [
        "-y",
        "@postman/mcp-server"
      ]
    }
  }
}

(Oczywiście realna konfiguracja zależy od wybranego trybu i regionu.)

Konfiguracja mcp.json: 3 rzeczy, które mają znaczenie

1. Region, czyli bezpieczeństwo danych.

Jeśli pracujesz komercyjnie, temat regionu nie jest detalem.

Może mieć znaczenie dla:

  • zgodności z regulacjami (np. GDPR),
  • polityk organizacyjnych,
  • miejsca przetwarzania danych.

Jeśli firma działa w UE — wybór regionu EU jest logiczny.

2. Toolset, czyli co może Twój Agent?

To kluczowa decyzja.

Minimal
Podstawowe operacje na Postmanie.
Dobry wybór dla zespołów, które nie chcą dawać agentowi pełnej swobody.

Code
Scenariusze bardziej developerskie.
Przydatne np. gdy frontend konsumuje API i potrzebuje read-only / generowania kodu.

Full
Pełny dostęp do narzędzi.
Największa moc — największa odpowiedzialność.

Zasada jest prosta:
Im większy toolset, tym większy zakres operacji, które model może wykonać.

3. Token – konieczny element

MCP musi uwierzytelnić się wobec Postmana.

Najlepsza praktyka: użyj zmiennej środowiskowej.
Token to klucz do Twojego workspace. Nie commituj go do repo. Traktuj jak hasło.

Playbook dla AI – plik z instrukcjami

Jedna z najważniejszych rzeczy, która stabilizuje pracę z MCP, to plik z instrukcjami.
Np. postman.instructions.md

Co możesz w nim umieścić:

  • workspaceId
  • konwencje nazewnictwa
  • standard struktury kolekcji
  • zasady tworzenia testów
  • konwencje folderów

Dlaczego to ważne?

Bo agent nie zna kontekstu Twojej organizacji.
Bez jasnych zasad będzie działał chaotycznie.

Ten plik to po prostu playbook dla AI. Może pójść dalej i przygotować też własnego agenta!

Dwa szybkie scenariusze

1. Import OpenAPI → gotowa kolekcja

Przykładowy prompt do przygotowania podstawowej kolekcji w oparciu o schemat OpenAPI.

Zaimportuj OpenAPI z http://localhost:3000/api-docs i utwórz kolekcję w workspace X.

Agent skorzysta z dostępnych mu narzędzi – w tym z Postman MCP – i wygeneruje kolekcję requestów. Jest to świetny punkt startowy do pracy z nowym API.

Co warto sprawdzić w trakcie review:

  • czy struktura folderów ma sens?
  • czy requesty mają poprawne przykłady?
  • czy nazwy są spójne?

To moment, w którym zaczynasz widzieć potencjał.

2. Smoke flow

Przykładowy prompt do przygotowania prostego E2E testu API w Postman.

Utwórz folder ‘Smoke’ i dodaj flow: login → create → get → delete. Dodaj podstawowe testy (status 200/201, walidacja body, response time < 500 ms).

Agent utworzy nam osobny folder z requestami połączonymi w jeden flow. W ten sposób może łatwo dodawać nowe scenariusze testowe.

Co warto sprawdzić w trakcie review:

  • czy kolejność ma sens?
  • czy dane są poprawnie przekazywane między requestami?
  • czy testy są realistyczne?

To świetny punkt wyjścia. Oczywiście, testy wygenerowane przez AI warto dokładnie przeanalizować. Natomiast jest to dobre na początek. Można dalej rozwijać to, co wygeneruje AI.

Real talk: gdzie to jeszcze kuleje?

  • Przy dużych API agent potrafi się zgubić.
  • WorkspaceId bywa „niewygrzany” – potrafi pytać o niego kilka razy.
  • Dodawanie złożonych skryptów testowych nie zawsze jest przewidywalne.

To nadal młody ekosystem. Ale potencjał — szczególnie dla zespołów dev + QA — jest bardzo ciekawy. Może znacząco ułatwić aktualizowanie kolekcji po zmianach w API.

Podsumowanie

Jeśli jesteś developerem — Postman MCP może skrócić dystans do QA.
Zmiana w kodzie szybciej trafia do kolekcji.

Jeśli jesteś QA, to narzędzie, które pozwala wpływać na jakość szybciej niż kiedykolwiek.

A jeśli interesuje Cię przyszłość pracy z AI w development workflow — MCP to coś, co naprawdę warto zrozumieć.

Jeżeli chcesz wiedzieć więcej, to zapraszam do oglądania materiałów na moim kanale YouTube.

Przewijanie do góry