How Do You Log the Tool Calls an MCP Agent Makes in Production?

How do you know what an AI agent actually did in your CRM?

Only if you log it. When an agent uses an MCP server to read or change records in your CRM, CMS, or database, each tool call is an action someone may need to explain later. A tool-call log records who asked, which tool ran, with what inputs, what changed, and whether it worked.

Agents connected through the Model Context Protocol are moving from demos into real marketing and sales work. They update contact properties, draft and publish CMS items, pull reports, and enrich records. That is useful. It also means software that reasons in natural language is now taking actions in systems your revenue depends on.

When something looks wrong, the first question is always the same: what did the agent do, and why? Without a log, the honest answer is "nobody knows." This article is how I set up tool-call logging for MCP agents that run in production, based on how I approach monitoring for any automation that touches revenue data.

What is a tool call in MCP, and why does it need logging?

A tool call is a single action an AI agent asks an MCP server to perform, such as searching contacts, updating a deal, or creating a CMS item. The agent decides which tool to call and with what inputs. Logging each call creates an audit trail that shows exactly what the agent did and in what order.

Traditional automations are predictable. A Zapier or Make workflow runs the same steps each time, so you can read the workflow and know what it will do. An agent is different. It chooses its steps at run time based on a prompt and the data it sees. Two runs with similar requests can take different paths.

That flexibility is the point of using an agent, and it is also why logging matters more. You cannot read the workflow ahead of time to know what will happen. You can only read what did happen. The log is your workflow diagram, written after the fact.

Logs also protect the people involved. If a rep asks why a deal stage changed, the log answers it in seconds. If a client asks whether an agent touched a record, you can say yes or no with evidence instead of a guess.

What does the MCP specification say about logging?

The MCP specification includes a logging feature where servers send structured log messages to clients, with severity levels based on the syslog standard. Its security guidance says log messages must not contain credentials or secrets, personal identifying information, or internal system details that could aid attacks. That guidance shapes what I record.

The spec lists eight levels, from debug and info up through warning, error, critical, alert, and emergency. Clients can set a minimum level with a request, and servers then send only messages at or above that level. Servers that emit these log notifications must declare a logging capability.

The spec also recommends that servers rate limit log messages, include relevant context, use consistent logger names, and remove sensitive information. On the client side, it says clients may show logs in the interface, filter and search them, and persist them.

Protocol-level logging is useful, but I treat it as one input, not the whole system. For production work, I also want my own durable record of every tool call, stored somewhere I control, in a format my clients and I can search. The spec's security rules apply to that record too.

What should each tool-call log entry include?

Each entry should record when the call happened, which agent or session made it, the user or trigger behind the request, the tool name, a safe summary of the inputs, the target record, the result or error, and a link back to the conversation or run. That is enough to reconstruct any action later.

The record ID matters most. If an agent updated a contact, the log should hold the CRM's ID for that contact, not just a name. Names repeat and change. IDs let you jump straight to the record and check its history in the CRM itself.

For changes, I log the before and after values of the fields that changed, where it is safe to do so. "Lifecycle stage changed from lead to opportunity" is far more useful than "contact updated." It also makes rollback possible, because you know what the old value was.

I keep a short "reason" field when the agent provides one. Agents often explain their next step in plain language. Capturing a one-line reason next to each write action helps a human understand why the agent thought the change made sense, which is often where the real bug hides.

What should you leave out of the logs?

Leave out credentials, API keys, tokens, and any personal information you do not strictly need. The MCP spec's security section says log messages must not contain credentials, secrets, or personal identifying information. For marketing and sales data, that usually means logging record IDs and changed field names instead of full contact details.

This is a real tension. The more you log, the easier debugging gets. But logs often end up in tools with broader access than your CRM, like a shared spreadsheet, a chat channel, or a logging service. A log full of names, emails, and phone numbers becomes a second copy of your customer data, with weaker protection.

My rule is simple. Log the ID, the field name, and a safe description of the change. If someone needs the actual values, they open the record in the CRM, where access controls already apply. The log points to the data. It does not duplicate it.

Be careful with prompts too. The user's request to the agent can include pasted customer details. If you log prompts, store them with the same care as customer data, or log a short summary instead of the full text.

Where should MCP tool-call logs be stored?

Store them somewhere durable, searchable, and access-controlled, separate from the agent itself. For a small team, an append-only table in a database or an Airtable base with restricted access works. Larger teams often use a proper logging service. What matters is that logs survive restarts and cannot be quietly edited.

Do not rely on the chat transcript alone. Transcripts are useful context, but they are often tied to a user account, can be deleted, and are hard to search across many runs. A separate log gives you one place to answer "what touched this record" across every agent and every user.

Keep write logs longer than read logs. Reads matter less for audits, and logging every read can produce huge volume. I log all writes in full, and sample or summarize reads unless a specific investigation needs more.

Give access to the people who need it: the automation owner, the RevOps lead, and whoever answers questions about data changes. Keep it away from everyone else, for the same reasons you limit CRM admin rights.

How do you turn logs into alerts?

Pick a few patterns that should never happen quietly and alert on them: a burst of writes in a short window, writes to fields the agent should not touch, repeated errors from one tool, or any delete action. Alerts turn a passive log into a safety system that catches problems while they are still small.

Volume alerts catch runaway loops. If an agent normally updates a handful of records per run and suddenly updates hundreds, something is wrong. A simple threshold, reviewed and adjusted after the first few weeks, catches most of these cases.

Field-level alerts catch scope creep. Decide in advance which fields an agent may write. If it writes to anything else, alert immediately. I wrote about whether an MCP server should get write access to your CRM, and the logging and alerting setup is what makes limited write access safe in practice.

Pair alerts with a way to stop the agent. An alert that says "the agent is misbehaving" is only half useful if nobody can pause it quickly. A documented off switch, owned by a named person, is part of the same system.

How do you review the logs without drowning in them?

Review a small sample of write actions each week, every alert as it fires, and a monthly summary of totals by tool and by agent. Look for actions that surprise you. A surprising action is either a bug, a gap in your instructions, or a new use case you should support on purpose.

Weekly sampling is the habit that matters most. Pick a handful of recent write actions and check them against the CRM. Was the change correct? Was it the change a person would have made? This takes minutes and builds trust in the system, or warns you early that trust is not yet earned.

Monthly summaries show trends. Which tools are used most? Which produce the most errors? Which users rely on the agent heavily? That tells you where to invest in better instructions, tighter permissions, or human review.

Before connecting any new server, run through a checklist. I covered what to check before connecting an MCP server to marketing tools, and logging belongs on that list from day one, not after the first incident.

What should you do next?

List every MCP server your agents can reach and mark which tools write data. Set up a durable, access-controlled log that records the tool, record ID, changed fields, result, and requester for every write. Strip credentials and personal data. Add alerts for bursts, unexpected fields, and deletes, then review a sample every week.

Start with the server that touches revenue data, usually your CRM. Once that log is working and trusted, extend the same pattern to your CMS, analytics, and enrichment tools.

I have built production automations for teams like Ajust, with Airtable and WhaleSync, and Kismet Health, with HubSpot through Zapier. Agents raise the stakes because they choose their own steps, but the rule is the same one I apply everywhere: if it can change revenue data, it must leave a trail.

If you are connecting AI agents to your CRM or CMS and want help designing the logging, permissions, and alerts around them, reach out. Let's chat about what your agents should be allowed to do and how you will know what they did.