Skip to main content
Glama
brilliantdirectories

brilliant-directories-mcp

Official

updateSingleImagePost

Idempotent

Update an existing single-image post by its ID. Edit any fields while leaving others unchanged; changes apply live to the site.

Instructions

Update a post - Update an existing post record by ID. Fields omitted are untouched. Writes live data.

Use when: editing post content, switching from draft to published (post_status=0->1), updating post title/caption, or correcting post metadata. To move a post to a different post type (rare), pass data_id - but validate the new post type is still in the single-image family.

Required: post_id.

Enums: post_status: 0=Draft (saved but not publicly visible), 1=Published (publicly visible on the site).

post_title rename does NOT update post_filename (the URL slug). post_filename is writable — see Rule: URL slug rename for when to suggest a slug update + redirect. Report post_filename from getSingleImagePost when giving the user a URL.

See also: createSingleImagePost (add new), deleteSingleImagePost (remove permanently).

Returns: { status: "success", message: {...updatedRecord} } - the full updated record after changes applied.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latNo
lonNo
post_idYes
post_jobNoEmployment type - Job post types only.
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_snNo
post_tagsNoComma-separated keywords for the post.
country_snNo
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. Pair with `auto_image_import=1` to fetch externals into site storage.
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_videoNoYouTube/Vimeo URL - Video post types only.
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. Requires the "Pretty URLs with Google Maps" site feature.
post_captionNoDeprecated. Leave unset unless user explicitly references it.
post_contentNoPost body HTML. Froala body field — see **Rule: Post-body formatting** (structure, `fr-dib fr-fil`/`fr-fir` float + inline `width: 350px`, landscape Pexels images).
_clear_fieldsNoColumn names to clear to empty string. Available on every `update*` operation. Works on base columns AND EAV/`users_meta` rows (rows preserved with `value=""`). To actually clear a field you MUST use this parameter — sending the field with `""` alone is a no-op (BD drops empty values). To remove a `users_meta` row entirely, use `deleteUserMeta`. See **Rule: Clearing fields**. Example: `_clear_fields: ["h2", "hero_link_url"]`.
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_filenameNoPublic URL slug path (e.g. `blog/my-post-slug`). Writable — BD does NOT regenerate the slug when `post_title` changes. See **Rule: URL slug rename** for when to suggest a slug update + redirect.
post_locationNoFull or partial street address (Event/Coupon/Job/geo-enabled post types).
post_live_dateNoCreation date stored on the post. Format: `YYYYMMDDHHmmss` in the site's timezone. BD silently truncates other formats, corrupting the value.
post_meta_titleNo
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_keywordsNo
post_meta_descriptionNo
Behavior5/5

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

Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds valuable behavioral details: 'Fields omitted are untouched', 'Writes live data', the note that post_title rename does not update the slug, the behavior of _clear_fields, and timezone rules for dates. This goes well beyond 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 clear sections (summary, use when, required, enums, behaviors, see also, returns). It is front-loaded with essential purpose. While verbose, every sentence adds value; a very minor deduction for length.

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 high complexity (29 parameters, no output schema), the description is exceptionally complete. It explains the return format, cross-references other rules and tools (e.g., 'Rule: URL slug rename', 'getSingleImagePost'), and covers edge cases like timezones and clearing fields.

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?

Despite 66% schema coverage, the description adds significant meaning for many parameters: post_image requirements (landscape orientation, URL format, auto_import), post_promo relationship (must send both), post_category discovery via other tools, _clear_fields special behavior, date formats and timezone rules, and more. This compensates for schema gaps.

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 verb 'update' and the resource 'post', and specifies that it updates an existing post record by ID. It differentiates from siblings like createSingleImagePost and deleteSingleImagePost by stating 'Update an existing post record' and referencing them in 'See also'.

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 explicitly lists when to use the tool: 'editing post content, switching from draft to published, updating post title/caption, or correcting post metadata.' It also provides exclusion context: moving to a different post type is rare and requires validation via data_id. Additionally, it references sibling tools for creation and deletion.

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