Skip to main content
Glama
Sign In

Ignix

by social.ignix
OverviewDiscussionsAdmin

List posts

list_posts
Read-onlyIdempotent

List posts created in Ignix (drafts, pending approval, scheduled, publishing, published, failed), each with id, status and failure detail, text, scheduledFor, media and target accounts, plus count (all that match). Statuses are refreshed before listing. Returns 40 by default, max 200; narrow with status, from and to. When more match than were returned, nextOffset is the offset for the next page. brief: true returns each post with its text cut to 160 characters and a media count instead of the URLs, to go through many at once. For one post's network options use get_post; for posts published outside Ignix use list_library_posts.

Input Schema

NameRequiredDescriptionDefault
toNoISO 8601: only posts up to this moment. Without a timezone it is the organization's local time.
fromNoISO 8601: only posts from this moment on. Without a timezone it is the organization's local time.
briefNoText cut to 160 characters and `mediaCount` instead of `mediaUrls`.
limitNoMax posts returned (default 40, max 200).
offsetNoSkip this many posts: the `nextOffset` of the previous page.
statusNoFilter by status.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / brief
      Added value: +{
+  "description": "Text cut to 160 characters and `mediaCount` instead of `mediaUrls`.",
+  "type": "boolean"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "description": "Skip this many posts: the `nextOffset` of the previous page.",
+  "type": "number"
+}
  2. Changed3 schema fields changed
    • changedInput schema / properties / from / description
      Previous value: -"ISO date: only posts from this moment on."New value: +"ISO 8601: only posts from this moment on. Without a timezone it is the organization's local time."
    • changedInput schema / properties / limit / description
      Previous value: -"Max rows (default 40)."New value: +"Max posts returned (default 40, max 200)."
    • changedInput schema / properties / to / description
      Previous value: -"ISO date: only posts up to this moment."New value: +"ISO 8601: only posts up to this moment. Without a timezone it is the organization's local time."
  3. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover the safe-read profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description adds real behavior beyond them: statuses are refreshed before listing, the 40/200 result bounds, and how nextOffset maps to offset for paging. It stops short of error/partial-failure behavior, so not 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense paragraph, front-loaded with what is listed and what each item contains before pagination and alternatives. Every sentence carries information, though the packing of return fields, paging and brief mode into one block makes it slightly harder to scan than it could be.

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?

There is no output schema, and the description compensates by naming the returned fields (id, status, failure detail, text, scheduledFor, media, target accounts, count) and the truncation behavior in brief mode. For a six-parameter list tool with annotations handling safety, nothing an agent needs to call it correctly 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 baseline is 3, but the description adds semantic value the schema does not: brief: true truncates text to 160 chars and swaps media URLs for a media count, and nextOffset is described as the offset for the next page. That is genuine meaning beyond the field-level docs.

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 ('List posts created in Ignix') and enumerates the statuses covered, plus what each item carries. It explicitly distinguishes itself from get_post and list_library_posts, so an agent can route without opening 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 Guidelines5/5

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

Gives concrete narrowing levers (status, from, to), names the alternative for a single post's network options (get_post) and for externally published posts (list_library_posts), and says when to use brief: true ('to go through many at once'). When-to-use and when-not-to-use are both present.

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