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

Goes well beyond the annotations: it discloses that this is an asynchronous background job that returns immediately, that it downloads several GB, that every file is verified against a hard-coded sha256, and that the operation is resumable. These are exactly the behavioral traits an agent needs but cannot derive from readOnlyHint/idempotentHint alone.

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?

Four compact sentences with zero filler: purpose and async nature first, then download/verification size, then progress tracking and resumability. Every sentence carries load-bearing 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, the description still tells the agent that the call returns immediately and that progress must be polled via asr_status, which is the critical return-behavior detail. Combined with the fully documented params and annotations, nothing needed to call it correctly 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 description coverage is 100%, and the schema already documents both the gpu and model parameters including the uv requirement and the 1.7b-with-gpu constraint. The description adds no parameter-level meaning 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?

States a specific verb (install/start background job), the exact resource (the Qwen3-ASR runtime used by transcribe_vod), and the install location (~/.cache/dotbugi-mcp/asr). It is clearly distinguishable from siblings like asr_status and asr_remove.

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?

Explains that progress is tracked via asr_status and that re-calling resumes an interrupted install, which gives the agent clear post-call handling. It does not explicitly state when not to use it (e.g., if already installed) or name asr_remove as the counterpart, 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?

Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds what actually gets deleted (the local runtime cache), the consent/confirmation requirement, the concurrency refusal condition, and the two-step token protocol. This is exactly the kind of operational context annotations cannot express.

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?

Four short sentences, front-loaded with the destructive action and target path, then consent, then refusal condition, then the token fallback. Every sentence carries distinct, actionable information with no repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, single-parameter tool with no output schema, the description covers target, consent, refusal, and the retry protocol, which is everything an agent needs to invoke it safely. The only return value an agent must handle (a token) is explicitly described.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the confirmToken parameter is already documented in-schema, so the baseline is 3. The description adds real value by explaining the protocol around it: that the token is returned by a first call on dialog-less clients and must only be supplied after user consent.

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 the exact resource and its filesystem path (/root/.cache/dotbugi-mcp/asr). The ASR-prefixed name and path make it unmistakable against siblings like asr_install and asr_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear preconditions: user must approve in a client confirmation dialog, and calls are rejected while install or transcription jobs are running. It also prescribes the fallback path (confirmToken) for clients without a dialog. It does not name sibling tools to check first (e.g., asr_status) or state when not to call at all, so it stops short of explicit 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?

The annotations already declare that this is a read-only, non-open-world operation, so the description doesn't need to restate that safety profile. It does add real behavioral context: turning on verify triggers a sha256 check that reads several GB and takes a few seconds, and that check is skipped while an install is running. The description does not disclose anything about the output, but an output schema 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?

The description takes two sentences. The first one front-loads what the tool reports, and the second one covers the costly verify option and its edge cases. There is 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 one-parameter, zero-required, read-only status tool that also has an output schema, the description covers the component list, the job-progress dimensions, and the cost plus skip behavior of verify. Nothing an agent needs in order to invoke it correctly 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%, so the verify parameter is already documented as a sha256 comparison against fixed values. The description adds meaning beyond the schema by quantifying the cost (several GB read, a few seconds) and describing the conditional skip during installation, which is behavior the schema alone cannot convey.

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 (shows/exposes) and enumerates the resources: ffmpeg, qwen_asr, model, GPU venv, plus the progress and errors of the current or last asr_install job. That makes the tool distinguishable from asr_install/asr_remove by implication, but it never names a sibling or explicitly frames itself as the read-only status counterpart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies its usage context, checking status and install progress, but it gives no explicit when-to-use or when-not-to-use guidance, and it doesn't mention alternatives such as asr_install or transcribe_status. The agent must infer the routing from the tool name and component list 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?

Goes well beyond the destructiveHint=true annotation: it discloses that targets are re-derived by re-syncing at execution time, that a client-side confirmation dialog must be approved by the user, and that headless clients get a list plus a one-time confirmToken. It also names the safety boundary (no modified files, links, or out-of-root paths), which is exactly the behavioral detail an agent needs before invoking a destructive 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?

The destructive scope is front-loaded in the first clause, followed by the confirmation flow and then the safety exclusions. Four sentences, each carrying non-redundant information, with 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 destructive, open-world, non-idempotent tool with no output schema, the description covers everything an agent needs: target derivation, approval requirements, the headless fallback and its returned token, and the protected-file boundary. Annotations and the 100%-covered schema handle the rest.

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 the baseline is 3; the description earns extra by clarifying that 'paths' is only a filter because targets are recomputed via re-sync, and by explaining the confirmToken round-trip (first call returns it, call again only after user consent). It does not describe the 'course' filter at all, leaving that 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?

