Skip to content

docs(server): note that logging without the capability sends nothing #3052

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
EdidiongA wants to merge 2 commits into
base: main
Choose a base branch
from
Open

docs(server): note that logging without the capability sends nothing #3052

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
494dae0
docs(server): note that logging without the capability sends nothing
EdidiongA Oct 19, 2026
ed7caa6
docs(server): note the window an event store cannot replay
EdidiongA Oct 19, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/servers/logging-progress-cancellation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -77,7 +77,7 @@ Only the result comes back:
Log to `stderr` (stdio servers) or use OpenTelemetry instead. **MCP logging** is deprecated as of protocol version 2026-07-28 (SEP-2577) and stays functional through the deprecation window (at least twelve months) — see the [deprecated features registry](https://modelcontextprotocol.io/specification/2026-07-28/deprecated).
:::

Declare the `logging` capability when you construct the server.
Declare the `logging` capability when you construct the server. Without it, `ctx.mcpReq.log()` and `server.sendLoggingMessage()` resolve successfully and send nothing, with no warning.

```ts source="../../examples/guides/servers/logging-progress-cancellation.examples.ts#logging_capability"
const server = new McpServer({ name: 'file-processor', version: '1.0.0' }, { capabilities: { logging: {} } });
Expand Down
2 changes: 1 addition & 1 deletion docs/serving/sessions-state-scaling.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -92,7 +92,7 @@ On shutdown, close every stored transport — `for (const { transport } of sessi

## Resume a dropped stream

A sessionful client holds a `GET` SSE stream open for server notifications, and anything sent while that connection is down is lost. An **event store** closes the gap: with one configured, the transport stamps every SSE message with an event id from the store before sending it.
A sessionful client holds a `GET` SSE stream open for server notifications, and anything sent while that connection is down is lost. An **event store** closes the gap: with one configured, the transport stamps every SSE message with an event id from the store before sending it. One window it cannot close: anything sent before the client has opened its first `GET`, because that request carries no `Last-Event-ID` to replay from. A server that emits alerts on a timer should repeat them while the condition persists, or defer its first check until a client is likely connected.

`EventStore` is a two-method contract — `storeEvent(streamId, message)` persists a message and returns its event id; `replayEventsAfter(lastEventId, { send })` re-sends every later message on that stream. Implement it over storage every node can reach (`databaseEventStore` here) and pass it next to `sessionIdGenerator`.

Expand Down
Loading