Track Home Assistant native LLM and MCP development

[magnusoverli]

Purpose

Track Home Assistant's native LLM, Assist, MCP, and OHF Voice intent work so OpenCode can stay a premium consumer of the platform as it develops.

This is a watchlist issue, not a single implementation task. Open concrete implementation issues separately when an upstream change is merged, released, and testable.

Upstream Watchlist

• LLM Tool Platform home-assistant/architecture#1412 - LLM Tool Platform architecture
• Add LLM integration home-assistant/core#174253 - native llm integration and tool platform plumbing
• Have the Assist API get its tools and prompt from the llm integration home-assistant/core#175659 - Assist API gets tools and prompt from the llm integration
• Expose all LLM APIs on the MCP server keyed by API ID home-assistant/core#175570 - expose all LLM APIs through MCP at /api/mcp/<API ID>
• Remove area from LLM system prompt and provide in a tool home-assistant/core#170014 - move current area/floor context from prompt into a tool
• Add assist_satellite LLM tools platform home-assistant/core#175655 - assist satellite LLM tools platform
• OHF-Voice/intents - intent schema/data changes, slot-combination migration, and domain coverage

Things To Check For OpenCode

• Which Home Assistant release or beta includes the change?
• Can the add-on reach the relevant API through Supervisor authentication?
• Does the change complement our MCP server or replace any part of it?
• Should get_agent_capabilities report a new capability or readiness state?
• Do docs or user guidance need updating?
• Do we need a companion Home Assistant custom integration to participate in <integration>/llm.py?

Useful GitHub Searches

repo:home-assistant/core llm updated:>=2026-07-01
repo:home-assistant/core "api/mcp" OR "MCP server" updated:>=2026-07-01
repo:home-assistant/core "Assist API" "llm" updated:>=2026-07-01
repo:OHF-Voice/intents "slot-combination" OR "vacuum" OR "todo" updated:>=2026-07-01

Current Position

OpenCode MCP remains the complete working tool surface for configuration editing, validation, admin/dev workflows, screenshots, updates, ESPHome, Zigbee tooling, and safety-oriented operations.

Home Assistant native LLM tools should become the preferred surface for core Assist/entity-control behavior once stable and accessible. The two surfaces are complementary.

[magnusoverli]

Upstream review, 2026-07-22

Reviewed everything on the watchlist against home-assistant/core and OHF-Voice/intents. Work is staged on feat/ha-2026.8-native-llm, held unmerged until it can be validated against a real 2026.8 build.

Watchlist status

Item	State
architecture#1412 — LLM Tool Platform	design accepted, implementation merged
core#174253 — native llm integration	merged 2026-07-03
core#175570 — keyed /api/mcp/<API ID>	merged 2026-07-04
core#175655 — assist_satellite platform	merged 2026-07-08
core#175659 — Assist API from llm	merged 2026-07-09
core#170014 — area/floor into a tool	still open, no movement since 2026-07-06
OHF-Voice/intents	slot-combination migration complete

Nothing is in a shipping release. All of it merged to dev after 2026.7.0 branched; dev is 2026.8.0.dev0. Checked against tag 2026.7.3: mcp_server/http.py registers only /api/mcp, /mcp_server/sse, /mcp_server/messages — the keyed endpoint does not exist on any release users can run today. First 2026.8 beta expected around 2026-07-29.

What landed beyond the watchlist

15 per-domain tool platforms now exist on dev: assist_satellite, calendar, climate, fan, homeassistant (GetLiveContext), humidifier, intent, intent_script, lawn_mower, light, llm (GetDateTime), media_player, script, todo, vacuum. Twelve follow one pattern — wrap the integration's own intents with IntentTool, gate on async_should_expose — which our get_ha_llm_development_guide did not describe. No manifest change is needed; LazyIntegrationPlatforms discovers llm.py automatically.

Two upstream bugs affect us directly.

• #176762 → fixed by #176814: GetLiveContext's domain parameter serialized to "anyOf": [{}, ...]. Clients that strictly compile tool schemas — the PR names Claude Code — cannot compile it, fall back to __unparsedToolInput, and Home Assistant rejects the call. Confirmed by diffing helpers/llm.py between 2026.7.3 and dev: the selector_serializer fix is dev-only, so every current release is affected.
• #176734 (open, fix PR still draft): a malformed or empty POST /api/mcp has been reported to crash Core.