States a specific verb (deletes locally) and a precisely scoped resource (only files sync_materials reports as removed). It also anchors the tool to its sibling sync_materials, so an agent can tell this apart from the sync/read tools without opening a schema.

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 precondition ('only files reported as removed'), explicit exclusions (modified-after-download files, links, paths outside the storage folder are not deleted), and a two-path invocation protocol. There is no competing delete tool among the siblings, so the exclusions serve as the when-not 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?

Annotations already declare idempotentHint=true and destructiveHint=false; the description adds real behavioral context beyond them: re-export overwrites the same file, stable per-item UIDs prevent duplicates on re-import, per-app update semantics differ, and completed/deleted items linger in calendars. It also warns that LMS text is data not instructions. Minor gap: no mention of whether the storage directory must be configured first (set_storage_dir exists as a sibling).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the action and resulting path, then the import workflow, then caveats in decreasing priority. It is a bit dense with several distinct caveats in one block, but each sentence carries information an agent would otherwise get wrong.

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?

An output schema exists, and the description still names the returned value (the file path). It covers the non-obvious failure modes (dedup, stale events, skipped items) that no structured field expresses. The only unaddressed prerequisite is the storage-location setup handled by a sibling 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 coverage is 100%, so the baseline is 3; the description goes further by declaring the filter semantics equivalent to list_tasks and by explaining that items lacking deadline data are skipped and only counted, which clarifies how withinDays/incompleteOnly actually behave. It does not document the individual enum values or the refresh cache, but the schema does.

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 output artifact: it saves VOD/assignment/quiz deadlines as an .ics file at a named path and returns that path. The selection criteria are anchored to a named sibling (list_tasks), so an agent can distinguish it from the read-only listing tools without opening either schema.

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?

Makes the use case explicit (import into Google/Apple/Outlook calendars) and ties filtering to list_tasks' criteria, which implicitly routes agents to list_tasks when they only want to view items. It does not state an explicit 'do not use for X' exclusion, but the downstream workflow 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?

It discloses the key side effect that annotations do not mention: attachments are downloaded into a dedicated folder, and local paths are returned. This explains why readOnlyHint=false appears on an otherwise read-oriented tool. It also states that the tool performs no submission and warns that LMS text is data, not instructions, which is valuable prompt-injection guidance.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It consists of three dense, front-loaded sentences: what it returns, the no-submission boundary, and the injection warning. No sentence repeats the schema or the title, and the behavioral disclosures are prominent.

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?

An output schema exists, so return values need not be explained, but the description still names the returned fields and the on-disk side effect. It is nearly complete; it only omits whether repeated calls re-download attachments or overwrite the dedicated folder.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has one parameter with 100% description coverage, and the description adds no detail about that parameter. In this situation, a baseline of 3 is appropriate, because the schema does the semantic work (cmid = mod/assign/view.php?id=...).

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?

