yimu-mcp

login_qr_poll

login_qr_poll

Polls QR login status every 3 seconds until the user scans or the timeout expires, then returns success with user details when authentication completes.

Instructions

等待/轮询扫码登录结果（免鉴权）。timeout 秒内每 3 秒查询一次，用户扫码后返回 status=success 与用户对象（JWT 仅保留在当前进程内部）；timeout=0 只查一次。默认 120 秒。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "session_id": "<session_id>"
    },
    "name": "login_qr_poll"
  }
}

Input Schema

Name	Required	Description	Default
`timeout`	No	等待秒数，0=只查一次；默认 120
`session_id`	Yes	login_qr_start 返回的 session_id

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.2Sep 15, 2026

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries the full disclosure burden and does well: it states polling every 3 seconds, default 120 seconds, timeout=0 as a single check, auth exemption, and that the JWT is kept only inside the current process. It does not describe non-success or timeout return states, but the core runtime behavior is well disclosed.

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

Conciseness5/5

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

The description is a single dense sentence that front-loads the action, then covers timeout behavior and return/JWT handling without filler. Every clause contributes operational information.

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

Completeness4/5

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

For a two-parameter auth-polling tool with no output schema, the description supplies enough context to invoke it correctly: polling cadence, timeout semantics, auth exemption, and partial return shape. It could be stronger by explaining pending/expired states, but the essential context is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents both parameters. The description adds useful meaning beyond schema, especially the 3-second polling interval and the default 120-second timeout behavior, while session_id semantics are covered by the schema.

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

Purpose4/5

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

The description states a specific verb+resource: waiting/polling for QR-code login results, and notes it is auth-exempt. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as login_qr_start or auth_status within the description.

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

Usage Guidelines3/5

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

Usage is implied by '等待/轮询扫码登录结果' and by timeout semantics, but the description never explicitly says to call this after login_qr_start or when to prefer it over auth_status or login_email. The timeout behavior is documented, but alternative selection is left to inference.

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