Descriptor Cluster

Cluster ID: 0x001D  |  Endpoint: Every Endpoint must have it (including Endpoint 0)

Descriptor is the most fundamental Cluster in the Matter protocol. It answers one core question: What is on this Endpoint? When a Controller (phone, smart speaker, hub) connects to a Matter device, the first thing it does is read the Descriptor on each Endpoint to learn which Device Types the device supports, which Clusters are implemented, and the hierarchical relationship between Endpoints.

This Cluster is entirely read-only — it has no Commands, only Attributes. The information is determined at manufacturing time and does not change at runtime.

What Problem Does Descriptor Solve

The data model of a Matter device is a tree structure: a Node (physical device) contains multiple Endpoints, and each Endpoint represents a functional unit. However, when a Controller connects to a device, it does not know what this tree looks like. Descriptor is the self-describing mechanism of this tree:

• DeviceTypeList — Tells the Controller "what I am" (door lock? light? switch?)
• ServerList / ClientList — Tells the Controller "what I can do" (which Clusters are supported)
• PartsList — Tells the Controller "what is under me" (list of child Endpoints)

Attribute Overview

Descriptor has only 5 attributes, but each one is essential. Click an attribute ID to jump to its detailed description.

Attributes

DeviceTypeList (0x0000)

Lists all Device Types supported by this Endpoint. Each entry is a DeviceTypeStruct containing the Device Type ID and revision number. Most Endpoints have only one Device Type, but the specification allows an Endpoint to declare multiple.

DeviceTypeStruct Structure

↑ Back to Attributes

ServerList (0x0001)

Lists all Cluster IDs that this Endpoint implements as a Server. A Server is the side that holds data and responds to read/write requests. For example, the ServerList of a door lock's Endpoint 1 would include 0x0101 (DoorLock), because the lock's state (locked/unlocked, user list, etc.) is stored on the device.

By reading the ServerList, a Controller knows which Clusters it can send read/write/command requests to on this Endpoint.

↑ Back to Attributes

ClientList (0x0002)

Lists all Cluster IDs that this Endpoint implements as a Client. A Client is the side that initiates requests — most end devices (lights, locks, sensors) have an empty ClientList because they are only controlled and do not actively control other devices.

A typical scenario where ClientList is non-empty: a physical switch. A wall switch declares 0x0006 (OnOff Client) in its ClientList, indicating that it will actively send on/off commands to lights.

↑ Back to Attributes

PartsList (0x0003)

Lists the child Endpoint numbers of this Endpoint. This attribute defines the hierarchical relationship between Endpoints.

↑ Back to Attributes

TagList (0x0004) — Optional

Attaches semantic tags to the Endpoint, used to distinguish Endpoints that have the same function but different locations or purposes. For example, a device with two temperature sensor Endpoints can use TagList to label one as "Indoor" and the other as "Outdoor".

TagList requires the device to declare the TAGLIST Feature (Feature Bit 0) in order to be present.

SemanticTagStruct Structure

↑ Back to Attributes

How Controllers Use Descriptor to Discover Devices

After connecting to a Matter device, the Controller follows this standard Endpoint discovery flow:

1. Read Endpoint 0's PartsList — Get all application Endpoint numbers, e.g. [1, 2, 3]
2. Iterate over each Endpoint and read DeviceTypeList — Learn that Endpoint 1 is a door lock, Endpoint 2 is a temperature sensor, etc.
3. Read ServerList — Learn which specific Clusters each Endpoint supports (what operations are available)
4. Build the UI based on this information — Show an unlock button for the door lock Endpoint, display a temperature reading for the sensor Endpoint

Example Data

Scenario 1: Standard Device (Door Lock)

Descriptor of Endpoint 0 (Root Node):

{
  // Descriptor of Endpoint 0 (Root Node)
  "DeviceTypeList": [
    { "DeviceType": "0x0016", "Revision": 2 }   // Root Node
  ],
  "ServerList": [
    "0x001D",   // Descriptor
    "0x0028",   // BasicInformation
    "0x002F",   // PowerSource
    "0x0030",   // GeneralCommissioning
    "0x0031",   // NetworkCommissioning
    "0x003E",   // OperationalCredentials
    "0x0033"    // GeneralDiagnostics
  ],
  "ClientList": [],
  "PartsList": [ 1, 2, 3 ]   // This Node also has Endpoints 1, 2, 3
}

Descriptor of Endpoint 1 (door lock application Endpoint):

{
  // Descriptor of Endpoint 1 (application Endpoint, e.g. a door lock)
  "DeviceTypeList": [
    { "DeviceType": "0x000A", "Revision": 3 }   // DoorLock
  ],
  "ServerList": [
    "0x001D",   // Descriptor (itself)
    "0x0003",   // Identify
    "0x0101",   // DoorLock
    "0x002F"    // PowerSource
  ],
  "ClientList": [],
  "PartsList": []   // Leaf Endpoint, no children
}

Scenario 2: Bridge Device

The PartsList of a Bridge (gateway/aggregator) device's Endpoint 0 lists all bridged child devices:

{
  // Descriptor of Endpoint 0 (Bridge device)
  "DeviceTypeList": [
    { "DeviceType": "0x000E", "Revision": 2 }   // Aggregator (Bridge)
  ],
  "ServerList": [ "0x001D", "0x0028", "0x0039" ],
  "PartsList": [ 1, 2, 3, 4, 5 ]   // Bridging 5 child devices

  // Each child Endpoint (1-5) has its own independent Descriptor,
  // describing its own DeviceType and Cluster lists
}