Skip to main content
Glama

Append to a config file

files_append_to_config_file

Append raw text to an existing Home Assistant config file, matching list indentation, with optional YAML validation. For automations, use automations_set_automation_config.

Instructions

Append text to the end of an existing config file.

Resolves relative_path via _safe_path, reads its current text, appends content after a newline, YAML-checks the combined text only when validate_yaml=True and the extension is .yaml/.yml, then writes the combined text back.

Use when: adding raw YAML/JSON/txt lines that already match the file's existing list indentation. Not for: automations — use automations_set_automation_config, which edits by config id instead of a raw text append. Returns: dict {"success": True, "path": ...} on success, or {"success": False, "error": ...} when validate_yaml=True and the combined text fails to parse. Errors: raises FileNotFoundError when the file does not exist, and raises PermissionError (from _safe_path) for a path outside the config directory, a disallowed extension, or secrets.yaml/.storage. Limits: validate_yaml defaults to False, so an invalid append is written without warning unless explicitly checked.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
contentYesText appended after a newline to the file's existing content.
relative_pathYesPath to an existing file relative to the HA config directory (HA_CONFIG_PATH), e.g. 'automations.yaml'. Must use an allowed extension (.yaml/.yml/.json/.txt) and not touch secrets.yaml or .storage/.
validate_yamlNoIf True and the extension is .yaml/.yml, the combined text (existing content plus the appended `content`) is YAML-checked before writing. Defaults to False, so an invalid append is written without warning unless set True.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.25.1
    • addedInput schema / properties / content / description
      Added value: +"Text appended after a newline to the file's existing content."
    • addedInput schema / properties / relative_path / description
      Added value: +"Path to an existing file relative to the HA config directory (HA_CONFIG_PATH), e.g. 'automations.yaml'. Must use an allowed extension (.yaml/.yml/.json/.txt) and not touch secrets.yaml or .storage/."
    • addedInput schema / properties / validate_yaml / description
      Added value: +"If True and the extension is .yaml/.yml, the combined text (existing content plus the appended `content`) is YAML-checked before writing. Defaults to False, so an invalid append is written without warning unless set True."
  2. First observedv0.3.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, but the description goes well beyond them: it discloses the exact internal flow, that validate_yaml only triggers for .yaml/.yml extensions and defaults to False (silent invalid writes), the error types raised, and that secrets.yaml/.storage and disallowed extensions are blocked by _safe_path. This is unusually rich behavioral 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?

Well front-loaded with the core action first, then behavior, use/not-for, returns, errors, and limits in clearly labeled blocks. It is somewhat dense (e.g. the _safe_path implementation detail) but every section is informative and no sentence is pure filler.

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 3-param mutation tool with an output schema, the description covers the mechanics, validation scope, return shape, error conditions, and an important default that could cause silent data issues. Nothing an agent needs to invoke this correctly is missing.

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 meaning beyond the schema: relative_path is resolved via _safe_path, content is appended after a newline, and validate_yaml's conditionality on the extension and its False default are spelled out. Marginal but genuine added value over the parameter descriptions.

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+resource ('Append text to the end of an existing config file') and immediately differentiates from siblings by naming `automations_set_automation_config` as the alternative for automations. An agent can distinguish it from files_write_config_file or automations_set_automation_config without opening any schema.

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?

Explicit 'Use when' (adding raw YAML/JSON/txt lines matching existing indentation) and 'Not for' (automations, with the correct alternative named and the reason — edits by config id vs raw text append). This is textbook when/when-not/alternative guidance.

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