submit_explanation

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

With no annotations, the description carries the full behavioral burden and does substantial work: the engine verbatim-verifies the locating sentence and the passage side of synonym pairs and rejects (退回) non-verbatim content, uncertainty is mandatory when evidence is '证据不完整', explanations cannot contradict the answer book, and rule-determined/user-confirmed causes will not be overwritten. What is missing is what a successful call returns or how rejection feedback is surfaced, but the mutation/validation profile itself is well 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?

One dense but front-loaded block: purpose first, then the pedagogical sequence, then engine validation rules. Every sentence carries information; no filler. Density is high enough that the workflow and the hard constraints are somewhat fused together, which slightly hurts scannability.

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 16-param, no-output-schema tool, the description conveys the required content model, the validation rules that will reject a submission, and the precedence rules over existing causes. Gaps remain around review_id/number semantics and the result of a rejected submission, but an agent can construct a valid call from this description alone.

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 50% across 16 params. The description adds real meaning for a few: cause selection is restricted to judge_set's causes, uncertainty becomes mandatory when any synonym has '证据不完整' evidence, and the step narrative implicitly maps to stem_reading, locate_route, sentence_breakdown, and from_your_view. Many remaining params (review_id, number, confidence, vocab, advice, method_tip, why_user_wrong) are only covered by short schema descriptions or not at all, so it does not fully compensate for the coverage 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?

Opens with a specific verb+resource ('提交一道题的讲解'), then enumerates the four-part pedagogical structure the explanation must follow (题干 → 定位 → 拆句 → 用户错因). An agent knows exactly what artifact this tool submits. It does not explicitly contrast with siblings like judge_set or set_cause, though it implicitly references them ("judge_set 返回的 causes", "method 工具").

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 description implies when to use it (after diagnosing a question, when producing a per-question explanation) and encodes constraints (cause must come from the fixed table, cannot overturn the answer book), but never states when NOT to use it or names alternatives. Usage is inferable rather than specified.

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