Logs into the Pintia practice and exam platform using email/phone and password, persists the session for reuse, and automatically solves slider CAPTCHA.
登录并持久化会话；已有有效会话时直接复用。滑块验证码由纯协议求解器自动通过。
Args: email: 邮箱（与 phone 二选一，也可用环境变量 PTA_EMAIL）。 password: 密码（也可用环境变量 PTA_PASSWORD）。 phone: 手机号，不含 +86。 remember: 是否"记住我"。 max_captcha: 验证码重试轮数，默认 2；站点风控严格时调大无益。 pace: 轮次间退避秒数。
| Name | Required | Description | Default |
|---|---|---|---|
| pace | No | ||
| No | |||
| phone | No | ||
| password | No | ||
| remember | No | ||
| max_captcha | No |
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 full burden and does substantial work: it discloses that the session is persisted, that the slider captcha is solved automatically by a protocol solver, and that raising max_captcha is futile under strict site risk control. It does not describe what a failed login looks like or how errors surface, leaving one meaningful gap for a credential-handling mutation tool.
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 behavioral summary is front-loaded in a single sentence, and the Args block is terse with no filler. The docstring-style parameter listing is efficient, though it duplicates parameter names rather than grouping the mutual-exclusivity rule more compactly.
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 six-parameter authentication tool with no annotations and no output schema, the description covers inputs and key behavior well but never states what a successful call yields (session token, user object, persisted file location) or how failure is reported. That leaves the agent guessing about the return contract.
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, and it does for all six parameters: email/phone mutual exclusivity, phone without the +86 prefix, env-var fallbacks for email and password, remember-me semantics, max_captcha's default of 2 plus advice not to raise it, and pace as inter-round backoff seconds. This is richer than the schema's bare titles and defaults.
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 opening sentence names a specific verb and resource ('登录') plus the resulting state change ('持久化会话'), and adds a distinguishing behavior: an existing valid session is reused rather than re-authenticated. It is unmistakable against siblings like pta_list_exams and submit_answers, which are unrelated exam operations.
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 tells the agent when authentication can be skipped ('已有有效会话时直接复用'), and the Args section clarifies the email-or-phone alternative along with environment-variable fallbacks, so most invocation prerequisites are stated. There is no explicit when-not or failure-recovery guidance, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.