cx_s_submit_homework

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

With no annotations, the description carries the behavioral burden. It explicitly flags submit=true as '★高影响', states that the first call returns confirmToken, and requires a second call with the token plus identical parameters before the submission happens. It does not mention auth prerequisites or irreversibility in detail, but the core side-effect and confirmation mechanism are disclosed.

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 whole usage contract is delivered in one dense, well-ordered sentence: safe mode first, high-impact mode second, then the answers format. Every clause earns its place and the important warning is starred and front-loaded.

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?

Given a 5-parameter mutation tool with no annotations, the description covers the safety profile, the two-step confirmation, and the answer payload. An output schema exists, so return details are covered elsewhere; the main missing context is where courseRef and workUrl come from.

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 add parameter meaning, and it does: it explains the submit boolean's semantics and gives the exact answers array format [{stem, answer}]. The confirmToken flow is also described. However, courseRef and workUrl are left unexplained, which is a small but real gap.

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 description opens with '作业作答' (homework answering/submission) and then defines the two modes: submit=false is draft and submit=true is official submission. This gives a specific action on a specific resource and makes it clear why this tool exists alongside read-only siblings like list_homeworks and get_homework_detail.

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 clear context for when to use each mode: use submit=false for safe draft saving and submit=true for high-impact final submission, with a confirmation step. It does not explicitly name alternative tools or say when not to call this tool, 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.