Skip to main content
Glama
Sign In
telegram-mcp

telegram-mcp

by dikaglorya
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Send a file

telegram_send_file

Send a local file to a Telegram chat as a document or auto-detected media, with an optional caption. Share files immediately from an agent.

Instructions

Send a local file as a document (forceDocument) or auto-detected media. Supports caption. Sends immediately.

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": {
      "chat": "<chat>",
      "filePath": "<filePath>"
    },
    "name": "telegram_send_file"
  }
}

Input Schema

NameRequiredDescriptionDefault
chatYes
captionNo
replyToNo
filePathYes
forceDocumentNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.1/5.0
Behavior3/5

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

Annotations declare readOnlyHint=false (a write) and openWorldHint=true, so safety is partly covered. The description usefully adds that the send is immediate (not scheduled) and that captioning is supported, but it doesn't explain the forceDocument default behavior's consequences or permission requirements.

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 terse sentences with zero filler, and the core action is front-loaded. It is efficiently sized for a simple send operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 5 parameters at 0% schema coverage and no output schema, the description is too thin. It omits semantics for replyTo and chat/filePath and gives no sense of what a successful send returns or how failures manifest.

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

Parameters2/5

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

Schema coverage is 0% across 5 parameters, so the description carries the burden but only partially delivers. It explains forceDocument (document vs auto-detected media) and caption, but leaves chat, filePath, and especially replyTo entirely undocumented.

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 names a specific verb+resource ('Send a local file') and clarifies the two modes of operation ('as a document (forceDocument) or auto-detected media'). This implicitly distinguishes it from siblings like telegram_send_photo and telegram_send_message, though it never names them explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It hints at when the tool applies ('local file', 'auto-detected media') and that it 'Sends immediately', implying no scheduling. However, it gives no explicit when-to-use guidance versus telegram_send_photo or telegram_send_message, leaving the agent to infer the boundary.

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

Deploy Server

Other Tools