[APP][Pro] MCP AI Bridge - Control Homey with any AI assistant (Claude, ChatGPT, Gemini, Copilot or Cursor) via the Model Context Protocol

[weide43]

MCP AI Bridge

Control your Homey Pro with any AI assistant. Claude, ChatGPT, Gemini, Copilot or Cursor. Just ask in plain language.

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 assistant through the open MCP standard, and you stay in full control. Over a hundred actions, your own custom AI commands in the flow editor, no extra cloud.

---

Links

• App Store: MCP AI Bridge | Homey
• Test version: MCP AI Bridge | Homey
• Support and feedback: right here in this topic

---

What it is

Your Homey already runs your home. Now you can just talk to it.

MCP AI Bridge turns your Homey Pro into something any modern AI assistant can talk to directly. No middleman cloud, no separate integration for each assistant. The app runs a local Model Context Protocol (MCP) server on your Homey, and any MCP-compatible AI connects straight to it over your own network.

Once it is connected you stop digging through menus and just say what you want. The assistant reads the state of your home and changes it for you, in plain language, in any language you speak to it.

MCP is the open standard that Anthropic, OpenAI and Google are building their assistants around. Because the bridge speaks that standard, it is not tied to one vendor. The same Homey endpoint works in Claude, ChatGPT, Gemini, Cursor, Windsurf and more.

Why this MCP app

There is more than one way to reach Homey from the outside. Here is why this one is the one to install.

• Works with every assistant, not one. It speaks the open Model Context Protocol, so the same endpoint works in Claude, ChatGPT, Gemini, Cursor, Windsurf and any other MCP client. No lock-in.
• Covers the whole Homey, not just switches. Over a hundred actions across devices, zones, flows, advanced flows, logic, energy, insights, alarms, notifications, apps and system.
• You build your own AI commands. Expose custom tools to the assistant in the flow editor and send real answers back using live device values. The AI asks, your flow replies.
• Local first. The AI connects to your Homey’s own address on your network. Nothing is routed through an extra cloud, and your home data is not handed to a third party.
• Real security, not an afterthought. Scoped keys per assistant, an access switch to pause or limit everything in one click, a tool blocklist, rate limits, and a security log with source IPs.
• You can see what it does. Every action is auditable, with a diagnostics tab, broken flow detection and a live connections view. Argument values are never logged.

Open standard, full coverage, your own commands, local, and locked down by choice.

Just ask

Lights and climate

• “Turn off all the lights downstairs.”
• “Dim the living room to 30 percent.”
• “Set the bedroom to 19 degrees tonight.”

Check on things

• “Is the garage door still open?”
• “Which devices have a low battery?”
• “Anything offline right now?”

Energy and history

• “What used the most power this week?”
• “Average power use over the last 7 days?”

Automations

• “Make a flow that turns on the porch light at sunset.”
• “Set the heating to 21 tomorrow at 8 in the morning.”
• “Watch the front door and tell me when it opens.”

Housekeeping

• “Did anything fail in the last hour?”
• “Restart the Hue app.”
• “Are any of my flows broken?”

You talk normally. The assistant works out which devices and capabilities you mean and does it.

What it can reach

The bridge exposes your whole Homey through one clean interface:

• Devices and every capability they have
• Zones and rooms
• Basic flows and Advanced Flows, including creating and editing them
• Logic variables
• Alarms and the alarm clock
• Energy, live and historical
• Insights, with one-number summaries
• Notifications
• Installed apps, including enable, disable, restart and settings
• Users and presence
• System info, memory, storage and reboot

Over a hundred actions in total, so the assistant can both understand the state of your home and act on it.

How it works

Under the hood it is a standard MCP server speaking JSON-RPC over local HTTP, using the StreamableHTTP transport from the MCP spec. Because it follows the open standard, the same endpoint works across clients.

Prefer to script against it? There is a plain REST shortcut at POST /tools/{name} and a full OpenAPI 3.1 spec at GET /openapi.json, so it drops right into tools like n8n, Make, or your own code.

