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

Apps
, , , ,
82

@weide43

First of all thank you for this great work! I already built lots of fascinating stuff around it.

Recently, however, I came across an odd restriction of Mistral: It caps the number of tools at 100!

Additionally I was not always happy with the tools that were visible or not from the predefined access levels, although you could work around it by selecting a higher level than you really intended and then introduce restriction using all the various mechanisms provided.

This together with Mistral‘s limitatiion lead to one big wish: Please give users an option per API key to select each single tool to be presented (or not) to the AI.

Thank you again for this great app. You outpaced Athom‘s laughing stock of a crippled toy by lightyears! :+1:

83

@4x4_Pete
Thanks, and that is a good catch on the Mistral limit.

You are right about the numbers. On the current build a key sees 71 tools at read, 84 at control, 115 at write and 132 at full, so control just fits under Mistral’s 100 and write does not. Picking a level you did not want and then clawing pieces back is exactly the workaround I would rather you did not have to invent.

So 4.12.0 does what you asked: on the Security tab, press Tools on any key and tick what that connection should see. Grouped by what each tool does, with a search box and a running count that turns red past 100. Ticking nothing means everything the permission allows, so your existing keys are unchanged.

One deliberate limit: a selection only ever narrows. You are only offered the tools that key’s permission already allows, and adding one it does not allow changes nothing. Trimming a list to fit a client limit should never be able to hand out access by accident. Tools you leave out are refused when called, not just hidden, and the refusal names the key to change rather than claiming the tool does not exist.

Thanks for the kind words too, and for reporting something with the numbers attached. That is what made it easy to build the right thing.

84

[SOLVED]

With Mistral there is a pitfall: Mistral defaults to OAuth. - And with OAuth none of API-key related stuff does work.

When creating a connector in Mistral you must select “User defined” as authentification method.
Then set
Header: Authorization
Value: Bearer bridge-api-token

Additionally you have to switch “Extended Header settings” on and set
Header: X-API-Key
Value: bridge-api-token

Hi @weide43

The per API key tools selection of version 4.12.0 unfortunately does not work for me (at least with Mistral):
I disconnected and deleted the MCP connector in Mistral and created a new one. But all tools remained visible and were capped at 100. In the Security tab of the MCP AI Bridge settings, however, the selection (44 tools selected) displays correctly.
I tried with the existing key and also with a newly created one. Both with same negative result.
MCP AI Bridge App was also restarted.

Do I have to Delete and reinstall the App?

85

@4x4_Pete

Thanks for coming back with the OAuth pitfall, and for writing it up rather than just fixing it for yourself. “Mistral defaults to OAuth, pick User defined” is the kind of thing nobody finds twice, and it is now the first thing the wizard will say about that client.

You were right about the tool selection as well, and the reason is the same OAuth. It was a real gap, not a setting you missed.

The selection lives on an API key. A local client sends that key with every request, so the app can look it up and cut the list down. A remote connector never sends it: it sends a token it received when you approved it on the consent page. That page checked your key and then forgot it, so there was nothing left to look the selection up with, and the connector was shown everything its permission allowed. Your Security tab was telling the truth about your 44 tools; the connector was simply not being asked about them.

That is fixed in 4.12.1. Approving a connector means proving you hold a key, so the connection now inherits that key’s selection, keeps it when the token is renewed an hour later, and the consent page tells you it will. Under Remote, a connected app now shows how many tools it may use, so you can see whether your choice arrived instead of having to guess. Nothing about the permission changed: a selection still only ever narrows, and the permission you pick for the connection stays the ceiling.

The ten auth_failed from 192.168.x.x lines in your report fit this too. Those are attempts arriving without a key the app recognises, which is what the OAuth route looks like from the inside. Once you are on the OAuth route with 4.12.1, approve the connector with the key that carries your 44 tools and it will come along.

No, you do not have to delete and reinstall. Update to 4.12.1 and, if you are connected through OAuth, approve the connector once more so the new grant picks the selection up. An existing grant from before the update keeps working exactly as it does now; it just has no selection attached to it, because there was none to attach at the time.

If you prefer the User defined route you found, that path already applied the selection and still does, since the app can see your key there.

86

May I ask what AI (Modell, reasoning setting, …) you are?

Since I also find the closed loop agentic pipeline you are running in somewhat impressive: How does that look like?

87

Bug report v4.10.1: all mcp-remote clients rejected with -32020 (“modern routing headers but no params._meta protocol version”)

