Postlyra.app — Telegram posts from AI chats

Attach uploaded media to a post

attach_media

Use when adding a finalized owner mediaId to a working post. Read the post revision first. Images, videos, audio and voice become media blocks; documents become file blocks. Does not publish or change existing delivery snapshots.

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>",
      "mediaId": "<mediaId>",
      "expectedRevision": "<expectedRevision>"
    },
    "name": "attach_media"
  }
}

Input Schema

Name	Required	Description
`postId`	Yes	Owner-bound postId from search_posts/search_post_drafts/create_post_draft.
`mediaId`	Yes	Owner-bound mediaId returned by finalize_media_upload.
`expectedRevision`	Yes	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.

Changed3 schema fields changedOct 29, 2026

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 / mediaId / description

Added value: +"Owner-bound mediaId returned by finalize_media_upload."

addedInput schema / properties / postId / description

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

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 mutating-but-non-destructive and non-idempotent; the description adds real value beyond that by stating the type-to-block mapping and that delivery snapshots are untouched. It still leaves the required precondition implicit (mediaId must be finalized — stated, but nothing on failure modes or revision-conflict behavior beyond the schema).

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?

Four short sentences, front-loaded with the usage trigger, and each adds a distinct fact (trigger, precondition, block mapping, exclusion). The revision instruction mildly duplicates the expectedRevision schema description.

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?

With an output schema present, annotations covering the safety profile, and full parameter coverage, the description only needs to carry intent and side effects — which it does. The remaining gap is disambiguation from attach_media_to_draft, a sibling that could easily be chosen by mistake.

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 100%, so all three parameters are documented with usage hints in the schema itself. The description only echoes "finalized owner mediaId" and the revision-read requirement, adding no syntax or format detail beyond the structured fields.

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: attaching a finalized owner mediaId to a working post, plus the concrete effect per media type (media blocks vs file blocks). It does not distinguish itself from the near-twin sibling attach_media_to_draft, which is the one ambiguity an agent must resolve.

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 adding a finalized owner mediaId to a working post" gives an explicit trigger condition, and "Read the post revision first" plus "Does not publish or change existing delivery snapshots" set boundaries. No guidance is offered on when attach_media_to_draft would be the correct alternative instead.

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.