Potential MCP response issue: Agent hangup on validation warning (category not found)

[matchy233]

I am experimenting with the ezbookkeeping MCP server using an upstream LLM agent (hermes). I noticed a behavior where the agent hangs indefinitely and eventually times out when a tool call validation fails.

Here is the scenario: the agent decided to pass an invalid category format (<category_name>:<secondary_category_name>) into a field that expects only the secondary category name.

Looking at both sides of the logs, it seems the server handles the validation but might be missing the JSON-RPC response step:

1. ezbookkeeping container logs:
   The server correctly identifies the issue and logs a warning:

ezbookkeeping-1  | 2026-06-08 18:43:29 [WARNING] [<hash>] [add_transaction.Handle] secondary category "<category_name>:<secondary_category_name>" not found for user "uid:<uid>"

2. Client-side (Hermes Agent) logs:
   After the warning above, nothing is received by the client, forcing it to wait until the 120-second timeout hits:

WARNING [...] run_agent: Tool mcp_ezbookkeeping_mcp_add_transaction returned error (120.00s): {"error": "MCP call failed: TimeoutError: MCP call timed out after 120.0s (configured timeout: 120.0s)"}

My Question:
Is ezbookkeeping supposed to return a standard MCP/JSON-RPC error packet back to stdout when this validation fails? Or could this be an unhandled edge case where the server logs the warning but leaves the transport connection open without replying?

Would love to hear if anyone else has encountered similar agent hangups on failed validation, or if the author could share some insights on the MCP error propagation design.

[mayswind]

The ezBookkeeping MCP tools return a JSON RPC error when a request fails. If you need to inspect the exact error details, you can capture the traffic with tcpdump or log the raw response at the reverse proxy layer.