Manages Telegram channels and tracks subscriber sources, with tools for channel management, integration with advertising systems, and tracking script configuration.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tgtrack-mcp list my channels"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Manage a tgtrack / «Откуда Подписки» account from an AI agent — channels, ad-system integrations, tracking-script settings, goals and links — with no official API.
English · Русский
tgtrack ("Откуда Подписки") tracks where your Telegram subscribers come from and feeds offline "subscription" conversions back to Yandex Metrika / Direct. All of it — channels, "advertising systems" (integrations), the landing tracking-script, goals, links, daily reports — lives only in the settings.tgtrack.ru panel. There is no public API.
tgtrack-mcp exposes that control plane as MCP tools. It talks to the same internal endpoints the panel uses and signs every request exactly like the panel does (a short-lived JWT plus an md5-based request signature), so an AI agent (Claude, etc.) can list channels, read and create integrations, tweak the script settings, goals and links — in one turn.
🔑 Uses your panel token — a JWT read from the settings.tgtrack.ru URL; nothing is scraped or hardcoded
🧩 18 focused tools — read + safe writes; destructive actions gated behind confirm: true
🧮 Panel-accurate signing — H = md5(md5(JSON + T) + T), verified against a live sample
🪶 TypeScript, ESM, strict — thin, MIT, no account secrets in the repo
Related MCP server: telegram-ads-mcp
Every call is a POST to https://api.tgtrack.ru/API/settings/<endpoint>.php with a multipart/form-data body of two fields:
JSON = JSON.stringify({ ...params, T, tn }) // T = unix seconds, tn = your JWT
H = md5( md5(JSON + T) + T ) // request signature (T is the salt)The response is a { S, D, M } envelope: S === 0 means success and the payload is D.data; otherwise the tool returns a typed error (217/218 = bad/expired token → a clear "refresh your token" message).
Node ≥ 18.
A tgtrack token (TGTRACK_TOKEN): open settings.tgtrack.ru, and copy the t= value from the address bar (or the tgtrack_token cookie). It is short-lived (~72 h); tgtrack has no working refresh endpoint, so re-paste it when it expires.
npm install
npm run buildRegister it with your MCP client (see .mcp.json.example):
{
"mcpServers": {
"tgtrack": {
"command": "node",
"args": ["dist/index.js"],
"env": { "TGTRACK_TOKEN": "<the ?t=... JWT from settings.tgtrack.ru>" }
}
}
}Tool | Purpose |
| List all channels / groups / bots on the account. |
| Full channel: integrations (ad systems), links, script & report settings. |
| Build the ready |
Tool | Purpose |
| Create an integration. For |
| Script settings of an integration (strict mode, conversion delay, auto-approve, goal flags…). |
| Update a goal (name/value in Metrika), optionally create it. |
| Poll Yandex auto-goal creation by |
| Link to re-grant Yandex access for an integration. |
Tool | Purpose |
| Landings attached to a channel / integration. |
| Change a link's target URL. |
| Rename a link / integration. |
| Params of an under-post button link (target, button text, subscription check). |
| Toggle auto-approval of join requests. |
| Daily-report toggles (morning report, send-if-no-subs, traffic report). |
confirm: trueTool | Purpose |
| ⚠️ Delete an invite link / integration (irreversible). |
| ⚠️ Delete an outbound link (irreversible). |
| ⚠️ Mint a new API key — invalidates the previous one. |
| ⚠️ Mint a new report key — invalidates the previous one. |
Without confirm: true the dangerous tools return a description of what they would do and never touch the API.
Run the MCP server over stdio, or call a tool directly for scripting:
node dist/index.js # MCP (stdio)
TGTRACK_TOKEN=... npx tsx src/run.ts tgtrack_list_channels
TGTRACK_TOKEN=... npx tsx src/run.ts tgtrack_get_channel '{"chatID":"600334c8b9b9e"}'
TGTRACK_TOKEN=... npx tsx src/run.ts tgtrack_get_integration_script \
'{"linkID":"5cd4255d831d9e","counterID":"110494105"}'Streamable HTTP transport:
TGTRACK_TOKEN=... node dist/index.js --http --port 3001 # /mcp, /healthIncluded (v1): the full settings/management control plane — channels, integrations, script settings, goals, links, reports.
Not included yet:
Analytics data (subscribers over time, source breakdown, conversions) — this lives behind a separate reporting API keyed by a report key (tgtrack_new_report_key). Planned for v2.
Admin tools (deleteChannel, changeUserAccess, …) — planned behind a flag (v1.1).
MAX (max.tgtrack.ru) parity — behind a service option.
The token lives only in your environment (TGTRACK_TOKEN) — never in the repo, never logged, never echoed in error messages. .mcp.json and .env are git-ignored; only .mcp.json.example (with a placeholder) is committed.
Contributions welcome — open an issue or a PR.
Fork and branch: git checkout -b feature/my-change
npm install; npm run build and npm test must pass
Never commit secrets (the JWT / .env / a real .mcp.json) or real account data
Open a PR describing what and why
MIT
Создать интеграцию («рекламную систему»). Для yandex вернёт grantAccessUrl + webCreationCode (нужно завершить OAuth в браузере).
| Name | Required | Description | Default |
|---|---|---|---|
| chatID | Yes | ID канала tgtrack | |
| linkName | Yes | Название интеграции (напр. «Яндекс Директ», «Лендинг Tilda») | |
| accessToken | No | OAuth access token (когда нужен ручной токен) | |
| counterNumber | No | Номер счётчика Я.Метрики (для yandex/website) | |
| goalSubscribe | No | userDidSubscribe | |
| goalToChannel | No | toTelegram | |
| integrationType | No | Тип рекламной системы. Для лендинга с Метрикой — yandex. | yandex |
| goalOpenTelegram | No | userDidOpenTelegram | |
| withMetrikaCounter | No | На странице есть счётчик Я.Метрики | |
| linkAutoApproveDelay | No | ||
| closedInviteTargetUrl | No | Целевой URL для закрытого инвайта | |
| enableLinkAutoApprove | No | ||
| enableGoalOpenTelegram | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It partially discloses behavior by noting that for yandex it returns grantAccessUrl and webCreationCode requiring OAuth completion, but it omits details for other integration types, side effects, or success/failure states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, no unnecessary words. Efficiently conveys core purpose and a key behavioral note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 13 parameters, no output schema, and no annotations, the description is too brief. It does not explain prerequisites, return format (for non-yandex types), or the overall context of integration creation. Significant gaps remain for an AI agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 54%, meaning some parameters lack schema descriptions. The description does not add any parameter-level meaning beyond what is in the schema, failing to compensate for the missing descriptions. It only mentions yandex-related output, not parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Create an integration') and adds a key detail about yandex behavior. It clearly distinguishes from sibling tools which focus on deletion, retrieval, or updates of links and channels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating integrations but does not provide explicit guidance on when to use this tool vs alternatives, nor does it mention conditions where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
⚠️ Удалить invite-ссылку/интеграцию (необратимо). Требует confirm:true.
| Name | Required | Description | Default |
|---|---|---|---|
| chatID | Yes | ||
| linkID | Yes | ||
| confirm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses irreversibility and the need for confirm, which are critical behavioral traits. It does not detail success responses or error conditions, but the disclosed traits are sufficient for basic safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. The emoji effectively highlights the destructive nature. Every word adds value, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is adequate for a simple irreversible delete action. However, it lacks details on return values, error handling, and resource identification (chatID, linkID), which could be clarified for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the confirm parameter (requires true), but provides no meaning for chatID or linkID. This partial coverage partially compensates but not fully for all three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes an invite link/integration and is irreversible. The verb 'delete' and noun 'invite-link/интеграцию' specify the action and resource, distinguishing it from sibling tools like tgtrack_create_integration (create) and tgtrack_delete_outbound_link (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly requires confirm:true to execute, providing a prerequisite. However, it does not specify when to use this tool versus similar deletion tools or when not to use it, leaving usage context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
⚠️ Удалить outbound-ссылку (необратимо). Требует confirm:true.
| Name | Required | Description | Default |
|---|---|---|---|
| chatID | Yes | ||
| linkID | Yes | ||
| confirm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. Clearly communicates irreversibility (destructive action) and need for confirm parameter. Lacks details on side effects, permissions, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with no filler. Warning emoji front-loads critical info. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimalist: covers purpose and key behavioral trait (irreversible + confirm requirement), but omits expected output, error conditions, and parameter semantics for IDs. Adequate for a simple destructive action but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description adds meaning only for the 'confirm' parameter (must be true). No clarification for chatID and linkID beyond basic type. Partial compensation for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the verb 'delete' and resource 'outbound link', with irreversibility warning. Differentiates from sibling tgtrack_delete_invite_link by specifying 'outbound'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a usage requirement (confirm:true) but does not specify when to use this tool versus other deletion tools or alternatives. No explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Полная инфа по каналу: интеграции (рекламные системы), ссылки, настройки скрипта и отчётов.
| Name | Required | Description | Default |
|---|---|---|---|
| chatID | Yes | ID канала tgtrack (виден в URL панели ?chat=..., напр. 600334c8b9b9e) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully discloses behavior. It describes the returned content (integrations, links, settings, reports). For a read-only operation, this is sufficient; no side effects are mentioned but not expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose, efficiently lists return categories. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately explains the returned information. It compensates for lack of output schema by listing key data categories. Could mention response format but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for chatID. The tool description adds no new meaning beyond the schema parameter description, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves full channel info including integrations, links, script settings, and reports. It uses specific verbs and resources, and distinguishes from siblings like list_channels which likely returns a channel list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for getting comprehensive channel data but does not explicitly state when to use versus alternatives. No exclusions or guidelines comparing to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Собрать готовый landing-скрипт + click-ссылку по linkID и counterID (без запроса к API).
| Name | Required | Description | Default |
|---|---|---|---|
| linkID | Yes | linkID интеграции (из get_channel → integrations[].linkID) | |
| counterID | Yes | Номер счётчика Яндекс.Метрики, привязанного к интеграции |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description takes full burden. While it notes 'без запроса к API' (no API request), which is a key behavioral insight, it does not disclose permissions, side effects, or state changes. However, for a read-like tool, the no-API-request detail is significant transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence conveying core functionality without verbosity. Could improve by front-loading the result type, but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no description of return value format. The agent cannot determine whether the result is a string, object, or file. For a tool assembling something, output details are critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for both parameters (linkID and counterID). The description adds no additional meaning beyond the schema's parameter descriptions, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'собрать' (assemble) and identifies the resource as a landing script and click link. It clearly distinguishes from sibling tools like 'tgtrack_get_landings' (likely returns list) by specifying assembly of ready-made script.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use or when to avoid this tool. No mention of alternatives among siblings. The description only states what it does, not the context of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Лендинги, привязанные к каналу/интеграции.
| Name | Required | Description | Default |
|---|---|---|---|
| chatID | Yes | ||
| linkID | No | Ограничить одной интеграцией |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits such as read-only nature, permissions, or side effects. Only states what resource is retrieved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise but under-specified. It lacks front-loaded essential details, making it insufficient for understanding tool usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and many sibling tools, the description is completely inadequate. It does not specify return format, error conditions, or relationships to other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information. The schema has 50% coverage (linkID documented, chatID not). The description fails to explain the required chatID or how parameters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool gets 'landings attached to channel/integration', but 'landings' is not defined. The purpose is somewhat clear but vague, and it does not distinguish from siblings like tgtrack_get_channel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ссылка для восстановления/повторной выдачи Яндекс-доступа по интеграции.
| Name | Required | Description | Default |
|---|---|---|---|
| linkID | Yes | linkID интеграции Яндекса |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the purpose but does not disclose whether the action is read-only or has side effects (e.g., generating a new link vs. retrieving an existing one). 'Restore' may imply state mutation, but this is unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the purpose. No redundant information. However, it could be slightly more precise (e.g., 'Retrieves a link to restore...').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is minimal. It does not explain the return value (e.g., is it a URL string?), potential errors, or prerequisites. A bit more context would be beneficial even for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the single parameter 'linkID' described in the schema. The tool description adds no extra meaning beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it's a link for restoring/re-issuing Yandex access via integration. The verb 'get' is implied by the tool name. It clearly indicates the resource (restore Yandex link) and distinguishes from sibling tools that create, delete, or update links or settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, common scenarios, or when not to use. Given many related sibling tools, explicit usage context would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Список всех каналов/групп/ботов пользователя в tgtrack.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the tool lists entities but does not disclose read-only nature, whether it returns full details or summaries, or any pagination/performance characteristics. For a read tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core purpose without extraneous information. It is appropriately sized for a simple list operation, though it could be slightly improved with a more active verb structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and a straightforward action, the description covers the basics. However, with no output schema, it should at least hint at what fields or format the list returns (e.g., IDs, names). The lack of such detail leaves some gaps for an agent expecting to parse the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage. The description adds meaning by clarifying what is listed (channels, groups, bots). Baseline for 0 params is 4, and the description meets it by providing context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates it lists all channels/groups/bots of the user in tgtrack. It specifies the resource type and scope (user's own entities), distinguishing it from sibling tools like tgtrack_get_channel which targets a single item. However, using a noun ('List') instead of an active verb slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., when to use list vs get_channel). There are no prerequisites, exclusions, or context about its role among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
⚠️ Создать новый API-ключ канала — ИНВАЛИДИРУЕТ предыдущий. Требует confirm:true.
| Name | Required | Description | Default |
|---|---|---|---|
| chatID | Yes | ||
| confirm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses critical behavioral trait: invalidates the previous API key. Also notes required confirm parameter being true. With no annotations, description carries full burden and provides strong transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: single sentence with warning emoji, action statement, and required condition. No extraneous text. Front-loaded with critical warning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, critical behavioral warning, and parameter requirement. Missing return value or success indicator, but no output schema exists. Mostly complete for a simple mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. It specifies confirm:true as required, giving semantics for that parameter. chatID is implied to identify the channel, but no format or additional detail. Adds value but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Create a new API key for channel' with a specific verb and resource. It distinguishes from sibling tools like tgtrack_create_integration or tgtrack_new_report_key by specifying channel API key. The warning about invalidation adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use requires confirmation (confirm:true) but does not explicitly state when to use vs alternatives or when not to use. No exclusion or alternative guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
⚠️ Создать новый ключ отчётов — инвалидирует предыдущий. Требует confirm:true.
| Name | Required | Description | Default |
|---|---|---|---|
| chatID | Yes | ||
| confirm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the destructive behavior of invalidating the previous key and requires confirm:true, adding important safety context. No annotations are provided, so the description carries the full burden. While it could detail the invalidation process more, it effectively warns about the impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a warning emoji, conveying the essential information efficiently and front-loading the caution. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, destructive effect, and the confirm requirement. However, it omits explanation of the required 'chatID' parameter and does not describe the return value or output. Given the tool's simplicity (2 parameters, no output schema), this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for the 'confirm' parameter by stating it must be true, but the schema has a default of false, creating a contradiction. The 'chatID' parameter is required but completely unexplained. With 0% schema coverage, the description should compensate more thoroughly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool creates a new report key and invalidates the previous one. The verb 'create' and resource 'report key' are specific, and the invalidation detail distinguishes it from other tgtrack tools, none of which appear to involve report keys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that the tool requires confirm:true, providing a usage condition. However, it does not explicitly state when to use this tool versus alternatives (e.g., other key management tools like tgtrack_new_api_token) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Вкл/выкл авто-одобрение заявок на вступление в канал.
| Name | Required | Description | Default |
|---|---|---|---|
| chatID | Yes | ||
| autoApprove | Yes | Авто-одобрение заявок на вступление |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It correctly indicates the tool toggles a boolean state (auto-approve). However, it does not disclose side effects, required permissions, or whether the operation is reversible. For a simple toggle, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded phrase with no extraneous words. Every word contributes meaning, making it efficient for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required params, no output schema, no annotations), the description covers the core purpose. However, it lacks details on prerequisites (e.g., channel existence), return value, or error conditions. It is minimally complete but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 50% description coverage (autoApprove has a description, chatID does not). The tool description adds no parameter-specific information beyond the action; it does not explain what chatID represents or the format required. The description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Вкл/выкл' – enable/disable) and the resource ('авто-одобрение заявок на вступление в канал' – auto-approval of channel join requests). This verb-resource pair is distinct from sibling tools, which focus on creating integrations, deleting links, fetching channel data, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It simply states what the tool does without context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Переименовать ссылку/интеграцию.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| chatID | Yes | ||
| linkID | Yes | ||
| isOutbound | No | true для outbound-ссылок (кнопка под постом) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only states 'rename' which implies a mutation but provides no information about side effects, permissions, or what happens to associated data. This is critically insufficient for safe agent invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but at the expense of necessary detail. It is not front-loaded with key information, and several pieces of information are missing, making it minimally viable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no output schema, no annotations), the description is severely incomplete. It lacks explanation of return values, effect on the link, and any edge cases, leaving the agent without sufficient context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters with only 25% coverage (isOutbound has a description). The description adds zero parameter information, failing to compensate for low schema coverage. The agent gets no help understanding name, chatID, or linkID beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Rename link/integration' clearly states the verb (rename) and resource (link/integration), making the purpose understandable. However, it does not differentiate from sibling tools beyond the name, leaving some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., tgtrack_set_link_url). There are no prerequisites, exclusions, or use-case examples, leaving the agent without decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Изменить целевой URL ссылки (targetUrl).
| Name | Required | Description | Default |
|---|---|---|---|
| chatID | Yes | ||
| linkID | Yes | ||
| targetUrl | Yes | Новый целевой URL (напр. t.me-инвайт канала) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must disclose behavioral traits. Only states 'change' which implies mutation, but lacks details on side effects, reversibility, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence is concise but too brief; lacks important details that would make it earn its place fully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations; description omits essential context like what chatID and linkID represent, return value, or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (targetUrl has description). Description adds no extra meaning for chatID or linkID, which remain undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (change target URL) and resource (link). The name helps distinguish from siblings (e.g., tgtrack_set_link_name) but could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites or conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Параметры outbound-ссылки (кнопка под постом): targetUrl, текст кнопки, проверка подписки.
| Name | Required | Description | Default |
|---|---|---|---|
| linkID | Yes | ||
| targetUrl | Yes | ||
| buttonText | No | ||
| unsubscribedText | No | Текст для неподписанных (null — убрать) | |
| checkSubscription | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose any behavioral traits such as whether the operation is destructive, requires authentication, or has rate limits. It only lists parameters, leaving the agent uninformed about side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) and front-loads the key terms. It could be slightly longer to cover missing parameters, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description is incomplete. It fails to explain the required linkID, the optional unsubscribedText, and the behavior of checkSubscription. The agent lacks critical context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (20%). The description adds meaning for three of the five parameters (targetUrl, button text, check subscription) but omits linkID (required) and unsubscribedText. This partial coverage does not fully compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it sets outbound link parameters (button under post) and lists targetUrl, button text, and subscription check. This clearly indicates the tool's purpose and differentiates it from sibling tools like tgtrack_delete_outbound_link or tgtrack_set_link_name. However, it could be more explicit about the action (e.g., 'update or set these parameters').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not mention when to use this tool vs alternatives, or any prerequisites or exclusions. The agent is left to infer usage from the name and parameter list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Настройки ежедневных отчётов канала (утренний отчёт, если нет подписок, отчёты по трафику).
| Name | Required | Description | Default |
|---|---|---|---|
| chatID | Yes | ||
| sendIfNoSubs | No | Присылать, даже если нет подписок/отписок | |
| sendMorningReport | No | ||
| sendTrafficReport | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It only lists settings without disclosing side effects, permissions, or safety. The tool likely performs a write operation, but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, front-loaded with key information. It earns its place by summarizing the tool's purpose efficiently, though it could be structured with bullet points for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, no output schema, and low schema documentation, the description fails to explain return values, error conditions, prerequisites (e.g., chatID must exist), or the exact effect of each setting. A tool that modifies settings should provide more comprehensive context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds context for three boolean parameters (morning report → sendMorningReport, if no subs → sendIfNoSubs, traffic reports → sendTrafficReport), but chatID is not explained. With only 25% schema description coverage, the description partially compensates but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Channel daily report settings (morning report, if no subscriptions, traffic reports)', clearly indicating the tool configures report settings for a channel. It distinguishes from sibling tools that set other channel properties like auto-approve or link names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No conditions, prerequisites, or exclusions are mentioned. Siblings include other set tools but no differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Изменить настройки скрипта интеграции (strictMode, conversionDelay, авто-одобрение, флаги целей и т.п.).
| Name | Required | Description | Default |
|---|---|---|---|
| chatID | Yes | ||
| linkID | Yes | linkID интеграции | |
| strictMode | No | ||
| autoApprove | No | ||
| conversionDelay | No | ||
| trackThroughWebApp | No | ||
| leadMagnetSubscriber | No | ||
| sendGoalDidOpenTelegram | No | ||
| sendGoalStayedInChannel | No | ||
| stayedInChannelCheckDelay | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the tool changes settings, implying a write operation, but gives no details on destructiveness, authorization needs, side effects, or what happens after changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose and then lists examples. It is appropriately sized and structured, though it could include more details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and no annotations, the description is insufficient. It does not explain return values, side effects, required permissions, or constraints, leaving many gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 10%, but the description lists examples like strictMode, conversionDelay, auto-approval, and goal flags, adding some context beyond the minimal schema. However, most parameters remain undefined, and the description does not explain values or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Изменить' (change) and the resource 'настройки скрипта интеграции' (integration script settings), with examples of settings. It distinguishes itself from sibling tools by specifying 'script settings' which is unique among the set tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools, the description does not indicate prerequisites, when not to use, or mention other related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Обновить цель интеграции (имя/значение цели в Метрике), опционально создать её.
| Name | Required | Description | Default |
|---|---|---|---|
| chatID | Yes | ||
| linkID | Yes | ||
| goalName | Yes | Имя цели (напр. userDidSubscribe / toTelegram / userDidOpenTelegram) | |
| goalValue | Yes | Новое значение идентификатора цели в Метрике | |
| needToCreateGoal | No | Создать цель в Метрике, если её ещё нет |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only states 'update' and 'optionally create', but does not disclose behavior when the goal doesn't exist, required permissions, or side effects. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Russian, front-loading the action. It is efficient and avoids verbosity, though a bit brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return values, success/failure behavior, or provide sufficient context for a tool that modifies an integration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60%, providing descriptions for goalName, goalValue, and needToCreateGoal. The description adds context by linking 'name/goal value in Metrica' to the parameters, but does not cover chatID or linkID. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and the resource 'integration goal in Metrica', and mentions optional creation. This distinguishes it from sibling tools like tgtrack_create_integration, which handle creation only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating or optionally creating a goal, but lacks explicit guidance on when to use this tool versus alternatives like tgtrack_create_integration. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Статус авто-создания целей в Яндексе по webCreationCode из create_integration.
| Name | Required | Description | Default |
|---|---|---|---|
| chatID | Yes | ||
| webCreationCode | Yes | Код из ответа create_integration (yandex) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should carry the full burden of behavioral disclosure. It does not state whether the tool is read-only, what side effects exist, or any authentication or rate limiting requirements. The description only states what it does, not its behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the key purpose. However, it could benefit from a slightly more detailed structure, such as mentioning the response type, for higher scores.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and two parameters, the description is too brief. It does not explain the possible status values, error scenarios, or the relationship with create_integration beyond the parameter link. A complete description would list example statuses and provide usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (chatID has no description). The description adds meaning to webCreationCode by stating it comes from create_integration, but chatID remains unexplained. The description partly compensates for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the auto-creation status of Yandex goals using a webCreationCode from create_integration. It uses a specific verb (status) and resource (auto-creation goals), and distinguishes itself from sibling tools like tgtrack_create_integration and tgtrack_update_goal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool should be used after tgtrack_create_integration to check progress, but it does not explicitly state when to use it, when not to use it, or mention alternatives. The context is clear but lacks formal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0tgtrack_create_integrationtgtrack_delete_invite_linktgtrack_delete_outbound_linktgtrack_get_channeltgtrack_get_integration_scripttgtrack_get_landingstgtrack_get_restore_yandex_linktgtrack_list_channelstgtrack_new_api_tokentgtrack_new_report_keytgtrack_set_channel_auto_approvetgtrack_set_link_nametgtrack_set_link_urltgtrack_set_outbound_link_paramstgtrack_set_report_settingstgtrack_set_script_settingstgtrack_update_goaltgtrack_yandex_web_create_statusScored across 18 tools
Each tool targets a distinct resource or action (e.g., create integration, delete link, get channel info), with no overlapping purposes. Descriptions further clarify unique roles.
All tools follow a consistent 'tgtrack_verb_noun' pattern using snake_case, with verbs like create, delete, get, list, set, new, update. Only minor variation like 'new' vs 'create' but pattern is uniform.
18 tools is well-scoped for managing integrations, channels, links, reports, and settings. Not excessive, and each tool serves a clear purpose within the domain.
The set covers CRUD-like operations for integrations, links, channels, and settings, plus specialized actions for Yandex OAuth, script generation, and goal updates. No obvious gaps for the server's scope.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
SEO & marketing toolkit for AI agents: GA4, Search Console, AdSense, GTM, PageSpeed, Trends.
Short-link service embedded in your AI workflow — shorten links, track campaigns, read stats.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/skiddgoddamn/tgtrack-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
