Skip to main content
Glama
brilliantdirectories

brilliant-directories-mcp

Official

listSingleImagePosts

Read-onlyIdempotent

Retrieve a paginated list of single-image posts (blog, events, jobs, etc.) with core fields. Optionally include content, SEO meta, author details, clicks, photos, or extras via flags.

Instructions

List posts - Paginated enumeration of post records. Read-only.

Lean-by-default keep-list: rows return only the core identity + routing + load-bearing fields: post_id, post_title, post_filename, post_status, post_start_date, post_expire_date, post_location, post_venue, post_category, data_id, data_type, system_name, data_name, data_filename, user_id, post_image, original_image_url, revision_timestamp, plus total_clicks (only when > 0) / total_photos rollups. Everything else stripped — restore via flags:

  • include_content=1 - return post_content (HTML body).

  • include_post_seo=1 - return post_meta_title, post_meta_description, post_meta_keywords.

  • include_author_full=1 - return the full user nested object. Default omits author detail entirely; call getUser(user_id) for author records.

  • include_clicks=1 - return the full click array under user_clicks_schema.

  • include_photos=1 - return the full users_portfolio photo array (multi-image posts).

  • include_extras=1 - return everything else (lat, lon, country_sn, state_sn, post_org_url, post_date, post_live_date, post_updated, post_token, post_clicks, recurring_type, sticky_post, post_featured, post_tags, post_job, post_video, post_price, image_imported, etc.).

Use when: enumerating posts of single-image families - blog articles, events, jobs, coupons, videos, discussions. Filter by user_id for one member's posts, or data_id to scope to one post type. Before using, confirm the target post type has data_type 9 or 20 (single-image); data_type=4 means multi-image and you want listMultiImagePosts instead.

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.

See also: getSingleImagePost (single record by ID). For keyword-in-body matching, use this tool with property=post_title property_operator=LIKE (or post_caption/post_content).

Returns: { status: "success", total, current_page, total_pages, next_page, prev_page, message: [...records] }. Each record is the lean-shaped resource object.

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
order_columnNoColumn to sort by — a column key present on the response rows (a wrong name silently returns empty)
include_clicksNoOpt in to return `user_clicks_schema.clicks` array. Default: `total_clicks` count surfaced only when > 0; absent means zero clicks.
include_extrasNoOpt in to return ALL remaining fields on this resource that are not in the lean-by-default keep-list and not gated by another `include_*` flag. Lean default returns only the core identity, routing, and load-bearing fields. `include_extras=1` restores everything else (geo, all hero_*, layout/sidebar/menu config, all display toggles, admin metadata, etc.). Resource-specific — see each tool's description for what the extras bundle contains.
include_photosNoOpt in to return `photos_schema` array. Default: `total_photos` count only (`image_main_file` URL always returned).
property_valueNoValue to filter by; array to pair with a `property` array (same length).
include_contentNoOpt in to return the full `post_content` HTML body. Default stripped (`post_title` + `post_caption` always returned).
include_post_seoNoOpt in to return `post_meta_title`, `post_meta_description`, `post_meta_keywords`. Default stripped.
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.
include_author_fullNoOpt in to return the full original `user` nested object (every field BD returns, including `password` hash, session `token`, `cookie`). Default: author detail omitted entirely — call `getUser(user_id)` when needed.
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. Description adds value by explaining lean-by-default keep-list behavior, which fields are stripped/restored via include flags, and pagination mechanics.

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?

Long but well-structured with clear sections (lean-by-default, use when, pagination, filter/sort, see also, returns). Front-loaded with purpose. Every sentence serves a purpose, though could be slightly more terse.

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?

No output schema, so description must explain return format—it does: 'Returns: { status: "success", total, current_page, total_pages, next_page, prev_page, message: [...records] }.' Covers pagination, filter/sort, lean default, and references rules. Complete for agent use.

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%, baseline 3. Description adds significant context: explains lean default, what each include flag restores, and details on property, property_value, property_operator with references to rules. Meaningfully supplements 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?

Clearly states 'List posts - Paginated enumeration of post records. Read-only.' and distinguishes from sibling listMultiImagePosts by specifying data_type 9 or 20 for single-image posts versus data_type=4 for multi-image.

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 says 'Use when: enumerating posts of single-image families' and instructs to confirm data_type before use, with alternative tool mentioned. Also provides filter/sort and pagination guidance.

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