The Model Context Protocol (MCP) provides a standardized way for servers to send structured log messages to clients. Clients control logging verbosity per-request viaDocumentation Index
Fetch the complete documentation index at: https://modelcontextprotocol.io/llms.txt
Use this file to discover all available pages before exploring further.
_meta, with servers sending notifications containing severity levels, optional logger
names, and arbitrary JSON-serializable data.
User Interaction Model
Implementations are free to expose logging through any interface pattern that suits their needs—the protocol itself does not mandate any specific user interaction model.Capabilities
Servers that emit log message notifications MUST declare thelogging capability:
Log Levels
The protocol follows the standard syslog severity levels specified in RFC 5424:| Level | Description | Example Use Case |
|---|---|---|
| debug | Detailed debugging information | Function entry/exit points |
| info | General informational messages | Operation progress updates |
| notice | Normal but significant events | Configuration changes |
| warning | Warning conditions | Deprecated feature usage |
| error | Error conditions | Operation failures |
| critical | Critical conditions | System component failures |
| alert | Action must be taken immediately | Data corruption detected |
| emergency | System is unusable | Complete system failure |
Requesting Log Messages
Per-request log level
To receive log messages for a specific request, includeio.modelcontextprotocol/logLevel in the request’s _meta. The server MUST NOT
emit notifications/message for a request that does not include this field.
The server sends notifications/message notifications on the response stream at or
above the requested level before the final response.
Protocol Messages
Log Message Notifications
Servers send log messages usingnotifications/message notifications:
Error Handling
Servers SHOULD return standard JSON-RPC errors for common failure cases:- Invalid log level:
-32602(Invalid params) - Internal errors:
-32603(Internal error)
Implementation Considerations
-
Servers SHOULD:
- Rate limit log messages
- Include relevant context in data field
- Use consistent logger names
- Remove sensitive information
-
Clients MAY:
- Present log messages in the UI
- Implement log filtering/search
- Display severity visually
- Persist log messages
Security
-
Log messages MUST NOT contain:
- Credentials or secrets
- Personal identifying information
- Internal system details that could aid attacks
-
Implementations SHOULD:
- Rate limit messages
- Validate all data fields
- Control log access
- Monitor for sensitive content