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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful context beyond that: results are computed from already-cached data (not a live upstream fetch) and include a stated calculation methodology, plus the caveat that it does not replace official school recognition. It omits whether stale cache affects results, but the added transparency is solid.

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

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

One dense, front-loaded sentence that leads with the computation and its inputs, then appends the methodological caveat. Nothing is padded, though the semicolon-separated clauses require careful parsing.

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 the data source and the non-official caveat. The remaining gap is the undocumented semester parameter, which is material for a calculation tool whose behavior changes depending on whether it is set.

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

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

Schema description coverage is 0% and the single 'semester' parameter (with an empty-string default) is never mentioned in the description. Worse, the phrase '按已缓存的全部成绩' ('all cached grades') suggests an unscoped computation, leaving the agent to guess how semester filtering interacts with the summary.

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

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

States a specific action (calculate credit-weighted average score/GPA) on a specific resource (all cached grades), which clearly differentiates it from the raw-data siblings like get_grades and get_exams. It stops short of naming an alternative tool, but the verb+resource pairing is unambiguous.

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

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

Implies usage context by noting the result derives from cached grades and is not an official school determination, which tells the agent this is an informational derivative metric. However, it never says when to prefer this over get_grades, nor whether the empty-default semester should be supplied to scope the calculation.

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 closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: it reports per-source login state and cache/freshness times, and asserts it will not force configuring all accounts at once, i.e. no config side effects.

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

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

A single compact sentence with the primary content front-loaded and the usage reassurance trailing after a semicolon. Every clause carries information; only the second clause is slightly oblique.

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 need not enumerate return fields, and strong annotations carry the safety profile. For a zero-parameter status tool the description is adequate, though it could state more explicitly when to prefer this over open_setup or refresh_source.

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 for the description to disambiguate. Schema coverage is 100% (vacuously) and no parameter semantics are needed.

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

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

The description names a specific resource set ('可用校园功能', per-source '登录状态', '缓存时间'), so the agent knows this returns a capability/status overview rather than notices, grades, or courses. It does not explicitly name which sibling it supersedes, but the content is distinct enough to separate it from refresh_source and the various get_* tools.

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 clause '不会要求一次配置全部账号' hints at the usage context (safe to inspect without configuring every account, useful before other calls), but there is no explicit 'call this when...' or 'use X instead' routing. Usage is implied 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description usefully adds that results come from a link cache and that the tool will not submit assignments or mutate school records. The cache mention implies possible staleness, which is behavior beyond 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?

Two short sentences, front-loaded with purpose followed by the boundary condition. No filler, nothing 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?

An output schema exists so return values need not be explained, and the read-only nature is well covered. However, four parameters with zero documentation leave the calling contract underspecified for what is otherwise a simple lookup tool.

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

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

Schema description coverage is 0% across four parameters (limit, query, offset, source), and the description supplies no meaning for any of them. With no enum hints and no per-parameter text, an agent must guess what 'source' accepts and how 'query' is matched.

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 (查询/query) and concrete resources (课程资料, Moodle/ELC 活动链接缓存), which distinguishes it from siblings like get_courses, get_grades and get_exams. The scope is clear, though the phrase '活动链接缓存' is slightly opaque about what exactly is returned.

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 second sentence gives a negative boundary ('不会提交作业或修改学校记录'), which implies when-not usage, but it names no alternative sibling for when a different tool is needed. Usage is implied rather than explicit.

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 closed-world. The description adds genuine context beyond that: each source logs in independently and the latest available semester is used. It still omits caching/refresh semantics or pagination behavior, so it is useful but not rich.

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

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

A single compact sentence with no filler, and the resource is front-loaded. It is efficient, though the behavioral clause is packed in rather than separated for scanability.

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. However, with 0% parameter coverage and no usage guidance, the description is thinner than a four-parameter, multi-source read tool warrants.

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

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

Schema description coverage is 0% across four parameters (limit, query, offset, source), so the description carries the full burden of explaining them. It only hints at 'sources' generally and never maps to the source/query/limit/offset arguments, leaving them undocumented in both places.

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

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

States a specific verb (读取/read) and resource (MySTU/雨课堂课程缓存), which distinguishes it from siblings like get_course_resources and get_grades. It is clear about scope, though it does not explicitly contrast itself with the nearest sibling.

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 explains source-login behavior and semester selection but gives no when-to-use guidance and names no alternatives (e.g. get_course_resources vs get_courses). The agent must infer the selection 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 read-only/idempotent/no-open-world safety. The description adds critical behavioral context beyond annotations: the data is a cache (缓存) and the school page is authoritative, warning that results may be stale or unofficial.

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

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

