Home Assistant Admin MCP

안전 지향적인 Model Context Protocol(MCP) 서버로, Home Assistant 인스턴스를 검사, 제어, 진단하고 선택적으로 관리하기 위한 도구입니다. Home Assistant의 REST 및 WebSocket API와 선택적인 제약된 Home Assistant 구성 마운트를 결합합니다.

이 서버에는 LLM이 포함되어 있지 않습니다. MCP 클라이언트가 도구를 선택하며, 이 서버는 입력을 검증하고 배포 정책을 적용하며 Home Assistant와 통신한 후 구조화된 결과를 반환합니다.

[!NOTE] 이 프로젝트는 AI 지원 개발 도구를 사용하여 구축되었습니다.

[!WARNING] admin 모드는 장치, 레지스트리, 헬퍼, 자동화, 스크립트, 장면, 통합 및 YAML 구성을 변경할 수 있으며 Home Assistant를 재시작할 수 있습니다. read_only 모드로 시작하고, 전용 Home Assistant 계정을 사용하며, 드라이 런을 검토하고, HTTP 엔드포인트를 신뢰할 수 있는 클라이언트에게만 노출하세요.

범위 및 경계

구현된 기능은 다음과 같습니다:

• 런타임 상태, 서비스/액션, 이벤트, 기록, 로그북, 통계 및 현재 세션 로그 검사(축약된 system_log 폴백 포함).

• 영역, 장치, 엔티티 및 구성 항목이 상호 연결된 레지스트리 및 통합 검색.

• 명시적 대상과 실시간 Home Assistant 서비스 정의를 사용한 검증된 서비스 호출.

• 편집기에서 관리하는 자동화, 스크립트 및 장면 읽기 및 변경.

• Home Assistant 내부 API를 통한 스토리지 기반 헬퍼 및 선택된 레지스트리/구성 항목 변경.

• 진단, 종속성 분석, 레지스트리/편집기 리소스/허용 목록 YAML 전반의 검색, 추적, 구성 차이, 체크포인트 및 제한된 Git 기록.

• 명시적 파일 시스템 허용 목록 하의 구조적 YAML 패치.

명시적 비목표 및 제한 사항:

• Home Assistant Supervisor API, 애드온 관리, 호스트 관리 또는 Home Assistant 백업 API는 없음.

• Docker API, Docker 소켓, 컨테이너 수명 주기, 이미지 관리 또는 컨테이너 로그 접근은 없음. 배포 시 /var/run/docker.sock을 마운트하지 않음.

• 임의 셸 실행 또는 임의 파일 시스템 접근은 없음.

• 일반적인 config-flow/options-flow 구현이 없으며 임의 통합 자격 증명을 제출할 메커니즘이 없음. 통합 도구는 구성 항목을 읽거나, 구현된 기본 설정을 변경하거나, 활성화/비활성화하거나, 다시 로드를 요청할 수만 있음.

• 모든 Home Assistant 사용자가 모든 엔드포인트를 호출할 수 있다고 가정하지 않음. 장기 토큰은 해당 Home Assistant 사용자의 권한 및 관리자 상태를 상속받음.

Related MCP server: hass-mcp-server

아키텍처

flowchart LR
    Client["MCP client"] -->|"Streamable HTTP + MCP bearer token"| HTTP["HTTP transport /mcp"]
    Client -->|"stdio"| Stdio["stdio transport"]
    HTTP --> Policy["MCP tools, schemas, mode, risk and confirmation policy"]
    Stdio --> Policy
    Policy --> REST["Home Assistant REST client"]
    Policy --> WS["Home Assistant WebSocket client"]
    REST --> HA["Home Assistant Core"]
    WS --> HA
    Policy --> TX["Filesystem transaction layer"]
    TX --> Mount["/ha-config allowlisted read-write mount"]
    TX --> Checkpoints[".ha-mcp/backups"]
    TX --> Git["Optional local Git commits"]
    TX -->|"check config, reload, health"| REST
    NoDocker["No Supervisor or Docker socket access"]

HTTP 전송은 MCP 핸들러 계층에서 상태 비저장(stateless)입니다. 애플리케이션 프로세스는 여전히 Home Assistant 연결/캐시를 공유하고 파일 시스템 트랜잭션을 직렬화합니다.

Home Assistant API 매트릭스

2026-08-20에 현재 Home Assistant 문서 및 home-assistant/core dev 소스를 기준으로 검토되었습니다. 소스 링크는 내부 명령이 현재 존재함을 보여주며, 안정성을 보장하는 것은 아닙니다.

Home Assistant API에는 Authorization: Bearer <HA token>이 필요합니다. 공식 authentication API를 참조하세요. MCP HTTP 엔드포인트에는 별도의 베어러 토큰이 있습니다.

내부 API 호환성

• 내부 엔드포인트는 공개 API 사용 중단 기간 없이 이름이 변경되거나, 제한되거나, 스키마가 변경될 수 있습니다. 프로덕션에서 admin을 활성화하기 전에 정확한 Home Assistant 릴리스로 테스트하십시오.

• 레지스트리, 헬퍼, 추적, 시스템 상태, logbook WebSocket, 레코더 메타데이터, config-entry 및 편집기 작업은 호환되지 않는 릴리스에서 HA_WS_UNSUPPORTED, HA_INTERNAL_API_UNAVAILABLE, HELPER_STORAGE_API_UNAVAILABLE, 권한 오류 또는 응답 검증 오류를 반환할 수 있습니다.

• 현재 Home Assistant 코어는 많은 레지스트리 변경 및 추적 읽기를 관리자 전용으로 표시합니다. 해당 도구가 필요할 때는 관리자 소유 토큰을 사용하십시오. 비관리자 토큰은 Home Assistant 권한이 충분하다면 읽기/제어 전용 배포에 여전히 적합할 수 있습니다.

• 편집기 변경은 편집기에서 관리하는 automations.yaml, scripts.yaml, scenes.yaml 리소스로 제한됩니다. 사용 가능한 편집기 ID가 없는 실행 중인 YAML 리소스는 편집 불가능으로 보고됩니다.

• 지원되는 헬퍼는 input_boolean, input_button, input_text, input_number, input_datetime, input_select, counter, timer 및 schedule입니다. 허용되는 필드는 설치된 Home Assistant 버전에 따라 결정됩니다.

• Config-entry 작업은 config flow, options flow, 재인증, 복구, OAuth 또는 자격 증명 입력을 시작하지 않습니다. 이러한 작업에는 Home Assistant UI를 사용하십시오.

