Skip to main content
Glama

Uninstall an add-on

supervisor_uninstall_addon
DestructiveIdempotent

Permanently uninstall a Home Assistant add-on and delete its data after explicit confirmation. Blocks removing Supervisor itself; use for add-ons no longer needed, not for temporary stops.

Instructions

Uninstall an add-on and its persistent data after an explicit confirmation.

Calls POST /addons/<slug>/uninstall. Refuses to run at all against nexus's own add-on (its real slug, or the alias Supervisor resolves to the caller itself — see self_protection.is_own_addon) — checked first, with no Supervisor request made either way, before even the confirmation gate: nexus removing itself is never the right tool for that regardless of confirm. Otherwise, without confirm=True nothing is removed; the call only returns an error asking for confirmation (ADR-0003 D1).

Use when: permanently removing an add-on that is no longer needed. Not for: temporarily stopping it while keeping its data and config — use supervisor_stop_addon. Returns: Supervisor's uninstall-job result when confirmed. Errors: {"error": "invalid_slug"} for a bad slug; {"error": "self_addon_uninstall_blocked", "message": ...} when slug is nexus's own add-on; returns {"error": "confirmation_required", "message": ..., "action": ...} when confirm is false; {"error": "HTTP <status>", "detail": ...} on a Supervisor API error. Limits: WARNING: deletes the add-on's data with no separate backup step; requires confirm=True.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugYesAdd-on slug to uninstall, e.g. from `supervisor_list_addons`.
confirmNoSet true to actually uninstall the add-on and its data. False (default) performs no action.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.25.1
    • addedInput schema / properties / confirm / description
      Added value: +"Set true to actually uninstall the add-on and its data. False (default) performs no action."
    • addedInput schema / properties / slug / description
      Added value: +"Add-on slug to uninstall, e.g. from `supervisor_list_addons`."
  2. First observedv0.3.0

TDQS

A4.8/5.0
Behavior5/5

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

Goes far beyond annotations: discloses the self-protection special case (nexus's own add-on blocked with no Supervisor request made), the confirmation gate semantics (ADR-0003 D1), that data is deleted with no separate backup step, and enumerates specific error shapes. This is richer than the destructiveHint/readOnlyHint annotations alone.

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-loads the core action and the critical refusal behaviors, then uses clear labeled sections (Use when / Not for / Returns / Errors / Limits). It is longer than typical but every segment carries distinct operational value; slight verbosity in the error enumeration.

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 destructive mutation tool, it covers the action, the guard conditions, the confirm requirement, the data-loss warning, and all error paths — everything an agent needs to call it safely and interpret the result. Output schema exists so return values need not be re-explained.

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 baseline 3. The description adds meaning by tying 'confirm' to the confirmation gate behavior and explaining that the self-addon check precedes the confirm gate, which is behavioral nuance not captured in the schema's 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 a specific verb+resource ('Uninstall an add-on and its persistent data') and explicitly names the sibling it is NOT for ('supervisor_stop_addon') and the condition that distinguishes them (temporary stop vs permanent removal). An agent can route correctly without opening any schema.

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?

Provides explicit 'Use when' and 'Not for' clauses, naming the alternative tool (supervisor_stop_addon) and the exact contrasting scenario. This is the when/when-not/alternatives pattern in full.

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