Skip to main content
Glama
homeassistant-ai

Home Assistant MCP Server

Official
by homeassistant-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Manage Updates

ha_manage_updates
Destructive

List, review, install, or skip Home Assistant updates across Core, OS, add-ons, firmware, and HACS, and ignore or restore Repairs issues.

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.

Installs run asynchronously in Home Assistant and can take minutes: 'install' returns once the service calls are accepted, with per-entity results. Poll action='list' to watch in_progress until installed_version reaches latest_version. action='list' also returns ha_mcp_update — this MCP server's own update status {current, latest, update_available}, so a newer ha-mcp release can be flagged.

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

Input Schema

TableJSON 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

TableJSON 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.5/5.0
Behavior5/5

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

Beyond the annotations (destructiveHint=true, idempotentHint=false, openWorldHint=true), the description discloses genuinely non-obvious behavior: installs run asynchronously and return before completion, per-entity results are returned, polling action='list' is the way to track progress, and ha_mcp_update is surfaced in list output. The Read Only Mode gating and the Claude Desktop timeout workaround are additional operational context the annotations cannot convey.

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

Conciseness3/5

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

Purpose and behavior are front-loaded and the examples are useful, but the prose is long and the trailing keyword-stuffing list ('update updates install skip firmware core os repair repairs issue ignore dismiss unignore') is pure noise. The extended Claude Desktop timeout paragraph, while helpful, is disproportionate to the call itself.

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?

An output schema exists, yet the description still covers the essentials an agent needs: async install semantics, how to verify completion, Read Only Mode gating, and where repairs originate. Nothing material for correct invocation is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents every parameter including the categories exclusion rule and the entity_ids/categories mutual exclusivity. The description reinforces usage via examples but adds little syntax or meaning beyond what the schema provides, so the baseline 3 applies.

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?

The opening sentence names specific verbs (list, details, install, skip, ignore) against a specific resource (Home Assistant updates and Repairs issues), so the tool's scope is unambiguous. It further disambiguates from the sibling ha_get_overview by stating that Repairs are listed there, not here.

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?

It gives explicit action-by-action routing, names the alternative tool for listing repairs, states the Read Only Mode behavior (read actions stay, writes blocked), and provides three concrete examples showing which action/parameters to combine. There is little left to infer.

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