Everything stays on your network. The AI connects to your Homey’s local address. No extra cloud in the path.

How to connect your AI assistant

Every assistant connects to the same address:

http://YOUR-HOMEY-IP:52199/mcp

You can find the exact URL in the app: open MCP AI Bridge → Settings → Connection. The connect wizard fills in your Homey’s IP for you and gives you a ready-to-paste snippet for the main clients. The examples below use <homey-ip> as the Homey IP, replace it with yours.

Local vs cloud. Desktop and CLI assistants (Claude Desktop, Claude Code, Cursor, Windsurf, VS Code Copilot, Gemini CLI) run on your own machine, so they reach your Homey directly on the local network. Cloud assistants (ChatGPT connectors, Claude on the web or phone) run on the provider’s servers and cannot see a private IP like 192.168.x.x. To use those you need to make the server reachable from the internet (a reverse proxy or tunnel) and you should set an API key first. For most people a local client is the easiest start.

Using an API key. If you set an API key in Settings → Security, add an Authorization: Bearer YOUR_KEY header to the config (shown per client below). Without a key, the server is open on your local network only.

---

Claude Desktop

1. Open Claude Desktop and go to Settings → Developer → Edit Config.
2. Add the server to claude_desktop_config.json:

{
  "mcpServers": {
    "homey": {
      "type": "http",
      "url": "http://<homey-ip>:52199/mcp"
    }
  }
}

3. Save and restart Claude Desktop. You will see the Homey tools appear.

With an API key:

{
  "mcpServers": {
    "homey": {
      "type": "http",
      "url": "http://<homey-ip>:52199/mcp",
      "headers": { "Authorization": "Bearer YOUR_KEY" }
    }
  }
}

---

Claude Code (CLI)

One command:

claude mcp add --transport http homey http://<homey-ip>:52199/mcp

With an API key:

claude mcp add --transport http homey http://<homey-ip>:52199/mcp \
  --header "Authorization: Bearer YOUR_KEY"

Then restart Claude Code. Check it with claude mcp list.

---

Cursor

1. Open Settings → MCP → Add new server, or edit ~/.cursor/mcp.json (global) or .cursor/mcp.json (per project).
2. Add:

{
  "mcpServers": {
    "homey": {
      "url": "http://<homey-ip>:52199/mcp"
    }
  }
}

3. Restart Cursor. Enable the server in the MCP settings if it is not on by default.

---

Windsurf

1. Open Settings → Cascade → MCP servers, or edit ~/.codeium/windsurf/mcp_config.json.
2. Add:

{
  "mcpServers": {
    "homey": {
      "serverUrl": "http://<homey-ip>:52199/mcp"
    }
  }
}

3. Restart Windsurf and refresh the MCP server list.

---

GitHub Copilot (VS Code)

1. Create .vscode/mcp.json in your workspace (or add it to your user settings).
2. Add the server. Note that VS Code uses servers, not mcpServers:

{
  "servers": {
    "homey": {
      "type": "http",
      "url": "http://<homey-ip>:52199/mcp"
    }
  }
}

3. Open the Copilot Chat panel, switch to Agent mode, and the Homey tools become available. Click the tools icon to enable them.

---

Gemini

A quick heads up: the regular Gemini app (gemini.google.com and the phone app) cannot add a custom MCP server. The consumer app has no custom connector feature yet. MCP works with the Gemini CLI (below), with Gemini Enterprise as a custom data store, or through the Gemini API in your own code. For most people the CLI is the way.

Gemini (CLI)

1. Edit ~/.gemini/settings.json.
2. Add:

{
  "mcpServers": {
    "homey": {
      "httpUrl": "http://<homey-ip>:52199/mcp"
    }
  }
}

3. Restart the Gemini CLI. Run /mcp to confirm the server and its tools are listed.

---

ChatGPT (custom connector)

ChatGPT runs in the cloud, so this needs a server URL that OpenAI can reach. Expose the bridge through a reverse proxy or tunnel first, and set an API key in the app.

