Skip to main content
Glama
Instagram Account MCP

Instagram Account MCP

by joinhackyard

Publish a photo post

publish_photo

Publish or schedule a single-image Instagram feed post, auto-converting and fitting images to Instagram's aspect ratio. Confirm first; it runs in the background, so check get_publish_status.

Instructions

Publish (or schedule) a single-image feed post. Images are converted to JPEG and fitted into Instagram's 4:5 to 1.91:1 range automatically. Needs the user's confirmation. Runs in the background; follow get_publish_status.

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.
alt_textNoAccessibility description (max 1,000 characters).
templateNoTemplate from list_templates: adds header/footer, hashtags, first comment, collaborators.
file_pathNoPath to the file on this computer, e.g. ~/Pictures/launch.jpg.
user_tagsNoPeople to tag in the media.
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).
is_ai_generatedNoSelf-disclose that the content was made or edited with AI (shows an AI label).
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.2/5.0
Behavior4/5

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

Annotations only give the generic write/open-world/non-idempotent profile; the description adds real substance on top: automatic JPEG conversion and aspect-ratio fitting into 4:5 to 1.91:1, the mandatory user confirmation gate, and asynchronous background execution that must be polled with get_publish_status. It stops short of describing failure modes after the confirmation_token call or what a partial publish looks like.

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?

Three sentences, each carrying distinct information: the verb and scope first, the media-transformation guarantee second, the confirmation requirement and async handoff last. No filler and no repetition of schema content.

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 16-parameter mutation with no output schema, the description supplies the two things an agent most needs and the schema cannot convey: the human-approval gate and the asynchronous poll-with-get_publish_status workflow. It leaves the return payload shape unstated, though the wait_seconds and status-tool handoff largely imply it.

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 every one of the 16 parameters is already documented in the schema, including the fit enum, the scheduling window, and the confirmation_token protocol. The description adds only indirect meaning ('Images are converted to JPEG and fitted...' which contextualises fit/prepare) and does not touch caption, tagging, location or collaborator parameters. Baseline 3 applies.

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 scope: 'Publish (or schedule) a single-image feed post.' That phrase cleanly separates this tool from publish_reel, publish_carousel and publish_story without the agent needing to open any schema.

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

Usage Guidelines4/5

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

It states the confirmation prerequisite ('Needs the user's confirmation') and names the follow-up tool get_publish_status, plus the recovery path via reschedule or resume_publish when a scheduled time is missed. It never explicitly says 'use publish_reel for video' or 'use publish_carousel for multiple images', so routing to siblings rests on the self-descriptive names rather than on stated exclusions.

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