# nickol-knx (pypi · nickol-knx-mcp)

Read-only KNX/ETS project auditor: validates a .knxproj and generates Home Assistant YAML

- Trust score: 57/100 (low)
- Change this week: −11
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-20

## Components

- pypi · `nickol-knx-mcp`: 57/100 (this document), [markdown](https://verifymcp.io/servers/nickoscope-nickol-knx-mcp/nickol-knx-mcp.md), [page](https://verifymcp.io/servers/nickoscope-nickol-knx-mcp/nickol-knx-mcp)

## Channel facts

- Registry: `pypi`
- Package: `nickol-knx-mcp`
- Version: `0.8.2`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-09-20.

- **Supply Chain Security**: 50/100
  - Malware scan not yet available for this package.
  - No known CVEs affecting this package version or its production dependencies.
  - Runs setuptools.build_meta at install time, a recognised native-build step with no shell scripting around it.
  - 1 of 35 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 48/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 6 days ago).
  - Publishes a security disclosure policy (SECURITY.md).
- **Schema Quality & AI Usability**: 71/100
  - AI-judged instruction clarity (good).
  - Tool/resource definitions use about 2884 tokens (~90/item across 32 items; 32 tools + 0 resources), lean.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 71/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 0% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 32 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 32 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the nickol-knx MCP server?