1. In ChatGPT, go to Settings → Connectors (Plus, Pro, Team or Enterprise). For tool use you may need to turn on Developer mode under Advanced.
2. Add a custom connector and paste your public MCP URL, for example https://your-domain.example/mcp.
3. Add the API key as the connector’s authentication header.
4. Save, then enable the connector in a chat.

---

Claude on the web or phone (custom connector)

Same idea as ChatGPT: the web and mobile apps are cloud based, so they need an internet-reachable URL.

1. Go to Settings → Connectors → Add custom connector.
2. Paste your public MCP URL and the API key.
3. Save and enable it in a conversation.

---

Fallback: mcp-remote

A few clients only support command-based (stdio) MCP servers. For those, bridge to the HTTP server with mcp-remote (needs Node.js installed):

{
  "mcpServers": {
    "homey": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "http://<homey-ip>:52199/mcp", "--allow-http"]
    }
  }
}

With an API key, append the header:

"args": ["-y", "mcp-remote", "http://<homey-ip>:52199/mcp", "--allow-http", "--header", "Authorization: Bearer YOUR_KEY"]

---

Quick check

Once connected, try a simple read first:

“List my zones.”

If that works, you are good to go. Ask it to turn something off, check a sensor, or build a flow. If a client cannot connect, confirm you are on the same network as your Homey, that the IP and port match the Connection tab, and that any API key matches.

Build your own AI commands with flow cards

This is where it gets fun. The app ships flow cards so your AI and your flows work together both ways, not just the AI reaching into Homey.

Give the AI its own command

• Trigger: “An AI agent calls a custom tool.” The assistant calls a tool you define, your flow runs whatever logic you want, and you reply with “Return a response to the AI agent” using live device values and flow tokens. The AI asks, your flow answers.

See and react to what the AI does

• Trigger: “The AI controls a device.” Fires whenever the assistant changes a device, with the name, capability and value as tokens. Perfect for a quick “AI just set the thermostat to 19” notification.

Catch problems early

• Trigger: “A flow becomes broken.” Know the moment an automation breaks, for example after you removed a device.
• Trigger: “An AI tool call fails.” Know when the assistant hits an error.
• Trigger: “A security event occurs.” Get the source IP and reason when someone is denied or tries to connect without a key.
• Condition: “There is a broken flow.” Use it in a daily check flow.

Give the AI memory from your flows

• Action: “Remember a value for the AI.” A flow writes context the assistant can recall later.
• Condition: “A remembered value is.” A flow reads that memory back.

You are not limited to the built in tools. You design your own AI commands in the flow editor.

Real world examples

A custom AI tool that answers with live data

1. Trigger: An AI agent calls a custom tool.
2. Action: Return a response to the AI agent, using a flow token like the current power usage.

Now you can ask “how much power am I using right now” and the assistant gets the real number back from your flow.

Let the AI know nobody is home

1. When everyone leaves, your presence flow runs “Remember a value for the AI”, key nobody_home, value true.
2. Later you ask the assistant to do something, and it can check that context first.

Get told when a flow breaks

1. Trigger: A flow becomes broken.
2. Action: send yourself a notification with the flow name.

You stay in control

The bridge is local first and locked down by choice:

• Access mode switch. Flip the whole bridge to full, write only, read only, or off in one click. Pause the AI or keep it read only while you are away.
• Scoped API keys. Give each assistant its own key with read, write or full rights.
• Tool blocklist. Disable specific risky tools entirely, like deleting devices or rebooting Homey, even for a full key.
• IP whitelist and rate limits, with a separate tighter limit for destructive actions.
• Security log. Every denied or unauthorized attempt is recorded with its source IP, right in the settings.
• Active connections view. See who is connected, from which IP, and for how long.

By default, with nothing configured, it stays open on your trusted local network, the same as before. The controls are there when you want them.

See what is happening

The settings page is organized into tabs: Status, Connection, Security, Memory, Schedules, Events, Diagnostics and About. Browse what the AI remembers, what it has scheduled, which devices it watches, recent activity, broken flows, and the security log. Everything the assistant does is auditable, and argument values are never logged, so nothing sensitive leaks into the history.