• 헬퍼, 레지스트리, 영역, 기기, 엔티티 및 config entry에 대한 드라이런 미리보기는 Home Assistant의 변경 검증기를 호출하지 않습니다. 해당 결과에는 이 사실을 설명하는 제한 사항이 포함됩니다.

프로덕션 배포

사전 요구 사항

• Compose v2 및 BuildKit이 포함된 Docker Engine.

• API가 활성화된 접근 가능한 Home Assistant Core 인스턴스. Home Assistant의 프론트엔드가 일반적으로 이를 제공합니다. API 전용 설치에는 api 통합이 필요합니다.

• Home Assistant 장기 액세스 토큰.

• 파일시스템, 체크포인트, 편집기 변경 안전성 또는 Git 기능이 필요한 경우 Home Assistant 구성이 포함된 호스트 경로.

• 구성된 비루트 UID/GID가 해당 경로를 읽고 쓸 수 있도록 하는 호스트 소유권/권한.

GitHub 릴리스는 docker.io/lemanjo/hac-mcp에 다중 아키텍처 이미지를 게시합니다. 재현 가능한 배포를 위해 latest 대신 정확한 릴리스 태그를 사용하십시오. 로컬 빌드도 계속 지원됩니다.

Home Assistant 토큰 생성

1. 이 서비스가 작동할 사용자로 Home Assistant에 로그인합니다.

2. 사용자 프로필을 연 다음 보안 탭을 엽니다.

3. 장기 액세스 토큰에서 토큰 생성을 선택하고 이 배포용으로 이름을 지정합니다.

4. 표시될 때 토큰을 기록해 둡니다. Home Assistant는 나중에 표시하기 위해 토큰 문자열을 보관하지 않습니다.

5. 내부 관리 도구가 필요한 경우에만 관리자 계정을 사용하십시오.

Home Assistant는 프로필 관리에 대해 여기에, 장기 토큰에 대해 여기에 문서화하고 있습니다. 장기 토큰은 높은 가치의 자격 증명이므로 커밋하거나 config.example.yaml에 넣거나 MCP 클라이언트에 노출해서는 안 됩니다.

Compose 설정

cp .env.example .env
cp config.example.yaml config.yaml
install -d -m 700 secrets
openssl rand -hex 32 > secrets/mcp_auth_token
read -rsp "Home Assistant token: " HA_TOKEN
printf '%s' "$HA_TOKEN" > secrets/home_assistant_token
unset HA_TOKEN
chmod 600 secrets/home_assistant_token secrets/mcp_auth_token

.env에서 다음 값을 설정합니다:

• HOME_ASSISTANT_URL: 컨테이너에서 접근 가능해야 합니다. http://host.docker.internal:8123은 Compose가 host-gateway 항목을 설치하므로 Linux Docker 호스트가 게시한 Home Assistant 포트에 도달합니다. Home Assistant LAN URL도 작동합니다.

• HA_CONFIG_PATH: 기존 호스트 Home Assistant 구성 디렉터리. /ha-config에 읽기-쓰기로 마운트됩니다. Compose는 누락된 소스 경로를 생성하지 않습니다.

• MCP_SETTINGS_FILE: 배포별 변경 후 ./config.yaml을 사용합니다.

• PUID 및 PGID: HA_CONFIG_PATH에 접근 권한이 있는 비루트 ID.

• MCP_ALLOWED_HOSTS: 클라이언트가 HTTP Host 헤더에 넣는 모든 DNS 이름 또는 IP.

• MCP_BIND_IP: 로컬 리버스 프록시/클라이언트의 경우 127.0.0.1을 유지합니다. 의도적인 LAN 노출에만 0.0.0.0을 사용합니다.

검증, 빌드 및 시작:

docker compose config
docker compose build --pull
docker compose up -d
docker compose ps
docker compose logs -f hac-mcp

로컬 빌드 대신 게시된 릴리스를 사용하려면 정확한 이미지 태그를 설정하고 빌드를 비활성화합니다:

MCP_IMAGE=docker.io/lemanjo/hac-mcp:0.1.0 docker compose pull hac-mcp
MCP_IMAGE=docker.io/lemanjo/hac-mcp:0.1.0 docker compose up -d --no-build hac-mcp

헬스 엔드포인트:

curl --fail http://127.0.0.1:3000/livez
curl --fail http://127.0.0.1:3000/readyz

/livez는 HTTP 프로세스가 서비스 중임을 보고합니다. /readyz는 인증된 Home Assistant /api/ 요청을 수행하며 Home Assistant를 사용할 수 없을 때 503을 반환합니다. 두 엔드포인트 모두 MCP 베어러 토큰이 필요하지 않습니다. 이미지와 Compose 헬스체크는 /livez를 사용하므로 일시적인 Home Assistant 중단이 재시작 루프를 유발하지 않습니다.

런타임 파일시스템은 /tmp, Docker 시크릿 마운트 및 /ha-config를 제외하고 읽기 전용입니다. 이미지는 비루트 사용자로 실행되며 PID 1로 tini를 사용합니다. SIGTERM/SIGINT는 Node에 도달하여 HTTP 핸들러와 Home Assistant WebSocket 연결을 닫습니다. Git과 CA 인증서가 설치되어 있지만 셸 실행 MCP 도구는 구현되지 않았습니다.

네트워크 배치

제공된 Compose 네트워크는 게시된 MCP 포트가 하나 있는 격리된 브리지입니다. 호스트 네트워킹을 사용하지 않으며 Docker 소켓을 마운트하지 않습니다.

Home Assistant 연결의 경우:

• 게시된 포트가 있는 Docker 호스트의 Home Assistant: http://host.docker.internal:8123을 사용합니다.

• LAN 또는 macvlan/ipvlan 네트워크의 Home Assistant: 해당 LAN DNS 이름 또는 IP를 사용합니다.

• 다른 사용자 정의 브리지의 Home Assistant: hac-mcp를 해당 외부 네트워크에 연결하고 Home Assistant의 컨테이너 DNS 이름을 사용합니다. 하단 네트워크 선언을 external: true 네트워크로 교체하거나 서비스에 두 번째 외부 네트워크를 추가합니다.

MCP 클라이언트 연결의 경우:

• 동일 호스트 클라이언트 또는 동일 호스트 리버스 프록시의 경우 MCP_BIND_IP=127.0.0.1을 유지합니다.

