ICS przez MCP: agent czyta treść, a błędy lądują od razu w OpenProject

Krótki tekst o tym, jak działa nasz ICS przez MCP — i dlaczego dopiero w parze z drugim serwerem MCP (OpenProject) robi się z tego coś więcej niż „kolejne miejsce na pliki”.

Mieliśmy taki moment. Kazałem agentowi przygotować i przejrzeć treść w ICS — zwykła robota redakcyjna, poukładać, opisać, pokazać. Patrzę, a on długo mieli wywołania ICS. Dłużej, niż się spodziewałem przy „tylko przeczytaj”. Pytam wprost: co ty właściwie robisz?

Odpowiedź: „znalazłem błędy w treści”. Nie zatrzymał się na samym renderowaniu, tylko przy okazji czytania zaczął wyłapywać nieścisłości. Więc bez kombinowania: to wrzuć je od razu do OpenProject jako zadania. I wrzucił. Tym samym agentem, w tej samej sesji, drugim serwerem MCP. Z przeglądania treści od ręki zrobił się backlog poprawek.

I to jest cały sens tego tekstu. ICS sam w sobie jest wygodny. Ale wartość widać dopiero wtedy, gdy agent ma jednocześnie warstwę treści (ICS) i warstwę pracy (OpenProject) i potrafi przejść z jednej do drugiej bez człowieka w środku jako przekładni.

Co to jest ICS

ICS (Internal Content Sharing) to nasza wewnętrzna platforma do zapisywania i udostępniania treści — coś jak osobisty CMS, ale na całą organizację. Repo: inprojects-ai-tools/ics, instancja pod ics.inprojects.ai.

Asset w ICS jest jednego z trzech rodzajów:

Każdy asset ma właściciela, może żyć w projekcie (członkowie projektu dziedziczą dostęp) i można go udostępnić — albo linkiem (org_sso / public / password / magic_email), albo konkretnej osobie z organizacji jako editor/viewer.

Jeśli znasz nasz sposób pracy z OpenProject, to ICS już tam mignął: prezentacja zespołowa OpenProject to właśnie html_bundle w ICS, udostępniony linkiem. Slajdy zrobił agent, opublikował do ICS, dostałem link do wklejenia. Bez wysyłania PDF-a po mailu, bez „wrzuć to gdzieś na Drive”.

Jak się tego używa: mówisz po ludzku

Nie wołasz żadnego ics_asset_create_md z palca. Mówisz agentowi po polsku, co ma być, a on sam dobiera narzędzia ICS. Tak jak przy OpenProject nie podajesz endpointów, tylko pytasz „co mam dziś zrobić”, tu nie podajesz slugów ani parametrów, tylko mówisz, co zrobić z treścią.

Kilka komend, których realnie używam:

• „Zrób z tego notatkę w ICS i daj mi link dla zespołu.” — agent zapisuje Markdown i zwraca link org_sso do wklejenia na Google Chat.
• „Zbierz te pliki w jedną kolekcję z wikilinkami.” — powstaje vault, czyli md_collection z nawigacją między notatkami.
• „Z tego raportu zrób pakiet HTML i daj publiczny link.” — agent buduje html_bundle, przepuszcza go przez security review i dopiero wtedy udostępnia.
• „Poszukaj u mnie czegoś o migracji Redmine i streść.” — wyszukanie pełnotekstowe, potem czytanie tylko trafionych fragmentów, nie całych dokumentów.
• „Zaktualizuj sekcję «Limity» w tamtej notatce.” — agent lokalizuje nagłówek, czyta kawałek, podmienia treść, reszta zostaje.

Pod spodem agent trzyma się prostej dyscypliny: najpierw tanio się rozejrzyj (lista, search, outline), potem czytaj punktowo, dopiero na końcu pisz. Nie musisz tego pilnować, robi to skill i sam serwer, zaprojektowany tak, żeby czytanie było tanie (paginacja, partial-read, snippety zamiast pełnych dokumentów), a zapis jawny.

Dwie rzeczy warto wiedzieć, bo robią różnicę przy agentach:

