feat: auto-publish server announcements on start (CEP-6)

[harsh04044]

Part of CEP-6 implementation #76.

When is_announced_server: true, the transport auto-publishes all announcement events after startup - no manual calls needed.

What happens:

• A background task is spawned after the message loop is running
• Dispatches a synthetic initialize request through the transport's message channel
• Waits up to 10s for the rmcp handler to respond, then proceeds gracefully even on timeout
• On init response, dispatches notifications/initialized then publishes kind 11316 with the full InitializeResult
• Dispatches tools/list, resources/list, resources/templates/list, prompts/list - each response triggers the correct kind (11317-11320)

Worker routes responses with id == "announcement" to the announcement handler before the existing stateless sentinel check.

Critical ordering preserved: notifications/initialized is queued before signaling the Notify, so the worker sees initialized state before capability-list requests arrive.

Note: schema-to-kind mapping is currently field-presence based - explicit schema validation matching the TS SDK is tracked as follow-up in 4th PR.

10 new tests, 373 passing.

[ContextVM-org]

I went through this against the CEP-6 scope and the TS reference, and overall I think the structure here is solid. The synthetic initialize flow, the worker interception for the announcement sentinel, and especially the initialized-ordering guarantee all look well thought out.

I do have one blocking correctness issue though: the auto-publish flow is dispatching resourceTemplates/list, but the MCP/spec method is resources/templates/list. The TS SDK and the Rust RMCP crate both use the spec form as well. So this looks like a Rust-side typo in the new CEP-6 auto-publish path, not a protocol ambiguity. As written, I’d expect resource template auto-publication to fail or be skipped depending on the server implementation. I’d change that method name and update the associated test expectation so we lock in the canonical protocol string.

I’d also tighten the PR description in two places for precision. First, saying this happens “on start” is a bit misleading, because the announcement task is actually spawned after startup from the worker side so the message loop is already running. Second, the current wording around the 10s wait sounds stricter than the implementation: the code waits up to 10s for initialize, but then proceeds gracefully with the capability-list dispatch even on timeout.

One other recommendation: the current schema-to-kind mapping works, but it is still heuristic, based on field presence. That is probably fine for landing this slice, but it does not quite reach the explicit mapping/validation shape described in the issue or used in the TS implementation. I would be fine with that as follow-up work, but I think it’s worth calling out clearly as not being full parity yet.

On tests, I think the new coverage is good around ordering and basic publication behavior. I would still like to see the resource templates request string covered as a regression point, since that is the easiest place for protocol drift to hide.

So my recommendation would be: fix the resource templates method name before merge, adjust the PR wording around startup and timeout behavior, and treat the stronger schema-mapping parity as follow-up rather than implying issue-wide completion.

[harsh04044]

I went through this against the CEP-6 scope and the TS reference, and overall I think the structure here is solid. The synthetic initialize flow, the worker interception for the announcement sentinel, and especially the initialized-ordering guarantee all look well thought out.

I do have one blocking correctness issue though: the auto-publish flow is dispatching resourceTemplates/list, but the MCP/spec method is resources/templates/list. The TS SDK and the Rust RMCP crate both use the spec form as well. So this looks like a Rust-side typo in the new CEP-6 auto-publish path, not a protocol ambiguity. As written, I’d expect resource template auto-publication to fail or be skipped depending on the server implementation. I’d change that method name and update the associated test expectation so we lock in the canonical protocol string.

I’d also tighten the PR description in two places for precision. First, saying this happens “on start” is a bit misleading, because the announcement task is actually spawned after startup from the worker side so the message loop is already running. Second, the current wording around the 10s wait sounds stricter than the implementation: the code waits up to 10s for initialize, but then proceeds gracefully with the capability-list dispatch even on timeout.

One other recommendation: the current schema-to-kind mapping works, but it is still heuristic, based on field presence. That is probably fine for landing this slice, but it does not quite reach the explicit mapping/validation shape described in the issue or used in the TS implementation. I would be fine with that as follow-up work, but I think it’s worth calling out clearly as not being full parity yet.

On tests, I think the new coverage is good around ordering and basic publication behavior. I would still like to see the resource templates request string covered as a regression point, since that is the easiest place for protocol drift to hide.

So my recommendation would be: fix the resource templates method name before merge, adjust the PR wording around startup and timeout behavior, and treat the stronger schema-mapping parity as follow-up rather than implying issue-wide completion.

fixed the method name (resourceTemplates/list → resources/templates/list) and updated the test expectation. also noted the schema-to-kind mapping parity as a follow-up item. good catch on the protocol string!