• 신뢰할 수 있는 LAN 클라이언트의 경우 MCP_BIND_IP=0.0.0.0을 설정하고, 서버의 LAN IP/DNS 이름을 MCP_ALLOWED_HOSTS에 추가하고, 호스트 방화벽 규칙으로 포트를 제한합니다.

• 이 서버는 TLS를 종료하지 않습니다. 신뢰할 수 없는 네트워크를 통과하는 트래픽에는 신뢰할 수 있는 리버스 프록시를 사용하고, Authorization 헤더를 보존하며, 브라우저 클라이언트가 Origin을 보내는 경우 허용된 출처 호스트 이름을 구성합니다.

허용된 호스트와 출처 호스트 이름은 DNS 리바인딩/교차 출처 접근을 완화합니다. 이는 베어러 인증이나 네트워크 제어를 대체하지 않습니다. MCP의 Streamable HTTP 보안 지침은 전송 사양에 있습니다.

Unraid

Unraid는 /mnt/user 아래에 사용자 공유를 노출합니다. 공식 공유 문서를 참조하십시오. 일반적인 레이아웃은 이 체크아웃/시크릿용 /mnt/user/appdata/hac-mcp이고 HA_CONFIG_PATH용 실제 Home Assistant appdata 디렉터리입니다.

1. 프로젝트와 시크릿 파일을 개인 appdata 위치에 둡니다. 가능한 경우 시크릿 파일 모드를 0600으로, 디렉터리 모드를 0700으로 유지합니다.

2. HA_CONFIG_PATH를 정확한 Home Assistant 구성 디렉터리로 설정합니다(예: /mnt/user/appdata/home-assistant). /mnt/user 전체를 마운트하지 마십시오.

3. Home Assistant 파일이 Unraid의 일반적인 nobody:users 계정용으로 소유된 경우에만 PUID=99 및 PGID=100을 설정합니다. 그렇지 않으면 실제 비루트 소유자를 사용합니다. 이 ID가 /ha-config/.ha-mcp/backups를 생성하고 허용된 YAML 파일을 원자적으로 교체할 수 있는지 확인합니다.

4. Docker Compose Manager 커뮤니티 플러그인 또는 Compose v2 CLI가 설치된 경우 프로젝트 디렉터리에서 위의 Compose 설정을 실행합니다. Compose 시크릿은 /run/secrets 아래에 파일로 나타납니다. Docker는 이 동작을 여기에 문서화합니다.

5. Compose 없이 home-assistant-admin-mcp:local을 빌드하고 Unraid의 Docker UI에서 고급 보기를 사용하여 컨테이너를 생성합니다. docker-compose.yml의 환경, 포트 및 경로 설정을 미러링합니다. 두 토큰 파일을 읽기 전용으로 /run/secrets/home_assistant_token 및 /run/secrets/mcp_auth_token에 바인드 마운트합니다. 이러한 UI 바인드 마운트는 앱이 기대하는 파일 인터페이스를 제공하지만 Compose 시크릿 객체는 아닙니다.

6. 기본적으로 브리지 네트워킹을 사용합니다. Home Assistant가 호스트 네트워킹을 사용하는 경우 HOME_ASSISTANT_URL을 Unraid LAN IP와 Home Assistant 포트로 지정하거나 host.docker.internal:host-gateway를 추가합니다. Home Assistant에 자체 br0 LAN IP가 있으면 해당 IP를 사용합니다. 두 컨테이너가 사용자 정의 Docker 네트워크를 공유하는 경우 Home Assistant의 네트워크 별칭을 사용합니다.

7. LAN MCP 접근의 경우 컨테이너 포트 3000을 게시하고 의도적으로 바인드하며 Unraid IP/DNS 이름을 MCP_ALLOWED_HOSTS에 포함합니다. 신뢰할 수 있는 LAN에서도 베어러 토큰과 방화벽 제한을 유지합니다.

8. Docker 소켓 경로를 추가하지 마십시오. Supervisor/컨테이너 관리는 필요하지 않으며 지원되지 않습니다.

Unraid의 Mover 또는 공유 설정은 /mnt/user/...를 변경하지 않고 사용자 공유 파일의 물리적 저장 위치를 변경할 수 있습니다. 하나의 안정적인 사용자 공유 경로를 사용하고 동등한 /mnt/user 및 /mnt/diskX 경로를 혼합하지 마십시오.

MCP 클라이언트

Streamable HTTP

아래 예제는 MCP 클라이언트가 Docker와 동일한 호스트에서 실행되고 Compose 기본값이 변경되지 않았다고 가정합니다. 클라이언트를 다음으로 지정합니다:

http://127.0.0.1:3000/mcp

/mcp에 대한 모든 요청은 별도의 MCP 토큰을携带해야 합니다:

Authorization: Bearer <contents of secrets/mcp_auth_token>

MCP 토큰을 클라이언트 구성 파일에 넣지 말고 클라이언트 프로세스 환경에 로드합니다. 이 토큰은 MCP 클라이언트만 인증합니다. 여기에 Home Assistant 토큰을 절대 사용하지 마십시오.

export HAC_MCP_TOKEN="$(tr -d '\r\n' < /absolute/path/to/secrets/mcp_auth_token)"

다른 호스트의 클라이언트의 경우 127.0.0.1을 MCP 호스트의 주소로 바꾸고 네트워크 배치에 설명된 대로 MCP_BIND_IP, MCP_ALLOWED_HOSTS, 방화벽 규칙 및 TLS를 구성합니다. 다른 컨테이너에서 127.0.0.1은 해당 클라이언트 컨테이너를 의미합니다. 공유 네트워크 별칭 또는 호스트 주소를 대신 사용하십시오.

Codex

사용자 수준 ~/.codex/config.toml 또는 신뢰할 수 있는 프로젝트의 .codex/config.toml에 다음을 추가합니다:

[mcp_servers.home-assistant-admin]
url = "http://127.0.0.1:3000/mcp"
bearer_token_env_var = "HAC_MCP_TOKEN"
enabled = true
default_tools_approval_mode = "writes"
tool_timeout_sec = 150

HAC_MCP_TOKEN을 설정한 후 Codex를 다시 시작하고 codex mcp list 또는 Codex TUI의 /mcp로 연결을 확인합니다. writes 승인 모드는 읽기 전용으로 표시되지 않은 도구에 클라이언트 측 프롬프트를 추가합니다. 서버 측 모드, 위험 및 확인 정책은 여전히 독립적으로 적용됩니다. Codex MCP 문서를 참조하십시오.

