Skip to main content
Glama
brilliantdirectories

brilliant-directories-mcp

Official

createSingleImagePost

Create a new single-image post for blog articles, events, jobs, or coupons. Provide user ID, post type ID, and data type to publish.

Instructions

Create a post - Create a new post record. Writes live data.

Use when: creating a blog article, event, job listing, coupon, or any other single-image post type. Look up data_id + data_type via listPostTypes first - the post type's data_type field determines which create endpoint is correct. If data_type=4 on the post type, use createMultiImagePost instead. For posts with scraped external image URLs, include auto_image_import=1 to fetch and store them locally.

Required: user_id, data_id, data_type.

Pre-check before create: BD does NOT enforce uniqueness on post_title, and BD auto-generates filename (the URL slug) from the title - so a duplicate title produces a URL collision (two posts fighting for the same public URL, unpredictable which one resolves). Do a server-side filter-find: listSingleImagePosts property=post_title property_value=<proposed> property_operator==. Zero rows = title free; >=1 row = taken. If post_title contains a comma (the = operator trips the CSV validator on commas only - colons and other characters are safe), switch to property_operator=like property_value=<distinctive-prefix>% using a 3-4-word prefix unique to this event. Do NOT paginate unfiltered lists - sites in the wild have thousands of posts; filtered lookup is one tiny response. If taken: reuse via updateSingleImagePost, OR ask the user, OR pick an alternate post_title and re-check. Never silently create a duplicate.

Parameter interactions:

  • user_id - owner; must be an existing member (discover via listUsers or searchUsers)

  • data_id - post type category ID; get via listPostTypes

  • data_type - data type classification; usually matches the post type's data type

  • post_status: 0=Draft (not visible), 1=Published (public)

  • Response includes both post_id and post_token - the token is used for sharable URLs

See also: updateSingleImagePost (modify existing).


Which endpoint to use - data_type family decides:

Every post type in data_categories has a data_type field that classifies its family. Call listPostTypes or getPostType to see the data_type of your target post type, then choose:

data_type value

Family

Use endpoint

4

Multi-image (albums, galleries, photo-heavy listings - e.g. Classified, Photo Album, Property, Product)

createMultiImagePost

9

Single-image video

createSingleImagePost

20

Single-image article / event / blog / job / coupon

createSingleImagePost

10, 13, 21, 28, 29 (and similar)

Internal admin types (Member Listings, Reviews, Sub Accounts, Specialties, Favorites) - NOT posts

Use the resource-specific endpoint (e.g. createReview for data_type=13)

If you call the wrong create endpoint for a given post type, BD may accept the row but it won't render on the public site correctly.

For "make a blog post" intent: look up data_categories for data_name matching "blog" (commonly data_id=14 with data_type=20) -> createSingleImagePost with that data_id + data_type.

For "make a photo album" / "gallery" intent: look up the album post type (often data_id=10, data_type=4) -> createMultiImagePost with that data_id + data_type. Photos are added separately via createMultiImagePostPhoto using the returned group_id.

