[BUG] ha_get_overview, ha_get_state, ha_get_integration, ha_get_updates, ha_get_logs (logbook/error_log) all return "API error: 400" on HA 2026.4.3

[ellewiz]

💬 What Happened?

When using the Claude Code app on macOS Tahoe 26.4.1, when it starts up looking at Home Assistant, it gets several 400 errors. Restarting didn’t fix.

🔴 Failing Tools
All of the following fail unconditionally, with no parameters or with default parameters:

ha_get_overview (any detail_level)
ha_get_state (any entity ID, including confirmed-existing entities)
ha_get_integration (no arguments)
ha_get_updates (no arguments)
ha_get_logs with source=logbook
ha_get_logs with source=error_log
ha_search_entities — returns "All search methods failed" (may be a separate issue)

✅ Working Tools
These work correctly on the same instance:

ha_get_system_health
ha_get_device
ha_get_addon
ha_get_logs with source=system
ha_eval_template (confirmed returns correct values, e.g. entity state read via template)
ha_call_service, ha_bulk_control (not yet tested but unrelated surface)

📋 Error Response Example
json{
"success": false,
"error": {
"code": "VALIDATION_FAILED",
"message": "API error: 400 - ",
"suggestions": [
"Check Home Assistant connection",
"Verify API token permissions",
"Try test_connection first"
]
}
}
Note: the error body after 400 - is empty, suggesting HA is rejecting the request with no explanation.
🖥️ Environment

Home Assistant Core: 2026.4.3
Home Assistant OS: 17.2
ha-mcp App version: 7.3.0 (latest per App store — update_available: false)
Board: Odroid-N2 (aarch64)
Installation method: HAOS App (formerly Add-on)
MCP Server state: started, watchdog enabled
HA system log: No errors or warnings related to MCP at time of failure

🔄 Steps to Reproduce

Install ha-mcp 7.3.0 on Home Assistant 2026.4.3
Call ha_get_overview() with default parameters
Observe API error: 400 - with empty body

💡 Additional Context
The split between failing and working tools suggests the issue is specific to certain API surfaces — likely WebSocket commands or REST endpoints that changed in HA 2026.4.x. Since ha_eval_template (which calls POST /api/template) works but ha_get_state (which presumably calls GET /api/states/<entity_id> or equivalent WebSocket) does not, the problem may be isolated to specific endpoint patterns.
No HA system log errors were present. Restarting the App did not help.

📋 Copy-Paste from Conversation

## 🚨 Auto-Generated by `ha_report_issue` Tool

## 📋 Bug Description

Multiple core tools (`ha_get_overview`, `ha_get_state`, `ha_get_integration`, `ha_get_updates`, `ha_search_entities`, `ha_get_logs` with logbook/error_log sources) return `VALIDATION_FAILED / API error: 400 -` (empty body) consistently on HA 2026.4.3. Errors appear within 8 seconds of startup and persist through App restarts and full HA restarts.

## 🔄 Steps to Reproduce

1. Install ha-mcp 7.3.0 App on Home Assistant 2026.4.3 (HAOS)
2. Connect an AI client
3. Call `ha_get_overview()` with default parameters — returns 400
4. Same result for `ha_get_state`, `ha_get_integration`, `ha_get_updates`, `ha_get_logs` (logbook/error_log)

## ✅ Expected vs ❌ Actual Behavior

**Expected:** Tools return system data normally.

**Actual:** All calls above immediately fail with `"API error: 400 - "` (no body). Tools that DO work on the same instance: `ha_get_device`, `ha_get_addon`, `ha_get_system_health`, `ha_get_logs` (system source), `ha_eval_template`. The split suggests certain API surfaces or WebSocket commands changed in HA 2026.4.x.

Note: HA was fully restarted immediately before this session. The 400s were present from the very first tool call — this is not a stale connection issue.

---

## 🔧 Environment

- **ha-mcp Version:** 7.3.0
- **Installation Method:** HAOS App
- **Home Assistant Version:** 2026.4.3 / HAOS 17.2
- **Board:** Odroid-N2 (aarch64)
- **Connection Status:** Connection Error: API error: 400 -
- **Entity Count:** 0 (cannot be retrieved due to the error)

---

## 🚨 Error Messages


[2026-04-20T22:18:21] ha_get_state: {
  "success": false,
  "error": {
    "code": "VALIDATION_FAILED",
    "message": "API error: 400 - ",
    "suggestions": ["Check Home Assistant connection", ...]
  }
}

[2026-04-20T22:16:29] ha_get_overview: {
  "success": false,
  "error": {
    "code": "VALIDATION_FAILED",
    "message": "API error: 400 - "
  },
  "total_entities": 0
}

[2026-04-20T22:11:48] ha_get_updates: { same pattern }
[2026-04-20T22:11:39] ha_get_integration: { same pattern }


---

## 🚀 Startup Logs


