Skip to main content
Glama

Niche — Editorial Intelligence

by com.nicheangle

Publish a draft

niche_draft_publish
Destructive

Publish a single output to its platform. Defaults to dry_run=true: returns the would-publish payload plus any verifier blocks without actually filing. Set dry_run=false and provide an idempotency_key to commit. The commit is the only irreversible action in the workflow; the agent should present the dry-run preview to the human and only commit on explicit go-ahead. For any piece with a rendered image, reel, or card, show the human the actual pixels (the preview_url / image_url) first: never let publish be the first time a human sees the final visual. Verifier-blocked outputs refuse to publish even with dry_run=false; clear the block on the row first. When the target social isn't linked, returns status='not_connected' plus a connect_url instead of publishing; send the user to connect once, then retry.

Scheduling: pass scheduled_for (an ISO-8601 datetime in the future) to file the post for later instead of publishing now; it dispatches automatically through the same publish path. Pass cancel_scheduled=true to clear a pending schedule for this platform.

Prefer an exact cell string (e.g. 'x:thread', 'x:single_tweet') over a bare family name. A bare family that matches more than one draft on the session returns status='ambiguous_platform' with the candidate cells rather than guessing. Every publish and dry-run response echoes resolved_cell so you can confirm which artifact shipped.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dry_runNo
platformYesAccepts either: • cell string: the platform×content_type the run produced (linkedin:text_post, linkedin:image_post, linkedin:carousel, x:single_tweet, x:thread, x:image_post, instagram:image_post, instagram:carousel), preferred for new code • family name: linkedin, linkedin_carousel, twitter, instagram, which coerces to the registered default cell for that family (e.g. linkedin maps to linkedin:text_post) Reels (linkedin:reel / x:reel / instagram:reel) and long_form_article have no in-app publish path: reels get a download URL, long-form ships as Markdown for paste-to-Substack.
session_idYes
scheduled_forNoISO-8601 datetime to publish this output later (must be in the future). Files a pending scheduled post and returns status='scheduled' instead of publishing now. Requires the platform's social account connected; long-form has no scheduled path.
idempotency_keyNoRequired when dry_run=false. Same key returns the prior result without re-publishing.
cancel_scheduledNoClear a pending scheduled post for this platform on this run. Idempotent: returns a clean message when nothing is scheduled.
acknowledge_surfacedNoRequired true to commit when the dry-run surfaced claims/flags worth a human look (the dry-run's next_step names them). Affirms the agent showed the human the surfaced items and got go-ahead. Ignored when nothing was surfaced. Default false.
acknowledge_publish_costNoRequired true to commit an X post that carries a link (X charges per link-post, so the dry-run returns a `publish_cost` in credits). Affirms the agent showed the human the cost and got go-ahead. Ignored when the publish is free (plain X / LinkedIn / Instagram). Default false.

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already indicate destructiveHint and readOnlyHint=false, but the description goes far beyond by explaining that commit is irreversible, defaults to dry_run=true, requires idempotency_key for commit, verifier blocks prevent publishing, and not_connected returns a connect_url. Also covers scheduling and cancellation behavior. No contradiction with annotations.

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 fairly long but well-structured with paragraphs separating safety, scheduling, and platform selection. Every sentence contributes critical operational detail, though a slightly tighter edit could improve scannability. It is not wastefully verbose.

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?

Without an output schema, the description compensates by explaining response states (status='not_connected', 'ambiguous_platform', 'scheduled', resolved_cell, publish_cost, next_step). It covers edge cases, scheduling, dry-run behavior, and human-in-the-loop requirements, making it nearly complete for a complex publish tool.

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 covers 75% of parameters with descriptions. The tool description adds valuable context beyond the schema, such as preferring exact cell strings over family names, the meaning of status='ambiguous_platform', and the idempotency guarantee. This enriches understanding but some parameters like session_id are minimally described.

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 'Publish a single output to its platform,' a clear verb+resource statement. It immediately distinguishes itself from sibling draft/rendering tools by focusing on the publish action and its dry-run/commit flow.

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?

Provides clear context on when to use the tool (final publish step) and when to use dry-run vs commit. Does not explicitly name alternative sibling tools for other scenarios, but the guidance around previews and explicit human go-ahead is strong. Lacks explicit 'rather than using X' statements.

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