login_qr

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It does disclose the return value and the necessary follow-up action, which is helpful. However, it omits such details as link expiry, whether starting QR login invalidates other pending login attempts, or what error conditions may arise, leaving only a moderate level of 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 entire description is one compact sentence that covers the action, the output format, the manual user step, and the next tool to call. Each clause adds necessary information and there is no filler or redundancy.

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?

For a zero-parameter tool that has an output schema, the description is nearly complete: it explains the returned link, the required user action, and the follow-up call. Minor gaps such as failure modes and link expiration are not critical for successfully invoking the 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?

The tool takes zero parameters, so the baseline is 4. The description correctly notes that the subsequent login_complete() call takes no arguments, though that pertains to a sibling tool. No parameter-specific information is needed here because the schema is already empty.

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 opens with the specific action 'Начать вход по QR-коду' (start login via QR code) and immediately states the concrete output: 'вернёт ссылку tg://login' (returns a tg://login link). This clearly differentiates the tool from sibling login tools like login_send_code and login_complete by positioning it as the QR-code initiation step.

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 gives explicit step-by-step instructions: scan the returned link with an already-authenticated Telegram via Settings → Devices → Connect device, then call login_complete() without arguments. It provides clear context but does not explicitly state when to prefer QR login over login_send_code or any exclusions.

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