ChatPush MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

Send file

send_file

Send documents, images, audio, video, or contact cards to WhatsApp or Telegram recipients, with local/URL/base64 file input and automatic link fallback for large files.

Instructions

Send a file (document, image, audio, video, contact) to a recipient via WhatsApp or Telegram. File is uploaded as multipart/form-data. Images under 10MB sent natively, larger files as download links active for 7 days.

Use it when the user wants to share a document, photo, voice message, video or contact card. Provide the file as exactly one of: file_path (local file), file_url (downloaded by the server) or file_base64 (with file_name).

Supported: pdf, doc, docx, ppt, pptx, xls, xlsx, zip, 7z; ogg, opus, mp3, aac, amr, 3gp; jpeg, png, webp; mp4; vcf. Max 100 MB. Recipient rules are the same as send_message.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "send_file"
  }
}

Input Schema

Name	Required	Description
`type`	No	document = send as file, image = send as photo (WhatsApp/tdlib).
`phone`	No	Recipient phone in international format. Optional if username is used (tdlib).
`caption`	No	Description below the file (WhatsApp only).
`file_url`	No	Public http(s) URL of the file; the server downloads and uploads it.
`priority`	No	Sending priority. Chosen automatically if omitted.
`username`	No	Telegram username (tdlib only).
`utm_mark`	No	Label for tracking dispatches (see get_utm_tags).
`file_name`	No	Filename with extension, e.g. document.pdf. Defaults to the name from file_path or file_url.
`file_path`	No	Absolute path of a local file to upload (~ is expanded).
`customer_id`	No	Internal client ID.
`external_id`	No	Your client-side ID for this message (idempotency ID).
`file_base64`	No	File content as base64 (a data: URL is accepted too). Requires file_name.
`sender_name`	No	Registered SMS sender name (see get_balance → sender names).
`callback_url`	No	URL that receives the final delivery status as a POST request (retried every 2 minutes, up to 10 times, until it returns HTTP 200).
`scheduled_at`	No	Delayed sending time, format YYYY-MM-DD HH:MM:SS in UTC+0. At least 1 minute and at most 1 month ahead.
`tdlib_user_id`	No	Telegram user ID (positive = private chat, negative = group chat). tdlib channel only.
`simulate_typing`	No	Default true: show a typing indicator in WhatsApp before sending. false sends instantly.
`dispatch_routing`	No	Channels in the order ChatPush should try them (cascade: the next channel is used only if delivery through the previous one fails). whatsapp = WhatsApp, tdlib = personal Telegram account, telegram = Telegram Bot, notify = VK/OK, max = MAX messenger, sms = SMS. If omitted, the account's default routing is used.
`reply_to_message_id`	No	ID of the message to reply to, taken from an incoming-message webhook.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 4, 2026

TDQS

A4/5.0

Behavior4/5

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

With annotations already declaring readOnlyHint=false, openWorldHint=true, destructiveHint=false and idempotentHint=false, the description still adds real behavior: multipart/form-data upload, native image delivery under 10MB, larger files converted to download links that expire after 7 days, and a 100 MB ceiling. The link-expiry side effect is exactly the kind of non-obvious trait an agent needs. It does not state permission requirements or what the response contains, keeping it below 5.

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?

Purpose and scope are front-loaded in the first sentence, followed by usage conditions and then input options. Three short paragraphs, no filler. Minor redundancy between the 'document, image, audio, video, contact' list at the top and the format enumeration below, and the 'images under 10MB sent natively, larger files as download links' clause is slightly ambiguous about which file kinds trigger link conversion.

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 19-parameter, open-world sending tool with no output schema, the description covers the important dimensions: input source alternatives, supported formats, size cap, delivery behavior for large images, and delegation of recipient rules to send_message. The main gap is that with no output schema it does not describe what a successful send returns (message ID, delivery status), which an agent would need to chain into get_delivery_status.

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% across 19 parameters, so the baseline would be 3. The description earns above baseline by stating an exclusivity constraint the schema does not encode: file_path, file_url and file_base64 are mutually exclusive alternatives, with file_base64 requiring file_name. It also bounds the file type and size, adding meaning beyond the per-property descriptions it also renders.

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 opens with a specific verb and resource: 'Send a file (document, image, audio, video, contact) to a recipient via WhatsApp or Telegram.' That is far more informative than the name alone, and the file-vs-text distinction against the send_message sibling is implicit in the medium. However, it never names send_message explicitly, so sibling routing is left to inference rather than stated.

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 it when the user wants to share a document, photo, voice message, video or contact card' gives clear when-to-use context. It also constrains how to supply input ('exactly one of: file_path, file_url or file_base64'), which is practical guidance. There is no explicit when-not guidance or reference to send_message for plain text, so it stops short of the top band.

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