TL;DR

MCP zyskuje masową adopcję – Windows Copilot, Google Gemini, OpenAI i Claude już wspierają protokół
Auto-generowanie MCP serverów z OpenAPI to pułapka – LLM gubią się przy zbyt dużej liczbie narzędzi
API z 75-100 endpointami przytłaczają sztuczną inteligencję – potrzeba świadomej selekcji
Opisy API nie pasują do LLM – wymagają bezpośredniego stylu pisania z przykładami
LLM potrzebują zadań, nie zasobów – projektuj workflows zamiast mapować endpointy
Rozwiązanie: hybrydowe podejście – zacznij od auto-generacji, potem drastycznie przytnij
Evals są kluczowe – testuj 1000+ razy, bo LLM nie są deterministyczne

Model Context Protocol (MCP) przestaje być ciekawostką dla entuzjastów AI. Ten stworzony przez Anthropic protokół ma zaledwie 6-7 miesięcy, ale zdobywa masową adopcję wśród największych graczy technologicznych. Podczas gdy wiele firm pospiesznie tworzy MCP servery, David z Neon – serverless postgres provider – ostrzega przed najczęstszym błędem: automatycznym generowaniem ich z istniejących API.

Dlaczego MCP staje się standardem

Tempo adopcji jest oszałamiające. Wczorajszy keynote Satya pokazał, że Windows Copilot wkrótce stanie się klientem MCP. Dziś rano na Google I/O ogłoszono wsparcie dla protokołu w Gemini. OpenAI już go wspiera, a Claude oczywiście od początku.

Wniosek jest prosty: jeśli budujesz aplikację lub usługę i chcesz, żeby LLM mogły z niej korzystać, potrzebujesz MCP servera.

To doprowadziło do pośpiechu w budowaniu MCP serverów. Firmy chcą szybko udostępnić swoje usługi Claude’owi, ChatGPT i innym asystentom AI.

Anatomia MCP servera – co naprawdę liczy się

MCP servery składają się z trzech głównych elementów:

Tools (narzędzia) – najważniejsze, to akcje które LLM może wykonywać
Resources (zasoby)
Prompts (podpowiedzi)

David ma konkretne demo Neon MCP servera działającego w produkcji od ponad miesiąca. W filmiku pokazuje użytkownika Cursor, który prosi: „build me a to do list app, Use Neon Postgres and use Neon Auth.”

Cursor automatycznie interfejsuje z MCP serverem Neon. W kilka minut aplikacja jest w pełni funkcjonalna z prawdziwą, fizyczną bazą danych Postgres i systemem uwierzytelniania NeonAuth.

Ich własny MCP server ma około 500 linii kodu i jest open source. To nie jest gigantyczne przedsięwzięcie, ale nadal wymaga znacznej pracy – projektowania, pisania testów, przemyśleń.

Pokusa szybkiego rozwiązania

Skoro każde API ma schemat OpenAPI opisujący endpointy, wejścia i wyjścia, czemu nie auto-wygenerować z tego MCP servera? Brzmi logicznie.

Powstało już kilka usług ułatwiających ten proces:

Stack
Stainless
Speakeasy
Mintlify

Proces zajmuje mniej niż minutę. Teoretycznie otrzymujesz kompletny MCP server bez wysiłku.

Pierwsza pułapka: chaos wyboru dla LLM

Problem zaczyna się od liczb. Neon API ma 75-100 różnych endpointów. David nie pokazuje ich wszystkich na slajdzie, ale podkreśla: „mamy dużo endpointów”.

LLM są tragicznie złe w wybieraniu z długiej listy narzędzi. Daj im za dużo opcji, a się pogubią.

To paradoks obecnych czasów. Słyszymy o milionowych tokenach, 5-milionowych, nielimitowanych oknach kontekstu. Ale większy kontekst nie oznacza lepszej wydajności.

Prawda jest odwrotna: LLM działają znacznie lepiej z ograniczonym kontekstem.

Auto-wygeneruj MCP server z API i otrzymasz wszystkie endpointy jako narzędzia MCP. LLM nie będą dobrze współpracować z Twoją usługą.

Druga pułapka: język dla ludzi vs LLM

Opisy API w istniejących schematach prawdopodobnie nie są dobrze napisane dla LLM. David podkreśla różnicę:

API są pisane dla ludzi – którzy mogą googlować, szukać informacji, rozumować.

LLM potrzebują większej bezpośredniości i znacznie więcej przykładów niż ludzi.

W Neon piszą opisy narzędzi MCP w XML-u, bardzo zorganizowanie. Dają LLM jak najwięcej kontekstu o każdym narzędziu i kiedy go używać.

