MAPI-local-medium: lokalny serwer MCP, który daje modelowi pamięć, narzędzia i granice

MAPI-local-medium to lokalny serwer MCP. Jego zadanie jest proste: pośredniczyć między modelem językowym a środowiskiem pracy użytkownika. Model sam z siebie nie dostaje dostępu do komputera, plików ani bazy danych. Dostaje listę narzędzi, które serwer wystawia przez MCP.

Każde użycie narzędzia przechodzi przez zdefiniowany interfejs. To ważna różnica. Nie mówimy: „AI ma dostęp do mojego komputera”. Mówimy: „AI może wykonać kilka jawnych operacji w ograniczonym zakresie”.

ChatGPT / klient MCP
        |
        | MCP / JSON-RPC
        v
MAPI-local-medium
        |
        +-- pamięć projektowa
        +-- wyszukiwanie wspomnień
        +-- zapis nowych wpisów
        +-- odczyt konkretnych wpisów
        +-- linki między wpisami
        +-- timeline projektu
        +-- kontrolowane operacje robocze

Zwykły chatbot żyje głównie w obrębie jednej rozmowy. Dopóki kontekst jest w oknie czatu, jakoś płyniemy. Gdy rozmowa się kończy, zostają ręczne notatki, przeklejanie ustaleń i klasyczne: „przecież ja to już gdzieś pisałem”.

Serwer MCP zmienia ten układ. Model może korzystać z zewnętrznego środowiska pracy. Może zapytać o wcześniejsze decyzje, odczytać stan projektu, zapisać wynik pracy i wrócić do niego w następnej sesji.

To nie robi z modelu samodzielnego programisty. Ale robi z niego coś znacznie użyteczniejszego niż samotny generator tekstu: asystenta pracującego na stanie projektu.

Najważniejszym elementem MAPI-local-medium jest pamięć projektowa. Nie chodzi o pamięć typu „użytkownik lubi kawę”. Chodzi o pamięć techniczną: decyzje, statusy, wyniki testów, ryzyka, kontekst implementacyjny i rzeczy wymagające ponownego sprawdzenia.

Dzięki temu model może pytać nie tylko „co pamiętasz?”, ale bardziej konkretnie: jaka była ostatnia decyzja, czy dana funkcja już istnieje, co było testowane, co jest sprzeczne i co wymaga rewalidacji.

MAPI-local-medium udostępnia modelowi zestaw prostych narzędzi do pracy z pamięcią. To z nich składa się praktyczny cykl agentowy: sprawdź kontekst, wykonaj zadanie, zapisz wynik.

find_memories       - wyszukuje wpisy w pamięci
get_memory          - pobiera konkretny wpis po ID
get_memory_links    - pokazuje powiązania danego wpisu
create_memory       - zapisuje nowy wpis
recall_memory       - przywołuje wpis jako istotny kontekst

To jest mały zestaw, ale wystarcza do zaskakująco dużej liczby zadań. Dobra infrastruktura agentowa nie musi wyglądać jak kokpit statku kosmicznego. Ma być przewidywalna, testowalna i użyteczna.

Model nie powinien zaczynać pracy od zgadywania. Dlatego ważnym elementem jest bootstrap sesji: pierwsze wywołanie, które zwraca podstawowy kontekst pracy, aktywny projekt, zasady działania, dostępne narzędzia i wskazówki, gdzie szukać dalszego kontekstu.

1. Przywróć kontekst sesji.
2. Sprawdź dostępne obszary narzędziowe.
3. Wyszukaj potrzebne wpisy w pamięci.
4. Dopiero potem wykonuj zadanie.

Sama baza pamięci nie wystarczy, jeśli model nie wie, że ma z niej korzystać. Bez bootstrapu pamięć jest biblioteką bez katalogu. Wiedza niby jest, ale zaczyna się archeologia z latarką na słabe baterie.

Jeden z częstych błędów przy budowaniu agentów to wystawienie modelowi zbyt wielu narzędzi naraz. Teoretycznie brzmi dobrze: dajmy mu wszystko. W praktyce robi się z tego smok narzędziowy.

Lepszy wzorzec to mała lista narzędzi głównych oraz logiczne obszary pracy. Model nie musi widzieć od razu całej tablicy rozdzielczej. Najpierw wybiera obszar, potem akcję.

restore / bootstrap kontekstu
find_memories
get_memory
get_memory_links
create_memory
recall_memory
open_workshop
run_workshop_action

Bardziej zaawansowane funkcje można ukryć za warsztatami: pamięć, timeline, konflikty, jakość pamięci, wyszukiwanie semantyczne, pliki lub administracja. To zmniejsza chaos i ułatwia kontrolę dostępu.

