Expose generic `SendNotification` on `ServerSession` for custom protocol extensions

[vaijab]

Use Case

I am implementing an MCP Server for the Gemini CLI IDE Integration. The specification requires the server to send custom notifications to the client to signal specific events.

Specifically, I need to send:

• ide/diffAccepted
• ide/diffRejected
• ide/contextUpdate

The Problem

Currently, the mcp.ServerSession struct only exposes specific notification helpers (like NotifyProgress and Log). There is no public API to send a generic/custom JSON-RPC notification.

I attempted to use session.Notify(ctx, method, params), but:

1. The conn field on ServerSession is unexported.
2. The mcp.Connection interface's Write method requires *mcp.JSONRPCMessage, which is an unexported struct.

Proposed Solution

Please expose a generic notification method on ServerSession, similar to:

// In mcp/server.go

func (s *ServerSession) SendNotification(ctx context.Context, method string, params any) error {
    return s.conn.Notify(ctx, method, params)
}

Current Workaround

I am currently forced to use unsafe and reflect to access the underlying conn field to call its Notify method, which is fragile for obvious reasons.

[jba]

While the MCP spec does not explicitly allow custom notifications, it doesn't explicitly exclude them either.

I confirmed by reading the linked doc that the IDE plugin must talk to the IDE over an HTTP connection using MCP, and that it does specify some custom notifications.

So I recommend we do this.

[jba]

Some issues that make this more complicated than the simple one-liner in the top post:

• All other notifications go through sending middleware. These should too.
• The sending mechanism recognizes a notification because its method starts with "notifications/". These do not.
• A server may support many sessions. Presumbably the notification should be sent to them all. (Even if there's ever only one for the IDE; we need to think more generally.)

[vaijab]

@jba thanks for looking into this. Shall I raise a PR with the changes or you prefer that maintainers do it?

[jba]

A PR would be great. I don't quite see how to do it myself, frankly.

[jba]

Let's discuss the design here first. We should start with how we're going to recognize these custom notifications. I'd rather not have a registration mechanism. Maybe we can design a convention.

[findleyr]

@jba I think we can just expose a method to send an arbitrary notification. No registry needed.

[jba]

@findleyr It should go through the middleware, which means it will eventually get to https://github.com/modelcontextprotocol/go-sdk/blob/main/mcp/shared.go#L91, which expects all methods to be known and recognizes notifications by method name.

I don't think we should skip the middleware. It may be performing accounting, logging, PII scrubbing, and other operations that should apply to all outgoing messages.

One simple idea: if method begins with the segment x-notifications, that segment is removed and the remainder is sent as a notification. We would skip everything else in the function until L107.