Skip to main content
Glama
brilliantdirectories

brilliant-directories-mcp

Official

listWidgets

Read-onlyIdempotent

List reusable HTML/CSS/JS widgets available for embedding in pages or email templates. Paginated, filterable by viewport or other properties, with optional code inclusion.

Instructions

List widgets - Paginated enumeration of widget records. Read-only.

Lean-by-default keep-list: rows return only widget_id, widget_name, widget_type, widget_viewport, short_code, date_updated, revision_timestamp, is_default. The code fields (widget_data, widget_style, widget_javascript) are stripped — restore with include_code=1.

Use when: discovering the reusable HTML/CSS/JS components available for embedding in pages (via [widget=Name] shortcode) or email templates. For fetching one specific widget by ID use getWidget.

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

Filter/sort: property+property_value+property_operator, order_column+order_type. See Rule: Filter operators for the verified-working operator set, silent-drop detection, and derived-field unfilterability. Useful filter: widget_viewport=front to list only public-facing widgets.

See also: getWidget (single by ID), createWidget (add new), updateWidget (modify).

Returns: { status: "success", total, current_page, total_pages, next_page, prev_page, message: [...records] }. Each record carries the full widget object (fields enumerated in the table that follows).

Widget object fields (from BD support article 12000108056):

Field

Type

Description

widget_id

integer

Primary key (read-only)

widget_name

string

Widget name/label - REQUIRED on create; unique per site

widget_type

string

Widget classification (default: Widget)

widget_data

text

Widget HTML content

widget_style

text

Widget CSS styles

widget_javascript

text

Widget JavaScript code

widget_settings

text

Configuration (JSON or serialized)

widget_values

text

Widget variable values

widget_class

string

CSS class names applied to container

widget_viewport

string

Where widget appears: front, admin, both

widget_html_element

string

Container element (default: div)

div_id

string

HTML ID attribute for container

short_code

string

Shortcode reference for this widget

bootstrap_enabled

integer

1 if Bootstrap framework loaded

ssl_enabled

integer

1 if SSL/HTTPS required

mobile_enabled

integer

1 if mobile viewport enabled

file_type

string

File type of the widget

revision_timestamp

timestamp

Last modified (auto-updated)

is_default

boolean

false = the site's own record, true = an uncustomised master default (read-only; filter with property=is_default). See Rule: Default-merge models.

Site records and platform master defaults are merged in the response — see Rule: Default-merge models to filter to one and to sort.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPagination cursor (use next_page from previous response)
limitNoRecords per page (default 25, max 100)
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
include_codeNoOpt in to return `widget_data`, `widget_style`, `widget_javascript` (the HTML/CSS/JS) on each row. Default stripped. Needed before `updateWidget` edits to the code.
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?

The description explains read-only nature (redundant with annotations but adds context), the lean-by-default keep-list, pagination cursor/cap/stop, silent-drop detection, derived-field unfilterability, and default-merge model. It significantly supplements the 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 lengthy but well-structured with sections, bullet points, and a table. It front-loads the core purpose and then provides necessary details. Minor redundancy but overall efficient for the complexity.

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, filtering, default-value merging, the return format, and a full table of widget object fields. No output schema exists, so the description compensates thoroughly.

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 coverage is 100%, so baseline is 3. The description adds meaningful context: 'include_code=1 to restore widget_data/style/javascript', 'Useful filter: widget_viewport=front', and detailed filter operator descriptions. It provides value beyond the schema.

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's purpose: 'List widgets - Paginated enumeration of widget records.' It specifies that it's for discovering reusable components and distinguishes from related tools like getWidget, createWidget, and updateWidget.

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?

Explicitly states when to use: 'Use when: discovering the reusable HTML/CSS/JS components available for embedding...' and provides alternatives: 'For fetching one specific widget by ID use getWidget.' Also includes filter/sort tips and references to rules.

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