MCP Server Logging – Why You Need It and How To Get It
MCP server logging is a foundational component of using MCP servers in businesses and other organizations. Developers experimenting with MCP servers can get by with built-in “syslogs”, but using MCP servers at scale requires logs that:
- Capture metadata that is essential for auditing and observability
- Link event chains across different servers
- Group, aggregate, and link events by various criteria
- Capture custom events, including security-related events
- Are reliably and consistently generated
- Are stored, organized, and can be retrieved at any time by authorized users
Generating logs with these characteristics empowers admin users and security teams to conduct audits, observe the health, performance, and security of their MCP ecosystem, and respond to any security or performance issues more efficiently and successfully.
In this blog, I’ll explain what MCP server logs are, what they should and shouldn’t include, and how you can implement them, with some best practices you should follow.
After reading, you’ll be able to add robust MCP logging to your MCP ecosystem, which is the first step to using MCP servers securely and scalably.
What are MCP server logs?
Strictly speaking “MCP server logs” or “MCP server logging” refers to the events an MCP (model context protocol) server captures and records as structured json files, such as:
- Requests from clients
- Responses to clients
- Errors
- Tool usage patterns (an MCP server is an interface that enables LLMs and AI agents to use apps and databases – which are called “Tools” or “Features”)
Example of an MCP server log entry:
{
“timestamp”: “2025-07-01T14:32:18.234Z”,
“method”: “tools/call”,
“params”: { “name”: “getUserInfo”, “arguments”: { “user_id”: “12345” } },
“id”: “req-8723”,
“response_time_ms”: 212,
“result”: { “name”: “John Doe”, “email”: “john.doe@example.com” }
}
However, when people say “MCP logs” or “MCP server logs,” they’re often referring to logs that encompass the entire MCP interaction flow, including the communication between MCP clients and MCP servers.
This cohesive and comprehensive level of logging, which incorporates events from both the client and server sides, is not possible without manual reconciliation of client and server logs, or the use of an MCP proxy or gateway.
Do MCP servers and clients have built in logging mechanisms?
Yes, MCP servers and clients have built-in foundational logging mechanisms that capture communications and transmissions in raw JSON files, which are only accessible during that specific session (or current runtime).
You can use these built-in, standard logs (also known as syslogs) if you are an MCP client/server developer or a technically savvy end user to troubleshoot issues with your clients and servers and ensure that MCP communication, authorization flows, and other traffic are functioning as intended.
However, these built-in logs do not connect events from or between the client and server, making them unsuitable for end-to-end traceability.
These built-in logs don’t link concurrent chains of events that span multiple servers, which means a chained task that uses multiple servers does not create a corresponding log that links these chained events together. This creates a risky and frustrating auditing and observability blind spot.
The section below provides a detailed breakdown of the limitations of the built-in MCP server and client logs.
What are the limitations of built in MCP server/client logs?
Built-in MCP server and client logs are fine for basic developer-level troubleshooting during a live session, but they aren’t suitable for end-to-end traceability or observability for business use. Below are the key limitations of built-in MCP server/client logs.
- Limited Detail: Built-in logs in MCP servers and clients only offer a foundational level of logging that includes basic details of key events, including:
- Connection and authentication
- Handling of requests and responses
- System resources and errors
- No Traceability: Logs generated by MCP servers and clients are limited to their own instance and are session-specific. Events are not tagged with a “correlation ID”, “Trace ID,” or equivalent, to connect linked events that were part of the same action but occurred across multiple servers.
- No Aggregation: Logs generated by MCP servers and clients are limited to their specific session and instance; there is no centralized place to collect and aggregate logs across multiple servers, never mind correlate, link, and aggregate logged events from servers and clients. Achieving aggregation requires a third-party logging tool or the use of a proxy or gateway.
- Limited to JSON: Logs are delivered as JSON-RPC messages, which is ideal for structure and parsing, but not suitable for investigating or debugging at scale, or for export/integration with SIEM (security information and event management) systems.
- Lacks Security Event Capture: Using MCP servers introduces a vast new attack surface, making logging security-related events paramount. MCP servers do not recognize or capture these events (such as sensitive command execution or retrieval of sensitive data), making both the logging and blocking of security-related events impossible.
- No Custom Event Capture: As with security events, there will be a range of custom events that your organization will want to capture, for example, when the number of requests from a single client in a specific timeframe hits a “high request” threshold. Capturing custom events like this is not possible in the out-of-the-box MCP server logs.
- No Custom Metadata: Using the built-in MCP server and client logs limits you to the metadata that their developers have configured them to capture, which means they may not capture some of the metadata that you feel is important.
- Unfocused and Noisy: Without filters (and datapoints/criteria to filter by) logs can quickly become noisy, overly verbose, and unfocused, making them harder to interrogate, particularly at scale.
Without an additional logging solution, such as an MCP gateway, proxy, or another enhanced observability setup, MCP server and client logs will be disconnected from each other, making it difficult, if not impossible, to get a full picture of the full MCP client-server flow.
In addition, both the client and server’s logs will typically be basic, developer-dependent, and unsuitable for comprehensive, scalable logging that supports the security and performance observability requirements of even small organizations.
What solutions are available for improved MCP server-client logging?
If you need logs that you can retrieve when you need them, use in audits, and scale up to multi-user or even enterprise-level use, then here are your options:
- Manual reconciliation/correlation
- Use an MCP proxy
- Use an MCP gateway
Manual Reconciliation/Correlation
It is possible, but not advisable, to manually combine the separate logs from your MCP servers and clients to gain a fuller understanding of the entire MCP flow.
This is a passable option if you are using MCP clients and servers for personal use and have a lot of free time and patience, but it is not scalable. You will need to use an MCP gateway or a specialist observability platform to generate logs that provide end-to-end traceability and comprehensive, aggregatable logs suitable for auditing and enterprise-level use.
MCP Proxy
MCP proxies allow you to connect all your MCP servers via a single node. At its most basic, this facilitates multi-step (and multi-server) workflows and chained tool calls. As an MCP proxy connects your hosts, clients, and servers, it also captures and controls all communication sent in any direction.
This intermediary position means an MCP proxy can generate comprehensive logs that incorporate all communication and transactions between MCP servers and clients.
MCP proxies vary in their features, and many do not have logging functionality out of the box, so it’s important to check out the functionality of any MCP proxy before assuming it will give you the level of logging you need.
You can also use MCP gateways like MCP Manager to achieve more robust and comprehensive logging. MCP gateways like MCP Manager combine a proxy to inspect, filter, and log tool calls in real-time, along with a gateway layer.
The gateway layer empowers you to control access across multiple dimensions (including servers, tools, agents, and users), set policies, and authorize and authenticate access.
MCP Gateways
Like a proxy, an MCP gateway sits between your organization’s MCP clients and servers, mediating, securing, improving, and logging all of the communications and transactions between client and server.
This means the MCP gateway securely processes and records all communications between your organization’s MCP clients and servers.
An MCP gateway includes an MCP proxy, but also offers a range of other features for managing and improving the functioning of your MCP ecosystem.
The primary role of an MCP gateway is to provide essential security protections against misuse and the vast attack surface that MCP servers introduce. However, they are also the best way to create logs for your MCP client and server interactions.
The gateway manages session-level context and adds a Correlation ID/Trace ID to link those events that are part of the same event chain and span across different servers and sessions, giving you end-to-end traceability for auditing purposes.
You can also configure gateways to capture custom events. For example, if a server attempts to return a response that violates a security policy the gateway enforces, it can log a custom security event.
What are the main benefits of using an MCP gateway to generate your logs?
- End-to-End Tracability: The gateway tags every event with a Correlation ID or Trace ID. Events that are part of the same request-response chain have the same Correlation ID even when they include multiple tools and servers.
- Centralized Logging and Monitoring: Generate logs that incorporate data from all relevant sources, including all MCP servers and tools, clients, and supplemental connected systems, to give you the full picture when auditing and monitoring.
- Custom Event Tracking & Logging: Define and log custom events specific to your organization’s needs, which would otherwise be untrackable with standard server/client logs.
- Security Event Tracking: Log security-related events (such as policy violations/enforcements, prompt sanitizations, and unauthorized access attempts) to allow for robust security audits, improved responses, and stronger security measures.
- Exports/Integrations: MCP gateways can transform logs into exportable CSV files and integrate with SIEM (Security Information and Event Management) systems
- Real-Time Observability: Use logged data to generate real-time reports and dashboards for security and performance monitoring, either within the gateway itself or via an integrated observability tool.
What metadata should MCP logs include?
The list below provides the core metadata (columns) that you should capture in your logs, along with recommended formats. If using technical logs for auditing is new to you, you can also use this list as a quick reference to understand what each data point represents.
The list below doesn’t represent the totality of all the data you should capture, but any logging function you configure should include these datapoints at a minimum.
- Timestamp: When the event occurred in ISO format.
- Log Level: What is the nature/severity of the item logged. Common log levels are: TRACE, DEBUG, INFO, WARN, ERROR, FATAL)
- Response Code: The response code returned by the server, such as 200, 401, 500 etc. This is useful when debugging, to exclude successful requests and filter down to specific errors.
- Response Type: The format or kind of response sent (e.g., JSON, XML, HTML, or a domain-specific response type).
- Headers: JSON representation of the HTTP response headers/header fields that were returned by the server
- Event Type: Text descriptor of the event, for example “mcp-response-success”.
- User/Team/Organization IDs: GUIDs/UUIDs to identify the user that initiated the logged event. Team and organizational IDs are optional but helpful when logging MCP servers at scale.
- Tool/Feature ID: Unique identifier for the tool/feature invoked
- Correlation ID: Unique identifier that is used to trace requests and transactions across multiple tools and servers.
- Request ID: Useful to categorize request types to identify patterns when troubleshooting.
- Session ID: Unique identifier that enables you to link and group events that occurred in the same session.
- Methods/Commands: What call/invocation was being made in this event (such as getting the list of tools or initializing the connection)
- IP Address: The IP of the user that initiated the event
Information that should not be included in MCP logs:
While your logs should be comprehensive, they shouldn’t risk compromising any sensitive data.
Organizations should secure logs behind some form of secure login and password to prevent deliberate or accidental tampering. However, even with those access controls, they still should never include data such as:
- Credentials
- Secrets
- API keys
- Environment variables
- PII (personal identifying information)
MCP Server Inventory Logs
In addition to generating detailed logs of all communications between your MCP clients and servers via a proxy or gateway, you should also maintain a higher-level record of the servers themselves, such as an inventory of your servers.
This server database should include key information such as:
- Date the server was added
- Date the server was removed
- Who added the server
- If the server was subject to a review and approval process (if applicable)
- Approval status (if applicable)
- Approval notes (if applicable)
- Reason rejected (if applicable)
If you are using a gateway or proxy you should also be able to record:
- Errors logged against the server (counts, timestamps, and details)
- Quarantined/sanitized prompts (counts, timestamps, and details)
- Tool/feature count for this server
- Tools served by this server (with version details)
- Last used
- Last used by (username, user ID, and team ID if used)
MCP Logging Best Practices
Below are some best practices you should follow when implementing MCP logging in your organization. If you are using an MCP gateway, it should take care of these best practices for you.
- Use a standardized, structured log format like OpenTelemetry
- Control access to logs – behind some form of login/password protection
- Monitor for sensitive content and exclude/sanitize/mask all sensitive data from logs where possible (especially in headers).
- Enable logs to be structured and exported as CSV files, for easier investigation and aggregation, and for importing into Security Information and Event Management (SIEM) systems. Alternatively, use a log drain platform like Splunk to aggregate your logs and make them searchable.
- Consider using asynchronous logging mechanisms, batch processing, and log buffering to reduce overhead.
- Consider using libraries like Pinot Logging to implement most of these best practices.
- Ensure any middleware (such as an MCP gateway) preserves header content, particularly, but don’t forget to sanitize sensitive headers like “authorization”.
In Summary: Generating Enterprise-Level MCP Logs Needs a Little Extra
Robust, detailed, end-to-end logging for your MCP servers and wider MCP ecosystem is essential to using MCP servers in any business or organization.
Your logs should include as much metadata as possible, excluding any sensitive data, and should include a range of identifiers (such as server and correlation IDs) to help aggregate and track chained events by user, session, server, action, and other relevant criteria.
Having robust logs at hand gives you the ability to observe the health and security of your MCP ecosystem and respond more quickly and successfully to any performance or security issues.
This robust level of MCP logging is not possible without a gateway, proxy, or other intermediary layer between your MCP client and server.
The good news is that the benefits of using an MCP gateway aren’t limited to enterprise-level logging. An MCP gateway addresses all the challenges of using MCP servers within businesses and other organizations, including security risks, identity management, authorization, and more.
MCP Manager equips you with detailed, comprehensive logs of all MCP interactions in your organization. Learn more and get access to MCP Manager today, to provide your organization with the controls and guardrails it needs to adopt MCP servers securely and successfully.
