pta_submission_detail

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.