Skip to main content
Glama

Add card to dashboard section

dashboards_add_card_to_section

Insert a Lovelace card into a specific section of a sections-type dashboard view, leaving other views intact. Optionally guard against stale reads with a config hash.

Instructions

Insert a card into one section of a type: sections view, leaving every other view intact.

Resolves the view via _load_view, requires it to be a sections view, inserts card_config into that section's cards list at position (or the end), and saves the whole dashboard back. This is the only way to make a card visible on a sections view — dashboards_add_card_to_view writes to view.cards, which such a view renders only in edit mode. When expected_config_hash is given, it is checked against the dashboard's hash right after the read and before any change, so a stale caller never overwrites the wrong section.

Use when: adding a card to a specific section of a sections view. Pass expected_config_hash whenever section_index/position came from an earlier read that might now be stale. Not for: a masonry/panel view — use dashboards_add_card_to_view. Returns: {status: "added", url_path, view_index, view_title, section_index, card_index, cards_in_section, config_hash} — config_hash is re-read from HA after the save (not the locally built dict), ready to chain into the next call's expected_config_hash. Errors: raises ValueError when card_config has no type key, the view can't be resolved, isn't a sections view, or section_index is out of range. Returns {"error": "config_changed", "expected_config_hash", "current_config_hash", "action"} without saving when expected_config_hash doesn't match.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
positionNoZero-based index within the section to insert at. Omit to append at the end.
url_pathYesDashboard url_path, or a view path in the default dashboard (e.g. 'living-room').
view_indexNoZero-based view index; needed only when url_path names a dashboard rather than a view path.
card_configYesLovelace card config with a 'type' key, e.g. {'type': 'tile', 'entity': 'sensor.power'}.
section_indexYesZero-based target section index, from dashboards_get_view_sections.
expected_config_hashNoOptional guard: the config_hash from a recent dashboards_get_view_sections or section-tool response. If the dashboard's current hash differs, this call returns 'config_changed' and saves nothing, since section_index/position are positions, not stable ids, and a change since your read may target the wrong section. Omit to skip the check (today's behaviour).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.25.1

TDQS

A4.4/5.0
Behavior4/5

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

Annotations cover mutation/safety (readOnly=false, destructive=false, idempotent=false), but the description adds critical context: the internal resolve/insert/save sequence, the reason positional indices are risky, the config-version guard behavior, and both the success payload and the ValueError/'config_changed' failure modes. It stops short of stating permission requirements or whether the dashboard must exist, so not a 5.

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 purpose, then mechanics, then the explicit Use when/Not for/Returns/Errors blocks. It is longer than most MCP descriptions, but every clause carries a distinct fact; only slight tightening of the mechanics paragraph would help.

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 mutation tool with a nested card_config object and a ConcurrencyGuard parameter, the description supplies returns, error contract, hash semantics, and sibling routing. An agent has everything needed to call it correctly, including recovery from 'config_changed'.

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 description coverage is 100%, so parameters are already well-documented. The description reinforces meaning (position, expected_config_hash, section_index) but adds no format details beyond what the schema states, which matches the baseline for full 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?

States a specific verb+resource with exact scope: 'Insert a card into one section of a type: sections view, leaving every other view intact.' It explicitly differentiates from the sibling dashboards_add_card_to_view by naming its behavior on a sections view.

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?

Provides explicit 'Use when' and 'Not for' sections naming the alternative (dashboards_add_card_to_view) for masonry/panel views, plus the condition for passing expected_config_hash. The routing logic is unambiguous.

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