#mcp tool use issue with fastmail server

1 messages · Page 1 of 1 (latest)

whole talon
#

I'm using the fastmail public MCP server. Added it via oauth successfully. Did a test run last night and the agent pulled down emails. Running hermes "mcp test fastmail" returns status connected and all 8 tools discovered. But this morning my agent couldn't use the tools due to some type of schema error on the data returned. Agent analysis is attached. My MCP block is very basic. Just server name and oauth.

I'm not a developer. Using Hermes Agent as a homelab helper and assistant. I can post logs or configs or whatever, though. Thanks.

Screenshot_20260514-201839.png
#

I'm also on the latest Hermes version

#

I had the agent grab relevant logs

Screenshot_20260514-202825.png
amber nebula
#

hermes mcp test fastmail passing means the OAuth connection works and Hermes can discover the Fastmail tools. The failure in your screenshot is later, when an individual tool returns data.

The relevant part is:

CallToolResult -> structuredContent -> Input should be a valid dictionary ... input_type=list

That points to the Fastmail MCP server returning structuredContent as a top-level list for tools like list_folders / search_email, while the MCP Python SDK model Hermes uses expects structuredContent to be an object/dictionary or null. If that validation fails inside the MCP SDK, Hermes may not get a chance to process or normalize the result afterward.

So this is probably not an OAuth/config issue on your side. The connection can be healthy while specific tool calls still fail because of the returned result shape.

Please post a normal Hermes debug share from right after reproducing it:

hermes debug share

The most useful part will be the exact traceback around the Fastmail MCP tool call, especially the lines around CallToolResult, structuredContent, and the tool name that failed.

For now I do not have a clean config workaround to give you. If the logs match the screenshot, this likely needs either a Fastmail MCP server result-shape fix.

whole talon
#

Great. Thanks. Will send logs shortly

turbid moon
whole talon
#

Just sitting down at my Thinkpad. Will have logs posted in a sec

whole talon
#

So....this is embarrassing. A bit like going to the mechanic when your car is making a sound, but it won't make the sound when you get to the shop 😅

Screenshot_20260515-083635.png
#

The debug logs have zero info except for reporting a successful retrieval. I'm sorry. Didn't mean to waste anyone's time. These are deterministic tool calls, so they SHOULD work the same every time, right? I have a few MCP servers setup and this has been the only one to give me intermittent trouble. I'm going to try another couple of tests

#

Just ran an inbox sweep and asked agent to summarize. Flawless and fast. Again, my apologies. The client-side SDK is static, so it shouldn't produce intermittent issues, right? Maybe Fastmail was doing something on the server side yesterday? I've also seen an error in the log every one hour saying "MCP server fastmail keepalive failed, triggering reconnect:session terminated". Then some reconnection messages. Is there some extra config I should be doing to manage this connection? Maybe a timeout setting?

amber nebula
#

No worries, intermittent MCP/server behavior is exactly the kind of thing that disappears when you go to collect logs.

The hourly line:

MCP server fastmail keepalive failed, triggering reconnect: session terminated

is not automatically a problem by itself. Hermes keeps MCP sessions alive in the background; when a remote MCP session expires or the connection goes stale, it logs that warning and reconnects. If the next Fastmail tool call works, that reconnect path did its job.

There are two MCP timeout knobs you can set per server if actual calls are timing out:

timeout controls tool-call timeout.

connect_timeout controls initial connection/reconnect timeout.

Example shape:

mcp_servers:
fastmail:
...
timeout: 180
connect_timeout: 60

There is not currently a separate user config knob for the keepalive interval itself.

For the original structuredContent validation error, the useful thing is still a debug share captured immediately after it happens again. If it was Fastmail returning a different result shape for a while, normal successful logs afterward will not preserve the traceback we need.

whole talon
#

I really appreciate the assist, man. This community has been so welcoming and helpful. If I run into the issue again, I will capture the logs immediately and start a fresh thread. Cheers