draft answer

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

The clause '只读无副作用' (read-only, no side effects) merely restates annotations that already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so it adds no new behavioral information. The description says nothing about what a draft answer looks like, whether generation is costly or slow, or whether drafts are persisted anywhere — the details an agent would actually need.

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?

A single tight sentence with the action front-loaded and zero filler. It is appropriately sized for what it conveys, though the brevity comes at the cost of the missing differentiation and output context noted elsewhere.

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 simple single-parameter read tool this covers the basics, but with no output schema the description should at least indicate what is returned (draft text, number of suggestions, whether it is inline or stored). The drafting-versus-answering boundary with minimax_answer_question is also left unresolved.

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?

With 100% schema description coverage on both parameters (including the note that id is an alias of requestId), the schema already carries the parameter semantics. The description contributes nothing about which identifier to supply or how to obtain a valid requestId, so baseline 3 applies.

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 gives a concrete verb and resource — generating draft answer suggestions for questionnaires awaiting answers — so an agent can understand the operation without opening the schema. However, it never distinguishes this from the sibling minimax_answer_question, which presumably submits an actual answer, leaving the boundary between drafting and answering 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 phrase '待回答问卷' (questionnaires awaiting answers) implies a usage condition, but there is no explicit when-to-use, no prerequisite such as first locating a pending requestId via minimax_pending, and no guidance on when to prefer this over actually answering. Usage is inferred rather than stated.

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