Cancellation protocol operation not implemented.

[Tyler-R-Kendrick]

According to the spec

When a party wants to cancel an in-progress request, it sends a notifications/cancelled
notification containing:

• The ID of the request to cancel
• An optional reason string that can be logged or displayed

{
  "jsonrpc": "2.0",
  "method": "notifications/cancelled",
  "params": {
    "requestId": "123",
    "reason": "User requested cancellation"
  }
}

Behavior Requirements

1. Cancellation notifications MUST only reference requests that:
   • Were previously issued in the same direction
   • Are believed to still be in-progress
2. The initialize request MUST NOT be cancelled by clients
3. Receivers of cancellation notifications SHOULD:
   • Stop processing the cancelled request
   • Free associated resources
   • Not send a response for the cancelled request
4. Receivers MAY ignore cancellation notifications if:
   • The referenced request is unknown
   • Processing has already completed
   • The request cannot be cancelled
5. The sender of the cancellation notification SHOULD ignore any response to the
   request that arrives afterward

Timing Considerations

Due to network latency, cancellation notifications may arrive after request processing
has completed, and potentially after a response has already been sent.

Both parties MUST handle these race conditions gracefully:

sequenceDiagram
   participant Client
   participant Server

   Client->>Server: Request (ID: 123)
   Note over Server: Processing starts
   Client--)Server: notifications/cancelled (ID: 123)
   alt
      Note over Server: Processing may have<br/>completed before<br/>cancellation arrives
   else If not completed
      Note over Server: Stop processing
   end

Loading

Implementation Notes

• Both parties SHOULD log cancellation reasons for debugging
• Application UIs SHOULD indicate when cancellation is requested

Error Handling

Invalid cancellation notifications SHOULD be ignored:

• Unknown request IDs
• Already completed requests
• Malformed notifications

This maintains the "fire and forget" nature of notifications while allowing for race
conditions in asynchronous communication.

Implementation suggestions

If an operation is meant to be cancellable and implements a cancellation token, it should send a cancellation notification over the protocol when the token "IsCancellationRequested" property is true.

Because this is behavior that is likely to be implemented in every method, this should probably be implemented as an ambient concern.

[PederHP]

In practice, this is relevant for Tool Calls (server cancels when notified by client, and tool call is still on-going) and Sampling (client cancels when notified by server).

I am not sure tool/sampling methods should be forced to take a cancellation token to support cancellation. It's possible to cancel it in the handler in other ways). There are two aspects to cancellation:

1. Actually canceling the ongoing operation - whether this is possible depends on the implementation by the SDK user.
2. Not sending a response (as spec requires) - this is possible to align with regardless of whether the operation supports cancellation.

For all other request types I think it makes sense to ignore the cancellation request. They're essentially instant requests, where there is nothing to cancel.

[stephentoub]

We should just make it so that the cancellation token that's already passed into the relevant operation has cancellation requested when a relevant cancellation signal arrives.

[PederHP]

We should just make it so that the cancellation token that's already passed into the relevant operation has cancellation requested when a relevant cancellation signal arrives.

Does ReflectionAIFunction allow passing through the token to the implementing method if it has a CancellationToken in the signature?

Otherwise, won't the cancellation only occur once the tool returns?
https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol/Server/AIFunctionMcpServerTool.cs

In many cases that's probably fine, but for some cases having the actual tool be cancellable would be preferable. For Sampling I think it will be easier because the relevant IChatClient methods have cancellation, and there's no reflection involved.

But I think for tools, it would be ideal to be able to write cancellable tool methods.

[stephentoub]

Does ReflectionAIFunction allow passing through the token to the implementing method if it has a CancellationToken in the signature

Yes