A single front-loaded sentence that states purpose, return contents, and a freshness caveat with zero wasted words.

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

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

For a simple read-only tool with an output schema, the description adequately covers purpose and data freshness. However, it leaves all parameter behavior (limit, query, offset) unexplained despite 0% schema coverage, which is a clear gap.

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

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

Schema description coverage is 0% for all 3 parameters (limit, query, offset), and the description does not mention any parameter semantics at all. It fails to compensate for the missing schema documentation.

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

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

States a specific verb (读取) and resource (本人考试安排缓存), and clarifies the content includes 考场/时间等信息. It distinguishes from siblings like get_schedule/get_grades by focusing on exams, though it does not name an alternative 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?

Provides only a data-reliability caveat (以学校页面为准), not when to use this tool versus get_schedule or other siblings. No explicit conditions, exclusions, or alternatives 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 declare the safe read-only/idempotent profile, so the description earns credit for adding two things they don't: the data comes from a cache (possible staleness) and a prior local login plus 'refresh jw' is required. It stops short of describing pagination or staleness semantics.

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: purpose first, precondition second. No filler, no repetition of 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?

With an output schema present, return values needn't be explained, and annotations cover safety. Purpose, precondition, and the key query semantic are covered; only pagination behavior and cache-staleness implications are 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 coverage is 0%, so the description carries the param burden. It clarifies the non-obvious 'query' param as a course/semester keyword filter, but says nothing about 'limit' or 'offset', leaving two of three params to inference from standard naming.

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 ('读取本人教务成绩缓存' – read one's own grade cache) and adds scope ('本人' = own grades). The word '缓存' (cache) usefully distinguishes it from a fresh fetch, though it doesn't explicitly name a sibling for contrast.

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 real precondition ('需要先在本地登录并刷新 jw'), which tells the agent what must happen before calling. However it never states when to prefer this over alternatives such as refresh_source or get_exams, so routing guidance is only implied.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true). The description adds genuinely useful context beyond them: refresh pulls from a cached school link and arbitrary URLs are rejected. However it never explains what refresh mutates (cache state) or how it relates to the non-read-only annotation, which the agent needs to reconcile.

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

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

A single compact sentence, front-loaded with the tool's function and then the refresh constraint. Every clause earns its place, though the punctuation-heavy semicolon structure slightly compresses two distinct facts.

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 explanation is not required, and the core purpose plus refresh behavior are covered. Gaps remain around item_id's origin (how it is obtained from search_notices) and any pagination or error behavior, leaving the definition adequate but not complete.

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

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

Schema description coverage is 0%, so the description must carry the load. It gives real meaning for refresh (source is the cached school link, not an arbitrary URL) but says nothing at all about item_id, leaving half the parameters undocumented anywhere.

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: 读取通知正文及附件列表 ('read the notice body and attachment list'), which clearly distinguishes it from search_notices and read_attachment. It is a clear, unambiguous purpose, though it does not explicitly name the sibling it differs from.

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?

Provides an implied usage cue via refresh=true ('从已缓存的学校链接获取正文') and one exclusion ('不接受任意 URL'), but never states when to call this tool versus search_notices or read_attachment, nor any prerequisites. Usage is inferable rather than prescribed.

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, non-destructive, and closed-world behavior, so safety is covered. The description adds genuinely useful non-annotation context: this reads a local cache and its data covers only the past 7 days through the next 31 days, which tells the agent about freshness and coverage limits.

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

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

A single tight sentence that front-loads the action, resource, and data window with no filler. Every clause carries information.

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

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

An output schema exists, so return values need no explanation, and annotations cover the safety profile. However, with three undocumented parameters at 0% schema coverage, the definition is incomplete on the input side and leaves the agent guessing about pagination and filtering.

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

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

The schema has 0% description coverage and three parameters (limit, query, offset) with only titles and defaults. The description says nothing about any of them, so it fails to compensate for the schema gap; an agent cannot tell what query filters on or how limit/offset behave.

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 (读取 MySTU 个人日程 = read MySTU personal schedule) and identifies the data source as the local cache, plus the temporal coverage window. It does not explicitly differentiate itself from similar siblings such as get_tasks or get_exams, so it falls short of a 5.

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

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

There is no guidance on when to choose this tool over alternatives like get_tasks, get_exams, or refresh_source, despite those siblings existing. The stated refresh window implies the data range but offers no when/when-not criteria for tool selection.

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, non-destructive and closed-world, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond the annotations: no login/authentication is required. It says nothing about pagination, result ordering, or what happens with an empty query, so it stays at a baseline-plus level.

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 the resource and the key constraint front-loaded; nothing is wasted. It is borderline under-specified rather than padded, so it earns high marks for economy but not perfection.

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 definition omits all parameter semantics and any usage context for a 3-parameter query tool. An agent knows what the tool is for but not how to call it well or when to prefer it.

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

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

