Skip to main content
Glama

Remove a config entry

integrations_remove_integration
DestructiveIdempotent

Permanently uninstall a Home Assistant integration by deleting its config entry with explicit confirmation. Use when you want to fully remove an integration, not just disable it.

Instructions

Remove (uninstall) an integration's config entry after an explicit confirmation.

Calls DELETE /api/config/config_entries/entry/{entry_id} — there is no config_entries/remove WebSocket command. HA unloads the integration and deletes its entry; any devices/entities it owned typically go with it. Without confirm=True nothing is removed.

Use when: an integration is no longer wanted and should be fully uninstalled, not just disabled. Not for: keeping the entry but pausing it — use integrations_disable_integration. Returns: HA's removal result when confirmed, otherwise a confirmation prompt. Errors: returns {"error": "confirmation_required", "message": ..., "action": ...} when confirm is false; raises httpx.HTTPStatusError if entry_id does not exist. Limits: requires confirm=True; deletes the entry and its devices/entities with no separate backup step.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
confirmNoSet true to actually remove the integration. False (default) performs no action and instead returns a confirmation prompt.
entry_idYesConfig entry ID to remove, from `system_list_integrations` or `system_get_all_integrations`.

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 remove the integration. False (default) performs no action and instead returns a confirmation prompt."
    • addedInput schema / properties / entry_id / description
      Added value: +"Config entry ID to remove, from `system_list_integrations` or `system_get_all_integrations`."
  2. Changed1 schema field changedv0.18.1
    • addedInput schema / properties / confirm
      Added value: +{
      +  "default": false,
      +  "type": "boolean"
      +}
  3. Addedv0.4.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already indicate destructive=true and readOnly=false, but the description adds crucial behavior: confirmation is mandatory, nothing is removed without `confirm=True`, devices/entities are deleted with no separate backup, and the exact error shape for missing confirmation or bad entry_id.

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

Conciseness5/5

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

The description is front-loaded with purpose and usage, then structured into useful sections for endpoint, returns, errors, and limits. Every part contributes to safe invocation of a destructive tool.

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?

Given the rich annotations, full schema coverage, and existing output schema, the description provides all remaining context an agent needs: confirmation requirement, destructive scope, error handling, and alternative tool. Nothing essential 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 coverage is 100%, and the schema already fully documents `confirm` and `entry_id`, including the confirmation prompt behavior and source of entry_id. The description reinforces these points but does not add significant new parameter semantics beyond what the schema provides.

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 description opens with a specific verb and resource: 'Remove (uninstall) an integration's config entry'. It also explicitly distinguishes this from merely disabling the integration and names the sibling tool to use instead.

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 'Use when' and 'Not for' sections, including the alternative `integrations_disable_integration` for pausing. The condition for choosing this tool versus the sibling is fully specified.

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