Works with

Claude (Desktop, Code, mobile), ChatGPT, Google Gemini, GitHub Copilot, Cursor, Windsurf, and any other MCP client. The text to speech and LED ring tools work on Homey Pro (Early 2019) and older models.

Get it

1. Install from the App Store: MCP AI Bridge | Homey
2. Or try the latest test build: MCP AI Bridge | Homey
3. Open the app settings and run the connect wizard.
4. Paste the config into your assistant and start talking to your home.

Questions, ideas and bug reports are very welcome in this topic. If the app makes your home a little easier to live with, a reply or a thumbs up helps other people find it.

---

Changelog

v2.2.7

• Fixed: Creating and editing Advanced Flows. The AI could only make empty Advanced Flows because the nodes and connections were not converted to the format Homey stores internally, so they were dropped. The bridge now translates the full node graph (triggers, conditions, actions, delay, any/all, with their connections) into Homey’s card structure. It can also accept the native structure from advanced_flows_get for round-trip edits.
• Fixed: Triggering a flow (basic or advanced) no longer fails with a scopes error; it now uses the token session.
• Fixed: Reading and deleting notifications, and restarting / enabling / disabling / updating apps, no longer fail with a scopes error. They fall back to the token session when the app’s own API lacks the permission.
• Added: A “start” node type so the AI can build Advanced Flows that are manually triggerable.

v2.2.6

• Added: Masked preview of the saved Personal Access Token on the Connection tab, so you can see which token is active (full token is never shown).

v2.2.5

• Fixed: Token-save feedback no longer flips a successful save into a misleading “saving failed” when the flow check is slow.
• Changed: Immediate confirmation on save, then “flow writing active” or the exact rejection error.

v2.2.4

• Fixed: Saving the token on the Homey web app (my.homey.app). The settings page used a method the current web SDK no longer provides, and the fallback was blocked by CORS in the sandboxed settings frame.
• Fixed: Status counts, connections, and the Security / Memory / Schedules / Events / Diagnostics tabs load in the browser again, not only in the mobile app.

v2.2.3

• Fixed: Settings page loaded an old cached version of itself after an update. Scripts are now versioned so every update loads the fresh page.

v2.2.2

• Changed: The save now reads the live flow-write status back from the app instead of trusting the write, and reports the real result.

v2.2.1

• Fixed: Saving the token works on every Homey; flow writing activates the moment you save, with no app restart.
• Added: Real token validation, so a wrong or wrong-scope token is caught instead of looking saved while writes fail.

v2.1.9

• Added: The Status tab lists recent connections (most AI clients connect statelessly and hold no live session).

v2.1.8

• Changed: The Bug report clearly states the flow-write status (active token session, the real error, or no token set).

v2.1.7

• Flow create and edit require a Personal Access Token with the Flow scope. The app’s own API can only read flows, not write them (which caused “Missing Scopes”), and no app permission grants flow-write access.
• The token session now uses the same local address the app API uses, so it initializes correctly on Homey Pro 2026 firmware.
• If no token is set, you now get a clear message explaining what to do instead of a cryptic “Missing Scopes” error. The Bug report tab shows whether the token session is active.

v2.1.0

• New flow cards: AI controls a device, a flow becomes broken, an AI tool fails, a security event occurs, remember a value for the AI, check a remembered value, and is any flow broken.
• New Bug report tab in the app settings that builds a diagnostic report with no tokens, plus a system_create_bug_report tool so you can ask your AI to create one straight from the chat. Both copies stay identical.
• Better compatibility with strict clients like Gemini CLI: list results are objects, safe serialization, protocol-version echo, a session id for POST-based clients (ChatGPT, Cursor, Windsurf), and read-only/destructive tool hints.
• Flow create and edit no longer need a Personal Access Token; they use the app’s own API on modern firmware.
• Fixed the app settings API so all management tabs load their data, and fixed the Generate report button.
• Security and reliability fixes from a deep audit: destructive tools are blocked until you set an API key (with an in-app warning), the energy price tools use the correct Homey API, webhooks are no longer revealed to the AI, a memory namespace limit, a scheduler cancel fix, and corrections to the Claude Code mcp-remote command and the insights time range.

