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

With no annotations, the description carries the full disclosure burden. It usefully reveals that supplying termId triggers an actual authentication call rather than only a local check, but it does not describe return values, possible error states, or any side effects. This is adequate but leaves clear gaps for a tool with no output schema.

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 split by a semicolon, with the primary purpose front-loaded. Every clause earns its place by stating the local-check behavior and the termId-triggered auth behavior.

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?

The tool is simple and the parameter schema is fully documented, but there are no annotations and no output schema. The description explains the two checking modes reasonably well, yet it does not state what the tool returns or how validity is represented, which is a notable gap for a check operation.

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 termId parameter is already fully described in the schema as an optional semester/class id. The description adds meaningful behavioral semantics: when termId is provided, the tool calls the authentication interface for real verification. That is a useful distinction beyond the schema text.

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 action and resource: checking whether a locally saved session is valid. It also distinguishes the two modes: local-only check without termId, and actual authentication-interface verification when termId is supplied. It does not, however, differentiate this tool from nearby siblings such as mk_verify or mk_login_status.

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 two-mode behavior is clearly implied: pass termId to perform an actual auth verification, omit it to check only the local session. However, there is no explicit guidance on when to choose this tool over siblings like mk_verify or mk_login_status, and no exclusions or prerequisites are stated.

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 and does well: it discloses built-in ≥13s write throttling, rate-limit retry, deliberate wrong-answer behavior for quizzes, PDF byte download, and that discussion tasks return a list instead of executing. It omits idempotency/re-run semantics, auth prerequisites, and the fact that defaults (onlyUnfinished=true, dryRun=false) mean it will actually write.

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 paragraph, front-loaded with the action and then the per-type rules; nearly every clause carries operational information. Slightly cramped and mixes batch policy with execution timing details that could be split, but there is little 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?

There is no output schema, so the description should characterize what comes back; it only describes the discussion-list return case and is silent on what success/failure output looks like for videos, documents, and quizzes. For a batch mutation tool with throttling and retries, that leaves meaningful gaps around partial failures and re-run behavior.

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 33%, so the description must compensate. It does add real meaning for the ct codes (1/3/4/5/6) and for autoQuiz's simulated answering, but dryRun, onlyUnfinished, and includeUnpublished are documented nowhere, leaving three behaviorally important parameters unexplained.

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 ('批量完成任务点') and then enumerates the exact per-content-type behaviors (ct1 video, ct3 PDF download, ct4 rich text, ct5 quiz, ct6 discussion). This clearly distinguishes it from the single-item sibling mk_complete_unit and routes discussion work elsewhere.

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 says discussions are NOT auto-posted and that the agent must follow up with mk_discuss_reply at ~30s intervals, which is real when/how guidance tied to a named sibling. It doesn't state when to prefer this tool over mk_complete_unit (single unit) or how dryRun/onlyUnfinished should drive the decision, so it falls short of full when/when-not coverage.

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?

Annotations are absent, so the description must carry the full behavioral burden. It discloses the non-obvious completion logic per content type, which is genuinely valuable, but it omits permission/auth needs, whether the profile is idempotent, and failure behavior. Worse, it names a parameter `videoTime` that does not exist in the schema (which uses durationSeconds and sets additionalProperties:false), so an agent following it literally would fail validation.

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?

It is a single dense sentence with no filler, and the core purpose is stated upfront before the per-type rules. The heavy use of abbreviations (ct, 时长) and a compressed clause structure make it slightly terse, but it is still readable.

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 8 parameters (5 required), no annotations, and no output schema, the definition should say more. It never explains the identifier parameters, what a successful response looks like, or what to do when a required value is missing, and its `videoTime` naming error creates a real risk of a rejected 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 coverage is only 50%, so the description needs to fill the gap: it explains contentType codes (ct=1/3/4/6), that textPages can be auto-derived from contentId, and the video duration rule. But four of the eight parameters (termId, unitId, courseId, lessonId) receive no explanation, and the `videoTime` reference conflicts with the schema's durationSeconds and the explicit 50% coverage of the other parameters, so it only partly compensates.

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 specific verb and object: report that a single task point's learning is complete (上报一个任务点的学习完成). Combined with the title 'MK 完成单个任务点', an agent can easily distinguish this from mk_complete_course. However, it never explicitly names mk_complete_course as the whole-course alternative, so the differentiation is implied rather than stated.

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 per-type invocation guidance: for a video (ct=1), submit videoTime=duration+50 to reach 100%; for a document (ct=3), textPages is required unless a contentId is supplied, in which case the total is auto-fetched; for rich text or discussion (ct=4/6), completion happens simply by opening the item. No exclusion or when-not guidance relative to siblings is given, so it is not 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 carries the full load and does well: it discloses the side effect that only a real reply marks the discussion complete, the DWR transport, and an explicit anti-burst pacing expectation. It omits auth/prerequisite state (implied by the sibling login tools) and says nothing about the response or failure behavior.

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?

