[BUG] ha_config_set_automation tool missing from MCP toolset

[aakashparekh-777]

💬 What Happened?

1 ## 🚨 Auto-Generated by ha_report_issue Tool
2
3 ha-mcp Version: 7.4.0
4 Home Assistant Version: 2026.4.4
5 Platform: Windows 11 (ARM64)
6
7 ## 📋 Bug Description
8 The tool ha_config_set_automation is missing from the available toolset despite being defined in the system prompt. Attempts to use
automation.create via ha_call_service also failed.
9
10 ## ✅ Expected vs ❌ Actual Behavior
11 Expected: Ability to create or update automations using ha_config_set_automation.
12 Actual: Tool reported as "not found" by the MCP server.

📋 Copy-Paste from Conversation

1 ## 🚨 Auto-Generated by `ha_report_issue` Tool
    2
    3 ha-mcp Version: 7.4.0
    4 Home Assistant Version: 2026.4.4
    5 Platform: Windows 11 (ARM64)
    6
    7 ## 📋 Bug Description
    8 The tool `ha_config_set_automation` is missing from the available toolset despite being defined in the system prompt. Attempts to use
      `automation.create` via `ha_call_service` also failed.
    9
   10 ## ✅ Expected vs ❌ Actual Behavior
   11 **Expected:** Ability to create or update automations using `ha_config_set_automation`.
   12 **Actual:** Tool reported as "not found" by the MCP server.

[github-actions[bot]]

❌ Evaluation failed

An error occurred:

YOLO mode is enabled. All tool calls will be automatically approved.
Approval mode overridden to "default" because the current folder is not trusted.
YOLO mode is enabled. All tool calls will be automatically approved.
Approval mode overridden to "default" because the current folder is not trusted.
�[31mGemini CLI is not running in a trusted directory. To proceed, either use `--skip-trust`, set the `GEMINI_CLI_TRUST_WORKSPACE=true` environment variable, or trust this directory in interactive mode. For more details, see https://geminicli.com/docs/cli/trusted-folders/#headless-and-automated-environments�[0m

Please check the workflow logs.

[Patch76]

Hi @aakashparekh-777, thanks for filing this — and especially for using ha_report_issue.

---

On the report itself. I checked master:

• ha_config_set_automation exists and is registered (src/ha_mcp/tools/tools_config_automations.py:307). Auto-discovery in src/ha_mcp/tools/registry.py picks it up under the default ENABLED_TOOL_MODULES=all. I don't see a code path that silently drops it.
• automation.create is not a real Home Assistant service. HA's automation services are reload/toggle/trigger; create/update goes through the REST/WS config API at /api/config/automation/config/{id}, which is exactly what ha_config_set_automation wraps. So that fallback was always going to fail — it's a separate misconception, not corroboration.

Most likely causes (need your input to narrow down):

1. ENABLED_TOOL_MODULES filtered to a custom list that omits tools_config_automations (src/ha_mcp/config.py:80-83).
2. ENABLE_TOOL_SEARCH=true (src/ha_mcp/config.py:103-106) — replaces the full catalog with a BM25 search tool and three call proxies, so individual tools don't appear by name. An agent introspecting its toolset would report the tool as "missing" but it's still callable via the write-proxy.
3. Client-side tool-count truncation (some clients cap around 100; ha-mcp registers in that ballpark).
4. Version drift — running build differs from the 7.4.0 you expect.

Could you share:

1. The values of ENABLED_TOOL_MODULES, ENABLE_TOOL_SEARCH, and ENABLE_SKILLS_AS_TOOLS in your config (.env, addon options, or environment)?
2. Which MCP client and version (Claude Desktop / Cursor / VS Code / Copilot CLI / something else)?
3. The list of ha_config_* tools the client actually exposes (Claude Desktop's hammer icon, Copilot CLI's /mcp, VS Code's MCP panel, etc.)?
4. The first ~20 lines of ha-mcp's startup log — whether tools_config_automations shows up in the registered-modules line is the deciding signal.

Priority: medium-leaning-low pending repro. If it turns into cause #3, the relevant existing work is #798 and #1062.

Label: needs-info applied.

If you trace it to a concrete cause and want to write the fix yourself, that's very welcome — external PRs are prioritized here. Workflow is in AGENTS.md and CONTRIBUTING.md; the relevant code is in src/ha_mcp/tools/registry.py and src/ha_mcp/config.py.

Could you also retitle from [BUG] to something easier to find for others hitting the same combination.

[kingpanther13]

Toolsearch should be pinning that tool if it's enabled, so the most important question is What AI are you using? Claude has been doing some weird stuff with deferred tools lately but it should still be able to find it eventually.

[meow4agreencard]

Just came across the same problem with gemini-cli. Funny enough, it worked fine last night. I was running the 7.3.0 version of the HACS integration. After updating to 7.4.1 the issue got resolved.

[kingpanther13]

@meow4agreencard did you have the toolsearch toggle enabled?

[meow4agreencard]

@meow4agreencard did you have the toolsearch toggle enabled?

Yes.

    "ENABLE_SKILLS": "true",
    "ENABLE_SKILLS_AS_TOOLS": "true",
    "HAMCP_ENABLE_FILESYSTEM_TOOLS": "true",
    "HAMCP_ENABLE_CUSTOM_COMPONENT_INTEGRATION": "true",
    "ENABLE_TOOL_SEARCH": "true"

[kingpanther13]

I just confirmed that config set automation is pinned by default when toolsearch is enabled, it's very strange that you weren't able to see it. I wonder if maybe gemini got confused and tried to call it via toolsearch even though it was available to be used directly, or maybe something else was going on. Either way I'm glad it resolved on your side. I will say in my personal experience Gemini has always been flaky with just about everything.

[kingpanther13]

Converted to discussion, if we get more info and can reproduce the problem we can open a new issue, but I think this was a transient issue as nobody else seems to be complaining of it right now