+00.21s | WARNING | ha_mcp.server: Skills directory not found, skipping skill registration
+07.85s | ERROR | ha_mcp.tools.smart_search: Error in smart_entity_search: API error: 400 -
+07.85s | WARNING | ha_mcp.tools.tools_search: Fuzzy search failed, trying exact match: API error: 400 -
+07.85s | WARNING | ha_mcp.tools.tools_search: Exact match failed, trying partial results: API error: 400 -
+07.85s | ERROR | ha_mcp.tools.tools_search: All search methods failed: API error: 400 -
+14.15s | ERROR | ha_mcp.tools.smart_search: Error in get_system_overview: API error: 400 -
+16.45s | ERROR | ha_mcp.tools.smart_search: Error in get_system_overview: API error: 400 -
+28.25s | ERROR | ha_mcp.tools.tools_integrations: Failed to get integrations: API error: 400 -


---

## 💡 Additional Context

- `ha_eval_template` works correctly (confirmed entity states via template)
- `ha_get_device` works correctly (confirmed entity list via device registry)
- HA system log shows no errors or warnings related to MCP
- App was restarted during troubleshooting — no change
- Full HA restart prior to session — no change
- Workaround: using `ha_eval_template` to read entity states and `ha_get_device` with integration filter to enumerate entities

[github-actions[bot]]

❌ Analysis failed

An error occurred:

YOLO mode is enabled. All tool calls will be automatically approved.
YOLO mode is enabled. All tool calls will be automatically approved.
Error executing tool read_file: File not found.
{
  "session_id": "219c2a69-d5cc-4712-961d-61392db7d295",
  "error": {
    "type": "FatalTurnLimitedError",
    "message": "Reached max session turns for this session. Increase the number of turns by specifying maxSessionTurns in settings.json.",
    "code": 53
  }
}[ERROR] {
  "session_id": "219c2a69-d5cc-4712-961d-61392db7d295",
  "error": {
    "type": "FatalTurnLimitedError",
    "message": "Reached max session turns for this session. Increase the number of turns by specifying maxSessionTurns in settings.json.",
    "code": 53
  }
}

Please check the workflow logs.

[kingpanther13]

What is your connection method? Local, cloudflare, nabu casa, etc?

[kingpanther13]

Mac has been known to have finnicky connection issues with ha-mcp, so knowing if you're connecting locally or via http is important to try to pinpoint the issue. I'd recommend try to set up an http/remote connection via cloudflare or nabu casa if you haven't already to see if that might help, or to try doing it locally if you're currently doing it remotely.

[ellewiz]

Thanks, it’s Nabu Casa. I had tried adding the Nabu Casa add-on before, but it didn’t seem to work. Or it may have been an ID-10-T error. I’ll check that out.

[github-actions[bot]]

❌ Analysis failed

An error occurred:

YOLO mode is enabled. All tool calls will be automatically approved.
YOLO mode is enabled. All tool calls will be automatically approved.
{
  "session_id": "2190f195-14ed-4cca-9f8b-1e4a7be94f52",
  "error": {
    "type": "FatalTurnLimitedError",
    "message": "Reached max session turns for this session. Increase the number of turns by specifying maxSessionTurns in settings.json.",
    "code": 53
  }
}[ERROR] {
  "session_id": "2190f195-14ed-4cca-9f8b-1e4a7be94f52",
  "error": {
    "type": "FatalTurnLimitedError",
    "message": "Reached max session turns for this session. Increase the number of turns by specifying maxSessionTurns in settings.json.",
    "code": 53
  }
}

Please check the workflow logs.

[kingpanther13]

So Claude is using the URL that the nabu casa webhook app provided in MCP/connector settings? Try to access the URL directly in your browser and tell me what it says please.

Also ake sure that you restarted HA after setting up the nabu casa webhook app since it has to install a custom component to work.

[ellewiz]

Thanks, it’s Nabu Casa. I had tried adding the Nabu Casa add-on before, but it didn’t seem to work. Or it may have been an ID-10-T error. I’ll check that out.

My bad. I'm currently connecting locally (http://192.168.1.47:8123/), not via the Nabu Casa webhook. I tried the webhook proxy approach previously but it failed with 'Couldn't reach the MCP server.' I do not currently have the webhook proxy app installed, which also explains why there's no custom_components folder in my config.

Should I reinstall the webhook proxy app and try again? If so, any tips on what might have gone wrong the first time?

[github-actions[bot]]

I've checked other AsyncClient initializations and confirmed that none of them incorrectly include the Content-Type header for GET requests. The only place needing a fix is src/ha_mcp/client/rest_client.py. I'm now ready to finalize the report.

🔍 Analysis

The "API error: 400" issues you're seeing on Home Assistant 2026.4.3 are likely caused by a change in how Home Assistant (or its underlying web server) handles HTTP headers. Specifically, the ha-mcp REST client is sending a Content-Type: application/json header with every request, including GET requests which have no body.

