retoor
251c3dc2ba
- 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)
55 lines
2.9 KiB
Markdown
55 lines
2.9 KiB
Markdown
# 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. |
|