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

With no annotations, the description carries the full burden, and it delivers meaningful behavior: the engine validates number continuity, legal tags, and answer-key consistency, and rejects bad input ("有问题会退回"). It also discloses that web-sourced keys get flagged as "未核对答案册" in results. It stops short of describing idempotency (what happens when the same source is ingested twice) or the shape of rejection feedback.

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 simplest call shape is front-loaded, then progressively richer alternatives follow, which matches how an agent should decide. Sentences are dense but each carries a distinct fact; the middle clause about web lookup and *_origin flags is the only slightly tangled segment.

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 13-parameter, nested, mutation-style ingestion tool with no annotations and no output schema, the description covers what an agent needs before calling: which combinations of inputs are valid, the validation-and-rejection contract, the provenance labeling, and the no-grading boundary. Minor parameters like reflections and elapsed_minutes are self-described in the schema and don't block correct invocation.

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 already 77%, so the baseline is high, yet the description still adds value: it shows the literal answer_sheet format with a worked example ("1 FALSE NG / 2 two weeks | two week / 3 B ✓") that the schema does not spell out, and it explains that questions_text propagates instruction/word-limit lines to subsequent questions. The remaining parameters (reflections, elapsed_minutes, answer_line vs user_answers) are left to the 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 opening sentence gives a specific verb and resource ("录入一篇阅读或一个听力 Part" — ingest a reading passage or listening Part). The closing "不判题" (does not grade) implicitly separates it from judge_set, but no sibling is named outright, so the differentiation is by implication rather than explicit.

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 enumerates the input pathways and the condition that selects each: source + answer_sheet is called the easiest path, questions_text and passage are optional add-ons, structured questions are an alternative, and set_id is the reuse path when the set already exists. It also specifies the condition for the web fallback ("用户没给原文/答案时"), so an agent can choose a route without guessing.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses that judging is deterministic and rule-bounded and that only rule-attributable error causes are returned, but says nothing about whether the result is persisted, whether the call is idempotent, or what happens if the passage was not ingested.

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?

Three short sentences, front-loaded with the purpose and followed by the routing instruction and the return summary. No filler, though '一整篇' and the parenthetical rule list are a little compressed.

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?

Without annotations or an output schema, the description does sketch the return (per-question results plus rule-determinable causes), but it leaves the sole input undocumented and the mutation semantics unclear, which is thin for a scoring/judging tool.

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?

There is one required parameter, review_id, with 0% schema description coverage, and the description never mentions it or explains where the id comes from. With schema coverage this low the description needed to compensate and does not.

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?

States a specific verb (judge) and scope (an entire passage/set) plus the rule categories applied: word count, singular/plural, spelling, and true/false label conventions. The line '对错只能由这里判' implicitly distinguishes it from siblings like submit_explanation or set_cause, though no sibling is named.

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?

Explicitly tells the agent to use this tool rather than judging correctness itself ('不要自己判'), which is a real routing directive. It does not state prerequisites such as whether the review must be ingested first or whether re-judging is allowed.

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

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

With no annotations, the description still discloses useful behavior: deduplication by book/passage, the role of set_id in redoing a set, and the instruction to submit only current answers. It does not cover read-only safety, permissions, return format, or filtering behavior, leaving meaningful gaps for a tool with no annotation support.

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 description is a single compact sentence with the main purpose front-loaded and no obvious filler. It is slightly dense because it mixes listing scope with downstream ingest_passage workflow, but it remains efficient.

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 low-complexity listing tool with no output schema and no annotations, the description covers the core purpose and redo flow adequately. It omits any explanation of the module parameter and does not describe the shape of the returned list beyond implying that set_id is available.

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?

The schema has 0% description coverage and defines a single optional module enum, but the description never mentions module or explains whether it filters the listed sets. The enum values reading/listening are somewhat self-explanatory, but the description does not compensate for the missing schema documentation.

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 states a specific verb and resource: listing already-recorded question sets, with the uniqueness rule that the same book and passage are recorded only once. It also relates the output to ingest_passage for redoing a set, which helps distinguish the workflow, though it does not explicitly contrast list_sets with any sibling listing tool.

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 a clear redo workflow: pass set_id to ingest_passage and fill in only this attempt's answers. However, it does not explicitly say when to use list_sets versus alternatives, nor does it state exclusions or prerequisites for calling it.

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

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

