Manage a Telegram chat by retrieving chat details, banning users, or kicking members using a chat ID and specified action.
Manage a Telegram chat (get info, ban, kick, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| chat_id | Yes | ||
| user_id | No | ||
| bot_token | No | Bot token. Optional when connected in UnClick or the documented env var is set. |
Changes observed during successful MCP inspections.
v0.1.11Input schema / properties / bot_token / descriptionAdded value: +"Bot token. Optional when connected in UnClick or the documented env var is set."Input schema / requiredPrevious value: -[
- "bot_token",
- "chat_id",
- "action"
-]New value: +[
+ "chat_id",
+ "action"
+]v0.1.5Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full behavioral burden. It hints at destructive operations (ban, kick) but never states irreversibility, required admin permissions, rate limits, or how mixed read/write actions behave in one tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence front-loads the resource and operation. It is efficient, though the trailing 'etc.' signals underspecification rather than helpful brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A multi-action chat management tool with no annotations, no output schema, and a free-text action parameter needs far more explanation. The definition leaves the agent guessing about valid actions, permissions, and return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, and the critical 'action' parameter has no enum and no description, leaving valid values like ban vs kick vs get-info undocumented. Only bot_token has a schema description; the description compensates minimally with examples but not with actual accepted values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb "Manage" is generic and the scope is broadened by "etc.", but the parenthetical examples (get info, ban, kick) give an agent some sense of the operations. It does not distinguish this from siblings like telegram_send, telegram_read, or telegram_search, nor does it enumerate valid action values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this versus telegram_send, telegram_read, telegram_search, or telegram_get_updates. The description also doesn't state prerequisites, like whether the bot must be an admin to ban or kick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.