listUserMeta
Enumerate paginated user metadata records (key/value pairs) attached to any parent table, with compound identity filtering by database, database_id, and key.
Instructions
List user metadata records - Paginated enumeration of users_meta records (EAV key/value table). Read-only.
Use when: enumerating metadata rows (key/value pairs) attached to a parent record in any BD table.
IDENTITY RULE - (database, database_id) is ONE atomic compound identity, not two independent fields. The same numeric database_id routinely points at UNRELATED rows on different parent tables - any integer ID can exist as a PK on multiple parent tables simultaneously. A database_id=<n>-only query will return a MIX of rows from every parent table where that integer happens to be a PK (even low IDs like 1 return hundreds of rows spanning 2+ parent tables). Always pair database=<parent_table> WITH database_id=<id> whenever reading, writing, updating, or deleting users_meta. Pass database, database_id, and key as first-class query params; the MCP wrapper translates them into BD's multi-condition filter syntax so server-side scoping IS accurate — no client-side post-filter needed. The safety guard requires at least 2 of (database, database_id, key) on every read; single-filter queries are rejected. Do NOT mix first-class filters with the generic property/property_value style in the same call — pick one style. Never act on a partial-identity result - misidentifying a row can silently corrupt or destroy unrelated resource metadata on another table.
Commonly-seen database values (BD may accept other table names with users_meta rows - prefer these for known resources; if the user names an unfamiliar table, GET first to verify it actually has meta rows before writing): users_data, deleted_users_data, data_posts, list_seo, subscription_types, list_professions, list_services, rel_services, tags, tag_groups, rel_tags, leads, lead_matches, forms, form_fields, users_reviews, menus, menu_items, data_widgets, email_templates, 301_redirects, data_categories, smart_lists, users_clicks, unsubscribe_list.
Pagination: cursor-based (limit, page). See Rule: Pagination for full cursor/cap/stop semantics.
Filter: prefer the first-class database / database_id / key params (see Rule: users_meta identity). The generic property / property_value / property_operator + order_column / order_type flow also works as a fallback and counts toward the 2-of-3 guard when property is one of the three target keys — but do not mix the two styles in the same call.
See also: getUserMeta (single record by ID), updateUserMeta, deleteUserMeta.
Returns: { status: "success", total, current_page, total_pages, next_page, prev_page, message: [...records] }. Each record includes meta_id, database, database_id, key, value, date_added, revision_timestamp.
Note on duplicates: BD does NOT enforce a uniqueness constraint on (database, database_id, key) - the same field can have multiple rows (observed live). Read-layer merge uses last-write-wins, but stored data can bloat. When updating, consider patching ALL matching rows, or deleting duplicates first.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| database | No | Parent table filter (e.g. `list_seo`, `users_data`, `data_posts`). First-class shortcut - the MCP wrapper translates it into BD's multi-condition filter syntax. Pair with `database_id` to target all EAV rows for one parent record, or with `key` to find one field across parents. The safety guard requires 2 of `(database, database_id, key)` on every query. | |
| database_id | No | Parent record primary key filter. Pair with `database` (required - same `database_id` can exist on multiple parent tables) to target one parent's EAV rows, or with `key` to find one specific field. The safety guard rejects queries that send this alone. | |
| key | No | EAV key/field-name filter (e.g. `hero_content_overlay_opacity`, `search_membership_permissions`). Pair with `database` (scope to one parent table) or with `database_id` (one specific row). The safety guard rejects this alone. | |
| value | No | Exact-match filter on the stored `value` column. Optional fourth first-class param (listUserMeta only) — narrows a (database, key) scope to rows whose value equals this exactly. NOT counted toward the 2-of-3 safety guard; `value` alone is rejected. Use case: dedup lookups where (database=`list_seo`, key=`hero_image`, value=`<exact URL>`) returns 0-or-1 row in one call instead of paginating + client-filtering. Wrapper appends this as a 4th condition to BD's `property[]`/`property_value[]`/`property_operator[]==` multi-condition syntax. | |
| limit | No | Records per page (default 25, max 100) | |
| page | No | Pagination cursor (use next_page from previous response) | |
| property | No | Field name to filter by | |
| property_value | No | Value to filter by | |
| property_operator | No | Filter operator: =, LIKE, >, <, >=, <= | |
| order_column | No | Column to sort by | |
| order_type | No | Sort direction: ASC or DESC |