With no annotations, the description carries the full disclosure burden, and it does deliver the key behavioral fact: the call mutates scheduling state, and the engine uses the grade to compute the next review date. It does not say whether regrading overwrites a prior result, whether the item must still be due, or what the response contains.

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 tight sentence: action and target first, grade vocabulary in a compact inline list, consequence last. Nothing is redundant and nothing is padded.

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 two-parameter grading tool, the description covers the whole loop: due item from `today` → grade → rescheduling by the engine. The main gap is return behavior — with no output schema, an agent is not told whether the next review date comes back in the response.

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%: `key` is documented in the schema as 'the key returned by today', and `grade` is an enum with no per-value description. The description partly compensates by glossing `again` as '又错了' and stating that the grade drives the next review date, but `hard`/`good`/`easy` remain unglossed.

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?

States a specific verb+resource: records the redo grade of a *due* wrong-answer item, and names the four accepted grades. The 'due' qualifier plus the schema note tying `key` to `today`'s output makes the relationship with the `today` sibling inferable, though it is not stated outright.

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?

Usage is only implied: it should be called after redoing an item that `today` surfaced. There is no explicit when-not guidance (e.g. what happens if the key is not due, or whether it can be re-called to overwrite a grade), and no sibling is named as an alternative.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies mutation ('保存用户改过的版本', '设为当前') but never says whether save overwrites an existing method, whether 'use' persists as a durable current setting, or what is returned. For a read/write tool with zero annotation coverage, this is a significant gap.

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?

Three short clauses, front-loaded with what the resource is, then when to read it, then what actions exist. Every sentence carries information. Slightly dense and mixes workflow advice with capability listing, but no waste.

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?

