Home Assistant MCP Server

Official

by homeassistant-ai

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Delete Dashboard

ha_config_delete_dashboard

DestructiveIdempotent

Permanently delete a storage-mode dashboard and its configuration from Home Assistant. Use it to remove dashboards you no longer need; it cannot be undone, and YAML-mode dashboards are not supported.

Instructions

Delete a storage-mode dashboard completely.

WARNING: This permanently deletes the dashboard and all its configuration. Cannot be undone. Does not work on YAML-mode dashboards.

HA internal IDs may differ from url_path (e.g. hyphens → underscores); the tool resolves either form to the actual registry ID before deletion.

EXAMPLES:

Delete dashboard: ha_config_delete_dashboard("mobile-dashboard")

Note: The default dashboard cannot be deleted via this method.

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`url_path`	Yes	Dashboard URL path or internal ID to delete (e.g., 'my-dashboard' or 'my_dashboard'). Both forms are accepted.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv7.14.2Jul 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, and the description substantially enriches this: permanent, irreversible, all configuration removed, YAML-mode unsupported, default-dashboard exception, and internal-ID vs url_path resolution semantics. It even flags a known timeout/hang workaround, which is behavior no annotation conveys.

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?

Purpose and the destructive WARNING are front-loaded, followed by an example and an edge-case note, which is good ordering. The final Claude Desktop paragraph is verbose and narrow in applicability, costing a point on conciseness.

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 single-parameter destructive delete with an output schema present, the agent has everything needed: what is destroyed, irreversibility, unsupported targets, ID resolution, and the one undeletable special case. Return values are legitimately omitted since an output schema exists.

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, but the description adds real value beyond the schema by explaining that HA internal IDs may differ from url_path (hyphens become underscores) and that the tool resolves either form before deletion.

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?

Opens with a specific verb+resource+scope: 'Delete a storage-mode dashboard completely.' This distinguishes it from siblings such as ha_config_delete_dashboard_resource, ha_config_get_dashboard, and ha_config_set_dashboard without needing the schema.

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

Usage Guidelines4/5

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

Clear when-not conditions are given: it does not work on YAML-mode dashboards and cannot delete the default dashboard. However, it never names the alternative route for those cases (e.g., resource deletion or editing the YAML config), leaving the fallback 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