Skip to main content
Glama
Instagram Account MCP

Instagram Account MCP

by joinhackyard

Publish a reel

publish_reel

Publish or schedule an Instagram reel by providing a video file or URL, with automatic 9:16 conversion, captions, covers, and background publishing after user confirmation.

Instructions

Publish (or schedule) a reel: 3 seconds to 15 minutes, up to 300 MB, 9:16 fills the screen (fit: crop or blur reframes other shapes). Converted to H.264/AAC MP4 when needed. Licensed music can't be added through the API. Needs the user's confirmation; runs in the background.

Input Schema

NameRequiredDescriptionDefault
fitNoReframing when converting: keep (only clamp into the allowed range), crop (fill the frame from the centre) or blur (whole frame over a blurred fill). Reels/stories target 9:16.
urlNoPublic http(s) URL of the file instead of a local path.
accountNoWhich connected account: @username or Instagram user ID. Omit to use the default account.
captionNoCaption (max 2,200 characters, 30 hashtags, 20 @mentions). The first ~125 characters show before 'more'. Captions can't be edited through the API after publishing.
prepareNoConvert to Instagram's specs with ffmpeg first (JPEG, H.264/AAC MP4, allowed aspect ratio and length). Default true.
templateNoTemplate from list_templates: adds header/footer, hashtags, first comment, collaborators.
cover_urlNoCover image URL instead of cover_file.
file_pathNoPath to the file on this computer, e.g. ~/Pictures/launch.jpg.
user_tagsNoPeople to tag in the reel.
audio_nameNoName for the reel's original audio.
cover_fileNoCustom cover image for the reels tab and grid (9:16 looks best).
publish_atNoSchedule: ISO 8601 date-time with timezone, at least 10 minutes and at most 75 days ahead. Instagram has no API scheduling, so this computer (or the background service) publishes it then; if the computer is off and the time passes by more than 2 hours, it is not published late (reschedule or resume_publish).
location_idNoFacebook Page ID of a place (see find_location).
wait_secondsNoWait this long for publishing before returning; then follow get_publish_status.
collaboratorsNoUp to 3 usernames invited as collaborators (they must accept in the app).
first_commentNoPosted as the first comment right after publishing (hashtags, credits, links).
share_to_feedNoAlso show the reel in the profile grid and feed (Instagram's default is yes).
is_ai_generatedNoSelf-disclose that the content was made or edited with AI (shows an AI label).
thumb_offset_msNoUse the frame at this time (ms) as the cover when no cover image is given.
confirmation_tokenNoOnly after the user approved: the confirmation_token returned by the previous call with identical arguments.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

The annotations already declare non-read-only, open-world, non-idempotent, and non-destructive behavior. The description adds meaningful operational context beyond those annotations: duration and size limits, automatic H.264/AAC MP4 conversion, the inability to add licensed music via API, required user confirmation, and background execution.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded, moving from the core action to key constraints, conversion behavior, licensing limitation, and confirmation/background behavior. Every sentence carries useful information and there is no redundant wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 20-parameter publishing mutation with no output schema, the description covers the most important operational constraints and the confirmation/background model. It stops short of explaining return behavior or status polling, though the wait_seconds schema and get_publish_status sibling tool provide related guidance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 20 parameters in detail. The description adds some useful media context around fit and 9:16 reframing, but most of that meaning is already present in the schema, making a baseline 3 appropriate.

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 states a specific verb and resource: publish or schedule a reel. It adds concrete scope constraints (3 seconds to 15 minutes, up to 300 MB, 9:16 targeting) that distinguish this from generic media publishing and make the reel-specific purpose clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It indicates that the tool can publish or schedule and that user confirmation is required, which gives useful context. However, it does not explicitly explain when to use this versus sibling tools such as publish_trial_reel, publish_story, publish_photo, or publish_carousel, so the agent must infer selection from the tool name.

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