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

With no annotations, the description carries the full burden. It does add real value by disclosing the output structure (three feedback dimensions plus a suggested score) and by framing the result as a '草稿' (draft), implying nothing is committed. However, it never states whether the suggested score is persisted, whether the call mutates any submission record, or anything about latency, cost, or the reliability of AI-generated judgement.

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 compact sentence bracketed by a tag, front-loading both the input contract and the deliverables. Every clause earns its place; the only minor cost is the marketing-flavored tail about reducing TA workload, which adds tone rather than 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?

There is no output schema, and the description compensates by enumerating what the response contains (three-part feedback and a suggested score), which is exactly what an agent needs to chain it with a grading write step. Combined with fully documented parameters, the definition is nearly complete; only the side-effect question (does it store anything?) is left open.

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%, with each of the four properties documented, so the baseline is 3. The description names the same four inputs (題目、滿分、學生作答內容與參考擬答), effectively restating the schema rather than adding semantics such as how referenceAnswer influences scoring or what happens when it is omitted (it is the only non-required parameter).

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: given question, max score, student answer and reference answer, the AI produces a constructive grading-comment draft (praise, blind spots, improvement suggestions) plus a suggested score. The operation and its output shape are unmistakable. It does not distinguish itself from nearby siblings such as audit_essay_question or ai_generate_homework_assignment, so it falls 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 phrase '大幅減輕助教人工批改負擔' implies the TA-grading context, so when to use it is inferable, but there is no explicit condition, prerequisite, or named alternative (e.g. calling audit_essay_question first, or whether a submission must already exist). Guidance exists only by implication.

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 the generated structure (warm opening, key-point list, important reminders, TA contact info) and that the result can be published immediately or saved as a draft — a real side effect. It does not state permission requirements, whether publishing is reversible, or what exactly 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?

A single front-loaded sentence with the AI-writing purpose first and the structural detail in a parenthetical. Dense but not padded; the bracketed tag and exclamation mark are cosmetic 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?

For a 6-parameter mutation tool with no annotations and no output schema, the description covers the input story, the generated content shape and the publish-vs-draft outcome well. It leaves unclear what the tool returns when composing without publishing and says nothing about topMost behavior, which is a modest gap.

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 the schema already documents all six parameters including the tone enum. The description reinforces topic, key points, tone and the draft choice but adds nothing about topMost or courseId, so it earns the baseline rather than more.

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: AI composes a course announcement from a topic, key points and tone, with optional publish or draft. An agent can tell it apart from create_bulletin because AI authoring is explicitly named, though the sibling is never called out by name.

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 reference to create_bulletin or copy_bulletin as alternatives. The only routing signal is implicit: you supply a topic, key points and tone, and the AI writes the body.

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 must carry the full behavioral burden. It does disclose the draft-first nature and the optional publish step, but there is a wording mismatch: the description says it can 直接發布至 eeclass while the schema defines autoCreateInEeclass as 建立此作業 — an agent cannot tell whether a real, visible-to-students assignment is created or only a draft. Nothing is said about permissions, irreversibility of publishing, or cost/latency of the AI generation.

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 that puts the core action and output structure first. The bracketed 【AI 智能出作業】 label restates the tool name and is mild waste, but the rest is dense and non-redundant.

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 7-parameter generative tool with no annotations and no output schema, the description covers what content the draft contains but not what is actually returned (raw text? an object with ids?), whether a draft is persisted or ephemeral, or whether courseId must be a course the caller teaches. Enough to attempt a call, not enough to predict its side effects.

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 every parameter (courseId, topic, type, targetAudience, difficultyLevel, daysUntilDeadline, autoCreateInEeclass) is already documented in structured form. The description echoes topic/difficulty and the publish option but adds no syntax, format, or constraint details beyond the schema, 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 verb+resource (AI 自動生成作業草稿) and enumerates the generated artifacts: 情境背景、實作任務、繳交規範、評分規準 Rubric. The 'AI-generated draft' framing, plus the optional eeclass publish step, separates it from the manual create_homework and from ai_compose_bulletin_announcement / ai_assist_grading_feedback siblings.

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 a clear triggering scenario: a TA or teacher supplies course unit, topic, difficulty and learning objectives, and the tool produces a draft. It does not explicitly state when NOT to use it (e.g. when a human-authored assignment already exists, use create_homework/copy_homework instead), so no exclusions or named alternatives.

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 reveals the write mechanism (DOM auditEditArea switch synced to a hidden textarea) which is genuinely useful context, but it never says what happens on invalid score, whether existing scores/comments are overwritten, what permissions or live Chrome session are required, or how failures surface. For a mutation tool with zero annotation coverage this is a major 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?

One sentence, front-loaded with the action and target. The parenthetical about DOM auditEditArea and the hidden textarea selector is implementation trivia that adds length without helping an agent decide or invoke correctly.

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 write tool with no annotations and no output schema, an agent still lacks information about required session prerequisites, overwrite semantics, and success/failure signaling. The DOM hint implies UI-driven operation but does not make those behaviors explicit.

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 every parameter is already documented (including the 'score must be <= full marks' constraint). The description adds no per-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: fill in score and comment for manual essay questions in an exam. It is distinguishable from siblings like audit_homework_submission (homework vs exam) and import_grades_csv (bulk vs single essay). The trailing DOM/textarea implementation detail is noise but does not obscure the purpose.

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 statement of when to use this versus alternatives (e.g., audit_homework_submission, import_grades_csv, ai_assist_grading_feedback) and no preconditions such as session state or exam status. Usage is only inferable from the phrase 'manual essay questions in an exam'.

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. It discloses that it writes grading fields and can optionally send an email notification, which is useful side-effect context, but it says nothing about permissions, reversibility, whether existing scores can be overwritten, or what happens if the submission has already been audited.

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 front-loaded sentence with no filler, and it enumerates the main fields concisely. It is efficient, though very dense and lacking structure for the optional side-effect parameter.

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 five-parameter mutation tool with no annotations and no output schema, the description leaves important gaps: prerequisites, required vs optional fields, validation/error behavior, overwrite semantics, and the precise effect of sending email. The schema covers parameter details, but behavioral completeness is weak.

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 the schema already defines all five parameters with examples and defaults. The description echoes the fields (score, comment, exemplary flag, email notification) but adds no format constraints, validation rules, or default behavior beyond what the schema provides.

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 on a specific resource: filling in grading score, rich-text comment, exemplary flag, and email notification for an individual student's homework submission. It is clear what the tool does, but it does not explicitly differentiate itself from siblings such as reject_homework_submission or audit_essay_question.

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 provides no explicit when-to-use conditions, prerequisites, or alternative tools. Usage is only implied by 'individual student's submission' and the fact that it fills in grading fields; there is no guidance on when to choose this over reject_homework_submission or audit_essay_question.

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?

