Skip to main content
Glama
Sign In

Ignix

by social.ignix
OverviewDiscussionsAdmin

Create a recurring Autopilot plan

create_autopilot_plan

Save an Autopilot setup (accounts, ideas per run, period, format, brief) that runs on its own daily, weekly or monthly at 7:00 in the organization's time zone and leaves the content as DRAFTS (the user gets an email each time; nothing is published). EVERY RUN SPENDS AI CREDITS, like run_autopilot: 25 for the plan + 35 per piece PER ACCOUNT + 20 per image (40 with the speaker's photos). Tell the user the estimated credits per run and per month and get a clear yes before passing confirm: true; without confirm the plan is saved PAUSED. The first run is one cycle after it is created.

Input Schema

NameRequiredDescriptionDefault
nameNoOptional name, e.g. "Weekly tips".
whenNoWhat each run plans for, counted from the day it runs: today, tomorrow, this_week, next_week, this_month or next_month. Default this_week.
countNoHow many ideas (1-20). Each one becomes a piece per account. For a week, 3-5 is typical.
topicNoOptional brief: a launch, a theme, a date. Leave it out to let the plan come from what is working in the brand’s niche and on its own account — usually the better choice.
formatNoForce a format, or "auto" (default) to let each run choose per piece. Same values as run_autopilot.
repeatNoHow often it runs. Default weekly.
confirmNotrue ONLY after the user agreed to the estimated credits per run. Needed to create the plan active, to activate it, and to change a plan that is active.
accountIdsYesAccount ids from list_accounts (the ones to plan for).
keywordCtaNoAllow a "comment WORD" call to action with its comment-to-DM automation. Default false.
withImagesNoGenerate images (default true). Images are the biggest part of the cost.
workspaceIdNoDefaults to the workspace this connection is scoped to.
idempotencyKeyNoOptional. A unique id for this action (16-128 chars: letters, digits, _ : . -). If you are unsure whether a call went through (timeout, network error), repeat it with the SAME idempotencyKey and the same arguments: you get the original result and nothing is done twice.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond annotations, it discloses that runs leave content as DRAFTS, send an email, never publish, and consume AI credits at specific rates. It also explains that confirm: true is needed to create the plan active and that without it the plan is saved PAUSED, plus when the first run occurs.

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 front-loaded with the tool's purpose and key constraints, and every sentence carries useful information about credits, drafts, confirm, and first-run timing. It is dense with caps and parentheticals, making it less scannable than it could be, but not padded.

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 complex 12-parameter creation tool with no output schema, the description covers the essential behavior: schedule, draft output, email notification, credit costs, confirm gating, paused default, and first-run timing. No important agent-facing call context 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 100%, so the schema already documents all parameters; baseline would be 3. The description adds behavioral meaning to confirm (paused without it, activation requirement) and withImages (biggest cost driver), plus notes accountIds come from list_accounts, which goes beyond the schema text.

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: saving a recurring Autopilot setup that runs daily, weekly, or monthly. It distinguishes this from run_autopilot by emphasizing recurring scheduling and draft-only output, so an agent can tell it apart from sibling autopilot tools.

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 gives clear context for use: create a plan that runs on its own, get user agreement on credits before passing confirm: true, and otherwise the plan is saved paused. It does not explicitly name alternatives like run_autopilot or activate_autopilot_plan, but the condition for active versus paused creation is well specified.

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

All Ignix toolsInspect
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