Logging and auditing MCP tool calls means recording who made the call, what parameters they used, what the tool returned, and what policy decision applied, for every single call, not a sample of them. This matters more for AI systems than for conventional software because the path from user request to tool call isn't fixed in code you can read afterward. A model decides which tool to call and how, based on a conversation that can include manipulated context, and without a record of that decision and its outcome, investigating anything that went wrong turns into guesswork about what the model probably did rather than a factual reconstruction of what it actually did.
Record identity on every call, not just success or failure
Every logged tool call needs to tie back to a specific requesting identity, a user, tenant, or agent, not just a generic "system" label. Without that, a log full of tool calls tells you what happened but not who it happened for, which makes it far less useful the moment you need to investigate a specific user's activity or a specific tenant's data exposure.
Capture the actual parameters and the actual result
Logging that a tool was called without logging what it was called with, or what it returned, misses the two pieces of information most likely to matter during an investigation. Record both, understanding that this means your logs will sometimes contain sensitive data, which brings its own protection requirements.
Log policy decisions alongside the raw call
If a call was denied, or allowed only after a modification, or flagged by some rule, record that decision and the reason for it next to the call itself. A raw list of executed tool calls tells you what happened. A record of policy decisions tells you what almost happened and why it didn't, which is often more useful for understanding whether your controls are actually working.
Protect logs with the same rigor as the systems they describe
An audit trail of tool calls will often contain the same sensitive data the tools themselves handle, records, messages, file contents passed through as parameters or results. Treat access to these logs as its own sensitive system, with its own access controls and retention policy, rather than assuming logging infrastructure is automatically safe just because it's "just logs."
Set a retention policy deliberately, not by default
Keep logs long enough to support a real investigation, typically well beyond the length of a single session, but not indefinitely without a reason, since unbounded retention of sensitive tool call data becomes its own liability. Decide this deliberately rather than letting whatever a logging tool defaults to become the policy by accident.
Correlate tool call logs with other security telemetry
A tool call log that lives entirely on its own, disconnected from authentication logs, network telemetry, and application-level events, forces an investigator to manually stitch together a timeline from multiple disconnected sources. Where possible, correlate tool call records with the broader security monitoring your organization already runs, using a shared identity or session reference, so a suspicious tool call can be quickly placed in the context of everything else happening around it, rather than reviewed in isolation.
Make logs useful to more than just security
A log designed only for a security investigation tends to get ignored the rest of the time, which means problems with its completeness or accuracy go unnoticed until the one moment it actually matters. Structure tool call logs so they're also useful for debugging, performance review, and product analytics day to day, and the log ends up genuinely maintained by people with a regular reason to look at it, rather than a write-only archive nobody checks until an incident forces them to.
Where TELEON fits
TELEON records an audit trail of tool call activity, including identity, parameters, results, and policy decisions, for calls that pass through the gateway, giving teams a consistent, centralized record across MCP servers that might otherwise log inconsistently or not at all.
Deciding what counts as sensitive within that log data, and setting a retention policy that matches your organization's actual regulatory and operational needs, remains a decision each team has to make based on its own data and obligations.
A short checklist
- Log every tool call, not a sample, tied to a specific requesting identity.
- Capture both the parameters sent and the result returned.
- Record policy decisions, including denials, alongside the underlying call.
- Protect tool call logs with access controls matching the sensitivity of the data they contain.
- Set a deliberate retention policy rather than accepting a default.
- Monitor logs for patterns, not just individual calls, since sequences reveal risk single calls don't.
- Test that your logging actually captures enough detail to reconstruct a real incident.
The value of an audit trail is almost entirely invisible until the day you actually need it, which is exactly why it's the control most likely to get shortchanged during a rushed integration. By the time an incident happens, it's too late to go back and start logging what you should have been logging all along.