Without annotations, the description carries the full burden. It discloses an important side effect—automatically opening a setup wizard in Chrome if the extension is missing or the password is not configured—which is valuable behavioral context. However, it does not state whether the check is read-only otherwise, whether it is safe to call repeatedly, 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?

The description is two sentences: one enumerating the checks and one describing the automatic wizard behavior. It is front-loaded and reasonably efficient, though the first sentence packs multiple concepts together.

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 no-parameter check tool with no output schema, the agent needs to know what status information is returned and how to interpret it. The description covers what is checked and the fallback wizard, but omits any indication of the return format or result structure, leaving a meaningful gap.

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 is no parameter semantics to explain. Baseline 4 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 lists specific checks: whether Chrome is open, the extension is installed/ready, the school password is set up, and the current course identity status. It uses a clear verb ('check') and names the resources, though it does not explicitly contrast itself with closely related siblings like verify_extension_mcp_sync or ensure_chrome_eeclass_session.

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 the diagnostic nature of the tool, but there is no explicit statement of when to call it versus alternatives, nor any exclusions. An agent must infer that this is a preflight or troubleshooting 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?

With no annotations, the description carries the full disclosure burden. It usefully states that the current date is auto-filled and that the copy can be lightly adjusted, but it does not say whether the resulting bulletin is a draft or published, whether the source is untouched, or what permissions are required for this mutation.

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 sentence, front-loaded with the bracketed feature tag and then the core action, with no filler. The bracketed label is mildly noisy but still earns its place by framing this as a TA-only shortcut.

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 three-parameter mutation with no annotations and no output schema, the definition covers the what and the date auto-fill, but omits the outcome (what gets created, draft vs. live) and any permission or side-effect context. 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?

Schema description coverage is 100%, so all three parameters (sourceBulletinId, newTitle, topMost) are already documented in the schema. The description adds no parameter-level meaning such as how newTitle relates to the copied title, 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 uses a specific verb + resource ('複製既有公告') and scopes it to past-semester or existing bulletins, tying it to a concrete UI affordance ('公告清單「複製」按鈕'). It implicitly separates itself from create_bulletin but never names that sibling, leaving a little inference to the agent.

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 '複製過往學期或現有公告' signals the situation that calls for this tool, so usage is implied. However, it gives no explicit when-not guidance and never says to use create_bulletin instead when authoring from scratch, so the alternative is left to inference.

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 usefully discloses what gets carried over (questions, grading settings) and that the time window is reset for the new exam — implying the source exam is left untouched. However it never states permission requirements, whether student attempts/submissions are copied or dropped, or whether the copy is immediately published.

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 compact sentence with the function tag front-loaded and the core action stated first, followed by what is copied. No filler, though the bracketed Chinese label duplicates information already available to the agent.

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 four-required-parameter copy operation with a fully documented schema and no output schema, the description covers the essentials: what is duplicated and what is reset. The main omission is what the call returns (presumably a new exam ID), which the agent would need to chain follow-up calls.

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%, with all four parameters individually documented including ID example and time format, so the baseline is 3. The description adds only the framing that the new exam gets a fresh time interval, which loosely maps to newStartTime/newEndTime but adds no format or constraint detail beyond 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?

States a specific verb and resource (copy an existing exam) and enumerates what is duplicated: questions and grading settings. It also names the UI affordance it maps to (the 'copy' button in the exam list). It stops short of naming a sibling like create/delete_exam for differentiation, but the resource is unambiguous.

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 parenthetical '(corresponds to the copy button in the exam list)' gives the agent a concrete situational cue for when to reach for this tool, and 'helping TA feature' frames the actor. There are no explicit when-not conditions or comparison to copy_homework, but the usage context is clear.

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?

沒有任何註解，因此描述承擔全部說明負擔。它透露了有用的複製語意（來源作業的設定會沿用，只有標題和日期可調整），但沒有說明哪些內容不會被複製（例如繳交紀錄、成績），也沒有說明建立後學生是否會看到，還沒有說明 consentToken 參數所暗示的同意權杖要求，也沒有說明會回傳什麼。

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?

一個精心組織的句子，先出現帶括號的功能標籤，接著是核心動作，最後是助教的好處。篇幅不大，但「免去重新輸入複雜設定」這種行銷框架式說法，比單純說明它能節省什麼略微多餘。

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?

對於一個建立型工具來說，這已達到最低可接受程度：它說明了工具做什麼以及參數由結構描述完整記錄，但沒有輸出結構描述，而且描述沒有告訴代理成功後會拿到什麼（新的作業 ID？），也沒有告訴代理同意權杖要求。

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?

結構描述覆蓋率為 100%，因此所有五個參數（包括 consentToken 與日期格式）都已有結構描述說明——基準值為 3。描述只補充了 newTitle/newDeadline 是為了方便而提供的主要調整項，除此之外沒有增加超出結構描述的内容。

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?