OpenCode

프로젝트 수준 opencode.json 또는 전역 OpenCode 구성에 다음을 병합합니다:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "home-assistant-admin": {
      "type": "remote",
      "url": "http://127.0.0.1:3000/mcp",
      "enabled": true,
      "oauth": false,
      "headers": {
        "Authorization": "Bearer {env:HAC_MCP_TOKEN}"
      },
      "timeout": 150000
    }
  }
}

HAC_MCP_TOKEN을 설정한 후 OpenCode를 다시 시작합니다. opencode mcp list로 상태를 확인하거나 opencode mcp debug home-assistant-admin으로 연결을 진단합니다. 프롬프트에서 필요할 때 서버를 이름으로 참조합니다(예: Use home-assistant-admin to list unavailable entities.). OpenCode MCP 문서를 참조하십시오.

Claude Code

Claude Code를 실행하는 프로젝트에서 이 .mcp.json을 생성하거나 병합합니다:

{
  "mcpServers": {
    "home-assistant-admin": {
      "type": "http",
      "url": "http://127.0.0.1:3000/mcp",
      "headers": {
        "Authorization": "Bearer ${HAC_MCP_TOKEN}"
      },
      "timeout": 150000
    }
  }
}

환경 변수 참조는 공유해도 안전합니다. 커밋된 파일에서 리터럴 토큰으로 대체하지 마십시오. HAC_MCP_TOKEN을 설정한 후 claude mcp list를 실행하고 claude를 시작하고 프롬프트가 표시되면 프로젝트 범위 서버를 승인하고 /mcp로 상태를 확인합니다. Claude Code MCP 문서를 참조하십시오.

확인 및 사용

클라이언트와 독립적으로 엔드포인트, 프록시 및 인증 실패를 진단하는 데 유용한 저수준 초기화 프로브:

curl --fail-with-body http://127.0.0.1:3000/mcp \
  -H "Authorization: Bearer ${HAC_MCP_TOKEN}" \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  --data '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"curl-probe","version":"1.0.0"}}}'

정상 운영에는 실제 MCP 클라이언트를 사용하십시오. 클라이언트가 초기화, 프로토콜 버전 협상, 알림 및 도구 호출을 올바르게 수행합니다. 서버는 auto 응답 모드에서 JSON 또는 SSE 응답을 수락하고 상태 비저장 HTTP 핸들러를 사용합니다. 유용한 첫 프롬프트는 다음과 같습니다:

• Use home-assistant-admin to summarize the Home Assistant instance and list unavailable entities. Do not make changes.

• Use home-assistant-admin to diagnose why <entity> is unavailable. Read configuration and recent logs only.

• control 모드에서: Turn on <explicit entity_id>. Do not target an area or device.

• admin 모드에서: Dry-run the requested configuration change, show the diff and validation result, and wait for confirmation before applying it.

클라이언트는 서버의 구성된 모드를 승격할 수 없습니다. read_only로 시작하고, 권한과 배포 노출을 검토한 후에만 .env에서 MCP_MODE를 변경하고 Compose 서비스를 다시 생성하세요.

stdio

먼저 pnpm build로 빌드한 다음, 로컬 MCP 클라이언트가 서버를 실행하도록 구성하세요. stdio에서는 MCP 클라이언트가 하위 프로세스와 파이프를 소유하므로 HTTP 인증을 사용하지 않습니다.

{
  "mcpServers": {
    "home-assistant-admin": {
      "command": "node",
      "args": ["/workspaces/hac-mcp/dist/index.js"],
      "env": {
        "MCP_CONFIG_FILE": "/workspaces/hac-mcp/config.example.yaml",
        "MCP_TRANSPORT": "stdio",
        "MCP_MODE": "read_only",
        "HOME_ASSISTANT_URL": "http://homeassistant.local:8123",
        "HOME_ASSISTANT_TOKEN_FILE": "/absolute/private/path/home_assistant_token",
        "HA_CONFIG_PATH": "/absolute/path/to/home-assistant/config"
      }
    }
  }
}

서버는 stdio 모드에서 stderr에만 로그를 기록합니다. Docker healthcheck는 HTTP 전용이므로, 이미지를 의도적으로 stdio 하위 프로세스로 실행하는 경우 기본 Docker healthcheck를 사용하지 마세요.

인증 및 구성

두 개의 독립적인 자격 증명이 있습니다:

두 토큰 모두 *_FILE 변수가 직접 환경 변수보다 우선하며 주변 공백은 제거됩니다:

• HOME_ASSISTANT_TOKEN_FILE이 HOME_ASSISTANT_TOKEN보다 우선합니다.

• MCP_AUTH_TOKEN_FILE이 MCP_AUTH_TOKEN보다 우선합니다.

MCP_AUTH_TOKEN 또는 해당 파일은 HTTP에 필수이며 stdio에는 필요하지 않습니다. Bearer 비교는 SHA-256 다이제스트와 타이밍 안전 비교를 사용합니다. Bearer 토큰은 재생 가능하므로 네트워크를 신뢰할 수 없을 때 TLS가 여전히 필요합니다.

구성은 MCP_CONFIG_FILE에서 로드된 다음 환경 값이 파일을 재정의합니다. 지원되는 환경 변수 재정의는 다음과 같습니다:

쉼표로 구분된 변수는 공백이 제거됩니다. 존재하는 환경 변수만 YAML 값을 재정의합니다. 제한, 권한, 캐시 TTL, 비밀 메타데이터 정책, 백업 디렉터리 및 Git 작성자 ID는 그 외에는 YAML 기본값 또는 구성 파일에서 가져옵니다.

모드, 위험 및 확인

모든 도구는 위험 수준으로 등록되며 클라이언트에 계속 표시됩니다. 정책은 호출 시 다시 적용됩니다.

call_service는 CONTROL 기준을 가지지만 권한 부여 전에 알려진 관리 인수를 승격합니다: 재시작/중지, 백업 및 recorder 제거 작업은 HIGH_IMPACT가 되고, reload, logger 및 config 작업은 CONFIG가 됩니다. 유효 위험은 각 결과에 반환되며, 사용자 지정 MCP 메타데이터는 도구를 동적으로 분류된 것으로 표시합니다.

