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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, non-open-world). The description adds genuine context beyond them: that it runs locally and checks the Playwright Chromium runtime specifically, which explains why it is a safe pre-flight/diagnostic step.

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 local/diagnostic framing and followed by the check performed and the usage trigger. 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?

An output schema exists, so return values need not be explained, and the tool is a parameterless, non-destructive local check. Nothing an agent needs 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?

Zero parameters, so there is nothing for the description to disambiguate; baseline of 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?

States a specific verb and resource: a local diagnostic that verifies whether Playwright Chromium can launch. This is functionally distinct from every eclass_* data sibling, so an agent can tell it apart immediately.

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 names the trigger condition: use it when other tools fail due to auth or browser errors. That is clear when-to-use guidance, though it does not state when NOT to reach for it (e.g. first-line troubleshooting vs. only after a failure).

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?

Adds substantial behavior beyond the sparse annotations: cached files matching course+original ID are skipped, video/interactive/unresolved/locked items are returned as normal exclusion states rather than errors, and only real failures set isError=true with error_code/retryable. This is rich. A minor gap remains around what local_path/file_id actually contain and permission needs.

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 purpose and scope in the opening sentence, then layers the handoff workflow, cache rule, and error semantics. Dense but every clause carries operational weight; slightly verbose but not 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?

An output schema exists, so return values need not be detailed, yet the description still explains the returned records and error contract well. For a 16-param tool the main residual gap is per-parameter meaning, but the workflow and behavioral model are complete enough to invoke 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?

