---
title: "Hvad du skal logge for hvert MCP-værktøjskald"
description: "En klient ser en fjern MCP-server som ét uigennemsigtigt span, og et katalogdashboard ser totaler. Kun serveren så kaldet. Den række, Tajos MCP-servere skriver for hvert kald, felt for felt, hvad der renses ud af den, og hvad der ikke er bygget."
url: https://tajo.io/dk/blog/what-to-log-for-every-mcp-tool-call/
markdown: https://tajo.io/dk/blog/what-to-log-for-every-mcp-tool-call.md
lang: da-DK
author: "Set Noa"
author_url: https://tajo.io/dk/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, 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, nl-NL: /nl/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-agenter](https://tajo.io/dk/blog/?category=ai-agents)

# Hvad du skal logge for hvert MCP-værktøjskald

En klient ser en fjern MCP-server som ét uigennemsigtigt span, og et katalogdashboard ser totaler. Kun serveren så kaldet. Den række, Tajos MCP-servere skriver for hvert kald, felt for felt, hvad der renses ud af den, og hvad der ikke er bygget.

logning af mcp-server

Hvad skal en MCP-server skrive ned for hvert værktøjskald?

Log én række pr. værktøjskald, på serveren, fordi serveren er det eneste sted, der så kaldet. Tajos MCP-servere registrerer, hvem der kaldte (nøglens id, aldrig dens hemmelighed), hvilken server og connector, værktøjet, hvis det findes, dets effektklasse, ok eller en kort fejlkode, varighed, resultatstørrelse, trace-id, de poster, kaldet rørte ved, og argumenterne og svaret renset for hemmeligheder og persondata. Rækkerne læses med logs.list og logs.get og slettes efter 30 dage. De ligger adskilt fra den hashkædede auditlog, hvor godkendelser og deres input-digests gemmes. Ikke bygget: en sundhedsscore, en alarm på fejlrate, søgning på værktøj eller trace-id og eksport til din egen tracing.

