Skip to main content
Glama
homeassistant-ai

Home Assistant MCP Server

Official

Manage Blueprints

ha_manage_blueprints
Destructive

Manage Home Assistant blueprints — list, read, import, save, delete, or render standalone configs from automation and script blueprints.

Instructions

Manage Home Assistant blueprints — list, read, import, save, delete, or render a standalone config.

One interface for the whole blueprint lifecycle in the automation and script domains.

DO NOT use this to create an automation or script FROM a blueprint — that is ha_config_set_automation / ha_config_set_script with a use_blueprint config.

Use action="list" to discover installed blueprints, action="get" for one blueprint's metadata, inputs and YAML, action="import" to install one from a URL, action="save" to write YAML text to a blueprint path, action="delete" to remove an installed one, and action="substitute" to render a blueprint plus inputs into a standalone config (the UI's "Take control"). To duplicate a blueprint, get it and save its yaml under a new path; to edit one in place, get it, change the text, and save it back to the same path with overwrite=True.

get also reports used_by: the automations or scripts built on the blueprint, which is the UI's "Show automations using this blueprint". Check it before deleting — Home Assistant refuses to delete a blueprint anything still uses, and it goes on counting a consumer that has since taken control of its own config until that consumer is removed.

CAVEATS: get returns the on-disk YAML only when something can read it — an in-process server, the ha_mcp_tools component, the File & YAML Tools entry, or the blueprint's source_url; yaml_source names which one answered, and source_url text is a fresh download that can differ from the installed file. Core's blueprint API alone exposes metadata only, so a locally authored blueprint on a bare install has no readable text. save needs overwrite=True to replace an existing path and reloads every automation/script using it. delete requires confirm=True, and Home Assistant refuses it while any automation or script still uses the blueprint — the error lists the consumers. Both writes are snapshotted first when a copy can be read, so ha_manage_backup(scope="edits") can restore the previous file. substitute only renders — it writes nothing, so pass the returned config to ha_config_set_automation / ha_config_set_script to persist it. To convert an automation or script that ALREADY exists, prefer ha_config_set_automation / ha_config_set_script with take_control_of_blueprint=True: it renders with that item's own current inputs and saves the result over itself in one call, where substitute would need those inputs restated and the config written back by hand. Taking control does NOT free the blueprint — Home Assistant goes on counting a converted automation or script as a user of it, so delete stays refused until the consumers are removed.

EXAMPLES:

  • List: ha_manage_blueprints(action="list", domain="automation")

  • Get one (with its consumers in used_by): ha_manage_blueprints(action="get", path="homeassistant/motion_light.yaml")

  • Import: ha_manage_blueprints(action="import", url="https://example.com/bp.yaml")

  • Duplicate: ha_manage_blueprints(action="save", path="user/my_copy.yaml", yaml=)

  • Edit in place: ha_manage_blueprints(action="save", path="user/motion.yaml", yaml=, overwrite=True)

  • Delete: ha_manage_blueprints(action="delete", path="user/motion.yaml", confirm=True)

  • Detach: ha_manage_blueprints(action="substitute", path="user/motion.yaml", input={"motion_sensor": "binary_sensor.hall"})

  • Convert an existing consumer to a standalone config: ha_config_set_automation(identifier="automation.hall", take_control_of_blueprint=True)

RELATED TOOLS: ha_config_set_automation / ha_config_set_script to build on a blueprint or persist a substituted config, ha_config_remove_automation / ha_config_remove_script to clear consumers blocking a delete, ha_search to find them, and ha_manage_backup(scope="edits") to restore a deleted blueprint.

blueprint blueprints import delete remove unused substitute take-control list ha_get_blueprint ha_import_blueprint

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoURL to import from — GitHub, Home Assistant Community, or a direct YAML link (action='import')
pathNoInstalled blueprint path, e.g. 'homeassistant/motion_light.yaml' (action='get' / 'save' / 'delete' / 'substitute'). 'save' appends '.yaml' when it is missing, as Home Assistant does.
yamlNoBlueprint YAML text to write (action='save')
inputNoBlueprint input values keyed by input name (action='substitute'); defaults to {}
actionYes'list' installed blueprints, 'get' one blueprint's metadata/inputs/YAML, 'import' one from a URL, 'save' YAML text to a blueprint path, 'delete' an installed one, or 'substitute' to render a standalone config
domainNoBlueprint domain: 'automation' or 'script'. Ignored by action='import' — the blueprint file declares its own domain.automation
confirmNoRequired confirmation for action='delete'
overwriteNoWrite over an already-installed blueprint (action='import' / 'save'). Home Assistant reloads every automation/script using it.
source_urlNoOrigin URL to stamp into the saved blueprint's metadata (action='save'); omit for a hand-authored blueprint

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv8.5.0

TDQS

A5/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and readOnlyHint=false, and the description goes far beyond that: it details overwrite behavior, reload side effects, confirmation requirements, snapshotting for backup, refusal of delete while consumers exist, the conditions under which 'get' returns YAML, and the fact that 'substitute' writes nothing. It even explains the non-obvious persistence of consumer counts after taking control. This is exemplary transparency with no contradictions.

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?

Despite being long, the description is tightly structured with clear sections (main description, CAVEATS, EXAMPLES, RELATED TOOLS). Every sentence earns its place—no filler. The core purpose is front-loaded, and the detailed caveats are logically organized. For a tool with 9 parameters and 6 actions, this length is justified and well-presented.

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 tool's complexity, the description covers all actions, all parameters, edge cases, side effects, prerequisites, and related tools. It includes practical examples for every action and explains subtle behaviors like the 'take control' caveat. The presence of an output schema presumably documents return values, so nothing an agent needs to call this correctly is missing.

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

Parameters5/5

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

Schema coverage is 100%, so each parameter is already documented, but the description adds substantial semantic context: the interplay between actions and parameters (e.g., overwrite for save/import, confirm for delete), the meaning of yaml_source, how to duplicate via get+save, and domain being ignored by import. It also gives concrete examples that map parameters to actions. This far exceeds the baseline 3 for high coverage.

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 states a specific verb and resource ('Manage Home Assistant blueprints') and enumerates all six actions (list, read, import, save, delete, substitute). It explicitly distinguishes itself from sibling tools like ha_config_set_automation/ha_config_set_script, clarifying that it does not create automations from blueprints. This fully resolves the purpose.

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?

The description provides explicit when-to-use and when-not-to-use guidance, naming alternatives: 'DO NOT use this to create an automation or script FROM a blueprint — that is ha_config_set_automation / ha_config_set_script with a use_blueprint config.' It also explains preferred approaches for converting existing consumers and references related tools for cleanup. Nothing is 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