To coś, czego prawdopodobnie nie robisz w swoich API dziś.

Pisanie dla LLM to inna gra

David i zespół rozwijają też evals – zasadniczo testy w świecie AI. Sprawdzają, czy LLM wywołują właściwe narzędzie do właściwej pracy.

Uruchamiają te testy 100, 1000, 10,000 razy – bo LLM nie są deterministyczne.

Upewniają się, że narzędzia które eksponują do LLM mają dobre opisy. Iterują nad tymi opisami gdy ich evals ewoluują. To proces, którego nie ma w tradycyjnym projektowaniu API.

Trzecia pułapka: zasoby vs zadania

Większość dzisiejszych API jest projektowana do niskopoziomowego zarządzania zasobami i automatyzacji. Firmy budują API, żeby deweloperzy mogli je wykorzystać do automatyzacji.

Ale LLM potrzebują czegoś innego: zadań, akcji, narzędzi.

LLM są bardziej podobne do ludzi w tym sensie. Nie obchodzi ich niskopoziomowe tworzenie zasobów – chcą osiągnąć konkretny cel.

Projektując MCP server, musisz myśleć o zadaniach, nie o endpointach API. To częściowo dlatego Anthropic stworzył MCP – istniejące schematy OpenAPI nie były przygotowane na taki sposób projektowania.

Studium przypadku: migracje baz danych

David pokazuje konkretny przykład z ich MCP servera. LLM często muszą robić migracje baz danych – tak jak ludzie.

Naiwne podejście: udostępnij jedno narzędzie „Run SQL” i oczekuj, że LLM będą go używać do migracji.

Przemyślane podejście: zbuduj dedykowane narzędzia MCP do migracji baz danych.

Neon ma dwa narzędzia:

prepare_database_migration – przygotowuje migrację
complete_database_migration – kończy migrację

Workflow bezpiecznych migracji

LLM chętnie używają tych specjalistycznych narzędzi zamiast ogólnego „run SQL”.

Oto jak to działa:

Pierwsze narzędzie przygotowuje migrację na tymczasowej gałęzi Neon
System odpowiada LLM: „migracja którą próbujesz uruchomić jest teraz na tej gałęzi”
Zachęca do testowania przed zatwierdzeniem
Instruuje jak zakończyć: „wywołaj complete_database_migration żeby ukończyć zadanie”
LLM może wywołać drugie narzędzie gdy uzna, że jest gotowy

Taki złożony wieloetapowy workflow nie miałby sensu w REST API. Ale to dokładnie to, co ma sens dla LLM.

Szczególnie że LLM nie są zbyt dobre w SQL – więc chcemy pomóc im przetestować SQL zanim zastosują go na głównej gałęzi bazy danych.

Co zrobić z Twoim MCP serverem

David kategorycznie odradza auto-generowanie. Ale rozumie pokusę.

Jego rekomendacja: podejście hybrydowe.

Zacznij od auto-wygenerowania MCP servera z schematu OpenAPI, potem drastycznie go przytnij.

Konkretne kroki:

Usuń jak najwięcej narzędzi. Najgorszą rzeczą jaką możesz dać LLM to za dużo wyboru. Zostaw tylko narzędzia niezbędne do korzystania z LLM.

Oceń opisy wszystkich narzędzi. Przepisz je z myślą o LLM, nie o ludziach.

Pomyśl o ciekawych narzędziach które chciałbyś udostępnić LLM, ale może nie chcesz w API.

Napisz evals. David podkreśla: jeśli budujesz MCP server, powinieneś mieć evals i testy zapewniające, że LLM mogą poprawnie używać Twojego servera.

Praktyczne wnioski z miesiąca w produkcji

David i jego zespół prowadzą MCP server w produkcji od ponad miesiąca. To daje im praktyczną perspektywę na wyzwania:

Pisanie dla LLM wymaga innego mindset. Nie wystarczy skopiować opisów z dokumentacji API.

Testowanie jest kluczowe. Evals muszą być uruchamiane tysiące razy ze względu na niedeterministyczność LLM.

Mniej znaczy więcej. Lepiej mieć 5 doskonale działających narzędzi niż 50 średnich.

Myśl workflows, nie endpointy. LLM chcą wykonywać zadania, nie zarządzać zasobami.

David zajmuje się też autentyfikacją dla MCP – kolejnym obszarem wymagającym przemyślenia przy projektowaniu dla LLM zamiast tradycyjnych API.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: Your API is not an MCP – prezentacja Davida z Neon

Tag: Evals Llm

Dlaczego auto-generowanie MCP serwerów z API to błąd, który kosztuje Cię efektywność LLM #EN103