Skip to main content
Glama
Vortitron

home-assistant-mcp

by Vortitron
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Give a program its own Home Assistant login, without anyone seeing the password

ha_provision_service_login
Destructive

Create a non-admin Home Assistant login for an MQTT client or program, store its generated password in add-on options or secrets files, and rotate it without exposing it.

Instructions

Create a non-admin Home Assistant login for a program (an MQTT client such as Zigbee2MQTT or an energy manager, an ESPHome device, a bridge), generate its password here, and write it straight into where that program reads it: an add-on's options and/or a secrets file. The password is never returned — not to you and not to the owner — so you never have to choose, see or type one. The Mosquitto add-on accepts Home Assistant logins, so this is all an MQTT client on this home needs.

Ask the owner before calling it: it creates a standing account on their home that outlives the API key that made it. Every delivery target is checked before anything is created; a new login that could be delivered nowhere is deleted again. Use rotate=true to issue a new password to a login this tool created earlier (the old one stops working); it refuses any other account. A program outside Home Assistant with neither add-on options nor a secrets file cannot be reached from here — ask the owner to set its login. Revoke with ha_delete_user. Requires ha:config, plus ha:files for secrets_file targets.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesWhat the login is for, e.g. 'Zigbee2MQTT'.
roleNo'read_only' (default) is enough for MQTT; 'user' if the program drives HA itself.
rotateNoRe-issue the password of an existing login this tool created, and redeliver it.
usernameYesLogin name: lowercase, e.g. 'zigbee2mqtt'.
deliver_toYesWhere the program reads its login. At least one.
local_onlyNoAccept sign-in from the local network only (default true).
instance_idYesThe instance this login is for (as listed by vomehome_list_instances). Checked against the one this session is targeting; refused if they differ.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.10.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations flag this as destructive and open-world, and the description adds real substance beyond them: the password is never returned, the account is standing and outlives the API key, delivery targets are validated before creation with delete-on-failure rollback, rotate invalidates the old password, and it requires ha:config (plus ha:files for secrets_file targets).

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 core action and the never-seen password guarantee, then layers prerequisites, rotation, limitations and revocation. Slightly long, but each sentence carries distinct operational information rather than restating the schema.

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 destructive, credentialed mutation with no output schema, the description covers prerequisites, permission scopes, rollback on failed delivery, rotation semantics, reachability limits, and the revoke path. An agent has everything needed to call it correctly or refuse.

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 goes beyond it by explaining rotate's contract (new password, old one stops working, refuses other accounts) and framing deliver_to as 'where the program reads its login' with the Mosquitto context for role/login use.

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 (create a non-admin login), the exact resource (Home Assistant login for a program), and the mechanism that makes it distinct (password generated and written directly to an add-on's options/secrets file, never exposed). It is clearly distinguishable from siblings like ha_create_user, ha_set_user_credentials and ha_delete_user.

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 when-to-use and when-not-to-use guidance: ask the owner first, use rotate=true only for a login this tool previously created, and a program with neither add-on options nor a secrets file cannot be reached at all. It also names the revocation alternative (ha_delete_user).

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