Refactor progress reporting to use official MCP API instead of `transport.sendEvent`

[regenrek]

Problem

The starter currently calls transport.sendEvent('progress', ...) directly from tool code.
Only the SSE transport implements sendEvent. When the server runs with the stdio or HTTP transports this produces a runtime error:

TypeError: transport.sendEvent is not a function

To keep things running we added a temporary shim that injects a no-op sendEvent method into transports that do not have one. That patch hides the crash but sidesteps the proper solution.

Goal

Eliminate the need for the shim by routing all progress updates through the official MCP progress notification helper that is transport-agnostic.

Tasks

• Identify all tool code paths that call transport.sendEvent
• Replace those calls with the SDK helper:

  mcp.sendProgressNotification(progressToken, params)

  or the newer context.progress(params) if available in the SDK version in use
• Remove the shim that adds sendEvent to Rest and Stdio transports
• Verify that progress events are delivered correctly over SSE, HTTP, and stdio
• Update unit tests and add a new test that ensures no code path relies on sendEvent

Acceptance criteria

• Server runs in stdio, HTTP, and SSE modes without shimming or runtime patches
• Progress notifications reach clients in all modes
• No tool code references transport.sendEvent directly
• All tests pass

Additional context

The MCP SDK’s Protocol class already handles progress notifications uniformly for every transport. Using that API keeps transports simple and avoids duplication.

With a shim:

if (options.type === 'stdio') {
    const transport = new StdioServerTransport() as any
    if (typeof transport.sendEvent !== 'function')
      transport.sendEvent = () => {}
    await server.connect(transport)
    return
  }