Deprecations and refactors: async_render_no_api_prompt deprecated (#176111); helpers/llm.py roughly halved by #176082, so guidance quoting its internals is stale; LLMContext.assistant now required (#175553); script tool aliasing moved into the script integration (#176114).

OHF-Voice/intents: slot-combination migration finished — migration scripts and guide removed, language scores now derived from slot combinations, entity device_class migrated into attributes as a single canonical form. Latest release is 2026.6.24, so none of the post-migration work is in a released package. Nothing actionable for the add-on today.

What the branch changes

1. Endpoint negotiation. The bridge defaulted to /api/mcp/assist and never fell back, so on every shipping Home Assistant it was talking to a 404 and could not work at all. It now prefers the keyed endpoint, latches onto the configured /api/mcp after a 404, and logs whether the endpoint is absent (pre-2026.8) or the API ID is unknown. HA_NATIVE_MCP_ENDPOINT_MODE=auto|keyed|configured pins the choice.
2. Tool schema repair for #176762, so the bridge is usable on 2026.7.x. HA_NATIVE_MCP_SANITIZE_SCHEMAS=0 disables it — that switch is how we will confirm #176814 actually landed once 2026.8 is testable.
3. JSON-RPC validation before forwarding, so the bridge cannot be the thing that triggers #176734.
4. get_agent_capabilities now reports the 2026.8 minimum, whether this instance meets it, and a known_issues list naming each upstream limitation with its mitigation — so a stalled bridge reads as a known upstream gap, not a broken configuration. Also corrected the AI-component probe: lmstudio is not a Home Assistant integration and was dropped, ovhcloud_ai_endpoints was missing, and conversation agents are now reported separately from AI task providers.
5. get_ha_llm_development_guide rewritten against the merged code: exposure-gated IntentTool pattern first, upstream's real import paths, the schema-conversion pitfall documented so tool authors avoid reproducing it, and the 2026.8 requirement stated plainly.

Open question for 2026.8

Whether a Supervisor-proxied add-on request presents as an admin hass_user. Irrelevant for assist, which is explicitly exempted from the admin check in mcp_server/http.py, but it decides whether any other keyed API ID is reachable from an add-on at all. Can only be answered against a live 2026.8.

[magnusoverli]

Upstream review, 2026-07-31

Re-verified the whole watchlist against real refs rather than the previous review's assumptions. 2026.8 has entered beta — 2026.8.0b0 on 2026-07-29, 2026.8.0b1 on 2026-07-30 — so the platform work is testable for the first time. Latest stable is 2026.7.4 (2026-07-24); 2026.8.0 final is not out.

The bridge work has shipped: stable 2.4.0 and beta 2.3.9b3.

Watchlist status

Item	State (verified against the ref named)
architecture#1412 — LLM Tool Platform	design accepted, implementation merged
core#174253 — native llm integration	merged 2026-07-03
core#175570 — keyed /api/mcp/<API ID>	in 2026.8.0b1 — ModelContextProtocolStreamableApiView, url = /api/mcp/{api_id}
core#175655 — assist_satellite platform	merged 2026-07-08
core#175659 — Assist API from llm	merged 2026-07-09
core#176762 → #176814 — schema conversion	in 2026.8.0b1, absent from 2026.7.4
core#176734 — streamable endpoint crash	still open, and not fixed in 2026.8
core#170014 — area/floor into a tool	still open, no movement since 2026-07-06
OHF-Voice/intents	2026.7.30 released — first release carrying the post-migration work

The open question is answered: yes, admin

The previous review left this hanging: "whether a Supervisor-proxied add-on request presents as an admin hass_user." It resolves from code, no live instance needed.

• hassio/__init__.py creates its user via async_create_system_user(HASSIO_USER_NAME, group_ids=[GROUP_ID_ADMIN]), and force-migrates pre-existing ones into the admin group.
• Supervisor's APIProxy._api_client forwards /core/api through sys_homeassistant.api.make_request — the Supervisor's own token — so request["hass_user"] is that admin user.

Every registered API ID is reachable from an add-on, not just assist. This was being reported the other way round, which steered users away from custom API IDs that work; corrected in the add-on's capability output, docs and option text.

Also worth recording: the Supervisor is already MCP-aware. FORWARD_HEADERS carries Accept, Mcp-Session-Id and MCP-Protocol-Version, and the proxy detects and streams text/event-stream (home-assistant/supervisor#6461, Feb 2026). Nothing in the transport works against us.

Corrections to the 2026-07-22 review

#176814 was not backported. 2026.7.4 shipped on 2026-07-24, four days after the fix merged, and does not contain it — selector_serializer in 2026.8.0b1 opens with if schema is cv.string or schema is intent.non_empty_string, and 2026.7.4's does not. So the schema repair is still required on every current stable release, and the 2026.8 gate on it is correct.

#176734 applies on 2026.8 exactly as on 2026.7. Its fix (#176782) is a draft from a third-party contributor, untouched since 2026-07-22, and 2026.8.0b1's http.py still has the bare asyncio.timeout + task-group block with no except*. The local JSON-RPC guard has no near-term exit. Note the maintainer analysis in the PR describes the failure as an unhandled ExceptionGroup surfacing as a 500 plus a 60s hang, rather than the Core crash the report describes.

Nothing new has merged since 2026-07-20 in mcp_server/, helpers/llm.py or components/llm/. Upstream went quiet at the freeze; there is no 2026.9 material to react to yet. Still exactly 15 per-domain tool platforms.

Smaller findings

• #169636 (Improve Assist LLM entity targeting) is open alongside #170014, on the same surface. Both missed 2026.8. Worth adding to the watchlist.
• #175572 changed the platform contract to async_get_tools(hass, llm_context, api_id) -> LLMTools | None — platforms receive the API ID and opt out by returning None.
• /api/mcp is multi-API. CONF_LLM_HASS_API is a multi-select and Core passes the whole list through, so the unkeyed endpoint can carry several APIs at once. This predates 2026.8; it was simply being treated as singular.
• Protocol version matches. 2026.8 pins mcp==1.26.0, whose LATEST_PROTOCOL_VERSION is 2025-11-25.
• OHF-Voice/intents 2026.7.30 is coming in 2026.8. core#177662 bumped home-assistant-intents to 2026.7.30 on 2026-07-30 at 15:50 UTC with milestone 2026.8.0. 2026.8.0b1 was cut at 09:31 the same day and still shows 2026.6.24, so the pin lands in a later beta or the final. hassil moved 3.8.0 → 3.10.0 for 2026.8; hassil v3.11.0 released 2026-07-31 and is therefore post-2026.8.
• A third open PR on this surface: core#172755, "llm: Fix DEFAULT_INSTRUCTIONS_PROMPT to not suppress tool use" — open, not a draft, untouched since 2026-06-03.
• AI component probe is current — the add-on's lists match dev exactly: 10 conversation platforms (including the new-in-2026.8 litellm and llama_cpp) and 6 ai_task providers.

Current position

The bridge ships in stable 2.4.0 and handles both sides of the 2026.8 boundary on its own: it prefers the keyed endpoint, falls back and re-arms on a timer, repairs the pre-2026.8 tool schemas, and validates JSON-RPC locally so it cannot be what triggers #176734. get_agent_capabilities reports each upstream limitation against the release that fixes it, so a stalled bridge reads as a known upstream gap rather than a broken configuration.

The two surfaces stay complementary. OpenCode MCP remains the tool surface for configuration editing, validation, admin/dev workflows, screenshots, updates, ESPHome, Zigbee and safety-oriented operations; Home Assistant's native LLM tools are the preferred surface for core Assist and entity control.

The rest of the sphere is quiet

Swept beyond this watchlist to check nothing is being missed. ai_task, tts, stt, wake_word and assist_pipeline have had only lint, typing and dependency commits since June — no feature work. Frontend has nothing structural in this area (Assist appears only in demo changes). Only three open PRs touch the LLM surface at all: #169636, #170014 and #172755. New AI-adjacent integrations in 2026.8 are llm itself, litellm and llama_cpp.

Next actionable

One gap is worth an upstream contribution rather than a workaround: there is no way to enumerate registered LLM APIs from outside Core. llm.async_get_apis is used only by config flows and mcp_server — no REST route, no websocket command. That is why an unknown API ID can only tell the user to go and check for themselves, and why the add-on cannot offer a picker. A small websocket command listing API IDs and names would close it.

How that has to be done: the Open Home Foundation AI Policy landed on 2026-07-20 (architecture#1432, blog) and now sits in every home-assistant repo as AI_POLICY.md. It states plainly that "we do not allow autonomous agents to be used for contributing to our projects", and requires that a contributor understand and be able to explain every change in their own words. AI assistance is permitted and should be disclosed. So this must be a human-owned PR — worth recording here, because it constrains every upstream action item this watchlist produces, not just this one.