Postlyra.app — Telegram posts from AI chats

Create an auto-signature

create_signature

Use this when managing post auto-signatures. Create a reusable auto-signature with the post editor's full RichDocument and optional buttons/media. Assign it with assign_signature. Never publishes.

Input Schema

TableJSON Schema

Name	Required	Description
`title`	Yes
`language`	No
`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
`richDocument`	Yes	Complete reusable RichDocument. Use get_formatting_capabilities and the same media slot bindings as post drafts.
`inlineButtons`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`text`	No
`title`	No
`locale`	No
`display`	No
`message`	Yes
`richHtml`	No
`signature`	Yes
`updatedAt`	No
`previewUrl`	No
`screenshot`	No
`signatureId`	Yes
`documentJson`	No
`inlineButtons`	No
`screenshotUrl`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedOct 13, 2026

removedOutput schema / properties / channelId

Removed value: -{
-  "maxLength": 128,
-  "type": [
-    "string",
-    "null"
-  ]
-}

removedOutput schema / properties / deliveryDocumentJson

Removed value: -{
-  "description": "Composed publication including the selected auto-signature. Edit documentJson, never copy this composition into the post body.",
-  "type": "object"
-}

removedOutput schema / properties / deliveryInlineButtons

Removed value: -{
-  "items": {
-    "anyOf": [
-      {
-        "type": "object"
-      },
-      {
-        "items": {
-          "type": "object"
-        },
-        "type": "array"
-      }
-    ]
-  },
-  "type": "array"
-}

removedOutput schema / properties / draftId

Removed value: -{
-  "maxLength": 128,
-  "minLength": 1,
-  "type": "string"
-}

removedOutput schema / properties / id

Removed value: -{
-  "maxLength": 128,
-  "minLength": 1,
-  "type": "string"
-}

removedOutput schema / properties / signatureSelection

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "mode": {
-      "enum": [
-        "inherit",
-        "none",
-        "custom"
-      ],
-      "type": "string"
-    },
-    "signatureId": {
-      "maxLength": 128,
-      "type": [
-        "string",
-        "null"
-      ]
-    }
-  },
-  "required": [
-    "mode"
-  ],
-  "type": "object"
-}

removedOutput schema / properties / signatureSnapshot

Removed value: -{
-  "type": [
-    "object",
-    "null"
-  ]
-}

removedOutput schema / properties / status

Removed value: -{
-  "maxLength": 64,
-  "type": "string"
-}

AddedOct 9, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly=false, destructive=false and non-idempotent, so the safety profile is covered. The description adds genuinely non-obvious behavior: 'Never publishes', which tells the agent this write is inert with respect to live posts. It omits auth/permission requirements and any storage-quota limits, so it is not exhaustive.

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, all front-loaded with the action before the follow-up pointer. The trailing 'Never publishes' is a slight orphan fragment, but nothing is wasted and there is no filler.

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 not be described, and annotations cover the mutation profile. For an 11-parameter nested-object creation tool the description supplies the workflow (create then assign_signature) and the inertness guarantee; only the media-slot mechanics and permission prerequisites are left entirely to the schema.

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 64% and the schema itself carries the heavy detail (media slot names, mime types, size limits, mediaFile1-6 vs a mediaFiles array capped at 6). The description adds no syntax or constraints beyond naming 'RichDocument and optional buttons/media', which mirrors the schema rather than extending it.

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: 'Create a reusable auto-signature with the post editor's full RichDocument and optional buttons/media.' This distinguishes it from read/update/delete signature siblings and from post-draft tools. It does not explicitly differentiate from convert_draft_to_signature, which is the nearest ambiguous sibling, so it stops 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?

It gives clear context ('Use this when managing post auto-signatures') and routes the agent to the follow-up step ('Assign it with assign_signature'). It never states a when-not condition, e.g. use convert_draft_to_signature when you already have a draft, which would be required for a 5.

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.