It uses a specific verb (returns) and a precise resource (HanSung LMS assignment body/deadline/submission status), plus a secondary effect (downloads attachments and reports local paths). This clearly distinguishes it from the sibling 'list_tasks', which only lists items, so an agent can tell the two apart without opening either schema.

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 implicitly indicates it should be used for a single assignment (it takes a cmid), and it clearly says the tool does not submit, but it gives no explicit guidance on when to use it instead of 'list_tasks', 'read_material', or 'sync_materials'. The note that the user must submit at submitUrl is a boundary, not usage 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the description does not need to restate safety. It adds real context by disclosing the derived directory layout and the semester month boundaries (March–August vs. September–February), which the agent could not infer from annotations. It stops short of describing output shape, but an output schema exists to cover that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with what is returned, then the path pattern, then the alternative tool. Every clause carries information an agent would otherwise have to guess, and nothing is repeated from the schema or annotations.

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 an output schema and full annotation coverage, the description supplies everything the agent needs: what it returns, how the path is structured, how semesters map to months, and where to go to modify the setting. No gaps remain that would cause a misinvocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4 and there is no parameter semantics to explain. The description instead spends its words on how the returned path is composed, which is the right use of space for a no-argument tool.

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 pairing (reports the storage location and this semester's folder) and enumerates the content types covered: lecture materials, assignment attachments, recordings. It is immediately distinguishable from the sibling set_storage_dir, which the description itself names as the mutation counterpart.

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 final sentence explicitly routes the agent to set_storage_dir when the goal is to change the location, which is the only realistic competing action in this sibling group. The read-only nature of this tool versus the write nature of the alternative is therefore unambiguous.

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?

Goes well beyond the readOnly/openWorld annotations: it discloses that courses with tracking off are absent from list_tasks and sync_materials, a cross-tool behavioral consequence an agent could not infer from the schema. It also flags that course names are LMS data, not instructions — a genuine prompt-injection caveat that materially affects safe handling.

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?

Four short clauses, front-loaded with what is returned, then consequences, then the alternative tool, then the safety note. No sentence is 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?

An output schema exists, so return-shape detail is unnecessary; the description instead covers what the schema cannot — the downstream filtering effect and the untrusted-content caveat. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline applies and there is nothing further to document. The description correctly adds no parameter noise.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('내 강좌를 ... 보여준다') and enumerates the returned fields (courseId, 과목명, 종류, 추적 여부), which is exactly the scope an agent needs to distinguish it from siblings like list_tasks or get_assignment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent to set_course_tracking when the intent is to change tracking state, which is a real disambiguation case. It lacks an explicit 'when-to-use vs list_tasks' clause, but the tracking-exclusion note implies the relationship clearly enough.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description's job is to add behavioral context — and it does: scope derived from the tracking setting, default exclusion of 비교과, overdue items surfaced first when includePast is set, and an explicit data-vs-instruction warning about LMS text (prompt injection). It does not mention caching/rate behavior in prose, but the refresh parameter covers that in the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tight sentences with the primary purpose and sort order front-loaded, followed by scope, chaining, and one edge-case flag. Nothing is redundant with the title or schema, and the safety note is a single clause rather than a paragraph.

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?

An output schema exists, so return values need no explanation; what remains — which courses are in scope, default filters, sort order, how cmid chains into sibling tools, and the injection caveat — is all covered. For a 6-parameter read-only list tool with full schema coverage, nothing an agent needs to call it correctly 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%, so the baseline is 3, but the description adds meaning beyond the schema: includePast not only includes past-due items but places them first with overdue=true, and the course scope is defined by set_course_tracking rather than being free-form. Those are behaviors the schema text alone does not convey.

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 (VOD·과제·퀴즈 상태와 마감), and ordering (마감 임박 순) in one sentence, so the agent knows exactly what it returns and in what order. It also distinguishes itself from siblings by naming get_assignment and transcribe_vod as downstream consumers of the cmid values.

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?

Clear context for use: the target scope follows set_course_tracking (default excludes 비교과), and the follow-up path to get_assignment/transcribe_vod is spelled out via cmid. There is no explicit when-not-to-use or pointer to an alternative listing tool (e.g. list_courses), which keeps it below a 5.

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

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

Discloses the crucial non-obvious behavior that the tool does not block waiting for login and instead returns instructions (including a XXX-XXX verification code) that must be relayed verbatim to the user. It also covers the already-logged-in short circuit and the keychain write, adding real value beyond the readOnly/idempotent annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose in the first sentence, then modes, then the non-blocking return contract. No redundant restatement of the tool name or schema; every sentence carries information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly compensates by explaining what the tool returns (guidance text, verification code, or an already-logged-in notice) and how to handle it. Nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds the condition the schema omits — that browser mode is intended for environments without the extension and is unsupported on WSL — which meaningfully helps the agent pick a value.

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 ('한성대 LMS 세션을 받아 OS 키체인에 저장한다'), including the side effect of keychain storage. It is clearly distinguishable from the sibling `logout` and from the LMS data tools like `list_courses`.

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 explicit selection criteria for the two modes: extension is the default, browser is for when the extension is absent or on WSL. It does not explicitly tell the agent when to invoke login at all (e.g., before calling other LMS tools), 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?

Annotations already flag destructive=true, idempotent=true and openWorld=true, and the description adds real context beyond that: exactly what is destroyed (the keychain entry), that the server-side session is also killed for method=browser sessions but deliberately not for extension-linked ones. It does not say what the tool returns or whether calling it with no active session errors, which keeps it below 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, front-loaded with the primary effect, followed by the conditional exception and the follow-up action. No redundant restatement of the name or title.

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, no-output-schema tool whose annotations cover the safety profile, the description covers the important semantics: what is removed, when the server is also logged out, and how to resume work. Only the no-active-session edge case is 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?

Zero parameters, so the baseline is 4. The description still earns its place by referencing the 'method=browser' origin from the login flow, which is the only input-like distinction that governs the tool's behavior.

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: it deletes the LMS session stored in the OS keychain, and contrasts that with server session termination for browser-obtained sessions. An agent can distinguish this from login and from the browser-cookie case without inspecting any schema.

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 explicitly names the counterpart action ('다시 쓰려면 login 을 호출한다') and explains the condition under which server logout does or does not happen (extension-linked vs method=browser). It stops short of stating what happens when no session exists, so it falls just under a full when/when-not spec.

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

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the description wisely spends its budget on what annotations cannot say: per-extension behavior (md/txt/csv/json as text, pdf as original attachment, png/jpg as image), how folders behave versus files, the security boundary against links/hidden/out-of-root paths, and a prompt-injection warning that content is LMS data, not instructions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the verb and root, then compact clauses per file type, then the boundary rule, then the injection caveat — every sentence adds a distinct fact with no restatement of the name or schema.

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 carries the entire burden of explaining what comes back, and it does: folder → listing, text → text chunks, pdf → original attachment, images → images. Combined with the stated security boundary, an agent has everything needed to call it correctly and interpret the result.

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 the baseline is 3, but the description adds real meaning the schema lacks: that long text is continued via offset (matching the schema's '이전 결과의 안내대로'), and that mode is inferred from whether path is a folder or file. maxChars is left to the schema, which is fine given its inline description.

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 a named storage root, and explicitly anchors the root to the sibling get_storage_dir. It also enumerates the output shape per file type, so an agent can tell it apart from sync_materials or delete_materials without opening a schema.

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 usage context ('파일 접근이 없는 클라이언트(Claude Desktop)에서 쓴다') and hard exclusions (저장 위치 밖·링크·숨김 파일은 읽지 않는다), which is more than most. It does not, however, route the agent to a sibling when it wants to modify or remove materials — no 'when not to use this, use X instead' statement.

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

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

Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false). The description goes further by disclosing that an ambiguous match is a no-op that returns candidates instead of writing, which is behavior no annotation conveys.

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?

Four short sentences, front-loaded with the action, then the disambiguation rule, then the safety note. Nothing repeats the schema or the title.

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?

An output schema exists so return shape need not be described, and the description covers the one edge case an agent would otherwise get wrong (ambiguous match, no write). Nothing needed for a correct call 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% and both parameters are documented there, so the schema carries the basic meaning. The description still adds value by explaining that course accepts either an exact courseId or a partial subject-name match and what happens when that match is not unique.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource plus scope: turning tracking on or off for exactly one course. An agent can distinguish it from list_courses or get_assignment without opening any schema.

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 recovery path for the ambiguous case: if several courses match, nothing is saved and candidates are returned, so the caller should re-invoke with courseId. It also adds a usage rule that course names are LMS data, not instructions, which is exactly the guidance an agent needs before acting on user-supplied strings.

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

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

Annotations declare destructive and non-idempotent, and the description goes well beyond them: every change requires explicit approval in a client confirmation dialog, existing materials are moved when moveExisting is true, and headless clients fall back to a list + confirmToken round trip. This is exactly the context an agent needs before invoking a destructive 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?

The action and its example are front-loaded, and each subsequent parenthetical carries a distinct constraint (allowed folders, rejections, WSL, approval, token fallback). It is dense but nothing is redundant; the stacked parentheticals make it slightly harder to scan than it needs to be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description covers the return behavior (a list and confirmToken when no confirmation dialog is available), the approval requirement, the migration side effect, and the path rejection rules. An agent has everything needed to call this correctly.

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 the baseline is 3, but the description adds real semantics: moveExisting (default true) migrates existing materials, and confirmToken is a one-time token from the first call that must only be supplied after the user consents to the returned list. That explains the two-step protocol the schema only hints at.

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 (change the storage location for lecture materials, assignment attachments, and recordings), scopes it to those three content types, and gives a concrete example mapping an utterance to a path. It is plainly distinguishable from the sibling get_storage_dir.

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 spells out when the call is accepted (general folders under the home directory, WSL C:\Users\... paths) and when it is refused (symlinks, hidden/system folders, folders nested inside or above the current location), plus the mandatory user-approval step. It does not explicitly name get_storage_dir as the read alternative, so it falls just 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?

The description adds real behavioral detail beyond the annotations: temporary files are deleted and partial recordings are discarded, so the agent knows nothing recoverable is left behind. There is mild tension with destructiveHint=false since files are removed, but these are intermediate artifacts the tool itself created rather than user data, and the deletion is explicitly disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, no filler. The core action comes first and the side effects (temp file cleanup, no partial recording kept) follow immediately, which is the right order for an agent scanning for impact.

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 stop tool with no output schema, the description covers the action, the target, and the cleanup consequences. The only gap is that it does not say what the call returns or what happens if no transcription is running, which idempotentHint=true suggests is safe but is not spelled out.

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 applies. The description correctly says nothing about inputs, keeping attention on the effect of the call.

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 (멈춘다/stop) and resource (the transcription started by transcribe_vod), which tells an agent exactly what is halted and ties it to the sibling that starts it. It stops short of distinguishing itself from transcribe_status or asr_remove, so the differentiation against siblings is only partial.

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 reference to transcribe_vod: call it to halt a running transcription. There is no explicit guidance on what happens when nothing is running, when to prefer asr_remove instead, or any prerequisite, so the agent must infer the calling 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?

Goes well beyond annotations: incremental download semantics, no overwrite of user-edited files, no deletion of vanished LMS files (only a 'removed' report), a per-call volume cap with a more flag for resumption, and a prompt-injection caution about file names. This is rich behavioral context the annotations do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the action and destination, then layers constraints in short declarative sentences. Each sentence carries distinct, load-bearing information with no padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists, the description still covers the pieces an agent needs: incremental behavior, pagination/resumption, deletion policy, and tracking dependency. Nothing essential is missing 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% and the single 'course' parameter is fully documented there, so the description adds little parameter-level detail. It does mention that the course filter is a partial, case-insensitive match only implicitly via 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?

Names a specific verb (download/sync) and resource (LMS lecture materials, file/folder modules) and states the exact destination path layout. Clearly distinguishes itself from siblings like delete_materials and read_material, which operate on already-local files.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states that the target courses follow set_course_tracking and that an optional course filter exists, plus the rule for continuing via the more flag. It does not explicitly contrast with siblings like read_material, but the operational 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds real value beyond them: it says it reports the most recent job only, lists stage/progress/result-file as the payload shape, and warns that course/title text is LMS data rather than instructions — a genuine prompt-injection caveat.

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 core purpose and with the security caveat kept short and separate. No filler, though the injection note would read better tied explicitly to the result-file field it protects.

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 an output schema present and no inputs, the description need only justify the call: it does so by naming the reported fields and the recency scope. The one remaining gap is not clarifying whether it errors or returns empty when no transcription has run.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4; there is nothing to disambiguate. The description correctly implies a no-argument call by referring only to the implicit last job.

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+resource ('마지막 받아쓰기 작업의 상태를 보여준다') and adds the concrete fields reported (단계·진행률·결과 파일). It scopes to the LAST job, which distinguishes it from generic status checks, though it never contrasts with the adjacent asr_status or transcribe_vod 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?

The phrase '마지막 받아쓰기 작업' implies you call this after starting a transcription, but there is no explicit when-to-use statement, no note that it takes no arguments, and no routing away from asr_status. Usage is inferable rather than stated.

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

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

Beyond the annotations (idempotentHint, destructiveHint=false, openWorldHint=true) it discloses real behavior: the call returns immediately while work continues in the background, it is serialized to one job, it skips existing transcripts, and it does not affect attendance/progress records. The only gap is that it never says what the immediate return value is (job id or status object), which an agent needs for correlation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the action and destination, then alternatives, then constraints and side-effect disclaimers. Every clause carries a distinct fact — nothing restates the tool name or the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by declaring the async/background contract and where progress lives. Nearly complete for a 2-parameter job starter; the missing piece is what object is returned when it 'returns immediately'.

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 schema itself explains cmid (LMS view.php?id number) and the language enum with the auto-detection vs. forced-language tradeoff in detail. The description adds nothing about either parameter, so it sits at the baseline the schema earns.

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: it starts a background ASR transcription job for one LMS VOD and names the exact destination path pattern. It also explicitly distinguishes itself from the two closest siblings (transcribe_status, stop_transcribe), so an agent can route without opening any schema.

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 explicit when-to-use context (target lecture follows set_course_tracking) plus concrete exclusions: only one job at a time, and it skips lectures that already have a transcript. It also names the alternatives for progress (transcribe_status) and cancellation (stop_transcribe).

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