Postlyra

Create a Postlyra post draft

create_post_draft

Use this when creating a beautifully structured Telegram post. First read get_formatting_capabilities. Prefer finished richDocument; it overrides text/preset/template. Import images via mediaFile1..mediaFile6 or mediaFiles; bind slots as media.src. Returns draftId, native JPEG and display instructions. Include the image in the FINAL answer via native attachment or display.imageMarkdown, then the preview link; a tool-only image is insufficient. Inspect preview_post. Never publishes.

Input Schema

TableJSON Schema

Name	Required	Description
`text`	No	Optional user-approved draft text supplied by ChatGPT.
`style`	No	Natural style request from the user, for example beautiful, premium, business, blog, presentation, informal, real-estate, launch, or landing-page-like. Use this as guidance, not literal post copy.
`topic`	Yes
`language`	No
`channelId`	No	Optional owner-bound Postlyra channel id or exact title returned by list_channels.
`structure`	No	Desired content structure in natural language. Mention available facts such as gallery, CTA, comparison, details, map, report, changelog, or before/after.
`mediaFile1`	No	Actual attached or generated image file, up to 10 MiB: JPEG, PNG, GIF or WebP. Pass the file through the client upload mechanism; the server receives download_url and file_id. mime_type and file_name may be omitted. In the same richDocument call, use this slot name as media.src for exact placement.
`mediaFile2`	No	Actual attached or generated image file, up to 10 MiB: JPEG, PNG, GIF or WebP. Pass the file through the client upload mechanism; the server receives download_url and file_id. mime_type and file_name may be omitted. In the same richDocument call, use this slot name as media.src for exact placement.
`mediaFile3`	No	Actual attached or generated image file, up to 10 MiB: JPEG, PNG, GIF or WebP. Pass the file through the client upload mechanism; the server receives download_url and file_id. mime_type and file_name may be omitted. In the same richDocument call, use this slot name as media.src for exact placement.
`mediaFile4`	No	Actual attached or generated image file, up to 10 MiB: JPEG, PNG, GIF or WebP. Pass the file through the client upload mechanism; the server receives download_url and file_id. mime_type and file_name may be omitted. In the same richDocument call, use this slot name as media.src for exact placement.
`mediaFile5`	No	Actual attached or generated image file, up to 10 MiB: JPEG, PNG, GIF or WebP. Pass the file through the client upload mechanism; the server receives download_url and file_id. mime_type and file_name may be omitted. In the same richDocument call, use this slot name as media.src for exact placement.
`mediaFile6`	No	Actual attached or generated image file, up to 10 MiB: JPEG, PNG, GIF or WebP. Pass the file through the client upload mechanism; the server receives download_url and file_id. mime_type and file_name may be omitted. In the same richDocument call, use this slot name as media.src for exact placement.
`mediaFiles`	No	Alternative file array for clients supporting file arrays. Prefer mediaFile1..mediaFile6 otherwise. At most 6 files total across slots and array; use mediaFiles[0] etc. as richDocument src bindings.
`references`	No
`templateId`	No
`formatPreset`	No	Optional Postlyra formatting preset/layout recipe. Leave unset when the user did not name one; Postlyra will infer a recipe from topic, style, structure, and references.
`richDocument`	No	Preferred finished layout: {version:1, blocks:[...]}. Overrides text, template and preset. Call get_formatting_capabilities for exact block/inline schemas and examples. For uploaded images use media.src="mediaFile1" etc. with the corresponding file in this call.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	No
`text`	No
`title`	No
`locale`	No
`status`	No
`display`	No
`draftId`	Yes
`message`	Yes
`richHtml`	No
`updatedAt`	No
`previewUrl`	Yes
`screenshot`	No
`documentJson`	No
`inlineButtons`	No
`screenshotUrl`	No	JPEG screenshot of the saved Telegram preview; null if rendering is temporarily unavailable.

Schema Changelog

Changes observed during successful MCP inspections.

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 declare non-readOnly, non-idempotent, non-destructive. The description adds meaningful context beyond annotations: 'Never publishes' clarifies the boundary between drafting and publish_post/schedule_post, and it discloses the richDocument precedence rule and the required final-answer image handling. It doesn't mention rate limits or auth needs, but the safety-critical boundary is covered.

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?

Dense and front-loaded, but it packs workflow instructions, output handling, and image-answer rules into one run-on description. Every sentence is relevant but the overload of procedural guidance makes it harder to scan; some content could be trimmed or split.

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?

Given 17 params, nested objects, an output schema, and the complex richDocument workflow, the description covers the key procedural requirements: prerequisite tool, precedence rules, media binding, final-answer image inclusion, and the no-publish boundary. It is complete for a tool of this complexity.

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 coverage is 76%, so the schema carries most parameter meaning. The description adds a few useful rules (media.src binding via mediaFile slots, richDocument overrides text/preset/template), but most param detail is already in the schema. Baseline 3 is appropriate.

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?

States a specific verb+resource (create post draft) and frames it as building a Telegram post. It differentiates itself from update_post_draft/attach_media_to_draft by describing the drafting task, though it doesn't explicitly name siblings. The core intent is clear.

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?

Gives concrete sequencing: read get_formatting_capabilities first, prefer richDocument over text/preset/template, inspect preview_post. It names the prerequisite and a related tool but stops short of explicit when-not-to-use guidance or naming alternatives like search_post_drafts.

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

All Postlyra tools Inspect

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.