Three pages carried names the 2026-07-28 specification does not use: "Multi-Round-Trip Results" for the pattern the specification titles Multi Round-Trip Requests (MRTR) and serves at basic/patterns/mrtr - the results are the `InputRequiredResult` wire type, not the feature - plus "Completions" for the utility the specification titles Completion, and "Notification Subscriptions" for the pattern it titles Subscriptions. Retitle the three pages to the specification's names, move them to /server/mrtr/ and /client/mrtr/, /server/completion/, and /server/subscriptions/ following the specification's slugs, update every internal reference, and keep the URLs published with v1.3.0 working via jekyll-redirect-from. The Discovery page keeps its title but moves from /server/discovery/ to /server/discover/, matching the specification's slug and the `server/discover` RPC, with its published URL redirected the same way.
3.3 KiB
| layout | title | nav_order |
|---|---|---|
| default | Logging | 17 |
Logging
The MCP Ruby SDK supports structured logging through the notify_log_message method, following the MCP Logging specification.
The notifications/message notification is used for structured logging between client and server.
{: .warning }
MCP Logging (
logging/setLevelandnotifications/message) is deprecated as of protocol version2026-07-28(SEP-2577), while remaining fully supported under2025-11-25. Use stderr or OpenTelemetry for new servers.
{: .note }
On the modern lifecycle, where
logging/setLeveldoes not exist, the level comes per request from theio.modelcontextprotocol/logLevel_metamember: it authorizesnotifications/messagefor that request only, delivered on the request's own response stream. A request without the member (or with an unrecognized level) receives no log messages.
Log Levels
The SDK supports 8 log levels with increasing severity:
debug- Detailed debugging informationinfo- General informational messagesnotice- Normal but significant eventswarning- Warning conditionserror- Error conditionscritical- Critical conditionsalert- Action must be taken immediatelyemergency- System is unusable
How Logging Works
- Client Configuration: The client sends a
logging/setLevelrequest to configure the minimum log level - Server Filtering: The server only sends log messages at the configured level or higher severity
- Notification Delivery: Log messages are sent as
notifications/messageto the client
For example, if the client sets the level to "error" (severity 4), the server will send messages with levels: error, critical, alert, and emergency.
For more details, see the MCP Logging specification.
Usage Example:
The client first configures the level with a logging/setLevel request:
{ "jsonrpc": "2.0", "id": 1, "method": "logging/setLevel", "params": { "level": "info" } }
The server then emits messages at each severity; only those at or above the configured level are delivered:
server = MCP::Server.new(name: "my_server")
transport = MCP::Server::Transports::StdioTransport.new(server)
server.notify_log_message(
data: { message: "Application started successfully" },
level: "info"
)
server.notify_log_message(
data: { message: "Configuration file not found, using defaults" },
level: "warning"
)
server.notify_log_message(
data: {
error: "Database connection failed",
details: { host: "localhost", port: 5432 }
},
level: "error",
logger: "DatabaseLogger" # Optional logger name
)
Key Features:
- Server has capability
loggingto send log messages - Messages are only sent if a transport is configured
- Messages are filtered based on the client's configured log level
- If the log level hasn't been set by the client, no messages will be sent
Transport Support
- stdio: Notifications are sent as JSON-RPC 2.0 messages to stdout
- Streamable HTTP: Notifications are sent as JSON-RPC 2.0 messages over HTTP with streaming (chunked transfer or SSE)