Problem

MCP servers have a good vocabulary for telling a host that state changed:

• notifications/resources/updated: a resource's contents changed; invalidate caches.
• notifications/resources/list_changed, notifications/tools/list_changed, notifications/prompts/list_changed: a catalog changed.
• notifications/progress: a long-running request made progress.
• notifications/message: server-side logging.

None of these model a short, turn-scoped fact the server wants the agent to see before its next model call. Concrete cases that come up with watcher-style servers:

• A filesystem server notices the user edited src/lib.rs in another editor while the agent was working. The agent should re-read the file before its next edit.
• A build-watcher server sees cargo check go green after the agent's last change.
• A test-watcher server sees a previously failing test start passing.
• A CI/code-review server sees a review land on the PR the agent is iterating on.

Hosts already solve this internally: several coding agents inject ambient "system reminder"-style context blocks at turn boundaries (Claude Code's <system-reminder> pattern is the most visible public example). But an MCP server has no standard way to feed that channel. Today implementors pick one of three workarounds:

1. Re-emit notifications/resources/updated and rely on an out-of-band convention that the host will re-read and surface the change to the model. Fragile, and the server (the domain expert on why the event matters) never gets to phrase it.
2. Expose a "check for updates" tool the agent must remember to call. Loses push semantics and burns a tool slot.
3. Overload notifications/message (logging) or notifications/progress with reminder text. Wrong primitive; hosts route those to logs and progress UI, not model context.

Proposal

A new server-initiated notification:

{
  "jsonrpc": "2.0",
  "method": "notifications/reminder",
  "params": {
    "reminder": {
      "id": "0190abcd-2024-7c1d-bb02-3a0e8a44d7f0",
      "body": "src/lib.rs changed externally; re-read it before editing.",
      "tags": ["workspace", "file_changed"],
      "dedupeKey": "file_changed:src/lib.rs",
      "ttlTurns": 2,
      "roleHint": "system"
    },
    "_meta": {}
  }
}

• body is the only required content field: natural-language text the host may place into the agent's next turn (as a system/developer block; roleHint is advisory).
• dedupeKey: a newer reminder replaces older pending ones with the same key, so a chatty watcher collapses to one line instead of flooding the transcript.
• ttlTurns: the reminder stops being rendered after N turns; stale facts age out instead of accumulating.

Servers declare the capability at initialize (capabilities.reminders.emit: true); hosts SHOULD ignore the notification from servers that didn't declare it, consistent with the existing tolerance rule for unknown messages.

Why not notifications/resources/updated?

They compose rather than compete. resources/updated is a cache-invalidation signal about host-side state; nothing reaches the model unless the host invents a synthetic nudge and its own wording. notifications/reminder is "tell the agent X happened, in the server's words, on its next turn." A well-behaved watcher server emits both: resources/updated so caches invalidate, and a reminder so the agent learns about it in time to act.

Open questions

1. Naming: flat notifications/reminder (matching notifications/progress) vs something namespaced.
2. Scope: session-scoped as proposed, or also tool-scoped (riding alongside an in-flight tools/call)?
3. Should hosts echo reminder lifecycle events (rendered / deduped / expired) back to servers, or stay asymmetric like the rest of the notification surface?
4. roleHint values: standardize provider-specific hints, or keep just system / developer?
5. Backpressure: recommend a per-server reminder budget, or leave rate-limiting to host policy like notifications/message?

If maintainers think this is worth pursuing, I'm happy to write it up through the SEP process at whatever scope fits. There is a working implementation of this shape behind _meta today, so the proposal comes from running code rather than a sketch.

Disclosure: I drafted this with AI assistance and reviewed it before posting; the design and the reference implementation are human-maintained.