Skip to main content
Glama

File context

tg_file_context
Read-only

Gathers a Telegram file message’s caption, nearby posts, album items, passwords, versions, links, and sizes; finds its description post in a given chat before download or archive extraction.

Instructions

Everything around one file message: its caption, neighbouring posts and album items, plus extracted passwords, versions, links and sizes. With intro_chat, also finds the matching description post in that chat. Use it before downloading or extracting archives.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "tg_file_context"
  }
}

Input Schema

NameRequiredDescriptionDefault
chatNoChat: @username, username, t.me link, t.me/c/<id> link, or numeric id such as -100123…
linkNo
aroundNo
accountNoAccount id (see tg_list_accounts). Defaults to the default account.
intro_chatNoChat whose posts describe the files
message_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so safety is covered. The description goes beyond them by disclosing exactly what content is assembled (captions, neighbours, album items, extracted passwords/versions/links/sizes), which is the main behavioural trait an agent needs, though it says nothing about rate limits, auth or failure modes.

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?

Two front-loaded sentences with dense, useful content and no filler; the conditional intro_chat behaviour is attached where it belongs. Only the slightly vague opener "Everything around one file message" costs it the top score.

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

Completeness3/5

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

The tool has six parameters, zero required, only 50% schema coverage and no output schema. The description covers what comes back but never explains how to identify the target file (chat + message_id vs link), which is the key invocation decision for a tool with no required parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% and the description compensates by explaining that intro_chat switches on a lookup of the matching description post, and that neighbouring posts and album items are part of the result (implying what around controls). It also clarifies the extraction surface that link/message_id ultimately feed into.

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 description gives a specific verb-less but concrete scope: gathering everything around one file message (caption, neighbouring posts, album items, passwords, versions, links, sizes). That is clearly distinct from tg_get_message or tg_search_files, though it never names a sibling explicitly.

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

Usage Guidelines3/5

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

"Use it before downloading or extracting archives" gives a clear usage context and implicitly points at tg_download/tg_extract. However there are no when-not conditions and no guidance on choosing between this and tg_get_message for the same message.

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