You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
-14Lines changed: 0 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2160,8 +2160,6 @@ Servers may send notifications, which derive from the `ServerNotification` class
2160
2160
1. For each notification type you want to support, write a callback function that follows implements the matching protocol, such as `ToolListChangedFnT` for the tool list changed notification.
2161
2161
2. Pass that function to the appropriate parameter when instantiating your client, e.g. `tool_list_changed_callback` for the tool list changed notification. This will be called every time your client receives the matching notification.
2162
2162
2163
-
You can also use this pattern with the `UnknownNotificationFnT` protocol to handle notification types that aren't anticipated in the SDK or by your code. This would handle custom notification types from the server.
If your client expects to connect to a server that sends custom notifications, you can create your handler or handlers, then pass them in a dictionary where the key is the notification literal and the value is a reference to the handler function. This dictionary is then passed in to the `custom_notification_handlers` parameter of the `ClientSession` constructor.
2217
-
2218
-
For a runnable example, see [examples/snippets/clients/custom_notifications_example.py](https://github.com/modelcontextprotocol/python-sdk/blob/main/examples/snippets/clients/custom_notifications_example.py).
2219
-
2220
2206
### Client Display Utilities
2221
2207
2222
2208
When building MCP clients, the SDK provides utilities to help display human-readable names for tools, resources, and prompts:
0 commit comments