MCP często przedstawia się jako warstwę hydrauliczną, dzięki której model może wywoływać narzędzia. To opis technicznie prawdziwy i architektonicznie niepełny.
W chwili, gdy agent może przeglądać repozytorium, odpytywać usługę, modyfikować artefakt lub wykonywać workflow, integracja staje się granicą operacyjną. Problem projektowy zaczyna przypominać architekturę API i bezpieczeństwa bardziej niż prompt engineering.
Capability jest jednostką projektu
Nie zaczynaj od pytania „do czego agent może się podłączyć?”. Zacznij od „jakiej capability wymaga to zadanie?”.
Capability powinna być na tyle wąska, by dało się określić:
- co agent może czytać;
- co może zmieniać;
- jakie wejścia są akceptowane;
- jakie dowody wracają;
- co wymaga osobnego kroku zatwierdzenia.
Zmniejsza to niejednoznaczność dla modelu i ułatwia ludziom audyt systemu.
Ścieżki read i write powinny odczuwać się inaczej
Inspekcja jest tania. Mutacja jest droga.
Repo-aware agent może potrzebować szerokiego read access, aby zrozumieć architekturę, a jednocześnie mieć bardzo wąskie akcje write. Ta sama zasada dotyczy infrastruktury, baz danych i zewnętrznych API.
Gdy narzędzie łączy obserwację i mutację za jedną niejasną akcją, tracisz przydatną granicę bezpieczeństwa i utrudniasz debugging.
Wynik narzędzia jest dowodem
Output tool calla powinien być traktowany jako ustrukturyzowany dowód, który może zostać sprawdzony przez późniejszy etap workflow.
To oznacza, że odpowiedzi narzędzi powinny być wystarczająco przewidywalne, by można je było konsumować, logować i porównywać. Agent walidujący powinien móc sprawdzić, co się wydarzyło, bez polegania na opisowym podsumowaniu agenta implementacyjnego.
Zasada architektoniczna
Projektuj narzędzia MCP tak, jak projektowałbyś wewnętrzne API produkcyjne: mała powierzchnia, jawna semantyka, least privilege i obserwowalne rezultaty.
Model jest nowy. Dyscyplina interfejsu nie jest.