> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qobra.co/llms.txt
> Use this file to discover all available pages before exploring further.

# list_user_attributes

> List the schema of user attributes your company defines: name, type, picklist options, readonly flag and source connection, in display order.

List the *schema* of user attributes your company defines — what it records
about its people (Segment, Hiring date, Region…), of what type, and which labels
a picklist accepts. This is the schema behind the `attributes` array
[`get_user`](/mcp_documentation/tools/get_user) returns: reach for
`list_user_attributes` when you need each attribute's type, whether it is synced
from a source system, or the exact labels a picklist accepts; reach for
`get_user` when you need one specific user's values.

Rows come in the company's own display order (the order shown in the Qobra web
app), so a page is directly usable as a form or a rendering layout.

Access is gated by **READ** permission on **Users**.

## Parameters

<Accordion title="Body" defaultOpen>
  <ParamField body="limit" type="integer">
    Page size, between 1 and 250. Defaults to 50.
  </ParamField>

  <ParamField body="offset" type="integer">
    Row offset into the result set — the number of rows to skip before this
    page. Any offset >= 0 is accepted; it does not have to be a multiple of
    limit, so you can start from an arbitrary row. Pass the next\_offset returned
    by the previous call to walk the pages, or None for the first page.
  </ParamField>
</Accordion>

## Response

<Accordion title="Body" defaultOpen>
  <ResponseField name="attributes" type="object[]">
    <Expandable title="object properties">
      <ResponseField name="id" type="string">
        Id of the attribute — pair it with the `id` each `get_user` attribute
        entry carries to map a user's value back to its definition, even when
        two attributes share a display name.
      </ResponseField>

      <ResponseField name="name" type="string" />

      <ResponseField name="description" type="string">
        What the company says this attribute means, in their own words. Null
        when they wrote none.
      </ResponseField>

      <ResponseField name="type" type="string">
        Attribute data type: amount, percentage, float, string, bool, date,
        picklist, multipicklist, or user (a reference to another Qobra user).
        One of: `float`, `amount`, `percentage`, `string`, `picklist`,
        `multipicklist`, `bool`, `date`, `user`.
      </ResponseField>

      <ResponseField name="options" type="string[]">
        Selectable option labels for a PICKLIST / MULTIPICKLIST attribute, in
        definition order; null for every other type. Archived options are left
        out — they can no longer be picked, though a user set to one before it
        was archived still carries it, so a value `get_user` returns need not
        appear in this list.
      </ResponseField>

      <ResponseField name="readonly" type="boolean">
        True when the value cannot be edited in Qobra — it is owned by the
        source system that syncs it.
      </ResponseField>

      <ResponseField name="integration" type="object">
        The company connection this attribute is synced from; null when it is
        maintained in Qobra itself. An attribute whose source connection has
        since been removed reads as maintained in Qobra rather than naming a
        link that no longer syncs.

        <Expandable title="object properties">
          <ResponseField name="id" type="string" />

          <ResponseField name="name" type="string" />
        </Expandable>
      </ResponseField>
    </Expandable>
  </ResponseField>

  <ResponseField name="next_offset" type="integer" />
</Accordion>