明確的動詞+資源：「複製既有作業」以現有作業為範本建立新一輪作業，並將其對應到作業清單中的「複製」按鈕。它隱含地與 create_homework（從零開始）區分開來，但並未明確點名同類工具。

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?

它說明這是助教功能，並描述了情境（複製後僅需調整標題和截止日期），這隱含了使用時機。但描述沒有明確說明何時不應使用它，也沒有點名任何替代工具（例如 create_homework 或 copy_exam），而是留給代理推斷。

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 behavioral burden, yet it only restates fields that already appear in the schema. It never says whether creation requires a specific role, whether students get notified (a separate sibling send_bulletin_mail_notification hints this matters), whether a draft is invisible to students, or what the tool returns.

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 verb and course scope front-loaded, followed by a compact field list. The parenthetical does duplicate schema information, but it costs little and remains scannable.

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?

This is a 7-parameter mutation tool with no annotations and no output schema, so the description is the only source for permission requirements, side effects (notification, visibility window, draft behavior) and the shape of a success response. None of that is covered, leaving the agent under-informed for a write 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?

Schema description coverage is 100%, so every one of the seven parameters including draft, topMost and the period dates is already documented with types and formats (YYYY-MM-DD). The description's parenthetical simply mirrors those fields without adding constraints such as required-vs-optional behavior or validation rules, 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 verb and resource (新增公告 in 指定課程) and enumerates the supported attributes, so the agent knows exactly what gets created. It does not, however, distinguish itself from siblings such as copy_bulletin or ai_compose_bulletin_announcement, which also produce bulletin content.

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 when-to-use clause, no prerequisites (e.g. teacher/owner role on the course), and no routing away from ai_compose_bulletin_announcement (drafting the text) or copy_bulletin (duplicating an existing one). The agent must infer all of this from the name alone.

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 for a mutation tool. It signals configurability (deadline rules, weighting, late submission) but says nothing about required permissions, the consent/token flow implied by the consentToken parameter, side effects, duplicate handling, or 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?

One front-loaded sentence with zero filler; the core action and scope lead. It is efficient but also thin — the brevity is achieved by omitting operational context rather than by compression.

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 nine-parameter mutation with no annotations and no output schema needs more: nothing addresses authorization requirements, the consentToken/permanent-consent interplay, or the effect of allowDelay and weight on resulting course state. For a creation tool in a family that includes consent-management siblings, this leaves a real gap.

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 all nine parameters are already documented in the schema, including type enum, weight range 0-100, date format, and consentToken. The description's feature list (分組作業/成績比重/遲交規則) merely restates parameters at a higher level without adding syntax or edge-case meaning, 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 verb (新增) and resource (作業) scoped to 指定課程, and enumerates the capability surface (個人/分組作業、起訖時間、成績比重、遲交規則). An agent can distinguish it from list_homeworks or copy_homework without opening the schema, though no sibling is named 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?

No when-to-use / when-not-to-use guidance and no mention of alternatives such as copy_homework or ai_generate_homework_assignment. Critically, it never says that a consentToken may be required or that request_action_consent is the sibling to call first, despite a consentToken parameter being present.

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?

Without annotations, the description carries the full burden, and it does disclose a hard server-side guard and a required consent token. However, it never states that the deletion is irreversible or what the blocked-invocation response looks like — significant omissions for an unannotated destructive operation.

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 with the safety constraint front-loaded ahead of the credential requirement, which is the right ordering for a destructive tool. The emphasis formatting is heavy but every sentence 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?

For a destructive, unannotated tool with no output schema, the critical guard is present, but irreversibility, effect on student records, and failure behavior are not described. Enough to call it safely in the happy path, not enough for full confidence.

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 both parameters (examId, consentToken) are already documented there, including the X-Consent-Token mapping. The description's mention of the token merely repeats the schema, 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 states a specific verb and resource ('刪除測驗') plus the precondition attached to it, so there is no ambiguity about what the tool does. It does not explicitly contrast itself with nearby siblings such as copy_exam or delete_student_exam_attempt, so the sibling-differentiation element is missing.

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 concrete when-not rule: deletion is blocked when testedCount > 0, which tells the agent exactly when the call will fail. It does not redirect the agent to the alternative (delete_student_exam_attempt) when students have in fact attempted the exam, so the guidance stops just short of full routing.

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 submission guard, that a refusal throws an error rather than silently no-opping, and the consent-token requirement. It leaves out irreversibility and permission scope, so not 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?

Three short sentences with the destructive safety guard front-loaded ahead of the consent prerequisite. Nothing is padded and the ordering matches how an agent should reason before calling.

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 destructive tool with no output schema, the description covers the guard, the error behavior, and the consent prerequisite. It omits whether deletion is permanent and what identifiers/return data come back, but those are secondary for 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 100%, so baseline is 3, but the description adds real value by specifying where consentToken comes from (request_ui_consent / X-Consent-Token), which the schema does not explain. homeworkId semantics are left entirely 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 description opens with a specific verb+resource (刪除作業), which unambiguously identifies the operation and separates it from siblings like delete_exam or copy_homework. It does not explicitly name an alternative tool, but the resource is distinct enough that no confusion is likely.

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 states a clear blocking precondition (refuses if submittedCount > 0) and a required prerequisite (a consent token obtained via request_ui_consent), which is actionable routing guidance. It stops short of naming an alternative path or explaining what to do instead when the deletion is refused.

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 disclose that this is a deletion that releases exam eligibility and requires a UI consent token. It does not state whether the deletion is irreversible, what happens to associated grading data, or any permission/authorization nuance beyond the TA role.

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, front-loaded sentence with a bracketed feature label followed by the rationale and consent requirement. It is efficiently sized, though the opening clause and the later phrase about releasing exam eligibility slightly restate the same idea.

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 destructive tool with no annotations and no output schema, the description covers purpose, scenario, and consent token requirement. It is still missing contextual detail such as irreversibility, expected return behavior, or how to obtain the recordId (for example via get_exam_record_detail).

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 the schema already documents all four parameters. The description adds modest context by tying the action to a specific attempt and a UI permission token, but it does not add syntax, format, or source details beyond 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 description states a specific verb (刪除), resource (學生測驗紀錄/作答紀錄), and scope (特定一次) while naming the operational goal of allowing a retake. This clearly distinguishes it from sibling tools like delete_exam, which deletes an entire exam rather than a single student's attempt.

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 triggering condition: when a student needs a retake due to disconnection or an abnormal situation, a TA may delete that student's specific attempt. It does not, however, name explicit alternatives or state when not to use this tool, so it stops short of a full routing guideline.

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 it does disclose the key side effect (fetches files and archives them to the specified local directory) and that it returns a result list plus an ACK. It omits overwrite behavior, failure modes, and any permission/session requirements, which matter for a disk-writing operation.

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?

