Skip to main content
Glama
hermoso-ai

Hermoso

Official

Retry a failed scheduled post

retry_scheduled

Retry failed scheduled posts by re-queuing only unpublished channels, with optional field corrections (board, captions, etc.) to fix the cause and avoid duplicates.

Instructions

Send a post that FAILED again. A scheduled post fans out across its channels INDEPENDENTLY, so a failure is usually PARTIAL — LinkedIn 401s while Instagram published fine — and this re-fires ONLY the channels that did not succeed by default (list_scheduled reports them as retryable). It re-queues the same content as a NEW post that goes out RIGHT AWAY — the queue picks it up on its next pass, within seconds — and the original keeps its failure record so the history still shows what went wrong. Naming a channel that already published is REFUSED rather than quietly posting a second time. Two independent belts stop a double-post: a channel that genuinely published can only REPLAY (nothing is posted), and a channel whose outcome is UNRESOLVED — the platform timed out and may be holding the post — refuses with that reason instead of guessing. Retry after fixing the cause — and you can fix it IN THIS CALL: pass boardId, pageId, linkedinOrganizationId, locationId, message or captions to correct the value that failed, and the corrected post is re-validated exactly like a fresh schedule. That matters because the commonest cause is a field, not an outage: a Pin aimed at the wrong board fails identically however many times it is re-sent. Anything you do not name is copied from the original. To send the same thing again ON PURPOSE, use duplicate_scheduled.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
atNohold the retry until a later time — ISO timestamp or epoch milliseconds. Leave it out to retry immediately, which is almost always what you want. A time you name here must be at least a minute from now, exactly like any other scheduled post.
idYesthe scheduled post id from list_scheduled
chatIdNoCORRECT THE TELEGRAM DESTINATION on retry — the @username or numeric id of the chat. A post aimed at a chat the bot is not in fails every time it is retried until this changes.
pageIdNoCORRECT THE PAGE on retry — which connected Facebook Page (and its linked Instagram/Threads) publishes, from list_meta_pages.
boardIdNoCORRECT THE BOARD on retry — the Pinterest board the Pin goes on, from list_pinterest_boards. A Pin aimed at a board Pinterest refuses fails the same way on every retry until this is changed.
messageNoCORRECT THE CAPTION on retry — use this when the original was refused for length or content. Anything not named here is copied from the original post.
captionsNoCORRECT ONE CHANNEL’S CAPTION on retry, e.g. { "x": "..." } when only that channel refused the text.
channelsNoretry only these channels (default: every channel that did not publish)
locationIdNoCORRECT THE LISTING on retry — which Google Business Profile location, e.g. "locations/123" from list_business_locations.
allowDuplicateNoONLY for a channel you have checked by hand and confirmed the post is genuinely NOT there. It bypasses the double-post protection and can publish a second public copy, so never set it to work around a refusal you have not investigated.
linkedinOrganizationIdNoCORRECT THE LINKEDIN AUTHOR on retry — the company Page id from list_linkedin_pages. Set it to an empty string to fall back to the personal profile.
Behavior5/5

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

Annotations provide only basic hints (readOnlyHint false, destructiveHint false), so the description carries the full burden of behavioral disclosure. It does this richly: explains partial failures, re-queues as a new post that goes out right away, keeps the original's failure record, refuses to double-post, and handles unresolved outcomes with explicit refusal. No contradiction with annotations; it goes far beyond them.

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 highly front-loaded, opening with the core purpose and then layering details. Each sentence adds crucial operational or safety information, but the overall length is considerable (600+ words). While dense and necessary for this complex tool, it could be tightened slightly without losing value; still, it eams its place overall.

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 tool's complexity (multi-channel fan-out, partial failures, safety mechanisms), the description covers all essential behaviors: what happens on retry, what gets refused, how to correct fields, the copy behavior, and the timing of re-queueing. It references list_scheduled for identifying retryable channels, and explicitly names the sibling tool for intentional duplicates. No gaps for correct invocation.

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?

Even though schema coverage is 100%, the description adds significant meaning: it identifies which parameters are for correcting failures (boardId, pageId, linkedinOrganizationId, locationId, message, captions), explains that unspecified fields are copied from the original, and gives detailed semantics for allowDuplicate including its bypass of double-post protection. This goes well beyond the schema's own descriptions.

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 opens with 'Send a post that FAILED again', a specific verb+resource that immediately distinguishes it from scheduling, rescheduling, or duplicating. It elaborates on partial failures and re-firing only failed channels, and explicitly names duplicate_scheduled as the alternative for intentional resends, so an agent can clearly tell it apart from siblings without inspecting 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?

The description gives explicit when-to-use guidance: after a failure, after fixing the cause, and for correcting specific fields in the same call. It also states when NOT to use it (for sending the same thing on purpose, use duplicate_scheduled) and warns about allowDuplicate misuse, leaving no ambiguity about the correct scenarios.

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/hermoso-ai/hermoso'

If you have feedback or need assistance with the MCP directory API, please join our Discord server