Skip to main content
Glama
Sign In

Ignix

by social.ignix
OverviewDiscussionsAdmin

Validate a post before publishing

validate_post
Read-onlyIdempotent

Dry run: check copy and media against every target network (character limits, media requirements, mandatory options) WITHOUT creating anything. Use it before create_post when the copy is long or several networks are involved. For YouTube it also returns advice on the title and thumbnail as one pairing (where the title gets cut on desktop and phone, capitals, empty adjectives, a thumbnail that repeats the title): advice, not blockers — fix what applies and tell the user the rest.

Input Schema

NameRequiredDescriptionDefault
altTextNoAccessibility alt text per image, keyed by its URL in mediaUrls: {"https://…/a.jpg":"A dog on a red sofa"}. Applied on Instagram feed, Facebook, Threads, X (max 1000), LinkedIn, Bluesky and Pinterest (max 500); ignored elsewhere. Write it for every image you attach — a post without alt text is unreadable to screen readers, and several networks rank it.
contentYes
mediaUrlsNoPublic https URLs of images/videos to attach. THE ORDER MATTERS: it is the carousel order the reader swipes through, and the first one is the cover — the image that shows in the profile grid. Get them from generate_image, generate_video (via get_media_job), upload_media (for a file on the user's machine), import_media (for a url that is already public) or list_library_media.
accountIdsYesIgnix account ids from list_accounts.
thumbnailTextNoYouTube: the words written on the thumbnail, if any, so they are checked against the title.
networkOptionsNoNetwork-specific options keyed by platform: first comment, collaborators, cover image, privacy, board, flair, TikTok consent… e.g. {"instagram":{"firstComment":"…","collaborators":"user1,user2"},"youtube":{"visibility":"public"},"pinterest":{"boardId":"…"}}. Call get_network_options for the EXACT list each network accepts, with types, accepted values and which ones are required.
perNetworkTextNoDifferent copy per network, keyed by platform, e.g. {"x":"short version","linkedin":"long version"}. Networks not listed use the main content.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds that it creates nothing, enumerates what is checked, and discloses the YouTube `advice` return semantics (advisory, not blockers, and how to act on it). It does not describe the general return shape for non-YouTube networks, which keeps it short of a 5.

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?

Front-loads the core idea ('Dry run ... WITHOUT creating anything') in the first sentence, then usage, then the YouTube-specific nuance. Three dense but non-redundant sentences, 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?

With no output schema, the description carries the return-value burden and does so for YouTube only, leaving the general result format (warnings vs errors vs pass/fail across networks) unspecified. For a 7-parameter validator with nested objects, one more sentence on the general return shape would complete it.

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 86%, so the baseline is 3; the description still adds meaning by linking copy, media and networkOptions to the validation checks, and by explaining that thumbnailText is checked as a pairing against the title for YouTube. That is genuine semantic value 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?

States a specific verb and resource ('Dry run: check copy and media against every target network') with explicit scope (character limits, media requirements, mandatory options) and the crucial qualifier 'WITHOUT creating anything'. It is immediately distinguishable from create_post and the other publish-path siblings.

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?

Names the alternative explicitly ('Use it before create_post') and the conditions that select it ('when the copy is long or several networks are involved'). This is exactly the when-to-use guidance an agent needs to choose between validating and publishing.

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