With 16 parameters and only 44% schema description coverage, the description compensates for some: it explains the acquisition_policy/downloadable pairing and the file_id's role in handoff. But many parameters (source, unlock_at, module_name, resolution_reason, external_url, locked_for_user, asset_kind) receive no explanation in either schema or description, leaving real gaps.

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 (download a lecture file to the MCP server's local disk/cache) and immediately clarifies the crucial scope distinction: it does NOT deliver the file body to ChatGPT, only server-side records like local_path/file_id. It explicitly distinguishes itself from eclass_download_video and routes reading through eclass_file_handoff.

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 names when to use each alternative: use eclass_file_handoff with the returned file_id to get a public /files/<token> URL when ChatGPT needs to read the file, and use eclass_download_video for videos. It also states prerequisites (pass acquisition_policy/downloadable together) and the cache-skip condition.

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?

Adds substantial behavior beyond the annotations: results are partial-success capable, file bodies are never passed to ChatGPT, only server-side records (file_id/local_path) are returned, and the local cache is the write target. The annotations only give meta-hints (readOnly=false, destructive=false, non-idempotent), so this description carries real disclosure value about side effects and the follow-up workflow.

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?

Core purpose is front-loaded in the first sentence, followed by return-shape, follow-up workflow, input-mapping, and the video exclusion. Information-dense with almost no filler, though the four-sentence block is packed and could be line-structured for faster scanning.

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 needn't be described, and the description still covers side effects, partial success, and the two-step read workflow. It does not explicitly address what happens to locked/needs_resolution or excluded items despite instructing the caller to pass lock fields, leaving a minor gap for edge-case inputs.

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 baseline is 3. The description goes beyond that by telling the caller how to construct the 'materials' entries (map eclass_get_materials id/title → file_id/display_name, and pass classification/source/lock fields together), which meaningfully guides population of a complex nested array.

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 ('여러 파일 자료를 ... 한 번에 다운로드합니다') with an explicit target destination (MCP 서버 로컬 디스크/캐시) and partial-success semantics. It also names the sibling it is not (eclass_download_video) and implicitly distinguishes itself from the single-file eclass_download_file via 'batch/한 번에'. An agent can tell it apart from siblings 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 alternatives and the conditions that select them: read the file yourself → call eclass_file_handoff and browse the /files/<token> URL; video content → eclass_download_video. It also directs the caller to source inputs from eclass_get_materials. When-to-use and when-to-use-something-else are both covered.

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 only give write/non-destructive flags, but the description adds substantial context: a 30-minute timeout, that video bytes are NOT relayed to ChatGPT, that playback/progress/attendance APIs are not touched, and how the cache records the entry. This is exactly the beyond-annotations detail an agent needs for a write-to-disk 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?

Front-loaded with the core action and constraint (network, verify, download, 30-min limit), followed by what it deliberately avoids and the sibling routing. Dense but each sentence carries operational information; only the file_id/remove_download clause feels slightly packed into one line.

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, return values need not be explained, and the description fully covers the behavioral constraints (timeout, no byte relay, no tracking API calls) plus the cross-tool workflow for external delivery and cache cleanup. Nothing needed 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 schema already documents all six parameters and the baseline is 3. The description adds real value by specifying the cache key format 'video:<video_id>' for the video_id parameter, connecting it to handoff and removal semantics beyond what the schema states.

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+scope: verifies a direct MP4 video seen in OCS metadata and downloads it to the MCP server's local disk/cache. It explicitly differentiates from sibling behavior by noting it does NOT call playback/progress/attendance APIs, and names eclass_file_handoff for the external-receipt case.

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?

Clearly frames when to use it (need the video bytes cached locally) versus the alternative path (eclass_file_handoff for a public /files/<token> URL) and the removal path (eclass_remove_download with the video:<video_id> key). The conditions that select each sibling are explicit rather than inferred.

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 mark this as destructiveHint=true and non-idempotent, and the description explains the mechanism: writing to output_path refuses to overwrite an existing file unless overwrite=true. It also flags the [네트워크] network dependency. It does not explain readOnlyHint=false or other side effects, but the key destructive behavior is 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?

Three tight sentences with the scope and output formats front-loaded, then the alternative-usage hint, then the file-saving caveat. No filler, though the parenthetical enumeration is dense.

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-format details are not needed. Combined with the annotations, the description covers scope, alternatives, and file-write behavior adequately for a 5-parameter export tool; only the exact structure of the snapshot contents is left implicit.

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 five parameters are already documented in the schema (format enum, overwrite default false, output_path optional, include_grades default false). The description only restates the overwrite-refusal semantics already present in the schema, adding no new parameter meaning beyond that baseline.

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 (내보냅니다/export) and resource (한 강의의 현재 상태) with an explicit enumeration of what is included (course info, assignments, announcements, materials, download status, optional grades). The scope 'one course, all at once' clearly distinguishes it from the many single-resource siblings like eclass_get_assignments or eclass_get_announcements.

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

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

Explicitly says to use this single call instead of repeated individual queries when surveying a whole course, which is real routing guidance. It does not name specific sibling tools or state when NOT to use it (e.g., when only one resource is needed), so it falls short of a full 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?

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses substantial behavior: the 25MB rejection threshold and its env-var override, the localhost-vs-public URL accessibility constraint, and the required configuration for public handoff. These are exactly the operational traits an agent needs and are not in the annotations.

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

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

The core purpose is front-loaded and every sentence carries information (limits, config, sourcing). It is somewhat dense with parenthetical env-var names, but nothing is 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?

With an output schema present, return values need no explanation, and the description still covers the source of the input, the size cap, and the networking prerequisite. 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% for the single parameter, and the schema already documents the file_id source and the 'video:<id>' format. The description's mention of where file_id comes from largely duplicates the schema, 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?

The first sentence states a precise verb+resource: it issues a /files/<token> URL without attaching the file body to the response, which is the key distinguishing behavior from the eclass_download_file/eclass_download_video siblings. It does not name those siblings explicitly, so the contrast must be inferred from the 'no body' phrasing.

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 usage path: obtain file_id from eclass_search_downloads/eclass_list_downloads, and if a publicly reachable handoff is needed, set ECLASS_HANDOFF_BASE_URL and re-call. It explains the localhost/127.0.0.1 restriction but never states when to prefer this tool over the direct-download siblings.

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, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description's '[네트워크]' tag is the only added behavioral signal (presumably a live network call rather than a cached read), but it is cryptic and unexplained, so the added value is thin.

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 short sentence with no filler and the resource front-loaded. It is efficient, though arguably under-specified rather than optimally sized for a tool that must be distinguished from 25 siblings.

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 annotations cover behavior, so the description need not explain returns. Still, for a read tool in a crowded eclass namespace it omits the one thing structured fields cannot supply: what the '[네트워크]' qualifier means and when this call is preferable to its siblings.

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 both parameters (limit with default 20, course_id) are documented in the schema itself. The description adds no format, range, or sourcing information beyond what the schema provides, 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 ('가져옵니다'/fetch) and resource ('강의 공지사항'/course announcements), which is enough to separate it from get_assignments, get_grades, and get_materials. However, it offers no explicit differentiation from close siblings such as eclass_get_courses, and the '[네트워크]' prefix is left unexplained.

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 tool, what prerequisites exist (e.g. whether course_id must come from get_courses), or which alternative to pick. The only implicit hint is the '[네트워크]' tag, which is never defined.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered for free. The description adds only the '[네트워크]' network-requirement tag and the returned-field list (which an output schema already carries), and says nothing about auth/permission needs or caching/freshness behavior. It adds light value over the annotations, not rich context.

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 action and scope, followed by the field list and the usage note. The parenthetical enumeration of return fields is somewhat long but earns its place as a scan-able summary; no filler sentences.

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 the description needn't explain return values, annotations cover the safety profile, and both parameters are schema-documented with 100% coverage. The only mild gap is the absence of explicit sibling routing, but for a simple two-param read tool the definition is otherwise sufficient to call 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 description coverage is 100% and both parameters (course_id, assignment_id) are documented in the schema, including a hint that assignment_id can be found via eclass_get_assignments. The description adds no parameter-level detail, 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 names a specific verb and resource ('단일 과제의 상세 정보를 가져옵니다' – fetch detail for a single assignment) and enumerates the concrete fields returned (submission type, deadlines, points, allowed extensions, submission status, attempt count, score). The '단일' (single) scope implicitly distinguishes it from the bulk-list sibling eclass_get_assignments, 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?

'과제 제출 전 확인용' gives a clear when-to-use context: check this before submitting, which positions it naturally ahead of eclass_submit_assignment. There are no explicit exclusions or named alternatives, but a competent agent can infer the workflow placement.

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, idempotentHint, and non-destructive, but the description adds real behavioral context beyond them: course_id causes submission_types to be included, LTI (external_tool) assignments cannot be submitted via the API, and the days_ahead cap is lifted for a specified course. These are non-obvious traits an agent could not infer from structured fields.

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 dense, front-loaded sentences with no filler; the network tag and core operation lead, followed by the conditional caveats. Efficient, though the parenthetical LTI note packs multiple concerns into one clause.

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 described, and annotations cover the safety profile. The description covers the key parameter interactions; only minor gaps remain (behavior when course_id is omitted, pagination/result-size handling).

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 by explaining cross-parameter interaction: course_id pulls in submission_types and removes the days_ahead upper bound. That interaction is not derivable from the per-parameter schema text alone.

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

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

The description gives a specific verb and resource ('과제 및 퀴즈 목록을 가져옵니다' – fetch assignment and quiz list), which is clearly a listing operation distinct from the sibling eclass_get_assignment_detail. It does not explicitly name the sibling, so it stops short of a top-tier differentiation score.

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 through condition-dependent behavior (specifying course_id changes the result shape). There is no explicit statement of when to choose this over eclass_get_assignment_detail, and no exclusions 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?

Annotations already cover read-only, idempotent, non-destructive and closed-world traits. The description adds genuinely useful behavior beyond them: it is a network fetch that replaces the current course cache, it fails loudly instead of misclassifying when the semester is ambiguous, and the training scope is deliberately conservative. Auth/rate-limit behavior is still unstated.

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

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

Front-loaded with the '[network]' tag and the core action, then four sentences that each carry distinct information (scope semantics, cache replacement, failure mode, fallback). Dense but every sentence earns its place; 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?

An output schema exists, so return values need no explanation, and the single-parameter surface is fully covered. The failure mode and cache-replacement side effect are disclosed, leaving only minor gaps such as authentication or rate-limit expectations for a network call.

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

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

Schema coverage is 100% and the single enum is documented, so baseline is 3. The description goes further by explaining the classification logic behind each scope (term name/ID/date detection, Canvas available/completed enrollment history, conservative training classification), adding real meaning beyond the terse schema strings.

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 (fetch fresh) and resource (e-Class course list), and breaks the result set into three named scopes with distinct contents. It implicitly distinguishes itself from eclass_get_courses_cached by noting that it replaces the current cache, but never names that sibling explicitly, so it falls just short of a clean 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?

Gives explicit conditions for choosing each scope (current = this semester's regular courses; all = full Canvas enrollment history; training = prevention/mandatory education) and a concrete fallback: if the semester cannot be determined, use scope=all rather than mislabeling. It stops short of pointing to the cached alternative tool, so no explicit when-not.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile and the no-network property are partly covered. The description still adds real behavior beyond that: exact lookup by course_id also searches previous-semester catalogs, and stale/empty cache states require a refresh via another 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?

Four short sentences, front-loaded with the local/cache scoping and the mapping use case, then the lookup nuance, then the refresh fallback. No filler, though the '[로컬]' tag and the refresh sentence could be tightened slightly.

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, return values need not be explained, and the annotations carry the safety profile. The description covers staleness, refresh routing and the exact-lookup nuance, leaving only minor gaps such as behavior when course_id matches nothing.

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% for the single course_id parameter, so the baseline is 3. The description adds genuine meaning beyond the schema by explaining that a course_id exact lookup reaches into previous-semester catalogs, which is not conveyed by the parameter 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?

The description states a specific verb and resource ('캐시의 현재 학기 강의 스냅샷을 조회') and immediately scopes it as local/cache-only with no network calls. It also explicitly distinguishes itself from the sibling eclass_get_courses, 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?

It names the intended use case (course_id ↔ 강의명 mapping without network calls) and gives an explicit fallback condition: if the cache is empty or the semester has changed, refresh via eclass_get_courses's default current query. Both the when-to-use and the alternative are spelled out.

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 read-only, idempotent, non-destructive, non-open-world behavior. The description adds valuable context beyond that: it returns no file body, it reads only the local cache, and course names come from the local course cache. It does not discuss pagination or freshness/staleness of the cache, which would push it higher.

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 core purpose, followed by the non-return of file contents and the routing to alternatives. Three sentences, each earning its place, though the file-contents caveat is stated twice in slightly different forms.

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-value details need not be repeated, and annotations cover the safety profile. Combined with the explicit non-content and local-cache caveats, the description is nearly complete; only cache staleness or refresh behavior 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?

Schema description coverage is 100% for the single optional course_id parameter, so the schema already documents it. The description adds only the tangential note that course names resolve via the local course cache, not parameter-level detail. Baseline 3 applies when the schema carries the semantics.

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 summarizes per-course download status from the MCP server's local cache. It clearly distinguishes itself from file-fetching siblings by stating it does not return file contents.

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 see file contents, find file_id via eclass_search_downloads/eclass_list_downloads and issue a public URL with eclass_file_handoff. Both the alternative and the condition that selects it are named.

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 readOnly/idempotent annotations, it discloses the matching priority (SIS course_code+분반 exact match, then lecture-name fallback flagged via matched_by) and the failure contract (reason=EXACT_MATCH_NOT_FOUND plus a candidates list for the caller to decide). The refresh+term network side effect is also stated.

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?

Purpose is front-loaded in the first sentence, followed by omission behavior, matching logic, failure handling, and the refresh caveat. Every sentence carries information, though the density is high enough that it reads as a compact spec rather than a quick orientation.

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, yet the description still explains the matched_by discriminator and the EXACT_MATCH_NOT_FOUND/candidates failure shape, which is what an agent needs to interpret a result. Nothing required to invoke the tool 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 cross-parameter semantics the schema cannot express: omitting course_id/query widens results, course_id changes the matching algorithm, and refresh only works when term is supplied.

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 the '[로컬]' marker distinguishes it from the network-syncing sibling eclass_sync_exam_schedules. An agent can tell it apart from the sync and syllabus 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 concrete conditional usage: omitting course_id/query returns the full term/exam_type schedule, specifying course_id triggers SIS exact-match with a normalization fallback, and refresh=true requires term to sync first. It stops short of naming sibling tools explicitly as alternatives, but the conditions for each mode are 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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds the '[네트워크]' marker signaling a live network fetch, which is genuinely useful given cached siblings exist, and it scopes the return content beyond what the annotations say.

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 tight sentences with no filler; the tool action and its output scope are front-loaded, so an agent can parse it in a single pass.

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 annotations cover the safety profile, so the description need not explain return values; it still summarizes the payload usefully. Only the missing sibling differentiation keeps it from fully closing the 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% and both parameters are documented in-schema (course_id filters courses, include_assignments toggles assignment detail), so the baseline is 3. The description does not add syntax or defaulting 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+resource ('성적을 가져옵니다') and enumerates the returned content (course-level current/final scores plus per-assignment scores, submission status, grading time). It is clear on its own, but it does not explicitly distinguish itself from close siblings like eclass_get_assignments or eclass_get_courses_cached.

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 tool's purpose; there is no explicit when-to-use, when-not-to-use, or named alternative. The '[네트워크]' prefix hints it is a live call rather than a cached read, but the description never states this trade-off against eclass_get_courses_cached.

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 indicate read-only, non-destructive, idempotent behavior, but the description adds substantial context beyond annotations: multi-source aggregation and merging rules, partial-failure return behavior, exclusion of not_open placeholders, acquisition_policy handling for locked Canvas items, ExternalTool classification and LTI confirmation, and an explicit no-download boundary.

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

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

The purpose is front-loaded, followed by source priority, edge cases, no-download boundary, and downstream flow. It is long but mostly earns its space for a complex aggregation tool; however, some content repeats the schema descriptions and output shape despite an existing output 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?

Complete for a complex cross-source material metadata tool: it covers default and exceptional source handling, merging rules, partial failures, return shape, downstream file-tool boundaries, and important Canvas/Chung-Ang edge cases. No critical invocation context appears 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 input schema already explains sources defaults, files behavior, and resolve_external LTI confirmation. The description largely repeats those points and adds little parameter-specific format or syntax guidance, so the baseline 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?

States a specific verb and resource: fetching course material list/metadata, with source domains enumerated in parentheses. It distinguishes itself from sibling tools by explicitly saying it does not download file bodies or attach to ChatGPT, and routes download/attachment needs to eclass_download_file, eclass_download_materials_batch, and eclass_file_handoff.

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 source priority (modulebuilder, courseresource, announcements, modules, external), when to include files last (Files tab visible or explicit user request), and when not to treat files 401 as token expiry. It also states the downstream condition for passing items to file tools only when downloadable=true and acquisition_policy=download, and names alternatives for actual downloads.

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, idempotentHint, destructiveHint=false and a closed world, so the safety profile is fully covered. The description adds that the return is structured, but discloses nothing extra about auth needs, rate limits, or failure behavior; a 3 is appropriate with annotations doing the heavy lifting.

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 tightly packed sentences with no waste: purpose first, then the sourcing instruction for inputs. Fully front-loaded and appropriately sized.

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 structure needn't be explained, and annotations cover the safety profile. The description covers purpose and where to source inputs, which is sufficient for a detail-fetch tool, though the undocumented parameters remain 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?

Schema description coverage is low (33%): only clssno1 and sbjtno1 carry field labels, while year, term, sust and campcd are undocumented. The description partially compensates by telling the agent the values come from the eclass_search_syllabus result row, but adds no per-field meaning for the undocumented parameters.

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 (returns a specific course's structured syllabus body) and enumerates the returned content (textbook, evaluation ratios, weekly schedule, professor info). It also implicitly differentiates from sibling eclass_search_syllabus by telling the agent to feed this tool that sibling's result rows.

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 workflow instruction: take the input keys directly from an eclass_search_syllabus result row. This tells the agent when/how this tool is used (detail fetch after a search), but there are no explicit exclusions or when-not-to-use conditions.

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, non-destructive, closed-world), and the description adds genuinely non-obvious behavior: it reads a local cache and never returns file bodies, with the handoff workflow needed to actually read a file. It does not discuss pagination or cache staleness, which would be the next useful detail.

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 local-cache scope, then the critical 'no file bodies' constraint, then the alternatives. Every sentence carries distinct information with no 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?

An output schema exists, so return shapes need not be described; the description instead covers the non-obvious gaps (local cache source, absence of file content, handoff path, sibling routing). Nothing needed 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% and the single course_id parameter is fully documented in the schema. The description adds no format or filtering semantics for course_id (and its 'lists all records' phrasing slightly understates that filtering is possible), 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 ('lists all download records stored in the local MCP cache') with an explicit scope qualifier ('[local]'). It also names the sibling tools it must not be confused with, so an agent can distinguish it from eclass_search_downloads and eclass_get_download_status without opening schemas.

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: conditional filtering goes to eclass_search_downloads, per-course summaries go to eclass_get_download_status, and reading a file requires eclass_file_handoff with a file_id. Both the when-to-use and the alternatives are stated outright.

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 safe-read profile (readOnlyHint=true, idempotentHint=true), but the description adds a real behavioral detail they do not: refresh=true reaches out to the central university (중앙대) list and rewrites the department candidates. That side effect is worth knowing before passing refresh=true, though there is no mention of cost/rate limits or how the refreshed list is persisted.

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

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

Two compact sentences with the core purpose front-loaded and the conditional flag behavior immediately after. 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 an output schema present, return values need not be explained, and annotations cover the safety profile. Purpose and the single parameter's effect are both covered; the only gap is that the [로컬/네트워크] tag is not unpacked 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 coverage is 100% and the single parameter is already described, so baseline would be 3. The description goes slightly further by explaining what refresh actually re-fetches and from where (단과대 후보 from 중앙대 목록), adding meaning beyond the schema's generic "다시 탐색".

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 ("시험 공지 소스 목록을 조회합니다" = retrieve the list of exam notice sources) plus a scope tag ([로컬/네트워크]). It is clearly distinguishable from siblings like eclass_sync_exam_schedules or eclass_get_exam_schedule, though it does not explicitly name those 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?

The conditional "refresh=true면 ... 갱신합니다" tells the agent what the flag does but not when to choose this tool over eclass_get_exam_schedule or eclass_sync_exam_schedules. Usage is implied by the purpose rather than stated as when/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 destructiveHint=true and readOnlyHint=false. The description meaningfully extends this by specifying exactly what is destroyed (local DB record only, not the on-disk file) and that re-download remains possible — genuinely clarifying the scope of a destructive op. Auth, rate limits, and the interaction of the two optional params are unaddressed.

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 compact sentences, each earning its place: scope of deletion, re-downloadability, and the file_id format. The most important constraint (files remain) is front-loaded.

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, return values needn't be described, and the annotations cover the safety profile. The description covers scope and id format adequately, though it leaves the two optional params' mutual exclusivity and the neither-provided case 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 coverage is 100%, so baseline is 3, but the description adds real meaning beyond the generic schema labels by documenting the video file_id format ('video:<video_id>'). It does not clarify whether file_id and course_id are mutually exclusive or what happens when neither is supplied.

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 (삭제/remove) and resource (다운로드 기록/DB record) and immediately scopes it: only the DB record is removed, disk files remain. An agent can distinguish this from real file deletion among the download siblings (eclass_download_file, eclass_file_handoff) without opening the 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 line '삭제 후 재다운로드가 가능합니다' implies a use case (clearing history to re-download), but there is no explicit when-to-use/when-not or named alternative among siblings. Usage 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?

Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds behavior beyond them: it operates on the local cache only and does NOT return file contents. The handoff workflow for actually viewing a file is non-obvious and valuable. No contradiction with annotations.

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

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

Front-loads the [로컬] scope and the core action, then the key behavioral caveat (no file contents), then the workflow, then sibling alternatives. Every sentence carries distinct, necessary 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?

An output schema exists, so return-value explanation is unnecessary. The description covers scope, output limitation, downstream workflow, and sibling routing — everything an agent needs 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 description coverage is 100%, so all 7 parameters are already documented. The parenthetical (filename/course/extension/source/date range) merely restates the filterable dimensions the schema defines, adding no syntax or format detail. 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+resource with explicit scope: filter-searching only the MCP server's local cache of downloaded file records. It distinguishes itself from eclass_list_downloads and eclass_get_download_status by name, so an agent can select it 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 alternatives: full listing → eclass_list_downloads, per-course summary → eclass_get_download_status. It also explains the downstream workflow (use file_id with eclass_file_handoff to get a /files/<token> URL and open it via browsing), which is exactly the routing an agent needs.

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 readOnly, idempotent, non-destructive and non-open-world, so the safety profile is covered. The description adds real behavioral context beyond that: the default-to-current-term behavior when year/term are omitted and the shape of the candidate list 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?

Three short sentences, front-loaded with purpose, then default behavior, then return content and routing. No filler; each sentence contributes actionable 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 read-only search tool with an output schema present, the description covers purpose, default term, return content and the downstream call, which is nearly complete. The remaining gap is clarifying how the 'by' search mode (subject vs professor) changes behavior.

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

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

With 75% schema description coverage, the schema already documents year and term, and the description largely repeats the year/term default already stated in the schema. The 'by' enum (subject/professor) is never explained in the description, so it adds little semantic 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 (검색/search) and resource (강의계획서/syllabus), including the [mportal] scope. It explicitly distinguishes itself from the detail sibling eclass_get_syllabus by describing itself as returning a candidate list rather than full details.

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?

Clearly routes the agent: it returns candidates so the caller can decide and then call eclass_get_syllabus for details, and it states the year/term default. It does not, however, say when to pick this over other search siblings like search or eclass_get_courses.

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 readOnlyHint=false, and the description goes well beyond that: it discloses the dry-run default that prevents real mutation, the resubmission guard flag, the unsupported LTI case, and a UI fallback limited to a single file. These are concrete operational behaviors 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?

Four tightly packed sentences with zero filler; the network tag and action lead, followed by the safety default. Slightly dense, but each clause (dry_run, confirm_resubmit, LTI limits, fallback) carries distinct 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 mutation tool with 7 parameters, the description covers prerequisites, unsupported cases, safety defaults, and fallback behavior. An output schema exists, so return values need no explanation, and the annotations already carry the safety profile.

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 cross-parameter relationships the schema cannot express: file_paths maps to online_upload, body maps to online_text_entry, and confirm_resubmit gates resubmission. That is real semantic value beyond the per-field descriptions.

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 ("과제를 제출합니다" / submits the assignment) and immediately scopes what submission types are valid. It also names the sibling to consult first (eclass_get_assignment_detail), so an agent can separate it from read-only siblings like eclass_get_assignment_detail or eclass_get_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 explicit when/when-not: default dry_run=true validates without submitting, resubmission requires confirm_resubmit=true, and external_tool (LTI) assignments cannot be submitted at all. It also routes the agent to a precondition check and names a fallback path, leaving little 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?

Annotations mark this as a non-read-only, non-idempotent write, and the description adds real value beyond them: it discloses the exact source values written (source=learningx_sis), the SIS-failure fallback (source=canvas_only) and that an sis_error is included. That fallback/overwrite behavior is not derivable from the annotations or 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?

Two dense sentences with the network tag and purpose front-loaded, followed by the primary path and the failure path. It is efficiently structured, though the bracketed [네트워크] tag and multiple slash-delimited field lists make it slightly cramped.

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, and the description fully covers the sync semantics, source tagging, and error fallback. It could still mention permission/auth or cache-write implications, but for this tool it is largely complete.

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

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

Schema description coverage is 100% and both parameters (force, course_id) are documented in the schema itself. The description adds no syntax or format detail beyond what the schema provides, 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 names a specific verb (동기화합니다 / sync-save) and resource (강의 메타데이터 / course metadata), and specifies the upstream source (LearningX SIS). It also scopes its purpose to exam-schedule matching, which distinguishes it somewhat from generic course tools, though it never names a sibling tool 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 phrase '시험 시간표 매칭용' (for exam schedule matching) implies the context in which to reach for this tool, but there is no explicit when-to-use/when-not guidance and no mention of the obvious alternative eclass_sync_exam_schedules or eclass_get_courses. Usage is only inferable.

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 (readOnly=false, idempotent=false, destructive=false), and the description adds genuinely useful behavior beyond them: it writes to a separate exam DB and, critically, discloses graceful degradation ('pdftotext가 없으면 문서만 저장하고 파싱 실패를 partial_failures에 남깁니다'). It omits auth requirements and rate/network failure handling, 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?

Two dense sentences with no filler; the core action is front-loaded and the fallback behavior is appended. It is compact and appropriately sized, though the bracketed [네트워크] prefix is minor overhead.

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 5-param network sync with full schema coverage and an output schema, the description covers the essential action and the notable fallback path (partial_failures), so return values need not be spelled out. What is missing is when this should run relative to the get_exam_schedule sibling and any permission prerequisites.

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 term formats, force, exam_type enum, course_id and source_url. The description references the term and midterm/final concept but adds no syntax or precedence detail 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?

The description names a precise verb chain (탐색 → 다운로드/정규화 → 별도 시험 DB에 저장) and a concrete resource (중간/기말시험 공지 PDF 시간표). It is clearly distinguishable from the sibling eclass_get_exam_schedule (read/retrieve) because it explicitly describes syncing and persisting to a separate DB.

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 scope ('지정한 학기의 시험 공지'), which suggests running before retrieval, but it never names when to use it versus eclass_get_exam_schedule or eclass_list_exam_sources, and states no prerequisites or exclusions. The [네트워크] tag hints at network requirements but is not framed as a gating condition.

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 (readOnlyHint/idempotentHint/destructiveHint already cover the safety profile), the description discloses real operational behavior: download entries return no body, HTTP transport only returns publicly configured /files/<token> URLs, ChatGPT must open those URLs via browsing, and localhost URLs require the operator to set ECLASS_HANDOFF_BASE_URL. This is substantial context an agent cannot get from the schema or 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?

Roughly four dense sentences, front-loaded with the core behavior before the edge cases. Every sentence carries operational information about URL handling, so there is little waste, though it is on the longer side.

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-only tool that already has an output schema (so return values need not be described), the description covers the important gaps: what kind of input id is expected, what it will not return, and the transport-dependent URL behavior. 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?

There is a single parameter with 100% schema description coverage, and the schema text ('search 결과의 id') is identical to what the description provides, so no additional meaning is added. The baseline of 3 applies when the schema already documents the 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?

The description states a specific verb and resource: it takes an id from search results and returns the original/detailed document text, and it explicitly labels itself a read-only fetch tool. It differentiates itself from download-oriented siblings by stating that eclass://download/<file_id> items return no file body, though it does not name a specific alternative tool.

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

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

It establishes the usage context (invoke with the id produced by search) and gives a clear exclusion: download items do not yield file content, and file reading must be done by browsing the URL rather than through an MCP tool. It stops short of naming a specific sibling tool to use instead in those cases.

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 readOnly/idempotent/non-destructive/non-open-world, but the description adds real behavioral nuance beyond them: download hits are metadata (file_id/local_path) not content, and notice/material body scanning is deliberately restricted to courses whose names match the query for cost control. That hidden scoping limitation is exactly the kind of trait an agent cannot infer from 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?

Five sentences, each carrying distinct information (scope, safety posture, metadata caveat, file-access workflow, cost-control limitation), with the purpose front-loaded. Slightly longer than strictly needed but 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 values need not be described, and the description covers scope, the metadata-vs-content distinction, the file retrieval path, and a non-obvious coverage limitation. Only the absence of sibling-tool routing keeps it from being fully 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?

With one parameter at 100% schema coverage, the schema already documents 'query' as 검색어, so the baseline is 3. The description adds no syntax, matching rules, or format guidance for the query string that would go 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 (통합 검색) and enumerates the exact resources covered (강의, 과제, 공지, 자료, 강의계획서, 다운로드 기록), so the agent knows the scope without opening a schema. It does not explicitly distinguish itself from sibling search tools like eclass_search_downloads or eclass_search_syllabus, which slightly caps the score.

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 identifies itself as a read-only connector-compatible tool and routes the agent to fetch or eclass_file_handoff when the actual file body is needed, which is useful context. However it never says when to prefer this unified search over the narrower sibling search tools, leaving the primary selection decision to inference.

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