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

With no annotations, the description carries the full burden. It does disclose the meaningful behavioral distinction that only_active=True returns only unfinished sets while False returns all visible sets, but says nothing about permissions, pagination, or result size beyond limit.

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?

Front-loaded purpose sentence followed by two terse parameter notes; no filler. The embedded 'Args:' block is slightly awkward for a prose description but costs almost nothing in length.

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 two-parameter, zero-required listing tool with no output schema, the description covers purpose, both parameters, and the reason the caller needs the result. What an agent would still miss is the shape of the returned items (fields besides exam_id) and total-count/pagination behavior.

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 coverage is 0%, so the description must compensate. It explains only_active's effect well (not just the default but what each value returns) and glosses limit as 条数上限, but omits the default of 20 and any pagination/cursor behavior, leaving half the parameter semantics thin.

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 first sentence names a specific verb and resource (列出练习/考试) and states the concrete payoff: the exam_id needed for submission, which links it to submit_answers. It does not explicitly contrast itself with pull_exam_set, so sibling differentiation is only implicit.

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 link to submission (给出提交时要用的 exam_id) implies this is a discovery step before submit_answers, and the only_active default is stated. However, it never says when to prefer pull_exam_set over this tool, nor any prerequisites such as login (pta_login is a sibling).

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

Does 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.

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

With no annotations, the description must carry the full behavioral burden: '查看' implies a read-only operation and the return contents are described. But it says nothing about authentication/permission requirements, whether results are final or may still be grading, or any rate limits.

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?

It is front-loaded: a one-line summary of what is retrieved, followed by a compact Args list. No filler; only minor gain from stating defaults or limits.

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?

No output schema exists, and the description steps in by enumerating the returned fields and dimensions. Together with full parameter coverage it is nearly sufficient; only operational details such as grading readiness or auth are missing.

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%, yet the description documents all three parameters: exam_id, the source of submission_id, and max_text as the truncation length for failing output. This meaningfully compensates for the empty schema, though formats (e.g., exam_id syntax) and max_text bounds/default are not stated.

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 first sentence gives a specific verb and resource ('查看某次提交的判题结果') and enumerates exactly what is returned: overall status/score, per-case results, and truncated output for failing cases. It is clearly distinguishable from siblings like submit_answers or pta_list_exams.

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?

By noting that submission_id comes from submit_answers, the definition implies the intended workflow: submit first, then inspect results. It gives no guidance on when not to call it, when results are ready, or what to do instead if grading is still pending.

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

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

With no annotations present, the description carries the full burden, and it does disclose important failure behavior (a mismatch with summaries raises an error instead of returning incomplete data) plus pagination (limit=0 means all) and truncation via max_content_chars. It does not state whether the call is read-only, whether it requires an active pta_login session, or anything about rate limits, which matters for an unannotated 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 scoping and error-guarantee sentence is front-loaded, then a tight Args list. Every line carries information, though the overall block is longer than strictly needed and could fold offset/limit into a single line.

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, no-annotation, no-output-schema tool, the description covers what each mode returns (id/type/title vs. stem with the first line as title), paging, truncation, and the failure mode. The only material gap is the absent authentication/session prerequisite and confirmation that the operation is non-destructive.

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 entirely, and it does: every one of the six parameters is explained, including the three undocumented mode values with their distinct return content, the limit=0 sentinel, the digest-specific 15–30 recommendation, and the default-ish role of max_content_chars.

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 states a specific verb+resource: fetch problems from an exam set filtered by problem type, with a summaries cross-check that errors out rather than returning partial data. It is clearly distinguishable from pta_list_exams (which supplies the problem_set_id) and from submit_answers, though it never names a sibling outright.

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 gives concrete selection guidance: problem_set_id comes from pta_list_exams, and mode is explained as a choice with explicit consequences (index = overview, digest = stem only, content = longer stem). It also recommends limit 15–30 for digest. What's missing is any statement of when not to use this tool versus submit_answers or pta_submission_detail.

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

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

With no annotations, the description carries the full burden and does well: it discloses that dry_run=True returns only a submission plan (a safe preview), that programming submissions return judge results, and that answers_file avoids re-pasting large JSON. It does not cover failure modes, resubmission/overwrite semantics, or auth requirements, which keeps it from a 5.

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?

Front-loads the submit semantics, then args, then payload examples — a sensible order with little waste. The example blocks are justified by the 0% schema coverage, though 'answers: 上述结构（或它们的列表）' partially repeats the opening sentence.

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 4-parameter mutation tool with no annotations and no output schema, the description covers invocation, payload construction, and the dry-run confirmation loop. It leaves the shape of the dry-run plan and the returned judge results implicit, which the missing output schema makes a real gap.

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: all four parameters are explained, including the exact per-problem-type JSON shape with worked examples, the list-vs-object distinction for answers, the answers_file path convention and its equivalence to answers, and dry_run's default and effect.

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 ('提交答案') and immediately splits the behavior into two concrete modes: whole-exam submission for objective question types versus per-problem submission with judge-result feedback for programming questions. An agent can tell this apart from the sibling list/detail tools without opening any schema.

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?

Gives actionable routing context: exam_id is sourced from pta_list_exams, large payloads should use answers_file under work/ instead of pasting JSON into the conversation, and dry_run defaults to True so the agent previews a plan before confirming with False. It stops short of stating exclusions (e.g. when not to resubmit or how this relates to pta_submission_detail), so not a 5.

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