Front-loads the action, then layers constraints (content quality, completion semantics, pacing). Dense but well ordered; the pacing sentence is long but each clause carries real instruction.

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 4-parameter write tool with no annotations and no output schema, the description covers purpose, content requirements, side effects on discussion completion, and rate pacing. Missing only return-value expectations and the meaning of the anonymous flag.

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 75%, so postId, text and pauseBeforeMs are already described. The description reinforces text semantics (must be self-authored, on-topic) and clarifies pauseBeforeMs as an internal wait, but the 'anonymous' parameter is documented nowhere in schema or description. Baseline 3 fits given the schema does most of the work.

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: posting a reply inside a discussion unit, and even names the underlying endpoint (MocForumBean.addReply, DWR). No sibling tool shares this responsibility, so an agent can immediately tell this is the write action for discussion threads.

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?

Gives concrete usage rules: text must be authored by the agent and topic-relevant, no templates or placeholders, and batch posting should be paced with a self-managed sleep (30s±10s Gaussian) or via pauseBeforeMs. It does not name an alternative tool to use instead, but for a single-purpose write tool the guidance is clear and actionable.

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 behavioral burden. '获取' implies a read-only operation, and the description usefully discloses that the response includes unit type, completion status, and publish status. It does not state authentication requirements, error behavior, or whether the data is scoped to the current user, so meaningful gaps remain for a no-annotation tool.

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 front-loaded sentence with no waste: the hierarchy and included fields are stated immediately. Every element (chapters→lessons→units, type/completion/publish status) adds useful scope information.

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 one-parameter read tool with no output schema, the description adequately explains the shape of returned data and the hierarchy. It does not fully cover when to choose this over sibling listing tools, but the core behavior needed to invoke it correctly is present.

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 100% and the single required termId parameter is already documented in the schema as '学期 id(tid)'. The description adds no parameter meaning beyond the schema, so the baseline of 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?