While previously tolerated, stricter security or protocol enforcement in recent Home Assistant versions often rejects GET requests that claim to have a JSON body but are empty. This explains why tools using WebSocket (like ha_get_device and ha_eval_template) still work perfectly, while core discovery tools using REST GET (like ha_get_state and ha_get_overview) fail unconditionally.

This is a known pattern when newer web servers (like aiohttp used by HA) become more compliant with HTTP specifications.

🛠️ Suggested Steps

1. Verify WebSocket connectivity: Run ha_get_system_health or ha_get_device. If these work, your connection and token are valid, confirming the issue is specific to the REST API implementation.
2. Wait for a patch: A fix is required in the ha-mcp codebase to remove the unnecessary header from GET requests.
3. Manual Workaround (Advanced): If you are comfortable editing the python package directly in your installation, you can remove the "Content-Type": "application/json" line from the src/ha_mcp/client/rest_client.py file in the HomeAssistantClient.__init__ method.

📊 Technical Analysis (for maintainers)

Root Cause

The HomeAssistantClient in src/ha_mcp/client/rest_client.py initializes its httpx.AsyncClient with a default Content-Type: application/json header. This header is then included in all requests, including GET calls to /api/states, /api/logbook, and /api/config/config_entries/entry.

Home Assistant 2026.4.3 appears to have updated its web server (likely aiohttp) to a version that strictly enforces that Content-Type should only be present if a request body is provided. Since GET requests in ha-mcp do not provide a body, the server returns a 400 Bad Request.

Affected Code

• src/ha_mcp/client/rest_client.py:82 - Global header initialization includes Content-Type.
• src/ha_mcp/tools/tools_search.py - Uses get_states() and get_entity_state() which use the affected REST GET calls.
• src/ha_mcp/tools/tools_updates.py - Uses get_states() for listing updates.
• src/ha_mcp/tools/tools_integrations.py - Uses REST GET for listing config entries.

Proposed Fix

Remove the global Content-Type header. httpx automatically adds the correct Content-Type: application/json header when the json= parameter is used in self.httpx_client.request(), so POST/PUT/PATCH calls will remain unaffected.

--- a/src/ha_mcp/client/rest_client.py
+++ b/src/ha_mcp/client/rest_client.py
@@ -79,7 +79,6 @@
         self.httpx_client = httpx.AsyncClient(
             base_url=f"{self.base_url}/api",
             headers={
                 "Authorization": f"Bearer {self.token}",
-                "Content-Type": "application/json",
             },
             timeout=httpx.Timeout(self.timeout),
         )

Related Issues/PRs

• No similar issues found in recent history for this specific version, but similar "400 on GET" issues are common in other HA-adjacent projects when strict header enforcement is enabled.

---

🤖 Automated analysis by Issue Bot

[kingpanther13]

I think that's your problem then, there has been a plethora of issues with MAC connecting locally. See https://homeassistant-ai.github.io/ha-mcp/faq/#macos-connection

If you want to use nabu casa addon it will allow you to connect remotely (like via claude.ai or the claude mobile app and etc) and will probably get around the problem too, but it isn't necessary.

Let me know if any of that stuff fixes your issue! If not then we may need to do more digging.

[ellewiz]

I tried the manual fix you suggested (removing the Content-Type: application/json header from the GET requests in rest_client.py). To find the file, I had to install ha-mcp permanently first using uv tool install ha-mcp, since uvx runs in a temporary environment and doesn't leave the source files anywhere editable. Once I found the file and commented out that line, I updated my Claude config to point to the installed binary instead of uvx, and restarted.

The fix didn't seem to work. REST GET tools like ha_get_state and ha_get_overview are still returning 400. WebSocket-based tools still work fine.

One thing I noticed while looking at the code: rest_client.py sets the httpx base URL to {base_url}/api (no trailing slash), and then all the endpoint paths start with a leading / (like /states/{entity_id}). From what I understand, newer versions of httpx treat a leading slash as an absolute path, which would drop the /api part and send requests to http://192.168.1.47:8123/states/sun.sun instead of http://192.168.1.47:8123/api/states/sun.sun. That would explain the 400s even without the Content-Type issue. Not sure if this is related or a separate bug, but wanted to flag it.

Also I'm connecting locally via http://192.168.1.47:8123, not through Nabu Casa or Cloudflare. I have Nabu Casa set up but the MCP connector right now uses the local IP directly.

[kingpanther13]

Disregard what the github actions bot says, it usually doesn't give very useful advice. Installing it via uv tool is using a completely different path and method than the addon and is independent from the addon. You might have conflicting setups right now, as in you might have more than one running at once.

If you're using the addon you should see a url like http://:9583/private_(KEY HERE) in the addon logs. That is the url you should give your AI to connect to your MCP server, with port 9583. If you're going to do it the other way, then you'd use port 8123 and I think you need a long lived access token as well.

[kingpanther13]

@ellewiz were you able to get it working? I'm going thru the backlog of issues to see what still needs to be addressed or what can be closed.

[kingpanther13]

Converting to discussion; if you still are having trouble then let me know here and I can help troubleshoot, or you can open a new issue