To, co Blender MCP ujawnia na temat budowy przydatnych serwerów MCP

Bardzo wiele zadań inżynieryjnych zaczyna się od znajomego scenariusza: ktoś otwiera aplikację, którą stworzyłeś.

Projektujesz panel sterowania, decydujesz, gdzie znajdą się przyciski, i starasz się jasno pokazać najważniejsze działania. Użytkownik korzysta z części twojej interfejsu i wykonuje swoje zadanie.

Częściej pojawia się ciekawe pytanie: co się dzieje, gdy ta sama osoba ma już otwartego asystenta AI i prosi go po prostu o bezpośrednie wykonanie zadania?

Czy użytkownik naprawdę musi otwierać twój panel sterowania?

Czasami odpowiedź wciąż brzmi „tak”. Zastąpienie działającego przycisku trzema akapitami rozmowy to nie ulepszenie. Jednak w wielu procesach pracy zmuszanie kogoś do korzystania z nawigacji w twojej aplikacji to jedynie dodatkowe utrudnienia, które nie przynoszą żadnej wartości.

To jest główny powód, dla którego serwery MCP prawdopodobnie staną się ważniejsze. Blender MCP jest dobrym przykładem tego, jak to może wyglądać w praktyce, a jednocześnie ujawnia niektóre mniej oczywiste pytania dotyczące sposobu budowania, utrzymywania i oceny tych integracji z biegiem czasu.

To właśnie te mniej oczywiste pytania były motywacją do pracy nad Pulse.

Czym jest MCP i jak działają serwery MCP?

MCP to skrót od Model Context Protocol, otwartego standardu służącego do łączenia aplikacji AI z zewnętrznymi narzędziami i źródłami danych. Serwer zbudowany według tego standardu może udostępniać narzędzia, które podejmują działania, zasoby dostarczające kontekstu oraz prompty, które można ponownie wykorzystać. Ten tekst koncentruje się specjalnie na narzędziach.

Architektura oddziela aplikację AI, określaną jako host, od klientów i serwerów MCP z którymi komunikuje się. Host jest odpowiedzialny za koordynację interakcji. Klient dowiaduje się, jakie narzędzia są dostępne, wywołując metodę tools/list, a następnie uruchamia wybrane narzędzie za pomocą tools/call. Serwer wykonuje właściwą logikę i wysyła wynik. Same serwery mogą być hostowane lokalnie lub dostępne zdalnie.

W przypadku prostego integracji produktu sekwencja może wyglądać mniej więcej w ten sposób:

User asks for something
 → AI application selects an available tool
 → MCP client sends the call
 → Your MCP server checks access and runs the operation
 → Result returns to the AI application

Sam MCP nie ma wpływu na to, czy model powinien skorzystać z danego narzędzia, czy prośba użytkownika ma jakikolwiek sens, ani na to, czy ostateczna odpowiedź jest przydatna. Protokół łączy te komponenty ze sobą, ale aplikacja nadrzędna nadal musi zarządzać ich wspólną pracą.

Dostawa serwera również nie gwarantuje, że każdy asystent AI automatycznie go przyjmie. VS Code wymaga na przykład wyraźnych kroków do zainstalowania, skonfigurowania i nadeślenia zaufania serwerowi MCP. Nadal istnieje wyraźna granica pomiędzy integracją a uprawnieniami, którą trzeba przekroczyć.

Czym właściwie jest Blender MCP

Projekt stworzony przez społeczność ahujasid/blender-mcp łączy klienty AI z Blenderem za pomocą serwera MCP opartego na Pythonie w połączeniu z dodatkiem do Blendera. Może on badać sceny, modyfikować obiekty i materiały oraz wykonywać kod Pythona bezpośrednio w Blenderze. Warto zaznaczyć, że jest to integracja stworzona przez stronę trzecią, a nie coś oficjalnie dostarczanego przez Blendera.

Jego architektura wygląda mniej więcej tak:

AI application / MCP client
  ↕ MCP
Python MCP server
  ↕ Project-specific socket connection
Blender add-on
  ↕
Blender scene and operations

