Ignix

Plan a post or carousel

plan_content

Plan a piece of content end to end: caption plus, for each slide, its idea and a detailed art-directed image prompt with a shared visual style. Written in this brand's voice — as the company, or as the person or character it speaks as. This is the right first step for a carousel: plan it, then feed each imagePrompt to generate_image, then create_post with the caption and the resulting URLs. Costs 35 AI credits per plan (the images are charged separately by generate_image); nothing is charged if it fails. For a week or a month of content use plan_campaign (to go through the plan with the user) or run_autopilot (to create it all as drafts). SPENDS AI CREDITS ONLY WITH confirm: true. Call it first without confirm: nothing runs and nothing is charged, you get the quote (what it will do and the credits). Tell the user, in your own words, exactly that — including the options you chose, so they can change them — and wait for a clear yes before calling again with the same arguments and confirm: true. One yes covers the plan they approved (e.g. every line of an approved voice-over with the chosen voice); anything new or different needs a new yes.

Input Schema

Name	Required	Description
`type`	No	Content format. Defaults to post.
`topic`	No	Brief or topic.
`confirm`	No	true ONLY after the user said yes to the quote (what it does and the credits). Without it nothing runs and nothing is charged.
`language`	No
`platform`	Yes	Target network.
`keywordCta`	No	Let the plan close with a keyword CTA ("comment WORD and I'll send it"). It may only offer something the brand actually has on file — see `deliverables` in get_brand_profile. With nothing on file, no CTA is produced. Off by default.
`slideCount`	No	Number of images to plan (1 for a single post, 3-5 for a carousel).
`workspaceId`	No	Workspace to work on (an id from list_workspaces). Not needed when this connection is tied to one workspace, or when you pass an account: the account's workspace is used.
`idempotencyKey`	No	Optional. 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.

First observedOct 17, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations are minimal (readOnlyHint=false, openWorldHint=true), so the description carries heavy weight, and it mostly delivers: cost of 35 credits, no charge on failure, images billed separately, and the confirm-then-quote two-call protocol. However, it doesn't state what a failed plan returns or rate/credit-limit behavior. It's rich but not exhaustive given zero output schema.

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?

Front-loaded with the value prop, then workflow, then cost/confirm protocol in a logical order. Slightly redundant: 'SPENDS AI CREDITS ONLY WITH confirm: true' is restated twice and partly echoes the schema's confirm description. The confirm paragraph is somewhat dense but each part is actionable.

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 9-param mutating tool with no output schema, the description covers workflow position, output shape (caption, slide ideas, imagePrompt), cost, failure behavior, and the approval protocol. That's the full picture an agent needs to invoke correctly.

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 89% (high baseline 3), so most params are already documented. The description adds genuine meaning to `confirm` by detailing the quote-then-approve loop and to `keywordCta` indirectly through deliverables/CTA semantics. It doesn't touch `platform`, `type`, `slideCount`, or `idempotencyKey` beyond schema.

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?

Opens with a specific verb and full scope: 'Plan a piece of content end to end: caption plus, for each slide, its idea and a detailed art-directed image prompt.' The output shape (caption + per-slide idea + imagePrompt) immediately distinguishes it from create_post, generate_image, and plan_campaign.

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 ordering: 'plan it, then feed each imagePrompt to generate_image, then create_post' positions it as the first step in a pipeline. It also names alternatives with conditions — plan_campaign for a week/month, run_autopilot to create as drafts — leaving nothing to inference.

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

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