autario-mcp

social_publish

Publish the caller's OWN social drafts on the caller's OWN channels through the official APIs (spec 2026-11-09-own-channel-publish): the X account connected to this autario account (POST /2/tweets) and the LinkedIn company page of the connected LinkedIn login (POST /rest/posts with the organization id of the LinkedIn connector). The drafts are the rows of the account's private dataset social_drafts (columns drafted_at, channel x|linkedin, topic, draft, data_source, link, status, posted_at, plus post_url and error once published), which the daily social routine writes with status draft. Four actions: targets lists the channels (connection, can_publish, and the reason plus a connect URL when it cannot post yet: not connected, the login did not grant tweet.write / w_organization_social, no organization id on the LinkedIn connector); drafts returns the rows; approve {draft_id} flips ONE row from draft (or failed, skipped) to approved after checking the channel and the text length (X 280 weighted characters with every URL counting 23, LinkedIn 3000); run publishes every approved row now, one per channel, exactly once (the row is set to posting before the request and never taken twice), writes status posted + posted_at + post_url and one row into the account's social_posts dataset (day, channel, url, title, kind, views) that the funnel widget reads, or status failed + error with the vendor's own sentence and a bell notification. The worker runs the same run on the refresh cycle, so approving is enough; run is for "post it now". A row with status draft is NEVER published: only a person, or this tool on their behalf, approves. Own channels only: nothing here posts to Reddit, Hacker News, a forum or anybody else's thread, and nothing comments. Requires the caller's own autario account (OAuth); every row and connection is the caller's. Use when asked "post today's draft", "approve the LinkedIn draft", "which channels can autario post to", "publish the approved posts now".

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "social_publish"
  }
}

Input Schema

Name	Required	Description
`action`	Yes	targets = the channels this account can post to; drafts = the social_drafts rows; approve = set one draft to approved (needs draft_id); run = publish every approved draft now, one per channel.
`format`	No	Output wire format for this MCP call. Default 'toon' (Token-Oriented Notation, fewest tokens, best for tabular rows). 'compact' = minified JSON. 'json' = pretty JSON for readability. The REST API always returns JSON regardless.
`draft_id`	No	approve only: the row id (dd_id) from drafts.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), it discloses the state machine (draft/approved/posting/posted/failed), exactly-once semantics via a pre-request 'posting' mark, the text-length validation rules (X 280 weighted chars with URLs counting 23, LinkedIn 3000), failure handling with vendor error text plus a bell notification, and the side effect of writing rows into `social_posts`. That is a lot of context the annotations cannot convey; the only gap is that it never states whether a publish can be undone or deleted, which matters for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

It is front-loaded with purpose and endpoints, but the whole definition is one dense unbroken paragraph of long sentences, including a full column list for `social_drafts` that an agent does not need in order to choose an action. Information is valuable but the structure (no separation of actions, side effects, and constraints) makes it harder to scan than it needs to 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?

For a four-action mutation tool with no output schema, the description covers what each action returns (targets: connection, can_publish, reason, connect URL; drafts: the rows), the approval gate, the publish path, the downstream dataset write, and the failure surface. Nothing an agent must know to call it safely or 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?

With 100% schema description coverage the baseline is 3, but the description earns more: it defines what each action does to real rows (`approve` flips exactly ONE row and only from draft/failed/skipped, after checking channel and text length; `drafts` returns the social_drafts rows), and clarifies that draft_id is the 'dd_id' taken from `drafts`. The `format` parameter's wire-format tradeoffs are left entirely to the schema, which is acceptable.

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 names a specific verb and resource (publish social drafts to the caller's own X account and LinkedIn company page via named official endpoints) and enumerates the four actions with their exact effects. Scope limits ('own channels only, nothing to Reddit, Hacker News, a forum or anybody else's thread, and nothing comments') clearly separate it from generic publishing siblings like publish_app or publish_chart.

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?

It states explicitly when to use `run` versus relying on the worker ('The worker runs the same run on the refresh cycle, so approving is enough; run is for "post it now"'), and closes with concrete trigger phrasings ('post today's draft', 'approve the LinkedIn draft'). It also spells out the prerequisite gate (OAuth account, granted tweet.write / w_organization_social, organization id) that must be satisfied before calling.

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

All autario-mcp 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.