Since auto-updating from 4.7.0 to 4.10.1 (Homey Pro 2026, v13.4.1), Claude Desktop can no longer connect through mcp-remote. Every connection attempt fails at initialize with:

{"jsonrpc":"2.0","id":0,"error":{"code":-32020,"message":"This request carries modern routing headers but no params._meta protocol version. Send both, or neither."}}

What I tested (all failing with the same error):

  • mcp-remote 0.8.1 (latest) and 0.7.0
  • both X-API-Key and Authorization: Bearer headers
  • the exact “mcp-remote (Compatible)” snippet from the app’s own connect wizard

What works:

  • a plain curl POST of initialize (no MCP-Protocol-Version header) → normal result, serverInfo 4.10.1
  • pinning mcp-remote@0.3.3 (predates the MCP-Protocol-Version header) → connects fine; this is my current workaround

So the check seems to require params._meta.protocolVersion whenever the MCP-Protocol-Version header is present — but that _meta field isn’t part of the MCP spec (in initialize the protocol version is top-level params.protocolVersion), so spec-compliant clients like current mcp-remote can never satisfy the “both” branch. The “Native HTTP” wizard config ("type":"http") isn’t accepted by current Claude Desktop either (“not valid MCP server configurations”), so mcp-remote is still the only route for Claude Desktop users.

Could the check be relaxed to accept the standard params.protocolVersion? Happy to test a beta. Thanks for the great app!

88

@Paul_Pandre

Your diagnosis is exactly right, and thanks for doing it properly: the versions you tested, the curl that worked, and the 0.3.3 pin narrowed it down to one line of my code. Fixed in 4.12.2.

What happened. The bridge serves two protocol eras and has to tell them apart per request. It was using the MCP-Protocol-Version header to decide, and that was simply wrong: the header is not a mark of the new era. Every client since 2025-06-18 is required to send it, and its value is whatever the newest version that client’s SDK knows about happens to be. So the moment mcp-remote learned the string 2026-07-28, an ordinary legacy client started announcing it, my code read that as “this is a new-era request”, went looking for params._meta, did not find it, and refused. And as you spotted, the other branch was unreachable: in initialize the version is top-level params.protocolVersion, and a new-era message has no initialize at all. It was a check nothing could satisfy.

The gate now keys on Mcp-Method and Mcp-Name. Those two have no legacy meaning, and the new era requires Mcp-Method on every request, so nothing is given up: a genuine new-era request whose _meta went missing still carries it and is still refused. Your client can announce whatever version it likes.

I checked the thing that gate was added for before touching it, rather than assuming. It went in after an audit found a legacy body under new-era headers reaching system_reboot. That hole is closed by the confirmation gate itself, which does not care about eras: a plain tools/call system_reboot is refused with “this client cannot show a confirmation”, header or no header. Measured both ways, and pinned in the test suite so it cannot quietly come back.

Your second point was right too. The Claude Desktop tab of the connect wizard opened on the native HTTP entry and called it Recommended, while that client answers it with “not valid MCP server configurations”. It now opens on the mcp-remote setup. Native HTTP is still there, marked as newer versions only, and it names the tab to fall back to. Claude Code and Cursor do take a native entry, so those tabs are unchanged.

After updating you can drop the 0.3.3 pin and go back to current mcp-remote. Sorry for the week of workaround, and thanks again for the report; it was about as useful as a bug report gets.

89

4.15.0 is in test, and your home can now ask a question back

Everything this app has ever done points one way. An assistant reaches into your Homey, reads it and operates it. Nothing in your home could ask the assistant anything, because there is no assistant sitting there: there is a client somebody has open, and when it is closed there is nobody.

This version turns that around with one new flow card.

Ask a model a question

Put the card in a flow, type a question, and the answer comes back as a flow tag called Answer. Drop that tag into whatever comes next: a notification, spoken out loud, into a variable, into a condition. A few things people have asked for over the last months turn out to be this card plus one they already had.

Some examples of what that looks like in practice:

  • every morning at seven, ask for a two sentence summary of what happened in the house last night, and send it as a notification
  • when the washing machine finishes and nobody is home, ask for a short reminder to leave on the kitchen speaker
  • when a sensor reports something odd, ask whether the reading is unusual for this time of year before you wake anyone up

It uses your own API key with Anthropic, OpenAI or Mistral. That is the honest version of this feature. The alternative, borrowing the model of whichever assistant happens to be connected, needs a client that implements MCP sampling, and almost none do, so it would work for nobody and fail quietly for everybody. Your key means every question is a request you pay for, and the app is built around that fact rather than around it.