All three parameters (limit, query, offset) have 0% schema description coverage, and the description never mentions any of them. It gives no hint about search syntax, pagination defaults, or how limit/offset interact, so it fails to compensate for the coverage gap.

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

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

The description states a specific verb and resource (查询...服务入口) plus a scope qualifier (公开, 不需要登录), so an agent knows it retrieves public school service links. It does not differentiate itself explicitly from siblings like get_course_resources or get_capabilities, which is the only thing keeping it from a 5.

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

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

There is no when-to-use guidance, no when-not-to-use, and no mention of any alternative sibling tool. The '不需要登录' phrase implies it is safe to call without auth but does not tell the agent when this tool is the right choice over the other 15 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=true, idempotentHint=true, openWorldHint=false and non-destructive, so the safety profile is covered. The description adds genuine value by disclosing that local task status and school-reported submission status are tracked separately, but it says nothing about filtering, ordering, pagination, or how stale the school data may be.

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

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

A single front-loaded sentence with no filler; the most important fact (what is read) comes first. It is efficient, though the extreme brevity contributes to the missing guidance elsewhere.

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

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

An output schema exists, so return values need not be explained, but for a four-parameter, zero-required listing tool the definition leaves filtering, pagination, and source selection entirely undocumented, and gives no usage signal against set_task_status. Too thin for a tool with this many undocumented knobs.

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

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

Schema description coverage is 0% across four parameters (limit, query, offset, source) and the description mentions none of them. An agent gets no information on how to filter by source, page results, or use the query string, so the description fails to compensate for the schema gap.

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

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

States a specific verb (读取) and resource (作业/测验待办) plus the returned facets (截止时间、提交状态), so an agent knows exactly what it retrieves. It reads as a task-listing tool, but it never explicitly names how it differs from the sibling set_task_status (write) or get_grades, leaving sibling differentiation to inference.

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

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

There is no explicit when-to-use statement and no routing to alternatives. The clause '本地状态与学校状态分开' hints at how the data is organized but gives the agent no condition for selecting this tool over set_task_status or get_grades.

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 non-read-only, non-destructive, non-idempotent, non-open-world, but say nothing about where the action lands. The description supplies exactly that context – the page opens locally on the user's machine – plus an important behavioral constraint: never request the user's password or token. That is real value beyond the annotations; it stops short only of describing what happens after login completes.

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: the action and its location come first, the security constraint second. No redundant restatement of the tool name and 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?

With an output schema present, return values need no explanation, and with zero parameters the schema burden is nil. The description covers the action, its locality, and the credential-handling rule. The only omission is when this should be invoked relative to siblings and what the agent should do after the login flow returns.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly adds no parameter narrative because there is nothing to parameterize; the schema is empty and complete.

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

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

