Files

T

retoor 251c3dc2ba research: mcp-client-support subject (106 sources, 3 conclusions)

- wire spec: lifecycle, stdio + Streamable HTTP transports, tools,
  utilities, legacy SSE, versioning, changelog (14 Tier 1)
- client ecosystem: Claude Code/VS Code/Cursor/Codex configs,
  mcp-remote, Smithery, registries, Glama (12 Tier 1)
- security/ops: authorization draft, trust model, poisoning,
  rug pulls, production hardening (12 Tier 1) + 68 Tier 2 cards
- conclusions: minimal stdlib client on 2025-11-25, normalizer +
  resolver agent for pasted configs/GitHub URLs, untrusted-until-
  consent trust model; nothing built yet
- audit PASS (14 subjects, 797 sources, 32 conclusions)

2026-10-18 19:23:02 +02:00

2.9 KiB

Raw Blame History

Logging (server utility, 2025-11-25)

Metadata

Field	Value
Institute	Molodetz Institute - Research & Retrieval Division
Subject	mcp-client-support
Document type	Source Dossier
Tier	1
Source title	Logging utility (MCP Specification v2025-11-25)
Source URL	https://modelcontextprotocol.io/specification/2025-11-25/server/utilities/logging
Source publisher / author	Model Context Protocol authors (Anthropic-donated open project; site docs)
Source type	standard
Source date (published)	2025-11-25 (version stamp; no other publish date stated)
Date researched	2026-10-18
Researched by	tai (agent), model: Claude Sonnet 5, on behalf of retoor
Research method	gather-subagent direct page fetch, parent synthesis from evidence pack
Confidence	High
Status	Active

Summary

Servers that emit log notifications must declare the logging capability. Levels follow syslog/RFC 5424 (debug through emergency). Clients may send logging/setLevel and receive server-to-client notifications/message with level, optional logger name, and JSON data. All client handling (display, filtering, search) is MAY-level, so a minimal client may set the level, display messages, or ignore them entirely.

Key findings

"Servers that emit log message notifications MUST declare the logging capability."
Levels follow syslog/RFC 5424: debug, info, notice, warning, error, critical, alert, emergency.
Clients "MAY send a logging/setLevel request" ({"level":"info"}).
Server-to-client notifications/message carries level, optional logger, and JSON data.
"Clients MAY: Present log messages in the UI; Implement log filtering/search…" (all MAY).

Pros / strengths

Syslog/RFC 5424 levels are a well-understood 8-level scale, so no new severity taxonomy to learn.
Entirely optional on the client: set level, display, filter, or ignore are all compliant, which is ideal for a minimal implementation.
Structured data plus optional logger name gives enough shape for filtering without mandating any client behavior.

Cons / limitations / caveats

No explicit author names or publish dates appear on the page; the date above is the version stamp in the URL, per the pack's Uncertainty notes.
Minimal debugging value for a stdio client that already sees server stderr; the feature matters more for HTTP sessions where stderr is unavailable.
Deprecated in the 2026-07-28 revision (logging/setLevel removed; log level becomes per-request _meta), so any client investment here is handshake-era-only.

Relevance to tai

Entirely optional on the client: tai may send logging/setLevel, may display or ignore notifications/message. For a minimal stdlib client this is safely deferred or reduced to ignoring the notifications.

Changelog

Date	Change
2026-10-18	Initial dossier created.

2.9 KiB Raw Blame History