Skip to main content
Glama
Sign In
Home Assistant MCP Server

Home Assistant MCP Server

Official
by homeassistant-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Manage Updates

ha_manage_updates
Destructive

List, install, skip, or inspect Home Assistant updates and dismiss Repairs issues. Check pending Core, OS, add-on, firmware, and HACS updates before applying them.

Instructions

Manage Home Assistant updates (list, details, install, skip) and Repairs issues (ignore).

Covers Core, OS, supervisor, apps (add-ons), device firmware, and HACS update entities, plus the Repairs issues in Settings > System > Repairs. Repairs are listed by ha_get_overview (not here); pass their domain and issue_id to 'ignore_repair' / 'unignore_repair'. In Read Only Mode the read actions ('list', 'get') stay available; write actions are blocked.

'install' blocks until each update finishes (minutes). One that outlasts the request timeout ends the call with a connection timeout while it keeps running, and a Core update restarts Home Assistant; neither means failure, but later batch targets were not started. Confirm per entity with action='get'; finished updates drop out of 'list', which also returns ha_mcp_update — this MCP server's own update status {current, latest, update_available; python_required + upgrade_command if it needs another Python}.

EXAMPLES:

  • Pre-update analysis: ha_manage_updates(action="get", entity_ids=["update.home_assistant_core_update"], include_release_notes=True)

  • Update everything pending in a category: ha_manage_updates(action="install", categories=["addons", "hacs"])

  • Dismiss a repair: ha_manage_updates(action="ignore_repair", repairs=[{"domain": "sun", "issue_id": "abc"}])

If a Claude Desktop user gets a 4-minute timeout with no result on this call, read the target back before repeating it, and tell them to wait a few seconds before clicking the manual-approve button, as clicking it too quickly is known to cause hangs in Claude Desktop. This workaround is specific to Claude Desktop.

update updates install skip firmware core os repair repairs issue ignore dismiss unignore

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "ha_manage_updates"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionNo'list' (all pending updates, default), 'get' (details/release notes for one update), 'install' (apply pending updates), 'skip' (hide the offered version), 'clear_skipped' (re-offer a skipped version), 'ignore_repair' (dismiss Repairs issues, as the Repairs UI's Ignore does), or 'unignore_repair' (show them again).list
backupNoFor install: create a backup before installing where the update entity supports it (apps (add-ons)).
repairsNoFor ignore_repair / unignore_repair: the Repairs issues to act on, as [{'domain': ..., 'issue_id': ...}] taken from ha_get_overview's repairs.
categoriesNoFor install: apply every pending update in these categories ('addons', 'hacs', 'devices', 'other'). As with the HA 'Update all' button, core/os/supervisor are excluded (target those individually via entity_ids) and skipped updates are never included.
entity_idsNoUpdate entity_id(s) to act on. 'get' takes exactly one; skip/clear_skipped require at least one; for install, mutually exclusive with categories.
include_skippedNoFor list: include updates that have been skipped.
include_release_notesNoFor get on a Core update entity: fetch multi-version release notes and breaking changes for all versions between installed and latest. Adds breaking_changes, multi_version_release_notes, and installed_integrations to the response.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv8.6.0
    • changedInput schema / properties / action / description
      Previous value: -"'list' (all pending updates, default), 'get' (details/release notes for one update), 'install' (apply pending updates), 'skip' (hide the offered version), or 'clear_skipped' (re-offer a skipped version)."New value: +"'list' (all pending updates, default), 'get' (details/release notes for one update), 'install' (apply pending updates), 'skip' (hide the offered version), 'clear_skipped' (re-offer a skipped version), 'ignore_repair' (dismiss Repairs issues, as the Repairs UI's Ignore does), or 'unignore_repair' (show them again)."
    • changedInput schema / properties / backup / description
      Previous value: -"For install: create a backup before installing where the update entity supports it (apps/add-ons). Default: False."New value: +"For install: create a backup before installing where the update entity supports it (apps (add-ons))."
    • changedInput schema / properties / categories / description
      Previous value: -"For install: apply every pending update in these categories ('addons', 'hacs', 'devices', 'other'). Mirrors the HA 2026.7 'Update all' button: core/os/supervisor are excluded by design (target those individually via entity_ids) and skipped updates are never included."New value: +"For install: apply every pending update in these categories ('addons', 'hacs', 'devices', 'other'). As with the HA 'Update all' button, core/os/supervisor are excluded (target those individually via entity_ids) and skipped updates are never included."
    • changedInput schema / properties / include_release_notes / description
      Previous value: -"For get on a Core update entity: fetch multi-version release notes and breaking changes for all versions between installed and latest (default: False). Adds breaking_changes, multi_version_release_notes, and installed_integrations to the response."New value: +"For get on a Core update entity: fetch multi-version release notes and breaking changes for all versions between installed and latest. Adds breaking_changes, multi_version_release_notes, and installed_integrations to the response."
    • changedInput schema / properties / include_skipped / description
      Previous value: -"For list: include updates that have been skipped (default: False)."New value: +"For list: include updates that have been skipped."
    • addedInput schema / properties / repairs
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "For ignore_repair / unignore_repair: the Repairs issues to act on, as [{'domain': ..., 'issue_id': ...}] taken from ha_get_overview's repairs."
+}
  2. First observedv7.14.2

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already flag destructive=true and readOnly=false, but the description adds much more: install blocks for minutes, a timeout does not mean failure and leaves remaining batch targets unstarted, Core updates restart Home Assistant, and finished updates drop out of list. It also discloses the read-only-mode gating and the ha_mcp_update self-status payload, which are behaviors no annotation could convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then coverage, then operational caveats, then examples — a sensible ordering with dense but non-redundant sentences. The closing Claude Desktop timeout/hang workaround paragraph is tangential to tool selection and invocation, and reads more like embedded operator instructions than tool documentation, which costs it a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter mutation tool spanning updates and repairs, the description covers scope, selection rules, side effects, timeout semantics, read-only behavior, and even the extra ha_mcp_update return key. An output schema exists, yet the one non-obvious return element is still called out, leaving nothing an agent needs missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, and the description still adds meaning on top: it explains that categories mirrors the HA 'Update all' button and therefore excludes core/os/supervisor, that skipped updates are never picked up, and what include_release_notes injects into the response. The added value is real, though most of it is restated from the schema field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States the resource (Home Assistant update entities plus Repairs issues) and enumerates the specific verbs: list, get, install, skip, clear_skipped, ignore_repair, unignore_repair. It also carves out scope against a sibling by saying 'Repairs are listed by ha_get_overview (not here)', so an agent can tell exactly what this tool does and does not own.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit routing rules: use ha_get_overview to obtain repairs before calling ignore_repair, use entity_ids instead of categories for core/os/supervisor, and note that read actions survive Read Only Mode while writes are blocked. Three concrete examples show the intended call shapes, and the entity_ids/categories mutual exclusivity is stated as a selection constraint rather than left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools