Bug: MCP tools not available in ACP sessions — enabled_toolsets hardcoded to ["hermes-acp"]

Summary

MCP server tools (registered via mcp_servers in config.yaml or provided by ACP clients) are correctly discovered and registered at startup, but are not available to the LLM in ACP sessions. The tools appear in agent logs as registered, but the LLM never receives them in its tool schema.

This is a regression — MCP tools worked correctly in earlier versions before the ACP session toolset was hardcoded.

Environment

• hermes-agent version: 0.11.0 (v2026.4.23-26-g6fdbf2f2)
• Platform: WSL2 (Ubuntu) on Windows
• ACP client: VS Code (Continue) + custom ACP orchestrator (Aether Agents Olympus MCP)

Reproduction

1. Configure an MCP server in ~/.hermes/config.yaml:

   mcp_servers:
     olympus:
       command: /path/to/venv/bin/python
       args: [-m, olympus.server]
       env:
         AETHER_HOME: /path/to/Aether-Agents/home
         PYTHONPATH: /path/to/Aether-Agents/src
       enabled: true

2. Start Hermes with hermes acp or connect via an ACP client.

3. Observe agent log — MCP tools are registered:

   MCP server 'olympus' (stdio): registered 6 tool(s): mcp_olympus_talk_to, mcp_olympus_discover, ...

4. Send a prompt asking to use an MCP tool (e.g., mcp_olympus_talk_to).

5. Result: The LLM does not recognize mcp_olympus_talk_to as a callable tool. The tool schema sent to the model does not include any mcp_* entries.

Root Cause

There are 5 interconnected gaps that prevent MCP tools from reaching the LLM:

Gap 1: ACP session hardcodes enabled_toolsets

File: acp_adapter/session.py — line 542

kwargs = {
    "platform": "acp",
    "enabled_toolsets": ["hermes-acp"],          # ← hardcoded, no MCP toolsets
    "quiet_mode": True,
    "session_id": session_id,
    "model": model or default_model,
}

The ACP agent is created with only the "hermes-acp" toolset. This static toolset definition does not include dynamically-registered MCP tools.

Gap 2: hermes-acp toolset is static, no MCP references

File: toolsets.py — lines 241-258

"hermes-acp": {
    "description": "Editor integration (VS Code, Zed, JetBrains) — ...",
    "tools": [
        "web_search", "web_extract", "terminal", "process",
        "read_file", "write_file", "patch", "search_files",
        ...
        "execute_code", "delegate_task",
    ],
    "includes": []              # ← no reference to MCP toolsets
},

MCP tools are registered dynamically into mcp-{server_name} toolsets at runtime, but hermes-acp has no mechanism to pull them in.

Gap 3: Tool surface refresh after MCP registration discards MCP tools

File: acp_adapter/server.py — lines 284-296

enabled_toolsets = getattr(state.agent, "enabled_toolsets", None) or ["hermes-acp"]  # ← still no MCP
disabled_toolsets = getattr(state.agent, "disabled_toolsets", None)
state.agent.tools = get_tool_definitions(
    enabled_toolsets=enabled_toolsets,   # ← only "hermes-acp"
    disabled_toolsets=disabled_toolsets,
    quiet_mode=True,
)

After registering MCP servers (line 270-287), the code refreshes the tool surface. But it rebuilds the tool list from enabled_toolsets=["hermes-acp"], which doesn't include MCP toolsets. The newly-registered MCP tools are discarded.

Gap 4: get_tool_definitions only resolves static toolsets

File: model_tools.py — lines 222-234

if enabled_toolsets is not None:
    for toolset_name in enabled_toolsets:
        if validate_toolset(toolset_name):
            resolved = resolve_toolset(toolset_name)
            tools_to_include.update(resolved)

When enabled_toolsets=["hermes-acp"], this only resolves the static tools in that toolset. Dynamically-registered MCP toolsets (mcp-olympus, etc.) are never iterated because they're not in the enabled_toolsets list.

Gap 5: Delegation inherits the gap

File: tools/delegate_tool.py

Lines 60-67 — _SUBAGENT_TOOLSETS is computed at module import time:

_SUBAGENT_TOOLSETS = sorted(
    name
    for name, defn in TOOLSETS.items()       # ← only static TOOLSETS, no dynamic MCP
    if name not in _EXCLUDED_TOOLSET_NAMES
    and not name.startswith("hermes-")
    and not all(t in DELEGATE_BLOCKED_TOOLS for t in defn.get("tools", []))
)

Lines 847 — children inherit parent's toolsets:

child_toolsets = _strip_blocked_tools(parent_enabled)  # ← inherits ["hermes-acp"]

The _preserve_parent_mcp_toolsets mechanism (from recent fix 7d8b2eee) only works if the parent has MCP toolsets in its enabled_toolsets. Since ACP sessions don't, children never get MCP tools either.

Impact

• MCP tools are invisible to ACP sessions — this affects all ACP clients (VS Code, Zed, JetBrains, and custom orchestrators like Aether Agents' Olympus).
• Delegation from ACP context also loses MCP tools — sub-agents spawned via delegate_task from an ACP session don't inherit MCP tools.
• Existing MCP inheritance fix (7d8b2eee) doesn't cover this case — it only works when the parent already has MCP toolsets in enabled_toolsets.

Suggested Fix

The core issue is that MCP toolsets (mcp-{server}) are dynamic and need to be added to enabled_toolsets at runtime. Three possible approaches:

Option A: Dynamic toolset expansion in ACP session creation

In acp_adapter/session.py, after creating the agent, discover registered MCP toolsets and add them:

from tools.registry import registry

mcp_toolsets = [ts for ts in registry.get_registered_toolset_names() if ts.startswith("mcp-")]
kwargs["enabled_toolsets"] = ["hermes-acp"] + mcp_toolsets

Also apply the same expansion in acp_adapter/server.py:290 after MCP server registration.

Option B: Config-based toolset includes

Add an includes mechanism to toolset definitions that references dynamic toolset patterns:

# In config.yaml or toolsets.py
hermes-acp:
  includes: ["mcp-*"]    # auto-include all MCP toolsets

Then resolve_toolset("hermes-acp") would expand mcp-* against the registry at runtime.

Option C: Auto-include MCP toolsets in all toolset resolution

In model_tools.py:get_tool_definitions, after resolving explicit toolsets, always append MCP toolset tools when no explicit toolset filter excludes them, or when the calling context supports MCP (e.g., main agent loop, ACP sessions).

Option A is the smallest change and can be a targeted fix. Option B is a more general mechanism that benefits all toolsets. Option C is the most robust but requires careful design to avoid leaking MCP tools to contexts that shouldn't have them.

Happy to submit a PR for Option A as a quick fix, with Option B as a follow-up.