To rozdzielenie jest ważne. MCP reguluje interfejs pomiędzy klientem a serwerem. To, co dzieje się między serwerem a Blenderem, zależy wyłącznie od implementacji. Każdy serwer MCP nadal potrzebuje własnego mechanizmu do sterowania oprogramowaniem podstawowym.

Wyobraźmy sobie, że prosimy asystenta o przejrzenie sceny, przestawienie kilku obiektów i dostosowanie ich materiałów. Dzięki takiemu połączeniu asystent może bezpośrednio wykonywać operacje na scenie, zamiast jedynie opisywać, które menu należy kliknąć. To, czy rezultat będzie dobry, to zupełnie inna kwestia.

Najważniejsze jest to, że cała rzeczywista praca nadal odbywa się wewnątrz Blendera. Aplikacja, jej istniejący zestaw funkcji oraz możliwość sprawdzenia, co się zmieniło, pozostają kluczowe.

Wydaje się, że ten wzorzec może pojawić się również w innych rodzajach oprogramowania: ktoś prosi o konkretną zmianę, sprawdza wynik w znajomym interfejsie i wraca do pracy ręcznej, gdy jest to szybsze.

To wydaje się o wiele bardziej realistyczne niż oczekiwanie, że ludzie porzucą swoje obecne narzędzia i będą robić wszystko przez okno czatu.

MCP kontra API: co tak naprawdę się zmienia?

Serwer MCP może być zainstalowany na wierzchu istniejącego API. Może on równie dobrze otaczać bazę danych, lokalną bibliotekę lub specjalnie stworzony most komunikacyjny, jak ten używany w Blender MCP. Wdrożenie MCP nie zmusza cię do przebudowy backendu tylko dlatego, że teraz aplikacja AI go wywołuje.

To, co naprawdę się zmienia, to fakt, że istnieje teraz wspólna interfejs do udostępniania funkcjonalności dowolnemu kompatybilnemu klientowi. Narzędzia są opisywane za pomocą definicji, które wymieniają dostępne działania oraz ich dane wejściowe, dzięki czemu poszczególne integracje z klientami nie muszą już samodzielnie tworzyć własnych procedur wykrywania i wywoływania funkcji.

Pomaga traktować to jako trzeci punkt dostępu do produktu, umieszczony obok istniejącego interfejsu użytkownika oraz istniejącej API.

Weźmy za przykład system inwentaryzacji. Logika biznesowa już wie, jak wyszukać produkt, sprawdzić, czy jest on w magazynie, oraz zarezerwować jego jednostki. Ponowne wykorzystanie tej logiki ma o wiele większy sens niż pisanie równoległej implementacji wyłącznie w celu obsługi asystenta AI.

Mimo to argumenty na rzecz MCP nie są bezwarunkowe. Jeśli masz do czynienia z pojedynczym wewnętrznym skryptem komunikującym się z jedną znana API, bezpośrednie wywołanie go jest prawdopodobnie nadal najprostszym rozwiązaniem. MCP okazuje się przydatny, gdy faktycznie potrzebujesz kompatybilności między kilkoma klientami AI lub gdy interfejs narzędzia wielokrotnego użytku rozwiązuje rzeczywisty problem, z którym się borykasz. Dodawanie kolejnego protokołu tylko dlatego, że jest obecnie popularny, oznacza jedynie kolejny protokół, który trzeba teraz utrzymywać.

Budowanie narzędzi MCP to również projektowanie interfejsu

To krok, przy którym warto zwolnić.

Agent musi ustalić, które narzędzie pasuje do danej zadania i jak je poprawnie wywołać. Wewnętrzne wytyczne inżynieryjne Anthropic zalecają projektowanie narzędzi wokół sensownych jednostek pracy, nadanie im jasnych granic oraz ocenę ich wydajności w praktyce, zamiast wystawiania wszystkich istniejących punktów końcowych w takim stanie, w jakim się znajdują.

Dla hipotetycznego aplikacji katalogowej rozsądna definicja początkowa mogłaby wyglądać w ten sposób:

