java mcp message endpoint error
Because the implementation of java mcp sdk does not handle the problem of messageEndpoint returning CompleteMessageEndpoint URI when splicing messageEndpoint and base URL, it simply splices, resulting in the phenomenon of http://localhost/mcphttp://localhost/mcp/message.
Here are the references:
https://github.com/modelcontextprotocol/java-sdk/releases/tag/v0.8.1
public Mono<Void> sendMessage(McpSchema.JSONRPCMessage message) {
if (this.isClosing) {
return Mono.empty();
} else {
try {
if (!this.closeLatch.await(10L, TimeUnit.SECONDS)) {
return Mono.error(new McpError("Failed to wait for the message endpoint"));
}
} catch (InterruptedException var5) {
return Mono.error(new McpError("Failed to wait for the message endpoint"));
}
String endpoint = (String)this.messageEndpoint.get();
if (endpoint == null) {
return Mono.error(new McpError("No message endpoint available"));
} else {
try {
String jsonText = this.objectMapper.writeValueAsString(message);
HttpRequest request = HttpRequest.newBuilder().uri(URI.create(this.baseUri + endpoint)).header("Content-Type", "application/json").POST(BodyPublishers.ofString(jsonText)).build();
return Mono.fromFuture(this.httpClient.sendAsync(request, BodyHandlers.discarding()).thenAccept((response) -> {
if (response.statusCode() != 200 && response.statusCode() != 201 && response.statusCode() != 202 && response.statusCode() != 206) {
logger.error("Error sending message: {}", response.statusCode());
}
}));
} catch (IOException var6) {
return !this.isClosing ? Mono.error(new RuntimeException("Failed to serialize message", var6)) : Mono.empty();
}
}
}
}
fix https://github.com/mark3labs/mcp-go/pull/75
Could you achieve the required behaviour by passing just an empty baseUrl? That way all the rendered URLs should be relative.
And I believe it should be fixed in Java SDK anyway.
Could you achieve the required behaviour by passing just an empty
baseUrl? That way all the rendered URLs should be relative.And I believe it should be fixed in Java SDK anyway.
I think giving choices is a better approach.
Java has not fixed this problem in 7 versions. We need to consider industry compatibility to ensure a wider audience, and I don't know how long it will take for the Java author to fix this problem.
Java has not fixed this problem in 7 versions.
I suppose it would be great for the cross-project references if you could link a relevant issue in Java SDK project.
OK, I'll go back and make a suggestion.