Skip to main content
Glama
brilliantdirectories

brilliant-directories-mcp

Official

searchUsers

Read-onlyIdempotent

Search members by keyword, category, and location with sorting options such as reviews or name.

Instructions

Search members/users - Full-text search across members with category, location, and sorting options.

Lean-by-default keep-list: same shape as listUsers — identity + routing + location core. Restore extras via the same include flags including include_extras=1 for stripped fields (billing/analytics rollups, duplicate location fields, social URLs, awards, credentials, work_experience, etc.).

Use when: (1) mirroring the public member-search experience - embedding search results in an external app, building a custom search-results page, or letting users search BD from outside the site; (2) verifying what is publicly findable for a given keyword / category / location combo (SEO coverage audits, "who shows up if a visitor searches X?"); (3) keyword / partial-name / location / category lookup in general. For exact-field lookup (by email, by user_id, by phone, by any admin column) use listUsers + property / property_value - faster, more precise, and supports admin-only filters (join date, subscription status, meta fields) that this endpoint does not.

Pagination: cursor-based (limit, page). See Rule: Pagination for full cursor/cap/stop semantics.

Enums: sort: reviews, name ASC, name DESC, last_name_asc, last_name_desc.

Parameter interactions:

  • q - keyword (matches first name, last name, company, about, search_description)

  • pid (category ID), tid (sub-category/service ID), ttid (sub-sub-category) - taxonomy filters, use IDs from listTopCategories / listSubCategories

  • address + dynamic=1 - proximity/geographic filtering

See also: getUser (single record by ID), listUsers (full enumeration).

Returns: { status: "success", message: [...records] }. Supports pagination fields when result set is large.

Profile URL: every user record has a filename field. To get the full public profile URL, concatenate: <site-domain>/<user.filename>. The filename is the complete relative path (e.g., united-states/monterey-park/doctor/harrison-hasanuddin-d-o) - DO NOT prepend /business/, /profile/, /member/, or any other segment. BD's router resolves filename verbatim.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoSearch keyword
pidNoCategory ID
tidNoSub-category ID
ttidNoSub-sub-category ID
addressNo
sortNo
pageNo
limitNo
dynamicNo
include_passwordNoOpt in to return bcrypt `password` hash.
include_subscriptionNoOpt in to return full `subscription_schema`. Heavy — when set, `limit` is auto-capped at 25 for transport stability.
include_clicksNoOpt in to return `user_clicks_schema.clicks` array.
include_photosNoOpt in to return `photos_schema` array. Heavy — when set, `limit` is auto-capped at 25 for transport stability.
include_transactionsNoOpt in to return full `transactions` array. Heavy — when set, `limit` is auto-capped at 25 for transport stability.
include_professionNoOpt in to return `profession_schema`.
include_tagsNoOpt in to return `tags` array.
include_servicesNoOpt in to return `services_schema` array. Heavy — when set, `limit` is auto-capped at 25 for transport stability.
include_seo_hiddenNoOpt in to return SEO-hidden meta fields.
include_aboutNoOpt in to return the `about_me` HTML bio. Heavy — when set, `limit` is auto-capped at 25 for transport stability.
include_legacy_fieldsNoReturn image-import state on `photos_schema` rows: `original`, `resized`, `error`. Requires `include_photos=1`.
include_extrasNoOpt in to return ALL remaining user fields not in the lean keep-list and not gated by another `include_*` flag (social URLs, awards, credentials, quote, gmap, work_experience, ref_code, booking_link, listing_type, profession_name, verified, featured, etc.).
Behavior4/5

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

Annotations already declare readOnly=true and idempotent=true. The description adds value by detailing pagination, limit caps with heavy include flags, profile URL construction, and the lean-by-default keep-list. No contradictions 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?

The description is long but well-structured with headings (Use when, Pagination, etc.) and front-loaded with purpose. It could be slightly more concise, but the structure helps navigate the complexity of 21 parameters.

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

Completeness4/5

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

Given no output schema, the description covers output format, pagination, sort enums, and profile URL construction. Missing details: default sorting order, exact pagination fields. Overall quite complete for a search tool.

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 high (76%), but the description adds meaningful context: groups parameters, explains interactions (q matches specific fields, address+dynamic for proximity), and clarifies the role of include_extras. This goes beyond the schema descriptions.

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 it performs full-text search across members with filters. It explicitly distinguishes itself from sibling tools like listUsers (exact-field lookup) and getUser (single record), making its purpose unambiguous.

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 'Use when' scenarios (public member-search, SEO audits, keyword/category/location lookup) and explicitly advises against using it for exact-field lookups, directing to listUsers instead. It also explains parameter interactions.

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