• Tryby pracy. Możesz powiedzieć „działaj bez pytania” albo „najpierw pokaż, co byś zrobił, nic nie ruszaj”. Domyślnie agent pyta przed kasowaniem. Zanim puścisz go na masowe porządki, ten tryb podglądu jest twoim przyjacielem.
• Limit ruchu. ICS przepuszcza 600 żądań na minutę na osobę i sam się wycofuje przy przekroczeniu, więc agent czytający dokument kawałek po kawałku nie spamuje, tylko porządnie przewraca strony. To zresztą tłumaczy moje „czemu on tak długo mieli” z początku — nie zaciął się, tylko sumiennie czytał.

I o to chodzi: warstwa pod spodem jest na tyle przewidywalna, że na wierzchu możesz po prostu mówić, czego chcesz.

Dwa MCP, jeden agent

Teraz sedno. Mój use case nie był „ICS robi coś magicznego”. Był „agent miał pod ręką dwa serwery MCP naraz”.

Agent czytał treść przez ICS. Przy okazji wyłapał błędy. A że w tej samej sesji miał wpięty openproject-mcp, to na jedno polecenie przełożył znaleziska na zadania: create_work_package z typem Bug, opis, projekt, i tyle. Treść została w ICS, robota do zrobienia wylądowała w OpenProject. Ja w środku nie przepisywałem niczego ręcznie.

To jest ta sama myśl, którą opisywałem przy OpenProject: ludzie i agenci mają pracować na jednej strukturze, nie obok siebie. Tylko że teraz są dwie struktury — treść i praca — i agent jest tym, co je zszywa. Człowiek mówi „znajdź i napraw proces”, a nie „skopiuj te trzy błędy z dokumentu do trackera, każdy osobno, nie pomyl projektu”.

Ten wzorzec wraca u nas regularnie. Inny przykład z zespołu: testowanie wyszukiwarki ICS na produkcji wyłapało lukę w widoczności wyników — i to znalezisko od razu poszło jako ticket opisany według naszej konwencji (sekcje Powtórzenie / Oczekiwane / Faktyczne / Regresja?). Nie „zapamiętam i założę później”. Znalazłeś → jest w systemie zadań, w ustandaryzowanej formie, gotowe do podjęcia.

Dlaczego to działa akurat na MCP

Można by powiedzieć: przecież to da się skryptem. Da się. Ale skrypt trzeba napisać pod konkretny kształt znaleziska, a agent nie. On czyta treść jak człowiek, decyduje co jest błędem, formułuje to po ludzku i dopiero wykonanie (założenie WP) leci deterministycznym narzędziem MCP.

Dlatego oba serwery są zbudowane tak samo: chowają surowe API za nazwanymi toolami z walidacją. openproject-mcp ukrywa pułapki HAL+JSON (_links, lockVersion, custom fields). ICS chowa zarządzanie wersjami, share’ami i CSP. Agent nie pali tokenów na składanie HTTP ani na parsowanie odpowiedzi, których nie potrzebuje — robi to, co tylko on potrafi (ocena treści), a brudną robotę zostawia narzędziom.

I jeszcze jedno, praktyczne: dwa MCP w jednej sesji to dwa zestawy narzędzi w kontekście. Jeśli odpalasz agenta na własnym base URL (np. przez firmowy gateway DeepSeeka), trzymaj włączone odraczanie narzędzi (ENABLE_TOOL_SEARCH=true), żeby nie wpychać obu pełnych zestawów przy każdej turze. Inaczej zapłacisz kontekstem za wygodę.

Jak zacząć

1. Wepnij ICS przez MCP. Konfiguracja siedzi w repo ICS. Pierwsze wywołanie zawsze to ics_help() (albo ics_help("tool-selection"), gdy nie wiesz, którego z dwóch toolów użyć) i ics_assets_list().
2. Miej obok drugi MCP, który coś robi. U nas to OpenProject. Treść bez warstwy wykonawczej to wciąż tylko ładne pliki.
3. Daj agentowi zadanie procesowe, nie czynnościowe. Nie „przeczytaj plik X”. Raczej „przejrzyj tę treść, a co znajdziesz nie tak — załóż jako zadania w projekcie Y”. Resztę dopowie sam.

Najlepszy test nie jest taki, czy agent zna endpointy ICS. Tylko czy umie sam przejść z warstwy treści do warstwy pracy, kiedy treść okazuje się do poprawki. U mnie umiał — i dlatego z „pokaż mi to ładnie” zrobił się przy okazji uporządkowany backlog.