Skip to main content
Glama
brilliantdirectories

brilliant-directories-mcp

Official

listUserMeta

Read-onlyIdempotent

List user metadata key-value records attached to any parent record. Requires providing both database table name and record ID to correctly retrieve paginated metadata.

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

TableJSON Schema
NameRequiredDescriptionDefault
databaseNoParent 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_idNoParent 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.
keyNoEAV 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.
valueNoExact-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.
limitNoRecords per page (default 25, max 100)
pageNoPagination cursor (use next_page from previous response)
propertyNoField name to filter by
property_valueNoValue to filter by
property_operatorNoFilter operator (word-form; symbol forms WAF-stripped). Single: eq, ne, lt, lte, gt, gte, like, not_like. CSV: in, not_in, between. Substring: contains, starts_with, ends_with (+not_). Date: year_eq, month_eq, day_eq (+not_), since_days, until_days. Length: length_eq, length_lt, length_gt, length_between. Null: is_set, is_not_set, is_null, is_not_null. See Rule: Filter operators for value shapes.
order_columnNoColumn to sort by
order_typeNoSort direction: ASC or DESC
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=true and other properties, but the description adds significant behavioral context: safety guard requiring 2 of (database, database_id, key), rejection of single-filter queries, duplicate handling, and the MCP wrapper's translation of filters. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured with sections and bold emphasis. However, some parts are repetitive (e.g., identity rule mentioned multiple times). It could be more concise while retaining clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (11 parameters, EAV structure, safety rules), the description is comprehensive. It covers identity, filtering, pagination, return format, duplicates, and references other rules. No output schema, but return format is described.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, but the description adds beyond schema: explains that value is not counted toward safety guard, provides common database values list, and clarifies how parameters interact (e.g., first-class vs generic filters). While baseline 3, the extra context justifies a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists user metadata records (EAV key/value table) with paginated enumeration. It specifies read-only and distinguishes from sibling tools like getUserMeta, updateUserMeta, and deleteUserMeta.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use the tool (enumerating metadata rows attached to a parent record), includes the identity rule for compound identity, warns about mixing filter styles, and lists common database values. References to sibling tools and rules for pagination and filtering are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/brilliantdirectories/brilliant-directories-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server