Postlyra.app — Telegram posts from AI chats

Schedule a Telegram publication

schedule_post

DestructiveIdempotent

Use when the author explicitly asks to schedule a post to a connected channel or group. Supply an exact ISO date with UTC offset and an idempotency key. The server uses the shared publishing rules and stores an immutable delivery snapshot.

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": {
      "postId": "<postId>",
      "channelId": "<channelId>",
      "scheduledAt": "<scheduledAt>",
      "idempotencyKey": "<idempotencyKey>"
    },
    "name": "schedule_post"
  }
}

Input Schema

Name	Required	Description
`postId`	Yes	Owner-bound postId from search_posts/search_post_drafts/create_post_draft.
`timezone`	No	IANA time zone, e.g. Asia/Bangkok; the scheduledAt UTC offset specifies the exact instant.
`channelId`	Yes	Owner-bound channel id from list_channels; never invent a recipient.
`scheduledAt`	Yes	Exact publication time as ISO 8601 with UTC offset, e.g. 2026-10-29T10:00:00+07:00. Resolve the user time zone before scheduling.
`idempotencyKey`	Yes	Stable 8-128 character key using letters, digits, dot, underscore, colon or hyphen. Reuse with identical arguments for the same intended schedule after a lost response.
`pinAfterPublish`	No	Pin this bot-delivered publication after successful delivery when the user requests it; notify group members (Telegram disables pin notifications in channels). Pin failures are reported separately and never resend the post. Does not apply to native/inline sharing.
`expectedRevision`	No	Current revision from get_post/last mutation. On conflict reread and compare changes; never bypass revision.

Output Schema

Name	Required	Description	Default
`data`	Yes
`message`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 6, 2026

changedInput schema / properties / pinAfterPublish / description

Previous value: -"Pin this bot-delivered publication after successful delivery when the user requests it. Pin failures are reported separately and never resend the post. Does not apply to native/inline sharing."New value: +"Pin this bot-delivered publication after successful delivery when the user requests it; notify group members (Telegram disables pin notifications in channels). Pin failures are reported separately and never resend the post. Does not apply to native/inline sharing."

Changed1 schema field changedOct 30, 2026

addedInput schema / properties / pinAfterPublish

Added value: +{
+  "default": false,
+  "description": "Pin this bot-delivered publication after successful delivery when the user requests it. Pin failures are reported separately and never resend the post. Does not apply to native/inline sharing.",
+  "type": "boolean"
+}

Changed6 schema fields changedOct 29, 2026

addedInput schema / properties / channelId / description

Added value: +"Owner-bound channel id from list_channels; never invent a recipient."

addedInput schema / properties / expectedRevision / description

Added value: +"Current revision from get_post/last mutation. On conflict reread and compare changes; never bypass revision."

addedInput schema / properties / idempotencyKey / description

Added value: +"Stable 8-128 character key using letters, digits, dot, underscore, colon or hyphen. Reuse with identical arguments for the same intended schedule after a lost response."

addedInput schema / properties / postId / description

Added value: +"Owner-bound postId from search_posts/search_post_drafts/create_post_draft."

addedInput schema / properties / scheduledAt / description

Added value: +"Exact publication time as ISO 8601 with UTC offset, e.g. 2026-10-29T10:00:00+07:00. Resolve the user time zone before scheduling."

changedInput schema / properties / timezone / description

Previous value: -"IANA zone, for example Asia/Bangkok; publication times are stored in UTC."New value: +"IANA time zone, e.g. Asia/Bangkok; the scheduledAt UTC offset specifies the exact instant."

First observedSep 11, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds genuinely new context: the server applies shared publishing rules, stores an immutable delivery snapshot, and an idempotency key should be reused after a lost response. It does not explain why the operation is flagged destructive or what can be overwritten, which keeps it below 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?

Three short sentences, front-loaded with the trigger condition, with no filler. It could be marginally tighter by leading with the operation itself rather than the usage clause, but nothing is wasted.

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?

An output schema exists, so return values need no explanation, and 7 parameters are fully described in the schema. The description supplies the scheduling-specific caveats (exact instant, idempotent retry, immutable snapshot) that an agent needs to call it correctly; only the destructive-hint implications are left unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter including idempotencyKey and scheduledAt is already documented in detail. The description restates the ISO-with-UTC-offset requirement and idempotency key but adds no format or constraint detail beyond the schema, so the baseline of 3 applies.

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 description states a specific verb and resource ("schedule a post to a connected channel or group") and the title reinforces it, so the agent knows exactly what operation occurs. It does not explicitly distinguish itself from nearby siblings such as publish_post, reschedule_publication, or create_post_draft, so it falls short of a 5.

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?

"Use when the author explicitly asks to schedule" gives a clear, actionable trigger condition rather than leaving usage implied. It stops short of naming alternatives or stating when not to use it (e.g. immediate delivery via publish_post, or changing an existing schedule via reschedule_publication).

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

All Postlyra.app — Telegram posts from AI chats 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.