[Læs mere](https://tajo.io/dk/blog/what-to-log-for-every-mcp-tool-call/#%C3%A9n-r%C3%A6kke-pr-kald)

Den 8. juni 2026 gav Anthropic ejerne af connectors i Claudes katalog et dashboard. Det viser aktive brugere, det samlede antal værktøjskald og placering i kataloget. Det viser en »[sundhedsscore, fejlrater og latenstid med ét blik, med fejl fordelt pr. værktøj, så du kan finde ud af, hvad der fejler](https://claude.com/resources/articles/observability-for-developers-building-connectors)«.

Et år tidligere havde Alex Volkov fra Weights & Biases beskrevet det samme problem fra den anden ende. Da hans agent først kaldte værktøjer over MCP, »[blev al den observability, jeg er vant til, når min egen kode kører fra ende til anden, lidt mørk](https://www.youtube.com/watch?v=Lcqat4iP_lE&t=61s)«. Hans medtaler, Benjamin Eckel fra Dylibso, viste hvorfor. En fjern MCP-server »[optræder for os i tracet som ét enkelt service-span](https://www.youtube.com/watch?v=Lcqat4iP_lE&t=447s)«, fordi den kører uden for kalderens kontrol.

Begge blikke står uden for serveren. Klienten ser ét uigennemsigtigt span. Kataloget ser totaler. Ingen af dem så, hvad serveren blev bedt om, hvad den afviste, og hvad den rørte ved. Det gjorde kun serveren, så kun serveren kan skrive det ned.

Her er det, Tajos MCP-servere skriver ned, læst ud af den kode, der kører dem, og [beskrevet i dokumentationen](https://tajo.io/dk/docs/mcp/#mcp-request-log). [Hvad en MCP-server er](https://tajo.io/dk/blog/what-is-an-mcp-server/) dækker protokollen. Her handler det om rækken.

## Én række pr. kald

Et dashboard er havnefogedens blik: skibe ind, skibe ud, hvilke der var forsinkede. Forespørgselsloggen er skibets egen logbog, skrevet om bord, mens det skete.

Hvert `tools/call` på Tajos arbejdsområdeserver og på hver connector-server [ender i én række](https://tajo.io/dk/docs/mcp/#mcp-request-log). Rækken skrives, når svaret er bygget, uanset hvad svaret var. Et kald, der afvises, fordi nøglen ikke må skrive, eller fordi endpointet er skrivebeskyttet, får en række som alle andre. Det samme gør et kald til et værktøj, der ikke findes.

Her er, hvad rækken indeholder, og hvad den nægter at indeholde.

| Felt | Gemmes | Gemmes ikke |
| --- | --- | --- |
| Hvem | Id’et på den API-nøgle, der kaldte. Et token fra et OAuth-login er også en nøgle. | Nøglens hemmelighed eller dens præfiks. |
| Hvor | Arbejdsområdeserveren eller en connector-server, med dens connector og profil. |  |
| Værktøj | Navnet, når serveren har et værktøj med det navn. | Ethvert andet navn, klienten sender: det gemmes som `(unknown)`. |
| Effekt | `read`, `write`, `send` eller `destructive`: den tungeste effekt, kaldet kunne have. |  |
| Udfald | `ok` eller en kort fejlkode i snake\_case som `unknown_tool`. | Fejltekst: alt, der ikke er en kode, gemmes som `tool_error`. |
| Varighed og størrelse | Millisekunder fra ankomst til svar og de bytes, kalderen modtog. |  |
| Trace-id | Anmodningens id, fra en `x-request-id`-, `x-trace-id`- eller W3C `traceparent`-header, ellers et nyt. | En headerværdi, der ikke er hex eller et UUID. |
| Poster | Op til 20 id’er på poster, kaldet nævnte eller skabte: en kontakt, en besked, en godkendelse. | Selve posterne. |
| Bodies | Argumenterne og svaret, [renset](https://tajo.io/dk/docs/mcp/#mcp-request-log), højst 4 KB hver. | Hemmeligheder, fritekst og de persondata, der står nedenfor. |

Tre af de afvisninger handler om klienten, ikke om dataene. Et værktøjsnavn, en fejlkode og et trace-id kommer alle udefra. Hver af dem gemmes kun i en form, serveren kan stå inde for. En log, der gemmer hvad som helst, kalderen sendte, kan fyldes med hvad som helst, også en kundes e-mailadresse i kolonnen til værktøjsnavnet.

Benjamin Eckels åbne spørgsmål i slutningen af talken var, hvordan en collector ved, »[at det er et MCP-værktøjskald, der har en fejl](https://www.youtube.com/watch?v=Lcqat4iP_lE&t=906s)«. På én server er svaret en kolonne. `ok` er falsk, og koden siger, hvilken fejl.

## Argumenterne: en regel, vi vendte om

Indvendingen er rimelig, og den er vores egen. Logger du argumenterne, har du bygget en ekstra kopi af dine kunders data, uden for enhver anmodning om sletning. Indtil 18. oktober 2026 var det [vores egen regel](https://tajo.io/dk/docs/mcp/#mcp-request-log). Loggen gemte hverken argumenterne eller svarets body, fordi begge kan indeholde persondata.

Det var den forkerte afvejning. En forespørgselslog, der ikke kan vise, hvad der blev sendt, og hvad der kom tilbage, kan ikke besvare det ene spørgsmål, den findes for: hvorfor fejlede min agents kald?

Så bodies gemmes, og grunden til, at de ikke blev det, imødekommes på en anden måde. Hver body går gennem [én deterministisk gennemgang](https://tajo.io/dk/docs/mcp/#mcp-request-log), før den sættes i kø.

- **Ingen hemmelighed overlever.** Et felt, hvis navn siger token, password, secret, signature, cookie, session eller omkring tyve lignende ord, beholder kun `[secret]`. Det samme gør en værdi i en kendt form for legitimationsoplysninger, uanset hvor den står. Det dækker bearer-tokens, JWT’er, private nøgler, URL’er med en adgangskode og enhver uigennemsigtig række på 40 eller flere nøgletegn.
- **Prosa gemmes slet ikke.** Et felt med navnet `html`, `text`, `body`, `markdown` eller `content` beholder kun `[redacted]`. Prosa indeholder navne og gadeadresser, som intet mønster finder.
- **Persondata maskeres for altid.** Et felt, hvis navn markerer persondata, som en e-mail, et telefonnummer, et navn, en adresse eller en note, beholder kun `[redacted]`. En e-mailadresse, et telefonnummer, et kort eller et IBAN inde i enhver anden streng maskeres.
- **Bodies forbliver små.** [Strenge skæres ved 512 tegn](https://tajo.io/dk/docs/mcp/#mcp-request-log), lister ved 20 elementer, objekter ved 50 nøgler og indlejring ved 6 niveauer. Hele bodyen [skæres ved 4 KB](https://tajo.io/dk/docs/mcp/#mcp-request-log) og markeres som afkortet.

To slags kald gemmer mindre. Kontakter, som en persons chat har hentet ind fra en anden app, logges som en markør og et antal, aldrig som en body. Et kald, der læser loggen, gemmer intet svar, fordi svaret kun ville være andre logrækker.

Så prisen. Maskeringen er permanent, ikke kryptering med en nøgle, som nogen har. Loggen kan ikke vise dig den e-mailadresse, der bouncede. Den viser dig kontaktens id, og kontakten er, under sine egne regler, ét kald væk. Loggen ligger uden for arbejdsområdets sletningsrunde, og derfor kan maskeringen ikke vente på en.

## Hvorfor loggen ikke er audit-sporet

Tajo har allerede [en auditlog, der kun kan tilføjes til](https://tajo.io/dk/docs/mcp/#mcp-request-log). Hver række bærer en hash af rækken før den, så en ændring hvor som helst bryder kæden. Hvorfor ikke skrive værktøjskald der?

Fordi kæden har en pris. Hver tilføjelse tager en lås pr. arbejdsområde og læser den forrige række for at forlænge kæden. Skrev man hver læsning igennem den, ville et arbejdsområdes kald stå i kø bag én lås. Det ville også begrave de tilstandsændringer, som auditloggen findes for at vise, under tusindvis af læsninger.

Så de to registreringer deles efter spørgsmål. Forespørgselsloggen siger, hvad en agent bad om, og hvad der skete, [i 30 dage](https://tajo.io/dk/docs/mcp/#mcp-request-log). Auditloggen siger, hvad der ændrede sig, hvem der tillod det, og om nogen har ændret registreringen siden.

Godkendelser hører til på audit-siden. På Tajos connector-profiler [forbereder et propose-værktøj en deklareret handling, og et apply-værktøj kører den, når den er godkendt](https://tajo.io/dk/docs/mcp/). Intet når frem til udbyderen, før forslaget er godkendt, af en person eller af en regel, som arbejdsområdet har slået til. Propose-kaldets række nævner den godkendelse, det skabte, blandt sine poster. Selve godkendelsen er bundet til et SHA-256-digest af det nøjagtige input. [En godkendelse dækker præcis det input, du så](https://tajo.io/dk/docs/mcp/agent-specification/): ændr ét felt, og den passer ikke længere. Når skrivningen lander, gemmer dens auditrække input-digestet og et digest af udbyderens svar, aldrig svarets værdier.

## Hvad rækken koster

En række er en skrivning i databasen, og en skrivning har en commit. [Indtil 8. oktober 2026](https://tajo.io/dk/docs/mcp/#mcp-request-log) ventede hvert kald på sin egen commit før svaret, omkring 2,6 ms på vores host. For én klient var det en fjerdedel af et lille værktøjskald.

Nu bygges rækken, når kaldet slutter, og sættes i kø. En flush skriver køen [højst 100 ms senere](https://tajo.io/dk/docs/mcp/#mcp-request-log), én transaktion pr. arbejdsområde, så mange kald deler én commit. Intet ved en række ændrer sig, heller ikke dens tidsstempel. Hvis [5.000 rækker venter](https://tajo.io/dk/docs/mcp/#mcp-request-log), venter det næste kald på flushen i stedet for at droppe en række.

Registrering får aldrig et kald til at fejle. En skrivning, der fejler, prøves igen række for række og bliver derefter logget og droppet. Det, et hårdt kill af processen mister, er det, der lå i køen: [højst de sidste 100 ms af kald](https://tajo.io/dk/docs/mcp/#mcp-request-log).

## Læs det tilbage

[`logs.list`](https://tajo.io/dk/docs/mcp/#mcp-request-log) returnerer arbejdsområdets kald, nyeste først, uden bodies. Den filtrerer på tid, på udfald eller HTTP-status, på kilde (MCP eller REST API’et, som deler tabellen) og på API-nøgle. Den viser som standard 50 pr. side, op til 100. `logs.get` returnerer ét kald med nøglens nuværende navn, dets status, dets varighed, den rensede anmodning og det rensede svar og de poster, det rørte ved.

Begge læser kun kalderens eget arbejdsområde. Et række-id fra et andet arbejdsområde findes ikke.

En værktøjsfejl bærer anmodningens id. Når serveren lavede det id, eller det kom som hex eller et UUID, er det rækkens trace-id. En agent, der fik en fejl, kan give en person den ene værdi, der navngiver kaldet.

## Hvad der er bygget, og hvad der ikke er

Bygget, da dette skrives:

- Én række pr. `tools/call` på arbejdsområdeserveren og hver connector-server, også afviste og ukendte kald.
- [Nøgle-id, server, connector, profil, værktøj, effekt, udfald, varighed, resultatstørrelse, trace-id og op til 20 berørte poster](https://tajo.io/dk/docs/mcp/#mcp-request-log).
- [Rensede argumenter og svar](https://tajo.io/dk/docs/mcp/#mcp-request-log), højst 4 KB hver.
- [`logs.list` og `logs.get`](https://tajo.io/dk/docs/mcp/#mcp-request-log), afgrænset til arbejdsområdet, med 30 dages opbevaring.
- Godkendelser bundet til et input-digest og udførte skrivninger registreret med input- og output-digests i den hashkædede auditlog.

Ikke bygget, og værd at vide, før du stoler på det:

- Ingen sundhedsscore, intet diagram pr. værktøj og ingen alarm ved en stigende fejlrate. En oversigt pr. værktøj over kald, fejl og langsomste varigheder [findes for Tajos driftsfolk](https://tajo.io/dk/docs/mcp/#mcp-request-log), ikke på nogen flade, du kan åbne.
- `logs.list` kan ikke filtrere på værktøjsnavn eller trace-id. For at finde rækken bag et anmodnings-id skal du indsnævre på tid og nøgle.
- Rækker eksporteres ikke til et tracingsystem, du selv kører. Trace-id’et læses kun fra HTTP-headere, ikke fra MCP-feltet `_meta`, som talken brugte til at [bære trace-kontekst](https://www.youtube.com/watch?v=Lcqat4iP_lE&t=535s).
- [Efter 30 dage slettes en række](https://tajo.io/dk/docs/mcp/#mcp-request-log). Der er intet arkiv og ingen eksport.
- Det, der blev maskeret, kan ikke genskabes fra loggen.
- [Et hårdt kill kan miste de sidste 100 ms af rækker](https://tajo.io/dk/docs/mcp/#mcp-request-log).

Talken sluttede med, at observability i MCP »[ikke er jævnt fordelt](https://www.youtube.com/watch?v=Lcqat4iP_lE&t=841s)«. Et dashboard længere nede ad strømmen kan ikke rette op på det, og det kan et trace, der stopper ved serverens dør, heller ikke. [En synkronisering, der fejler, har brug for sin egen registrering](https://tajo.io/dk/blog/worker-died-sync-didnt/); det har hvert kald, der bad om en, også.

Serveren så kaldet. Ingen andre gjorde. Skriv det ned der.

## Ofte Stillede Spørgsmål

**Hvad skal en MCP-server logge for hvert værktøjskald?**

Én række pr. kald, skrevet af serveren: hvilken API-nøgle der kaldte, hvilken server og connector, værktøjets navn, hvis værktøjet findes, dets effektklasse, ok eller en kort fejlkode, varigheden, resultatets størrelse, anmodningens trace-id, id'erne på de poster, kaldet nævnte eller skabte, og argumenterne og svaret med hemmeligheder og persondata renset ud. Tajos MCP-servere skriver den række for hvert tools/call, også afviste kald, og gemmer den i 30 dage.

**Skal en MCP-forespørgselslog gemme værktøjets argumenter?**

Ja, renset. En log uden argumenterne kan ikke sige, hvorfor et kald fejlede. Tajo gemte ingen bodies indtil 18. oktober 2026 og gemmer nu begge, efter én deterministisk gennemgang: hemmeligheder bliver til \[secret\], fritekst og personfelter bliver til \[redacted\], e-mailadresser, telefonnumre, kort og IBAN'er maskeres, og hver body skæres ved 4 KB. Maskeringen er permanent, så loggen peger på posten via id i stedet for at kopiere den.

**Hvorfor holde loggen over MCP-værktøjskald adskilt fra auditloggen?**

Fordi de besvarer forskellige spørgsmål til forskellige priser. Tajos auditlog er en hashkæde af tilstandsændringer, og hver tilføjelse tager en lås pr. arbejdsområde for at forlænge kæden. Skrev man hver læsning igennem den, ville et arbejdsområdes kald stå i kø bag den lås, og ændringerne ville drukne mellem læsningerne. Værktøjskald går til en separat tabel uden kæde, som gemmes i 30 dage; de skrivninger, et kald forbereder, efterlader stadig deres egne auditrækker.

## Relaterede artikler

### [Hvad er en MCP-server? Sådan virker MCP og MCP UI i 2026](https://tajo.io/dk/blog/what-is-an-mcp-server/)

3\. okt. 2026 · 14 min læsetid

Trin 1 → Trin 6

### [Grok Bot og Brevo: fra produktønske til bekræftet svar til kunden](https://tajo.io/dk/blog/grok-bot-brevo-product-feedback/)

7\. okt. 2026 · 4 min læsetid

3 afsnit

### [MCP eller CLI er det forkerte spørgsmål. Spørg, hvor tilstanden bor.](https://tajo.io/dk/blog/mcp-or-cli-is-the-wrong-question/)

4\. nov. 2026 · 7 min læsetid

5 afsnit