fix: startup logging messages never reached clients

[mattpodwysocki]

Summary

Two compounding issues meant startup logging (.env load status, tracing status, detected client capabilities) never reached any client:

1. The McpServer never declared the logging capability in its constructor options, so sendLoggingMessage was an unconditional no-op (the SDK checks this._capabilities.logging before doing anything) regardless of timing.
2. Independently, several sendLoggingMessage calls ran before await server.connect(transport) — a notification sent before the transport is connected has no client to reach, so those calls would have been dropped even with the capability declared correctly.

Fixed both:

• Added logging: {} to the server's declared capabilities.
• Moved all startup sendLoggingMessage calls to run after connect(), matching the ordering @mapbox/mcp-server's src/index.ts already uses (with the same "now that we're connected, send all the logging messages" pattern).

Follow-up commit, same root cause: getClientVersion()/getClientCapabilities() are only populated once the client's initialize request has been processed — reading them right after connect() (as the existing capability-gated tool registration did) reliably saw them as unset, confirmed live even for a client that explicitly declared elicitation support. Both reads now happen inside a server.server.oninitialized callback, which only fires once the handshake is fully done. As a result:

• The connected client's identity (name/version from its initialize request) is now logged, e.g. Client identified as: claude-ai v1.0.0 — useful for support/debugging across Claude Desktop, Cursor, VS Code, etc.
• It's also recorded as mcp.client.name/mcp.client.version on every subsequent tool-execution trace span, so OTel-backed traces can be filtered/grouped by client.
• The capability-gated elicitation-tool registration path is fixed too (currently dormant since ELICITATION_TOOLS is empty, but was silently broken for whenever a tool is added there).

Matches the equivalent changes landing in @mapbox/mcp-server.

Test plan

• New integration test (test/integration/loggingOrder.test.ts) spawns the real built server and asserts a real MCP client receives at least one startup log message. Verified it fails against each fix in isolation (capability alone still drops messages sent pre-connect; ordering alone still no-ops without the capability) and passes with both applied.
• New unit tests (test/utils/tracing.test.ts) cover createToolSpan picking up mcp.client.name/mcp.client.version once setClientInfo is called.
• Live-verified against the real built server with a real MCP client declaring a custom name/version and elicitation capability: server now logs Client identified as: pretend-codex-client v4.2.0 and Client capabilities detected: { "elicitation": { "form": {} } } (previously undefined).
• npx vitest run — all 641 tests pass
• npm run build succeeds
• CHANGELOG.md updated

🤖 Generated with Claude Code