Replies: 1 comment
|
It was an omission in the synchronous client, not an intentional protocol limitation. With the current API, register the consumer when building the client and then subscribe to the resource URI: McpSyncClient client = McpClient.sync(transport)
.resourcesUpdateConsumer(contents -> {
// Updated contents for the subscribed URI.
contents.forEach(System.out::println);
})
.build();
client.initialize();
client.subscribeResource(
McpSchema.SubscribeRequest.builder("file:///project/src/main.rs").build()
);The callback receives The async equivalent is: McpAsyncClient client = McpClient.async(transport)
.resourcesUpdateConsumer(contents -> Mono.fromRunnable(() -> {
contents.forEach(System.out::println);
}))
.build();
client.initialize()
.then(client.subscribeResource(
McpSchema.SubscribeRequest.builder("file:///project/src/main.rs").build()
))
.subscribe();See the current resource-subscription documentation and the client notification handler, which performs the automatic |
Uh oh!
There was an error while loading. Please reload this page.
Pre-submission Checklist
Discussion Topic
According to the MCP protocol, servers can send:
We do have
ResourcesUpdatedNotification.McpClient.SyncSpecis missing the support for reacting to this notification.Is this intentional?
All reactions