How to Check MCP Server Logs: Debug, Audit, and Monitor AI Tool Calls
Two questions dominate every MCP deployment, and both are answered by logs you probably don’t have:
- “Why isn’t my MCP server working?” — Locally, MCP servers run as child processes of your AI client. When one crashes or a tool call errors, the evidence is buried in a client log file (if it exists at all). Debugging means tail-guessing.
- “What did the AI actually do?” — After an agent session touches GitHub, Slack, and a database, “it seemed fine” is not an audit answer. You need per-call records: which tool, which arguments, what came back.
This guide walks through the three log layers you get when your servers run behind MCP Trail: runtime logs (the server process itself), the audit log (every MCP call), and live monitoring (traffic over time). Setup first, then where to look for what.
Step 1: Create your free MCP Trail account and add a server
Sign up at app.mcptrail.com and add a server from the MCP Marketplace (five clicks — see the GitHub setup guide for the walkthrough). Because every request now flows through the gateway, logging is automatic — nothing to instrument.
Step 2: Runtime logs — is the server process healthy?
Open your server under Guardian servers and view its runtime logs: the stdout/stderr of the actual MCP server process, live-streaming, with persistent history back to the first boot — so the stack trace from Tuesday’s crash is still there on Friday. Use Load earlier to page back through rotated history.
This is where startup failures live: missing environment variables, bad credentials, a package that won’t boot. If a server crashed, there’s a restart from error action right next to the log.
Step 3: The audit log — what did the AI call?
Sidebar → Audit log. Every MCP request across all your servers is recorded: session, method (tools/call, tools/list, …), tool name, scrubbed arguments, result status, timing, and a correlation ID. Switch between line, table, and graph views; filter by server, method, or status.
Typical debugging reads:
- Tool call failing? Find the call, read the exact arguments the model sent — most “broken server” reports are actually malformed arguments
- Agent behaving oddly? Read the call sequence for its session; the story is usually obvious in order
- Compliance ask? Filter by server and date range, export the evidence
Step 4: Inspect a single call in detail
Click any row to expand the full record — argument payloads (scrubbed of detected secrets), the response preview, and what the policy layer did (DLP matches, approval outcomes, rate-limit hits). A JSON diff view shows when the gateway transformed a response, so you can see exactly what the model received versus what the upstream returned.
Step 5: Live monitoring — traffic over time
Each server has a Monitoring view: request volume, errors, and latency charted over the last hour, day, week, or month, flowing from history into live data — plus a per-tool breakdown showing which tools do the heavy lifting. This is where you spot the slow drift (an agent retry-looping at 2am) that individual log lines won’t show you.
Step 6: Verify the loop end to end
Make one tool call from your client (or the built-in playground), then find it: runtime log shows the server handling it, audit log shows the call record, monitoring shows the tick in the chart. Once you’ve traced one call through all three layers, you know where to look when something real breaks.
What about local MCP server logs?
If you’re staying local: Claude Desktop writes MCP logs under ~/Library/Logs/Claude/mcp*.log (macOS), and most servers print to stderr, which clients capture inconsistently. It’s workable for one developer and one server. The reason teams centralize is that local logs answer “did my process crash?” but never “what did the AI do across all our servers last week?” — that requires the gateway vantage point.
FAQ
Do MCP servers keep logs by default?
Mostly no — a typical stdio server prints to stderr and keeps nothing. Persistent history has to be provided by whatever runs the server.
Are sensitive values visible in the audit log?
Detected secrets are scrubbed and DLP matches are recorded by rule class, not raw content. You get the evidence without creating a new secret store to protect.
How far back does the history go?
Runtime logs persist from the server’s first boot, with rotation; the audit log retains per-call records queryable by server and date range.
Can I get alerted instead of checking dashboards?
Yes — approval requests and threshold alerts can notify via Slack and email, and the Threat Center surfaces anomalous patterns proactively.
Related Articles
- MCP Audit Logging: The Complete Guide
- MCP Token Tracking and Observability
- How to Protect Sensitive Data When Using MCP Servers
- How to Set Up the GitHub MCP Server
- Securing MCP with RBAC and Audit Logs
Stop debugging blind. Create your free MCP Trail account and get runtime logs, audit trails, and live monitoring on your first server in minutes.