Summary

For every connected MCP server, hermes-agent registers four "utility" tool schemas (mcp_<server>_list_resources, mcp_<server>_read_resource, mcp_<server>_list_prompts, mcp_<server>_get_prompt) regardless of whether the server actually advertises prompts or resources capabilities in its initialize response. Calling those stubs against a tools-only server returns JSON-RPC -32601 Method not found, which leads the agent to incorrectly conclude the MCP server is broken or disconnected.

Reproduction

1. Configure any MCP server that advertises only tools capability — e.g. Context7 (@upstash/context7-mcp):

   mcp_servers:
     context7:
       command: npx
       args: ["-y", "@upstash/context7-mcp"]

2. Probe Context7 directly to confirm its capabilities (initialize → result.capabilities):

   {"tools": {"listChanged": true}}

   No prompts / resources keys, and the server returns -32601 for prompts/list, prompts/get, resources/list, resources/read.
3. After hermes-agent connects to it, the LLM is offered six tool names instead of two: mcp_context7_resolve_library_id, mcp_context7_query_docs, plus mcp_context7_list_prompts, mcp_context7_get_prompt, mcp_context7_list_resources, mcp_context7_read_resource.
4. When the model invokes any of the four stubs, it gets Method not found and reports the server as dead, even though resolve_library_id / query_docs work fine.

Root cause

tools/mcp_tool.py:_select_utility_schemas (around lines 2614–2641) gates the four utility schemas on:

required_method = _UTILITY_CAPABILITY_METHODS[handler_key]
if not hasattr(server.session, required_method):
    ...
    continue

server.session is an mcp.ClientSession, which always has the four method attributes (list_resources, read_resource, list_prompts, get_prompt) defined on the class — independent of what the remote server actually supports. The check therefore never trips, and all four stubs are always registered.

The InitializeResult returned from await session.initialize() (called at lines 1118, 1219, 1242) is the source of truth — its .capabilities.resources / .capabilities.prompts are non-None only when the server advertises support — but hermes-agent currently discards this object instead of inspecting it.

Expected behavior

Per the MCP spec, capability sub-objects in the initialize response indicate which request types the server actually implements. Utility schemas should be gated on those flags:

Impact

• Each tools-only MCP server adds 4 dead schemas to the LLM's tool list — context bloat plus wasted tokens.
• The LLM repeatedly attempts the dead stubs (especially the discovery-style list_* ones) and surfaces "MCP server is broken" reports to the user even when the working tools succeed.
• Confuses model planning: it thinks the server is half-broken and avoids the two real tools.

Patch

PR will follow this issue. Approach:

1. Add initialize_result to MCPServerTask.__slots__ and initialise to None in __init__.
2. In all three await session.initialize() call sites (lines 1118, 1219, 1242), capture the return value into self.initialize_result.
3. In _select_utility_schemas, inspect server.initialize_result.capabilities.{resources,prompts} and skip the corresponding stubs when they are None. Keep the previous hasattr(server.session, ...) check as a fallback for the rare case where initialize_result is missing (older test fixtures), so behaviour is unchanged for those.

Environment

• hermes-agent: main (commit at the time of report: 62a5d7207 "feat(plugins): bundle hermes-achievements + scan full session history (#17754)", 2026-04-30)
• Python 3.13 venv on Debian 13 (ARM64)
• MCP server tested: @upstash/context7-mcp v2.2.3 (Context7 per serverInfo.name)