Adeli

Publish to several accounts

create_publication

Publish one post to several connected accounts at once. This posts publicly unless a platform's privacy setting says otherwise, so confirm the content and accounts with the user first. publication has shared content and media (staged {upload_id} or {url} items), and platforms: one entry per account with platform, accountId, and optional kind, content, media, and options. options are that platform's create_post fields other than text and media (for example TikTok music_usage_confirmed and privacy_level, YouTube privacy_status and made_for_kids); a target's content and media replace the shared ones. Every target is validated as create_post would validate it, then the publication is accepted and runs in the background. Poll get_publication until status is published, partial, or failed. Pass idempotencyKey to make a retry of this call safe.

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": {
      "publication": "<publication>"
    },
    "name": "create_publication"
  }
}

Input Schema

Name	Required	Description	Default
`publication`	Yes
`idempotencyKey`	No	Any unique string; repeating it with the same publication returns the original instead of posting again.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 3, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations only say this is a non-read-only, open-world, non-destructive write. The description goes well beyond: default public visibility overridable by platform privacy settings, validation performed the same way create_post validates, asynchronous acceptance with background execution, the three terminal statuses to poll for, and how idempotencyKey makes retries safe. That is exactly the behavioral context an agent needs before firing a multi-account public post.

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-loaded with purpose, then constraints, then payload structure, then lifecycle, then retry safety. It is a dense single paragraph with semicolon-chained clauses, but every clause carries operational meaning; nothing is redundant with the annotations or the schema.

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?

For a complex nested, asynchronous, open-world mutation with no output schema, the description covers the lifecycle, validation behavior, visibility default, and retry semantics. The remaining omission is profileId semantics and the account/platform coverage limits (schema-enforced), which are minor but leave a small inference burden.

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 50% schema description coverage and a fully undocumented nested publication object, the description does most of the work: shared content and media as staged {upload_id} or {url} items, one platforms entry per account, the per-target override rule, and that options are that platform's create_post fields minus text and media (with TikTok and YouTube examples). The gap is profileId, which is neither described in the schema nor mentioned in the description, so its meaning is left to inference.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb and resource with scope: publish one post to several connected accounts at once. That scope implicitly separates it from the single-target create_post sibling, though it never names that sibling or get_publication's read role explicitly. An agent can tell what it does without opening the schema.

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 gives a real prerequisite (confirm content and accounts with the user because posting is public by default) and a clear post-call procedure (poll get_publication until status is published, partial, or failed). It stops short of explicit when-not guidance, e.g. 'use create_post for a single account' or 'use retry_publication instead of re-calling this'.

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

All Adeli 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.

Resources

Need Help?