Agent Outbox for Telegram

Send to Telegram

send_to_telegram

Sends text to one of the user's Telegram destinations (private chat, group, channel or group topic) by name, or to the user's default destination when destination is omitted. Markdown is converted to Telegram formatting and long text is split into up to 10 messages. Each successful call counts as one message toward the user's plan limit.

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": {
      "text": "<text>"
    },
    "name": "send_to_telegram"
  }
}

Input Schema

Name	Required	Description	Default
`text`	Yes	The full message content to post; Markdown is supported.
`destination`	No	Destination name; omit to use the default destination.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 3, 2026

addedInput schema / properties / destination / description

Added value: +"Destination name; omit to use the default destination."

addedInput schema / properties / text / description

Added value: +"The full message content to post; Markdown is supported."

First observedNov 3, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare this is a non-idempotent, non-destructive write to an open world, so the safety profile is covered. The description adds genuinely non-obvious behavior: Markdown conversion, splitting long text into up to 10 messages, and that each successful call counts as one message toward the plan limit. It stops short of describing what happens on an unknown destination name or when a 10-message split would be exceeded.

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?

Three sentences, front-loaded with what the tool does, then the destination rule, then secondary behavior and billing impact. No redundant restatement of the title or schema fields.

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 two-parameter write tool with full annotation coverage and no output schema, the description covers purpose, destination resolution, formatting, splitting, and quota impact. What is missing is the failure/error surface (invalid destination name, quota exhausted) and any hint about the confirmation returned.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: destinations are addressed by name across four destination types, and omission selects the default. It also clarifies that text is Markdown regardless of the schema's 'Markdown is supported' phrasing and that text may span multiple outbound messages.

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

Purpose5/5

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

Description opens with a specific verb and resource ("Sends text to one of the user's Telegram destinations") and enumerates the destination kinds (private chat, group, channel, group topic). It is clearly distinguishable from the siblings get_usage and list_destinations, which do not post messages.

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 states the key branching rule explicitly: provide a destination by name, or omit it to fall back to the default destination. It does not say how to discover valid destination names (i.e., whether to consult list_destinations first), which is the one obvious usage gap.

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

All Agent Outbox for Telegram 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?