Content is front-loaded with the bracketed tag then the action, but the second sentence is padded with implementation jargon ('外掛實體接收此指令後……外掛確認 ACK') that adds little for an agent deciding whether to call the 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?

For a 3-parameter tool with no annotations and no output schema, the description does compensate partly by describing the returned file list and ACK. However, it leaves out session/auth prerequisites and the effect of onlyNewFiles defaults, so it is adequate rather than 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 coverage is 100%, so all three parameters are already documented. The description adds only a small amount — an example custom path — and says nothing about courseId semantics or the deduplication behavior governed by onlyNewFiles, so baseline 3 is appropriate.

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 plus resource ('下載指定課程的課堂教材與檔案'), scoped to a course. It is clearly distinguishable from siblings like package_download_homework or list_homeworks, though it does not explicitly name the alternatives.

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 usage by saying it supports a custom local folder and gives an example path, but there is no explicit when-to-use / when-not-to-use guidance and no mention of prerequisites such as an active Chrome/eeclass session despite that being required by sibling tools.

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 it discloses meaningful side effects: it will auto-launch Chrome, open a specific platform URL, and trigger an automated OAuth login via a captcha-solving model. That is real behavioral disclosure beyond a mere "check". Gaps remain — it does not state failure behavior, blocking duration, or whether the extension must be installed first.

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 compact paragraph front-loaded with the 【前置 Session 檢查】 label, then the check behavior, then the fallback behavior. Every clause adds information and the ordering follows the actual control 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?

Zero parameters and no output schema, so the description must convey behavior — which it does well, covering both the idle and not-running branches. It is slightly incomplete in not signaling what result the agent receives (success/failure indication) or what to do if the automated login fails, which matters since there is no output schema to fall back on.

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 is nothing for the description to disambiguate. Baseline of 4 applies for the no-parameter case.

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: check whether Google Chrome is running, and if not, launch it and open the NTHU eeclass platform. The 【前置 Session 檢查】 prefix scopes it as a prerequisite step. However, it does not differentiate itself from the very similar sibling wake_and_bootstrap_eeclass, so an agent cannot tell the two apart from the description alone.

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?

"前置 Session 檢查" implies this should be run before other eeclass operations, which gives some usage context. But there is no explicit when-to-use statement, no exclusions, and no mention of the overlapping siblings (wake_and_bootstrap_eeclass, check_extension_and_setup_status, verify_extension_mcp_sync).

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 states that the tool returns a classification list and explains the two permission categories, which implies a read-only query, but it does not explicitly confirm read-only behavior, auth requirements, or return format. For a zero-parameter read tool this is adequate but not rich.

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 front-loaded sentence with a bracketed label and a clear explanation, with no wasted text. It is slightly dense but appropriately sized for a simple list 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?

For a zero-parameter read tool with no output schema, the description explains the returned classification categories well enough to invoke it correctly. It could mention the read-only nature or output shape, but the core information 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?

The tool has zero parameters, so the baseline is 4. The description adds no parameter information because none exist, and the schema is trivially complete.

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 uses a specific verb (查詢/取得) and resource (課程身分分類清單), and explains the two permission categories it reports. It does not explicitly differentiate itself from siblings such as list_teaching_courses or get_user_permissions, so it falls 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?

There is no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The description implies the tool is for checking course permission classification, but it does not tell the agent when to choose it over list_teaching_courses or get_user_permissions.

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 add real value by disclosing the four data categories returned, including the caller's own identity — something the name alone would not convey. It stops short of stating permission requirements, behavior for non-enrolled users, or error/empty cases.

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 sentence, front-loaded with the verb and scope, followed by an inline enumeration of return contents. No filler and nothing that could be trimmed without losing 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 output schema and no annotations, the description compensates well by listing the returned fields, which is the main ambiguity for a getter. The remaining gap is behavioral edge cases and access requirements, which are modest for a one-parameter read 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 100%: the single courseId parameter is documented with a concrete numeric example (35657). The description adds nothing about the parameter beyond the schema, so the 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 verb and resource (取得指定課程的側欄資訊) and enumerates the exact contents returned: instructor list, TA list, current user identity, and course code. This is distinctive against siblings like list_teaching_courses or get_homework_detail, though it does not name any sibling 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: call it when you need a course's sidebar metadata, and it requires a courseId. There is no explicit statement of when to prefer this over list_teaching_courses or list_granted_consents, and no prerequisites (e.g. enrollment) are given.

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 full burden. 讀取 implies a read-only operation and the text usefully discloses that the response separates auto-graded from human-graded content, but it says nothing about permissions, access scope, or error conditions for a non-existent recordId.

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 substantive behavior (auto vs manual grading distinction) is included without redundancy.

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 one-parameter read tool with no output schema, the description tells the agent what the payload contains (graded vs manually graded answers), which is enough to call it correctly. Minor gaps around permissions and error behavior keep it from a 5.

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% – recordId is already documented as 作答紀錄 ID (recordID). The description adds no syntax, format, or sourcing guidance beyond what the schema supplies, so the 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 states a specific verb (讀取) and resource (學生個別測驗作答明細), and even characterizes the payload by distinguishing auto-graded multiple-choice from manually graded essay answers. It is clear what the tool returns, though it does not explicitly contrast itself with siblings like audit_essay_question.

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 '讀取學生個別測驗作答明細' – fetch a single student's exam answer sheet. However, there is no explicit when/when-not guidance, no mention of prerequisites (e.g., teacher role), and no routing to alternatives such as audit_essay_question for grading.

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. It does add one genuinely useful behavioral hint — that values are parsed out of a dt/dd HTML structure, implying fields may be absent or scraped rather than first-class data — but it says nothing about read-only semantics, permissions, or failure behavior for an invalid ID.

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 sentence, front-loaded with the verb and resource, with the parenthetical used efficiently to enumerate returned fields rather than pad. Nothing is wasted.

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 usefully compensates by listing the concrete settings the caller will receive. It is nearly complete for a single-parameter read tool; only edge cases (nonexistent ID, unpublished homework, missing dt/dd sections) are unaddressed.

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% and the single parameter (homeworkId) is fully documented with a type and an example (70800). The description adds no additional meaning about the identifier beyond what the schema already supplies, 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?

