jeecgboot/JeecgBoot · warning · RuntimeException
未知方法: {method}
Error message
未知方法: {method} What it means
McpDemoController implements a minimal MCP (Model Context Protocol) JSON-RPC 2.0 server. The switch dispatches only initialize, initialized, notifications/initialized, tools/list, tools/call, ping, notifications/cancelled. Any other method -- that is not a notifications/* (which is silently ignored) -- throws. The exception is caught and returned to the client as JSON-RPC error code -32603 (internal error) with the method name in the message.
Source
Thrown at jeecg-boot/jeecg-boot-module/jeecg-module-demo/src/main/java/org/jeecg/modules/demo/mcp/McpDemoController.java:184
// 构建 JSON-RPC 2.0 响应
Map<String, Object> jsonRpcResponse = new LinkedHashMap<>();
jsonRpcResponse.put("jsonrpc", "2.0");
jsonRpcResponse.put("id", id);
try {
Object result = switch (method) {
case "initialize" -> handleInitialize(params);
case "initialized", "notifications/initialized" -> handleInitialized();
case "tools/list" -> handleToolsList();
case "tools/call" -> handleToolsCall(params);
case "ping" -> handlePing();
case "notifications/cancelled" -> handleCancelled(params);
default -> {
if (method != null && method.startsWith("notifications/")) {
log.info("[MCP Server] 忽略未知通知: {}", method);
yield Map.of();
}
throw new RuntimeException("未知方法: " + method);
}
};
jsonRpcResponse.put("result", result);
} catch (Exception e) {
log.error("[MCP Server] 处理请求失败", e);
jsonRpcResponse.put("error", Map.of(
"code", -32603,
"message", e.getMessage()
));
}
String responseJson = JSON.toJSONString(jsonRpcResponse);
log.info("[MCP Server] 返回: {}", responseJson);
writer.write(responseJson);
} catch (Exception e) {
log.error("[MCP Server] 解析请求失败", e);
writer.write("{\"jsonrpc\":\"2.0\",\"id\":null,\"error\":{\"code\":-32700,\"message\":\"Parse error\"}}");View on GitHub (pinned to 96fb33f5ec)
Solutions
- Check the 'method' field in the request and the log line '[MCP Server] 处理请求失败'.
- If the client needs the capability, add a case branch and a handler.
- If it is a notification, ensure the method starts with 'notifications/' so it is ignored instead of erroring.
- Return a proper -32601 'method not found' instead of -32603 if you want spec-correct behavior.
Example fix
// before
default -> throw new RuntimeException("未知方法: " + method);
// after - spec-correct JSON-RPC method-not-found
default -> {
if (method != null && method.startsWith("notifications/")) { yield Map.of(); }
throw new RuntimeException("Method not found: " + method); // map to code -32601
} Defensive patterns
Strategy: validation
Validate before calling
private static final Set<String> SUPPORTED = Set.of(
"initialize","initialized","notifications/initialized",
"tools/list","tools/call","ping","notifications/cancelled");
if (method != null && !SUPPORTED.contains(method) && !method.startsWith("notifications/")) {
// return JSON-RPC -32601 method not found instead of -32603
} Try / catch
// The handler already catches Exception and maps to error code -32603.
// Improve: distinguish method-not-found (-32601) from internal errors.
try { ... } catch (UnsupportedMethodException e) {
jsonRpcResponse.put("error", Map.of("code", -32601, "message", e.getMessage()));
} catch (Exception e) {
jsonRpcResponse.put("error", Map.of("code", -32603, "message", e.getMessage()));
} Prevention
- Keep the supported-method set in sync with the MCP spec version you target.
- Return -32601 for unknown methods to be spec-correct.
- Ignore unknown notifications silently rather than erroring.
When it happens
Trigger: An MCP client sends a method the demo server doesn't implement: resources/*, prompts/*, completion/*, logging/*, or any future-spec method.
Common situations: Client uses newer MCP spec capabilities the demo lacks; a generic MCP client probing endpoints; custom method invocation.
Related errors
AI-assisted analysis of jeecgboot/JeecgBoot@96fb33f5ec (2026-08-14).
Data as JSON: /api/errors/fb206021d7195c2c.
Report an issue: GitHub.