Skip to main content
Glama

user_telegram_web_auth_init_get

Initiates Telegram Login OIDC for web authentication, generating state, nonce, and PKCE parameters.

Instructions

GET /telegram/web/auth/init Инициализация Telegram Login OIDC (state, nonce, PKCE) Тег: Telegram bot Спека: user

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoМакс. кол-во записей
offsetNoСмещение (пропуск записей)
user_idNoadmin acts on behalf of this user

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.7/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It does disclose non-obvious behavioral content — that this initializes an OIDC flow producing state, nonce and PKCE — which is real context beyond the schema. It still omits auth/credential requirements, whether it issues a redirect, and what the caller receives.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is short and the purpose line comes first, but it spends lines on low-value boilerplate — the raw HTTP path duplicates the tool name, and 'Тег: Telegram bot' / 'Спека: user' are metadata rather than usable instruction.

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

Completeness2/5

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

For a security-sensitive auth-init endpoint with zero annotations and no output schema, the definition is too thin: it never explains credential/permission needs, what the init returns, or how it relates to the sibling start/post/callback tools an agent must sequence after it.

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 100%, so the schema already documents limit, offset and user_id; baseline is 3. The description adds no parameter meaning at all, and notably the listed params (pagination, user_id) look unrelated to an OIDC init step, which it does not clarify.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a verb and resource ('GET /telegram/web/auth/init', 'Инициализация Telegram Login OIDC'), so the basic action is identifiable. However, it gives no differentiation from near-identical siblings such as user_telegram_web_auth_start_get, user_telegram_web_auth_post, user_telegram_web_callback_get and user_telegram_webapp_auth_get, leaving the agent unable to tell which init/start step it should call.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisites, and no mention of the alternative Telegram auth endpoints. The word 'init' weakly implies it is a first step, but nothing tells the agent when to prefer this over the sibling start/callback/webapp variants.

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

Install Server

Other Tools