Są takie momenty, kiedy trafiasz na technologię i od razu czujesz, że to jest przyszłość.
Dla mnie jednym z takich tematów jest MCP, czyli Model Context Protocol. Sama idea jest super. Bierzesz asystenta AI, podpinasz go do prawdziwego systemu i nagle zamiast klikać po konsoli albo ręcznie sklejać kolejne komendy, możesz po prostu zapytać:
- “pokaż mi regiony AWS”,
- “znajdź nieużywane wolumeny EBS”,
- “wylistuj klastry ECS”,
- “sprawdź konfigurację RDS”.
Brzmi dobrze.
I co najważniejsze: to naprawdę działa.
Problem zaczyna się dopiero wtedy, kiedy próbujesz uruchomić AWS MCP Server w Codexie i okazuje się, że droga od “to powinno być proste” do “wreszcie działa” jest dziwnie długa.
TL;DR
Finalnie wszystko uruchomiłem poprawnie, ale zajęło to wyraźnie więcej czasu, niż powinno. Główny powód był bardzo prosty: dokumentacja AWS nie mówi wystarczająco jasno, że w praktyce często trzeba jawnie wskazać profil AWS przez --profile.
I to jest właśnie ten typ problemu, który zjada czas nie dlatego, że jest trudny, tylko dlatego, że jest źle opisany.
Na pierwszy rzut oka wszystko wygląda sensownie
AWS publikuje dokumentację do MCP Server i kiedy ją czytasz, możesz mieć wrażenie, że temat jest dość prosty. Jest config, jest klient, jest serwer, jest przykład, więc teoretycznie powinno to ruszyć bez większego dramatu.
Tyle że ten opis zakłada dość sterylne środowisko.
A prawdziwe środowisko pracy z AWS bardzo rzadko jest sterylne.
Jeśli pracujesz zawodowo z chmurą, to zwykle nie masz jednego konta, jednego profilu i jednego prostego setupu. Masz kilka kont, kilka profili, czasem SSO, czasem direnv, czasem jakieś lokalne workflowy, które działają świetnie w terminalu, ale już niekoniecznie poza nim.
No i wtedy zaczyna się zabawa.
Objawy wcale nie wskazywały na prawdziwą przyczynę
U mnie Codex próbował uruchomić serwer MCP, ale kończyło się to błędami w stylu:
1 | MCP startup failed |
To są dokładnie takie komunikaty, które nic sensownego nie mówią.
Na tym etapie bardzo łatwo założyć, że problem jest w MCP, w Codexie, w uvx, w samym configu albo w jakimś niuansie JSON-RPC. Czyli klasyczny debugging po omacku, gdzie człowiek przez chwilę strzela we wszystko, bo jeszcze nie wie, z której strony naprawdę go boli.
A prawda była dużo bardziej przyziemna.
Faktyczny problem nie miał nic wspólnego z “magią AI”
Po zajrzeniu do logów wyszło:
1 | No AWS credentials found. |
I to był cały sekret.
W terminalu wszystko działało poprawnie, bo shell miał ustawiony kontekst AWS. W moim przypadku było to związane z profilem:
1 | AWS_PROFILE=MyBedrock |
Natomiast Codex uruchamiał proces MCP we własnym środowisku i tego kontekstu po prostu nie widział.
Czyli sytuacja była absurdalnie prosta: ręcznie działało, z poziomu Codexa nie działało. Nie dlatego, że MCP było zepsute, tylko dlatego, że proces startował bez credentiali, do których ja byłem już przyzwyczajony w shellu.
To jest zresztą bardzo zdradliwy rodzaj błędu. Wszystko wygląda tak, jakby działało. AWS CLI działa. Ręczne odpalenie też działa. A potem jedno konkretne narzędzie wywala się na starcie i przez chwilę nie wiadomo dlaczego.
Rozwiązanie okazało się banalne
W moim przypadku wystarczyło po prostu jawnie wskazać profil AWS w konfiguracji MCP.
W ~/.codex/config.toml skończyło się to tak:
1 | [mcp_servers.aws-mcp] |
Po tej zmianie wszystko ruszyło od razu.
I tutaj dochodzimy do sedna. Sam problem nie był trudny. Problem polegał na tym, że dokumentacja nie przygotowała mnie na najbardziej normalny scenariusz pracy.
I właśnie dlatego uważam, że dokumentacja tutaj zawodzi
Nie chodzi mi nawet o to, że brakuje jakiegoś wielkiego podręcznika. Bardziej o to, że pominięto coś, co dla wielu ludzi jest absolutnie podstawowe.
Jeśli pracujesz jako konsultant AWS, architekt, DevOps albo FinOps engineer, to świat jednego konta i jednego profilu po prostu nie istnieje. Masz kilka środowisk, kilku klientów, czasem produkcję, czasem sandbox, czasem własne konto labowe. To nie jest edge case. To jest normalna codzienność.
Dlatego brak prostego komunikatu w stylu: “jeśli klient MCP nie dziedziczy credentiali z Twojego shella, podaj --profile jawnie” jest dla mnie dużym minusem. Taka jedna uwaga mogłaby oszczędzić ludziom naprawdę sporo czasu.
direnv tylko dodatkowo miesza w obrazie
U mnie dochodzi jeszcze direnv, więc sytuacja robi się jeszcze bardziej życiowa.
direnv jest super, bo ustawia zmienne środowiskowe lokalnie dla katalogu i wszystko w terminalu działa dokładnie tak, jak chcesz. Tylko że aplikacja GUI nie musi tego środowiska dziedziczyć. I wtedy cały misternie ustawiony kontekst nagle wyparowuje.
Ze względu na to od kilku lat dosłownie we wszystkich moich projektach i każdemu polecam direnv.
Czy direnv był tutaj częścią problemu? Tak, jak najbardziej.
Ale właśnie dlatego uważam, że dokumentacja powinna to uwzględniać. To nie jest żadna egzotyczna konfiguracja dla trzech nerdów na krzyż. To jest całkiem normalny sposób pracy.
Największa słabość nie dotyczy jednak samego startu serwera
Dla mnie dużo ciekawszy jest inny problem. Nawet jeśli już wiesz, że trzeba podać --profile, to cały model pracy nadal jest dość toporny.
Bo co właściwie robisz? W praktyce wpisujesz w configu jeden profil i tyle. To może działać, jeśli siedzisz cały czas na jednym koncie. Tylko że dla wielu ludzi to kompletnie nierealny scenariusz.
Dzisiaj pracujesz na jednym koncie klienta, jutro na drugim, za chwilę zaglądasz na własne konto, potem na produkcję, potem na sandbox. I co wtedy? Masz ręcznie przepisywać config? Trzymać kilka wariantów? Przełączać się między wpisami? To wszystko jest do zrobienia, tylko że UX jest po prostu słaby.
I tutaj dochodzę do rzeczy, która moim zdaniem powinna być zrobiona zupełnie inaczej.
Co AWS naprawdę powinno z tym zrobić
Gdybym miał wskazać jedną zmianę, to nie zaczynałbym od kolejnej sekcji troubleshooting w dokumentacji. To oczywiście też by się przydało, ale dla mnie ważniejsze jest coś innego.
Sam serwer MCP powinien umieć odczytać profile z ~/.aws/credentials i ~/.aws/config, a potem sensownie z nich korzystać.
To znaczy: nie zmuszać użytkownika do ręcznego wpisywania jednego profilu na sztywno w configu, tylko potraktować profile jako coś normalnego i pierwszorzędnego. Jeśli ktoś ma ich pięć, dziesięć albo piętnaście, to narzędzie powinno to po prostu ogarniać.
W idealnym świecie wyglądałoby to tak, że MCP widzi dostępne profile, LLM patrzy na kontekst rozmowy i w wielu przypadkach sam potrafi zorientować się, o które konto chodzi. Jeśli pytam o produkcję klienta X, to naprawdę nie potrzebuję ręcznie grzebać w configu tylko po to, żeby dojść do właściwego profilu. Model już powinien być w stanie to zawęzić. A jeśli sytuacja jest niejednoznaczna, wtedy dopiero może paść krótkie pytanie doprecyzowujące.
I to byłoby naprawdę sensowne użycie AI.
Bo na dziś wygląda to trochę odwrotnie. Mamy AI, mamy MCP, mamy integrację z prawdziwą infrastrukturą, a człowiek i tak musi ręcznie przepinać profil jak dyżurny w elektrowni z radzieckiego filmu sci-fi. To nie jest przyszłość. To jest półśrodek.
Dla mnie największa wartość takich narzędzi nie polega na samym tym, że model może wywołać API. Największa wartość pojawia się wtedy, kiedy całość działa naturalnie, rozumie kontekst i nie dokłada użytkownikowi zbędnej roboty operacyjnej.
Na razie AWS MCP Server jest jeszcze po tej bardziej surowej stronie.
Czy mimo wszystko warto się tym interesować?
Tak. Zdecydowanie tak.
Bo kiedy już to postawisz i zacznie działać, to od razu widać potencjał. Nagle możesz rozmawiać z infrastrukturą dużo bardziej bezpośrednio. Zamiast skakać po konsoli, klepać kolejne komendy albo ręcznie zbierać dane z kilku miejsc, po prostu pytasz.
I to jest ten moment, w którym człowiek czuje, że to ma sens.
Nie dlatego, że to jest modne. Nie dlatego, że “AI”. Tylko dlatego, że skraca drogę między pytaniem a odpowiedzią. A jak zawsze, właśnie to daje największą produktywność.
Podsumowanie
AWS MCP Server to dla mnie bardzo dobry kierunek. Sama idea jest mocna i uważam, że z takich integracji będzie się korzystało coraz częściej.
Jednocześnie na dziś to nadal jest rozwiązanie, które wymaga od użytkownika zbyt dużo domyślania się rzeczy, które powinny być oczywiste albo załatwione przez narzędzie.
I właśnie to mnie tutaj najbardziej uwiera.
Bo technologia jest naprawdę dobra, tylko wejście w nią nadal wymaga podejścia w stylu: najpierw bądź seniorem od infrastruktury, potem dopiero użytkownikiem.
A szkoda, bo to mogłoby działać dużo bardziej naturalnie już teraz.