Off until you switch it on. There is a daily limit, set to 50 to begin with. A flow that reacts to a device can fire hundreds of times an hour, and the first you would know is the bill, so past the limit the question is refused until tomorrow. The count is taken before the request rather than after, because a failed request still cost a request, and counting afterwards means a provider erroring on every attempt can be retried all night for free.

Text in, text out, and that is deliberate. The model gets a question and returns an answer. It cannot call tools, it cannot see your home unless you set the card to include a short summary, and it cannot change anything. A flow that should act on the answer does that with its own cards, where you can see exactly what will happen. Letting a paid-for model drive the house directly would put an unattended actor behind every permission this app spent its life building, and nobody would be watching.

It has a tab of its own, Ask a model, with the steps, the settings, and a test question you can ask straight from the page, so you find out whether your key works without building a flow first. That test costs what any question costs, so it counts against the same limit, and the page says how many of today’s are used.

Three more, while I was in there

A set of changes, shown first and applied as one thing. Ask an assistant to rename twelve devices and until now that was twelve separate calls: if the seventh failed, six were done, five were not, and you found out by reading a wall of output. Now it describes all twelve first, you read them and agree, and they are applied together. If one fails, the ones that already went through are put back, so your home is never left half changed, and the answer says exactly what was restored and what could not be. A set containing a delete or an overwrite is refused unless you say in so many words that you accept it cannot be fully undone.

The log now says which assistant did it. A house can have Claude on a laptop with one key, a connector in the cloud with another and a flow calling tools with a third, and “who renamed my device” had no answer. Every line now carries the key it came from, by its current name, and a key you have since deleted still shows on the line it made instead of quietly vanishing.

One call to get oriented. A fresh conversation used to find out about your home by listing devices, then zones, then flows, then variables. On a house with 96 devices that is 31 KB before it has answered anything, every conversation again. home_briefing is the same picture in 3 KB: what the home is, which rooms exist and how much is in each, what kinds of devices there are, how many flows and variables, and who is home.

What would help

The test version is here: MCP AI Bridge | Homey

Everything above has been driven against a real Homey, including every way the new card can refuse and a deliberately invalid key at all three providers, which were really contacted and whose own error messages come straight back to you. The one thing I could not test is the ordinary case: a valid key and a real answer, because that needs a paid key of my own.

So if you try it with your own key, I would like to know it worked, and if it did not, the exact text the card or the page gave you. Those messages are the provider’s own words on purpose, so they usually say precisely what is wrong.

90

MCP Insights issue:

get_insights_log_entries_number Rejects Entire Response on Any Null Value in Series (Homey Pro, MCP AI Bridge)

Environment:

  • Device: Homey Pro
  • Firmware: [not verified from this session — please confirm on your end]
  • App: MCP AI Bridge / Homey MCP Server (mcp.athom.com)

The Issue: Calling get_insights_log_entries_number returns a schema validation error whenever any single entry in the requested series has v: null, instead of omitting the null point or returning it as-is. This makes numeric Insights data effectively unusable whenever there’s a gap in the log, which appears to be common.

Summary of Findings:

  • Boolean logs: WORKING. get_insights_log_entries_boolean returns valid data, null-safe, across the full requested range.
  • Number logs: FAILING. Every call to get_insights_log_entries_number that touches a null entry fails outright with: Invalid structured content for tool get_insights_log_entries_number: [{“code”:“invalid_type”,“expected”:“number”,“received”:“null”,“path”:[“entries”,N,“v”],“message”:“Expected number, received null”}] — often listing dozens of offending indices per response.
  • Not resolution-specific: Failed under today, yesterday, last6Hours, last24Hours, and last7Days alike.
  • Not device-specific: Reproduced on two unrelated devices — a Tesla car’s battery SoC (measure_soc_level) and two separate Tibber Pulse energy meters (measure_power) — so it’s a general handling issue in the tool, not a device quirk.

Steps Taken (all failed to resolve the issue):

  1. Retried with narrower resolutions (today, yesterday) to avoid the current incomplete bucket.
  2. Retried with wider resolutions (last7Days) assuming more history might route around the gap.
  3. Tried a different device’s log entirely (Tesla SoC vs. Tibber Pulse power) to rule out a per-device fault.
  4. Confirmed the adjacent boolean-log tool (get_insights_log_entries_boolean) succeeds against a null-containing series on the same underlying device, isolating the fault to the number-log tool’s response validation.