permissions.requireConfirmationFor는 기본적으로 HIGH_IMPACT입니다. 일치하는 도구는 confirm: true를 받아야 하며, 그렇지 않으면 재시도 메타데이터와 함께 CONFIRMATION_REQUIRED를 반환합니다. 더 광범위하게 확인을 요구하려면 CONTROL 및/또는 CONFIG를 추가하세요.

민감 도메인 정책은 모드와 독립적입니다:

• allow: 일반 모드/위험 정책이 적용됩니다.

• confirm: 명시적 confirm: true가 필요합니다.

• deny: admin 모드에서도 작업이 거부됩니다.

기본값은 lock, alarm_control_panel 및 siren에 대해 확인을 요구합니다. garage 또는 gate를 포함하는 명시적 cover 엔티티 ID도 확인이 필요합니다. 정책은 다중 엔티티 대상의 모든 명시적 엔티티를 평가합니다. 영역/장치 대상은 권한 부여 시점에 안전하게 확장할 수 없으므로, 그 구분이 중요할 때 전체 서비스 도메인을 거부하거나 확인을 요구하세요.

드라이 런

dry_run: true는 영구 리소스, 헬퍼, 레지스트리, 영역, 장치, 엔티티, config-entry, YAML 패치, 관리 수명 주기, 롤백 및 일반 서비스 호출 도구에 구현되어 있습니다. 편의 물리 제어 도구는 작업을 시뮬레이션하지 않습니다.

• YAML 패치는 결과 YAML을 구문 분석하고 검증하며, 쓰기, 체크포인트, reload, 전체 Home Assistant 구성 확인 또는 커밋 없이 수정된 구조적 diff를 반환합니다.

• 로컬 YAML 구문 분석은 구문 오류, 중복 매핑 키, 확인되지 않은 별칭 및 과도한 별칭 확장을 거부합니다. 이후 비드라이 적용은 Home Assistant의 전체 구성 검사를 실행하고 거부 시 롤백을 시도합니다. 로컬 검증은 Home Assistant의 도메인 검증을 대체하지 않습니다.

• 자동화/script/scene 드라이 런은 현재 편집기 리소스를 읽고 JSON diff를 생성하며 사용 가능한 경우 구현된 조각 검증을 호출하지만 쓰기나 체크포인트 생성을 수행하지 않습니다.

• 헬퍼, 레지스트리, 영역, 장치, 엔티티 및 config-entry 드라이 런은 현재 데이터를 읽고 미리보기를 구성합니다. 내부 변형 엔드포인트를 호출하지 않으며 Home Assistant의 서버 측 변형 검증을 수행하지 않습니다.

• Config-entry reload 드라이 런은 제안된 reload를 보고하지만 런타임 효과를 예측할 수 없습니다.

• Reload, 재시작, 체크포인트 롤백 및 서비스 소유 Git 롤백 드라이 런은 사용 가능한 식별자/현재 메타데이터를 검증하고 적용하지 않고 제안된 고영향 작업을 설명합니다.

• 일반 call_service는 라이브 서비스 정의에 대한 드라이 런 검증을 지원합니다. 서비스는 호출되지 않습니다. 편의 물리 제어 도구는 의도적으로 작업을 시뮬레이션하지 않습니다.

• 성공적인 드라이 런은 결과에 설명된 검증만 증명합니다. 적용 시점에 상태, 권한, 내부 API, 파일 또는 통합 동작이 변경되지 않을 것임을 보장하지 않습니다.

파일시스템 안전

파일시스템 액세스는 HA_FILESYSTEM_ENABLED=false로 단위로 비활성화됩니다. 활성화되면 요청은 filesystem.root 아래에서 정규화되고, 모든 경로 세그먼트가 검사되며, 심볼릭 링크는 거부됩니다.

허용된 경로:

• 구성 루트 바로 아래의 모든 .yaml 또는 .yml 파일.

• 구성된 allowedDirectories 아래의 YAML(기본값은 packages 및 themes), 스캔 깊이 32까지 재귀적으로.

• 사용자 지정 구성 요소 정책이 활성화된 경우에만 custom_components/<integration>/... 아래의 선택된 .json, .py, .pyi, .yaml 및 .yml. 전용 도구는 제한된 소스 읽기를 제공합니다. 소스 쓰기 도구나 Python 실행/검증 경로는 노출되지 않습니다.

항상 보호되거나 거부됨:

• .storage, .git, Home Assistant 데이터베이스 형식, 개인 키 형식/이름 및 구현된 인증, 자격 증명, 토큰 또는 백업 키 패턴과 일치하는 경로 이름.

• 루트 외부의 경로, 잘못된 경로 세그먼트, 누락된 쓰기 부모, 비일반 파일 및 모든 심볼릭 링크.

• 기본적으로 secrets.yaml 및 secrets.yml 값. allowSecretsMetadata: true를 사용하면 도구는 값 없이 정렬된 최상위 비밀 키 이름, 바이트 수 및 타임스탬프를 반환할 수 있습니다.

allowSecretValues: false를 사용하면 password, clientSecret, token, apiKey, private-key, credential, authorization 및 cookie와 같은 민감한 snake_case, camelCase 및 하이픈 키가 정규화되어 재귀적으로 수정됩니다. !secret/!env_var 값과 일치하는 diff 줄도 수정됩니다.

이러한 검사는 패턴 기반이지 콘텐츠 스캐너가 아니므로 흔하지 않은 비밀 이름이 모든 가드와 일치하지 않을 수 있습니다. 실제 값을 보호된 루트 secrets.yaml에 보관하고, 다른 허용 목록 YAML에 자격 증명을 저장하지 말며, 신뢰할 수 없는 모델에 제공하기 전에 수정된 출력을 검사하세요. HA_ALLOW_SECRET_VALUES=true를 설정하면 루트 secrets.yaml을 포함한 비밀 포함 YAML을 명시적으로 읽고 패치할 수 있습니다. 이 예외적 복구 옵션은 완전히 신뢰할 수 있는 클라이언트에서만 사용하세요.

쓰기는 임시 파일, O_NOFOLLOW, fsync, 원자적 이름 변경, 보존된 모드, SHA-256 낙관적 동시성 검사 및 지원되는 경우 부모 디렉터리 동기화를 사용합니다.

체크포인트, 트랜잭션 및 롤백

patch_yaml_file 비드라이런 워크플로:

1. 허용 목록 경로를 확인하고, 현재 해시를 읽고, 구조적 YAML 작업을 적용하고, 구문을 검증합니다.