{
  "name": "search_catalog",
  "description": "Find products in the authorized catalog by name or SKU. Returns product IDs, names, and availability. Read-only; does not reserve stock.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string", "minLength": 1 },
      "limit": { "type": "integer", "minimum": 1, "maximum": 20 }
    },
    "required": ["query", "limit"],
    "additionalProperties": false
  }
}

Jest to ilustracja definicji narzędzia, a nie pełna implementacja na serwerze ani rzeczywiste narzędzie MCP w Blenderze. Nazwa, opis oraz kontrakt wejściowy JSON Schema pokazane tutaj są zgodne z formatem określonym przez MCP.

Opis szczegółowo opisuje, co narzędzie może wyszukiwać, co zwraca oraz czego celowo nie robi. Jego dane wejściowe mają wąski zakres. Rezerwowanie zapasów jest celowo traktowane jako odrębna akcja, ponieważ ma inne konsekwencje niż proste wyszukiwanie.

Mimo to oznaczenie czegoś jako „upoważnionego” w opisie nie czyni tego faktem. Rzeczywiste egzekwowanie kontroli dostępu i walidacji danych musi odbywać się w implementacji. Każda akcja z rzeczywistymi konsekwencjami wymaga również odpowiedniego kroku potwierdzenia. Wytyczne bezpieczeństwa MCP dla narzędzi bezpośrednio odnoszą się do tych obowiązków.

Blender MCP jasno ilustruje ten kompromis: jego narzędzie do wykonywania kodu w Pythonie jest naprawdę potężne, a sam projekt wyraźnie ostrzega przed zagrożeniami związanymi z pozwalaniem asystentowi na uruchamianie dowolnego kodu.

Dla własnych narzędzi produkcyjnych warto zacząć od najmniejszego zestawu uprawnień, który jest rzeczywiście przydatny, i rozszerzać go tylko wtedy, gdy istnieje konkretny powód. Warto również testować narzędzia pod kątem rzeczywistych żądań. Opis, który jest dla ciebie jasny, nie jest dowodem na to, że agent będzie go prawidłowo interpretował i wykorzystywał.

Skąd wiesz, że serwer MCP jest przydatny?

Działająca demonstracja odpowiada tylko na jedno wąskie pytanie: czy ten proces pracy w ogóle funkcjonuje?

Nie mówi ci nic o tym, czy ludzie nadal używają tego narzędzia, na jakie konkretne funkcje polegają, ani o tym, co się psuje, gdy rzeczywiste żądania wykraczają poza scenariusz, który zaprogramowałeś.

Weźmy jako przykład serwer katalogowy. Chciałbyś wiedzieć, czy funkcja search_catalog rzeczywiście jest wywoływana, czy wysyłanie nowej wersji spowalnia jej obsługę, oraz czy błędy występują głównie przy jednej konkretnej operacji, a nie są rozproszone równomiernie.

Tutaj również interpretacja wymaga ostrożności. Wzrost liczby wywołań narzędzi może odzwierciedlać rzeczywiście przydatną pracę. Może to też oznaczać, że agent próbuje ponownie zrobić coś, co powinno udać się przy pierwszej próbie. Same surowe liczby wywołań nie pozwalają odróżnić tych dwóch zupełnie różnych sytuacji.

Jeśli chodzi o monitorowanie, są to oddzielne kwestie, które należy śledzić osobno. Metryki operacyjne obejmują takie aspekty jak opóźnienia i wskaźniki błędów. Analiza produktu ujawnia wzorce użytkowania oraz, w przypadku dostępu do odpowiedniego kontekstu tożsamościowego, powtarzające się interakcje. Ocena na poziomie zadań pokazuje, czy cały proces faktycznie zapewnił to, czego potrzebował użytkownik.

To rozróżnienie jest ważne, ponieważ pomyślne zakończenie obsługi nie jest równoznaczne z ukończeniem zadania użytkownika. Wywołanie obsługi może technicznie się udać, a mimo to nastąpić błąd podczas walidacji wyników lub w warstwie transportu. Nawet technicznie poprawny wynik może okazać się bezużyteczny dla osoby, która go zażądała.

