Uses notifications/message for logging, not console.log
Why it matters
MCP defines a structured logging protocol via notifications/message with severity levels (debug, info, warning, error, etc.) that clients can display, filter, and route to observability systems. A server that only uses console.error keeps all operational visibility on stderr — invisible to the connected AI client and to any MCP-aware monitoring tool. When a server-side failure occurs during an agentic run, the client has no programmatic signal to surface the failure; the AI sees only the missing tool result with no explanation.
Severity rationale
Low because the absence of MCP-native logging reduces observability without causing data loss or security failures — clients still function, but operational diagnosis is harder.
Remediation
Use server.sendLoggingMessage() for events the client should see. Keep console.error for local debugging only.
// src/utils/logger.ts — MCP-native logging
import { server } from '../index.js' // your McpServer instance
export function log(level: 'info' | 'warning' | 'error', message: string) {
server.sendLoggingMessage({ level, logger: 'my-server', data: message })
}
// In tool handlers:
log('info', 'Connected to database successfully')
log('error', `Failed to connect: ${error.message}`) // client sees this
Declare logging: {} in your server capabilities so clients know to expect log messages.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the MCP Server Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- external · mcp-spec-logging — MCP Specification — Logging via notifications/message
Taxons
History
- 2026-04-18·v1.0.0·Initial import from mcp-server·automated