CLI --log-level rejects valid MCP log levels and accepts invalid ones (spec mismatch)

[ayaangazali]

Inspector Version

1.0.0 (repo HEAD, commit ac3c1a1)

Affected client

CLI (--cli mode). Web UI is not affected (it imports the SDK schema directly).

Describe the bug

The CLI --log-level flag validates against a hardcoded list that does not match the MCP spec logging levels, so it rejects valid levels and accepts invalid ones.

cli/src/client/connection.ts:5-11 defines:

export const validLogLevels = ["trace", "debug", "info", "warn", "error"] as const;

The MCP spec / SDK LoggingLevelSchema (RFC 5424 syslog levels) is:

["debug", "info", "notice", "warning", "error", "critical", "alert", "emergency"]

So the CLI:

• rejects the spec-valid levels notice, warning, critical, alert, emergency
• accepts trace and warn, which are not valid MCP levels, and forwards them to the server via logging/setLevel

The validator that enforces this is at cli/src/index.ts:307-318.

To Reproduce

# spec-valid level, gets wrongly rejected before any request is sent:
mcp-inspector --cli <server> --method logging/setLevel --log-level warning
# -> "Invalid log level: warning. Valid levels are: trace, debug, info, warn, error"  (exit 1)

# non-spec level, wrongly accepted (passes validation, proceeds to connect):
mcp-inspector --cli <server> --method logging/setLevel --log-level warn

Reproduced against HEAD (built CLI). Only debug, info, and error overlap between the CLI list and the spec, so those are the only levels that both pass validation and are actually valid.

Expected behavior

--log-level should accept exactly the MCP spec levels: debug, info, notice, warning, error, critical, alert, emergency, and reject anything else (including trace and warn).

Actual behavior

Valid levels notice/warning/critical/alert/emergency are rejected; invalid trace/warn are accepted and sent to the server.

Suggested fix

Derive the list from the SDK instead of hardcoding, so it can never drift from the spec:

import { LoggingLevelSchema } from "@modelcontextprotocol/sdk/types.js";
export const validLogLevels = LoggingLevelSchema.options;
export type LogLevel = (typeof validLogLevels)[number];

The validator at cli/src/index.ts:307-318 stays as-is; it just validates against the correct set. The web client already uses LoggingLevelSchema directly (client/src/components/Sidebar.tsx), so this also aligns CLI and Web on one source of truth.

Version Consideration

This is an MCP spec-compliance bug in V1 CLI, so it fits the current V1 scope. Suggesting the v1 label (targets main).

---

apologies if I got any detail wrong here. I reproduced this locally against HEAD and talked through the logic with Claude Code to double-check the spec levels, but I am a freshman still learning, so happy to be corrected. just trying to help out where I can :)

[manjunathbhaskar]

Confirmed — here is the root cause and a one-file fix.

Root cause

cli/src/client/connection.ts defines:

export const validLogLevels = ["trace", "debug", "info", "warn", "error"] as const;

The MCP spec uses RFC 5424 syslog levels. The SDK's LoggingLevelSchema (in @modelcontextprotocol/sdk) is:

"debug" | "info" | "notice" | "warning" | "error" | "critical" | "alert" | "emergency"

So the hardcoded list:

• Rejects 6 spec-valid levels: notice, warning, critical, alert, emergency
• Accepts 2 non-spec levels: trace, warn

Fix

Replace the hardcoded array with the SDK's own schema so the CLI can never diverge from the spec again:

import { LoggingLevelSchema } from "@modelcontextprotocol/sdk/types.js";

export const validLogLevels = LoggingLevelSchema.options;
export type LogLevel = (typeof validLogLevels)[number];

If importing from the SDK feels too tight a coupling, a direct fix is:

export const validLogLevels = [
  "debug", "info", "notice", "warning", "error", "critical", "alert", "emergency"
] as const;

Happy to open a PR for either approach — whichever the maintainers prefer.