2.0.0

• AI memory: the assistant remembers facts across chats, like zone IDs and your preferences.
• Devices and insight: device health scan, find devices by capability, batch control, and insight summaries as a single number.
• Scheduling: have the AI run actions later, once or repeating, all visible and cancelable.
• Events and webhooks: watch a device for changes and forward them to approved webhook URLs.
• Automation templates with a dry run preview, plus a flow validator.
• New flow cards: AI controls a device, a flow becomes broken, an AI tool fails, a security event occurs, remember a value, check a remembered value, and is any flow broken.
• Security: access mode switch (full/write/read/off), scoped API keys, tool blocklist, destructive rate limit, and a security log with source IPs.
• Rebuilt settings page with tabs for Status, Connection, Security, Memory, Schedules, Events, Diagnostics and About, fully in English and Dutch.
• Diagnostics: activity log, broken flow detection, and active connections view.

1.4.x

• Added Gemini to the supported assistants. Settings page translated to NL and EN. Tool notes for speech and LED ring on supported models. Security and bug fixes, simplified store description.

1.3.0

• Renamed to MCP AI Bridge. Added flow cards to build custom AI tools with a real response callback, optional API key auth, REST shortcuts, and an OpenAPI spec.

1.0.0

• First release: control Homey Pro from any AI agent over the Model Context Protocol.

[Mark1541]

Where can I add Gemini ?

[weide43]

@Mark1541
A quick heads up: the regular Gemini app (gemini.google.com and the phone app) cannot add a custom MCP server. The consumer app has no custom connector feature yet. MCP works with the Gemini CLI (below), with Gemini Enterprise as a custom data store, or through the Gemini API in your own code. For most people the CLI is the way.

[Luke_Vredeveld]

I have everything in working order with Gemini-cli on MacBook and the MCP-server app. I have made a personal acces token to be able to write flows to my homey. But writing doesn’t work. Gemini helped to troubleshoot but without success. I asked Gemini to make a bug report for me:

 Bug Report: Flow Write Operations Unavailable (even with Full Access PAT)

  Device: Homey Pro (2026)
  Firmware: v13.2.1
  App Version: MCP AI Bridge (latest)
  Issue: The bridge consistently reports that flow write operations are unavailable, despite using a Personal Advisory Token (PAT) with all possible scopes/permissions enabled.

  Steps taken to resolve:
   1. Created multiple new PAT tokens with "Full Access" (all scopes checked).
   2. Removed and re-added the token in the app configuration.
   3. Restarted the MCP AI Bridge app multiple times (with 10+ seconds wait time).
   4. Tested with both Basic Flows (flows_create) and Advanced Flows (advanced_flows_create).
   5. Verified the user account is the Owner/Admin of the Homey.

  Error Message received via MCP:
  Error executing tool "flows_create": Flow schrijfoperaties zijn niet beschikbaar. Controleer of het PAT token correct is ingesteld en herstart de app (Homey → MCP AI Bridge →
  Uitschakelen/Inschakelen).

  Additional Technical Observation:
  List-based tools (like flows_list, devices_list, zones_list) are also failing with a Zod-like type validation error:
  Invalid input: expected record, received array at path: ["structuredContent"]. This suggests a potential issue in how the bridge serializes data or how the schema is defined for the MCP output.

  Expected behavior:
  With a valid Admin PAT token, the bridge should allow the creation and modification of flows and correctly parse list-responses as records.

[weide43]

@Luke_Vredeveld

Thanks for the detailed report, it was really helpful. Both problems are fixed in v2.1.0 (now in test/review).

The list-tool error. The error expected record, received array at path ["structuredContent"] was a real bug on our side. The list tools (devices, flows, zones, etc.) returned a bare JSON array, and strict MCP clients like Gemini CLI reject that during structured-content validation, they expect an object. List results are now returned as an object, so reads work again in Gemini CLI and other strict clients.

