get_login_status

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds context that this tool deals with interactive login progress and that it is process-specific. It does not describe the return format or what 'progress' entails, but given the simple nature and existing annotations, it provides sufficient additional behavioral context without contradiction.

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, efficient sentence: 'Get progress of an interactive login in this process; use check_auth to verify a saved session.' It front-loads the primary action and immediately provides a relevant alternative, with zero wasted words. This is exemplary conciseness and 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?

For a read-only, no-parameter tool, the description is fairly complete. It states what it does and distinguishes from a key alternative. However, it does not clarify what 'progress' means (e.g., possible return values) nor does it mention the existence of service-specific status tools (get_mytu_login_status, etc.) that might be more appropriate for certain login flows. Given the simplicity, this is a minor gap but leaves the agent to infer some 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 input schema has zero parameters, so schema coverage is 100% (vacuously). The description adds no parameter-specific information, which is appropriate since none exist. Per the calibration baseline, a tool with no parameters earns a 4, as the description does not need to elaborate on inputs.

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's function: 'Get progress of an interactive login in this process.' It uses a specific verb (Get) and resource (progress of an interactive login), and distinguishes itself from check_auth by explicitly noting that tool is for verifying a saved session. However, it doesn't differentiate from the service-specific status tools like get_mytu_login_status or get_mail_login_status, which are siblings, so the purpose is clear but not fully contrasted with all alternatives.

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 a clear usage alternative: 'use check_auth to verify a saved session.' This tells the agent when not to use this tool and points to a specific alternative. It implies that this tool is for checking the progress of an interactive login, which is a distinct scenario. However, it does not mention the other status getters (e.g., get_mytu_login_status) that exist for specific login flows, leaving some ambiguity about which status tool to use in those contexts.

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