Technical Observation: The failure is a client-side/schema-level validation step rejecting the whole payload rather than an upstream API failure — the error is a structured content validation error (invalid_type), not an auth or network error. The underlying Homey Insights data itself appears intact (gaps are normal in Insights logs, e.g. around device sleep/offline periods); the tool’s response schema simply doesn’t tolerate null in numeric series.

Expected Behavior: get_insights_log_entries_number should handle null entries gracefully — either by omitting them from the returned series or passing them through as null — rather than failing the entire call. This should mirror how get_insights_log_entries_boolean already handles nulls correctly.

91

@KjetilJD

Thanks for the detail in that report, it is a good one: two devices, four resolutions, and the boolean tool tried as a control. It is just aimed at the wrong app, and the app line in your own post shows how easily that happens. It reads “MCP AI Bridge / Homey MCP Server (mcp.athom.com)” as though those were one thing, and they are two separate products.

get_insights_log_entries_number and get_insights_log_entries_boolean are Athom’s tool names, from their hosted server at mcp.athom.com. This app has never had a tool by either name. Its Insights tools are insights_list, insights_get_entries, insights_get_summary, insights_trend and insights_anomaly. So the bug is real, but it belongs with Athom rather than here, and it is worth filing there so it actually reaches somebody who can fix it.

One detail that may help whoever picks it up. The error you quoted is not the Homey API failing, and you spotted that yourself. That shape, with code, expected, received and a path into the payload, is the MCP TypeScript SDK validating a tool’s declared output schema and throwing out the whole result when one field does not fit. If the schema says that value is a number, a single null in a thousand points fails the call, and the boolean tool works because its schema happens to tolerate what its series contains. That also explains why nothing you tried helped: no resolution and no device avoids it, because the rejection happens after the data is already back and intact.

For what it is worth, this app takes the second of the two options you propose, and passes the gaps through:

**•**	insights_get_entries returns every point, null values included, with their timestamps. A gap is data. A caller drawing that series needs to know where the hole is, and silently dropping the points would shift everything after them.

**•**	insights_get_summary, insights_trend and insights_anomaly skip the gaps and tell you how many real points they used, so an average over a sleeping sensor is an average of what was actually measured.

**•**	A range that contains nothing but gaps answers “No numeric data points in range” rather than a number that means nothing.

There is now a test pinning that, so it stays true.

If you were reaching for Insights because you wanted a number rather than the raw series, insights_get_summary and insights_trend are worth a look either way: they do the aggregating on the Homey and hand back one answer, which is a lot easier on an assistant’s context window than a week of five-minute points.

92

Hi Danny,

I’m testing the new “Ask a model a question” feature in MCP AI Bridge.

The settings page shows the Model vragen / Ask a model section, but when I press the test button I get this error:

Missing implementation for api endpoint “postAskia”

I also checked the available MCP AI Bridge action cards in Homey/Advanced Flow. I can see the existing actions such as:

  • Remember a value for the AI
  • Send an error back to the AI agent
  • Send an answer back to the AI agent

But the new “Ask a model a question” action card is not available.

I have already configured the OpenAI provider, model and API key, so it looks like the settings page is present, while the corresponding backend endpoint and Flow card may not be registered correctly.

Could you please check whether this is a bug in the current test version?

Thanks!

@weide43

93

@Mark1541

Hi Mark,

You found a real one, and thanks for the precision: the exact error text plus the list of cards you could see is what made it quick to pin down.

The test button. That is my bug, and you read it right when you guessed the settings page was there while the backend was not. A button on the settings page does not call the app directly. It goes through a small routing file that maps each endpoint name to the method that handles it, and that file is the one place the new endpoint never got added. So the tab, the provider settings, your API key, the flow card and the whole path out to OpenAI were all present and correct, and the door the button knocks on was not there. Hence the error naming an endpoint that does exist everywhere except in the one file that has to point at it.

It is fixed in 4.15.1, along with a test that compares the three lists which have to agree, so the next endpoint cannot go out half connected.

Worth being honest about why it reached you at all. The Ask a model feature was tested hard before it shipped, including every way it can refuse and a deliberately wrong key at all three providers to see their real error messages come back. But every one of those tests drove the provider directly or through the flow card, and neither of those goes past the routing file. So the one path nobody exercised was the button, which is exactly the path you took first. Testing the parts is not the same as testing the door.

