# ✨ Homey MCP Server | Megathread **URL:** \ **Category:** Official Announcements\ **Created:** [November 10, 2025, 4:32pm UTC](https://community.homey.app/t/homey-mcp-server-megathread/145181 "2025-11-10T16:32:36Z")\ **Posts on this page:** 9\ **Page:** 6
**Author:** ![Reto\_H](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/reto_h/32/102857_2.png) [@Reto\_H](https://community.homey.app/u/Reto_H)\ **Post date:** [September 4, 2026, 8:00am UTC](https://community.homey.app/t/homey-mcp-server-megathread/145181/104 "2026-09-04T08:00:26Z")
**Feature request: `resolution` parameter missing on Insights `getLogEntries` via MCP** I’m using the official Homey MCP server ([mcp.athom.com](http://mcp.athom.com)) with Claude to compare Insights boolean-log events (e.g. `alarm_offline`) against an external log. The MCP tool that wraps `ManagerInsights.getLogEntries` only accepts `logId` — it doesn’t expose the `resolution` query parameter that the underlying Web API supports (`last24Hours`, `last31Days`, `lastWeek`, `lastMonth`, `last2Years`, etc. — see [ManagerInsights docs](https://athombv.github.io/node-homey-api/HomeyAPIV3Cloud.ManagerInsights.html#getLogEntries)). Without it, repeated calls — even hours/days apart — return an identical, fixed ~50-entry window that never reaches “now”. So I can’t retrieve recent Insights events through the MCP tool at all, only whatever fixed historical slice it happens to return. Could the MCP server pass through a `resolution` (or `start`/`end`) parameter on the Insights log-entries tool, so agents can request a specific/recent time range? Happy to share more repro details if useful. ---
**Author:** ![B4ZZY](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/b4zzy/32/40486_2.png) [@B4ZZY](https://community.homey.app/u/B4ZZY)\ **Post date:** [September 5, 2026, 9:39pm UTC](https://community.homey.app/t/homey-mcp-server-megathread/145181/105 "2026-09-05T21:39:46Z")
Hi, I’m experiencing a persistent issue with the official Homey integration in ChatGPT when ChatGPT tries to retrieve the Flow Trigger Card catalogue. The Homey MCP call list\_flow\_trigger\_cards consistently fails with: INVALID\_ARGUMENT: Invalid structured content for tool list\_flow\_trigger\_cards The relevant validation error is: Expected string, received null at paths such as: cards[1353].args[0].values[0].title cards[1353].args[0].values[1].title cards[1384].args[0].values[0].title There are multiple affected cards/values. It appears that Homey returns one or more Flow Trigger Cards containing an argument with values[] entries where title is null, while the MCP schema requires: title: string Because validation fails on these entries, ChatGPT cannot retrieve **any of the Flow Trigger Card catalogue**. **Impact** Other Homey MCP functionality continues to work. ChatGPT can: - read devices and their capabilities - read existing Advanced Flows - inspect cards and connections inside an Advanced Flow - retrieve current sensor/device values However, because list\_flow\_trigger\_cards fails, ChatGPT cannot safely create/update Advanced Flows, as retrieving the Flow Card catalogue is required before performing these writes. **Troubleshooting already performed** - Restarted Homey - Disconnected and reconnected the ChatGPT/Homey integration - Deleted the Advanced Flow that initially appeared to be involved - Confirmed other Advanced Flows work normally in the Homey editor - Restarted several Homey apps individually, including: - Toros Vision - Better Logic Library - \< group \> - Smart Gateways - Solar Forecast - Enphase Controller - Tuya Cloud - Aqara The error persists. Restarting apps sometimes changes the numerical index of the affected cards (for example from ~1620 to ~1460 and later ~1353), presumably because the catalogue is rebuilt, but the same values[].title = null validation error remains. **Possible cause** This looks like a schema/serialization compatibility issue between Homey’s Flow Card data and the MCP response schema rather than an Advanced Flow problem itself. If null is valid/possible for a Flow Card value title on the Homey side, perhaps the MCP schema should accept: title: string | null Alternatively, the MCP server could normalize a null title to a string/fallback value or skip malformed entries instead of failing the complete Flow Trigger Card catalogue. It would also be very useful if the error exposed the **Flow Card ID / app ID** , rather than only its numerical position in the returned cards[] array. That would make identifying the originating app/card much easier. Is this a known issue with the official Homey MCP server / ChatGPT integration? I’m happy to provide additional diagnostics or test a fix. ---
**Author:** ![Welshsmarthome](https://avatars.discourse-cdn.com/v4/letter/w/df705f/32.png) [@Welshsmarthome](https://community.homey.app/u/Welshsmarthome)\ **Post date:** [September 6, 2026, 1:18am UTC](https://community.homey.app/t/homey-mcp-server-megathread/145181/106 "2026-09-06T01:18:41Z")
Im Also getting constant issues with Chat GPT. I have on several occassions reauthorised the connection. Chat GPT says it can read all my flows/devices etc and then starts to do what i ask. I then get connection times out, FORBIDDEN REQUEST, unable to connect. Basically its stopped working and i dont know why. Any suggestions? Thanks ---
**Author:** ![4x4\_Pete](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/4x4_pete/32/113286_2.png) [@4x4\_Pete](https://community.homey.app/u/4x4_Pete)\ **Post date:** [September 7, 2026, 4:19am UTC](https://community.homey.app/t/homey-mcp-server-megathread/145181/107 "2026-09-07T04:19:07Z")
Further up in this thread I already suggested an alternaitve. See: [✨ Homey MCP Server | Megathread - #98 by 4x4\_Pete](https://community.homey.app/t/homey-mcp-server-megathread/145181/98) I had also been asking Athom multiple times (aalso through a support ticket) to improve things and tried to get some general insights into Athom´s AI strategy from @Doekse … - But never got anywhere. So my recommendation is: When it comes to AI, forget about Athom. They are either not interested in this topic or have neither plans nor ideas. Find yourself a community alternative like the one suggested above. ---
**Author:** ![Dominik](https://avatars.discourse-cdn.com/v4/letter/d/ee7513/32.png) [@Dominik](https://community.homey.app/u/Dominik)\ **Post date:** [October 3, 2026, 4:09pm UTC](https://community.homey.app/t/homey-mcp-server-megathread/145181/108 "2026-10-03T16:09:52Z")
Can it also create Advanced Flows and move them into subfolders? The official MCP has low rate limits and unfortunately cannot do so in subfolders. ---
**Author:** ![4x4\_Pete](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/4x4_pete/32/113286_2.png) [@4x4\_Pete](https://community.homey.app/u/4x4_Pete)\ **Post date:** [October 4, 2026, 12:11pm UTC](https://community.homey.app/t/homey-mcp-server-megathread/145181/109 "2026-10-04T12:11:11Z")
Yes. - And much more. Check this > **[MCP AI Bridge | Homey](https://homey.app/en-us/app/community.mcp-ai-bridge/MCP-AI-Bridge/)** > > Your Homey Pro, powered by AI. And this > [@\[APP\]\[Pro\] MCP AI Bridge - Control Homey with any AI assistant (Claude, ChatGPT, Gemini, Copilot, Cursor or Mistral) via the Model Context Protocol](https://community.homey.app/t/app-pro-mcp-ai-bridge-control-homey-with-any-ai-assistant-claude-chatgpt-gemini-copilot-cursor-or-mistral-via-the-model-context-protocol/155930): > > robot MCP AI Bridge Control your Homey Pro with any AI assistant. Claude, ChatGPT, Gemini, Copilot, Cursor or Mistral. Just ask in plain language.speech_balloon Talk to your Homey like you talk to a person. “Turn off the lights.” “Is the door still open?” “Set the heating to 21.” “Build me a flow for the porch light at sunset.” MCP AI Bridge lets your favorite AI assistant control your Homey Pro directly, in any language you speak. It runs locally on your Homey, works with every major assi… ---
**Author:** ![Dominik](https://avatars.discourse-cdn.com/v4/letter/d/ee7513/32.png) [@Dominik](https://community.homey.app/u/Dominik)\ **Post date:** [October 6, 2026, 11:59pm UTC](https://community.homey.app/t/homey-mcp-server-megathread/145181/110 "2026-10-06T23:59:19Z")
@4x4_Pete Not working ☹. However, the app page stated that Homey Pro 2019 is supported. I asked about it in the app’s thread. Just in case anyone here wanted to give it a try. ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/c/e/ce1d8f074bc269b50d99e1e80c9bba5282dd6394.jpeg) ---
**Author:** ![weide43](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/weide43/32/79186_2.png) [@weide43](https://community.homey.app/u/weide43)\ **Post date:** [October 8, 2026, 9:03pm UTC](https://community.homey.app/t/homey-mcp-server-megathread/145181/111 "2026-10-08T21:03:37Z")
Hi Dominik, sorry about that, and thanks for the screenshots. The store page was wrong, not your Homey. The bridge only runs on Homey Pro (Early 2023), Homey Pro (2026), Homey Pro mini and Homey Self-Hosted Server. There is no setting to get around it on the 2019. You can safely uninstall it: it never started, so it left nothing behind. Why not the 2019? The bridge talks to Homey through the newer local Homey API. A Homey Pro (Early 2019) offers the older version of that API, which is what the “platformVersion 1” in the message means. Devices, flows and settings come back in a different shape there, so every one of the 173 tools would need its own translation layer. The flow tools differ the most, and those are exactly the ones you were after. On top of that I don’t own a 2019, so I couldn’t test any of it properly. I’d rather not ship something I can only guess works. The “Works on” list showed every model because the app only stated a firmware range, and your 2019 runs the same firmware numbers as the newer models. Version 4.20.3 fixes that: the store now only offers the app to the Homeys that can actually run it, so nobody else on a 2019 or older installs it for nothing. For what you were after, on a supported Homey: the bridge runs on the Homey itself, so the cloud limits of Athom’s own MCP do not apply, and it can create an Advanced Flow straight into a folder (and create the folder first if needed). Sadly that doesn’t help on the 2019. ---
**Author:** ![atwright147](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/atwright147/32/148194_2.png) [@atwright147](https://community.homey.app/u/atwright147)\ **Post date:** [October 17, 2026, 4:56pm UTC](https://community.homey.app/t/homey-mcp-server-megathread/145181/112 "2026-10-17T16:56:31Z")
**\*\*Homey MCP Server returns** `200` **for expired tokens, which breaks OAuth MCP clients\*\*** Hey, I’m using the official Homey MCP Server ([https://mcp.athom.com](https://mcp.athom.com)) from an OAuth-capable MCP client. After the access token expires (`~61 min`, the server issues `expires_in=3660`), every tool call fails with: `The access token provided has expired.` …and the client never recovers on its own, even though the **\*\*refresh token is still valid and works\*\***. The refresh endpoint returns a brand new token set when I call it manually, so the only problem is the error signalling. The server answers an expired/invalid token with **\*\*HTTP 200\*\*** and a JSON-RPC result containing `isError: true`, instead of **\*\*HTTP 401\*\*** : ```auto # expired token -> 200 (should be 401) 200 {"result":{"content":[{"type":"text","text":"The access token provided has expired."}],"isError":true},"jsonrpc":"2.0","id":1} # no auth header -> 401 (correct) 401 {"error":"Missing Authorization Header"} ``` Per `RFC 6750 §3.1` (and the MCP authorization spec), a protected resource that rejects a token should return `401 Unauthorized` with a `WWW-Authenticate: Bearer error="invalid_token"` header. That is the signal clients use to discard the token and refresh or re-authenticate. Because that signal is missing, any client that gates its OAuth refresh on a `401` keeps sending the dead token indefinitely – and still reports the server as connected, so the failure is silent to the user. This affects every conformant MCP client, not just one. **\*\*Request:\*\*** when the access token is expired or invalid, please respond with `401` + `WWW-Authenticate: Bearer error="invalid_token", resource_metadata="``https://mcp.athom.com/.well-known/oauth-protected-resource``"` instead of `200` + `isError`. This is likely the same root cause behind the ChatGPT connector reports where the connector shows a green checkmark but doesn’t work. I can provide the full probe output if useful. Thanks! [Previous page](https://community.homey.app/t/homey-mcp-server-megathread/145181.md?page=5)