Skip to main content
Glama
hermoso-ai

Hermoso

Official
by hermoso-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Configure the posting refill

set_post_refill
Idempotent

Configure the automatic posting refill: enable or pause recurring queue fills, cap new daily image/video renders and credits, and preview the plan in dry-run before it queues anything.

Instructions

Turn the automatic posting refill on or off and set how it behaves. PASS ONLY WHAT CHANGES. enabled:false is the PAUSE — it removes the recurring job outright, and posts already queued are left alone (cancel those with cancel_scheduled if you want them gone). It starts in dryRun, which plans and previews without queueing; set dryRun:false only once a human has read a preview from run_post_refill. THE CADENCE IS THE BRAND’S POSTING TIMES, not a number here: three posting times means three posts a day. Raising maxImagesPerDay / maxVideosPerDay / maxCreditsPerDay above 0 lets it SPEND on new creative — at 0 (the default) it only reuses renders already in the Library and costs nothing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chatIdNoTELEGRAM — which chat, group or channel posts go to (@username or numeric id). Without one, telegram is skipped: there is no default chat and posting to the wrong one is a public mistake.
dryRunNotrue (the default) = plan and preview only, queue nothing. Set false ONLY after a human has read a preview.
pageIdNoFACEBOOK / INSTAGRAM / THREADS — which connected Page to publish from (list_meta_pages). Omit for the brand’s only Page.
boardIdNoPINTEREST — which board Pins go on (list_pinterest_boards). Without one, Pinterest is skipped: a Pin on the wrong board is a public mistake, so it is never guessed.
enabledNoon/off. false PAUSES it: the recurring job is deleted and nothing new is queued. Already-queued posts are untouched.
channelsNorestrict it to these channels. Omit (or send an empty list) to use every connected channel that can carry each post.
daysAheadNohow far ahead to keep the queue full, 1–30 (default 7)
postsPerDayNocap the posts per day BELOW the number of posting times. 0 (default) = use every posting time, which is where "3 a day" comes from. To post MORE per day, add posting times instead.
maxImagesPerDayNohow many NEW images a day it may render when the Library runs dry. 0 (default) = none, spend nothing.
maxVideosPerDayNohow many NEW videos a day it may render. 0 (default) = none. Video is the expensive one — hundreds of credits each.
maxCreditsPerDayNoa hard credit ceiling per day, checked BEFORE any render starts. It binds independently of the counts above.
assetCooldownDaysNohow long before a Library render may be posted again (default 30). It never repeats one inside this window — it queues fewer posts and says so.
linkedinOrganizationIdNoLINKEDIN — which company Page to post as (list_linkedin_pages). A single shared Page is used automatically; a Page that is not shared with this brand is ignored rather than failing the whole post.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.161

TDQS

A4/5.0
Behavior1/5

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

Annotation contradiction: the description states that enabled:false removes the recurring job outright, which is a destructive side effect, while annotations set destructiveHint to false. Even though the description otherwise discloses dryRun defaults, spending behavior, and queued-post handling, the direct conflict requires a score of 1.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long, but justified for a 13-parameter configuration tool. It front-loads the most important constraints (pass only what changes, enabled:false is the pause) and every sentence contributes operational information without padding.

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?

It covers the critical invocation context: pause semantics, dryRun prerequisite, cadence source, spending controls, and references to run_post_refill and cancel_scheduled. It is slightly incomplete on what a successful response looks like and what an empty call with zero parameters does, but those are minor given the rich schema and partial-update guidance.

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?

Because schema description coverage is 100%, the schema already documents all 13 parameters. The description still adds value by explaining relationships between parameters: why raising maxImagesPerDay, maxVideosPerDay, or maxCreditsPerDay enables spending, how postsPerDay caps below posting times, and that maxCreditsPerDay binds independently.

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 opening sentence states a clear verb and resource: turn the automatic posting refill on or off and set its behavior. It also differentiates this tool from siblings like run_post_refill and cancel_scheduled, so an agent can identify which operation this tool performs.

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 gives explicit usage rules: pass only changed fields, keep dryRun true until a human has reviewed output from run_post_refill, use cancel_scheduled if queued posts must be removed, and recognize that cadence comes from the brand's posting times rather than a number here. This goes well beyond vague applicability.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools