Diagnose why answers are wrong by analyzing repeated wrong choices and explanations; classify misconceptions as concept confusion, trap-falling, or carelessness while flagging systematic errors.
錯誤類型診斷（不只正確率，要『為什麼錯』）：回傳每筆答錯題帶——你反覆選的錯選項＋正解 ＋逐項詳解＋該題錯幾次＋考點，並標『同考點群聚』。據此歸納誤解類型：①觀念混淆（把A當B） ②掉陷阱（選最誘人的錯選項）③粗心（偶發）。wrong_times≥2 或群聚＝系統性，優先補。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| q_type | No | mcq |
Changes observed during successful MCP inspections.
v0.6.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and is remarkably transparent. It discloses the returned fields, the same-knowledge-point clustering marker, the three misunderstanding categories, and the threshold for treating errors as systematic. There is no contradiction with annotations.
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 purpose is front-loaded in the opening parenthetical, and the rest is a dense but purposeful enumeration of output fields, classification categories, and a priority rule. Every clause adds relevant information with no filler or repetition.
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 tool with no output schema and no annotations, the description covers the return shape and interpretation logic well. It falls short only in omitting input-parameter semantics and explicit usage guidance, but the defaults and self-explanatory parameter names keep it reasonably complete.
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 needed to explain limit and q_type, but it mentions neither. An agent cannot tell that limit caps the number of wrong-question records or that q_type selects the question type; the input semantics are entirely undocumented beyond the bare schema.
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 clearly names the resource ('錯誤類型診斷' / error-type diagnosis) and the verb ('回傳'), and enumerates the returned fields: wrong option, correct answer, detailed explanation, wrong count, and knowledge point. It also distinguishes itself from accuracy-only views with '不只正確率，要『為什麼錯』', though it does not explicitly name a sibling alternative.
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 tool's context is implied: it diagnoses why wrong answers are wrong and provides interpretation rules such as 'wrong_times≥2 或群聚＝系統性，優先補'. However, it never states when to choose this tool over siblings like get_weak_topics or get_progress, and it gives no exclusions or explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.