Simplo

Create post

create_post

Creates a single-image or video post as a draft (the default) or scheduled. A scheduled post is published to the real social accounts automatically at its time — ask the user before scheduling, then pass confirm: true. Pass the time as localTime with timeZone (Simplo resolves the offset), or as scheduledAt with its offset. The time must be in the future and on the hour (Simplo publishes once an hour, on the hour). A draft with a time is placed on that day in the plan (draft_scheduled) and does not send by itself. For a video post pass videoUrl (a public MP4 or MOV link, up to 100 MB) instead of imageUrl: Simplo copies it to its own hosting. The first frame is the cover (the picture Instagram shows on the profile grid); if the video starts on an empty or animating frame, pass coverAt with the second that shows what the post is about. For a video or picture that is a file rather than a public URL (one you rendered, or one the user has on their device), call create_upload_link, have the file sent to it, and pass its uploadId here instead of imageUrl or videoUrl. A video goes to Instagram (as a Reel), Facebook and TikTok, not to X. possibleDuplicateOf in the answer names another planned post within 14 days that opens the same way: ask the user whether both should stay.

Input Schema

Name	Required	Description	Default
`status`	No		draft
`caption`	Yes	Full caption, including hashtags
`confirm`	No	Must be true to schedule — confirms the user approved auto-publishing
`coverAt`	No	Video posts only: the second the cover is taken from (0 to under the video's length, hundredths). Without it the cover is the first frame
`imageUrl`	No	A hosted image URL, e.g. from generate_image
`timeZone`	No	The user's IANA time zone, e.g. America/Edmonton. Needed with localTime; with scheduledAt it only sets the zone scheduledLocal is shown in. The answer's scheduledLocal says how the saved time reads there: check it against what the user asked for
`uploadId`	No	From create_upload_link, once the file was sent: the post's video or picture; not together with imageUrl or videoUrl
`videoUrl`	No	A public video URL (MP4 or MOV) for a video post; not together with imageUrl
`localTime`	No	The time as the user's clock shows it, YYYY-MM-DDTHH:MM with no offset (e.g. 2026-11-09T12:00), with timeZone. Preferred over scheduledAt: Simplo works out the UTC offset in force on that date. Not together with scheduledAt
`platforms`	Yes
`projectId`	Yes	Simplo project id (from list_projects)
`aiGenerated`	No	Whether the post is AI-made (use it for AI-made video or voices): true shows it on TikTok with its "AI-generated content" label and marks a YouTube video as altered or synthetic content, false does neither. Omit to follow the defaults: on TikTok the brand's "Label TikTok posts as AI-generated" setting when on, else pictures are labelled and videos are not; on YouTube the brand's own synthetic content setting. get_post shows the TikTok result as tiktokAiLabel
`scheduledAt`	No	ISO 8601 time with offset, on the hour (e.g. 12:00, never 11:45), in the future; scheduling needs it or localTime. localTime with timeZone is safer
`youtubeTitle`	No	Video posts going to YouTube only: the video's title on YouTube, at most 100 characters, no < or >. Without it the title is the caption's first line with its hashtags dropped, and the whole caption is the description either way
`tiktokSettings`	No	TikTok accounts connected directly (not through Simplo's posting partner) need these on every post that goes to TikTok, or TikTok fails with "Choose who can see this TikTok post". Ask the user who can see it and whether comments are allowed; never choose for them

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 6, 2026

addedInput schema / properties / localTime

Added value: +{
+  "description": "The time as the user's clock shows it, YYYY-MM-DDTHH:MM with no offset (e.g. 2026-11-09T12:00), with timeZone. Preferred over scheduledAt: Simplo works out the UTC offset in force on that date. Not together with scheduledAt",
+  "type": "string"
+}

changedInput schema / properties / scheduledAt / description

Previous value: -"ISO 8601 time with offset, on the hour (e.g. 12:00, never 11:45); required when scheduling, and must be in the future"New value: +"ISO 8601 time with offset, on the hour (e.g. 12:00, never 11:45), in the future; scheduling needs it or localTime. localTime with timeZone is safer"

addedInput schema / properties / timeZone

Added value: +{
+  "description": "The user's IANA time zone, e.g. America/Edmonton. Needed with localTime; with scheduledAt it only sets the zone scheduledLocal is shown in. The answer's scheduledLocal says how the saved time reads there: check it against what the user asked for",
+  "type": "string"
+}

First observedNov 2, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already flag this as a non-read-only, non-idempotent mutation, and the description adds the crucial risks on top: a scheduled post auto-publishes to real accounts, times must be on the hour and in the future, drafts with a time never send, and videos are limited to 100 MB and copied to Simplo hosting. That is strong disclosure, but the description says nothing about what happens on partial platform failure or how to recover a mis-scheduled post (unschedule_post/publish_post siblings go unmentioned).

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?

It is a long single block, but front-loaded with the action and then the highest-risk fact (auto-publishing to real accounts). Every clause carries operational content — hour alignment, cover frame, upload fallback, platform exclusions — with no filler, though paragraphs or line breaks would have improved scanability.

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 15-parameter, nested-object mutation with no output schema, the description covers the full decision tree: draft vs scheduled, media source paths, scheduling time formats, video platform coverage, and how to interpret possibleDuplicateOf in the response. Nothing an agent needs to call this correctly is missing.

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?

Schema coverage is already 87%, so the schema carries most per-field meaning; the description still adds cross-parameter logic the schema cannot express, such as uploadId replacing imageUrl or videoUrl, the localTime-versus-scheduledAt exclusivity, and the confirm gate on scheduling. The aiGenerated and tiktokSettings subtleties are left mostly to the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a specific verb and resource plus the two output modes: "Creates a single-image or video post as a draft (the default) or scheduled." It also bounds the media types (single image or video), which implicitly separates it from create_carousel and create_reel, but it never names those siblings, so an agent must infer the boundary.

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?

Explicit routing conditions throughout: ask the user before scheduling and pass confirm: true, use localTime with timeZone in preference to scheduledAt, pass videoUrl instead of imageUrl for video, and call create_upload_link plus uploadId when the media is a local file rather than a public URL. It even states video does not go to X, and that possibleDuplicateOf should trigger a user question.

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

All Simplo tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?