Skip to main content
Glama

Match posts to files

tg_match_posts
Read-only

Matches posts from an intro chat to indexed files in a files chat, returning best file matches with scores, message IDs, and any passwords or versions found.

Instructions

Pair description posts in intro_chat with files in files_chat (which must be indexed). Split archives are grouped. Returns, per post, the best matching files with a score, message ids and any passwords/versions found in the post. Typical use: one channel announces/describes, another hosts the downloads.

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": {
      "intro_chat": "<intro_chat>",
      "files_chat": "<files_chat>"
    },
    "name": "tg_match_posts"
  }
}

Input Schema

NameRequiredDescriptionDefault
postsNoHow many recent intro posts
queryNoOnly posts containing this text
fieldsNoKeep only these fields in list items (e.g. ["message_id","name","size"])
formatNocompact = lists as {columns, rows} tables; saves a lot of context for long listingsjson
accountNoAccount id (see tg_list_accounts). Defaults to the default account.
per_postNo
min_scoreNo
files_chatYesChat: @username, username, t.me link, t.me/c/<id> link, or numeric id such as -100123…
intro_chatYesChat: @username, username, t.me link, t.me/c/<id> link, or numeric id such as -100123…

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations only declare read-only, non-destructive and open-world, so the description adds real value: the indexing prerequisite for files_chat, the grouping of split archives, and the per-post result shape including scores, message ids and extracted passwords/versions. It omits scoring behavior beyond 'score' and any cost/rate characteristics of matching across two chats.

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?

Three front-loaded sentences with the core pairing behavior first, then output shape, then a use-case line. No filler, though the 'Typical use' sentence is the weakest and could be tighter.

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 9-parameter, no-output-schema tool the description covers the essential contract: what pairing means, the indexing prerequisite, and the returned fields. It leaves the list-shaping parameters (fields, format, query) and account selection entirely to the schema, which is acceptable given the high coverage.

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 coverage is 78%, so the baseline is 3, and the description only indirectly alludes to per_post/min_score via 'best matching files with a score'. It says nothing about posts, query, fields, format or account, leaving those entirely to the schema.

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 two concrete resources: 'Pair description posts in intro_chat with files in files_chat'. It also names the matching output (best matching files with score, message ids, passwords/versions), which no sibling tool name suggests, so an agent can distinguish it from tg_search_files or tg_compare_chats without opening the schema.

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 clear usage context ('one channel announces/describes, another hosts the downloads') and an implicit prerequisite that files_chat must be indexed, which points at tg_index_chat. It stops short of naming explicit alternatives or when-not-to-use, so it is not a 5.

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