Skip to main content
Glama

Write ESPHome device YAML config

esphome_write_config
DestructiveIdempotent

Validate YAML syntax and write a complete ESPHome device configuration to /config/esphome/, replacing any existing file only if validation succeeds.

Instructions

Write a full ESPHome device YAML config to /config/esphome/, overwriting any existing file.

Validates YAML syntax first (HA custom tags !secret/!include/ !lambda/!extend/!remove pass through unchanged) and only writes if that succeeds. This replaces the whole file — there is no merge with the previous content and, unlike git_safe_write_with_checkpoint, no checkpoint commit is made first, so the previous content is not recoverable through this tool.

Use when: saving a complete device config you already have in full, e.g. after fetching and editing it with esphome_get_config. Not for: a git-checkpointed config write — use git_safe_write_with_checkpoint; for a generic /config file write use files_write_config_file; for a single LVGL widget edit use esphome_lvgl_add_widget/esphome_lvgl_delete_widget instead of hand-editing the whole YAML text. Returns: {"success": True, "name": ..., "path": ..., "bytes": ...} on success; a remote external_components:/packages: source (github:///gitlab:///codeberg:///git:///http(s)://, or a dict with a url) adds "warning" (review before esphome_compile_device, which fetches and runs it) and "external_sources": [...]; a config with none, or only local (type: local, bare-path, !include) ones, gets neither key. Errors: {"success": False, "error": "YAML validation failed: ..."} for invalid YAML; {"success": False, "error": "Invalid device name: ..."} for a path-escaping name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesDevice name, with or without the '.yaml' suffix, e.g. 'kitchen_sensor'. If the file already exists, its entire content is replaced.
contentYesFull YAML document to write, replacing the file's current content.

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 / content / description
      Added value: +"Full YAML document to write, replacing the file's current content."
    • addedInput schema / properties / name / description
      Added value: +"Device name, with or without the '.yaml' suffix, e.g. 'kitchen_sensor'. If the file already exists, its entire content is replaced."
  2. Addedv0.18.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, yet the description adds real context beyond them: validation-before-write, HA custom tag pass-through, no checkpoint so prior content is unrecoverable, plus remote external_components/packages sources triggering a warning and error shapes. This is unusually rich disclosure for a mutation tool.

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 operation and then segments behavior, usage, returns and errors in labeled blocks, so it is scannable. It is longer than strictly necessary for a 2-parameter tool, but nearly every sentence earns its place given the destructive semantics.

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?

Covers the destructive consequence and irrecoverability, validation gating, the warning path for remote sources, and both error variants. An output schema exists, yet the return-shape detail adds value rather than duplicating boilerplate.

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 semantics beyond the schema: HA custom tags (!secret/!include/!lambda) pass through unchanged in content, and a path-escaping name yields a specific 'Invalid device name' error. Minor value-add over the schema, not a full replacement.

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 and resource (write full ESPHome device YAML config to /config/esphome/) and immediately names the scope constraint (overwrites existing file, no merge). It explicitly differentiates from siblings git_safe_write_with_checkpoint, files_write_config_file, and the LVGL widget tools.

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?

Uses an explicit 'Use when' / 'Not for' structure naming four concrete alternatives and the conditions that select them (git-checkpointed write, generic /config write, single LVGL widget edit). No inference required.

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