The flow card. This one I cannot reproduce, and I want to be straight about that rather than fix something that is not broken. The card is in the app manifest in the build you have, and on my own Homey the app offers four action cards: Ask a model a question, Remember a value for the AI, Send an error back to the AI agent, and Send an answer back to the AI agent. The first is the one you are missing, and the other three are exactly the three you listed.

That pattern, an updated app whose new flow cards do not turn up until something reloads, is one Homey does now and then. Two things worth trying, in this order: restart the app from Settings, Apps, MCP AI Bridge, and if it still is not offered, close and reopen the flow editor so it fetches the card list again. If neither works I would like to know, because then it is something else and I will keep digging.

One thing that will not be the cause, so you can rule it out: the missing endpoint and the missing card are unrelated. Fixing the first does not touch the second.

Thanks again for testing it and for writing it up properly. If the test button works for you on 4.15.1 with a valid key, I would like to hear that too. A model actually answering with a real key is the one part of this I have not been able to prove myself.

94

Thank you for quick fix now it’s working ! @weide43

One question does this also search on the internet ? Like weather forecast or something else?

I’m using ChatGPT

95

@weide43 When I’m using the official integration for CHATGPT MCP from Homey, I sometimes experience limitations and get rate limits. Does your app also suffer from this if I switch to this bridge?

96

@Mark1541

Good question, and the honest answer has two halves, because “rate limits” with ChatGPT can come from either side of the connection.

What changes. This app is not a hosted service. It runs on your own Homey and your assistant connects to your Homey’s address, so there is no server of mine in between with a quota to share out among everybody using it. That holds all the way down: even writing flows, which needs your Personal Access Token, goes to your Homey’s local address rather than out through Athom’s cloud.

The app does have a rate limiter, but it is off unless you switch it on. Out of the box the setting is 0, which means no limit at all. If you do turn it on, the number is yours: requests per minute, counted per API key so one assistant cannot spend another’s allowance, with a separate and tighter limit you can set for destructive actions like deleting or rebooting. It is there so a runaway client cannot hammer your Homey, not to ration you.

What does not change. If the limits you are hitting come from ChatGPT rather than from the server it is talking to, switching the server will not help, and I would rather say that now than have you move for nothing. OpenAI puts its own ceilings on how much a custom connector may be called, and those follow your ChatGPT account, not the Homey side.

There is a way to tell which side you are on. When the bridge refuses something it says so in the app: the Security tab logs it as a rate_limited event with the source, and the Diagnostics tab lists every call that arrived with its result. So if ChatGPT tells you it is rate limited and there is nothing in either tab at that moment, the request never reached your Homey and the limit was upstream. If it does show up there, it is my limiter and you can raise or clear it yourself.

Two other ChatGPT specifics worth knowing before you switch, since they are limitations rather than rate limits:

  • Write-capable custom MCP connectors are restricted to Business, Enterprise and Edu. On Plus and Pro you get read-only, which still covers roughly 80 read tools here, but no control.
  • ChatGPT runs in the cloud, so it cannot reach a local address. You would need your bridge reachable over HTTPS through a reverse proxy or a tunnel, plus an API key. The Remote tab in the app settings walks through that step by step.

And one limitation you may have run into without it being called a rate limit: several clients cap a connector at 100 tools, and this bridge has more. Since 4.12.0 you can tick exactly which tools each API key is shown, with a running count that warns you when you go over 100, and a preset that orders them by what your house actually uses so the ones you would miss end up above the line.

One thing I deliberately will not tell you is what limits Athom applies on their own hosted server, because I do not know and guessing would not help you decide.

97

Does your connection – or the bridge – also run via the MCP AI Bridge integration via mcp.athom.com @weide43

98

@Mark1541
No. They are two separate servers, and you pick one in your client rather than stacking them.

mcp.athom.com is Athom’s own hosted MCP server. This app is a different MCP server, running inside the app on your Homey, listening on your own network. Your client connects straight to it, at an address like http://192.168.1.50:52199/mcp. Nothing is registered with Athom’s service, routed through it, or announced to it. The string “athom.com” does not appear anywhere in this app’s code.

So when you connect a client to this bridge, you are pointing it at your Homey instead of at Athom, not in addition to it.

