Je MCP-Server Zou Elke Week Slimmer Moeten Worden

Goede tool-descriptions schrijven is het begin. Ze goed houden is het echte werk.

De beschrijvingsblokken die ik behandelde in een eerder bericht vormen de initiële kennislaag. Maar hoe weet je wat er ontbreekt? Hoe vind je de gaten waar de agent stilletjes omheen werkt zonder het je te vertellen? Daar komt de feedbackarchitectuur om de hoek kijken.

Na het draaien van zeven MCP-servers in productie kwam ik uit op drie lagen, ruwweg gewogen 70/20/10 qua waarde, met één ontwerpkeuze die alles aan elkaar knoopt.

Laag 1: Tool-call logs (70% van de waarde)

Log elke tool-call: requestparameters, response-samenvatting, sessie-ID, timestamp. Geen chattekst, geen gebruikersvragen, geen agent-redenering. Alleen de MCP-laag.

Dit is het fundament. Drie opeenvolgende calls met aanscherpende filters op dezelfde tabel betekent dat de agent worstelt met iets dat de metadata had moeten dekken. Je hebt de agent niet nodig om te zeggen dat hij in de war is. Het call-patroon vertelt het je.

In de productie-implementatie schrijft elke tool-call naar een persistent store met: toolnaam, gebruiker, queryIntent, filtervelden en operatoren (geen waarden, vanwege privacy), summaryOnly-flag, rijtelling, duur en fouttype. Sessie-ID's correleren multi-tool sequenties.

Laag 2: Patroonanalyse (20% van de waarde)

Wekelijkse analyse van de ruwe logs. Zoek naar herhaalde call-sequenties, overbodige calls, ongebruikte tools die wel hadden moeten worden gebruikt, tools die in onverwachte volgorde werden aangeroepen.

Sessie-ID's maken dit mogelijk. Je kunt een volledige multi-tool interactie van begin tot eind traceren en vragen: waar nam de agent een omweg? Waar riep hij tool A aan terwijl het antwoord in tool B zat? Waar deed hij een retry met andere filters omdat de eerste call niet teruggaf wat hij verwachtte?

Dit vindt stille fouten: gevallen waarbij de agent een verkeerd antwoord gaf zonder het te beseffen.

Laag 3: QueryIntent + rapportagetool (10% van de waarde)

Een queryIntent-parameter op elke tool-call: één zin die de zakelijke vraag beschrijft. Plus een rapportagetool die de agent kan gebruiken als hij echt vastzit.

Hier wordt het concreet. Dezelfde drie-call sequentie, met en zonder queryIntent:

Zonder:

09:14:03 | get_service_records | summaryOnly=true, project=P-7056

09:14:07 | get_service_records | type=13, project=P-7056

09:14:09 | get_service_records | type=13, project=P-7056, completed=true

Drie calls. De laatste voegde een filter toe. Waarom? Onbekend.

Met:

09:14:03 | intent: Overzicht van alle servicerecords voor project P-7056

09:14:07 | intent: Welke onderhoudsopdrachten bestaan voor dit project

09:14:09 | intent: Alleen afgeronde opdrachten, vorige call gaf ook openstaande items

Nu zie je precies wat er gebeurde: de agent verwachtte alleen afgeronde items, maar de metadata maakte niet duidelijk dat een afrondingsfilter nodig is. Dat is een gerichte metadata-fix die minuten kost.

Nudge-patronen: feedback laten gebeuren

Agents rapporteren niet betrouwbaar uit zichzelf. Academisch onderzoek laat gemengde resultaten zien over LLM-metacognitie. Dus in plaats van te vertrouwen op het initiatief van de agent, injecteert de productie-implementatie contextuele nudges in tool-responses:

• Lege resultaten: "Geen records kwamen overeen met je filters. Als dat onverwacht is, overweeg report_problem aan te roepen."
• Paginatie gedetecteerd: "Je pagineert (skip=200). Als je dit doet om handmatig data te aggregeren, roep report_problem aan. We kunnen mogelijk die samenvattingsdimensie toevoegen."
• Elk antwoord: Een feedbackherinnering als laatste alert: "Als deze query meerdere pogingen kostte of verwarrende data opleverde, roep report_problem aan voor je volgende stap."

Deze nudges worden geïnjecteerd door de handler-factory van de server, niet door het oordeel van de agent. Ze richten zich op specifieke frictiepatronen en geven de agent een laagdrempelig pad om problemen te melden die hij anders stilletjes zou omzeilen.

Waarom dit compound werkt

Elk opgelost probleem maakt het systeem permanent slimmer. Een metadata-update is geen patch. Het elimineert een hele categorie onzekerheid voor elke toekomstige sessie, elke verbonden agent. De metadatalaag wordt rijker over tijd terwijl de redeneringslaag gelijk blijft. Goedkope, permanente, samengestelde vooruitgang.

Voor het complete ontwerp van de feedbackarchitectuur, inclusief het sessie-ID-correlatiepatroon en hoe het verbindt met de vijffasenmethode, download het practitioner report.