Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: MCP server: tools/list sent as notification instead of request/response (breaks Hermes Agent) [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#68587•Fetched 2026-04-19 15:09:53
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
charlescha615charlescha615
Participants
charlescha615charlescha615m13vm13v
Timeline (top)
labeled ×2commented ×1cross-referenced ×1referenced ×1

Root Cause

Additional context:

  • initialize works correctly (request/response with id)
  • Other tools (e.g. memory_search) fail because clients cannot discover them via tools/list
  • Hermes Agent reports "Method not found" for tools/list
  • Hermes MCP debug shows the server actually pushes tools asynchronously via notification, not in response to client request

Fix Action

Fixed

PR fix notes

PR #68800: fix: route logs to stderr in openclaw mcp serve (fixes #68587)

Description (problem / solution / changelog)

Problem

openclaw mcp serve writes config warnings and other log output to stdout, polluting the MCP JSON-RPC message stream. MCP stdio clients (e.g. Hermes Agent) that strictly parse stdout encounter non-JSON text before the first response, causing tools/list and other requests to fail with "Method not found".

The plugin tools MCP server (servePluginToolsMcp) already calls routeLogsToStderr() at the top of its function, but the channel MCP server (serveOpenClawChannelMcp) does not.

Root Cause

loadConfig() emits styled warnings via console/clack that default to stdout:

│
◇  Config warnings ───────────────────────────╮
│  - plugins.entries.memory-lancedb-pro: ...   │
├──────────────────────────────────────────────╯
{"result":{"protocolVersion":...},"jsonrpc":"2.0","id":1}

The non-JSON output before the JSON-RPC response breaks any MCP client that reads stdout line-by-line.

Fix

Add routeLogsToStderr() at the top of serveOpenClawChannelMcp() before loadConfig() is called, matching the pattern already used by servePluginToolsMcp().

Verification

Tested with raw JSON-RPC over stdio:

Before fix: stdout contains terminal UI warnings before JSON-RPC responses → clients see parse errors / "Method not found"

After fix: stdout is pure JSON-RPC, warnings go to stderr → tools/list returns 9 channel tools correctly

Changes

  • src/mcp/channel-server.ts: import and call routeLogsToStderr() (2 lines)
  • src/mcp/channel-server.test.ts: add test verifying tools/list returns proper response with tools capability

Closes #68587

Changed files

  • src/mcp/channel-server.test.ts (modified, +34/-0)
  • src/mcp/channel-server.ts (modified, +6/-0)
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

Yes

Summary

Bug: MCP server tools/list uses notification instead of request/response

OpenClaw version: 2026.4.15 (macOS)

Summary:
When OpenClaw MCP server (openclaw mcp serve) is used as a stdio MCP server, it sends tools/list as a notification (no id field) instead of responding to a client request (with matching id). This violates the MCP protocol specification and causes all standard MCP clients (tested with Hermes Agent) to fail with "Method not found" when trying to list available tools.

Environment:

  • OpenClaw CLI: 2026.4.15
  • macOS (Darwin arm64)
  • Node: 25.9.0
  • Gateway: LaunchAgent

Steps to reproduce:

  1. Start OpenClaw MCP server: openclaw mcp serve --token-file <token>
  2. Connect a standard MCP client (e.g. Hermes Agent) configured to connect via stdio
  3. Client sends initialize → succeeds
  4. Client sends tools/list request (with id) → server responds with Method not found
  5. Server sends notifications/tools/list (notification, no id) → client receives tools but doesn't know which request it answers

Expected behavior (per MCP protocol):
Server should respond to tools/list request (with matching id) with a tools/list response containing the list of tools.

Actual behavior:
Server sends notifications/tools/list as a fire-and-forget notification with no id, which standard MCP clients cannot correlate to a pending request.

Additional context:

  • initialize works correctly (request/response with id)
  • Other tools (e.g. memory_search) fail because clients cannot discover them via tools/list
  • Hermes Agent reports "Method not found" for tools/list
  • Hermes MCP debug shows the server actually pushes tools asynchronously via notification, not in response to client request

Steps to reproduce

  1. Start OpenClaw MCP server: openclaw mcp serve --token-file <token>
  2. Connect a standard MCP client (e.g. Hermes Agent) configured to connect via stdio
  3. Client sends initialize → succeeds
  4. Client sends tools/list request (with id) → server responds with Method not found
  5. Server sends notifications/tools/list (notification, no id) → client receives tools but doesn't know which request it answers

Expected behavior

Server should respond to tools/list request (with matching id) with a tools/list response containing the list of tools.

Actual behavior

Server sends notifications/tools/list as a fire-and-forget notification with no id, which standard MCP clients cannot correlate to a pending request.

OpenClaw version

2026.4.15 (macOS)

Operating system

macOS (Darwin arm64)

Install method

No response

Model

minimax

Provider / routing chain

none

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

The OpenClaw MCP server should be modified to respond to the tools/list request with a matching id instead of sending it as a notification.

Guidance

  • Review the OpenClaw MCP server implementation to ensure it handles the tools/list request correctly and responds with a matching id.
  • Verify that the server is not mistakenly sending the tools/list response as a notification instead of a response to the client's request.
  • Check the MCP protocol specification to ensure compliance with the expected request/response behavior for the tools/list method.
  • Consider modifying the server to handle the tools/list request synchronously, ensuring that the response is sent with the correct id and not as a separate notification.

Example

No code snippet is provided as the issue does not include specific implementation details.

Notes

The provided information suggests a regression issue, and the fix likely involves modifying the OpenClaw MCP server implementation to correctly handle the tools/list request and response.

Recommendation

Apply workaround: Modify the OpenClaw MCP server to respond to the tools/list request with a matching id to ensure compliance with the MCP protocol specification and fix the regression issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Server should respond to tools/list request (with matching id) with a tools/list response containing the list of tools.

#GPU compatibility#latency issue#model loading#dependency error#configuration error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: MCP server: tools/list sent as notification instead of request/response (breaks Hermes Agent) [1 pull requests, 1 comments, 2 participants]