Since you asked about limits just before this, here is the whole picture of what does leave your house, because “it is all local” would be too easy an answer:

  • The MCP traffic itself: your client to your Homey’s address. Nothing in between.
  • Creating and editing flows, which needs your Personal Access Token: this goes to your Homey’s local address too, not out through Athom’s cloud. That one surprised me when I checked it, which is why I checked.
  • Webhooks, if you set any up: straight to the URLs you configured yourself. The AI can never post to an arbitrary address; it can only reference a webhook you added, by its id.
  • Asking a model a question, the new flow card: straight to Anthropic, OpenAI or Mistral, with your own key. That one genuinely leaves the house, on purpose, and it is off until you switch it on.
  • Reaching it from outside your network, which is off by default: through your own reverse proxy or tunnel, and the app can serve HTTPS itself so the last hop is not plain text either. Still nothing of mine or Athom’s in the middle.

Two bits of Athom that do remain, so the list is honest. The app settings page you are reading all this on is a Homey app settings page like every other app’s, served through Homey’s own interface. And your Homey keeps its own connection to Athom for the platform itself, updates and remote access to Homey, whether this app is installed or not. Neither of those carries any MCP traffic.

99

Heavens beware! mcp.athom.com is a useless toy and has not received any fixes or improvement for many months. Athom does not seem to be interested in AI and simply has no idea and strategy in place.
Or they have simply been to busy launching their overpriced ridiculous gadget - “zoney” or how they call that remote control with a power cord hanging from its back :rofl:

100

4.17.0 is in test: your flows can ask, branch on the answer, and you can see what it cost

First, @Mark1541, thanks for both reports.

The test question button that answered “Missing implementation for api endpoint” was a real bug and my fault. A settings button reaches the app through a small routing file, and that file is the one place the new endpoint never got added. Everything else was there and working, and the door the button knocks on was not. Fixed in 4.15.1, with a test that now compares the three lists which have to agree so the next endpoint cannot go out half connected.

The missing flow card I still cannot reproduce; the card is in the manifest and shows up here. If it did not appear for you after a restart, I would like to know, because then it is something else.

Ask a model, six months of missing halves, all at once

It remembers now. An answer used to go into a flow tag and vanish. If a flow asked something at three in the morning and put it in a notification you dismissed, there was no way to see what it asked, what came back, or what it cost. Every question is now recorded, whichever way it came in: a flow, the test button, or a dashboard. The Ask a model tab shows the last twenty with the provider, the model, the tokens and what went along with the question, and a button to clear them, because a question carries whatever a flow put in it.

A condition card, so a flow can branch. Until now a flow could pass an answer onward but not decide anything with it. Now it can ask a yes or no question and take a different path. The model is told to answer with one word, and if it says something that is neither, the flow stops and quotes what it actually said. It does not pick a branch for you: a wrong branch is worse than a stopped flow, because a wrong branch looks like it worked.

Context you can aim. It used to be nothing or the whole house. Neither is right for “is the living room colder than usual”: nothing cannot answer it, and the whole house sends ninety-odd devices to answer a question about one room, per token, every single time. You can now send one room, one device, or what happened recently.

What it costs, in money. A limit of fifty questions a day is a number nobody can price. Fifty questions with a big model and the whole house attached is not the same money as fifty one-liners. Fill in what your provider charges per million tokens and you get a real amount, per question and per day. These are settings rather than a built-in table on purpose: model prices change, and a table baked into an app is wrong the week after it ships, always in the direction of making your bill look smaller. Leave them blank and no amount is shown, which is not the same as free.

A second provider. If the first cannot be reached or refuses, a fallback is tried once, with its own key. It is not tried when the first refused on purpose. A daily limit or a missing key is a decision you made, and going around a decision is not a fallback.

On both kinds of dashboard

The Bridge device gained two values, the last answer and the questions sent today. Put the device on a Homey dashboard and the tile shows what your house last learned.

The app’s own dashboard has a new card for the same two values, and it can carry an Ask button with your own preset questions.

That button is off until you switch it on, and a card alone is not enough. The reason is worth saying out loud: a dashboard page carries its own access token inside the page, which is exactly why dashboard control has always been limited to the devices already on it. Asking a model is the first dashboard action that spends money rather than flipping a switch, and money is not a control you can take back. So it needs your switch and a card that declares itself, and it goes through the same daily limit as everything else rather than a second, looser path.

What would help

Test version: https://homey.app/a/community.mcp-ai-bridge/test/

All four kinds of context were driven through the real flow cards on a real Homey, the condition card runs, and every way this can refuse was triggered on purpose. The one thing I still cannot test is the ordinary case: a valid paid key and a real answer coming back.

So if you use it with your own key, I would like to hear that it worked, and if it did not, the exact text you got. Those messages are the provider’s own words on purpose, so they usually say precisely what is wrong.

101

Set it up tonight working fine great app