Serwery MCP stają się platformami z możliwościami, a nie tylko otoczeniami narzędziowymi.
Serwery MCP przekształcają się w platformy z możliwościami: transformacja narzędzi, wyszukiwanie, przestrzenie nazw, proxy, umiejętności, zadania i wersjonowanie, a także informacje o tym, kiedy należy zwlekać.
Źródła: Stop Building AI Apps for Every Idea. Start Building MCP Servers — Part #7
Każdy, kto wprowadzał serwer MCP do środowiska produkcyjnego, zna już listę sprawdzianową: wyraźne umowy między narzędziami, ustrukturyzowane dane wejściowe i wyjściowe, rozsądna semantyka błędów, autoryzacja, możliwość obserwacji, wyraźne rozdzielenie tego, co kontroluje model, od tego, co dostarcza środowisko wykonawcze (identyfikator użytkownika, tenant, role i zakresy uprawnień), autoryzacja w momencie wykonywania oraz model wdrażania, który umożliwia skalowanie. Następna ewolucja to nie nowy protokół transmisji ani kolejna platforma agentów – nie ma to też powodu do przepisywania całego stacku. Chodzi o to, że serwer MCP coraz bardziej przypomina prawdziwą platformę aplikacyjną dla różnych funkcji, a nie prosty punkt końcowy z dodanymi na siłę kilkoma narzędziami.
Różnica staje się istotna, gdy masz dziesiątki narzędzi, kilka serwerów MCP, wiele zespołów, użytkowników z różnymi uprawnieniami, różnorodne klienty, długotrwałe procesy pracy, umiejętności wielokrotnie wykorzystywane, wersje oraz coraz większą ilość kontekstu. W tym momencie pytanie nie brzmi już o to, jak udostępnić funkcję w Pythonie jako narzędzie – staje się ono znacznie szersze:
Jak kształtować, odkrywać, komponować, zarządzać, uruchamiać, obserwować, testować i rozwijać całą powierzchnię możliwości, nie przerzucając ich wszystkich na model?
To jest kierunek, w którym zmierza MCP, a reszta tego tekstu go omawia.
Pierwszy serwer MCP i dzisiejszy serwer MCP to zupełnie różne rozwiązania
Pierwotne przykłady MCP były celowo proste – jeden serwer zawierał zaledwie kilka narzędzi:
MCP server
├── search_documents
├── create_ticket
└── get_customer
Klient wymienił narzędzia, model przeczytał schematy i wybrał jeden, a serwer go uruchomił. W małym systemie taki model myślowy nadal jest właściwy. Przy pięciu prostych narzędziach, jednym backendzie, jednym zespole i jednym przypadku użycia nie potrzeba niczego bardziej skomplikowanego.
A teraz umieść ten sam projekt w prawdziwej firmie:
Salesforce MCP 60 capabilities
GitHub MCP 40 capabilities
Jira MCP 35 capabilities
Google Drive MCP 25 capabilities
Knowledge Base MCP 20 capabilities
Internal Platform MCP 70 capabilities
Reporting MCP 15 capabilities
Admin MCP 30 capabilities
To już nie jest serwer narzędziowy. To ekosystem możliwości. Jeśli po prostu połączysz wszystkie schematy i prześlesz je do modelu, pojawią się trzy problemy: kontekst zostanie utracony jeszcze przed rozpoczęciem zadania, wybór narzędzi stanie się trudniejszy, a model zobaczy funkcje, które mogą być nieistotne, ryzykowne lub mylące dla tego użytkownika i tego procesu pracy.
Ten nacisk jest nam znany z dyskusji na temat bezpieczeństwa i odkrywania, ale ma szersze konsekwencje, które łatwo przeoczyć: katalog narzędzi jest sam w sobie artefaktem inżynieryjnym. Można w nim wyszukiwać, modyfikować, filtrować i nadawać nazwy przestrzeni. Może być budowany na podstawie ofert innych serwerów i może zawierać ponownie wykorzystywalne umiejętności oraz zasoby. Niektóre operacje mogą zostać wstrzymane, aby zadać użytkownikowi pytanie, długotrwałe zadania mogą być przenoszone do tła, umowy mogą mieć wersje, a cała ta struktura może być testowana jak każdy API produkcyjny.
To właśnie ta ewolucja jest przedmiotem poniższych rozdziałów.
FastMCP to jedna z dobrych implementacji tej koncepcji, a nie sama koncepcja
FastMCP pojawia się we wszystkich przykładach, ponieważ jego obecna architektura sprawia, że te wzorce są wyjątkowo widoczne. Dostawcy dostarczają komponenty. Transformacje kształtują wygląd komponentów przed tym, jak zostaną one zobaczone przez klienta. Funkcje wyszukiwania mogą zastąpić ogromny katalog małą interfejsem do odkrywania treści. Proxy’i mogą łączyć inne serwery MCP. Umiejętności mogą stać się zasobami. Powolne operacje mogą być przekształcane w zadania w tle. Wersje mogą współistnieć. A otrzymana interfejs MCP może być testowana za pomocą rzeczywistego klienta, zamiast poprzez bezpośrednie wywoływanie funkcji implementacji.
To przydatne, ale lekcją nie jest to, że „wszyscy powinni przyjąć FastMCP”. Są to wzorce architektoniczne nadające się do ponownego użycia w systemach MCP. Te same koncepcje można zaimplementować w Pythonie, TypeScript, Go, C#, Java, Rust lub na wewnętrznej platformie, przy użyciu innego frameworka, ręcznie napisanych elementów lub zarządzanego bramy. Ważne jest, aby zauważyć, w którą stronę zmierza abstrakcja. Protokół standaryzuje sposób, w jaki klienci komunikują się z funkcjami, natomiast architektura serwera decyduje o tym, jak wygląda ta powierzchnia funkcji, a ta powierzchnia może teraz być znacznie inteligentniejsza niż statyczna lista ozdobionych funkcji.
1. Transformacja narzędzia: API backendu nie powinno automatycznie stawać się API agenta
Jedna z najpraktyczniejszych koncepcji jest jednocześnie jedną z najprostszych. Narzędzie udostępniane przez usługę wyższego poziomu może być technicznie poprawne, a mimo to okazać się kiepskie dla modeli LLM.
Wyobraź sobie wewnętrzną integrację z Salesforce, która umożliwia tę operację:
salesforce_account_query_v2_internal(
q_string,
include_deleted_flag,
tenant_uuid,
raw_fields,
)
Wewnątrz usługi, która ją posiada, taki podpis może być w porządku. Czy model powinien widzieć dokładnie tę umowę? Prawdopodobnie nie. Wersja przeznaczona dla modelu lepiej wyglądałaby w ten sposób:
find_customer_account(
company_name,
include_archived=False,
)
Podstawowa operacja pozostała bez zmian. To, co się zmieniło, to interfejs prezentowany modelowi, a jest to transformacja narzędzia.
FastMCP umożliwia to za pomocą dedykowanej warstwy transformacji: zmiana nazwy narzędzia, przepisanie jego opisu, zmiana nazw argumentów, modyfikacja domyślnych wartości, ukrycie niepotrzebnych argumentów, dostosowanie tagów i adnotacji oraz otoczenie wykonywania w specjalistycznej logice. W skrócie, proces wygląda następująco:
Backend capability
↓
Raw MCP tool
↓
Transformation layer
↓
Agent-facing contract
Istnieje kilka powodów, dla których jest to wartościowe.
Model nie potrzebuje szczegółów dotyczących infrastruktury. Pola takie jak tenant_uuid, internal_region, api_version czy include_deleted_internal_records to sprawa backendu. Gdy model nie powinien decydować o wartości, należy całkowicie wykluczyć tę wartość z jego schematu. Jest to zgodne z zasadą kontekstu czasu wykonywania: zaufane wartości pozostają poza granicami możliwości modelu i nigdy nie pojawiają się w argumentach tworzonych przez model.
Po drugie, nazewnictwo używane przez system źródłowy może pozostać niewidoczne dla agenta. Dostawca lub usługa legendarna może publikować operacje przeznaczone dla programistów, co słabo pasuje do sytuacji, gdy model językowy musi wybierać spośród 80 narzędzi. Brama może zapewnić bardziej uporządkowany słownictwo, bez konieczności proszenia zespołu źródłowego o zmianę nazw API.
Po trzecie, umowa z agentem może pozostać stabilna, podczas gdy backend się zmienia. Ma to większe znaczenie, niż się na pierwszy rzut oka wydaje. Jeśli backend przeniesie się na nową wersję API Salesforce, zmieni nazwę jakiegoś parametru wewnętrznego lub przekształci jedną operację w parę operacji, narzędzie, które widzi model, wcale nie musi ulegać zmianie. Warstwa transformacji pełni rolę warstwy ochronnej pomiędzy tym, kto korzysta z tej funkcjonalności, a tym, kto ją implementuje. To zwykła architektura oprogramowania, po prostu zastosowana teraz do interfejsów skierowanych do agentów.
Umowa backendu służy systemowi, który posiada daną funkcjonalność. To, co prezentuje warstwa MCP, powinno służyć agentowi, który ją wywoła.
2. Szukanie narzędzi: katalog staje się dostępnym kontekstem
Kwestia ta staje się ważna, gdy tylko ekosystem się rozwija. Typowa pierwsza implementacja wygląda w ten sposób:
connect to server
↓
list all tools
↓
put every schema into the model context
↓
ask model to choose
To działa, gdy lista jest krótka, ale staje się coraz mniej efektywne z każdym dodanym narzędziem. Bardziej dojrzałe podejście wygląda tak:
small discovery interface
↓
search relevant capabilities
↓
load only matching schemas
↓
execute
Wyszukiwarka narzędzi FastMCP urzeczywistnia tę koncepcję. Zamiast zwracać pełny katalog, serwer udostępnia syntetyczne narzędzia do odkrywania, takie jak search_tools i call_tool. Obecnie dostępne strategie to dopasowywanie za pomocą regex oraz ranking BM25. BM25 to ranking leksykalny, a nie semantyczne wyszukiwanie wektorowe, ale architektura nie zależy od BM25. Na Twojej własnej platformie ranking może pochodzić od słów kluczowych, embeddingów, hybrydowego mechanizmu wyszukiwania z ponownym rankowaniem, filtrów metadanych, statystyk używania, oceny uwzględniającej zasady, lub indeksu stworzonego specjalnie pod możliwości Twojej dziedziny.
Kluczowym punktem jest to, że narzędzia stają się obiektami dostępnymi do wyszukiwania. Zamiast wypełniać kontekst 300 definicjami narzędzi, model może wywołać search_tools("find customer opportunities and open deals") i otrzymać trzy lub cztery wyniki, na przykład salesforce_find_account, salesforce_list_opportunities oraz salesforce_get_pipeline_summary. Tylko te schematy przechodzą do następnego kroku.
To jest coś więcej niż zwykła oszczędność zasobów. Poprawia to decyzje, przed którymi stoi model. „Wybierz jedną funkcjonalność spośród 300 schematów” oraz „wyświetl funkcjonalności związane z tym zadaniem, a następnie wybierz spośród czterech odpowiednich wyników” to zupełnie różne problemy rozumowania.
Postępowe odkrywanie stanowi również podstawę podejść do wykonywania kodu, ale wyszukiwanie narzędzi jest przydatne nawet wtedy, gdy nigdy nie uruchamiasz kodu napisanego przez model, i działa przy zwykłym wywoływaniu narzędzi. Jedna z zasad bezpieczeństwa musi pochodzić z procesu autoryzacji: należy wyszukiwać w katalogu, który użytkownik ma prawo odkryć, a nie w pełnym katalogu platformy. Jeśli wyszukiwanie pokazuje nazwy i schematy narzędzi administracyjnych niedostępnych dla użytkownika, informacje o ich funkcjach wyciekły, nawet jeśli później odmówiono ich wykonywania. Dlatego rzeczywisty proces wymaga filtru autoryzacyjnego przed wyszukiwaniem.
Można to postrzegać jako inżynierię kontekstu zastosowaną do funkcji.
3. Przestrzenie nazw: kompozycja powoduje problem tożsamości przed problemem skalowania
Gdy zaczynamy łączyć serwery MCP, natychmiast pojawia się niezwykle irytujący problem: każdy serwer ma generyczne nazwy takie jak search, get_user, list_files lub create_note. Po połączeniu serwera Salesforce, serwera Google Drive, serwera bazy wiedzy oraz serwera GitHub, przy czym trzy z nich udostępniają funkcję search, pojawia się mnóstwo pytań. Który search jest wywoływany przez model? Który widnieje w logach? Który jest objęty regułą polityki? Który uległ zmianie po zmianie „odcisku palca” schematu?
Dlatego nazwy przestrzeni są ważne, gdy MCP przestanie być pojedynczym, izolowanym serwerem. FastMCP oferuje transformację nazw przestrzeni, która dodaje przedrostek do komponentów podczas kompozycji, dzięki czemu search staje się salesforce_search, gdrive_search, knowledge_base_search oraz github_search. URI zasobów mogą również mieć nazwy przestrzeni w swojej ścieżce.
Unikanie kolizji to oczywista zaleta. Bardziej subtelna jest kwestia pochodzenia: przedrostek rejestruje źródło danej funkcjonalności, a to źródło służy do tworzenia reguł polityki, śledzenia działań, rozruchu tras, ograniczeń szybkości, określania właściciela, przeprowadzania migracji, debugowania oraz do generowania opisów, które odczytuje model.
Nie przesadzaj jednak. Nazwa taka jak enterprise_internal_platform_team_alpha_salesforce_v2_search_customer nie jest lepsza tylko dlatego, że jest unikalna na całym świecie. Przestrzeń nazw określa tożsamość, a transformacja nadal może sprawić, że ostateczna interfejs będzie przyjazna dla modelu. Są to dwa powiązane, ale odrębne problemy:
Source identity
→ Namespace
Agent usability
→ Transformation
4. Widoczność: inżynieria kontekstu to nie tylko tekst
Gdy mowa o inżynierii kontekstu, większość ludzi myśli o instrukcjach systemowych, pobranych dokumentach, pamięci, historii rozmów oraz ewentualnie opisach narzędzi. Jednak wszystkie możliwości, które model może dostrzec, również stanowią część jego kontekstu.
Weźmy proces badawczy klienta. Co model zrobiłby z narzędziami takimi jak rotate_api_key, terminate_employee, rebuild_search_index, publish_release i admin_delete_tenant, nawet jeśli użytkownik ma prawa do niektórych z nich? Żadne z nich nie służy temu zadaniu. Lepszym rozwiązaniem mogłaby być bardziej uporządkowana struktura:
Customer Research
├── salesforce_find_account
├── salesforce_list_opportunities
├── knowledge_search
├── web_research
└── generate_customer_report
Rozwiązaniem jest widoczność w czasie wykonywania. Funkcja widoczności komponentów w FastMCP umożliwia włączanie i wyłączanie komponentów za pomocą nazwy, klucza lub tagu; wyłączony komponent znika z list i nie może być odnaleziony przez standardowe interfejsy serwera. Zestawy funkcji specyficzne dla procesów pracy, flagi funkcji, różnice środowiskowe, narzędzia beta, okna konserwacyjne, produkty specyficzne dla użytkowników, profile agentów lub po prostu mniejszy zakres działań modelu – wszystko to wykorzystuje ten sam mechanizm:
workflow = customer_research
include:
salesforce.*
knowledge_base.*
reports.*
exclude:
admin.*
deployment.*
hr.*
Różnica w stosunku do zadań związanych z bezpieczeństwem nadal obowiązuje: widoczność nie zastępuje upoważnienia. Widoczność odpowiada na pytanie, czy dana funkcja powinna znajdować się na obecnym interfejsie. Upoważnienie odpowiada na pytanie, czy dany autoryzowany użytkownik faktycznie ma prawo jej używać. Dobra platforma MCP dla przedsiębiorstw zazwyczaj wymaga obu tych elementów – najpierw ogranicza dostępne funkcje, a dopiero potem sprawdza uprawnienia.
5. Proxy MCP: jeden serwer jako brama do innych
W tym momencie projekt staje się naprawdę interesujący. Serwer nie musi posiadać wszystkich funkcji, które oferuje; może pełnić rolę bramy do innych serwerów MCP. Dostawca proxy FastMCP pobiera narzędzia, zasoby i polecenia z odległego serwera MCP i ponownie je publikuje z bieżącego serwera.
Więc prosty łańcuch wygląda tak:
AI client
↓
Salesforce MCP
Może rozwinąć się w bramę obsługującą kilka serwerów wstępnych, a ta brama nie musi kopiować od nich żadnej logiki biznesowej. Proxyuje ich funkcje i otacza je warstwą platformową: autoryzacją, politykami, systemem nazewniczym, widocznością oraz możliwościami monitorowania.
To znacząca zmiana w sposobie projektowania systemów: serwery MCP przestają być oddzielnymi elementami i mogą tworzyć sieć. Jedna zespołów może zajmować się integracją z Salesforce, inny wiedzą projektową, a jeszcze inny operacjami infrastruktury, podczas gdy brama przedsiębiorstwa łączy to wszystko w jedną spójną powłokę produktu, bez konieczności wprowadzania zespołów do wspólnego repozytorium czy cyklu wypuszczania aktualizacji.
Proxy również przynoszą korzyści w mniej oczywisty sposób: łączą różne środki transportu, zapewniają stały punkt końcowy przed ciągle zmieniającymi się serwerami wejściowymi, centralizują proces autoryzacji, ułatwiają monitorowanie, stosują jednolitą politykę, uporządkowują nazwy oraz ukrywają strukturę wewnętrzną przed klientami.
To wszystko nie oznacza, że każda firma potrzebuje jednego ogromnego centralnego bramy. Można uruchomić kilka takich bram, rozdzielonych według dziedzin: inżynieria, sprzedaż, badania, operacje platformy. MCP dostarcza ramy protokołowe, które umożliwiają ich czyste łączenie.
Gdy serwery MCP mogą wzajemnie korzystać z swoich funkcji i je modyfikować, naturalną jednostką projektowania nie jest już pojedynczy serwer, lecz graf zarządzanych możliwości.
6. Umiejętności jako zasoby MCP: serwer może udostępniać wiedzę, a nie tylko konkretne działania
Narzędzia odpowiadają na pytanie, co może robić system. Zasoby odpowiadają na pytanie, jakie informacje może pobrać klient. Umiejętności wprowadzają trzecie pytanie: jak agent powinien wykonać dany rodzaj zadania?
Umiejętność zazwyczaj znajduje się w katalogu: instrukcje wraz z materiałami pomocniczymi, takimi jak przykłady, schematy, skrypty, listy kontrolne, odniesienia lub wskazówki dotyczące danej dziedziny. Tradycyjnie katalogi te znajdowały się w środowisku klienta, w miejscach takich jak ~/.claude/skills/, ~/.cursor/skills/ lub ~/.gemini/skills/. Zamiast tego dostawca umiejętności FastMCP publikuje je jako zasoby MCP, dzięki czemu umiejętność otrzymuje adresy w formie skill://customer-research/..., obejmujące jej główny plik SKILL.md, manifest, plik z przykładami oraz schemat JSON.
To ma większe znaczenie, niż się wydaje, ponieważ serwer może teraz rozpowszechniać wiedzę proceduralną wraz z możliwościami wykonawczymi. Wyobraźmy sobie wewnętrzną platformę badawczą dla klientów, której interfejs MCP oferuje narzędzia takie jak search_salesforce, search_knowledge_base i generate_report, a także informacje o umiejętnościach związanych z definiowaniem kwalifikowanych możliwości biznesowych przez zespół, metodologią badań, oczekiwanym układem raportu, wymaganiami dotyczącymi dowodów oraz przykładami udanych raportów.
Narzędzie informuje agenta o tym, co może uruchomić. Umiejętność podaje mu, w jaki sposób twoja organizacja oczekuje wykonania pracy. Taki podział jest przydatny: nie musisz włączać każdej procedury operacyjnej do jednego ogromnego promptu systemowego, ani ręcznie kopiować tej samej umiejętności do każdego klienta AI. Klient, który rozumie zasoby MCP, może odkryć i pobrać umiejętność za pomocą tego samego interfejsu protokołowego, podczas gdy klient ograniczony do narzędzi nadal może uzyskać dostęp do zasobów poprzez warstwę adaptacji, która otacza je wywołaniami narzędzi.
Server MCP może zapakować możliwości, kontekst oraz wiedzę operacyjną jako jeden wielokrotnie używalny produkt.
7. Elicitation: umożliwienie możliwości zadania pytania użytkownikowi
Najprostsza interakcja z narzędziem jest jednokierunkowa: model wywołuje narzędzie, a narzędzie zwraca wynik. Rzeczywiste procesy pracy są bardziej skomplikowane. Załóżmy, że użytkownik prosi o stworzenie nowego środowiska chmurowego dla projektu analitycznego, a narzędzie znajduje trzy dostępne regiony oraz dwa profile implementacji. Albo okazuje się, że żądane środowisko będzie kosztować około 420 dolarów miesięcznie. Albo pojawiają się dwa konta Salesforce o niemal identycznych nazwach. Prawidłowym dalszym krokiem nie zawsze jest zgadywanie – czasami narzędzie powinno zadać pytanie.
Taka jest idea wykorzystywana w technice MCP elicitation. FastMCP oferuje wygodną API do żądania ustrukturyzowanych danych od użytkownika, ale ten model należy do standardu MCP, a nie do konkretnego frameworka w Pythonie.
Specyfikacja MCP z datą 2026-07-28 przeprojektowała ten mechanizm wymiany na podstawie wielokrotnych żądań typu Round-Trip (MRTR), aby pasował do nowego modelu protokołu bezstanowego, zamiast polegać na sesji pozostającej otwartej w obu kierunkach. Zmienił się mechanizm transmisji danych. Sama możliwość pozostała bez zmian: operacja serwera nadal może zostać wstrzymana w oczekiwaniu na dane od użytkownika w trakcie realizacji procesu. Typowymi zastosowaniami są rozwiązywanie problemów z niejednoznacznymi elementami, uzupełnianie brakujących parametrów, potwierdzanie kosztownych operacji, sprawdzanie wygenerowanego treści przed jej publikacją, wybór środowiska docelowego oraz stopniowe zbieranie strukturyzowanych informacji.
W tym przypadku obowiązuje ważna uwaga dotycząca bezpieczeństwa: pytanie użytkownika nie stanowi upoważnienia. Gdy usunięcie wymaga zatwierdzenia, sam backend musi przechowywać i egzekwować ten stan zatwierdzenia. Przyjazne pytanie „Jesteś pewien?” w naturalnym języku nie rozwiązuje problemu. W przypadku operacji wrażliwych obecność człowieka w procesie musi faktycznie prowadzić do zmiany stanu.
8. Logowanie: przydatne dla klienta, ale pełna obserwowalność w produkcji wymaga czegoś więcej
Logowanie dzieli się na dwie odrębne koncepcje. Jedna to informacje dla klienta na temat wykonywanych działań: „Szukanie w Salesforce… Znaleziono 18 pasujących możliwości… Tworzenie raportu… Raport utworzony”. Druga to pełna obserwowalność w produkcji: identyfikatory śledzenia, żądania, użytkownika i najemcy, a także nazwa narzędzia, dostawca, opóźnienie, próby ponowne, werdykt polityki, identyfikator zadania oraz kod błędu. Traktuj je jako odrębne zadania.
FastMCP nadal opisuje logowanie klienta, w którym serwer wysyła komunikaty debug, info, warning lub error z powrotem do klienta MCP, który je obsługuje. Pomaga to podczas rozwoju i daje klientowi pewien wgląd w to, co robi dana funkcja. Istnieje jednak ważna zmiana w protokole z 2026 roku: własna funkcja Logging protokołu została uznana za przestarzałą dla nowych implementacji w MCP 2026-07-28. Dlatego nowy system obserwowalności w produkcji nie powinien polegać na komunikatach logowania MCP. Należy używać standardowej obserwowalności aplikacji: ustrukturyzowanych logów, śladów OpenTelemetry, metryk, narzędzi takich jak Datadog, Grafana i Tempo, CloudWatch, ELK lub czegokolwiek innego, co jest już używane w organizacji.
Jednym ze sposobów na to jest to, że komunikaty stanu umożliwiają użytkownikowi lub hostowi śledzenie tego, co się dzieje, natomiast telemetria po stronie serwera pomaga działom inżynieryjnym, bezpieczeństwa i operacyjnym zrozumieć system. W środowiskach korporacyjnych drugi rodzaj jest niezbędny. Jeden żądanie użytkownika może przemieścić się od hosta AI przez bramkę MCP, na serwer proxy, do API SaaS i dalej do zadania w tle, a pojedynczy ślad powinien wyjaśnić całą tę trasę. Im łatwiej jest proxyować i komponować MCP, tym ważniejszy staje się ten rozproszony widok.
9. Zadania w tle: funkcjonalność może mieć cykl życia wykonania
Klasyczna sekwencja operacji polega na wysłaniu żądania, jego wykonaniu i otrzymaniu wyniku, przy czym zakłada się, że praca mieści się w ramach jednego żądania. Wiele cennych funkcji korporacyjnych nie pasuje do tego modelu: raport klienta składający się z 60 stron, indeksowanie 20 000 dokumentów, analiza dużych zbiórów danych, pełny eksport możliwości z Salesforce, tworzenie prezentacji wraz z dodatkowymi materiałami, skanowanie zgodności z regulacjami czy obsługa dużych grup rekordów. Takie zadania mogą trwać kilka minut, wymagać ponownych prób, funkcjonować nawet po rozłączeniu się klienta, informować o postępach lub być wykonywane przez innego procesora niż punkt końcowy MCP.
Rozszerzenie MCP Tasks zapewnia długotrwałym zadaniom proces życiowy zgodny z protokołem. FastMCP pokazuje to wyraźnie: komponent jest oznaczony jako zdolny do wykonywania zadań, klient otrzymuje identyfikator zadania, a jego wykonanie przechodzi do procesora w tle obsługiwanego przez system zadań, zamiast utrzymywać otwarte oryginalne żądanie.
To różni się od zapisu asyncio.create_task(...). Konkurencja w Pythonie utrzymuje prace wewnątrz procesu, natomiast zadanie na poziomie protokołu tworzy umowę pomiędzy serwerem a klientem dotyczącą długotrwałych zadań, dzięki czemu takie rozwiązanie ma cykl życia zrozumiały dla klienta. Kolejnym wskaźnikiem na to, że serwer MCP staje się pełną aplikacją, a nie tylko narzędziem typu RPC, jest fakt, że jego zadaniem nie jest jedynie wywołanie funkcji i zwrócenie JSON – może on również rozpoczynać prace, przechowywać stan, informować o postępach, obsługiwać anulowania, odbudowywać się po awariach i zwracać wynik później.
10. Wersjonowanie: gdy agenci polegają na twoich narzędziach, schemat jest API
Każda udana wewnętrzna platforma dochodzi do momentu, w którym ktoś zmienia schemat i psuje funkcjonowanie użytkownika, o którego istnieniu nikt nie wiedział. MCP nie jest w żaden sposób odporny na to.
Załóżmy, że wersja 1 danej funkcjonalności to calculate_risk(project_id), a wersja 2 przyjmuje postać calculate_risk(project_id, methodology="v2", include_history=True). Jeśli wprowadzisz nową wersję kontraktu jednocześnie dla wszystkich agentów i klientów, spowodujesz zmianę API, która może zakłócić jego poprzednią funkcjonalność.
System wersjonowania komponentów FastMCP umożliwia istnienie kilku implementacji jednego narzędzia, zasobu lub instrukcji pod jednym logicznym identyfikatorem. Domyślnie serwowana jest najnowsza wersja, a filtry wersji pozwalają dostosować interfejs do konkretnych klientów lub okresów migracji.
Bardziej istotna jest ogólna architektura niż konkretna API. Gdy MCP staje się wspólną infrastrukturą, rozwój jego możliwości wymaga takiego samego podejścia jak w przypadku jakiegokolwiek kontraktu na usługę publiczną. Które zmiany powodują problemy? Które klienty nadal korzystają z wersji v1? Czy wersje v1 i v2 mogą działać obok siebie i jak długo powinien trwać okres migracji? Która wersja ma zatwierdzenie do użycia w produkcji, kto ma do niej dostęp i w którym momencie stara wersja zostanie wycofana? Przydatny rejestr przedsiębiorstwa mógłby w końcu rejestrować nazwę narzędzia, dostawcę, wersję, odcisk schematu, właściciela, klasę ryzyka, datę zatwierdzenia oraz osobę, która je zatwierdziła, a także datę wycofania.
Dla serwera z pięcioma narzędziami może to brzmieć przesadnie. Dla platformy obsługującej 20 zespołów tak nie jest.
Gdy tylko inny system będzie polegał na twoim schemacie MCP, staje się to API, niezależnie od tego, czy ma nazwę, czy nie.
11. Testowanie: sprawdzaj całą strukturę MCP, a nie tylko funkcję w Pythonie
Testowanie jest tutaj najmniej efektownym elementem, a jednocześnie najprawdopodobniej najważniejszym. Wyobraź sobie, że ta funkcja działa bez zarzutu:
async def find_customer(company_name: str):
...
Mimo to serwer MCP może być uszkodzony, a usterka może znajdować się w dowolnym miejscu związanych z tą funkcją elementów: błędnie utworzony schemat, mylący opis, transformacja ukrywająca niewłaściwy argument, przestrzeń nazw cicho zmieniająca nazwę narzędzia, widoczność ujawniająca uprawnienia administratora, filtrowanie autoryzacji dla niewłaściwego użytkownika, proxy nieprzekazujący danych uwierzytelniających, warstwa wyszukiwania niezdolna do znalezienia narzędzia, filtr wersji dostarczający wersję v1 zamiast zamierzonej v2, wynik niezgodny ze swoją strukturą lub zadanie w tle, które nigdy nie osiąga stanu końcowego.
Dlatego lepszym nawykiem jest testowanie rzeczywistej interfejsu MCP. Wskazówki dotyczące testowania w FastMCP polegają na uruchamianiu rzeczywistego klienta wewnątrz procesu serwera, dzięki czemu zachowanie protokołu można testować bez konieczności wdrażania oddzielnego usługi. Zamiast testować tylko implementację:
result = await find_customer("Acme")
assert result
Sprawdź również, co faktycznie widzi konsument MCP:
async with Client(mcp) as client:
tools = await client.list_tools()
assert "salesforce_find_customer" in {
tool.name for tool in tools
}
result = await client.call_tool(
"salesforce_find_customer",
{"company_name": "Acme"},
)
Dla platformy umożliwiającej realizację zadań produkcyjnych co najmniej cztery warstwy wymagają testowania.
Testy kontraktowe sprawdzają nazwę narzędzia, opis, schematy danych wejściowych i wyjściowych, adnotacje oraz wersję w porównaniu z oczekiwaniami.
Testy odkrywania sprawdzają, jakie narzędzia może zobaczyć dany użytkownik i proces pracy, a które pozostają ukryte, czy wyszukiwanie znajduje odpowiednią funkcjonalność oraz czy może przypadkowo ujawnić te zabronione.
Testy wykonywania sprawdzają, czy wywołanie się udaje, czy błędy są prawidłowo strukturyzowane, czy ponawiania są bezpieczne, czy proxy przekazują odpowiednią tożsamość oraz czy autoryzacja jest ponownie sprawdzana w momencie wykonywania.
Testy cyklu życia sprawdzają, czy zadania w tle kończą się pomyślnie lub nieudanie, czy można je anulować, czy migracja wersji zapewnia dalszą pracę starych klientów oraz co się dzieje, gdy serwer MCP jest niedostępny.
Żadne z tych rozwiązań nie testuje frameworku – testuje one umowę produktową. Gdy MCP stanie się warstwą funkcjonalną dla kilku klientów i agentów, ta umowa zasługuje na taką samą dyscyplinę, jaką stosuje się w przypadku interfejsów REST, gRPC czy opartych na zdarzeniach.
Połącz wszystkie elementy, a serwer wygląda zupełnie inaczej
Gdy połączymy wszystkie te koncepcje, powstanie system, który zajmuje się odkrywaniem zasobów, routowaniem, adaptacją interfejsów, kontrolą kontekstu, politykami, interaktywnymi procesami pracy, wykonywaniem zadań asynchronicznie, wykorzystywaniem wiedzy operacyjnej wielokrotnie, zapewnianiem kompatybilności oraz zarządzaniem cyklem życia produktu. To już dawno przestało być zwykłym serwerem z kilkoma narzędziami – to powierzchnia produktu. Co więcej, nic z tego nie wymaga od dostawcy modelu posiadania logiki biznesowej, ponieważ ta sama platforma może działać za dowolnym hostem kompatybilnym z MCP, który wybierze organizacja. To właśnie jest element o strategicznym znaczeniu.
Część najlepszych działań optymalizacyjnych odbywa się zanim model cokolwiek zobaczy
Wiele dyskusji na temat wydajności sztucznej inteligencji koncentruje się na samym modelu: który model, ile ma parametrów, jak duże jest okno kontekstowe, jak dobra jest jego zdolność rozumowania. To wszystko ma znaczenie, ale w warunkach produkcyjnych architektura otaczająca model może usunąć ogromną ilość niepotrzebnych operacji.
Załóżmy, że platforma posiada 300 narzędzi. Proste podejście polega na umieszczeniu wszystkich 300 schematów w kontekście LLM i liczeniu na to, że model dokona dobrego wyboru. Bardziej przemyślane podejście polega na stopniowym zawężaniu wyboru. Polityka ogranicza liczbę narzędzi z 300 do 85 dozwolonych. Widoczność procesów pracy redukuje je do 24 najbardziej istotnych. Wyszukiwarka pozostawia 4 kandydatów, a tylko te 4 schematy są ładowane w celu ostatecznego wyboru modelu.
Model nie stał się mądrzejszy. System tak. To jest główny powód, dla którego te wzorce są ważne w środowisku produkcyjnym. Kontekst się zmniejsza, dokładność selekcji rośnie, nieistotne działania znikają, uprawnienia stają się jaśniejsze, kontrakty backendu nie wpływają na model, a zespoły mogą współpracować bez łączenia kodu, wszystko to zanim od LLM zostanie zażądane rozważenie jego następnego działania.
Dobra architektura agenta nie ogranicza się tylko do poprawy rozumowania modelu. Kształtuje również materiał, nad którym model musi rozważać.
Od jednego serwera MCP do sieci takich serwerów
Dla systemów korporacyjnych tutaj ewolucja staje się naprawdę interesująca. Początkowa jednostka wyglądała tak:
AI client
↓
MCP server
↓
API
Następna jednostka przypomina bardziej bramę pośrodku, z serwerami domenowymi i pracownikami za nią. Każdy serwer MCP skupia się na swojej roli, każdy zespół zarządza swoją domeną, a każda usługa jest wdrażana według własnego harmonogramu. Brama tworzy odpowiedni interfejs dla każdego użytkownika, model odkrywa tylko to, czego potrzebuje, długi proces przenosi się do zadań, a umiejętności uczą agenta, w jaki sposób firma oczekuje, że proces będzie przebiegał, przy czym wszystko pozostaje dostępne poprzez granice MCP.
To wygląda znacznie bardziej jak platforma aplikacji rozproszonych niż jak zbiór obudów funkcji, dlatego określanie serwerów MCP jako „tylko narzędzi dla LLM” coraz częściej nie oddaje ich rzeczywistej roli.
Nie buduj platformy, dopóki nie pojawi się problem związany z platformą
Zagrożenie jest oczywiste. Po przeczytaniu tego wszystkiego można by dojść do wniosku, że wewnętrzny serwer wyposażony w pięć narzędzi wymaga trzech bramek, rejestru możliwości, funkcji wyszukiwania w schematach narzędzi, kilku przestrzeni nazw, negocjacji wersji w czasie wykonywania, rozproszonej kolejki do zadań, rynku umiejętności oraz tuzina warstw transformacji.
Proszę, nie rób tego.
Server z sześcioma stabilnymi narzędziami, które powinien zobaczyć każdy użytkownik? Po prostu wyślij te sześć. Jeśli schemat backendu jest już czysty, nie dodawaj transformacji tylko dlatego, że jakaś framework ją obsługuje. Przy jednym serwerze nie ma potrzeby topologii proxy. Jeśli operacja kończy się w dwie sekundy, prawdopodobnie nie potrzebuje zadania. Jeśli nikt już nie korzysta z wersji v1, nie ma powodu, by utrzymywać obie wersje wiecznie.
Architektura powinna powstawać w odpowiedzi na problem, a nie odwrotnie. Celem nie jest maksymalizacja liczby funkcji frameworka w twoim repozytorium. Chodzi o to, aby gdy problem się pojawi, MCP nie zmuszał cię do budowy całkowicie spersonalizowanej platformy AI wokół niego. Ekosystem dostarcza teraz ponownie wykorzystywalne elementy budulcowe do rozwiązywania tych samych problemów, z którymi boryka się każda dojrzała platforma aplikacyjna, i to jest postęp.
Framework można zamienić; liczy się architektura
FastMCP zasługuje na uznanie za to, że umożliwia widzenie wielu z tych koncepcji w jednym miejscu. Jego dokumentacja omawia dostawców, transformacje, wyszukiwanie, zarządzanie nazwami, widoczność, proxyowanie, umiejętności, procesy wydobycia informacji, zadania, wersje oraz testy, co ułatwia zrozumienie, w jaki sposób poszczególne elementy serwera MCP są ze sobą powiązane. Kilka z tych wzorców jest używanych w praktyce, ponieważ rozwiązują rzeczywiste problemy: zmniejszanie zakresu kontekstu narzędzia, oddzielanie umów skierowanych do modeli od tych związanych z backendem, ograniczanie dostępnych funkcji, łączenie integracji oraz ułatwianie obsługi otrzymanego rozwiązania.
Mimo to zespoły powinny skopiować tę ideę, a nie API biblioteki. Zadaj sobie pytanie: czy potrzebujemy funkcji odkrywania narzędzi na żądanie? Warstwy transformacji przeznaczonej do pracy z modelem? Bramy dostępu do funkcji? Widoczności specyficznej dla procesów pracy? Umiejętności rozproszonych za pomocą zasobów MCP? Trwałego cyklu życia dla długotrwałych operacji? Umów o funkcjach w wersjach? Czy testujemy to, co faktycznie widzi klient? Następnie stwórz rozwiązania przy użyciu takiego zestawu narzędzi, który pasuje do twojej organizacji.
Protokół zapewnia interoperacyjność. Framework zapewnia wygodę. Architektura pozostaje twoja.
Co się zmieniło
Najważniejszą zmianą w MCP nie jest dłuższy wykaz funkcji. Chodzi o rosnący zakres tego, co od serwera MCP oczekuje się, że będzie posiadał. Na początku sytuacja była prosta: publikuje się narzędzie, model je wywołuje i otrzymuje się wynik. Model, który obecnie nabiera kształtu, polega na pozyskiwaniu możliwości z kilku systemów, normalizowaniu ich umów, zarządzaniu identyfikatorami, filtrowaniu według istotności, autoryzowaniu tego, co jest dozwolone, wyszukiwaniu informacji w dużych katalogach na żądanie, udostępnianiu wielokrotnie używalnych umiejętności i kontekstu, zadawaniu użytkownikowi pytań, gdy potrzebna jest decyzja, przenoszeniu powolnych operacji na trwałe wykonanie, obserwowaniu całej ścieżki, wersjonowaniu umów oraz testowaniu produktu jako takiego.
To zupełnie inna praca. MCP celowo pozostaje protokołem, a nie frameworkiem aplikacyjnym, ale ekosystem wokół niego sprawia, że serwery MCP stanowią poważną granicę aplikacji, w której warstwy routingu, zarządzania, cyklu życia, kompatybilności i kompozycji mogą być budowane tak jak w dojrzałych backendach.
Dobrze zaprojektowany serwer MCP to już nie tylko sposób na dodanie kolejnej funkcji do LLM. Może to być produkt o możliwościach wielokrotnego użycia, który służy zarówno agentom, modelom, zespołom, jak i aplikacjom klienta. Pojedynczy serwer może pozostać mały, a sieć takich serwerów może rozwinąć się w platformę korporacyjną. Model pozostaje elastyczny, warstwa funkcji jest pod kontrolą, a klient na górze można wymienić bez konieczności przepisywania podstawowej funkcji biznesowej poniżej niego.
Literatura pokrewna
- MCP 2026-07-28: Jak bezstanowa specyfikacja zmienia projekt serwerów zdalnych — Jak rewizja MCP z dnia 2026-07-28, oparta na zasadzie bezstanowości, eliminuje sesje i procedurę handshake, dodaje MRTR, zadania oraz wskazówki dotyczące pamięci cache, oraz co to oznacza dla procesu migracji.
- Chmurna przeglądarka: Bezpieczna platforma przeglądarki zdalnej dla każdego agenta AI — Projekt referencyjny dla usługi przeglądarki zdalnej niezależnej od modeli: brama wejściowa, procesory robocze, funkcja oglądania na żywo przez WebRTC, mechanizmy zatwierdzania, zabezpieczenia przed SSRF, możliwość odtwarzania oraz wszystkie ustawienia konfiguracyjne.