Skip to main content
Glama

Retry a failed scheduled post

retry_scheduled

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.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only indicate readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description goes far beyond by explaining the re-queue mechanics (new post, immediate pickup), preservation of the original failure record, double-post protection with two independent belts, and refusal for unresolved outcomes. It also discloses the side-effect of publishing a new post, consistent with openWorldHint. No contradictions.

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 every sentence serves a purpose given the tool's complexity (11 parameters, partial failures, double-post protection). It is front-loaded with the core action and then logically progresses through failure modes, correction, and alternatives. It could be slightly trimmed, but it remains efficient and well-structured.

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 tool with 11 parameters and intricate retry semantics, the description covers all critical context: partial failures, retryable status from list_scheduled, default channel behavior, refusal of published channels, unresolved outcome handling, and re-validation of corrected fields. It also references list_scheduled and duplicate_scheduled for related tools. No output schema exists, but the description sufficiently communicates expected effects.

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 each parameter already has a description. The description adds meaning by grouping correction parameters (boardId, pageId, linkedinOrganizationId, locationId, message, captions) and explaining the default behavior for 'channels'. It also clarifies the allowDuplicate bypass and its risk, and the semantics of linkedinOrganizationId empty string fallback. This goes well beyond the schema.

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 a precise verb+resource: 'Send a post that FAILED again.' It clearly distinguishes itself from duplicate_scheduled by explicitly naming the alternative: 'To send the same thing again ON PURPOSE, use duplicate_scheduled.' It also explains the partial-failure nuance, making the tool's specific scope unmistakable.

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 explicit when-to-use guidance ('Retry after fixing the cause') and when-not-to-use ('Naming a channel that already published is REFUSED'), plus the alternative tool (duplicate_scheduled) for intentional reposting. It even details the default channel selection behavior, leaving zero ambiguity.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0
Disambiguation2/5

With 293 tools, the surface is enormous and many tools have overlapping purposes—multiple posting tools (post_to_meta, post_to_linkedin, schedule_post, etc.), multiple analytics tools per channel, and several search tools (search_meta_ads, search_instagram, search_reddit...). While each description is detailed, the volume makes it difficult for an agent to reliably distinguish between similar tools without careful reading, leading to frequent misselection.

Naming Consistency4/5

The naming is largely consistent with a verb_noun pattern (post_to_*, list_*, create_*, delete_*, update_*, manage_*). There are clear families for major operations. A few outliers like 'google_business_account', 'hermoso_capabilities', and 'store_get' break the pattern, but the overwhelming majority follow a predictable structure, making navigation somewhat easier.

Tool Count1/5

293 tools is far beyond any reasonable scope for a single MCP server, even for a comprehensive marketing platform. The calibration guide flags 50+ as an extreme mismatch, and this is nearly six times that threshold. Such a large surface overwhelms context windows, increases the probability of misselection, and makes it impractical for agents to learn or use effectively.

Completeness4/5

The tool set covers a vast domain: ad creation and rendering, posting across nine+ social channels, analytics and reporting, file management (Drive/OneDrive), competitor research, brand management, and more. It appears to provide CRUD and lifecycle coverage for most resources. While there may be minor gaps given the immense scope, the overall coverage is impressively comprehensive.