Skip to main content
Glama
TONresistor

Telegram MCP Server

by TONresistor

createInvoiceLink

Create a Telegram payment invoice link with product details, pricing, and currency, returning a ready-to-share URL for checkout.

Instructions

Create a link for an invoice. Returns the created invoice link as String on success.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesProduct name, 1-32 characters
pricesYesPrice breakdown, a JSON-serialized list of components.
payloadYesBot-defined invoice payload, 1-128 bytes. This will not be displayed to the user, use it for your internal processes.
currencyYesThree-letter ISO 4217 currency code, or "XTR" for payments in Telegram Stars
need_nameNoPass True if you require the user's full name to complete the order.
photo_urlNoURL of the product photo for the invoice.
need_emailNoPass True if you require the user's email address to complete the order.
photo_sizeNoPhoto size in bytes
descriptionYesProduct description, 1-255 characters
is_flexibleNoPass True if the final price depends on the shipping method.
photo_widthNoPhoto width
photo_heightNoPhoto height
provider_dataNoJSON-serialized data about the invoice, which will be shared with the payment provider.
max_tip_amountNoThe maximum accepted amount for tips in the smallest units of the currency.
provider_tokenNoPayment provider token, obtained via @BotFather. Pass an empty string for payments in Telegram Stars.
need_phone_numberNoPass True if you require the user's phone number to complete the order.
subscription_periodNoThe number of seconds the subscription will be active for before the next payment. The currency must be set to 'XTR' (Telegram Stars) if the parameter is used. Currently, it must always be 2592000 (30 days).
need_shipping_addressNoPass True if you require the user's shipping address to complete the order.
suggested_tip_amountsNoA JSON-serialized array of suggested amounts of tips in the smallest units of the currency.
business_connection_idNoUnique identifier of the business connection on behalf of which the link will be created. For payments in Telegram Stars only.
send_email_to_providerNoPass True if the user's email address should be sent to the provider.
send_phone_number_to_providerNoPass True if the user's phone number should be sent to the provider.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv1.0.0

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavior disclosure. It only mentions returning a string on success, but says nothing about side effects, required payment provider setup, whether a user is charged, or what failure behavior looks like. For a financial/create type operation with zero annotation coverage, this is a meaningful gap.

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?

The description is a single, front-loaded sentence with no filler. It states the primary action and the return value in the fewest possible words. Nothing in the description is redundant or unnecessary.

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?

Despite a rich 22-parameter schema, the description does not address key contextual elements: when this should be used instead of sendInvoice, payment-related constraints, or operational requirements. Since there is no output schema, the description is the only place to explain the full call context, and it falls short for a complex payment tool.

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?

Input schema coverage is 100%, so all 22 parameters have descriptions in the schema. The tool description adds no additional parameter semantics, which matches the baseline of 3 when the schema already documents everything.

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?

The description uses a specific verb-resource pairing: 'Create a link for an invoice'. It clearly distinguishes itself from the sibling sendInvoice by focusing on link creation rather than sending. It also explicitly states the return type, which removes ambiguity about what the tool produces.

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

Usage Guidelines2/5

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

The description does not state when to use createInvoiceLink versus sendInvoice or other payment-related tools. It says 'create a link' but gives no explicit context, prerequisites, or exclusions. An agent must infer the use case from the tool name and sibling list.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/TONresistor/telegram-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server