Skip to main content
Glama
bale-mcp

bale-mcp

by sepehr071

Bot: send message

bot_send_message
Destructive

Send a real text message from your bot to a chat or channel. Supply chat_id and text, optionally with inline buttons, to message users who started the bot.

Instructions

Send a real text message from the bot. Confirm recipient and text with the user first.

Text is Markdown (bold, italic). The user must have sent the bot /start first (or the bot is in the group/channel). To ask a question, send it (buttons for fixed choices), then call bot_wait_for_reply with the returned message_id.

Input Schema

NameRequiredDescriptionDefault
textYesMessage text.
buttonsNoInline buttons as rows of labels, e.g. [['Yes', 'No']]. A press arrives as kind 'button' (text = label, cut to 64 bytes).
chat_idYesChat id (number, e.g. 123456789) or public '@channel' username. See bot_list_chats.
reply_to_message_idNoReply to this message id in the same chat.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.2.0
    • changedInput schema / properties / buttons / description
      Previous value: -"Inline buttons as rows of labels, e.g. [['Yes', 'No']]. A press arrives as a message of kind 'button' whose text is the label (cut to 64 bytes); bot_wait_for_reply returns it."New value: +"Inline buttons as rows of labels, e.g. [['Yes', 'No']]. A press arrives as kind 'button' (text = label, cut to 64 bytes)."
    • removedInput schema / properties / buttons / title
      Removed value: -"Buttons"
    • changedInput schema / properties / chat_id / description
      Previous value: -"Chat id (number from bot_get_new_messages or bot_list_chats, e.g. 123456789) or a public channel/group username like '@mychannel'."New value: +"Chat id (number, e.g. 123456789) or public '@channel' username. See bot_list_chats."
    • removedInput schema / properties / chat_id / title
      Removed value: -"Chat Id"
    • removedInput schema / properties / reply_to_message_id / title
      Removed value: -"Reply To Message Id"
    • removedInput schema / properties / text / title
      Removed value: -"Text"
    • removedInput schema / title
      Removed value: -"bot_send_messageArguments"
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "title": "bot_send_messageDictOutput",
      -  "type": "object"
      -}New value: +null
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, openWorldHint=true, and idempotentHint=false, so the safety profile is partly covered. The description adds genuine context beyond them: a user-confirmation instruction ('Confirm recipient and text with the user first'), the Markdown formatting contract, and the prerequisite that the recipient must have started the bot. It omits rate limits and does not explicitly say the send is irreversible, but the confirmation warning is the operationally important part.

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?

Front-loaded with the action in the first sentence, then prerequisites and follow-up. Dense but nearly every clause carries operational information; the final sentence packs two distinct instructions (buttons, then bot_wait_for_reply) into one line, which is slightly compressed but not wasteful.

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 no output schema, the description usefully mentions the returned message_id and how to consume it, and it covers prerequisites, formatting, and a confirmation caution. An agent has enough to call the tool correctly; only edge cases such as failure/error behavior are unaddressed.

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. The description goes slightly beyond the schema by explaining the purpose of the buttons parameter (asking a question with fixed choices) and by noting that the call returns a message_id used for bot_wait_for_reply, which links the parameters to a workflow the schema cannot express.

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?

States a specific verb and resource ('Send a real text message from the bot') and implicitly separates itself from siblings bot_send_file (files) and bot_edit_message (modifying existing messages). The word 'real' signals the message is actually dispatched to an external chat, which matches the openWorld annotation.

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?

Gives a clear prerequisite ('The user must have sent the bot /start first, or the bot is in the group/channel') and an explicit workflow for the question case, routing the agent onward to bot_wait_for_reply with the returned message_id. It does not, however, state when to prefer bot_edit_message or bot_send_file instead, so the alternative-selection guidance is partial.

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