The flow-write problem. This was not your token, and not the scopes. On recent firmware the bridge’s separate token-based session fails to initialize, which blocked all flow writes no matter how many PATs you created or which scopes you checked. Flow create and edit now go through the app’s own API (which already has the required permission), so a Personal Access Token is no longer needed at all. If the token session still cannot start, the real error is now surfaced instead of the generic message.

Update to v2.1.0 and it should just work.

While I was at it I also hardened the server for all AI clients: safe serialization (no more crashes on circular or empty results), protocol-version echoing, a session id for POST-based clients like ChatGPT and Cursor, and read-only/destructive hints on every tool.

One more thing that should make future reports easier: there is now a Bug report tab in the app settings that builds a diagnostic report with no tokens included, and you can also just ask your AI assistant to “create a bug report”. It builds the same report, saves it in the app, and returns it in the chat, so the exact diagnostics (app version, firmware, flow-write status, recent errors) are one click away.

Changelog:

v2.1.2

• New flow cards: AI controls a device, a flow becomes broken, an AI tool fails, a security event occurs, remember a value for the AI, check a remembered value, and is any flow broken.
• New Bug report tab in the app settings that builds a diagnostic report with no tokens, plus a system_create_bug_report tool so you can ask your AI to create one straight from the chat. Both copies stay identical.
• Better compatibility with strict clients like Gemini CLI: list results are objects, safe serialization, protocol-version echo, a session id for POST-based clients (ChatGPT, Cursor, Windsurf), and read-only/destructive tool hints.
• Flow create and edit no longer need a Personal Access Token; they use the app’s own API on modern firmware.
• Fixed the app settings API so all management tabs load their data, and fixed the Generate report button.
• Security and reliability fixes from a deep audit: destructive tools are blocked until you set an API key (with an in-app warning), the energy price tools use the correct Homey API, webhooks are no longer revealed to the AI, a memory namespace limit, a scheduler cancel fix, and corrections to the Claude Code mcp-remote command and the insights time range.

[Luke_Vredeveld]

While the latest update fixed the reading of large lists (no more array errors!), I am completely blocked from creating flows.

I get ‘Missing Scopes’ every time. I’ve tried a clean reinstall and followed the release notes regarding the PAT being unnecessary, but it still won’t let me write. It seems like the new firmware

might have different requirements for the app’s internal API session.

Bug Report: Persistent "Missing Scopes" on Flow Write Operations (Homey Pro 2026)

  Environment:
   * Device: Homey Pro (2026)
   * Firmware: v13.2.1
   * App: MCP AI Bridge (latest version, post-array-fix)

  The Issue:
  Despite the latest update (which successfully fixed the "expected record, received array" error for read operations), the bridge is still unable to perform any flow write operations (flows_create or
  advanced_flows_create). Every attempt returns a "Missing Scopes" error.

  Summary of Findings:
   * Read Operations: WORKING. Tools like zones_list and devices_get_all_states return full, valid JSON structures.
   * Write Operations: FAILING. Any attempt to create a flow results in Error executing tool "flows_create": Missing Scopes.
   * Internal API Route: According to the release notes, the app should now use its own internal API permissions for flows, making a PAT unnecessary. However, on this firmware (v13.2.1), this internal
     session initialization still seems to be blocked or unauthorized.

  Steps Taken (All failed to resolve the issue):
   1. Created multiple new PAT tokens with "Full Access".
   2. Verified the user is the Homey Owner/Admin.
   3. Restarted the MCP AI Bridge app multiple times.
   4. Clean Reinstall: Fully uninstalled the app and reinstalled it from the App Store.
   5. Attempted write operations both with and without a PAT configured.

  Technical Observation:
  The bridge successfully authenticates for the general Web API (reading), but the authorization specifically for the homey.flow and homey.advancedflow scopes seems to be lost or not correctly requested
  when the bridge attempts to use the app's internal API on the newest Homey Pro 2026 firmware.

  Expected Behavior:
  The app should be able to create or edit flows using its internal permissions (as stated in the release notes) without requiring an external PAT, or it should correctly pass the PAT's scopes if one is
  provided.