Poza zwykłymi wpisami pamięci przydaje się timeline projektu. To nie jest zwykły log techniczny. Log mówi: „wykonano operację”. Timeline mówi: „w projekcie wydarzyło się coś znaczącego”.

Linki między wpisami robią drugi kawałek roboty. Wpis może wspierać inny, być z nim sprzeczny, dokumentować implementację albo opisywać poprawkę. Dzięki temu pamięć nie jest płaską listą notatek. Zaczyna działać jak graf wiedzy projektu.

MAPI-local-medium może być rozszerzany o operacje na plikach lub środowisku roboczym, ale to powinno być robione ostrożnie. Dobra zasada brzmi: model może działać tylko w określonym katalogu i tylko przez opisane narzędzia.

Model może czytać i pisać tylko w określonym katalogu roboczym.
Nie powinien mieć dostępu do całego dysku.
Nie powinien widzieć sekretów.
Operacje ryzykowne są ukryte albo dostępne tylko w profilu admin.
Najpierw odczyt, potem zapis.

To jest różnica między „AI ma dostęp do mojego komputera” a „AI może używać kilku bezpiecznych narzędzi w konkretnym katalogu”. Pierwsze brzmi jak początek incydentu bezpieczeństwa. Drugie brzmi jak inżynieria.

Nie każdy klient i nie każdy tryb pracy powinien widzieć te same narzędzia. Inny zestaw ma sens dla prostego użytkownika, inny dla operatora, a inny dla administratora.

basic:
- wyszukiwanie pamięci
- odczyt wpisów
- zapis wpisów

operator:
- timeline
- konflikty
- jakość pamięci
- linkowanie

admin:
- pliki
- SQL
- migracje
- narzędzia diagnostyczne

Agent nie musi mieć kluczy do całego królestwa. Potrzebuje właściwego klucza do właściwych drzwi. To podejście dobrze łączy się z wcześniejszym tekstem o semi-agencie MCP.

Po połączeniu z takim serwerem model może działać według powtarzalnego cyklu. Nie polega to na tym, że model „sam wszystko wie”. Polega na tym, że ma procedurę, narzędzia i trwały kontekst.

1. Klient MCP łączy się z lokalnym serwerem.
2. Model wykonuje bootstrap kontekstu.
3. Model wyszukuje istotne wpisy w pamięci.
4. Pobiera szczegóły i linki, jeśli trzeba.
5. Wykonuje zadanie.
6. Zapisuje ważny wynik jako nowy wpis pamięci.
7. Istotne zdarzenie trafia na timeline.

Bez MCP model odpowiada z rozmowy. Z MCP i pamięcią może pracować na stanie projektu. To praktyczna różnica, nie marketingowy brokat.

Nawet prosty lokalny serwer MCP pozwala zbudować agenta, który potrafi pamiętać decyzje projektowe, sprawdzać, czy coś już było robione, zapisywać wyniki pracy, odczytywać wcześniejsze ustalenia i porządkować dokumentację.

To nadal nie zastępuje programisty, testera ani operatora. Ale zmienia sposób pracy z modelem. Zamiast jednej rozmowy dostajemy środowisko pracy.

Na start nie potrzeba wielkiej platformy. Minimalna wersja może zawierać lokalny serwer MCP, SQLite albo prostą bazę plikową, narzędzia do szukania i zapisu pamięci, bootstrap kontekstu oraz ograniczony dostęp do katalogu roboczego.

Dopiero później warto dokładać wyszukiwanie semantyczne, statusy świeżości pamięci, rewalidację wpisów, konflikty, graf relacji, automatyczne porządkowanie pamięci i raporty jakości.

Największy błąd to zacząć od zbyt dużej architektury. Drugi największy to dać modelowi za dużo narzędzi. Trzeci to pomylić pamięć z bezładnym dopisywaniem notatek.

MAPI-local-medium daje modelowi trzy rzeczy:

pamięć,
narzędzia,
ograniczenia.

Pamięć pozwala wracać do wcześniejszych ustaleń. Narzędzia pozwalają robić coś więcej niż pisać odpowiedzi. Ograniczenia sprawiają, że całość nie zmienia się w pijanego chochlika z uprawnieniami administratora.

To jest sedno praktycznego agenta AI: nie jeden prompt, który robi cuda, tylko mały, dobrze opisany warsztat, w którym model ma dostęp do kontekstu, wykonuje konkretne operacje i wie, gdzie kończą się jego uprawnienia.

Więcej o repozytorium znajdziesz na stronie MAPI-local-medium, a kod projektu w repo github.com/cabo0m/MAPI-local-medium.