2. 기본적으로 /ha-config/.ha-mcp/backups 아래에 모드 보존 체크포인트를 생성합니다.

3. 해시를 다시 확인하고 각 파일을 원자적으로 씁니다. 서버 프로세스당 하나의 구성 트랜잭션만 실행됩니다.

4. Home Assistant에 전체 구성 검사를 요청합니다.

5. 영향을 받는 자동화/script/scene 도메인을 reload하거나, 다른/여러 경로에 대해 reload: false가 아닌 한 homeassistant.reload_all을 호출합니다.

6. 상태 확인으로 Home Assistant 구성을 읽습니다.

7. 쓰기 시작 후 실패 시, 해시가 여전히 트랜잭션 출력과 일치하는 경우에만 적용된 파일을 복원한 다음 reload 및 상태 확인을 시도합니다.

8. 선택적으로 변경된 경로만 Git에 커밋합니다. Git 실패는 Home Assistant 변경 성공 후 경고가 됩니다. 변경을 롤백하지 않습니다.

편집기 관리 자동화/script/scene 변형은 내부 편집기 엔드포인트를 호출하기 전에 파일시스템 체크포인트를 생성하고, 비드라이런 변경에 구성 마운트를 요구하며, 제한된 재시도로 편집기 구성 및 런타임 존재/부재를 확인하고, Home Assistant 구성 검증을 실행하며, 적용 또는 검증 실패 시 편집기 수준 롤백을 시도합니다.

rollback_change는 먼저 현재 파일의 안전 체크포인트를 생성하고, 현재 해시 충돌 검사로 선택된 체크포인트를 복원하고, Home Assistant 구성을 검증하고, reload합니다. 검증/reload가 실패하면 안전 체크포인트 복원을 시도하고 복구 실패를 보고합니다. 체크포인트는 Home Assistant Supervisor 백업이 아닌 로컬 파일 스냅샷이며, 보존 정리도 자동으로 수행되지 않습니다.

Git 동작 및 제한

Git은 선택 사항이며 /ha-config가 감지된 저장소 내부에 있을 때만 작동합니다. 이미지에는 Git CLI가 포함되어 있습니다.

• 상태, 기록, diff는 구성 경로 정책에서 허용된 경로로 제한됩니다.

• 커밋은 선택된 허용 경로만 스테이징하고 커밋합니다. 훅은 비활성화되고, 서명은 비활성화되며, 작성자/커미터 신원은 구성에서 가져옵니다.

• 서버는 초기화, 클론, fetch, pull, push, merge, rebase, 원격 저장소 관리, 자격 증명, 브랜치, 태그, 서브모듈을 수행하지 않습니다.

• 대상 경로는 변경 전에 검사됩니다. 영향을 받는 파일에 이미 스테이징된 변경 사항이나 작업 트리 변경 사항이 있는 경우, Home Assistant 작업은 체크포인트로 진행될 수 있지만 자동 Git 커밋은 건너뛰어 기존의 사람이 만든 편집이 MCP 커밋에 포함되지 않도록 합니다. 관련 없는 경로는 그대로 유지됩니다.

• rollback_to_commit은 현재 HEAD만 허용하며, 작성자 이메일이 구성된 서비스 이메일과 일치하는 커밋만 허용하고, 초기 커밋은 허용하지 않으며, 영향을 받는 경로에 커밋되지 않은 변경 사항이 없는 경우에만 허용합니다.

• Git 롤백은 기록을 재설정하는 대신 새로운 보상 커밋을 작성합니다. Home Assistant 검증이 실패하면 이전 상태를 복원하기 위해 서비스 소유의 또 다른 롤백이 시도됩니다.

• Git 명령은 30초 후에 시간 초과됩니다. 일반 출력은 4MiB로 제한되고, diff는 maxReadBytes의 4배로 제한되며 최대 16MiB입니다.

도구

아래 이름은 src/mcp/tools에서 파생되었습니다. 클라이언트에 표시되는 스키마, 설명, 주석, 위험, 소스 및 안정성 메타데이터는 MCP 검색으로 반환됩니다.

검색

• 인스턴스: get_home_assistant_info, get_system_health, get_config.

• 통합: list_integrations, get_integration.

• 영역: list_areas, get_area.

• 기기: list_devices, get_device, search_devices.

• 엔티티: list_entities, get_entity, search_entities.

• 교차 레지스트리 검색: search_home_assistant_registry.

런타임 및 기록

• 서비스/이벤트: list_services, list_event_types, get_events, subscribe_events.

• 상태: get_state, get_states, get_states_by_area, get_states_by_device.

• 레코더 데이터: get_history, get_logbook, get_statistics, get_recorder_statistics.

제어

• 일반/표준 제어: call_service, turn_on, turn_off, toggle, set_value, set_temperature.

• 실행: activate_scene, run_script.

자동화, 스크립트, 장면 및 추적

• 자동화: list_automations, get_automation, create_automation, update_automation, delete_automation, enable_automation, disable_automation, trigger_automation, reload_automations, validate_automation.

• 스크립트: list_scripts, get_script, create_script, update_script, delete_script, run_script_by_id, reload_scripts, validate_script.

• 장면: list_scenes, get_scene, create_scene, update_scene, delete_scene, activate_scene_resource, reload_scenes.

• 자동화 추적: get_automation_traces, get_automation_trace, explain_automation_failure, get_last_automation_run.

• 일반 추적: get_trace, list_traces, explain_trace, get_last_trace.

헬퍼 및 레지스트리

• 헬퍼: list_helpers, get_helper, create_helper, update_helper, delete_helper.

• 엔티티 레지스트리: update_entity_registry, disable_entity, enable_entity, rename_entity, move_entity_to_area.

• 기기 레지스트리: update_device, rename_device, move_device_to_area, disable_device, enable_device.

• 영역 레지스트리: create_area, update_area, delete_area, assign_device_to_area, assign_entity_to_area.

• 구성 항목: get_config_entries, get_config_entry, reload_config_entry, update_integration, enable_integration, disable_integration.

구성 및 복구

• 읽기/목록: read_configuration, list_configuration_files, read_yaml_file, list_custom_component_files, read_custom_component_source.

• 패치/검증: patch_yaml_file, validate_configuration, validate_home_assistant_configuration.

• 다시 로드/재시작: reload_configuration, reload_yaml_configuration, restart_home_assistant.

• 기록/diff: get_config_history, get_config_diff, get_recent_changes.

• 롤백: rollback_change, rollback_to_commit.

