Skip to main content
Glama
homeassistant-ai

Home Assistant MCP Server

Official

Get Integration

ha_get_integration
Read-onlyIdempotent

Retrieve Home Assistant integration config entries, filter by domain or title, and inspect options, schemas, subentries, or diagnostics for setup and troubleshooting.

Instructions

Get integration (config entry) information with pagination.

Without an entry_id: Lists all configured integrations with optional filters. With an entry_id: Returns detailed information including full options/configuration.

EXAMPLES:

  • List / search: ha_get_integration(query="zigbee")

  • Get an entry with its editable fields: ha_get_integration(entry_id="abc123", include_schema=True)

  • Diagnostics dump, paged along a list-valued path: ha_get_integration(entry_id="abc123", include_diagnostics=True, diagnostics_data_path="", diagnostics_data_limit=10, diagnostics_data_offset=20)

  • Inspect a subentry reconfigure schema: ha_get_integration(entry_id="abc123", include_subentry_schema=True, subentry_type="conversation", subentry_id="sub123")

  • List template entries with their options: ha_get_integration(domain="template")

STATES: 'loaded', 'setup_error', 'setup_retry', 'not_loaded', 'failed_unload', 'migration_error'.

OPTIONS: options reflect the entry's persisted values. Values that match a secrets.yaml entry are returned as "**redacted**". Use include_schema=True to see every editable field and its default/type. The shape depends on the read path, which the response does not name: when the ha_mcp_tools custom component serves the read, options are the stored mapping as-is, so a field never set may be absent and a section's fields stay nested under the section key (e.g. a template helper's additional_options). Otherwise they are read from the options flow form, which shows unset fields at their schema default and lists a section's fields at the top level. Check both places for a section field.

Each entry carries log_level: the canonical Python logger level name (DEBUG/INFO/WARNING/ERROR/CRITICAL) when the integration has a log-level override (set one with ha_set_integration(log_level=...)), or "DEFAULT" (uppercase sentinel) when no override is set; and log_level_raw: the original numeric level (e.g. 10 for DEBUG) when HA returned an int, None otherwise. This is distinct from the app side, where ha_get_app returns Supervisor's lowercase "default" literal — do not cross-compare.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax entries to return per page in list mode
queryNoWhen listing, search by domain or title.
domainNoFilter by integration domain (e.g. 'template', 'group'). When set, includes the full options/configuration for each entry.
offsetNoNumber of entries to skip for pagination
entry_idNoConfig entry ID to get details for.
device_idNoWith include_diagnostics=True, return the device-scoped diagnostics dump for this device instead of the full integration dump. Some integrations only expose config-entry-level dumps.
exact_matchNoUse exact substring matching for query filter. Set to False for fuzzy matching when the query may contain typos.
subentry_idNoExisting subentry ID used with include_subentry_schema=True to inspect a reconfigure flow.
subentry_typeNoIntegration-defined subentry type used with include_subentry_schema=True.
include_schemaNoWhen entry_id is set, also return the options flow schema (available fields and their types). Only applies when supports_options=true.
include_optionsNoInclude the options object for each entry. Automatically enabled when domain filter is set. For UI-created flow-based helpers (template, group, utility_meter, derivative, ...), the current config — template body, group members, source entity, etc. — is surfaced here by probing the options flow. Prefer this over include_schema when you only need to read the current values; use include_schema when you also need the field types or selector metadata.
diagnostics_fieldsNoTop-level keys to keep from the diagnostics data payload (e.g. ['home_assistant', 'issues']). Accepts a JSON list or comma-separated string. Only applies when include_diagnostics=True and the data payload is a dict. Unknown keys are dropped and listed under omitted_fields.
include_subentriesNoWhen entry_id is set, include config subentries for the integration entry.
include_diagnosticsNoWhen entry_id is set, also fetch the integration's diagnostics dump — integration-defined JSON (commonly includes redacted config, device list, state snapshots; exact top-level keys vary by integration), the same artifact as the UI's 'Download diagnostics'. Payloads can be large (Hue ~290 KB, ZHA/MQTT/ESPHome several MB) — pair with diagnostics_fields or diagnostics_truncate_at_bytes.
include_knx_projectNoWhen entry_id is a KNX config entry, also return the parsed ETS project: the full group-address table (address, name, DPT, description) under knx_project.group_addresses, plus the group-range hierarchy and project metadata. This GA table is not in the diagnostics dump; per-entity GA assignments are (config_store / configuration_yaml). Ignored (with a warning) when the entry is not a KNX integration. KNX exposes a single project, so the result is the same for every KNX entry_id.
diagnostics_data_pathNoDotted path into the diagnostics data sub-tree (e.g. '<list-valued path>' for per-device records, 'home_assistant.version' for HA core version; the exact key path varies by integration version). Walks into the post-fields payload. Resolution failures replace data with null and surface data_path_error. Only applies when include_diagnostics=True.
show_advanced_optionsNoWhen include_subentry_schema=True, ask older Home Assistant versions to expose advanced flow options. No-op on HA 2026.6+; pending removal before HA 2027.6.
diagnostics_data_limitNoPagination window size for list-valued diagnostics_data_path results. When set with a list-resolved path, swaps data for a pagination envelope {path, items, offset, limit, total, has_more}. Default None returns the full resolved value. Only applies when include_diagnostics=True.
diagnostics_data_offsetNoPagination start index for list-valued diagnostics_data_path results. Ignored when diagnostics_data_path is unset, diagnostics_data_limit is unset, or the resolved value is not a list. Only applies when include_diagnostics=True.
include_subentry_schemaNoWhen entry_id is set, return introspection-only config subentry schema information; no subentry is created. Pair with subentry_type, and optionally subentry_id for reconfigure schema.
diagnostics_truncate_at_bytesNoByte cap on the serialized diagnostics payload (after diagnostics_fields and diagnostics_data_path have been applied). On hit, drops data and emits truncated=true, bytes_total, byte_cap, plus available_fields (when the capped value is a dict). Recommended starting point: 20000 bytes. Only applies when include_diagnostics=True.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed15 schema fields changedv8.6.0
    • changedInput schema / properties / device_id / description
      Previous value: -"Optional. When set with include_diagnostics=True, returns the device-scoped diagnostics dump for that specific device under the integration (rather than the full integration dump). Some integrations only expose config-entry-level dumps; others expose both."New value: +"With include_diagnostics=True, return the device-scoped diagnostics dump for this device instead of the full integration dump. Some integrations only expose config-entry-level dumps."
    • changedInput schema / properties / diagnostics_data_limit / description
      Previous value: -"Pagination window size for list-valued diagnostics_data_path results. When set with a list-resolved path, swaps data for a pagination envelope {path, items, offset, limit, total, has_more}. Default None returns the full resolved value. Workflow: probe with a list-valued diagnostics_data_path and diagnostics_data_limit=10 to walk a large list one page at a time (the exact path varies by integration version). Only applies when include_diagnostics=True."New value: +"Pagination window size for list-valued diagnostics_data_path results. When set with a list-resolved path, swaps data for a pagination envelope {path, items, offset, limit, total, has_more}. Default None returns the full resolved value. Only applies when include_diagnostics=True."
    • changedInput schema / properties / diagnostics_data_offset / description
      Previous value: -"Pagination start index (default 0) for list-valued diagnostics_data_path results. Ignored when diagnostics_data_path is unset, diagnostics_data_limit is unset, or the resolved value is not a list. Only applies when include_diagnostics=True."New value: +"Pagination start index for list-valued diagnostics_data_path results. Ignored when diagnostics_data_path is unset, diagnostics_data_limit is unset, or the resolved value is not a list. Only applies when include_diagnostics=True."
    • changedInput schema / properties / diagnostics_data_path / description
      Previous value: -"Optional dotted path into the diagnostics data sub-tree (e.g. '<list-valued path>' for per-device records, 'home_assistant.version' for HA core version; the exact key path varies by integration version). Walks into the post-fields payload. Resolution failures replace data with null and surface data_path_error. Use this when the interesting payload lives several levels deep — top-level diagnostics_fields can't address sub-trees on integrations where the bulk lives under one key (ZHA, MQTT, ESPHome). Only applies when include_diagnostics=True."New value: +"Dotted path into the diagnostics data sub-tree (e.g. '<list-valued path>' for per-device records, 'home_assistant.version' for HA core version; the exact key path varies by integration version). Walks into the post-fields payload. Resolution failures replace data with null and surface data_path_error. Only applies when include_diagnostics=True."
    • changedInput schema / properties / diagnostics_fields / description
      Previous value: -"Optional list of top-level keys to keep from the diagnostics data payload (e.g. ['home_assistant', 'issues']). Trims the payload before it hits the LLM context budget. Accepts a JSON list or comma-separated string. Only applies when include_diagnostics=True and the data payload is a dict. Unknown keys are silently dropped and surfaced via the omitted_fields sub-key."New value: +"Top-level keys to keep from the diagnostics data payload (e.g. ['home_assistant', 'issues']). Accepts a JSON list or comma-separated string. Only applies when include_diagnostics=True and the data payload is a dict. Unknown keys are dropped and listed under omitted_fields."
    • changedInput schema / properties / diagnostics_truncate_at_bytes / description
      Previous value: -"Optional byte cap on the serialized diagnostics payload (after diagnostics_fields and diagnostics_data_path have been applied). On hit, drops data and emits truncated=true, bytes_total, byte_cap, plus available_fields (when the capped value is a dict). Recommended starting point: 20000 bytes. Only applies when include_diagnostics=True."New value: +"Byte cap on the serialized diagnostics payload (after diagnostics_fields and diagnostics_data_path have been applied). On hit, drops data and emits truncated=true, bytes_total, byte_cap, plus available_fields (when the capped value is a dict). Recommended starting point: 20000 bytes. Only applies when include_diagnostics=True."
    • changedInput schema / properties / entry_id / description
      Previous value: -"Config entry ID to get details for. If omitted, lists all integrations."New value: +"Config entry ID to get details for."
    • changedInput schema / properties / exact_match / description
      Previous value: -"Use exact substring matching for query filter (default: True). Set to False for fuzzy matching when the query may contain typos."New value: +"Use exact substring matching for query filter. Set to False for fuzzy matching when the query may contain typos."
    • changedInput schema / properties / include_diagnostics / description
      Previous value: -"When entry_id is set, also fetch the integration's diagnostics dump — integration-defined JSON (commonly includes redacted config, device list, state snapshots; exact top-level keys vary by integration). The canonical artifact users grab via Settings → Devices & Services → [integration] → ⋯ → Download diagnostics. Use when triaging integration bugs or filing ha_report_issue for a specific integration. Payloads can be large (Hue ~290 KB, ZHA/MQTT/ESPHome several MB) — pair with diagnostics_fields or diagnostics_truncate_at_bytes to fit the LLM context budget."New value: +"When entry_id is set, also fetch the integration's diagnostics dump — integration-defined JSON (commonly includes redacted config, device list, state snapshots; exact top-level keys vary by integration), the same artifact as the UI's 'Download diagnostics'. Payloads can be large (Hue ~290 KB, ZHA/MQTT/ESPHome several MB) — pair with diagnostics_fields or diagnostics_truncate_at_bytes."
    • changedInput schema / properties / include_knx_project / description
      Previous value: -"When entry_id is a KNX config entry, also return the parsed ETS project: the full group-address table (address, name, DPT, description) under knx_project.group_addresses, plus the group-range hierarchy and project metadata. This is the parsed-project GA table that is NOT in the diagnostics dump; per-entity GA assignments are already covered by include_diagnostics (config_store / configuration_yaml). Ignored (with a warning) when the entry is not a KNX integration. The KNX integration exposes a single project, so the result is the same regardless of which KNX entry_id is used."New value: +"When entry_id is a KNX config entry, also return the parsed ETS project: the full group-address table (address, name, DPT, description) under knx_project.group_addresses, plus the group-range hierarchy and project metadata. This GA table is not in the diagnostics dump; per-entity GA assignments are (config_store / configuration_yaml). Ignored (with a warning) when the entry is not a KNX integration. KNX exposes a single project, so the result is the same for every KNX entry_id."
    • changedInput schema / properties / include_schema / description
      Previous value: -"When entry_id is set, also return the options flow schema (available fields and their types). Use before ha_config_set_helper to understand what can be updated. Only applies when supports_options=true."New value: +"When entry_id is set, also return the options flow schema (available fields and their types). Only applies when supports_options=true."
    • changedInput schema / properties / include_subentries / description
      Previous value: -"When entry_id is set, include config subentries for the integration entry. Useful for integrations that expose conversation agents, devices, or other extension points as subentries."New value: +"When entry_id is set, include config subentries for the integration entry."
    • changedInput schema / properties / limit / description
      Previous value: -"Max entries to return per page in list mode (default: 50)"New value: +"Max entries to return per page in list mode"
    • changedInput schema / properties / offset / description
      Previous value: -"Number of entries to skip for pagination (default: 0)"New value: +"Number of entries to skip for pagination"
    • changedInput schema / properties / query / description
      Previous value: -"When listing, search by domain or title. Uses exact substring matching by default; set exact_match=False for fuzzy."New value: +"When listing, search by domain or title."
  2. First observedv7.14.2

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already establish it as a safe idempotent read, but the description adds substantial context beyond them: secrets.yaml values are returned as '**redacted**', options shape varies by read path (custom component vs. options flow), payload sizes are named (Hue ~290 KB, ZHA/MQTT/ESPHome several MB), and specific warnings for non-KNX entries and diagnostics truncation. The log_level vs. log_level_raw distinction is fully explained.

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-loaded purpose, then EXAMPLES, then STATES, then OPTIONS before the long log_level tail. Structure is clean and every block is load-bearing, but the log_level/log_level_raw paragraph and the cross-comparison aside with ha_get_app are verbose for what is essentially a return-value note that the output schema could carry.

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 21-parameter tool spanning list, detail, diagnostics, schema, and KNX sub-modes, the description covers mode selection, return-shape caveats, redaction, size limits, and pagination. With an output schema present it need not document raw return values, and nothing an agent requires to invoke it correctly appears to be 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 and each parameter already carries its own description. The prose adds value by giving worked invocation examples that reveal valid multi-parameter combinations and by explaining runtime interactions the schema leaves implicit (e.g., domain filter auto-enabling options, diagnostics_data_path swapping data for a pagination envelope).

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 (get integration/config entry) and immediately distinguishes its two operating modes: list-all when entry_id is absent vs. detailed retrieval when present. It also contrasts semantics with siblings ha_set_integration (writes log_level) and ha_get_app (logs), so an agent can place it 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?

Gives explicit mode selection (with/without entry_id), parameter-combination examples for each major path, and a direct alternative rule: 'Prefer this over include_schema when you only need to read the current values; use include_schema when you also need the field types or selector metadata.' It also advises pairing diagnostics flags with fields/truncation for large payloads.

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