login_qimaoOpens a real browser window so you can log in to Qimao via QR code or SMS code, then saves the session cookies for later use without handling your password.
打开真实浏览器窗口，你在窗口里扫码/短信验证码完成登录，服务只轮询登录态并保存 cookies。全程不接触账号密码。
| Name | Required | Description | Default |
|---|---|---|---|
| timeout_seconds | No | 等待登录的超时秒数，默认 300 |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses that a real browser window opens, that the human performs the verification, that the service only polls login state and persists cookies, and that credentials are never handled. It omits failure/timeout behavior and whether saved cookies persist across later calls.
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 tightly packed sentences with no filler; the mechanism and the credential-safety guarantee are both front-loaded and each clause 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?
For a single-parameter tool with no output schema and no annotations, the description covers the interaction model and security posture adequately. It could say more about what happens when the timeout expires or what the tool returns on success/failure.
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?
Only one parameter (timeout_seconds) and schema description coverage is 100%, so the schema fully documents it. The description adds nothing about the timeout semantics, so the baseline 3 applies.
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?
States a specific verb and resource (login to the Qimao author backend) and explains the mechanism: a real browser window where the user completes QR/SMS verification. This implicitly separates it from set_qimao_cookies, but no sibling is named explicitly.
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?
Usage is only implied – the agent can infer this is the tool to call when credentials/cookies are needed, but the description never says when to prefer it over set_qimao_cookies or what to do on timeout. No explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.