---
title: "Wat je bij elke MCP-toolaanroep moet loggen"
description: "Een client ziet een externe MCP-server als één ondoorzichtige span, en een directorydashboard ziet totalen. Alleen de server heeft de aanroep gezien. De rij die de MCP-servers van Tajo voor elke aanroep schrijven, veld voor veld, wat eruit wordt geschrapt en wat niet is gebouwd."
url: https://tajo.io/nl/blog/what-to-log-for-every-mcp-tool-call/
markdown: https://tajo.io/nl/blog/what-to-log-for-every-mcp-tool-call.md
lang: nl-NL
author: "Set Noa"
author_url: https://tajo.io/nl/set-noa/
published: 2026-11-06
updated: 2026-11-06
alternates: {en-US: /blog/what-to-log-for-every-mcp-tool-call.md, bg-BG: /bg/blog/what-to-log-for-every-mcp-tool-call.md, cs-CZ: /cz/blog/what-to-log-for-every-mcp-tool-call.md, de-DE: /de/blog/what-to-log-for-every-mcp-tool-call.md, da-DK: /dk/blog/what-to-log-for-every-mcp-tool-call.md, es-ES: /es/blog/what-to-log-for-every-mcp-tool-call.md, fr-FR: /fr/blog/what-to-log-for-every-mcp-tool-call.md, el-GR: /gr/blog/what-to-log-for-every-mcp-tool-call.md, hi-IN: /hi/blog/what-to-log-for-every-mcp-tool-call.md, id-ID: /in/blog/what-to-log-for-every-mcp-tool-call.md, hr-HR: /hr/blog/what-to-log-for-every-mcp-tool-call.md, hu-HU: /hu/blog/what-to-log-for-every-mcp-tool-call.md, it-IT: /it/blog/what-to-log-for-every-mcp-tool-call.md, ja-JP: /jp/blog/what-to-log-for-every-mcp-tool-call.md, ko-KR: /kr/blog/what-to-log-for-every-mcp-tool-call.md, ar-SA: /ar/blog/what-to-log-for-every-mcp-tool-call.md, no-NO: /no/blog/what-to-log-for-every-mcp-tool-call.md, pl-PL: /pl/blog/what-to-log-for-every-mcp-tool-call.md, pt-BR: /pt/blog/what-to-log-for-every-mcp-tool-call.md, ro-RO: /ro/blog/what-to-log-for-every-mcp-tool-call.md, ru-RU: /ru/blog/what-to-log-for-every-mcp-tool-call.md, sv-SE: /se/blog/what-to-log-for-every-mcp-tool-call.md, zh-CN: /zh-cn/blog/what-to-log-for-every-mcp-tool-call.md, sl-SI: /sl/blog/what-to-log-for-every-mcp-tool-call.md, sr-Latn-RS: /sr/blog/what-to-log-for-every-mcp-tool-call.md, th-TH: /th/blog/what-to-log-for-every-mcp-tool-call.md, tr-TR: /tr/blog/what-to-log-for-every-mcp-tool-call.md, ur-PK: /ur/blog/what-to-log-for-every-mcp-tool-call.md, vi-VN: /vi/blog/what-to-log-for-every-mcp-tool-call.md, sk-SK: /sk/blog/what-to-log-for-every-mcp-tool-call.md}
---

