Skip to main content
Glama
zai-one

telegram-ads-mcp

by zai-one

Targeting reference

get_targeting_reference
Read-onlyIdempotent

Retrieve country, language, topic, and channel taxonomy IDs for Telegram Ads targeting. Use these references to build user-geo or topic targeting; empty lists mean not embedded.

Instructions

List countries, languages, topics and channel taxonomies with IDs. Use for user-geo and topic targeting; for channels/bots use search_targets. Empty list means not embedded.

Input Schema

NameRequiredDescriptionDefault
kindNoboth

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description still adds a genuinely useful behavioral edge case — 'Empty list means not embedded' — which tells the agent how to interpret an empty result rather than treating it as an error.

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?

Two dense sentences: scope first, alternative second, edge-case semantics last. Nothing is wasted and the routing information is front-loaded.

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?

With an output schema present, return values need no explanation, and the description covers scope, alternative-tool routing, and empty-result semantics. The only meaningful gap for this one-parameter read tool is the unexplained/tension-laden `kind` enum.

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

Parameters2/5

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

Schema description coverage is 0% and the single `kind` parameter (enum user/channel/both) is never mentioned in the description. Worse, the enum offers kind=channel while the description says to use `search_targets` for channels, so the parameter's meaning is not just undocumented but potentially misleading.

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 names a specific verb and enumerates the returned resource types (countries, languages, topics, channel taxonomies with IDs), which is far more than a restatement of the name. There is a mild internal tension: it claims to list channel taxonomies but then routes channels/bots to `search_targets`, leaving an agent slightly unsure what the channel portion of the output actually is.

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

Usage Guidelines5/5

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

It explicitly states the use case ('user-geo and topic targeting') and names the alternative tool with the condition that selects it ('for channels/bots use `search_targets`'). This is exactly the when/when-not routing an agent needs among 25 siblings.

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