MCP Channel notifications (notifications/claude/channel) do not deliver server-initiated messages to AI context

Problem

MCP servers declaring experimental: { "claude/channel": {} } capability and calling mcp.notification({ method: "notifications/claude/channel", params: {...} }) do not reliably deliver messages to the Claude Code AI context.

What we built

An inter-agent messaging system where:

1. MCP server polls GitLab for new messages (every 30s)
2. On new message, calls mcp.notification() with notifications/claude/channel
3. Expected: Claude Code receives <channel source="..."> tag in conversation

const mcp = new Server(
  { name: "jkit-msg", version: "0.0.1" },
  {
    capabilities: {
      experimental: { "claude/channel": {} },
      tools: {},
    },
  }
);

// After polling detects new message:
await mcp.notification({
  method: "notifications/claude/channel",
  params: {
    content: "message text",
    meta: { from: "AgentB", note_id: "123", type: "message", ts: "..." },
  },
});

What actually happens

• Notifications are sent via stdio but never appear in the AI conversation
• Tested across multiple sessions and Claude Code restarts
• One instance (ANNZI2) partially received notifications once; another instance (ANNZI) never did — same codebase, same config
• Users must still manually invoke tools to check messages — the Channel feature provides zero value
• We spent significant development time building on this feature based on Claude Code's own recommendation and the SDK accepting the capability without error

Expected behavior

If experimental/claude/channel is a supported capability, server-initiated notifications should reliably appear in the AI context. If it's not supported, the SDK should reject or warn about the unsupported capability declaration — not silently accept it.

Environment

• Claude Code (latest, Windows 11)
• @modelcontextprotocol/sdk via Bun runtime
• Transport: StdioServerTransport

Request

1. Clarify: Is notifications/claude/channel actually implemented in Claude Code? If so, what are the exact requirements for it to work reliably?
2. If not implemented: Remove or deprecate the capability so developers don't build on a non-functional feature. At minimum, log a warning when an MCP server declares an unsupported experimental capability.
3. Feature request: Provide a reliable, documented mechanism for MCP servers to push asynchronous messages/notifications into the AI context (e.g., queued and delivered on next user prompt).

Impact

This is not a minor inconvenience. Claude Code (the AI itself) recommended this architecture, confirmed it would work, and reported successful verification — all of which turned out to be false. Developers relying on Claude Code's guidance built production features on a non-functional API surface. There needs to be either proper documentation of what works, or guardrails preventing the AI from recommending unsupported features.