로그, 진단, 종속성 및 검색

• 로그: get_home_assistant_logs, search_logs, get_errors, get_warnings, get_recent_errors, get_integration_errors.

• 엔티티/기기 발견: find_unavailable_entities, find_disabled_entities, find_orphaned_entities, find_orphaned_devices, find_duplicate_entities, find_entities_without_area, find_devices_without_area, find_stale_sensors.

• 자동화/헬퍼 발견: find_unused_helpers, find_broken_automations, find_automation_errors, find_automations_referencing_missing_entities.

• 종속성/검색: get_entity_dependencies, get_automation_dependencies, search_home_assistant.

사용자 요청 예시

• "주방에서 사용할 수 없는 엔티티를 나열하고 해당 기기 및 통합 관계를 포함하세요."

• "지난 1시간 동안 zha 통합에 대한 ERROR 및 CRITICAL 로그 항목을 표시하세요."

• "자동화 ID garage_arrival의 가장 최근 실패한 실행을 설명하세요."

• "누락된 엔티티를 참조하는 자동화를 찾은 다음 각 자동화의 종속성을 표시하세요."

• "packages/lighting.yaml을 변경하는 구조적 YAML 패치를 드라이런하고 수정된 diff만 표시하세요."

• "light.office를 끄되 다른 엔티티는 대상으로 지정하지 마세요."

• "게스트 모드용 input_boolean 헬퍼를 드라이런으로 생성하고 검증 제한 사항을 보고하세요."

• "명시적 확인과 함께 장면 ID old_evening을 삭제한 다음 체크포인트, 구성 검증, 확인, 롤백 및 Git 결과를 보고하세요."

모델/클라이언트는 요청을 정확한 도구 스키마로 변환해야 합니다. 자연어 요청은 모드, 위험, 확인, 경로 또는 Home Assistant 권한 부여 검사를 우회하지 않습니다.

성능 및 제한

기본값과 상한은 MCP 호출이 무제한의 Home Assistant 또는 파일 시스템 쿼리가 되지 않도록 설계되었습니다.

긴 기록/로그북 기간과 전체 진단은 여전히 Home Assistant 레코더 내부에서 비용이 많이 들 수 있습니다. 가능하면 엔티티, 기기, 통합, 시간 범위 및 페이지로 필터링하세요.

개발

Node.js 22.23.1 및 pnpm 11.21.0이 필요합니다.

corepack enable
pnpm --version
pnpm install --frozen-lockfile
pnpm build

종속성 공급망

• 직접 종속성은 정확한 버전을 사용하며, 잠금 파일은 레지스트리 무결성 해시로 전체 그래프를 고정합니다.

• pnpm은 10,080분(7일) 미만의 릴리스, 게시 시간이 없는 패키지, 게시자 신뢰 다운그레이드, 이국적인 전이 소스 및 승인되지 않은 종속성 빌드 스크립트를 거부합니다. 또한 모든 설치 시 고정된 npm 레지스트리에 대해 잠금 파일 해석 데이터를 다시 검증합니다.

• 설치 시 기본적으로 고정된 잠금 파일을 사용합니다. 종속성 변경에는 명시적이고 검토된 pnpm install --no-frozen-lockfile, 이후 pnpm supply-chain:check, 일반 검증 스위트 및 커밋된 잠금 파일 diff가 필요합니다.

• 전이 재정의는 최신 버전이 격리 기간 내에 있는 동안 적격한 content-type 및 hono 릴리스를 고정하고, 게시자 신뢰를 다운그레이드하지 않는 증명된 릴리스에 undici-types를 고정합니다. 검토된 종속성 업데이트 중에 이러한 재정의를 다시 평가하되 자동으로 제거하지 마세요.

• CI 작업 및 컨테이너 기본 이미지는 불변 커밋 또는 콘텐츠 다이제스트를 사용합니다. 런타임 Debian 패키지는 날짜가 지정된 스냅샷에서 제공되므로 다시 빌드해도 자동으로 업그레이드되지 않습니다.

• minimumReleaseAgeExclude 예외를 추가하지 마세요. 긴급 보안 릴리스의 경우 7일이 경과할 때까지 기다리거나 검토된 변경에서 이 정책을 변경하기 위한 명시적 승인을 받으세요.

릴리스 게시

v0.1.0과 같은 SemVer 태그로 GitHub 릴리스를 게시하면 .github/workflows/release-docker.yml이 실행됩니다. linux/amd64 및 linux/arm64 이미지를 빌드하고, 버전 태그를 docker.io/lemanjo/hac-mcp에 푸시하며, SBOM 및 출처 증명을 첨부합니다. 안정 릴리스는 latest도 업데이트하지만 사전 릴리스는 그렇지 않습니다.

저장소에는 다음 GitHub Actions 비밀이 필요합니다:

• DOCKERHUB_USERNAME: Docker Hub 계정 이름, 현재 lemanjo.

• DOCKERHUB_TOKEN: lemanjo/hac-mcp에 대한 읽기/쓰기 권한이 있는 Docker Hub 개인 액세스 토큰. 계정 비밀번호를 사용하지 마세요.

GitHub 저장소 > 설정 > 비밀 및 변수 > 작업 > 새 저장소 비밀에서 추가하거나 GitHub CLI로 추가하세요:

gh secret set DOCKERHUB_USERNAME --repo lemanjo/hac-mcp --body lemanjo
gh secret set DOCKERHUB_TOKEN --repo lemanjo/hac-mcp

두 번째 명령은 토큰 값을 안전하게 프롬프트합니다. 토큰을 .env, 워크플로 YAML, 셸 기록 또는 저장소에 저장하지 마세요.

main으로의 모든 푸시(병합된 풀 리퀘스트 포함)는 .github/workflows/nightly-docker.yml을 실행합니다. 이 워크플로는 별도의 DOCKERHUB_NIGHTLY_TOKEN 시크릿을 사용하며 nightly 태그와 변경 불가능한 nightly-<full-commit-sha> 태그를 게시합니다. 이 워크플로는 GitHub Actions에서 수동으로 시작할 수도 있습니다. 재현성이 중요한 경우 전체 SHA 태그를 사용하세요.

gh secret set DOCKERHUB_NIGHTLY_TOKEN --repo lemanjo/hac-mcp

HTTP 개발:

