Skip to main content
Glama

Niche — Editorial Intelligence

by com.nicheangle

List sessions

niche_list_sessions
Read-only

Enumerate the user's recent sessions. Returns id, niche_input, status, outcome, target_platforms, picked story/angle ids, and created/updated_at for each. Use this when the session_id has been lost (across agent invocations, hours of work, etc.) or to find an in-flight session to resume. Returns newest-first.

Judge a terminal run by outcome, not raw status: a failed status is usually a walk-away, not an error. outcome ∈ {complete, expired (a slate was produced but nobody picked; re-open and choose), interrupted (a restart ended it, credits refunded; just re-run), cancelled (stopped on purpose), failed (a real error; see error_message), running}. (status_filter still matches the raw status value.)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax sessions to return (default 25, max 100).
offsetNoSkip this many sessions before returning, for paging through history. Default 0.
brand_idNoOptional filter to sessions tied to one brand profile slot.
status_filterNoOptional status filter, e.g. 'cp1_awaiting_story', 'cp3_awaiting_review', 'complete', 'failed'. Omit for all.
niche_containsNoOptional case-insensitive substring filter on the niche input, to find sessions on a topic (e.g. 'walnut').
include_outputsNoWhen true, also returns `recent_outputs`: the account's produced posts/images/reels across all sessions, newest first, each with its session_id, cell, a reachable asset_url, and publish state. Use it to locate a past asset (e.g. an image made on a prior run). Default false.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety profile is known. The description adds significant nuance: return ordering, the distinction between `outcome` and `status`, and that a `failed` status is usually a walk-away not an error. It also details what `recent_outputs` contains. Goes well beyond annotations.

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?

The description is two tight paragraphs. First states action, return fields, use case, and ordering. Second explains the crucial outcome/status distinction. Every sentence carries information, no filler.

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?

With no output schema, the description compensates by listing exact return fields and the structure of `recent_outputs`. It also explains sorting and outcome semantics. Fully covers the tool's role among many siblings and all relevant aspects.

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 baseline is 3. The description adds semantic value by clarifying that `status_filter` matches raw status not the derived `outcome`, and by explaining the purpose of `include_outputs` for locating past assets. These clarifications are not in the 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?

The description opens with a specific verb+resource: 'Enumerate the user's recent sessions.' It clearly lists the return fields and explicitly states when to use it (when session_id lost or to find an in-flight session), distinguishing it from sibling tools that mutate sessions (e.g., niche_session_cancel).

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 explicitly states 'Use this when the session_id has been lost... or to find an in-flight session to resume' and explains the `include_outputs` use case ('Use it to locate a past asset'). However, it does not mention alternatives or exclusion criteria; sibling tools like niche_session_state are not referenced. Clear context without exclusions/alternatives.

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

All Niche — Editorial Intelligence toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation4/5

Tools are mostly distinct across the pipeline—discovery, brand setup, drafting, rendering, publishing, session management—and descriptions are detailed. Minor overlap exists between niche_signal_scan and niche_intelligence_query (both discovery) and between niche_add_output and niche_draft_create (both generate outputs), but the descriptions clearly differentiate them. Overall, an agent can reliably select the right tool.

Naming Consistency3/5

All tools share the `niche_` prefix and snake_case, but the verb/noun order is inconsistent: some are verb-first (add_output, render_image_card, list_sessions) while many are noun-first (angle_propose, brand_kit_ingest, draft_create, session_cancel). This mixed convention requires the agent to learn each name individually rather than predict the pattern.

Tool Count3/5

25 tools is on the heavy side but appropriate for the platform's scope—full editorial intelligence from discovery to publish. No redundant tools, and each covers a distinct aspect, but the count is high enough that it feels dense and may require orientation (which niche_whoami addresses).

Completeness4/5

The toolset covers the full workflow: discovery, angle proposal, drafting, revision, publishing, rendering, asset attachment, brand setup, and session management. Minor gaps exist, such as no direct read tool for the current BrandKit (only via ingest status) and no hard-delete tool (session_cancel mentions the REST endpoint instead), but these are edge cases and agents can work around them.

Resources