The description gives a specific verb+resource ('取得特定作業的詳細設定與規範') and enumerates the exact fields returned (grade weight, late submission, grading method, observation settings, description). It is clearly a detail-fetch counterpart to the sibling list_homeworks, though it never names that sibling 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?

There is no explicit statement of when to use this tool versus list_homeworks, create_homework, or audit_homework_submission. The only guidance is implicit — that a single 'homeworkId' is required — so an agent must infer the use case from the name alone.

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. It does disclose that this is a read of the caller's own state and tells the agent what information comes back (role plus permission classification), which is more than nothing. However, it says nothing about authentication requirements, whether it requires an established eeclass session (relevant given the sibling wake_and_bootstrap_eeclass / ensure_chrome_eeclass_session tools), or what happens when no session exists.

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 sentence with no filler, and the core resource (role) is front-loaded ahead of the secondary detail (permission categories). Nothing could be removed without losing 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 zero-parameter query with no output schema, the description does the important work of naming the returned shape: the role enum and the CRUD permission classification. It stops short of explaining how the permission categories are represented (list, flags, per-resource map), which is the only meaningful gap.

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 is no parameter semantics to explain and the baseline of 4 applies. The description correctly implies the implicit 'current user' subject rather than suggesting an identifier be passed.

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 pairs a specific verb (查詢) with two concrete resources: the current user's role and their CRUD permission categories. It even enumerates the possible role values (Teacher/TA/Student/Guest), so an agent knows exactly what comes back. No sibling tool in the list does anything comparable, so there is nothing to confuse it with.

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 phrasing '目前使用者' makes it clear this is a self-scoped lookup with no parameters, but the description never says when to call it — for example, before attempting a write operation, or to gate access to teaching functions. There are no exclusions or alternatives to choose between, so the usage signal is only implied.

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 zero annotations the description carries the full burden, and it does disclose the critical behavior: 批次覆寫 (batch overwrite), i.e. existing grades/comments are replaced. However it omits permission/auth requirements (the required consentToken is only visible in the schema), partial-failure behavior for the array, and any return-value information.

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 sentence with a bracketed category tag up front, so the core purpose is front-loaded and nothing is wasted. It is perhaps slightly under-sized for the operation's weight, but structurally clean.

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 mutating batch tool with no annotations and no output schema, the description should say more: it is silent on partial-failure semantics, whether values are replaced or merged, and what the caller gets back. It covers the 'what' adequately but not the operational detail an agent needs.

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 every parameter (homeworkId, gradesData, consentToken) is already documented in the schema. The description adds no extra semantics about formats, limits, or the meaning of the consent token, 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 (批次匯入 / batch import) and resource (成績與評語, grades and comments), and ties it to the familiar UI feature 『匯入成績』 on the submitted-list page. It is clearly distinguishable from sibling grading tools, though it never names a sibling to contrast with.

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 UI anchor ('corresponds to the Import Grades function on the submitted list page') implies when to use it, which is helpful context. But it gives no explicit guidance on when NOT to use it versus siblings like audit_homework_submission or ai_assist_grading_feedback, nor any prerequisite context.

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. It usefully discloses the payload fields returned and that results are scoped to a single specified course, but says nothing about permissions/role requirements, ordering, pagination, or behavior for an invalid courseId.

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 that puts the action and resource first and uses a compact parenthetical for the return fields. No filler or redundancy.

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 one-parameter read tool with 100% schema coverage and no output schema, the description covers the essential gap by enumerating what comes back (title, date, HOT flag, draft status). Only minor behavioral details (ordering, permissions) are absent.

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?

Only one parameter exists and schema description coverage is 100% ('課程 ID'), so the schema already documents it fully. The description's phrase 指定課程 corroborates that the list is scoped by course but adds no format or constraint detail beyond the schema, making the baseline 3 appropriate.

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 verb (取得/list) and resource (指定課程公告清單) and enumerates the returned fields (title, date, HOT pinned flag, draft status), so the agent knows exactly what data this yields. It does not explicitly contrast with siblings like create_bulletin or copy_bulletin, but the 'list' framing is unambiguous.

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 the read-only 'list' verb and the single courseId parameter. There is no explicit statement of when to use this versus copy_bulletin / create_bulletin, nor any prerequisite (e.g. whether the caller must be enrolled in or teaching the course).

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 useful work by disclosing what each returned row contains (examId, kexamId, answered count, canDelete). However, it says nothing about permission requirements, whether unpublished exams are included, ordering, or pagination, which matters for a teacher-facing listing 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 compact sentence, front-loaded with the action and immediately followed by the returned fields. No filler, though it is terse enough that some necessary context is omitted rather than wasted space.

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 field enumeration is a genuine contribution, but the description still leaves open whether the list is exhaustive, what canDelete is derived from, and what an empty result means. For a single-parameter read tool this is adequate but not 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?