Nic z tego nie powinno być łączone w jeden zielony wskaźnik stanu, który ukrywa tę różnicę.

Dlaczego tworzę Pulse do analiz MCP

To właśnie te pytania skłoniły mnie do stworzenia Pulse – otwartego SDK w połączeniu z opcjonalną, oddzielnie hostowaną usługą chmurową.

Publiczny repozytorium projektu znajduje się pod adresem github.com/selimeneserd/pulse-sdk, a oznaczenie go jako ulubione pomoże innym go znaleźć.

Jest udostępniony na licencji MIT. Biblioteka monitoruje ukończenie obsługi narzędzi MCP i może wysyłać te metadane do lokalnego celu, do kolektora, którym się kierujesz, lub za pośrednictwem opcjonalnego eksportera OpenTelemetry. Do jego użycia nie jest konieczne rejestrowanie się w Pulse Cloud, a w integracji nie ma ukrytego domyślnego punktu końcowego chmurowego.

Minimalna lokalna konfiguracja wygląda mniej więcej tak:

import { McpServer } from '@modelcontextprotocol/server';
import { createPulse } from '@reviseflow/pulse';
import { createJsonlExporter } from '@reviseflow/pulse-core/jsonl';

const analytics = createPulse({
  environment: 'development',
  exporter: createJsonlExporter({
    path: './catalog-events.jsonl',
  }),
});

const server = analytics.wrapServer(
  new McpServer({ name: 'catalog-server', version: '1.0.0' }),
);

// Register tools on `server`, then connect your existing MCP transport.

Ten fragment ma na celu ilustrowanie mechanizmów instrumentacji, a nie stanowi pełnej implementacji serwera. Został napisany z uwzględnieniem wersji Pulse 0.2.1 oraz wersji 2.0.0 biblioteki @modelcontextprotocol/server, przy czym jednym z obsługiwanych środowisk jest Node.js 24.20.0. Samo zarejestrowanie narzędzia nie generuje żadnych wydarzeń analitycznych; jedynie faktyczne wywołania obsługiwaczy to powodują. Aby zamknąć serwer w sposób uporządkowany, po zakończeniu pracy obsługiwaczy w trakcie wykonywania zadań, należy wywołać await analytics.shutdown({ timeoutMs: 2_000 }).

To konkretne przykład dotyczy serwera MCP opartego na TypeScript. W chwili obecnej w SDK nie ma adaptera dla Pythona, który mógłby obsłużyć coś takiego jak Blender MCP.

Pulse Cloud dostarcza warstwę zarządzanego przechowywania oraz panel sterowania oparty na tych metadanych: wzorcach używania narzędzi, czasie trwania obsługi, stanie wyniku oraz możliwości filtrowania według środowiska lub wersji. Działa na własnym strumieniu telemetrii, więc rzeczywisty ruch danych w narzędziu nigdy nie przechodzi przez niego.

Wysyłanie danych do Cloud jest dobrowolne i wymaga wyraźnej zgody, odbywa się za pośrednictwem eksportera HTTP przy użyciu adresu URL kolektora wraz z kluczem do zapisu po stronie serwera. Sam produkt Cloud ma zamknięty kod źródłowy, natomiast leżąca u jego podstaw warstwa instrumentacji pozostaje w pełni otwarta i może być używana samodzielnie.

Ważne jest, aby ta granica była wyraźna. Programista, który woli zapisywać dane do lokalnych plików JSONL lub już posiada stack do monitorowania, ma wszelkie powody, by przyjąć warstwę o otwartym kodzie źródłowym, bez konieczności najpierw zostania klientem Cloud.

Audytowna analiza wymaga wyraźnych granic

Telemetria Pulse celowo pomija surowe polecenia, argumenty narzędzi, wyniki ich działania, teksty błędów, ślady wywołań oraz nagłówki żądań. Nawet coś tak prostego jak nazwa narzędzia lub etykieta techniczna wymaga dokładnej analizy, ponieważ same metadane mogą ujawnić poufne informacje. Wszystkie opcjonalne identyfikatory kont są z założenia pseudonimowe i nie stanowią gwarancji pełnej anonimowości.

