Skip to main content
Glama
briejhxh

codex-telegram

by briejhxh

telegram_search_chats

Read-only

Search for Telegram chats, including people, groups, channels, and saved messages, by name or username. Retrieve user IDs for private chats and verify ambiguous matches before messaging.

Instructions

Find people, groups, channels, or Saved Messages by name, username, or title. Private-chat results include the contact's Telegram user_id where available. Before sending to an ambiguous name, search and confirm the intended chat.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.2/5.0
Behavior4/5

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

The readOnlyHint annotation already signals a safe read operation, and the description adds useful behavioral detail: private-chat results include the contact's user_id where available, and the tool is meant for disambiguating recipients before sending. No contradiction exists. The description could add scope limitations or result pagination, but with the annotation covering safety, this is solid.

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?

Three sentences, with the primary purpose in the first sentence and only functional extras after it. The user_id detail and usage advice both earn their place. There is no filler, repetition, or ambiguity.

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 simple two-parameter read-only search with no output schema, the description covers what the tool searches, how the query is interpreted, one key return detail (user_id), and the recommended workflow. It is slightly light on the exact shape of results beyond user_id, but the simplicity of the tool and presence of annotations make it adequately complete.

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 0%, so the description carries the burden of parameter meaning. It explains the required 'query' parameter well by defining it as name, username, or title. However, 'limit' is left undescribed; only the schema's numeric min/max constraints hint at its purpose, and the description does not mention result count or default behavior. This is partial compensation, not full.

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 starts with a specific verb 'Find' and clearly delimits the resource: people, groups, channels, or Saved Messages searchable by name, username, or title. This distinguishes it from siblings such as telegram_search_messages (message content) and telegram_list_chats (listing existing chats). It also adds a distinctive behavior—returning user_id for private chats—which further clarifies the tool's role.

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?

The description provides clear usage context: 'Before sending to an ambiguous name, search and confirm the intended chat.' This tells the agent when this tool is the right choice. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of a fully explicit routing guide.

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