There is a single required parameter with 100% schema description coverage ('課程 ID'), so the schema already explains it. The description's phrase '課程測驗列表' merely restates that the list is scoped to a course and adds no format or edge-case guidance.

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 returned fields (examId, kexamId, answered count, canDelete), which distinguishes it from siblings like get_exam_record_detail or delete_exam. It does not explicitly name a sibling, so it falls 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 by the name and the 'course' qualifier; there is no statement of when to call this versus get_exam_record_detail (per-attempt detail) or list_homeworks. The agent must infer the routing decision from the tool name alone.

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 must carry the full burden. It does add value by specifying that only currently effective grants are returned and by breaking the results into token vs. permanent vs. tracked-identity categories, which implies read-only behavior. However it never states that nothing is mutated, what an empty result means, or any permission requirements for viewing the 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?

A single sentence with the purpose front-loaded in the bracketed header followed by the returned categories. Slight redundancy between the header and the body, but nothing extraneous.

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 no-parameter, no-output-schema listing tool, the description covers what the result contains well enough to call it correctly. Only the read-only nature and empty-result semantics are left implicit, which is a minor gap given the tool's simplicity.

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 and the schema is an empty object, so there is nothing to disambiguate. Baseline for a 0-parameter tool 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 specific verb (list/query) plus resource (currently granted consents) and enumerates the three entry types returned: single-use permission tokens, per-course permanent permission lists, and tracked course identities. It distinguishes itself from the request_/revoke_ siblings by being the read/audit view, though it never names them 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 only implied: an agent can infer this is the tool to inspect existing authorizations before requesting or revoking. There is no explicit when-to-use statement, no mention of how it differs from the neighboring get_user_permissions, and no preconditions given.

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 the shape of the result set (name, group flag, submitted/graded counts, deadline, canDelete), but says nothing about read-only nature, whether unpublished or deleted items are included, ordering, or pagination limits.

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 scopes the tool first (指定課程) and then lists the fields. The field enumeration is long but each item is informative; no filler or redundancy.

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, listing the returned fields is the highest-value content and it is present, including the operationally important canDelete flag. Minor gaps remain around ordering, volume, and filtering behavior for a course's homeworks.

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% and the single courseId parameter is already documented with an example in the schema. The description's '指定課程' adds no syntax or constraint beyond that, so the 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 states a concrete verb-resource pair (取得作業清單) scoped to a specified course (指定課程), and enumerates the returned fields. This naturally contrasts with the singular get_homework_detail or the submission-oriented list_homework_submissions, though no sibling is named 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 only implied: an agent can infer 'use this when you need the homework list of one course'. There is no explicit when-to-use, no exclusion against get_homework_detail or list_unsubmitted_students, and no stated 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?

No annotations are supplied, so the description carries the full burden. It does disclose the returned fields per student (name, student ID, submission time, current score, reportId), which is genuinely useful, but says nothing about permission requirements, pagination, or behavior for empty rosters or invalid homeworkId.

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 resource and scope stated first and detail in a parenthetical. Dense but every clause carries information; no filler.

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 two-parameter list tool with no output schema, the description covers scope, category filtering, and returned fields. Only pagination/volume behavior and permission expectations are missing, which is a minor gap.

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%, so both parameters are already documented, giving a baseline of 3. The description reinforces the meaning of the three status categories and confirms homeworkId scoping, but adds no format or constraint detail beyond 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?

States a specific verb and resource: '取得指定作業之學生繳交名單' (retrieve the student submission roster for a specified homework). Scope is clear enough to distinguish it from list_homeworks or get_homework_detail, though it does not explicitly name the overlapping sibling list_unsubmitted_students.

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 parenthetical mentioning the submitted/not-submitted/rejected categories suggests when the status parameter matters, but there is no explicit guidance on when to pick this over list_unsubmitted_students or audit_homework_submission, which cover adjacent ground.

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 must carry the full behavioral burden; it does signal a read-only retrieval ('取得') and names the fields returned, which is useful. It is silent on authentication/session requirements, result ordering, pagination, and behavior when the user holds no TA/teacher roles — all relevant for an MCP agent deciding whether to depend on this call.

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: the first delivers the core scope and return contents, the second front-loads the dependency relationship to downstream tools. No filler, though the parenthetical field list could be trimmed if the response shape were documented 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?

There is no output schema, so the description must describe return values — it names the four key returned fields, which is the main thing an agent needs. The remaining gap is the lack of session/auth preconditions and error behavior for a bootstrap-style tool in a large sibling set.

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 is nothing for the description to disambiguate and the baseline of 4 applies. The description does not add spurious or confusing input guidance.

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 pair: fetch courses where the caller's role is TA or teacher, and it enumerates the returned fields (course code, numeric ID, instructor roster, role). This scoping by role makes it distinguishable from a generic course-listing tool, though it never contrasts itself with the sibling get_classified_courses, which an agent may see as overlapping.

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 'this is the foundation for all homework, exam, and bulletin functions' implies a prerequisite use case, telling the agent to call this before those operations. However, it gives no explicit when-not conditions, no mention of get_classified_courses as an alternative, and no statement about whether results are cached or need refreshing.

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 disclose the key behavioral trait that the call can have a side effect: it may send reminder emails when sendReminderEmail is set. It also discloses the returned fields (student number, name) and endpoint mapping, though it omits permission requirements and what happens if the homework ID is invalid.

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 bracketed feature label is slightly redundant with the tool name but still efficiently signals the TA-specific scope.

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 read tool with one optional mutating flag, the description covers purpose, output fields, and the email side effect; no output schema exists, so naming the returned fields is sufficient. Only edge-case or permission behavior 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?