States a specific verb and resource: 获取课程完整结构, and spells out the nested hierarchy chapters→lessons→units with included fields (类型/完成度/发布状态). It is clearly a structural fetch rather than a flat list, which distinguishes it from siblings like mk_list_courses and mk_list_units, though it does not name those siblings explicitly.

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 implied by '完整结构' as opposed to a flat listing, so an agent can infer this is for getting the full course tree. However, the description never explicitly says when to prefer this over mk_list_courses, mk_list_units, or other course tools, and it gives no exclusions or prerequisites.

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 at all, the description carries the full burden, and it does disclose one genuinely non-obvious behavior: the server DTO ships correct answers via option.answer=true and stdAnswer. It says nothing about auth requirements (the mk_login_* siblings imply a session is needed), failure modes for bad unitId/contentId, or whether the paper can be fetched repeatedly.

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 front-loaded sentence with the return payload spelled out immediately; no filler. Slightly dense with DTO/option.answer jargon, but every clause carries information an agent needs.

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 2-required-parameter read tool with no annotations and no output schema, the description covers the return payload well but leaves the parameter contract under-explained (unitId's meaning and its relation to contentId) and omits any auth or error context. Adequate to start a call, not sufficient to call 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 description never mentions unitId or contentId, so it adds zero meaning beyond the schema. Coverage is only 50% — contentId carries a note tying it to the tid, but unitId is completely undocumented in both schema and description, and the description does nothing to close that 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?

States a specific verb and resource ('取随堂测验/考试试卷') and goes further by enumerating what comes back (题目、选项、正确答案), which separates it in practice from the write-side sibling mk_submit_quiz. It never names a sibling or explicitly contrasts with one, so it stays short of a 5.

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 trailing clause '可据此满分作答' implies this is the step before answering/submitting, but there is no explicit when-to-use, no statement that it is read-only and safe to call repeatedly, and no pointer to mk_submit_quiz as the follow-up action. Usage is inferable rather than stated.

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 burden. '列出' implies a read-only operation and the returned fields are named, but it does not state whether the list is truncated, how 'recent' is defined or ordered, or whether authentication via mk_login is required — gaps that matter for a discovery tool consuming an account-scoped list.

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 zero waste: the first defines the resource and its fields, the second immediately explains how its output feeds the rest of the toolset. Front-loaded and appropriately sized for a no-argument listing tool.

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 compensates by enumerating the key returned fields and explaining downstream tid consumption. Minor gaps remain around truncation/pagination and how 'recent' is bounded, but nothing essential for correct invocation is missing.

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 tool takes zero parameters, so the baseline is 4. The description adds no parameter detail (none exists to add), but it does clarify that the tid values needed by other tools are sourced from this call's output, which is useful semantic context around usage rather than input.

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 and resource ('列出当前账号最近学习的课程') plus the exact fields returned (termId/教师/学校/起止时间/发布状态), which distinguishes it from mk_get_course, the single-course lookup sibling. An agent can tell this is the discovery/enumeration step.

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 when to call it — to obtain the tid that other tools require — and provides a fallback source (the tid in a course page URL) when the target course is absent from the list. It lacks a clear 'when not to use' statement or comparison against other listing siblings, but the workflow guidance is concrete.

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, so the description carries the full burden. It does not disclose that onlyPublished defaults to true (silently hiding unpublished units), the default for onlyUnfinished, whether login/auth is required, or what the returned items contain — all material for interpreting results.

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 purpose front-loaded and the enum table appended, no filler. The enum listing is terse but every token carries information.

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 annotations, no output schema, and 0% schema description coverage, the description should explain at least how onlyPublished/onlyUnfinished behave and what a returned task point looks like. It only covers purpose and the contentType enum, leaving half the surface undocumented.

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 0%, and the description compensates for contentType by enumerating its allowed values (1/3/4/5/6) and loosely maps '完成度' to onlyUnfinished. However termId and the onlyPublished default (true) remain completely undocumented.

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: lists all course 任务点 with optional filtering by type/completion. An agent can distinguish it from mk_get_course (single course detail) and mk_list_courses (course list). Lacks explicit sibling differentiation but the scope 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?

Implies when to use it — when you need the unit/task list for a course, optionally filtered — but never states prerequisites (e.g. must be logged in, termId must come from mk_list_courses) or when to prefer mk_get_course / mk_complete_unit instead.

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 must carry the full burden of behavioral disclosure. It does disclose the two effects (the browser closes and the pending flow is cancelled), but it omits error behavior when no login is in progress, idempotency, and whether any server-side session state persists. The tool's name and the verbs 'cancel' and '关闭' do signal that it changes state, but it does not spell out what happens when there is nothing to cancel.

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?

It is a single sentence with no wasted words, and it front-loads the action: closing the browser comes before cancelling the flow.

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 zero-parameter lifecycle tool, the description covers the core action and its two effects. Minor gaps remain: no stated behavior when no login is active and no confirmation of what happens to the session state afterward, though no output schema exists to carry that information.

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 tool takes zero parameters, so there are no parameter semantics to document; the baseline for a zero-parameter tool is 4.

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: it closes the login browser and cancels an in-progress login flow. That is clearly distinct from the sibling tools mk_login_start, mk_login_status and mk_check_login, but the description never names those siblings or explains how it relates to them.

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 'cancel the in-progress login flow' implies when to use the tool, namely to abort a login. However, it gives no explicit conditions, no preconditions (for example, 'only call while mk_login_status reports pending'), and no exclusions.

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 and does well: it discloses the async/non-blocking contract, that a human must complete the login in a local browser, that HttpOnly cookies and UA are persisted, and that polling is bounded by the timeout. It omits prerequisites such as needing a desktop GUI browser and whether existing saved credentials are overwritten.

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, each earning its place: what happens, what the side effect is, and how to retrieve the outcome. The immediate-return caveat is front-loaded before the side-effect detail.

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?

No output schema exists, yet the description explains that the call returns immediately and that the result must be fetched via mk_login_status, which is the key information an agent needs. It could go slightly further by stating what the immediate return value contains.

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 100%, so both termId (the success-criterion assertion) and timeoutSeconds are already documented in the schema. The description adds no further meaning about how termId is used or how timeoutSeconds relates to the immediate-return contract, 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?

States a specific action (launch local Chrome/Edge to the icourse163.org login page for manual user login) and the concrete side effect (capture all cookies including HttpOnly plus the browser UA to disk). It is clearly distinguishable from the polling siblings, naming mk_login_status directly.

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 says the call returns immediately and that mk_login_status is the way to poll for the result, which routes the agent to the right sibling. It does not cover the alternative case (e.g., checking an existing session with mk_check_login/mk_verify before starting a new login) or what happens if a login is already in progress.

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 discloses the state machine (idle/running/success/failed/timeout/cancelled) and the key operator behavior (prompt the user to finish captcha/scan in the popup browser), which is genuinely useful. It does not say the call is read-only/non-mutating, whether polling is rate-limited, or what an agent should do on timeout/failed.

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, zero waste: the first front-loads what is queried and the full result vocabulary, the second gives the one action the agent must take. Nothing is repeated or 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?

No output schema exists, and the description compensates by enumerating the status values as the return vocabulary, which is the essential missing piece. It is nearly complete for a trivial no-arg read, minus guidance on failure/timeout handling and polling cadence.

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?

Zero parameters, so there is no parameter semantics to explain and the baseline is 4. The description correctly spends no words on inputs.

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 (查询) and resource (浏览器登录流程状态) and enumerates the possible state values, so an agent knows exactly what it returns. However, it never distinguishes itself from the sibling mk_check_login, which by name appears to cover overlapping ground.

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: 'running 时提示用户…' tells the agent what to do once a run is in flight, which suggests this is a polling tool used after mk_login_start. There is no explicit when-to-use/when-not, no mention of how it relates to mk_check_login or mk_login_cancel.

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 does well: it reveals the deliberate side effect of injecting wrong answers (~25%, 1-3 questions), that real timestamps are written to the answer sheet, and that pacing is scaled to fit sessionSeconds. It doesn't state irreversibility of the submission, required auth, or rate limits, which keeps it from a 5.

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 dense paragraph that front-loads the action sequence before the timing knob, and every clause carries information. It is tight but packed with parenthetical detail, which makes it slightly harder to scan than an ideal definition.

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 mutation tool with no annotations and no output schema, the description covers the sequence, the intentional-wrong-answer behavior, and the timeout constraint. What's missing is what the caller gets back on success/failure and whether a submission can be re-run or undone, but the core behavior is adequately conveyed.

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 75%, so most parameters are documented. The description still adds value: it clarifies that sessionSeconds compresses the whole session while preserving relative pacing ratios – semantics beyond the plain min/max in the schema – and reinforces wrongCount's auto/25% behavior. unitId remains unaddressed in both places.

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 action chain: write an 'open quiz' study record, answer each question at a realistic pace with real timestamps, deliberately miss some questions, then submit. This is concrete enough for an agent to know exactly what the tool does. It doesn't explicitly contrast itself with a sibling (e.g. mk_get_quiz, which presumably fetches the paper first), so it stops short of a 5.

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 agent must infer that this is called after the quiz is known (likely after mk_get_quiz) and that sessionSeconds exists to fit MCP timeouts. There are no explicit when/when-not statements or named alternatives among the many mk_* siblings. The timeout-adaptation note is the only real usage context provided.

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 does disclose meaningful behavior: a fresh fetch (not cached) and a return shape with per-task completePercent plus a separately-listed incomplete subset. However, it says nothing about read-only nature, auth/permission requirements, or how the learning tree is scoped.

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 front-loaded sentence with no filler; the output contract is stated up front and the parenthetical clarifies the incomplete-item handling without padding.

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 annotations and no output schema, the description does a fair job of sketching the return value (completePercent per task plus a summary), but it leaves the sole required parameter and the tool's prerequisites unexplained, so an agent still cannot confidently construct the 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?

There is exactly one parameter (termId) with 0% schema description coverage, and the description never mentions it or explains what a term ID is, where it comes from, or whether it accepts string or number. The only parameter is therefore undocumented in both structured and natural-language form.

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+resource: re-fetch the learning tree and emit each task point's completePercent plus a summary, with sub-1 items listed separately. This distinguishes it from mutation siblings like mk_complete_unit, but it never names a sibling or explicitly contrasts itself with the list_* tools, which is the main gap.

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 by '重新拉取' (re-fetch) – an agent can infer this is a post-completion verification call, but there is no explicit 'use this after X' or 'do not use for Y' statement, and no alternative tool is named.

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