[AI-agents](https://tajo.io/nl/blog/?category=ai-agents)

# Wat je bij elke MCP-toolaanroep moet loggen

Een client ziet een externe MCP-server als één ondoorzichtige span, en een directorydashboard ziet totalen. Alleen de server heeft de aanroep gezien. De rij die de MCP-servers van Tajo voor elke aanroep schrijven, veld voor veld, wat eruit wordt geschrapt en wat niet is gebouwd.

MCP-server logging

Wat moet een MCP-server bij elke toolaanroep vastleggen?

Log één rij per toolaanroep, op de server, want de server is de enige plek die hem heeft gezien. De MCP-servers van Tajo leggen vast wie de aanroep deed (het id van de sleutel, nooit het geheim), welke server en connector, de tool als die bestaat, de effectklasse, ok of een korte foutcode, duur, resultaatgrootte, trace-id, de records die de aanroep raakte, en de argumenten en het antwoord, geschoond van geheimen en persoonsgegevens. Rijen worden gelezen met logs.list en logs.get en na 30 dagen verwijderd. Ze staan los van het auditlog met hashketen, waar goedkeuringen en de digests van hun input worden bewaard. Niet gebouwd: een gezondheidsscore, een alert op het foutpercentage, zoeken op tool of trace-id, en export naar je eigen tracing.

[Meer informatie](https://tajo.io/nl/blog/what-to-log-for-every-mcp-tool-call/#e%C3%A9n-rij-per-aanroep)

Op 8 juni 2026 gaf Anthropic de eigenaren van connectors in de directory van Claude een dashboard. Het toont actieve gebruikers, het totaal aantal toolaanroepen en de positie in de directory. Het toont “[gezondheidsscore, foutpercentages en latency in één oogopslag, met een uitsplitsing van fouten per tool om precies aan te wijzen wat er misgaat](https://claude.com/resources/articles/observability-for-developers-building-connectors)”.

Een jaar eerder had Alex Volkov van Weights & Biases hetzelfde probleem vanaf de andere kant beschreven. Zodra zijn agent tools via MCP aanriep, was “[al die observability die ik gewend ben als mijn eigen code gewoon van begin tot eind draait, een beetje op zwart gegaan](https://www.youtube.com/watch?v=Lcqat4iP_lE&t=61s)”. Zijn medespreker, Benjamin Eckel van Dylibso, liet zien waarom. Een externe MCP-server “[verschijnt voor ons in de trace als één enkele service-span](https://www.youtube.com/watch?v=Lcqat4iP_lE&t=447s)”, omdat hij buiten de controle van de aanroeper draait.

Beide blikken staan buiten de server. De client ziet één ondoorzichtige span. De directory ziet totalen. Geen van beide zag wat de server werd gevraagd, wat hij weigerde en wat hij raakte. Alleen de server zag dat, dus alleen de server kan het opschrijven.

Dit is wat de MCP-servers van Tajo opschrijven, gelezen uit de code die ze draait en [beschreven in de documentatie](https://tajo.io/nl/docs/mcp/#mcp-request-log). [Wat een MCP-server is](https://tajo.io/nl/blog/what-is-an-mcp-server/) behandelt het protocol. Dit gaat over de rij.

## Eén rij per aanroep

Een dashboard is het zicht van de havenmeester: schepen binnen, schepen buiten, welke te laat waren. Het requestlog is het logboek van het schip zelf, aan boord geschreven, op het moment zelf.

Elke `tools/call` op de workspaceserver van Tajo en op elke connectorserver [eindigt in één rij](https://tajo.io/nl/docs/mcp/#mcp-request-log). De rij wordt geschreven nadat het antwoord is opgebouwd, wat dat antwoord ook was. Een aanroep die wordt geweigerd omdat de sleutel niet mag schrijven, of omdat het endpoint alleen-lezen is, krijgt een rij zoals elke andere. Dat geldt ook voor een aanroep van een tool die niet bestaat.

Dit staat er in de rij, en dit weigert de rij te bewaren.

| Veld | Bewaard | Niet bewaard |
| --- | --- | --- |
| Wie | Het id van de API-sleutel die de aanroep deed. Een token uit een OAuth-aanmelding is ook een sleutel. | Het geheim van de sleutel of het prefix ervan. |
| Waar | De workspaceserver of een connectorserver, met de connector en het profiel. |  |
| Tool | De naam, als de server een tool met die naam heeft. | Elke andere naam die de client stuurt: die wordt opgeslagen als `(unknown)`. |
| Effect | `read`, `write`, `send` of `destructive`: het zwaarste effect dat de aanroep kon hebben. |  |
| Uitkomst | `ok`, of een korte foutcode in snake\_case zoals `unknown_tool`. | Fouttekst: alles wat geen code is, wordt opgeslagen als `tool_error`. |
| Duur en grootte | Milliseconden van binnenkomst tot antwoord, en de bytes die de aanroeper ontving. |  |
| Trace-id | Het id van het verzoek, uit een `x-request-id`-, `x-trace-id`- of W3C-`traceparent`-header, anders een nieuw. | Een headerwaarde die geen hex of UUID is. |
| Records | Tot 20 id’s van records die de aanroep noemde of opleverde: een contact, een bericht, een goedkeuring. | De records zelf. |
| Bodies | De argumenten en het antwoord, [geschoond](https://tajo.io/nl/docs/mcp/#mcp-request-log), elk hoogstens 4 KB. | Geheimen, vrije tekst en de persoonsgegevens die hieronder staan. |

Drie van die weigeringen gaan over de client, niet over de data. Een toolnaam, een foutcode en een trace-id komen allemaal van buiten. Elk wordt alleen bewaard in een vorm waar de server voor kan instaan. Een log dat opslaat wat de aanroeper ook maar stuurde, kan met alles worden gevuld, ook met het e-mailadres van een klant in de kolom voor de toolnaam.

De open vraag van Benjamin Eckel aan het eind van de talk was hoe een collector weet “[dat het een MCP-toolaanroep is die een fout heeft](https://www.youtube.com/watch?v=Lcqat4iP_lE&t=906s)”. Op één server is het antwoord een kolom. `ok` is false, en de code zegt welke fout.

## De argumenten: een regel die we hebben omgedraaid

Het bezwaar is terecht, en het is ons eigen bezwaar. Log de argumenten en je hebt een tweede kopie van de gegevens van je klanten gebouwd, buiten het bereik van elk verwijderverzoek. Tot 18 oktober 2026 was dat [onze eigen regel](https://tajo.io/nl/docs/mcp/#mcp-request-log). Het log bewaarde de argumenten noch de resultaatbody, omdat beide persoonsgegevens kunnen bevatten.

Het was de verkeerde afweging. Een requestlog dat niet kan laten zien wat er werd verstuurd en wat er terugkwam, kan de ene vraag waarvoor het bestaat niet beantwoorden: waarom mislukte de aanroep van mijn agent?

Dus worden de bodies bewaard, en de reden waarom dat eerst niet gebeurde, wordt op een andere manier ondervangen. Elke body gaat door [één deterministische ronde](https://tajo.io/nl/docs/mcp/#mcp-request-log) voordat hij in de wachtrij komt.

- **Geen geheim overleeft.** Een veld waarvan de naam wijst op token, wachtwoord, secret, handtekening, cookie, sessie of zo’n twintig vergelijkbare woorden, houdt alleen `[secret]` over. Hetzelfde geldt voor een waarde in een bekende vorm van inloggegevens, waar die ook opduikt. Daaronder vallen bearer tokens, JWT’s, private keys, URL’s met een wachtwoord en elke ondoorzichtige reeks van 40 of meer sleuteltekens.
- **Lopende tekst wordt helemaal niet bewaard.** Een veld met de naam `html`, `text`, `body`, `markdown` of `content` houdt alleen `[redacted]` over. Lopende tekst bevat namen en postadressen die geen enkel patroon vindt.
- **Persoonsgegevens worden voorgoed gemaskeerd.** Een veld waarvan de naam op persoonsgegevens wijst, zoals een e-mail, een telefoon, een naam, een adres of een notitie, houdt alleen `[redacted]` over. Een e-mailadres, een telefoonnummer, een kaart of een IBAN binnen een andere string wordt gemaskeerd.
- **Bodies blijven klein.** [Strings worden afgekapt op 512 tekens](https://tajo.io/nl/docs/mcp/#mcp-request-log), lijsten op 20 items, objecten op 50 sleutels en nesting op 6 niveaus. De hele body wordt [afgekapt op 4 KB](https://tajo.io/nl/docs/mcp/#mcp-request-log) en als ingekort gemarkeerd.

Twee soorten aanroepen bewaren minder. Contacten die de chat van iemand uit een andere app meenam, worden gelogd als een markering en een aantal, nooit als body. Een aanroep die het log leest, bewaart geen antwoord, want dat antwoord zou alleen uit andere logrijen bestaan.

Nu de prijs. Het maskeren is blijvend, geen versleuteling met een sleutel die iemand bezit. Het log kan je het e-mailadres dat bouncete niet laten zien. Het laat je het id van het contact zien, en het contact is, onder zijn eigen regels, één aanroep verderop. Het log valt buiten de verwijderronde van de workspace, en daarom kan het maskeren daar niet op wachten.

## Waarom het log niet de audittrail is

Tajo heeft al [een append-only auditlog](https://tajo.io/nl/docs/mcp/#mcp-request-log). Elke rij bevat een hash van de rij ervoor, zodat een wijziging waar dan ook de keten breekt. Waarom schrijf je de toolaanroepen daar dan niet?

Omdat de keten een prijs heeft. Elke toevoeging neemt een lock per workspace en leest de vorige rij om de keten te verlengen. Als elke leesactie daar werd geschreven, kwamen de aanroepen van een workspace achter één lock in de rij te staan. Ook zouden de statuswijzigingen die het auditlog moet laten zien, ondersneeuwen onder duizenden leesacties.

Dus verdelen de twee registraties de vragen. Het requestlog zegt wat een agent vroeg en wat er gebeurde, [gedurende 30 dagen](https://tajo.io/nl/docs/mcp/#mcp-request-log). Het auditlog zegt wat er veranderde, wie het toestond en of iemand de registratie sindsdien heeft bewerkt.

Goedkeuringen staan aan de auditkant. Op de connectorprofielen van Tajo [zet een propose-tool een gedeclareerde actie klaar en voert een apply-tool die uit zodra ze is goedgekeurd](https://tajo.io/nl/docs/mcp/). Niets bereikt de provider voordat het voorstel is goedgekeurd, door een persoon of door een regel die de workspace heeft ingeschakeld. De rij van de propose-aanroep noemt onder zijn records de goedkeuring die hij aanmaakte. De goedkeuring zelf is gebonden aan een SHA-256-digest van de exacte input. [Een goedkeuring geldt voor precies de input die je zag](https://tajo.io/nl/docs/mcp/agent-specification/): verander één veld en ze klopt niet meer. Wanneer de schrijfactie aankomt, bewaart de auditrij ervan de input-digest en een digest van het antwoord van de provider, nooit de waarden van dat antwoord.

## Wat de rij kost

Een rij is een schrijfactie in de database, en een schrijfactie heeft een commit. [Tot 8 oktober 2026](https://tajo.io/nl/docs/mcp/#mcp-request-log) wachtte elke aanroep vóór het antwoord op zijn eigen commit, ongeveer 2,6 ms op onze host. Voor één client was dat een kwart van een kleine toolaanroep.

Nu wordt de rij opgebouwd wanneer de aanroep eindigt en in de wachtrij gezet. Een flush schrijft de wachtrij [hoogstens 100 ms later](https://tajo.io/nl/docs/mcp/#mcp-request-log), één transactie per workspace, zodat veel aanroepen één commit delen. Aan een rij verandert niets, ook de tijdstempel niet. Als er [5.000 rijen wachten](https://tajo.io/nl/docs/mcp/#mcp-request-log), wacht de volgende aanroep op de flush in plaats van een rij te laten vallen.

Vastleggen laat nooit een aanroep mislukken. Een schrijfactie die mislukt, wordt rij voor rij opnieuw geprobeerd, daarna gelogd en weggegooid. Wat een harde kill van het proces verliest, is wat er in de wachtrij stond: [hoogstens de aanroepen van de laatste 100 ms](https://tajo.io/nl/docs/mcp/#mcp-request-log).

## Teruglezen

[`logs.list`](https://tajo.io/nl/docs/mcp/#mcp-request-log) geeft de aanroepen van de workspace terug, nieuwste eerst, zonder bodies. Het filtert op tijd, op uitkomst of HTTP-status, op bron (MCP of de REST API, die de tabel deelt) en op API-sleutel. Standaard geeft het 50 per pagina, tot 100. `logs.get` geeft één aanroep terug met de huidige naam van de sleutel, de status, de duur, het geschoonde verzoek en antwoord, en de records die hij raakte.

Beide lezen alleen de workspace van de aanroeper. Een rij-id uit een andere workspace wordt niet gevonden.

Een toolfout draagt het request-id. Als de server dat id heeft aangemaakt, of als het binnenkwam als hex of als UUID, is het de trace-id van de rij. Een agent die een fout kreeg, kan een persoon de ene waarde geven die de aanroep benoemt.

## Wat er gebouwd is, en wat niet

Gebouwd, op het moment van schrijven:

- Eén rij per `tools/call` op de workspaceserver en op elke connectorserver, geweigerde en onbekende aanroepen inbegrepen.
- [Sleutel-id, server, connector, profiel, tool, effect, uitkomst, duur, resultaatgrootte, trace-id en tot 20 geraakte records](https://tajo.io/nl/docs/mcp/#mcp-request-log).
- [Geschoonde argumenten en antwoorden](https://tajo.io/nl/docs/mcp/#mcp-request-log), elk hoogstens 4 KB.
- [`logs.list` en `logs.get`](https://tajo.io/nl/docs/mcp/#mcp-request-log), beperkt tot de workspace, met 30 dagen bewaartermijn.
- Goedkeuringen gebonden aan een input-digest, en uitgevoerde schrijfacties vastgelegd met input- en output-digests in het auditlog met hashketen.

Niet gebouwd, en goed om te weten voordat je erop vertrouwt:

- Geen gezondheidsscore, geen grafiek per tool en geen alert bij een stijgend foutpercentage. Een overzicht per tool van aanroepen, fouten en traagste duur [bestaat voor de operators van Tajo](https://tajo.io/nl/docs/mcp/#mcp-request-log), niet op een plek die jij kunt openen.
- `logs.list` kan niet filteren op toolnaam of trace-id. Om de rij achter een request-id te vinden, beperk je op tijd en sleutel.
- Rijen worden niet geëxporteerd naar een tracingsysteem dat je zelf draait. De trace-id wordt alleen uit HTTP-headers gelezen, niet uit het MCP-veld `_meta` dat in de talk werd gebruikt om [tracecontext mee te sturen](https://www.youtube.com/watch?v=Lcqat4iP_lE&t=535s).
- [Na 30 dagen wordt een rij verwijderd](https://tajo.io/nl/docs/mcp/#mcp-request-log). Er is geen archief of export.
- Wat gemaskeerd is, kan niet uit het log worden teruggehaald.
- [Een harde kill kan de rijen van de laatste 100 ms kwijtraken](https://tajo.io/nl/docs/mcp/#mcp-request-log).

De talk sloot af met de vaststelling dat observability in MCP “[niet gelijk verdeeld](https://www.youtube.com/watch?v=Lcqat4iP_lE&t=841s)” is. Een dashboard verderop kan dat niet oplossen, en een trace die bij de deur van de server ophoudt evenmin. [Een synchronisatie die mislukt, heeft haar eigen registratie nodig](https://tajo.io/nl/blog/worker-died-sync-didnt/); net als elke aanroep die om een synchronisatie vroeg.

De server zag de aanroep. Niemand anders. Schrijf het daar op.

## Veelgestelde vragen

**Wat moet een MCP-server bij elke toolaanroep loggen?**

Eén rij per aanroep, geschreven door de server: welke API-sleutel de aanroep deed, welke server en connector, de toolnaam als de tool bestaat, de effectklasse, ok of een korte foutcode, de duur, de grootte van het resultaat, de trace-id van het verzoek, de id's van de records die de aanroep noemde of opleverde, en de argumenten en het antwoord, geschoond van geheimen en persoonsgegevens. De MCP-servers van Tajo schrijven die rij voor elke tools/call, geweigerde aanroepen inbegrepen, en bewaren hem 30 dagen.

**Moet een MCP-requestlog de toolargumenten bewaren?**

Ja, geschoond. Een log zonder de argumenten kan niet zeggen waarom een aanroep mislukte. Tajo bewaarde tot 18 oktober 2026 geen bodies en bewaart nu beide, na één deterministische ronde: geheimen worden \[secret\], vrije tekst en persoonlijke velden worden \[redacted\], e-mailadressen, telefoonnummers, kaarten en IBAN's worden gemaskeerd, en elke body wordt afgekapt op 4 KB. Het maskeren is blijvend, dus het log verwijst naar het record via zijn id in plaats van het te kopiëren.

**Waarom staat het log van MCP-toolaanroepen los van het auditlog?**

Omdat ze verschillende vragen beantwoorden tegen verschillende kosten. Het auditlog van Tajo is een hashketen van statuswijzigingen, en elke toevoeging neemt een lock per workspace om de keten te verlengen. Als elke leesactie daar werd geschreven, kwamen de aanroepen van een workspace achter die lock in de rij te staan en verdwenen de wijzigingen tussen de leesacties. Toolaanroepen gaan naar een aparte tabel zonder keten, die 30 dagen wordt bewaard; de schrijfacties die een aanroep klaarzet, laten nog steeds hun eigen auditrijen achter.

## Gerelateerde artikelen

### [Wat is een MCP-server? Zo werken MCP en MCP UI in 2026](https://tajo.io/nl/blog/what-is-an-mcp-server/)

3 okt 2026 · 15 min leestijd

Stap 1 → Stap 6

### [Grok Bot en Brevo: van productverzoek naar bevestigde klantopvolging](https://tajo.io/nl/blog/grok-bot-brevo-product-feedback/)

7 okt 2026 · 4 min leestijd

3 secties

### [MCP of CLI is de verkeerde vraag. Vraag waar de state woont.](https://tajo.io/nl/blog/mcp-or-cli-is-the-wrong-question/)

4 nov 2026 · 7 min leestijd

5 secties