Schema coverage is 100%, with both parameters documented in the schema (homeworkId with an example, sendReminderEmail default false). The description only restates the optional reminder behavior, adding little beyond the schema, 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 verb and resource: retrieve the list of students who have not submitted homework for a given homework ID, including student ID and name. It also names the concrete backing endpoint (/homework/noSubmitList/{作業ID}), making the scope unambiguous relative to siblings such as list_homework_submissions.

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 bracketed label '助教特殊功能：未交學生清查與催交' implies a teaching-assistant cleanup/reminder scenario, and the description notes the optional one-click reminder email. However, it never says when to prefer this over list_homework_submissions, nor does it state any preconditions or 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 full behavioral burden, yet leaves key traits unclear: it says it returns "ZIP 下載資訊" (download information), which ambiguously sits between 'produces a file' and 'returns a URL/token' — the tool name 'download' points one way, the description the other. It also omits whether packaging is synchronous or job-based, permission requirements, and what happens when no submissions exist.

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 compact sentence with the operation front-loaded, followed by scope and then the UI anchor. No filler, though splitting the return-shape clarification into a short second clause would have improved it without bloat.

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?

Given one required parameter, no nested objects, and no output schema, the description is largely sufficient. The remaining gap is that with no output schema the agent cannot learn the shape of the returned download info (URL, expiry, file list), so a sentence on the return value would have completed it.

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% (homeworkId: 作業 ID), so the schema already fully documents the single parameter and baseline 3 applies. The description adds no extra semantics about homeworkId — e.g. whether it accepts an ID from list_homeworks or only from the teacher's own course.

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 operation: retrieve ZIP download info for all attachments and system text files of submitted homework (取得已繳交作業之所有附件與系統文字檔 ZIP 下載資訊). This is clearly distinct from get_homework_detail or list_homework_submissions in resource scope, but the description never names a sibling to contrast with, so the differentiation is implicit 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?

The parenthetical "對應已交名單頁工具列按鈕" anchors usage to a specific UI affordance (the toolbar button on the submitted-list page), which implies bulk download of an entire class's submitted work. However, there is no explicit when-not guidance, no prerequisite statement (e.g., must be the course instructor), and no mention of an alternative tool for downloading a single submission.

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 provided, the description carries the full behavioral burden. It usefully discloses that the student will be notified and can re-upload the answer file, which is meaningful side-effect context, but it does not explain permission requirements, the role of consentToken, or whether the rejection is reversible.

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 two tightly written sentences with the core action front-loaded and no wasted text. The parenthetical button reference is helpful context rather than filler.

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 a mutation with no annotations and no output schema, so the description should ideally cover authorization and consent behavior. It does cover the student-facing consequence, but the absence of any mention of consentToken or permission requirements leaves an operational gap for the agent.

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 reportId, reason, and consentToken are already documented in the schema. The description adds no parameter-specific meaning beyond the schema, so the baseline score of 3 is appropriate.

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: returning a student's submitted homework for rewrite, and ties it to the grading-page 'return for rewrite' button. It is clear what the tool does, but it does not explicitly distinguish this action from sibling tools such as audit_homework_submission or ai_assist_grading_feedback.

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 '助教特殊功能' and the mapping to the grading-page button imply when the tool is used, but there is no explicit when-to-use guidance, no exclusions, and no named alternatives. An agent can infer the context but must still decide on its own when this is preferable to auditing or feedback tools.

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 usefully discloses the human-in-the-loop flow: the user reviews the exact fill content on the Chrome permission page and picks one-time or permanent. It omits critical behavior for a gating tool — whether the call blocks awaiting the user, what happens on denial or timeout, and whether a denial aborts the subsequent 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?

Two sentences, front-loaded with the purpose and followed by the user-facing mechanics. The bracketed header partly restates the title, but the rest is dense and free of filler.

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 6-parameter tool (5 required) with a free-form nested payload object and no output schema, the description explains the trigger and the user-facing choice but says nothing about what the call returns or how a grant is represented to the caller, which matters since there is no output schema to fall back on.

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 every parameter is already documented, including the preferredMode enum. The description adds only the general notion that the payload is what the user will see; it supplies no extra constraints (e.g., payload size limits, required action code conventions) beyond 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 description names a specific verb and resource — requesting user authorization from the extension before sensitive or bulk data-fill operations — and lists concrete triggering actions (homework creation, grading, answer deletion, bulletin publishing). It is clear what the tool does, though it does not distinguish itself from the close sibling request_ui_consent or explain the relationship to list_granted_consents/revoke_permanent_consent.

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 context is explicit: call this before executing sensitive or high-volume fill operations, with examples of what counts. However, no exclusion guidance is given — it never says when to prefer request_ui_consent, or whether an existing permanent consent (checkable via list_granted_consents) makes this call unnecessary.

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 burden. It discloses that the call yields a Consent Token and that the flow is UI-facing (implying user interaction/approval), which is real context beyond the schema. It does not state what happens if the user declines, whether the token expires, or whether the call blocks — notable gaps for a mandatory gating 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?