States a specific verb and object ('在用户本机打开设置页' – open the setup page on the user's machine) and adds what the setup accomplishes (school-official login). The core action is unambiguous and clearly distinct from the get_* siblings, though it never names an alternative tool to differentiate against.

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: run this to get the user set up/authenticated before other tools can work, and skip credential collection. There is no explicit 'use this when… / use X instead when…' routing against siblings such as get_service_links or refresh_source, so the agent must infer the trigger 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?

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable processing limits (max 8 MiB, 100 pages) and clarifies that scanned copies are not OCR'd—useful context beyond annotations. It does not mention auth or error 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?

Two short sentences with the purpose front-loaded, followed by constraints. No wasted words; every clause earns its place.

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

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

For a simple read tool, annotations and output schema cover safety and return values. However, the required item_id parameter is undocumented and there is no usage context (e.g., how to obtain a valid item_id), leaving a gap 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 description coverage is 0%, so the description must compensate. It clarifies that index is 0-based, but item_id (the required parameter) is left completely unexplained; an agent cannot infer its format or source. Partial compensation only.

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 (提取/extract) and resource (PDF/文本附件 from cached notices), clearly distinct from sibling get_notice which retrieves notice content. Does not explicitly name alternatives, so 4.

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

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

No when-to-use guidance, alternatives, or prerequisites are provided. The only implicit context is 'cached notices', which is minimal and not framed as usage advice.

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 this is a non-read-only, non-idempotent, open-world, non-destructive operation, so the safety profile is covered. The description adds genuine behavioral context beyond that: it reports scope and partial failures, and bounds each course fetch to 1–50 records.

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

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

A single dense sentence that front-loads the fetch action and packs source list, range limit, failure reporting, and the semester caveat with no filler. The extreme terseness borders on cryptic but nothing is wasted.

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

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

An output schema exists, so return values need not be described. Given 3 parameters and no enums in the schema, the description supplies the missing source options, limit bounds, optional-semester behavior, and partial-failure reporting — enough for an agent to call it correctly, though it never says where refreshed data is stored.

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

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

Schema description coverage is 0%, so the description carries the full burden and does compensate well: it enumerates candidate source values, documents the 1–50 per-course limit, and states that semester may be left empty for 教务 sources. Only the exact meaning of each source token remains unexplained.

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

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

States a specific verb (按需获取/on-demand fetch) and names the concrete resources it pulls (public/oa/jw/mystu/yuketang), which distinguishes it from the read-only get_* siblings. The individual source tokens are opaque to an outside reader, but the fetch/ingest intent is clear.

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

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

'按需' (on demand) implies refresh-style usage rather than scheduled or first-time retrieval, and the semester note hints at a conditional parameter. However, no alternative tool is named and there is no explicit when-not guidance, so usage is only implied.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: it operates on a cache and an empty result is not authoritative proof of absence. That staleness caveat is exactly the kind of thing 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?

Three short clauses, front-loaded with what the tool does, then the caveat, then the workflow. Every clause carries information; nothing is padded.

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

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

An output schema exists, so return values need not be described, and the cache caveat plus workflow advice is useful. However, with 0% parameter documentation the agent still cannot tell how to shape a call, leaving a real gap for a 4-parameter search tool.

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

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

Schema description coverage is 0% across 4 parameters (limit, query, offset, source), and the description says nothing about them. It mentions 'scope' and 'body' abstractly but never explains what query matches, what source values are valid, or how limit/offset page the results. It fails to compensate for the coverage gap.

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

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

States a specific verb+resource: search the local notice cache. It also implicitly distinguishes itself from siblings by naming the refresh-then-read workflow. Not a 5 because it never contrasts itself with get_notice or other retrieval tools by name.

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

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

Gives actionable ordering guidance: refresh by scope first, then read the body to confirm. This maps onto the sibling tools refresh_source and get_notice. No explicit 'do not use this for X' exclusion, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, so the safety profile is known. The description adds a useful behavioral note that it does not accept authentication information, but omits critical write semantics such as whether it merges with or replaces an existing profile.

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, front-loaded sentences with the action stated first and the constraint second; no filler. Slightly terse given the gaps it leaves, but efficient.

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

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

An output schema exists, so return values need no explanation, and annotations cover the safety profile. Still, for a mutation tool with four 0%-documented parameters, the description should clarify merge/replace behavior and field formats, which it does not.

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

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

Schema description coverage is 0%, so the description carries the burden, and it does name all four fields (college/major/grade/interests) mapping to the four parameters. However, it gives no format or type guidance (e.g., entry_year format) and does not mention that all fields are optional with empty-string defaults.

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 (保存/save) and resource (学院/专业/年级/兴趣 = college/major/grade/interests), and gives the downstream purpose (helping the agent filter opportunities). The purpose is clear, though it does not explicitly differentiate itself from any sibling 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?

Usage is only implied via '帮助用户的 agent 筛选机会' (helps the user's agent filter opportunities) and the constraint '不接收认证信息'. There is no explicit when-to-use, when-not-to-use, or named alternative, but the intent is 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 readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the mutation profile is partly covered. The description adds genuinely new context beyond that: the mutation is confined to local state and never propagates to the school system, which prevents the agent from misreading this as a submission action. It does not address idempotency (idempotentHint=false) or re-setting the same status.

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, front-loaded with the action and immediately followed by the scope constraint. No filler or 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?

An output schema exists, so return values need not be explained, and the annotations cover the safety profile. The description supplies the critical local-vs-school distinction, leaving only minor gaps around sourcing item_id and idempotent behavior.

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

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

Schema description coverage is 0%, so the description must carry the load. It enumerates the three valid status values (todo/done/ignored), which is valuable given no enum is defined in the schema, but it says nothing about item_id — its format, or that it likely comes from get_tasks. Partial compensation only.

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 (mark a local todo item as todo/done/ignored) and scopes it as local-only. It implicitly distinguishes itself from read siblings like get_tasks and from school-facing actions, though it does not name an alternative tool directly.

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

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

The second sentence gives a useful negative boundary (it does not submit to or modify school assignments), which tells the agent when this is NOT the right tool. There is no positive guidance on when to prefer this over other write tools such as set_student_profile, so usage is only implied.

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