Skip to main content
Glama
brilliantdirectories

brilliant-directories-mcp

Official

listUserMeta

Read-onlyIdempotent

Enumerate metadata key-value records (EAV) from any parent table with pagination and filter support. Requires at least two of database, database_id, and key for safe queries.

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
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.
pageNoPagination cursor (use next_page from previous response)
limitNoRecords per page (default 25, max 100)
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.
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.
propertyNoColumn key to filter by (present on the response rows; a wrong name silently returns empty). For multi-condition AND, pass parallel arrays here and in `property_value`/`property_operator` — equal length, Nth entries paired. See Rule: Compound filters.
order_typeNoSort direction: ASC or DESC
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.
order_columnNoColumn to sort by — a column key present on the response rows (a wrong name silently returns empty)
property_valueNoValue to filter by; array to pair with a `property` array (same length).
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. Array to pair with a `property` array (same length). See Rule: Filter operators for value shapes.
Behavior5/5

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

Read-only behavior aligns with annotations. Adds pagination details, filter guard, duplicate handling, and return format. 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.

Conciseness4/5

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

Well-structured with sections and bold rules, but somewhat lengthy. However, complexity justifies the length, and content is well-organized.

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?

Covers all aspects: pagination, filters, identity, duplicates, common database values, and return format. No gaps given the tool's complexity and lack of output schema.

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

Parameters5/5

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

Adds significant meaning beyond the 100% schema coverage: explains compound identity, safety guards, wrapper translation, special value parameter, and filter style restrictions.

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?

Clearly states 'List user metadata records - Paginated enumeration of users_meta records (EAV key/value table). Read-only.' Differentiates from siblings like getUserMeta and deleteUserMeta via explicit 'See also' section.

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?

Provides extensive when-to-use guidance: identity rules, pagination, filter styles, and explicit alternatives. Includes safety guard requirements and warns against mixing filter styles.

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