Skip to main content
Glama
Fistacho

ha-nexus-agent

by Fistacho
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Create or overwrite an automation config

automations_set_automation_config
DestructiveIdempotent

Creates or replaces a Home Assistant automation config by ID, then reloads automations. Replaces the entire config, not for partial edits.

Instructions

Create or replace the automation whose config id is automation_id.

Posts config to /api/config/automation/config/<id>, replacing the whole stored config at that id (or creating a new automation if the id is unused), then calls the automation.reload service.

Not for: editing a single field without resending the rest of the config — this tool always replaces the whole stored config. Returns: dict {"status": "saved", "automation_id", "result"}. Errors: returns {"error": "config must be a dict"} when config isn't a dict, or {"error": "config must contain at least 'alias' or 'trigger'/'triggers'"} when both are missing. Limits: no confirm parameter; an existing automation at automation_id is replaced without a prompt.

Input Schema

NameRequiredDescriptionDefault
configYesFull automation config replacing whatever is stored at `automation_id` (alias, triggers, conditions, actions, mode). Must contain 'alias' or 'trigger'/'triggers'.
automation_idYesAutomation config id to create or replace — the entity's `id` attribute, not its entity_id. An id that does not exist yet creates a NEW automation instead of editing one; read the current id from `entities_get_entity(entity_id)` -> attributes.id before editing.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.25.1
    • addedInput schema / properties / automation_id / description
      Added value: +"Automation config id to create or replace — the entity's `id` attribute, not its entity_id. An id that does not exist yet creates a NEW automation instead of editing one; read the current id from `entities_get_entity(entity_id)` -> attributes.id before editing."
    • addedInput schema / properties / config / description
      Added value: +"Full automation config replacing whatever is stored at `automation_id` (alias, triggers, conditions, actions, mode). Must contain 'alias' or 'trigger'/'triggers'."
  2. First observedv0.3.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare destructive and idempotent behavior, but the description adds concrete operational detail: it posts to a specific endpoint, calls automation.reload, returns a status dict, describes error conditions, and critically states there is no confirmation prompt when replacing an existing automation. This goes well beyond the annotations.

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?

The description is front-loaded and structured with clear labels (Not for, Returns, Errors, Limits). It is somewhat long, and the Returns dict is partially redundant given an output schema exists, but most sentences add valuable behavioral or usage context.

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 destructive mutation, complete parameter schema, annotations, and output schema, the description supplies everything an agent needs: full-replacement semantics, reload side effect, no confirmation behavior, and error contracts. No critical information 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%, so both parameters are already well described in the schema. The description mainly reinforces the full-replacement meaning of config and adds error wording, but it does not materially extend 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 states a precise verb (Create or replace) and resource (the automation whose config id is automation_id), and clarifies that it replaces the whole stored config. It is clearly distinguishable from siblings like automations_get_automation_config, automations_delete_automation, and automations_set_scene_config/script_config.

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?

It explicitly tells the agent when not to use the tool (editing a single field without resending the rest) and implies when to use it (full create or replace). However, it does not name a specific alternative tool or describe prerequisites beyond the config id.

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