nickol-knx runs locally as a PyPI package, launched with uvx nickol-knx-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add nickoscope-nickol-knx-mcp -- uvx nickol-knx-mcp
```

### Cursor

```json
{
  "mcpServers": {
    "nickoscope-nickol-knx-mcp": {
      "command": "uvx",
      "args": [
        "nickol-knx-mcp"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "nickoscope-nickol-knx-mcp": {
      "command": "uvx",
      "args": [
        "nickol-knx-mcp"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add nickoscope-nickol-knx-mcp -- uvx nickol-knx-mcp
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "nickoscope-nickol-knx-mcp": {
      "type": "local",
      "command": [
        "uvx",
        "nickol-knx-mcp"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add nickoscope-nickol-knx-mcp --command uvx --arg nickol-knx-mcp
```

### Hermes

```yaml
mcp_servers:
  nickoscope-nickol-knx-mcp:
    command: "uvx"
    args: ["nickol-knx-mcp"]
```

### Netclaw

```json
{
  "McpServers": {
    "nickoscope-nickol-knx-mcp": {
      "Transport": "stdio",
      "Command": "uvx",
      "Arguments": [
        "nickol-knx-mcp"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add nickoscope-nickol-knx-mcp -t stdio -c uvx -a nickol-knx-mcp
```

### Other

```json
{
  "mcpServers": {
    "nickoscope-nickol-knx-mcp": {
      "command": "uvx",
      "args": [
        "nickol-knx-mcp"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-09-20 (score 57, +1)

No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-18 (score 56, +1)

No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-17 (score 55, −15)

- [security regression] Malware scan: pass → unverified

### 2026-09-16 (score 70, +16)

- [security improvement] Malware scan: unverified → pass

### 2026-09-14 (score 54, −14)

- [security regression] Malware scan: pass → unverified
- [functional regression] Schema quality: 80 → 90
- [functional improvement] Stability: unverified → 0.07
- [functional] Package version: 0.8.1 → 0.8.2

### 2026-09-12 (score 68)

First indexed and scored.

## MCP tools (32)

### `load_project` (~92 tokens)

Parse a .knxproj file (read-only) and cache it for the session.

Args:
    path: Path to the .knxproj file.
    password: Project password, if the .knxproj is protected.
    language: Optional language code (e.g. 'de-DE', 'ru-RU').

Input parameters:

- `language`
- `password`
- `path` (string, required)

### `load_ga_export` (~217 tokens)

Load an ETS group-address export (ga-export/01 XML) instead of a full .knxproj.

For when you only have the GA list: an ETS "Export Group Addresses" file, or the
ETS import file a planning tool produces (TapPlan and similar). Names, addresses,
DPTs, descriptions, the security flag and the range tree are read; the result
replaces the loaded project for every other tool.

Works: check_naming, check_missing_status, check_dpt, check_policy, check_secure,
analyze_all, suggest_repairs, project_report, generate_ha_package,
generate_ets_group_addresses. Nothing to read (the export has no devices, ETS
Functions or topology): get_devices, get_topology, check_topology,
decompose_device, check_device_parameters, parse_devices_from_project. Pairing
relies on names only, since there are no ETS Function roles.

Args:
    path: Path to the exported .xml file.

Input parameters:

- `path` (string, required)

### `list_group_addresses` (~191 tokens)

List parsed group addresses with classification, in a **stable order**.

Filters: category (lighting/shutter/hvac/sensor/scene/energy/diagnostics),
kind (command/status/sensor), missing_dpt_only.

Paging: results are always sorted by the group address itself (main/middle/sub
numerically, free-style addresses numerically, anything else lexically), so the
order does not depend on how the project happened to parse and a retry returns
the same page. Pass the returned `next_cursor` back as `cursor` for the next
page; `next_cursor` is null on the last page. `total_matched` reports how many
addresses match the filters, so a truncated answer is never silent.

Input parameters:

- `category`
- `cursor`
- `kind`
- `limit` (integer)
- `missing_dpt_only` (boolean)

### `get_devices` (~70 tokens)

List devices (individual address, name, order number, manufacturer), sorted by
individual address (area/line/device numerically). Same paging contract as
\`list_group_addresses`: `next_cursor` / `total_matched` / `returned`.

Input parameters:

- `cursor`
- `limit` (integer)

### `get_topology` (~18 tokens)

Return the area/line/device topology tree.

### `check_naming` (~24 tokens)

Validate naming conventions and 3-level structure.

Input parameters:

- `name_regex`

Output parameters:

- `result` (array)

### `check_missing_status` (~21 tokens)

Detect controllable GAs lacking a status/feedback counterpart.

Output parameters:

- `result` (array)

### `check_dpt` (~20 tokens)

Detect missing, inconsistent or mismatched DPTs.

Output parameters:

- `result` (array)

### `check_topology` (~54 tokens)

Check topology capacity and individual-address validity (KNX Handbook).

Flags lines over the TP1 segment (64) / line (256) limits, invalid or
duplicate individual addresses, and multi-line projects missing a coupler.

Output parameters:

- `result` (array)

### `suggest_repairs` (~110 tokens)

Propose concrete fixes for the project's findings — repair, don't just flag.

For each issue it suggests a reviewable fix: infer a DPT for a GA that has none,
correct a suspect sub-DPT, synthesise a status/feedback GA in a free address slot,
or add an absolute-brightness GA for a relative-only dimmer. Suggestions only —
a human reviews them; accepted new GAs feed generate_ets_group_addresses. The
server never writes to ETS or the bus.

### `check_secure` (~80 tokens)

Summarise KNX Data Secure posture + the keyring handover checklist.

Reports how many group addresses are secured vs plaintext, flags middle
groups that mix secure and plaintext addresses (a function is only as secure
as its weakest GA), and emits the ETS/HA keyring workflow as a checklist.
Report-only — this server never touches key material.

### `analyze_all` (~26 tokens)

Run every check and return the report summary plus all findings.

Input parameters:

- `name_regex`

### `generate_ha_package` (~52 tokens)

Generate a Home Assistant KNX package YAML.

If output_path is given, the YAML is written into the workspace and the path
returned; otherwise the YAML text is returned inline.

Input parameters:

- `output_path`

### `generate_ets_group_addresses` (~68 tokens)

Generate an ETS-importable Group Address export.

Args:
    fmt: 'xml' (ga-export/01, recommended) or 'csv' (native ETS layout).
    output_path: optional file inside the workspace.

Input parameters:

- `fmt` (string)
- `output_path`

### `project_report` (~32 tokens)

Produce the human-readable Markdown report (review before any import).

Input parameters:

- `name_regex`
- `output_path`

### `generate_handover_pack` (~127 tokens)

Generate a project handover pack (as-built deliverable for commissioning).

Assembles an equipment inventory, group-address map by domain, command/status
coverage, KNX Secure scope and QA state into ``handover.md``, plus a
\``topology.svg`` diagram, the full ``group-addresses.csv`` and the
\``ha-package.yaml``. When ``output_dir`` is given (a folder inside the
workspace) all files are written there and the paths returned; otherwise the
handover markdown + SVG are returned inline.

Input parameters:

- `output_dir`

### `decompose_device` (~134 tokens)

Expand a device into its group-address decomposition recipe.

A KNX actuator channel is not one GA — it expands into command/status/dimming/
position/mode objects, each with its DPT. Given a device order number, type or
alias (e.g. 'ZIO-MB24', 'dimmer', 'JRA/S', 'presence detector') and a channel
count, returns the objects a professional wires per channel and the total GA
count. Use when turning a spec/ТЗ device list into a group-address structure.

Input parameters:

- `channels` (integer)
- `order_number` (string, required)

### `list_device_recipes` (~22 tokens)

List the device decomposition recipes in the built-in device library.

Output parameters:

- `result` (array)

### `parse_devices_from_project` (~234 tokens)

Extract exact device object models from a .knxproj / .knxprod application programs.

Reads the manufacturer application programs (M-*) embedded in an ETS `.knxproj`
(devices actually used) or a `.knxprod` product database, and returns each device's
order number, app-program version, object counts and detected per-channel blocks —
the EXACT vendor comm-object model, not a generic recipe. Read-only and PII-safe: it
reads only vendor catalog data, never the client project (P-*/0.xml).

Use this to build/grow the local device catalog that `decompose_device` consumes
(set NICKOL_KNX_CATALOG to the catalog dir). If `output_path` is given, the full
catalog is written into the workspace as device-library YAML; the return value is
always a compact per-device summary + coverage manifest (the full object lists are
not inlined). DPT `unverified` = the vendor app-program declares none (never guessed).

Input parameters:

- `output_path`
- `password`
- `path` (string, required)

### `check_device_parameters` (~196 tokens)

Find the device whose ETS **parameter** settings differ from its N identical
siblings — the odd thermostat/sensor out (e.g. one thermostat with a different
setpoint/hysteresis, one presence detector with a different detection time).

Reads per-device parameter values straight from the `.knxproj` project part
(data xknxproject does not expose), groups identical devices by application
program, and returns `clear_outliers` (a strong majority with a small minority —
likely a mistake) and `split_configs` (balanced 2+ variants — review, often two
zones). Numeric config parameters are listed first; names are resolved from the
device application program. Read-only, no ETS/bus. Give a real `.knxproj` `path`
(a password-protected/encrypted project cannot be read).

Input parameters:

- `min_group` (integer)
- `password`
- `path` (string, required)

### `check_policy` (~148 tokens)

Validate the loaded project against a **Project Policy Profile** — *your*
agreed rules (main-group taxonomy, naming regex, command/status exemptions),
not one universal "standard". Flags GAs whose domain doesn't match the main
group your policy assigns, and names that don't match your pattern. Pass
\`profile_path` to a YAML profile (omit to validate against the taxonomy inferred
from the project itself). Set `write_example_to` to drop a commented example
profile into the workspace — **seeded from the loaded project's own main groups**
(mains that do not exist in the project are not written). Report-only.

Input parameters:

- `profile_path`
- `write_example_to`

### `explain_ga` (~135 tokens)

\**Provenance** for one group address — why the tool classified it the way it did.
Replays the classification and shows, per decision (category / kind / status pairing),
the signals that fired with a **confidence tier**: authoritative (an ETS Function role) >
structural (the KNX DPT) > heuristic (a name keyword). Flags **conflicts** (e.g. a GA
the DPT calls `lighting` while its name says "AC") — the hotspot for silent
misclassification. Read-only; use before trusting a category or generating an entity.

Input parameters:

- `address` (string, required)

### `check_matter` (~41 tokens)

Matter-readiness lint: which controllable functions round-trip to a Matter
cluster (have command + status + a decodable DPT) and which won't.

### `grade_completeness` (~55 tokens)

Grade the project: bare functional skeleton vs as-built grade — by the presence
of the professional patterns (central macros, device tuning, astro/meteo, monitoring,
deep metering, scenes, reserves, a debug main).

### `check_energy` (~50 tokens)

Check the metering/energy domain (energy DPTs 13.x / 14.056) and suggest a
per-circuit / PV / battery / EVSE structure for the HA energy dashboard.

### `suggest_names` (~23 tokens)

Naming hygiene suggestions (empty names, status GAs missing a status keyword).

### `generate_test_protocol` (~49 tokens)

Draft a functional acceptance protocol (per function: command → expected status,
pass/fail/sign-off) as Markdown. Execution is manual/on-site; this only drafts it.

Input parameters:

- `output_path`

### `diff_projects` (~79 tokens)

Semantic diff between two .knxproj files (path_a = base/old, path_b = new):
added / removed GAs, DPT changes, renames, security-flag changes. Read-only.

Input parameters:

- `password_a`
- `password_b`
- `path_a` (string, required)
- `path_b` (string, required)

### `generate_knx_iot` (~52 tokens)

Export a KNX IoT semantic view (Turtle/RDF) of the project's functional
datapoints — a pragmatic skeleton for the IP-native model, for review.

Input parameters:

- `output_path`

### `validate_room_template` (~129 tokens)

Validate a Room Library template against the R1 schema (report-only).

Pass ``template`` (a built-in template's semantic slot_id, e.g. 'bedroom',
'kitchen') or ``path`` to a custom template YAML. Checks the public contract:
a locale-neutral slot_id, ru/en labels, per-slot basic/comfort presets, known
function types, valid multiplicities, and that ``area_m2`` is a hint with
provenance (never a normative fact). Returns ok + findings; nothing is written.

Input parameters:

- `path`
- `template`

### `compose_rooms` (~317 tokens)

Compose a **new** KNX project from a list of room templates (constructor).

\``rooms`` is a list of specs, each: ``{template, preset?, slot_presets?,
params?, label?}`` — e.g. ``{"template": "bedroom", "preset": "comfort"}``.
\``preset`` is basic|comfort (per-room); ``slot_presets`` overrides individual
slots (mix comfort climate with basic lighting); ``params`` overrides template
defaults (window/circuit counts); ``label`` sets a custom zone name.

Pipeline: resolve templates+params to a functional model, allocate group
addresses (main = domain, middle = role, sub sequential), write a real
\``.knxproj`` and **re-read it with the standard loader**, then run our linters
on the re-read project. Output: a ``manifest`` (allocation), ETS GA XML/CSV,
and a device ``bom`` proposal from the device library.

R1 builds NEW projects only and is dry-run by default (nothing written). Set
\``dry_run=false`` with ``output_dir`` (a folder inside the workspace) to write
the .knxproj, ETS exports, manifest.yaml and bom.yaml. Docking into an
existing project and exact device selection are R2. Never touches a bus.

Input parameters:

- `dry_run` (boolean)
- `language` (string)
- `output_dir`
- `project_name` (string)
- `rooms` (array, required)

### `workspace_info` (~18 tokens)

Show the confined output workspace and the safety guarantees.

## Diagnostics

Captured diagnostic sections: Provenance, Install scripts, Dependencies. The full working is on the page: https://verifymcp.io/servers/nickoscope-nickol-knx-mcp/nickol-knx-mcp#diagnostics

## Score history

- 2026-09-20: 57
- 2026-09-19: 56
- 2026-09-18: 56
- 2026-09-17: 55
- 2026-09-16: 70
- 2026-09-15: 54
- 2026-09-14: 54
- 2026-09-13: 68
- 2026-09-12: 68

## Common questions

### What is the nickol-knx MCP server?

nickol-knx is an MCP server listed in the public MCP registry as io.github.NickoScope/nickol-knx-mcp. Read-only KNX/ETS project auditor: validates a .knxproj and generates Home Assistant YAML. This page covers its PyPI package (nickol-knx-mcp).

### Is the nickol-knx MCP server safe to use?

nickol-knx scores 57 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 20 September 2026. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the nickol-knx MCP server expose?

nickol-knx exposes 32 tools: load_project, load_ga_export, list_group_addresses, get_devices, get_topology, and 27 more. Their descriptions and schemas cost roughly 2,884 tokens of context every time the server is loaded.

### Is the nickol-knx MCP server still maintained?

nickol-knx is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the nickol-knx MCP server under?

nickol-knx declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- PyPI project: https://pypi.org/project/nickol-knx-mcp/
- Socket report: https://socket.dev/pypi/package/nickol-knx-mcp
- Repository: https://github.com/NickoScope/nickol-knx-mcp
- Website: https://nickoscope.github.io/nickol-knx-mcp
- Changelog RSS feed: https://verifymcp.io/servers/nickoscope-nickol-knx-mcp/nickol-knx-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/nickoscope-nickol-knx-mcp/nickol-knx-mcp.json
- HTML version of this page: https://verifymcp.io/servers/nickoscope-nickol-knx-mcp/nickol-knx-mcp