Sync-facade inconsistency

[tterimaa]

Pre-submission Checklist

• I have checked that this question would not be more appropriate as an issue in a specific repository
• I have searched existing discussions and documentation for answers

Question Category

• Protocol Specification
• SDK Usage
• Server Implementation
• General Implementation
• Documentation
• Other

Your Question

Details

McpSyncServer blocks, returns void:

java-sdk/mcp-core/src/main/java/io/modelcontextprotocol/server/McpSyncServer.java

Lines 246 to 248 in df75857

	public void closeGracefully() {
	this.asyncServer.closeGracefully().block();
	}

McpStatelessSyncServer returns the cold Mono, does not block:

java-sdk/mcp-core/src/main/java/io/modelcontextprotocol/server/McpStatelessSyncServer.java

Lines 55 to 57 in df75857

	public Mono<Void> closeGracefully() {
	return this.asyncServer.closeGracefully();
	}

Every other method on McpStatelessSyncServer follows the blocking-facade convention, so closeGracefully() is the lone exception.

Question

Is the Mono return type intentional (e.g. to allow composition), or an oversight? If intentional, could the javadoc call out that callers must subscribe (and contrast it with McpSyncServer)? If not, aligning the signature to void closeGracefully() with an internal .block() would make the two SyncServer classes consistent.

[chemicL]

Thank you for bringing this to our attention. This was completely overlooked. Fixing in #1019.