What Should an MCP Server Log So You Can Tell a Model Error From a Product Error?

TL;DR: An MCP server should log every tool invocation as a structured event: who or what called it, which agent and session, which tool, what arguments it received, what it returned or how it failed, and how long it took. Guidance read for this post on 2026-10-25, labelled here as vendor and security guidance, points the same way: the OWASP MCP Top 10 lists insufficient logging as a named risk, and MCP security checklists recommend logging every tool invocation with agent ID, tool name, arguments, and result, in append-only or tamper-evident storage. The operational payoff is classification. If each failure is tagged by origin, model error, client error, or product error, debugging is a query. If it is not, debugging is a debate.

Key Takeaways

• Log the invocation, not just the error. A log that only records failures cannot show what a successful but wrong call looked like.
• The minimum useful record is agent ID, session or request ID, tool name, arguments, result or error, timestamp, and duration, per the security guidance cited in this post.
• Separate model errors from product errors at write time, with an explicit error origin field, not later from memory.
• Keep logs append-only or tamper-evident, and treat arguments as sensitive data, because tool arguments routinely contain personal and commercial information.
• No adoption statistics are claimed here. The sources for the recommendations are the OWASP MCP Top 10 and MCP security checklists, read 2026-10-25 and labelled as vendor and security guidance.

Why does this distinction matter so much for MCP?

Your product can also fail in ordinary ways at the same moment: a validation rule rejects a legitimate value, an underlying service times out, a permission check is wrong, a schema and its implementation disagree. When a user reports that the agent did something wrong, both families of cause are live suspects. This is the practical version of the question in what actually changes when an agent calls your product through MCP instead of your API: the caller changed, so the evidence you need changed with it.

What does the security guidance actually say?

Two sources frame this post, both read 2026-10-25 and both labelled here as vendor and security guidance rather than independent measurement.

The OWASP MCP Top 10 lists insufficient logging among its named MCP risks. The significance of that listing is not a statistic; it is a classification. Logging is treated as a security control for MCP servers, not merely as a debugging convenience, because an agent that can act through tools can also be manipulated into acting, and an operator with no record cannot tell manipulation from malfunction.

MCP security checklists read alongside it recommend a concrete logging practice: log every tool invocation, and include the agent ID, the tool name, the arguments, and the result. They also recommend append-only or tamper-evident storage, so the record cannot be quietly edited after an incident, and they recommend separating model errors from product errors so that reliability work lands on the right team.

Those recommendations are the spine of this post. Where the sections below go beyond them, into field lists and retention practice, that is operational argument from the author, not a claim about what any study measured.

What belongs in one log line?

Treat each tool call as one structured event, written whether it succeeded or failed.

Start with identity and correlation: a timestamp, a request ID unique to the invocation, a session or conversation ID where the client supplies one, the agent or client identity, and the authenticated principal the call ran as. Identity matters because the same tool called by two different agents with two different permission scopes is two different risk stories.

Then the call itself: the tool name and version where you track one, and the arguments as received, before any server side transformation. Record arguments as received because a common failure is a mismatch between what the model sent and what your code assumed it sent. If you only log your normalised version, you have deleted the evidence.

Then the outcome: success or failure, the result size or a redacted result summary, a structured error code, an error origin tag, and duration. Duration separates slow product behaviour from instant rejections, which look identical in a user report that just says it failed.

How do you separate a model error from a product error?

Define the taxonomy before you need it, and assign the tag where the failure is detected, in code, not in a postmortem.

A model error means the request itself was wrong for a correctly working product: an unknown tool name, an argument of the wrong type, a value outside an enumerated set, a well formed call to the wrong tool for the stated task, or a retry that ignores an idempotency key the server returned. These errors point at descriptions, schemas, and examples. The fix lives in your tool design as often as in the model, which is why the tag should start a design review rather than end one.

A product error means the request was valid and the product failed it: a downstream timeout, a database error, a permission check that misclassified a legitimate principal, a result that contradicts your own API, or a schema that promises a field the implementation never returns. These point at the service behind the tool.

The design rule from how to build an MCP server for your SaaS helps here: return tool failures in a form the model can act on, with a clear statement of what was rejected and what a valid call looks like. A good error message and a good log line are the same information aimed at two readers, the model now and your team later.

What should you not log, or not keep carelessly?

Arguments are the problem. Tool arguments will contain names, email addresses, message drafts, search queries, and occasionally secrets that a user pasted into a conversation. A complete log is therefore a sensitive data store, and it needs the handling that implies: access control, retention limits, and redaction rules for known secret shaped fields.

Storage integrity matters for the same reason the checklists recommend append-only or tamper-evident logs. If an agent can be manipulated through a tool, the log is the record of that manipulation. A log the agent itself can edit, or that an attacker who reaches the server can rewrite, fails at the moment it is most needed. Ship logs to a system the MCP server can write to but not modify.

How do you know the logging is good enough?

Test it with questions, not with volume. Can you, from logs alone, reconstruct the last failed task: which tools were called, in what order, with what arguments, and where the first wrong step occurred? Can you count model errors and product errors for one tool over a chosen period without reading individual lines by hand? Can you show a customer exactly what an agent did under their account, and nothing from anyone else's?

If the answer to any of those is no, the gap names the next logging fix. The comparison in how many MCP servers ask before they act covers the gate before a call. Logging is the counterpart after a call: the record that makes the gate, the error taxonomy, and the incident review real instead of remembered.

An MCP server without invocation logs is asking its operators to trust summaries written by the system being investigated. Log the call, tag the failure by origin, protect the record, and most arguments about whose fault an agent incident was simply end.