Skip to content

fix: MCP Streamable HTTP can drop server notifications emitted during a request #8060

Description

@lloydrichards

Problem

An MCP tool invoked over Streamable HTTP can emit logging or other server notifications, but the notifications are not reliably delivered before the request completes.

The external MCP conformance scenarios tools-call-with-logging and tools-call-with-progress expose this. Against effect@4.0.0-rc.112, the applicable adapter checks fail for the released protocol versions.

Observed behavior

The tool result is returned, but notification frames are missing or the streamed response is not consistently represented as Server-Sent Events.

The HTTP request lifecycle also treats the request-body EOF as though the MCP client disconnected. This can remove the negotiated client/profile state while asynchronous request work is still running.

Expected behavior

Notifications emitted as part of an active HTTP request should be delivered as valid SSE frames before the response stream completes. Finishing the POST request body must not disconnect the logical MCP session.

External regression scenarios

  • tools-call-with-logging
  • tools-call-with-progress

These checks are applicable protocol behavior and should pass rather than be skipped.

Regression coverage

Add an HTTP adapter test that invokes a tool which emits multiple notifications and then returns a result. Assert that every notification and the final result are observable in order from the streamed response.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions