Skip to main content
Glama
hermoso-ai

Hermoso

Official
by hermoso-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Configure the posting refill

set_post_refill
DestructiveIdempotent

Turn automatic post refill on or off and adjust its behavior, including channels, daily caps, spend limits, queue horizon, and dry-run previews.

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 profile is ignored rather than failing the whole post.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.374
    • changedInput schema / properties / linkedinOrganizationId / description
      Previous value: -"LINKEDIN — 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."New value: +"LINKEDIN — which company Page to post as (list_linkedin_pages). A single shared Page is used automatically; a Page that is not shared with this profile is ignored rather than failing the whole post."
  2. Addedv0.1.161

TDQS

A4.9/5.0
Behavior5/5

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

Annotations declare this is destructive (destructiveHint true) and non-read-only; the description fills in the exact contours: enabled:false deletes the recurring job but leaves queued posts untouched, dryRun defaults to true and plans without queueing, and maxImagesPerDay/maxVideosPerDay/maxCreditsPerDay above 0 triggers spending on new creative with cost implications. That is genuine added context 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?

Front-loaded with the core action and the pass-only-changes rule, then topics chunked in short clauses. Dense but every sentence carries behavioral or routing information; mild redundancy between the description's dryRun/enabled notes and the schema's own descriptions costs a point.

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?

For a 13-parameter, zero-required, mutation tool with no output schema, the description covers the safe operating procedure (dryRun preview, human read, go live), pause semantics, cost gating, cadence model, and sibling delegation. Nothing an agent needs to invoke this correctly is missing.

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?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema: the cadence is the brand's posting times not a number, postsPerDay caps below posting times and 0 uses every time, 0 on the max* fields means reuse Library renders at zero spend, and video is flagged as the expensive resource. These clarify cross-parameter behavior the schema alone does not.

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?

Specific verb (turn on/off, set behavior) plus resource (automatic posting refill), and it links conceptually to siblings: pause removes the recurring job, queue cancellation is delegated to cancel_scheduled, and preview runs through run_post_refill. An agent can distinguish it from get_post_refill and run_post_refill without opening schemas.

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 the pass-only-what-changes contract, the dryRun-first workflow with a human check via run_post_refill, and routes removal of already-queued posts to cancel_scheduled. When-to-use and safe-sequencing are both spelled out.

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