[weide43]

@Luke_Vredeveld
Thanks again, this was a different root cause than the array fix, and your “Missing Scopes” observation pointed straight at it.

I verified it against the Homey API specification:

• Reading flows (getFlows, getFlow, getAdvancedFlows) needs the homey.flow.readonly scope.
• Creating or editing flows (createFlow, createAdvancedFlow, updateFlow, deleteFlow) needs the full homey.flow scope.

The app’s own API token (from the homey:manager:api permission) only carries the readonly scope, so reads work but writes return “Missing Scopes”. There is no app permission that grants the homey.flow write scope, so an app simply cannot create flows with its own token. My earlier “PAT no longer required” note was wrong, and the app-API fallback is exactly what produced the error.

On top of that, the token session that does have the right scope was connecting to a hand-built local address that fails on the Homey Pro 2026 firmware. It now uses the same local URL the app’s own API uses (homey.api.getLocalUrl()), so the token session initializes correctly.

What to do in v2.1.7 (now in test/review):

1. Keep your Full-Access PAT in the app settings (Flow scope is the part that matters).
2. Restart the app once (Homey, MCP AI Bridge, disable/enable).
3. Open the Bug report tab and check the “Flow write” line: it should say “PAT session active”.
4. flows_create and advanced_flows_create should then work.

If it still does not show an active session, generate a bug report and look at the flow_api_info patError field, it will contain the real error from the token session so we can pin down whether it is the address, the token scope, or something else. Thanks for the thorough testing.

v2.1.7

• Flow create and edit require a Personal Access Token with the Flow scope. The app’s own API can only read flows, not write them (which caused “Missing Scopes”), and no app permission grants flow-write access.
• The token session now uses the same local address the app API uses, so it initializes correctly on Homey Pro 2026 firmware.
• If no token is set, you now get a clear message explaining what to do instead of a cryptic “Missing Scopes” error. The Bug report tab shows whether the token session is active.

[Luke_Vredeveld]

@weide43

3. Open the Bug report tab and check the “Flow write” line: it should say “PAT session active”.

I’ve updated the app, but there is no such information in the bug report tab visible

[weide43]

(post deleted by author)

[weide43]

@Luke_Vredeveld
Thanks again for reporting this and for sticking with it. Here is a summary of everything that changed since 2.1.7, ending in the real fix.

• 2.1.8 The Bug report now clearly states whether flow writing is enabled (active token session, the real error, or no token set) instead of a misleading label.
• 2.1.9 The Status tab also lists recent connections, since most AI clients connect with stateless requests that hold no live session.
• 2.2.0 to 2.2.3 First round of fixes for saving the Personal Access Token: route the save through a reliable path, rebuild and verify the flow session the moment you save (no restart), validate the token (a session is created even for a wrong token, so I added a real check), and version the settings scripts so an update always loads the fresh page instead of a cached one.
• 2.2.4 (the actual root cause) On the Homey web app (my.homey.app) the settings page runs in a sandboxed frame, and the current web SDK there no longer exposes the methods the page was using. The fallback network request was blocked by the browser (CORS, null origin with credentials). That is why saving the token and loading the tabs silently failed in the browser, while the mobile app kept working. The page now talks to the app over the channel the web SDK does support, so saving and all tabs work in the browser again.
• 2.2.5 Reliable feedback: once the token is stored you get an immediate confirmation, and a slow flow check can no longer flip a successful save back into a false “saving failed”. It still shows flow writing active, or the exact error if the token was rejected.
• 2.2.6 The Connection tab now shows a masked preview of the saved token, so you can see which one is active.

What to do: update to 2.2.6. If your settings page was already open, do a hard refresh (Ctrl+Shift+R) so it loads the new version. Then on the Connection tab paste a Personal Access Token created at my.homey.app, Settings, API, with the Flow scope, and save. The page will confirm whether flow writing is active. Reading flows and everything else works without a token; only flow create/edit needs that Flow-scoped token.

