Skip to main content
Glama

sprkly

by app.sprkly

Schedule a post

sprkly_schedule_post

Queue a post for publishing, in ONE call. Attach media by passing the user's link straight to media_urls: sprkly downloads it into storage itself for the platforms that need that, so no upload tool has to run first. Runs the same quota, duplicate-content and platform pre-flight checks as the sprkly app. Instagram and TikTok require media at submission time; YouTube and TikTok require a title, and TikTok also requires platform_meta.tiktok.privacyLevel — just send the level the user asked for and this tool names the allowed values if it is not one of them. It reads the real bytes of the media and the response says what will actually publish on each platform (a Reel, a 3-slide carousel, a photo set, a Page feed video) plus anything worth passing on: relay that to the user. Confirm the date, time and target accounts with the user first. If a target platform has more than one connected account and profile_ids is not given, the tool returns needsAccountChoice with the options instead of scheduling — put that choice to the user, then re-call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNoPost title. Required for YouTube (max 100 characters) and TikTok (max 150 characters).
captionNoPost caption, max 2200 characters.
categoryNoOptional content category, e.g. "fitness".
media_idNoId of a single media file already uploaded to sprkly. Shorthand for a one-item media_ids.
media_idsNoIds of media files already uploaded to sprkly, in slide order. Array order is the published order. Use these when the user already has media in sprkly, or when one file is going on several posts; for a link the user just gave you, media_urls is fewer steps. Every photo in a set must be the SAME shape or the call is refused: export them all at 1080x1920 (9:16), 1080x1440 (3:4), 1080x1350 (4:5) or 1080x1080 (1:1). Instagram takes at most 10 slides; TikTok photo sets take up to 35.
platformsNoPlatforms to publish to. A platform with exactly one connected account is targeted directly; one with several makes the tool answer needsAccountChoice so the user can pick.
media_urlsNoPublicly reachable image or video URLs to attach, in slide order. Pass links through for ANY platform. Instagram and Threads fetch them directly; for TikTok, YouTube and Facebook sprkly downloads the file into its own storage while scheduling, so a link works there too and any problem with it is reported now, in this call. Google Drive and Dropbox share links are converted automatically. JPEG, PNG, WebP, GIF, MP4, MOV and WebM only: AVIF and HEIC (the iPhone camera default) are refused with re-export instructions, because sprkly cannot convert them. Each file must be publicly reachable and under 50 MB.
profile_idsNoSpecific accounts to publish to, from sprkly_list_profiles. When given, this list IS the target set — platforms are not fanned out.
all_accountsNoExplicitly post to EVERY connected account on every listed platform, skipping the needsAccountChoice question. Only pass true when the user has said they want all accounts.
platform_metaNoPlatform-specific publishing options, keyed by platform.
scheduled_timeNoISO 8601 timestamp to publish at. Must be in the future. If omitted the post goes out on the next publisher run, about a minute from now — there is no smart slot-picking, so pass an explicit time unless the user wants it published immediately. sprkly_get_analytics can suggest one.

TDQS

A4.8/5.0
Behavior5/5

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

Beyond annotations, the description reveals concrete behaviors: media is downloaded by sprkly, quota and duplicate checks run, platform-specific pre-flight checks happen at scheduling time, and platform-specific outcome types are reflected in the response. It also discloses that 'the response says what will actually publish' and instructs the agent to relay that to the user, including a needsAccountChoice instead of silently scheduling.

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 long but well organized and fronts the most important idea: this tool is the quick scheduling path. Each sentence earns its place by covering a distinct operational detail, though some details are also encoded in the schema and could have been trimmed slightly without losing value.

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 highly complex 11-parameter tool with no output schema, the description does an excellent job of covering key behaviors, error paths, platform-specific requirements, and agent follow-up actions. It tells the agent what the response reveals, what to report to the user, and how to handle the multi-account case. I can now say information absent from the description would materially impair correct usage.

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?

The schema already covers all 11 parameters with detailed descriptions, so this is a strong baseline. The free-text description adds important semantics beyond individual fields: the choice between media_urls and media_ids as process guidance, the meaning of 'valid media' by platform, and the platform-specific effects of TikTok privacyLevel and Instagram surface.

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 specific verb and resource: 'Queue a post for publishing, in ONE call.' It clearly distinguishes scheduling from related operations like uploading media or drafting by noting the multi-step bypass and by explaining that this call performs scheduling. It describes the scope (publishing to multiple platforms) without ambiguity.

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: users can pass raw media links to bypass an upload tool, account selection is clarified, and the tool instructs re-calling after the user makes a choice. It also tells the agent to confirm date, time, and target accounts first, and references when to pass profile_ids versus let the tool detect the account choice.

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

All sprkly toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation5/5

Every tool targets a distinct action and resource: media ingestion, draft creation, scheduling, deleting, updating, validation, approval, analytics, and account/profile listing. The only slight overlap is between sprkly_list_profiles and sprkly_list_scheduled_posts, but they serve clearly different purposes (target selection vs. queue view).

Naming Consistency5/5

All 16 tools follow the exact sprkly_verb_noun pattern with lowercase snake_case. Verbs are consistent (add, delete, draft, get, list, request, schedule, update, validate) and nouns are clear (media, scheduled_post, account_summary, analytics, profiles, etc.). No style mixing or vague naming.

Tool Count4/5

16 tools is slightly above the typical 3–15 sweet spot but each tool covers a distinct part of the content-scheduling lifecycle. The count feels justified given the breadth of features (media, drafts, scheduling, approvals, analytics), though a few tools could be merged (e.g., get_account_summary could be part of analytics) without much loss.

Completeness4/5

The surface covers the core workflows well: draft, schedule, update, delete, approve, validate, and analyze. Minor gaps exist—there's no explicit tool to list drafts or edit a draft after submission, and no direct way to unpublish or cancel an approval—but the domain is well-served for typical scheduling needs.

Resources