auth.login

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

With no annotations, the description must carry the behavioral burden. It discloses that login state is imported from the local browser and that browser-specific sources are supported, which is meaningful. However, it doesn't mention side effects like whether existing sessions are replaced, whether a QR path implies interactive scanning, whether cookies are stored, or what failures can occur (e.g., unsupported browser).

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?

A single concise sentence that front-loads the operation and default source, then adds supported browsers in a compact list. It is appropriately short, though it could use one more sentence for parameter behavior.

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?

There is an output schema, so return values may be documented elsewhere, but the tool lacks annotations and has 5 undocumented parameters at 0% coverage. For a login/import tool with several behavioral branches (QR login, raw mode, source, browser, timeout), the description is under-specified and leaves an agent with too many unknowns about when QR is needed and what the output means.

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 0%, so the description must compensate, but it only explains the 'browser' concept implicitly via the supported-browser list. Parameters like qr, raw, source, and qr_timeout are left entirely unexplained, so an agent must guess their semantics from names and defaults. Baseline 3 seems right because it adds some context for the auto-detect default but fails for the majority of 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 has a specific verb+resource ('导入登录态' / import login state), names the default source (本机浏览器 auto-detect), and lists supported browsers, clearly distinguishing it from siblings like auth.status or auth.doctor. It lacks an explicit contrast with related auth.* tools, but the meaning is clear enough.

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?

It communicates the default behavior (auto-detect from local browser) and supported browser choices, so an agent knows when this is the primary entry point for establishing authentication. It doesn't say when to prefer auth.doctor, auth.status, or auth.reset-guard, nor does it mention alternatives explicitly, so the guidance is implied rather than explicit.

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