Skip to main content
Glama
inssist

@inssist/mcp

Official
by inssist

Draft schedule

draft_schedule

Schedule an existing Instagram draft to publish automatically at a future date and time; Chrome must be running and online. Create or list drafts first to get a draftId.

Instructions

Schedule an existing draft for a date/time; publishes automatically then (Chrome must be running and online). Use draft_create first, or draft_list for a draftId. (Requires INSSIST PRO.)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
atYesPublish time, ISO 8601. No offset = browser local time, e.g. "2026-08-22T18:30". Must be future.
draftIdYesPost id from draft_create or draft_list.
instanceNoOptional. Browser instance id from account_info; defaults to the active one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, which is consistent with a scheduled write. The description adds real value beyond them: it requires Chrome to be running and online at publish time, and requires an INSSIST PRO account. It does not say what happens if a schedule already exists (overwrite vs error), which is a minor gap.

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?

Two tight sentences; the action and its auto-publish consequence are front-loaded, followed by prerequisites and account requirement. No filler.

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?

Covers action, timing, prerequisites, runtime environment and account tier — everything needed to invoke correctly, and there is no output schema to explain. Only the conflict/overwrite behavior for an already-scheduled draft is unstated.

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%, with 'at' fully documented including ISO 8601, local-time default and future-only constraint, and draftId's origin. The description merely restates that draftId comes from draft_create/draft_list, so the schema does the heavy lifting — baseline 3 is 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?

States a specific verb (schedule) and resource (an existing draft) and adds the crucial outcome that it publishes automatically at that time, which separates it from draft_publish's immediate behavior. An agent can distinguish it from its siblings without opening the 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?

Gives clear prerequisite context: use draft_create first, or draft_list to obtain a draftId, and flags the INSSIST PRO requirement. It does not explicitly contrast with draft_publish for the 'publish now' case, but the scheduling semantics make the choice implied.

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