MCP vs REST tools — hat hónap tapasztalat

2025 második felében kezdtünk komolyan MCP-szerverekkel dolgozni. Most, hat hónappal és öt szerverrel később (admin-mcp, finance-mcp, logistics-mcp, sales-ai-mcp, engine-mcp), érdemes leírni, mit nyertünk vele, és hol maradtunk a REST mellett.

A növekedés

• 2025 december: 0 MCP tool
• 2026 június: 919 regisztrált tool öt szerveren
  • admin-mcp: ~478
  • finance-mcp: 144
  • consulting-mcp: 193
  • logistics-mcp: 77
  • sales-ai-mcp: 47
  • assistant-mcp: 27

Ez nem a tooláradat dicsérete. Ez egy térkép arról, hogy mennyit lehetett strukturáltan kitenni minden domainből.

Hol nyer az MCP

1. Schema discovery

A REST-nél minden integráció kezdődött a kliens-csapat "adj egy OpenAPI specet" kéréssel. Az MCP-nél a chat-agent maga lekérdezi a tools/list-et, és látja az aláírásokat. Nincs külön "specet kell tartani" tartozás. Az agent egyetlen futás alatt felfedezi, mi van.

2. Per-tenant scoping

Minden MCP tool kontextusból olvassa a tenantId-t (NestJS ALS-en keresztül). A REST endpointnál ezt explicit kellett mindenhol átadni, és minden új ügyfél integráció után végig kellett menni a kéréseken, hogy a header ott van-e. Az MCP-nél a tenant scope a tool-hívás belső kontextusában él. Egyetlen helyen állítjuk be, mindenhol érvényes.

3. Token-költség

Egy REST API leírása az agent system promptjában durván 8-12k token. Egy MCP-szerver tool-listája dinamikusan lekérdezve, és csak a releváns tool-ok mennek be a kontextusba: átlag 2.1k token. A különbség egy 100k beszélgetésnél napi szinten USD-ben mérhető.

Hol marad a REST

1. Hosszan futó job-ok

Egy 8 perces report-generálás vagy egy 2 perces image-render rossz választás MCP tool-nak. Az MCP request-response, és a 60 másodperces időkorlát után az agent feladja. REST + job-id polling vagy webhook itt jobb. Mi a hosszan futó dolgokat job-id-vel adjuk vissza, és a getJobStatus(jobId) MCP tool-ként él. Az agent pollozza, az endpoint REST marad.

2. Streamelt válaszok

LLM-streaming, server-sent events, websocket-alapú push: az MCP nem ide való. Itt REST-fragment + WebSocket-csatorna nyer.

3. OAuth-védett upstreamek

Google/Microsoft/Stripe — ahol külső OAuth flow van a tenant és az upstream között, MCP tool-ba csomagolni lehet, de a hibajavítás (token refresh, scope-bővítés, consent screen redirect) nehézkes. REST + saját proxy itt egyszerűbb.

A hibrid minta amit beállítottunk

Ma minden új feature esetén egy egyszerű döntési fa fut:

1. Olvasási művelet (idempotens, < 5 sec) → MCP tool, kötelező
2. Írási művelet (mutáció, < 5 sec) → MCP tool, audit-trail kötelező
3. Bármi > 5 sec → REST endpoint job-id-vel + opcionális getJobStatus MCP tool
4. Streaming → REST/WebSocket, MCP nem érdekel
5. OAuth handshake → REST + saját callback handler

Ezzel a tool-katalógus tovább nőhet anélkül, hogy a long-running vagy a streaming use-case-ek elrontanák a chat élményt.

Az audit-trail darab

Minden írási MCP tool kötelezően ír egy audit_event rekordot Postgresbe. Tool name, args (PII maskolva), tenant, actor, timestamp, sikeresség. Ez az egyik dolog, amit a REST-nél elfelejtettünk volna, de az MCP-nél a tool-implementáció részévé tettük. Hat hónapja egyetlen "mit csinált a bot 3 hete?" kérdést sem volt nehéz megválaszolni.

Hibák amiket elkövettünk

• Tool-leírások túl rövidek voltak az első hónapokban. Az agent rosszul választott. Most minden tool-leírás minimum 60 szó, példa-args-szel.
• Túl sok tool egy szerveren. Az admin-mcp 478 tool-ja az agent kontextusát megfeszíti. Most domain-szelektorral küldjük csak a releváns aldomain tool-jait.
• A getById tool-ok visszaadták a teljes entitást. Túl sok token. Most projection-alapú: az agent választja, mely mezőket kéri.

Mit csinálnánk másképp

Ha újrakezdenénk: nem 0-ról 478-ra megyünk. Egy domain, egy szerver, 30 tool — utána mérünk. Az MCP nem a tool-mennyiségről szól. A tool-minőségről.

A fejlesztési ritmus

Most mind az öt MCP szervernek külön "tool katalógus owner"-e van. Az ő dolga eldönteni, hogy egy új modul mit érdemes tool-ként kitenni, és hogy a meglévő tool-ok között mit kell összevonni vagy kivonni. Hat hónap után átlagosan 4-6 tool/hét bővülési sebességet látunk, ami egészséges. Túl gyors növekedés (heti 20+) általában azt jelenti, hogy nem gondolkodtunk eleget. Túl lassú (havi 1-2) általában azt, hogy a domain a stabilizálódás közelében van.

A tool-katalógus governance lényegében ugyanaz, mint egy belső API governance. Ne legyen tulajdonosok nélküli tool. Minden tool-nak van versionált aláírása. A deprecation 6 hetes előzetes figyelmeztetéssel megy. Egyetlen tool eltávolítása sem hibrid: vagy fennáll vagy nem. Ez az egyetlen módja, hogy az agent ne bukjon el egy üzleti döntés szintű kapuban.