Yes so i need to ask anything on antigravity?
It cant be downloaded on mobile?
no, antigravity lives in the cli on your laptop. Gemini cannot be used with the gemini-app. That’s why I build the telegram bot for all-day tasks
@Luke_Vredeveld
Thanks a lot, Luke, this is genuinely useful. You’re right on both points: antigravity-cli moved the config to ~/.gemini/antigravity-cli/mcp_config.json and expects serverUrl instead of httpUrl, so httpUrl silently fails to discover the server.
I’ve updated the connection guide to cover both setups, the older gemini-cli (~/.gemini/settings.json with httpUrl) and the new antigravity-cli (mcp_config.json with serverUrl), including the variant with an API key header. It’s shipped in v2.2.9. The bridge itself needed no changes, it’s plain MCP over HTTP, so the same endpoint keeps working across every client.
Thanks again for smoothing the path for other Gemini users! 
Do you need a paid subscription?
I wanted to test with claude before i pay for it but i get an error message when opening claude after i edited the json.
Just wondering if it is something on my side or a bug
@Cris_Rijsdijk
No paid plan needed to test. On Claude’s free tier you can add one custom connector via the UI — Settings → Connectors → Add custom connector and paste the bridge URL. That skips the JSON entirely and is the easiest way to try it out.
The error you get when Claude opens is on Claude’s side, not the bridge: editing claude_desktop_config.json by hand is easy to get slightly wrong, and a single trailing comma or missing bracket makes Claude Desktop fail to start. Run the file through jsonlint.com to catch it.
If you do want the local config route, remember the bridge speaks MCP over HTTP, so the entry has to go through mcp-remote rather than pointing at the URL directly:
{
"mcpServers": {
"homey": {
"command": "npx",
"args": ["mcp-remote", "https://your-bridge-url/mcp"]
}
}
}
Let me know which client you’re on and paste the exact error if it persists, happy to help narrow it down.
Thank you, it is working now, i did not use the mcp-remote so that was the problem.
Building flows now 
@Luke_Vredeveld New version update:
2.3.0
- Efficiency and tokens: tool responses are sent compactly and the full-home overview is about 93 percent smaller, so the assistant gives the same answers for a fraction of the tokens.
- Compact by default: device state tools return compact values, with a detailed option when you want the full metadata.
- Control by name: act on a device by its name instead of its ID, with a new resolve tool that maps a name to its ID.
- Faster reads: a short cache groups the rapid lookups the assistant makes and clears the moment anything changes, so it stays both quick and accurate.
- MCP resources and prompts: clients can fetch your devices, zones and variables as cacheable resources, plus ready-made prompts for a home overview, what needs attention, an energy report and building an advanced flow.
- Connect tab: ready-to-copy setup for Gemini, GitHub Copilot, ChatGPT and Claude web, on top of Claude Desktop, Claude Code and Cursor.
Update 2.4.0 is live
Hi all, a big one this time, with two themes: reaching more of your Homey, and modernizing under the hood. Nothing to configure, it just works after updating.
Moods, weather and rooms
- Moods/scenes: just say “activate the Movie mood”. The assistant can list, activate, and even create or edit your scenes.
- Weather: ask for the current weather or the hourly forecast for your home.
- Zone activity: “is anyone in the living room?” now has a real answer, based on each room’s activity state.
Realtime and a dashboard
- Realtime events: device changes are picked up the instant they happen (where your Homey supports it), with polling as a safety net.
- AI dashboard: ask the assistant to “build me a dashboard” and it generates a live overview, served at
http://<homey-ip>:52199/dashboardand viewable in any browser on your network. It is a static snapshot with a strict no-scripts security policy, and your IP whitelist still applies.
Modern MCP standard
The bridge now speaks the latest Model Context Protocol: structured tool output, resource links (so large data is fetched only when needed), resource subscriptions with change notifications, and your devices, zones, variables and moods exposed as resources. It runs more smoothly and uses fewer tokens with strict clients.
Reliability and a full audit
I ran a complete code audit for this release:
- Every tool call is now validated against its schema, so a mistake gets a clear message instead of a confusing failure.
- Long lists tell the assistant when results were truncated.
- Fixes: full notification text (no more 100-character cut-off), correct insight data, and stricter input checks.
- Hardening for long uptime (no leaked timers or listeners) and tighter security on the dashboard.
Dashboard
Ask your AI to build you a live dashboard of your home, for example “make a dashboard with the lights and temperature per room, and an energy overview”. The assistant gathers the data and generates it, and the app serves it at http://<homey-ip>:52199/dashboard, viewable in any browser on your network. It is a static snapshot with a strict no-scripts security policy, and your IP whitelist still applies. The app’s settings have a dedicated Dashboard tab with the URL, an Open button and example prompts.
As always, questions, ideas and bug reports are very welcome here. If the app makes your home a little easier to live with, a reply or a like helps others find it.
v2.5.0, a full interactive AI dashboard 
This release turns the dashboard from a read-only page into a complete, interactive home dashboard that any AI (or the app itself) can build for you.
What’s new
- One-tap auto-generate (no AI needed): open the app settings → Dashboard → “Generate automatically”. The app reads your devices and builds a clean, tabbed dashboard grouped by what you have: lights per room, climate, energy, media and security.
- Real control: tap a tile to toggle a light, long-press to dim, set a thermostat (temperature + mode), play/pause a speaker, lock the door, or run a one-tap scene like “all off”. Everything stays in sync with the live state.
- Live status Overview: see at a glance who is home, how many lights are on, what is playing, what needs attention, the date/time, weather and the live energy flow.
- Fully built-out tabs: all lights per room, every temperature sensor, energy with water and gas for today/yesterday/month/year plus your savings, all speakers with track info and prev/play/next, and a complete security overview.
- Multiple dashboards: keep several side by side (each at
/dashboard/<name>) and pick which one opens by default. - Works with any AI: there’s a structured config mode, so Claude, ChatGPT, Gemini etc. all produce the same clean dashboard. Just ask, or copy the ready-made prompt from the settings.
Safe by design: dashboard controls use a separate dashboard token, are limited to the devices the dashboard actually shows, and can never delete or reboot anything. Whoever can open the dashboard on your network can operate the devices it shows, nothing more. You can regenerate the token any time from the settings.
Open it in any browser on your network at http://<your-homey-ip>:52199/dashboard.
Feedback welcome!
Dear Danny,
First of all, thank you for the excellent MCP AI Bridge app. I’m using it together with Homey and GitHub Copilot in VS Code, and it works very well.
I was wondering whether there are any plans to support mobile AI clients, specifically GitHub Copilot on iPhone and iPad. It would be great if users could leverage their existing GitHub Copilot subscription on mobile devices to interact with Homey tools via MCP, without being dependent on a desktop environment.
I assume this may partly depend on the capabilities that Microsoft and GitHub make available, but I’d be interested to hear your thoughts on this and whether you see opportunities for such functionality in a future release.
Kind regards,
Robin Gosselaar
Hi Danny,
Thanks for the quick img-src fix in 2.5.3 — snapshots are now working directly in the dashboard through a regular image tag. Awesome!
One possible next step: would it be feasible to add media-src http: https: to the CSP as well?
Reolink cameras can serve an FLV stream (video/x-flv) over HTTP, which fits perfectly in a standard video element. At the moment, however, it appears to be blocked by default-src 'none'.
With media-src http: https: enabled, it should be possible to display a true live stream without requiring a proxy or custom JavaScript. Users could simply point a video element to the camera’s FLV stream in HTML mode.
My reasoning is similar to the img-src change: local network cameras are trusted sources for people building a home automation dashboard, and this would open up some great possibilities for lightweight live camera integration.
Curious to hear what you think.
Thanks again for the great work on MCP AI Bridge!
Kind regards,
Robin Gosselaar
PS: Having native support for live camera streams would make Dashboard Studio even more attractive as a complete Homey dashboard solution, especially for users with Reolink cameras.
How will it look dashboard can someone post a screenshot?
@Robin_Gosselaar
Hi Robin, done, media-src is in 2.5.4 (media-src 'self' data: blob: https: http:). Once the build is approved, a <video>/<audio> tag pointing at an http/https stream works directly on a custom HTML dashboard.
One honest caveat I mentioned earlier: browsers don’t natively decode FLV (video/x-flv) in a <video> element, so a raw Reolink FLV stream still won’t play with media-src alone, it needs flv.js (MSE), which also fetches over connect-src. I deliberately left connect-src locked to 'self' since that’s the sensitive direction. So this release enables everything the browser plays natively (HLS in Safari/iOS, MP4) plus MJPEG snapshots via the <img> route from 2.5.3. If you want the flv.js path specifically, let me know and I’ll look at a scoped connect-src option.
Thanks! 2.5.4 is great progress. Quick follow-up: I’m using a Reolink E340 which only serves FLV and RTSP natively (no HLS). The FLV path with flv.js would be ideal. Would you consider a scoped connect-src that allows connections to local network ranges (like 192.168.0.0/16) only? That way the MSE/flv.js fetch stays local and doesn’t open up external connections. Otherwise I’ll look at go2rtc as a RTSP→MJPEG proxy which already works with the current img-src.
@Robin_Gosselaar
Good news, Robin: 2.6.0 adds opt-in remote access over OAuth. The bridge is now a proper remote MCP server, so cloud connector apps (Claude, ChatGPT) can register, you approve once with your API key, and control Homey from your phone, no desktop needed. Copilot mobile still has to add custom-MCP-server support on their side, but the moment it does, this works with it too. Enable it under the new Remote tab (put it behind an HTTPS reverse proxy like Cloudflare Tunnel).
v2.6.0 - Remote access for cloud AI apps (opt-in)
You can now securely connect cloud AI assistants like the Claude and ChatGPT apps to your Homey over the internet, using standard OAuth 2.1. No desktop needed anymore.
New “Remote” tab in the app settings
- One on/off switch, off by default so nothing changes unless you turn it on
- A field for your public HTTPS address
- Live status and a built-in step-by-step setup guide
How it works
- When enabled, the bridge acts as an OAuth server: a connector registers itself, you approve it once with your API key, and it receives a token that expires automatically
- Standard PKCE flow, single-use authorization codes, tokens stored hashed with automatic expiry
Secure by default
- With the switch off, the app stays local-network only, exactly as before, no OAuth endpoints exposed at all
- Meant to run behind a reverse proxy with HTTPS (e.g. a free Cloudflare Tunnel); never expose a bare port without HTTPS
- Requires an API key (used to approve connections)
Note: GitHub Copilot on mobile still needs to add custom-MCP-server support on their side. The moment it does, this works with it too, since the bridge is now a standard remote MCP server.
Hi! Really love the MCP server! Mutch better as the original one.
However AI’s struggle making, editing and troubleshooting (seeing) homey scripts and it run output. A better implementation of this would be awsome!
Helaas kan ik de script output niet direct zien via de MCP tools. De HomeyScript sandbox blokkeert require(), process, en import().
Thanks!
@LionelDerBoven
Hi! Thanks, this was a great suggestion, and it’s live in 2.7.0.
Your AI can now list, read, create, edit, delete and run HomeyScript scripts, and the run tool returns exactly what was missing: the console.log/log() output, the return value, and any error with a corrected line number in the stack trace. So the assistant can write a script, run it, see what it printed, and debug it, right from the chat.
A few extras:
- You can pass
argsandtokensjust like a flow card would, to test how a script behaves with input. - Running an existing script executes a throwaway wrapped copy, so your original script is never modified while you inspect its output.
- There’s a built-in guide that primes the AI with the sandbox rules (the
require()/process/import()you mentioned are blocked, so it now knows to use only the sandbox globals likeHomey,args,fetch,log).
One honest note: I looked into a “safe read-only test mode” and reading the output of past (flow/schedule-triggered) runs, but HomeyScript’s API doesn’t expose either cleanly, so I left those out rather than ship something unreliable. For safety, running scripts is treated as a full-access action (needs a full API key).
Give it a try and let me know how it works for your scripts!
Hi Robin, thanks for the excellent bug report, your diagnosis was spot on. It’s a real bug in 2.7.0, fixed in 2.7.1 (updating now).
The new homeyscript_run tool had an array parameter (args) without an items schema. Strict MCP clients like VS Code / GitHub Copilot reject any array-typed parameter that has no items, and that rejection aborts discovery of the entire toolset, which is why Copilot failed before answering even “hello”. Claude Desktop is more lenient about the schema, so it kept working with the same server.
Fixed the schema, and added a safeguard so every array parameter in every tool always gets an items from now on, so a single missing one can never break tool loading again. Verified across all 130 tools.
Update to 2.7.1 once it’s live (or grab the test build) and Copilot Chat should load the tools and work normally. Thanks again for flagging it so clearly!
That was fast! Thanks!
My AI found a bug I think? I am making an app and he said this. Don’t know if it is true (Claud Opus 5 high):
Found a real bug — and it’s not in your app.
mcp__homey__flowcards_test_condition returns true no matter what:
┌────────────────────────────────────────────┬────────────────────────────────────┬──────────┐
│ Test │ Correct answer │ MCP said │
├────────────────────────────────────────────┼────────────────────────────────────┼──────────┤
│ logic:random with chance = 0 │ false — a 0% chance can never fire │ true │
├────────────────────────────────────────────┼────────────────────────────────────┼──────────┤
│ cron:day_equals = Sunday (today is Monday) │ false │ true │
├────────────────────────────────────────────┼────────────────────────────────────┼──────────┤
│ your everyone_asleep (both asleep: false) │ false │ true │
└────────────────────────────────────────────┴────────────────────────────────────┴──────────┘
A 0% random condition returning true is impossible. That tool is hardcoded to true, or it’s reporting “the test ran” rather than the card’s result.
Your app is correct. At the same instant MCP claimed everyone_asleep was true, the CLI returned false — matching the raw data, where both of you are present: true, asleep: false. Both cards behave exactly as designed.
This is worth reporting to whoever maintains the MCP AI Bridge app — it’s the kind of bug that would silently break any automation built on that tool.
The rest of MCP works fine, for the record: apps_get, users_list and users_get_presence all returned accurate data, and apps_get confirms your app is running with crashedCount: 0.
Let me note this so a future session doesn’t get fooled by it:
Read 1 file, recalled 1 memory, wrote 2 memories
MCP is working and now permanently available from any directory.
The upshot of this last stretch: MCP gave a faster read path (users_list, apps_get, presence all accurate and instant), but it answered your original question with a no — there are no devkit tools, so it can’t install apps and couldn’t have routed around the rate limit.
It did earn its keep in an unexpected way, though: testing your cards through it surfaced a bug in the MCP AI Bridge that would have been easy to accept at face value. Had I trusted flowcards_test_condition, I’d have told you your everyone_asleep card was broken and gone hunting for a fault in code that was working perfectly.
Your app, verified from three independent angles just now:
- Raw Homey data: both users present: true, asleep: false
- CLI card execution: everyone_home → true, everyone_asleep → false
- App health: running, crashedCount: 0, CPU 0%
Which is exactly right, and closes out everything from this session — the app is built, tested (23/23), GPL-3.0 licensed, pushed to a private GitHub repo, installed and running, with zero runtime dependencies and no production advisories.
Two things worth doing when you have a moment, neither urgent:
Report the bridge bug. The chance: 0 reproduction is about as clean a bug report as you can hand a developer — one line, impossible to argue with.
Re-check the memory figure tomorrow. apps_get reported 77 MB RSS just now, but the app had been reinstalled minutes earlier. My expectation still stands that it settles once it’s idled overnight, and that’s the only honest way to compare it against Denon AVR’s 22 MB.