Picking post_category (and other per-type dropdowns): post_category values are configured PER POST TYPE by the site admin in the post type's feature_categories CSV. Read the CSV from your listPostTypes/getPostType result (or getPostTypeCustomFields.post_category.choices where your workflow routes through it) and pass ONE value from it VERBATIM - never from getSingleImagePostFields.post_category.choices, which BD fills from platform master defaults on some forms - BD does not trim whitespace when splitting feature_categories, so options after the first may have a leading space (e.g. " Category 2"). If the user names a category that isn't in the list: ask whether to pick the closest existing option or have them add the new option in BD admin first - do NOT invent a new value. WARNING: if form_name does not match a real post type form, getSingleImagePostFields silently returns a generic SUPER-UNION field list (HTTP 200, no error) - verify form_name exists in listPostTypes first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latNoLatitude for the post's location (geo-enabled post types). Decimal degrees as string.
lonNoLongitude for the post's location (geo-enabled post types). Decimal degrees as string.
data_idYesParent post-type ID (data_categories.data_id, from listPostTypes).
user_idYes
post_jobNoEmployment type - used by Job post types only. Other post types ignore this field.
post_urlNoExplicit CTA button link rendered under the feature image on the post-detail page. Use when the owner wants a prominent button. Full `http(s)://` URL. Stored in `users_meta` (database=`data_posts`, database_id=this `post_id`, key=`post_url`), not the `data_posts` column - the wrapper routes it automatically, scoped to this post.
state_snNo2-letter state/region code for the post's location (e.g. `CA`).
data_typeYesClassification family, read from target post type's `data_type` column (via `listPostTypes`/`getPostType`). Values: - `4` = multi-image - use `createMultiImagePost` instead - `9` = single-image video - `20` = single-image article/event/job/coupon Internal-only values (`10`, `13`, `21`, `28`, `29`) are NOT post-creatable via this endpoint - use the resource-specific creator (e.g. `createReview` for `13`). Do NOT call `listDataTypes` - `data_type` is a classification, not a per-site FK.
post_tagsNoComma-separated keywords for the post. Free-form strings - not related to the `Tags` resource.
country_snNo2-letter country code for the post's location (e.g. `US`).
post_imageNoFeature image URL. **LANDSCAPE only — verify orientation via `getImageDimensions` per **Rule: Image dimensions** before commit; bare URL, no `?query`, must end in `.jpg`/`.jpeg`/`.png` (WebP/GIF/AVIF skipped pre-tool per the same rule) — see **Rule: Image URLs**.** Query strings (`?w=1600`, `?auto=compress`) get baked into the imported filename and 404. Default: Pexels landscape URL + `auto_image_import=1` (skip only on explicit no-image request).
post_priceNo
post_promoNoTwin of post_price (job pay, event ticket price, coupon price — live-verified on jobs and events). BD requires post_promo to populate post_price — send post_promo (BD back-fills post_price). Sending post_price alone leaves post_promo null.
post_titleNo
post_venueNoEvent/post venue name/landmark where the event is held (e.g. `Staples Center`) - distinct from `post_location` (the street address). Free text. Stored in `users_meta` (database=`data_posts`, database_id=this `post_id`, key=`post_venue`), not the `data_posts` column - the wrapper routes it automatically, scoped to this post.
post_videoNoFull URL of a YouTube or Vimeo video. Only used by Video post types (`data_type=9`).
post_statusNo0=Not Published, 1=Published, 3=Pending Approval (rare — set when site admin requires manual moderation before posts go live).
auto_geocodeNoSet to `1` to geocode the post's location via Google Maps (uses `post_location`/lat/lon/state_sn/country_sn if supplied). Requires the "Pretty URLs with Google Maps" site feature.
post_captionNoDeprecated. Leave unset unless user explicitly references it.
post_contentNoMain HTML body of the post. Froala body field — see **Rule: Post-body formatting** (structure, `fr-dib fr-fil`/`fr-fir` float + inline `width: 350px`, landscape Pexels images). HTML allowed; supports `[widget=Name]` shortcodes and `%%%template_tokens%%%`.
post_categoryNoPer-post-type dropdown value, configured in BD admin on the post type's `feature_categories` field. Discover allowed values from `feature_categories` on your `listPostTypes`/`getPostType` result, or `getPostTypeCustomFields.post_category.choices` where your workflow routes through it - NOT from `getSingleImagePostFields.post_category.choices` (BD fills that from platform master defaults on some forms). Pass VERBATIM - BD does not trim whitespace, so leading spaces after commas in `feature_categories` persist in the stored option values.
post_locationNoFull or partial street address for the post (Event, Coupon, Job, or any geo-enabled post type). Pair with `auto_geocode=1` to resolve to lat/lon automatically, or set `lat`/`lon`/`state_sn`/`country_sn` explicitly.
post_live_dateNoCreation date stored on the post. Format: `YYYYMMDDHHmmss` in the site's timezone. BD silently truncates other formats, corrupting the value. Usually auto-set on create; override only for import/migration.
post_meta_titleNoSEO `<title>` override for the post's public page.
post_start_dateNoScheduled publish date — when the post becomes visible on the public site. Set a future timestamp to schedule (like WordPress's future-publish); set a past timestamp for immediate visibility. REQUIRED on Event post types (marks when the event begins); optional but commonly used on blog/article/news post types for scheduled publishing. Format: `YYYYMMDDHHmmss`. **Event post types: event-local wall-clock** — the time as a visitor in the event's city would read it; do NOT convert to the site's own timezone (a 7 PM Brooklyn event on a Los Angeles-timezoned site stores as `20260616190000`). **Scheduled-publish on blog/article/news types: site timezone.** BD silently truncates other formats, corrupting the value. The wrapper auto-derives `start_time` (`"H:MM AM/PM"`) from this value on `createSingleImagePost` / `updateSingleImagePost` so BD's form-edit time-of-day dropdown stays populated — agent never passes `start_time` directly.
post_expire_dateNoEnd/expiration date. Coupon post types use this for expiration; Event post types use it for end time. Format: `YYYYMMDDHHmmss`. **Event post types: event-local wall-clock** (match `post_start_date`). **Coupons and other post types: site timezone.** BD silently truncates other formats, corrupting the value. The wrapper auto-derives `end_time` (`"H:MM AM/PM"`) from this value on `createSingleImagePost` / `updateSingleImagePost` — agent never passes `end_time` directly.
auto_image_importNo**Auto-import images to site storage.** Set `1` when any external image URL field on this single-image post (e.g. `post_image`) holds a URL - BD fetches the image and saves locally. Without the flag, BD stores the URL as-is; images break if source host goes down. **Recommended default when supplying external image URLs**; omit or set `0` only if user explicitly wants the external URL reference. Supports JPG/PNG/GIF/WebP/SVG. Processing delay: several minutes.
post_meta_keywordsNoSEO meta keywords (comma-separated) for the post's public page.
post_meta_descriptionNoSEO meta description override for the post's public page.
Behavior5/5

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

Annotations indicate readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description goes far beyond annotations: it explains that the tool writes live data, auto-generates filename from title causing URL collision, details auto_image_import behavior (processing delay, formats supported), and notes that invalid calls may silently accept data but break rendering. It also describes parameter interactions like post_promo vs post_price and date format sensitivities. 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 lengthy but well-structured with clear headings, bullet points, tables, and hierarchical breakdowns. It front-loads the core purpose and usage guidance, then dives into details. While some sections are verbose (e.g., the endpoint family table), the complexity of 29 parameters justifies the length. A slightly more condensed version would be ideal, but current structure is functional.

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 complexity (29 parameters, 3 required, no output schema), the description covers all essential aspects: required parameters, parameter interactions, pre-check logic, error handling (duplicate titles, silent failures), alternative tools (createMultiImagePost, updateSingleImagePost), and special cases (date formats, timezone, CSV whitespace). It leaves minimal gaps for an agent to infer, making it highly complete.

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?

With 90% schema description coverage, the schema already documents most parameters. The description adds significant value beyond the schema: it clarifies the relationship between post_price and post_promo (post_promo must be sent to populate both), explains that post_category values must come from feature_categories (not getSingleImagePostFields), and provides date format examples and timezone rules. This is a meaningful addition, earning above the baseline 3.

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 explicitly states 'Create a post - Create a new post record.' and clarifies the specific post types (blog, event, job, coupon) it handles. It distinguishes from sibling tools like createMultiImagePost by detailing data_type values that determine which endpoint to use. The purpose is highly specific and actionable.

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 comprehensive usage guidance: when to use (e.g., blog, event, job, coupon), when to avoid (data_type=4 → use createMultiImagePost, internal types → other endpoints), and prerequisites (look up data_id/data_type via listPostTypes). It includes a detailed pre-check for duplicate titles with alternative actions, and covers parameter interactions and edge cases like commas in post_title. This far exceeds basic usage instructions.

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