[Luke_Vredeveld]

Hi there, still checking out the server-app, awesome development!

I can conform the write acces works. But now, the AI can only create empty advanced flows. Once again, I asked Gemini CLI to make me a bug report.

 Bug Report: advanced_flows_create silently drops nodes/edges (while flows_create works perfectly)

  Environment:
   * Device: Homey Pro (2026)
   * Firmware: v13.2.1
   * App: MCP AI Bridge (latest version, PAT session active & working)

  The Issue:
  Following the latest updates, write permissions via the PAT session are successfully established. Standard flows (flows_create) are now created flawlessly, including all nested triggers, conditions,
  and actions. 
  However, when using advanced_flows_create, the bridge successfully creates the flow object (it appears in the Homey app with the correct name and ID), but the flow canvas is completely empty. Homey
  silently drops or rejects the entire nodes and edges payload provided in the API call.

  Steps Taken & Observations:
   1. Basic Flows (Success): Called flows_create with a cron trigger and a HomeyScript action. Result: Flow created perfectly with all cards intact.
   2. Advanced Flows (Failure): Called advanced_flows_create with a minimal payload (1 trigger node, 1 action node, 1 edge).
       * The MCP tool returns {"success": true, "flow_id": "..."}.
       * Upon fetching the created flow via advanced_flows_get, the cards object is completely empty: { ..., "cards": {} }.
   3. Formatting Attempts: Tried alternative formatting strategies for the nodes (using strict UUIDs for node IDs, verifying ownerUri and cardId mapping), but all resulted in the same silent dropping of
      cards by the Homey validation engine.

  Conclusion & Request:
  The bridge's connection and token authorization are now rock solid. The issue lies entirely in the schema translation/validation for the advanced_flows_create payload. It appears the Homey Pro 2026
  firmware requires a highly specific internal formatting or nesting structure for Advanced Flow nodes/edges that differs from how the bridge currently serializes them. 

  Could you investigate the exact payload structure expected by the homey.advancedflow endpoint on firmware v13.2+?

[weide43]

@Luke_Vredeveld

Fixed in v2.2.7. Thanks for the excellent bug report, your diagnosis was spot on.

You were exactly right: the bridge was passing the nodes/edges payload straight through, but Homey’s advancedflow endpoint does not use nodes/edges. It stores an advanced flow as a cards map (the same structure advanced_flows_get returns), where each card carries its ownerUri, id, type, args, and its connections as output arrays on the source card. Because the payload had no cards, Homey accepted the flow but dropped the whole graph, hence the empty canvas.

What changed in 2.2.7:

• advanced_flows_create and advanced_flows_update now translate the node graph into Homey’s card structure: ownerUri is derived from the full card id, ports map to the right outputs (output to outputSuccess, true/false to outputTrue/outputFalse, error to outputError), any/all join nodes get their input arrays, and delay nodes keep their delay args.
• You can also pass a native cards object (exactly what advanced_flows_get returns) for a clean round-trip: get an example, tweak it, write it back.
• A start node type is now supported, so the AI can build advanced flows that are manually triggerable.
• Bonus, found while testing: triggering a flow (basic or advanced) used to fail with “Missing Scopes” because it went through the app’s own API token. It now uses the token session, like the writes. Same fix applied to reading/deleting notifications and restarting apps.

Tips for building one with the AI:

• For trigger/condition/action nodes, set uri to the FULL flowcard id, for example homey:manager:notifications:create_notification or homey:device:<deviceId>:onoff_true. The bridge derives ownerUri.
• Edges: sourcePort is output for triggers/actions, or true/false for conditions.
• Add a start node (no uri) if you want to trigger the flow on demand.

Verified end to end on a Homey Pro: the AI created an advanced flow (start node to a notification action), it triggered, and the notification showed up. Let me know how it works on your side.

[Luke_Vredeveld]

Can confirm it can write advanced flows now! Great job done