Two sentences, zero waste: the first defines scope and enumerates actions, the second states the mandatory precondition. The critical usage constraint is front-loaded and easy to scan.

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, yet the description never explains what the returned token is, how long it lives, or how it must be passed to the subsequent destructive tool (e.g. delete_homework). For a gating tool in a multi-step consent flow, that handoff is the single most important missing piece.

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% with per-parameter descriptions and an action enum, so the baseline is 3. The description's action list mirrors the enum values (delete_homework, delete_exam, delete_bulletin, broadcast_email, batch_import_scores) but adds no semantics about targetId format, reason expectations, or how targetId relates to action type.

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: applying for a UI Consent Token for enumerated high-risk actions, and lists the concrete action types (delete homework/exam/bulletin, broadcast email, batch import). However, it does not differentiate itself from the near-identical sibling request_action_consent or from list_granted_consents, leaving the agent unsure which consent tool to pick.

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 an explicit, mandatory trigger condition tied to destructive operations. It lacks any when-not guidance or pointer to request_action_consent as an alternative path, so the routing between the two consent tools is unresolved.

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 it does disclose the key consequence: after revocation every operation reverts to a per-action confirmation prompt. It does not state whether revocation is itself undoable, whether it requires any authorization, or what the response confirms, which matters for a destructive-style mutation.

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 compact sentence preceded by a bracketed scope tag; the effect and the resulting state are front-loaded with no filler. The 【】 label is mildly redundant with the tool name but serves as a quick scannable summary.

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-optional-parameter mutation with no annotations and no output schema, the description covers purpose, scope, and post-condition, which is enough to invoke it. It stops short of covering reversibility, return confirmation, or interaction with list_granted_consents, leaving a moderate gap.

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 parameters (action code and courseId) are already documented, and the description adds only the scoping rule that leaving courseId empty means all courses. That restates the schema's own note rather than adding new 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 description uses a specific verb (revoke) and resource (permanent consent/permissions), and clarifies the two scopes: a single action/course or all remembered permissions. It clearly contrasts with consent-granting siblings like request_action_consent by describing the inverse operation, though it never names a sibling 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: call this when previously remembered permanent permissions should be withdrawn. There is no explicit when-not guidance, no mention of checking list_granted_consents first, and no note on prerequisites, leaving the agent to infer the workflow.

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 flags the operation as high-risk, requires X-Consent-Token, and warns that the recipient set includes instructors and TAs, not just students — a genuine side-effect disclosure an agent would otherwise miss. It still omits whether the send is immediate or queued, whether it is reversible, and any volume/rate caveats.

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 sentences: purpose first, then the high-risk/consent warning in a bracketed callout. Nothing is redundant and the critical constraint is front-loaded where an agent will read it.

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-parameter mutation with no annotations and no output schema, the description covers what the tool does, the scope of its side effect, and the gating prerequisite. The remaining gap is procedural — it never says where to obtain the consent token — which matters for a tool that cannot be called without one.

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%, so both bulletinId and consentToken are already documented in-schema, establishing a baseline of 3. The description adds only the framing that the bulletin's content is what gets mailed; it provides no format, ID-source, or token-lifetime detail beyond 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?

States a specific verb (寄送 email) and resource (指定公告內容) plus an explicit recipient scope (全體修課生成員，包含教師與助教). This distinguishes it from list_bulletins/create_bulletin/copy_bulletin, which manage bulletins but do not dispatch email.

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 makes clear the context of use (broadcast a bulletin to all course members by email) and states a hard prerequisite: a UI consent token must be obtained first. It does not name the sibling that issues that token (request_ui_consent / request_action_consent) nor give any 'when not to use' condition, so it stops short of full routing guidance.

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 signal that this is a passive verification returning the most recent receipt, which usefully tells the agent it is a read, but it omits what happens when nothing has been received (empty result? error?), and whether calling it triggers or waits on the extension.

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 sentence, front-loaded with a bracketed category label, followed immediately by the verification target and the returned fields. Nothing is redundant 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?

There is no output schema, so the description must describe the return payload, and it does: latest MCP tool name, timestamp, and ACK status. For a zero-parameter read tool this is nearly complete; only the no-data / failure case and the ACK vocabulary are left unexplained.

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 is no parameter meaning to convey; the baseline for a 0-param 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?

States a specific verb (verify) and a specific resource (whether the Chrome extension actually received MCP communication data), and even previews what is returned (latest tool name, timestamp, ACK status). It is distinguishable from setup-oriented siblings like check_extension_and_setup_status, but the description never names or contrasts them 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?

The framing implies the use case — after an MCP tool call, confirm the extension actually received it — but the description never states when to call this versus check_extension_and_setup_status or ensure_chrome_eeclass_session, nor any preconditions. Usage must be inferred from the wording.

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 it does disclose meaningful behavior: it triggers a real automated login, scans the entire course list, and mutates the session's permission context. What it omits is significant for a login-performing tool — required prerequisites (extension installed, Chrome running, credentials present), idempotency when called repeatedly, whether re-running re-authenticates, and failure/retry 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?

A single dense sentence with a front-loaded bracketed label; each clause adds a distinct behavior (wake, login, scan, classify, propagate permission context). Slightly heavy for one sentence, but nothing is wasted or repeated.

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 is the only source of truth, yet it never says what the call returns — whether the classified course list comes back directly or the agent must follow up with get_classified_courses — nor what happens on failure. For a bootstrap gate that other sibling tools depend on, that missing contract is a real gap.

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 is nothing to mis-document and the baseline of 4 applies. The description correctly implies no inputs are required, since the tool self-drives the extension and course scan.

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 compound action: wake the extension, perform automatic CAPTCHA login, scan the course list, and classify course identities as TA/instructor vs. student. The verb+resource are concrete, but the description never distinguishes this bootstrap from overlapping siblings such as ensure_chrome_eeclass_session or get_classified_courses, leaving an agent to guess which one actually performs the login and classification.

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 bracketed '首次登入引導' (first-login guidance) label and the closing clause 'ensuring subsequent operations have the correct permission context' clearly convey this is a precondition to run early in a session. However, it never names alternatives or states what to do if the extension is already awake/bootstrapped (e.g., check_extension_and_setup_status or verify_extension_mcp_sync), so there are no explicit exclusions.

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