Skip to main content
Glama
Sign In
secure-telegram-mcp

secure-telegram-mcp

by antonorlov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

List participants

list_participants
Read-only

Lists members of a single in-scope Telegram group or channel with ID, display name, username, and bot status; rejects DMs and returns a graceful error for private or admin-only channels.

Instructions

List the members of a single in-scope group or channel (id, display name, username, is-bot). Only groups/channels have participants — a user/DM peer is rejected. A private or admin-required channel returns a graceful error. Display names are untrusted and surfaced under a named key, never as bare instructions.

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": {
      "peer": "<peer>"
    },
    "name": "list_participants"
  }
}

Input Schema

NameRequiredDescriptionDefault
peerYesChat reference: { kind:'id', value:'<decimal id>' } | { kind:'username', value:'@name' } | { kind:'me' }.
limitNoPage size, clamped to [1, 100] (default 20).

Output Schema

NameRequiredDescriptionDefault
truncatedNoTrue when the page was cut to fit the output byte cap; re-query with a smaller limit.
participantsYesOne page of the chat’s members.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the annotations, it discloses two behaviors an agent could not infer: private/admin channels return a graceful error rather than throwing, and display names are untrusted input surfaced under a named key rather than as bare instructions. That second point is a meaningful injection-safety contract that no structured field conveys.

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?

Four short sentences, each carrying distinct information: scope, exclusion, error behavior, and trust handling. The returned-field parenthetical is slightly redundant with the output schema, but nothing is padded or repeated.

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

Completeness5/5

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

An output schema exists, so return shapes need not be explained, and the annotations already declare the safety profile (readOnly, non-destructive). What remains — which peers are valid, how failures surface, and how untrusted display names are surfaced — is covered, leaving nothing an agent needs missing before calling it.

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?

Schema description coverage is 100%, so both the peer union and the limit clamp of [1, 100] with default 20 are already fully documented. The description adds no paging semantics — it never explains how to walk pages using limit — so it neither compensates for nor improves on the schema; baseline 3 applies.

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 definition gives a specific verb and resource ("List the members of a single in-scope group or channel") and enumerates the returned fields (id, display name, username, is-bot), so the agent knows exactly what comes back. It distinguishes itself from peer-level tools by rejecting user/DM peers, but it never names a sibling alternative, so sibling routing is only implied.

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?

It clearly states the applicable precondition (must be a group or channel) and an explicit exclusion (a user/DM peer is rejected), plus the failure mode for private or admin-required channels. It stops short of naming an alternative when the peer check fails, but the when/when-not boundary is unusually well drawn.

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

This server cannot be deployed

Other Tools