HOME_ASSISTANT_URL=http://homeassistant.local:8123 \
HOME_ASSISTANT_TOKEN_FILE=/absolute/private/path/home_assistant_token \
MCP_AUTH_TOKEN_FILE=/absolute/private/path/mcp_auth_token \
MCP_CONFIG_FILE=./config.example.yaml \
MCP_TRANSPORT=http \
MCP_HOST=127.0.0.1 \
MCP_ALLOWED_HOSTS=localhost,127.0.0.1 \
HA_CONFIG_PATH=/absolute/path/to/home-assistant/config \
pnpm dev

API 전용 개발의 경우 HA_FILESYSTEM_ENABLED=false 및 HA_GIT_ENABLED=false로 설정하세요. 체크포인트가 필요한 편집기 리소스 변경은 설계상 사용할 수 없게 됩니다.

테스트 및 검증

저장소 검사를 실행합니다:

pnpm supply-chain:check
pnpm audit --prod --audit-level high
pnpm typecheck
pnpm lint
pnpm format:check
pnpm test
pnpm build

Docker를 사용할 수 있는 환경에서 배포 파일을 검증합니다:

docker compose config
docker build --check -t home-assistant-admin-mcp:check .
docker build -t home-assistant-admin-mcp:local .

그런 다음 프로덕션이 아닌 Home Assistant 인스턴스에 대해 /livez, /readyz, MCP initialize 요청, 대표적인 읽기 전용 도구를 테스트하세요. admin을 활성화하기 전에 프로덕션에서 사용하는 것과 동일한 Home Assistant 버전과 파일시스템에 대해 내부 API 읽기, 드라이 런, 일회용 변경, 체크포인트 롤백, Git 동작을 테스트하세요.

문제 해결

서버가 시작되지 않음

• INVALID_CONFIGURATION: config.yaml을 파싱하고 정확한 camelCase 키, 숫자 범위, URL, 이메일 형식, stderr의 상세 검증 내역을 확인하세요.

• MCP_AUTH_REQUIRED: HTTP는 MCP_AUTH_TOKEN 또는 MCP_AUTH_TOKEN_FILE이 필요하며, 공백 제거 후 최소 16자 이상이어야 합니다.

• 시크릿 관련 ENOENT: Compose 시크릿 소스 경로는 Compose 프로젝트 기준 호스트 경로입니다. .env와 파일 권한을 확인하세요.

• stdio 모드에서 Docker healthcheck 실패: /livez는 HTTP 모드에서만 존재합니다. 의도적인 stdio 컨테이너의 경우 healthcheck를 제거하거나 재정의하세요.

MCP HTTP 401, 403 또는 413

• 401: MCP 베어러 토큰이 없거나, 형식이 잘못되었거나, 잘못되었습니다. 인증 방식은 대소문자를 구분하지 않으며 Bearer여야 합니다.

• 도구 호출 전 403: 요청의 실제 호스트 이름을 MCP_ALLOWED_HOSTS에 추가하고, 브라우저 클라이언트의 경우 스킴과 포트를 제외한 출처 호스트 이름을 MCP_ALLOWED_ORIGINS에 추가하세요. 임의의 와일드카드는 추가하지 마세요.

• 413 또는 JSON 파싱 거부: 요청을 줄이거나 mcp.maxRequestBytes를 10MiB 제한 내에서 늘리세요.

• 리버스 프록시 실패: Authorization, Host, Origin, Accept, Content-Type, MCP-Protocol-Version, HTTP 스트리밍, SSE 동작을 유지하세요.

/readyz가 503이거나 Home Assistant 호출 실패

• 브리지 컨테이너 내부에서 localhost는 Home Assistant가 아닌 MCP 컨테이너를 가리킵니다. host.docker.internal, LAN 주소 또는 공유 네트워크 별칭을 사용하세요.

• HA_AUTH_FAILED/HA_WS_AUTH_FAILED: Home Assistant 장기 액세스 토큰을 교체하거나 다시 생성하세요.

• HA_PERMISSION_DENIED: 토큰의 사용자에게 요청된 내부 명령에 대한 권한 또는 관리자 상태가 없습니다.

• HA_TLS_ERROR/HA_WS_TLS_ERROR: 신뢰할 수 있는 인증서 체인을 설치하거나, 통제된 사설 네트워크에서만 HA_VERIFY_TLS=false로 설정하세요. 이 경우 서버 ID가 더 이상 검증되지 않는다는 점을 완전히 인지해야 합니다.

• 기록, 로그북 또는 통계 오류: recorder/logbook 통합이 로드되었는지, 요청한 ID와 시간 범위가 존재하는지 확인하세요.

파일시스템 또는 Git 실패

• CONFIG_ROOT_UNAVAILABLE/권한 거부: HA_CONFIG_PATH를 올바르게 설정하고 PUID:PGID가 쓰기 가능하도록 하세요. 컨테이너는 의도적으로 root로 실행되지 않습니다.

• CONFIG_PATH_NOT_ALLOWED: 루트 YAML 또는 허용된 디렉터리를 사용하세요. 보호된 경로, 심볼릭 링크, 임의의 확장자, 누락된 상위 디렉터리는 거부됩니다.

• CONFIG_CONCURRENT_MODIFICATION/ROLLBACK_CONFLICT: 다른 프로세스가 파일을 변경했습니다. 강제로 덮어쓰지 말고 다시 읽고, 검토한 후 재시도하세요.

• Git is enabled but no repository was detected: MCP 외부에서 저장소를 초기화/관리하거나 HA_GIT_ENABLED=false로 설정하세요.

• Git이 소유권 불명(dubious ownership)을 보고하는 경우: 컨테이너 UID/GID를 저장소 소유자와 일치시키세요. 컨테이너를 root로 실행하여 해결하지 마세요.

• 체크포인트가 공간을 차지하는 경우: .ha-mcp/backups에 운영자가 정의한 보존 정책을 검토하고 적용하세요. 자동 삭제 도구는 없습니다.

Home Assistant 업그레이드 후 내부 도구 실패

• 명령이 연결된 최신 코어 소스에 여전히 존재하는지 확인하고 요청/응답 필드를 비교하세요.

• 먼저 읽기 전용 작업을 재시도하세요. 검증 또는 롤백 상태가 불확실할 때 변경 작업을 반복적으로 재시도하지 마세요.

• 내부 엔드포인트가 변경된 헬퍼, 통합 또는 리소스에는 Home Assistant UI를 사용하세요.

• 호환성이 테스트되고 검토될 때까지 MCP_MODE=read_only를 유지하세요.

라이선스

MIT