To, gdzie kończy się pomiar, jest równie ważne jak to, co jest zbierane. Pulse może stwierdzić, że dany proces został uruchomiony i ile czasu to zajęło, ale nie ma możliwości sprawdzenia, dlaczego model wybrał właśnie to narzędzie, co użytkownik faktycznie próbował osiągnąć, ani czy uzyskany rezultat biznesowy był pozytywny. Nie ma również sposobu na zapisanie rozmowy, która została zablokowana jeszcze przed dotarciem do procesu obsługi.

Dostawa danych telemetrycznych odbywa się w trybie „best-effort”: kolejki są ograniczone i dochodzi do prób ponownych wysyłek, ale nic nie gwarantuje dotarcia każdego zdarzenia. Zdarzenie telemetryczne, które nie dotrze, nigdy nie wpływa na rzeczywisty wynik narzędzia otrzymywany przez użytkownika, ale oznacza to, że dane mogą mieć luki. System ten jest przeznaczony do analizy, a nie jako niezawodny zapis audytowy odporny na modyfikacje.

Biorąc to pod uwagę, wydaje się uczciwsze bezpośrednio opisać te ograniczenia, zamiast nazwać tę funkcję „obserwowalnością” i pozostawiać ludziom domysły co do tego, co faktycznie jest monitorowane, a czego nie.

W perspektywie

Wydaje się prawdopodobne, że istnienie naprawdę przydatnej integracji MCP stanie się kolejnym kryterium, którego ludzie będą używać przy ocenie produktu obok standardowych kryteriów.

Czy asystent może rzeczywiście zapewnić funkcjonalność, której potrzebuje użytkownik? Czy działania, które podejmuje, są łatwe do zrozumienia i analizy? Czy ktoś może interweniować i sprawdzić wszystko istotne przed ich wykonaniem? I czy integracja nadal będzie działać, gdy początkowa nowość minie?

Blender MCP wyróżnia się tym, że stanowi konkretny przykład asystenta obsługującego rzeczywisty, istniejący już oprogramowanie, a nie tylko mówiącego o nim. Taki kierunek wydaje się bardziej obiecujący niż kolejny chatbot, którego głównym zadaniem jest opisywanie kroków, które użytkownik mógłby sam wykonać gdzie indziej.

To wcale nie oznacza, że każdy produkt musi mieć teraz serwer MCP ani że tradycyjne interfejsy graficzne stają się przestarzałe. Po prostu sugeruje to, że niektóre procesy mogą rozpoczynać się w asystencie, a następnie kontynuować w samym aplikacji, eliminując część ręcznych wymian informacji pomiędzy nimi.

Sam Pulse może być wczesną opcją inwestycyjną, a nie jest jasne, jak szybko ten model stanie się standardową praktyką. Mimo to problemy inżynieryjne leżące u jego podstaw wydają się warte rozwiązania już teraz: projektowanie narzędzi, które są rzeczywiście przydatne, ustalanie rozsądnych granic uprawnień, zapewnienie niezawodności działania oraz szczerość co do tego, w jaki sposób te narzędzia są używane w praktyce.

Samo dostarczenie serwera MCP nie będzie wystarczające. Warto budować takie serwery, do których ludzie będą wracać po tym, jak początkowa ciekawość minie.

Jeśli sam budujesz taki serwer, jak decydujesz, które narzędzia faktycznie warto zachować?

Literatura pokrewna

• MCP dla agentów AI: standaryzacja integracji narzędzi w LangGraph — Ten artykuł wyjaśnia, co dokładnie standaryzuje MCP w systemach AI opartych na agentach, porównując ad hoc integracje narzędzi z tymi opartymi na MCP w ramach orkiestratora LangGraph.
• Lekcje z wdrożenia Next.js SaaS i tworzenia CLI do budowy projektów — Opisuje kluczowe decyzje – wybór technologii, autoryzację, model wielu użytkowników, system fakturowania oraz zarządzanie stanem – a także tworzenie CLI ułatwiającego konfigurację projektów Next.js.