With no output schema, the description should indicate what get/list/use return, and it does not. It also leaves the module/method_id parameters and save semantics underspecified. Adequate for a small 4-parameter tool, but noticeable gaps remain.

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 only 25%, so the description needs to compensate. It loosely maps to the action enum (查看≈get/list, 设为当前≈use, 保存≈save), and the nested method object is described in the schema. However, 'module' (reading/listening) and 'method_id' are unexplained in both places, leaving real ambiguity.

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 names a specific resource (the user's 做题方法, e.g. 平行阅读法) and enumerates the supported operations: 查看、设为当前、保存用户改过的版本. That is enough to tell it apart from siblings like weakness or report, which concern different resources. The name 'method' alone is ambiguous, but the description resolves it.

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 concrete usage context: read it before 复盘 and follow the user's method when explaining questions ('下次在哪一步怎么做'). That is a clear when-to-use signal. It does not state when to prefer one action over another (get vs list vs use) or any exclusions, so it falls 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.

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

With no annotations, the description does useful work by disclosing the output format (Markdown, directly copyable) and the fact that result quality depends on how complete the submitted explanations are. It does not mention read-only nature, failure modes for a missing review, or what happens when no explanation has been submitted.

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?

Two compact sentences with the deliverable front-loaded and the quality caveat second; no wasted text. Slight compression cost: the verb and input are omitted entirely.

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?

Since there is no output schema, it is good that the description explains the return shape (three named tables in Markdown). However, the required input is unexplained and no preconditions (e.g., explanations must have been submitted) are stated explicitly, leaving gaps for a one-parameter generation tool.

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% and the single required parameter review_id is never mentioned in the description. The agent must infer from the schema alone that a review identifier is required and where to obtain it.

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 states concretely what the tool produces: three Markdown tables (error table, synonym-substitution table, difficult word/phrase table) that the user can copy. The generating action and use of review_id are only implied, and it does not explicitly distinguish itself from siblings like submit_explanation or weakness, but the resource is clear.

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 sentence '讲解提交得越完整，表越全' implies a dependency on prior submit_explanation calls and that this tool should be used after explanations exist, but it never states explicitly when to call this versus alternatives such as weakness or method.

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

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

With no annotations, the description carries the full burden. It does disclose a genuinely useful behavioral trait: the user-set cause takes precedence over model suggestions and future model explanations will not override it, which signals persistence. It omits whether an existing cause is overwritten, who is permitted to set it, and what is returned.

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?

Two short sentences with no filler, and the precedence rule is stated up front. It is appropriately sized for what it covers, though the lack of any parameter or scope statement means the brevity borders on under-specification.

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?

A mutation tool with no annotations, no output schema, and 0% schema description coverage needs more than this. The description never covers input meanings, overwrite behavior, or error conditions, so an agent cannot fully predict the effect of a call.

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% and four parameters exist, so the description must compensate. It only conveys the concept of 'cause' and never explains review_id, number, or the optional reflection field, leaving half the inputs semantically opaque.

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 states a specific verb and resource: confirm or modify the cause of an error for a wrong question (错题的错因), tied to a review item. It is clear enough to act on, but it doesn't differentiate itself from siblings like judge_set or mark_reviewed, which an agent would have to inspect separately.

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?

Usage is only implied: the tool is for when a user confirms or corrects a cause. There is no statement of when to call this versus judge_set or submit_explanation, and no prerequisites (e.g., must the review exist, must a model suggestion already be present). 'User's choice takes priority' hints at a conflict-resolution context but isn't a routing rule.

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

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.

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

With no annotations, the description carries the behavioral burden, and it does disclose a meaningful trait: returned items deliberately withhold answers and supply only question plus location scope, ordered by due date and recurrence. It does not say whether the tool mutates review state (a separate 'mark_reviewed' sibling exists) or what the response looks like.

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 sentence with the core purpose front-loaded, followed by the two content categories. The parenthetical instruction is operational and earns its place; nothing is padded.

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 read-only recommendation tool with no output schema and no annotations, the description conveys the conceptual shape of the result (due wrong items + targeted practice for top error causes) but leaves the response structure and the one parameter undocumented. Adequate but with clear gaps.

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?

The single 'limit' parameter has 0% schema description coverage, and the description never mentions it — an agent cannot tell whether it caps number of due items, error causes, or days. The schema's min/max gives bounds but no meaning.

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 vague name 'today' is rescued by the description: it returns what is most worth re-practicing today, drawn from spaced-repetition due items (1/3/7/14/30-day intervals) plus the error causes with the highest recurrence. That is a specific resource and selection rule. It does not, however, distinguish itself from siblings like 'weakness' or 'method', which sound related.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no sibling is named as an alternative (e.g., versus 'weakness' or 'list_sets'). The parenthetical 'give only the question and location scope, not the answer' is presentation guidance for the consumer, not a condition for choosing this tool.

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

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

No annotations are provided, so the description carries the full disclosure burden, yet it never states that this is a read-only/derived calculation, whether it queries across all modules or requires prior data, or what the response looks like. It does helpfully define the non-obvious north-star metric ('同类错误复发率'), which is real added context, but the operational profile is unstated.

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?

Two front-loaded sentences: the profile contents first, the metric definition second. The parenthetical definition is somewhat long but earns its place because the recurrence-rate metric is not self-evident.

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?

With no output schema and no annotations, the description adequately conveys the analytical content returned but leaves the module-parameter behavior and the response shape (e.g., per-cause breakdown format) undocumented. It is viable but incomplete for an agent needing to call it confidently.

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?

The single `module` parameter (enum reading|listening, optional) is never mentioned in the description, and schema coverage is 0%, so an agent cannot tell what happens if `module` is omitted (aggregate across both? default?). For a one-param tool the schema is trivial, but the description squanders the chance to explain scope selection.

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 identifies this as a weakness-profile analytic output, naming the specific contents: error-cause counts, most-frequent wrong question type, and a recurrence-rate metric. It is distinguishable from operational siblings like ingest_passage or set_cause, though it does not explicitly separate itself from the similarly analytical `report` and `today`.

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?

There is no guidance on when to call this versus `report` or `today`, nor any mention of prerequisites such as whether data must exist first. The agent must infer usage purely from the noun '弱点画像'.

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