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

With no annotations supplied, the description carries the full behavioral burden. It discloses the no-login requirement and the total application count, but it does not describe the return format, pagination behavior, or what each catalog entry contains.

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

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

The description is a single, front-loaded sentence with no wasted wording. It efficiently communicates the resource, access condition, scale, and filtering capability.

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 two-parameter listing tool with fully documented schema and no output schema, the description is largely complete. It covers the resource, no-login access, count, and filtering, though it omits return-field details that could help an agent understand the result shape.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description's note that filtering is possible by name/department adds only a high-level restatement of the keyword parameter and does not provide additional syntax or examples 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 clearly identifies the resource as the online service hall application catalog and adds useful scope (176 process applications, no login required). It does not explicitly distinguish this catalog from sibling tools such as affairs_portal or sis_other_applications, so it falls short of a 5.

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

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

The description implies the tool is for browsing service hall applications and notes that no login is required, which is useful context. However, it does not state when to choose this tool over alternatives like affairs_portal or sis_other_applications, nor does it provide exclusions.

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

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

With no annotations present, the description carries the full burden. It does disclose one genuinely behavioral fact — that a unified password is required — but says nothing about read-only behavior, what the response looks like, or whether the credential is supplied elsewhere since the tool takes no parameters.

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 that front-loads the resource and count with no filler. It is efficient, though arguably too terse given the number of overlapping 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?

For a zero-parameter, no-output-schema tool the description is minimally adequate: the agent learns it is a directory of 18 portal sites requiring unified auth. It still leaves open what the call yields and how it differs from portal_cards or sites_index, which matters in this sibling set.

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

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

The tool takes zero parameters and the schema coverage is 100%, so there is no parameter meaning for the description to add. Baseline 4 applies for a parameterless tool.

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

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

The description names the resource (a portal service directory of 18 department/application sites) but uses no verb, so it is unclear whether the tool lists, launches, or resolves those sites. It also does not distinguish itself from similar-sounding siblings such as portal_cards, sites_index, affairs_apps, and site_detail.

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 and no alternative named, despite a crowded sibling set with several plausible overlaps. The only hint is the parenthetical about the unified password, which implies a precondition but not a selection rule.

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

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

With no annotations, the description carries the full burden of disclosure. It does not say whether the operation is read-only, whether results are ranked by fit, how continuity is computed across rooms, or what happens when no qualifying slot exists. '避免多次轮询' hints at the tool's value proposition of a single batched query, but it does not describe how the tool actually behaves.

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

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

It is a single short sentence, so it is concise, but it is under-specified rather than efficient. The opening phrase '场景级复合求解' occupies a lot of space without adding meaning, and the actual purpose appears after it.

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

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

For a 6-parameter tool with no annotations and no output schema, the description is too thin. It does not describe the shape of returned slots, how a slot qualifies as contiguous, or how min_hours interacts with time and limit. An agent must infer the return contract entirely.

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%: date, time, type, limit, keyword, and min_hours each carry their own descriptions, including examples and defaults. The description adds no parameter-level meaning beyond the schema. That is expected when coverage is this high, so the baseline score 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 contains a specific verb phrase, '智能推荐空闲连续时段' (intelligently recommend free contiguous time slots), but it buries it after the vague jargon '场景级复合求解', which tells an agent nothing. It does distinguish the tool somewhat from sibling tools such as sport_scenes and sport_reservations by implying a recommendation rather than a raw listing, but that distinction is only implicit.

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 only usage hint is '避免多次轮询' (avoid repeated polling), which implies the tool should replace manual iteration but never states when to choose it over sport_days, sport_sites, or sport_reservations. There are no exclusions, prerequisites, or alternative-routing guidance.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose the most important trait: the operation is a write, but it is gated behind confirm=true and defaults to a non-mutating preflight. That makes the safety profile explicit. It omits what happens to an existing .ics at the path, whether overwrites are silent, and what the preflight plan contains, which are relevant for a file-writing 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?

A single dense sentence front-loads the action and target format, then immediately gives the confirm gating rule. Nothing is redundant and the semantically decisive detail (default is preflight only) arrives before the write case.

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

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

For a two-parameter write tool with no annotations and no output schema, the description covers the essentials: what is produced, that it is a write, and how the dry-run/write gate works. It leaves out overwrite/conflict handling and path-validity expectations, which is a meaningful but modest gap given the tool's low complexity.

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 confirm and output_path, making 3 the baseline. The description adds meaning beyond the schema by framing the default behavior as session-time validation plus a preflight plan, and by tying confirm=true specifically to writing at the target path. That extra framing helps an agent reason about the flag rather than merely read its type.

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

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

The description gives a specific verb and resource: exporting the SIS class schedule to a standard iCalendar (.ics) file. It also labels the tool as a write operation, which separates it from read-only siblings such as sis_schedule, calendar_today, or calendar_week. It stops short of naming an alternative, so it is clear but not fully differentiated by explicit comparison.

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 clearly states two modes of use: by default the tool only validates class sessions and returns a preflight plan; with confirm=true it actually writes to the given path. That is concrete when-to-use guidance for the single decision that matters. It does not discuss what to do if the target file already exists or any prerequisites for choosing this over a read-only schedule tool.

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

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

No annotations are supplied, so the description carries the full burden. It does disclose the returned fields (date, weekday, semester, teaching week, events), which is valuable because there is no output schema, but it never states that the call is read-only, side-effect free, or how the current date is resolved (timezone, caching). For a zero-parameter informational lookup the risk is low, but the disclosure is incomplete.

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 lists the returned values in a natural reading order, with the core resource ('today's date') front-loaded. No filler, no repetition of the tool name.

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

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

With no output schema, the description usefully enumerates the returned fields, which is the main thing an agent needs to know. The remaining gap is minor: no note on timezone/recency of the data or on the shape of the events list.

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

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

The tool takes zero parameters, so there is no parameter meaning to add and the baseline of 4 applies. The description correctly focuses on what is returned rather than inventing argument 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?

The description names a specific resource set: today's date, weekday, semester, teaching-week number, and today's campus calendar events. An agent can tell it apart from calendar_week, which is the obvious week-scoped sibling, without opening a schema. It stops short of an explicit contrast with that sibling, so it is clear but not maximally differentiated.

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 word 'today' in the description; there is no statement of when to call this versus calendar_week or events_upcoming. The scope is narrow enough that the intent is inferable, but no alternative is named 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?

No annotations are supplied, so the description carries the full burden. It does disclose the default behavior, but it does not state the date format returned, what happens if week exceeds the semester range, or that the boundaries follow the academic calendar rather than ISO weeks.

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

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

One compact sentence with the returned value front-loaded and the default behavior attached. Nothing is wasted; the terseness is close to the minimum needed, though a brief note on return format would not be 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?

For a single optional-integer read tool with no output schema and no annotations, this covers purpose, result, and default adequately. Only the returned date format and out-of-range behavior are left 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 the baseline would be 3, but the description additionally documents the default — omitting week yields the current teaching week — which the schema does not state. That is meaningful added semantics for the only 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 names a specific resource and result: the start and end dates of the Nth teaching week. It is clear what is returned, but it does not contrast itself with near siblings such as calendar_today or calendar_export, so an agent must infer the distinction.

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

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

The parenthetical "缺省取当前周" implies when the parameter can be omitted and hints at the typical use case of getting the current week's boundaries. No explicit when-to-use or when-not-to-use guidance versus calendar_today or calendar_export is given.

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

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

No annotations are supplied, so the description carries the full burden. It does disclose the content dimensions returned (location, service availability, opening hours) and, by describing itself as 'information', implies a read-only lookup, but it says nothing about completeness of results, whether closed venues are included, or the shape of the response.

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 short parenthetical sentence with no wasted words, and the key resource is front-loaded. It reads as a fragment rather than a complete sentence, and the coverage summary could have been paired with a one-clause usage cue at no extra length cost.

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-optional-parameter read-only lookup with no output schema, the description covers the subject matter but not the return values in any detail (no indication of fields like venue name, contact, or per-day hours). It is minimally sufficient but leaves the agent guessing about result structure.

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

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

Schema description coverage is 100%: the single optional 'campus' parameter already documents the three enum values and that omission means all campuses. The description adds no additional meaning about the parameter, which is acceptable given the schema is self-sufficient — baseline 3.

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 (campus dining venues: canteens and coffee/light-meal outlets) and enumerates the data it covers (location, meal service, business hours). That is clearer than a bare name restatement, but it never distinguishes itself from plausible siblings such as campus_services, campus_map, or campus_housing, so an agent cannot tell from the text alone which one to pick.

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

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

There is no when-to-use or when-not-to-use guidance, no mention of prerequisites, and no pointer to an alternative tool. The agent must infer from the noun phrase alone that this is the lookup for on-campus food options rather than general campus facilities.

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

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

No annotations are supplied, so the description carries the burden, and it only implies a passive informational lookup without stating read-only behavior, side effects, or result shape. The risk surface is low for this kind of lookup, but the description never confirms it returns a list vs a single record or how multiple campuses are handled (that detail lives only in the schema).

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

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

One front-loaded sentence with a parenthetical listing the covered fields; there is no filler. It is terse to the point of omitting useful routing information, 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?

For a one-optional-parameter lookup with no output schema and no annotations, listing the returned fields (address, amenities, phone) partially compensates for the missing output schema. It still leaves unclear how results are keyed per campus and why an agent should choose this over overlapping campus info 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%: the single campus parameter already carries its enum values and the 'default means all campuses' semantics. The description adds nothing about the parameter, so the baseline 3 applies.

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

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

The description names a specific resource (campus housing) and enumerates what it covers: address, amenities, and contact phone. That is clearly more informative than the bare name. It does not, however, distinguish this from the many adjacent siblings such as campus_dining, campus_services, campus_map, or contact_info.

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 guidance, no mention of alternatives, and no statement of when not to use it. In a sibling set that includes campus_services and contact_info, an agent has to guess whether housing addresses come from this tool or from those.

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

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

No annotations are supplied, so the description carries the full disclosure burden. It does convey the scope of what is returned (addresses, map images, panorama links, transit schedules), which is useful given there is no output schema, but it never states that this is a passive read-only lookup, nor how media or schedules are formatted and whether they can be stale.

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

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

One compact sentence with the topic front-loaded and no filler. The dense enumeration of four content categories is efficient, though it would read more scannably if slightly structured rather than strung together with '、'.

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 single-optional-parameter lookup with no output schema, the description adequately conveys the breadth of returned content, letting an agent judge whether to call it. Only minor gaps remain, such as the form of the images/panorama links and freshness of transit schedules.

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 optional 'campus' parameter already documents the 云谷/云栖/铜鉴湖 fragments and the default of returning all campuses. The description adds no further meaning about the parameter, 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 resource and enumerates its content: three-campus addresses, official map images, 720yun panoramas, and arrival transportation including metro/bus first and last train times. That is well beyond a restatement of the name 'campus_map'. It lacks an action verb and never distinguishes itself from nearby siblings like campus_housing, campus_services, or contact_info, so it falls short of a 5.

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

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

There is no explicit when-to-use guidance, no exclusions, and no named alternatives. The agent must infer from the content list that this is the tool for physical campus location and travel questions, and must guess on its own whether contact_info or campus_services overlaps.

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

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

With no annotations supplied, the description carries the full behavioral burden. It hints at return content by mentioning 'location and business hours,' but never states that the operation is read-only, whether results are paginated, how hours are formatted, or what happens when the optional campus parameter is omitted beyond the schema's note. The burden is largely unmet.

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

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

It is a single compact parenthetical enumeration with no wasted words, but it is not front-loaded with an action or purpose statement — the reader gets a category list rather than 'what this tool does.' Efficient yet weakly structured.

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

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

For a simple one-optional-param lookup with no output schema and no annotations, the description adequately conveys scope and the types of information returned (locations, hours). It is still missing the operation verb, read-only assurance, and any output shape hints, which matters more given the absence of annotations.

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 only one optional parameter (campus) with 100% schema description coverage and an explicit enum, so the schema already carries the semantics. The description adds nothing about campus-scoped behavior or the default-all behavior, so the baseline 3 applies.

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

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

The description names a specific resource — on-campus daily-life service points — and enumerates the categories covered (supermarket, package station, laundry, hair salon, printing, bank, vending machines), which distinguishes it from campus_dining. However, it is a bare noun phrase with no verb, so the agent must infer that it is a lookup/list operation, and it never names the siblings it is not (campus_map, campus_housing, campus_dining).

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 exclusion, and no routing to alternatives. An agent must decide on its own between this tool and campus_map, campus_dining, or sport_sites, none of which are mentioned.

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

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

With no annotations, the description carries the full disclosure burden, yet it only lists three returned fields. It says nothing about read-only nature, whether results are scoped to one course or all enrolled courses, ordering, volume, or failure modes such as an unknown course keyword.

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?

There is no wasted wording, but the definition is a bare noun phrase with a parenthetical; it is under-specified rather than well-structured, and it front-loads the resource without ever stating the operation.

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

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

For a simple one-parameter read tool with no output schema, disclosing the returned fields (time / title / link) covers part of the return-value burden. Still missing are the operation verb, result scope, and any behavioral caveats, which leaves the agent with gaps before calling 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?

There is a single parameter and the schema documents it fully as a course id or name keyword. The description adds no extra meaning about matching behavior (id vs. fuzzy keyword), so the baseline of 3 for high schema coverage 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 the resource (course announcements) and the fields returned (time / title / link), which distinguishes it reasonably from siblings like canvas_deadlines and canvas_inbox. However, it never states the action — nothing says whether it lists, fetches, or searches announcements — so the agent must infer that it is a per-course listing.

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 is given: no mention of when to prefer this over canvas_deadlines, canvas_courses, or canvas_discussions, and no prerequisites such as enrollment or authentication. The agent can only guess usage from the tool name.

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

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

No annotations are supplied, so the description carries the full burden. It does disclose useful behavioral detail beyond the schema: the return content, that due times come back in Beijing time as ISO8601, and that attachments are identified by file_id, name and size. It says nothing about read-only semantics, error behavior when the keyword matches multiple assignments, or whether submission status is included.

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 resource named first and the returned fields listed after, with zero filler. It is slightly list-heavy but every element conveys information.

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

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

With no output schema, the description's field list is the only documentation of return values, and it may not be exhaustive (submission status, points, rubrics are unmentioned). For a two-parameter read tool with full schema coverage this is adequate but leaves gaps about result shape and failure modes.

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, assignment) are already documented in the schema as id or name keyword. The description adds no further meaning about how fuzzy matching or id-vs-name resolution works, so baseline 3 applies.

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

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

The description states a specific resource, assignment details, and enumerates what is returned (description text, in-description attachments with file_id/name/size, due time, submission type), so an agent knows exactly what this tool produces. It does not distinguish itself from nearby siblings such as canvas_deadlines, canvas_todo, or canvas_submit, which keeps 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 mention of when not to use it, and no pointer to alternatives like canvas_deadlines for deadline lists or canvas_submit for submitting. The agent must infer the use case from the name alone.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the return payload (complete messages plus attachments), which is useful beyond the schema, but it says nothing about whether access is restricted to the caller's own conversations, how very long conversations are paginated or truncated, or that the call is a pure read.

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 line that front-loads the resource and appends the provenance constraint. No filler, though the extreme brevity leaves behavioral gaps that a slightly longer sentence could have closed.

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

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

For a one-parameter read tool with no output schema and no annotations, the description covers purpose and return content but leaves the safety profile (read-only nature), access scope, and handling of large conversations unstated. Adequate to invoke correctly, thin on behavioral context.

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's schema description already states that the id comes from canvas_inbox. The description repeats that fact rather than adding format details, error behavior for an invalid id, or how the id relates to course context.

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: the complete messages and attachments of a single conversation, and clearly distinguishes it from canvas_inbox, which supplies the conversation_id. The action verb is only implied (fetch/retrieve), but the scope is unambiguous.

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

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

The parenthetical 'conversation_id 取自 canvas_inbox' gives an explicit prerequisite and ordering: call canvas_inbox first, then this tool with the returned id. There is no explicit when-not guidance, but for a one-parameter reader the routing information is sufficient.

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

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

No annotations are provided, so the description must carry the full behavioral burden, and it does not. It says nothing about authentication scope beyond 'current account', ordering, pagination, whether archived or unpublished enrollments are excluded from 'active', or what each course entry contains, so an agent cannot predict the shape or limits of the response.

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 definition is one compact sentence that puts the resource first and packs the state options into a parenthetical, with no filler. The nested parentheses make it slightly harder to parse, 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?

This is a simple read tool with two optional parameters, 100% schema coverage, and no output schema, so it need not explain return values. Still, the description omits basic behaviors such as ordering, pagination, and the fields in each course entry, which leaves the behavioral picture incomplete in the absence of annotations.

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, state and keyword, are fully documented in the schema, including enum values and default. The description only restates those same facts ('active/completed/all', '关键词过滤') without adding filtering syntax, matching rules, or case sensitivity, 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 verb '列出' (list) and the resource 'Canvas 课程列表' are explicit, and the scope is limited to the current account. Among its Canvas siblings, such as canvas_deadlines, canvas_todo, and canvas_files, this is the only tool that lists courses. However, the description does not name a sibling that handles a related task, so the distinction is not explicit.

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

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

The description implies when to use it by offering the active, completed, and all states, which are effectively usage modes, but it never states a when-to-use or when-not-to-use rule, or a prerequisite. Because it also does not say how it relates to the course-related siblings such as canvas_deadlines or canvas_assignment_info, the 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?

No annotations exist, so the description carries the full burden. It does add genuine behavioral context beyond the schema by stating that either a token or a unified-password session is accepted, which removes a common pre-call blocker. However, it never states that the operation is read-only and non-destructive, nor what the result set looks like, leaving the safety profile implicit.

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

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

One compact sentence with the core resource front-loaded and the authentication note trailing as a secondary clause. Nothing is redundant or padded. It is short to the point of omitting useful routing detail, but not verbose.

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

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

This is a simple read tool with one optional parameter, so low description volume is reasonable. Still, with no output schema and no annotations, the description could have said what a deadline entry contains (course, title, due timestamp) and whether results are sorted. Adequate but with clear gaps for an agent deciding whether this answers its question.

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

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

Schema description coverage is 100%: the single 'days' parameter already documents its meaning, 1-180 bounds, and default of 14. The description only restates 'next N days' without adding format, boundary, or default behavior clarification. Baseline 3 is appropriate when the schema does the work.

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

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

The description states a concrete resource and scope: Canvas assignment deadlines falling within the next N days. An agent can tell this is an upcoming-deadline query rather than a submission or file tool. It does not explicitly distinguish itself from the nearby canvas_todo or canvas_assignment_info siblings, 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?

Usage is implied by the 'within the next N days' window, which suggests a look-ahead deadline check, and the parenthetical tells the agent authentication is flexible. There is no explicit when-not guidance or pointer to canvas_todo / canvas_assignment_info for related needs, so the agent must infer routing from sibling names alone.

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

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

No annotations are supplied, so the description carries the full burden, and it discloses only one behavioral trait: bodies are converted to plain text. It says nothing about whether the call is read-only, whether enrollment in the course is required, how the reply list is paginated, or what the result looks like, despite there being no output schema.

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

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

One short sentence with no wasted words, and the essential resource is front-loaded. It is efficient, though its brevity is achieved partly by omitting information.

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

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

With no annotations and no output schema, the description should explain the return shape and pagination behavior, but it does not. For a tool that returns both a topic and a variable-length reply list, this is under-specified.

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 explains course, topic, and limit (including the default of 20 and the cap of 200). The description adds no parameter-level meaning beyond the schema; 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 states a specific verb+resource pair: it returns discussion topic detail plus the reply list, with bodies converted to plain text. An agent can tell what the tool fetches. However, it never distinguishes itself from the sibling canvas_discussions, which likely also concerns discussions, so the boundary is left ambiguous.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and the obvious alternative (canvas_discussions) is not mentioned. Usage can only be inferred from the resource named in the description.

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

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

No annotations are supplied, so the description carries the full burden, yet it says nothing about read-only behavior, permissions, pagination, or ordering (only that a Beijing-time field is returned). Listing returned fields is a small behavioral hint, but for an unannotated tool this is a significant disclosure gap.

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

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

A single compact fragment with no filler; the field list in parentheses is front-loaded and informative given there is no output schema. It is terse to the point of being a label rather than a sentence, 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?

With no output schema, the enumerated return fields (title / unread / reply count / Beijing time / link) usefully describe the shape of the result. Still missing are read-only semantics, ordering, result limits, and any distinction from canvas_discussion_entries, leaving the definition only minimally adequate.

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

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

Schema coverage is 100% with a single required 'course' parameter already documented as '课程 id 或名称关键词'. The description adds no further meaning about matching behavior or ambiguity, 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 identifies the resource ('课程讨论主题' / course discussion topics) and lists the fields returned, so an agent knows roughly what it fetches. However, there is no verb (list? fetch? subscribe?) and no differentiation from the sibling canvas_discussion_entries, which an agent could easily confuse with this 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?

No guidance on when to use this versus canvas_discussion_entries or canvas_announcements is given. The agent must infer from the name alone that this lists topics while the sibling presumably lists posts within a topic.

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

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

With no annotations, the description carries the whole burden and does disclose the non-obvious behaviours: it is a write, it needs an API token, and by default it is a safe dry run requiring confirm=true to take effect. It stops short of saying whether an archived todo can be restored, what happens if the keyword matches multiple items, or what the precheck returns.

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

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

A single compact sentence places the mutation type, auth requirement, matching modes, and the confirm gate in that order. Nothing is redundant and the highest-risk information (write operation, confirm gate) comes first.

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

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

For a two-parameter mutation tool with no annotations and no output schema, the description covers the essentials but leaves meaningful gaps: ambiguous-keyword behaviour, failure modes, and what a confirm=false precheck produces. It is adequate to call the tool, not fully sufficient to predict its results.

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 already carry their own descriptions, so the description mostly restates them. It does clarify that matching accepts either an assignment ID or a title/course keyword, but adds no syntax, precedence, or disambiguation rules beyond the schema text.

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

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

The description uses a specific verb pair ("忽略/归档" – dismiss/archive) with the resource "Canvas 个人待办事项", so an agent knows this mutates a personal todo rather than listing them. It does not name the read counterpart (canvas_todo) that an agent would normally call first, so sibling differentiation is implied rather than stated.

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

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

It gives clear preconditions: this is a write operation requiring a Canvas API token, and nothing is dismissed unless confirm=true, otherwise it is only a precheck. The "when" is therefore well covered, but there is no explicit instruction about which sibling to call to find the todo first or what to do when the keyword is ambiguous.

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

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

No annotations are supplied, so the description carries the full burden. It does disclose the returned tuple (id, name, byte size), which is genuine behavioral information, and '清单' implies a read-only listing. However, it says nothing about permissions, pagination, recursion into folders, or whether all files or only top-level ones are 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?

It is a single compact sentence with the resource front-loaded and the return fields parenthesized, so there is no filler. The terseness comes at the cost of detail rather than verbosity, so it is efficient but thin.

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

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

For a simple one-parameter read tool with no output schema, the description is minimally sufficient because it names the returned fields. It is still incomplete on scope questions (folders, pagination, permissions) that an agent would need before relying on a complete file listing.

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

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

Schema coverage is 100% and the single 'course' parameter already documents that it accepts an id or name keyword. The description adds only the framing that the course scopes the file listing, which is marginal beyond the schema. Baseline 3 is appropriate for a one-parameter tool.

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

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

The description states the specific resource clearly: the file listing of a given Canvas course, plus the fields returned (file_id / filename / byte size). An agent can tell this apart from canvas_courses, share_files, and canvas_upload. It stops short of explicitly contrasting with the closest sibling, share_files.

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

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

There is no guidance on when to use this rather than share_files, site_content, or canvas_courses, and no mention of prerequisites or exclusions. The only implied usage is 'when you need a course's files', which the agent must infer.

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

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

No annotations are supplied, so the description carries the full burden. It does usefully disclose the shape of each returned row (unread count, subject, participants, last message time), which substitutes for the absent output schema, but it says nothing about read-only safety, ordering, or what happens beyond the limit cap.

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 short, front-loaded sentence with zero filler; the resource comes first and the parenthetical return-field summary follows. It is efficient, though the extreme terseness leaves no room for routing guidance.

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 list tool with no output schema, describing the returned fields largely closes the gap. Only minor omissions remain (sort order, whether it is unread-only or all conversations), which are unlikely to cause a mis-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 description coverage is 100% — the single 'limit' parameter already documents its default of 20 and its 1–100 bounds. The description adds no meaning beyond that, so the baseline of 3 applies.

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

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

States a specific verb+resource (收件箱会话列表 = inbox conversation list) and even enumerates what each row carries (unread count, subject, participants, latest message time). This makes it clearly distinct from the singular canvas_conversation sibling, though it never names that sibling explicitly.

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

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

Usage is implied: an agent would infer this is the entry point for browsing the Canvas inbox, after which canvas_conversation would be used for a single thread. There is no explicit when-to-use/when-not statement, no mention of alternatives, and no prerequisite (e.g. login) noted.

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

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

With no annotations, the description carries the full burden; it does disclose that this is a write operation and that the result is the course being pinned at the top of the course panel, which is real value. It stops short of stating whether starring an already-starred course is idempotent, whether the change is reversible (via canvas_unstar), or that the call is a no-op precheck unless confirm is set.

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

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

A single front-loaded sentence with the action, effect, and write nature packed into one clause and a parenthetical; nothing is wasted. The nested parenthetical makes it dense but not ambiguous.

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

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

For a 2-parameter tool with full schema coverage and no output schema, the definition is adequate: the mutation is disclosed and its visible effect described. It is incomplete in omitting its relationship to the sibling canvas_unstar and the precheck/confirm interaction that governs whether anything actually changes.

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

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

Schema description coverage is 100%, so both parameters (course id/keyword and the confirm precheck flag) are already documented in the schema, establishing a baseline of 3. The description adds only the general object of the action ('课程') and no extra semantics such as what happens when course matches multiple names.

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

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

The description names a specific verb+resource pair (将课程加入收藏/星标) and adds a concrete effect, '置顶于课程面板', plus flags it as a 写操作. It is distinguishable from the sibling canvas_unstar by the '加入/星标' direction, though it never explicitly references that inverse 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?

The use case is implied — star a course to pin it on the panel — but there is no explicit when-to-use versus when-not guidance, no pointer to canvas_unstar for removing a star, and no discussion of when to set confirm=true versus leaving the default precheck behavior.

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

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

With no annotations present, the description carries the full burden and does well: it flags the tool as a write operation, states that a Canvas API token is required, and discloses the dry-run-by-default safety behavior. What it omits is the consequence side — whether a submission can be withdrawn or overwritten, and whether multiple submission types can be combined in one call beyond the '三选一' hint.

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 clauses, front-loaded with the operation and its write/auth characteristics, followed by the dry-run rule. No filler, and the most decision-relevant fact (nothing is submitted without confirm=true) is easy to spot.

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?

Covers the essentials for a mutating tool with no output schema: what it writes, required auth, the safe-default gate, and the payload options. It does not describe what the pre-check plan contains or what a successful submission returns, which leaves a small gap for an agent deciding how to interpret the dry-run response.

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 every parameter including the file/text/url mapping and the confirm semantics. The description's only added meaning is the mutual-exclusivity framing ('三选一'), which is also repeated in the confirm field description, so it sits at the baseline rather than above it.

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 ('提交 Canvas 作业') and enumerates the three submission payload types (file/text/URL), which is more than a restatement of the name. It does not explicitly distinguish itself from the sibling canvas_upload (file upload to Canvas), so an agent could still hesitate between the two.

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 operating rule: default is a dry-run that returns a submission plan, and confirm=true is required to actually submit. That is strong when-to-act guidance, but there is no statement of when NOT to use this tool (e.g., use canvas_upload for staging files, canvas_assignment_info for checking requirements) or how resubmission behaves.

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

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

With no annotations at all, the description carries the full burden. It does disclose the shape of each returned row and the timezone/format of the due value (北京时间 ISO8601), which is genuinely useful behavior beyond the name. It says nothing about ordering, pagination beyond the schema's limit, or whether the list is read-only, so it remains partial.

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

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

One front-loaded sentence with no filler; the resource and return shape come first and the format caveat second. The dense parenthetical is readable but slightly crammed.

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

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

For a one-parameter read tool with no output schema, disclosing the returned fields and the due-date format covers the essentials. Missing are ordering/default sort, and any tie-in to the dismiss tool, which an agent would need to act on the list.

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 'limit' parameter is already documented with its default and bounds. The description adds no parameter meaning, which is acceptable given the baseline for fully-documented schemas.

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?

"Canvas 待办列表" names the resource and operation clearly, and the parenthetical enumerates the fields returned (课程/类型/事项/截止/链接), so an agent knows exactly what it gets. It does not distinguish itself from near-siblings such as canvas_deadlines or canvas_dismiss_todo, so it stops short of a 5.

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

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

Nothing states when this list should be preferred over canvas_deadlines, or that canvas_dismiss_todo is the mutation counterpart. Usage is only inferable from the tool name.

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

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

With no annotations at all, the description still carries the burden of behavioral disclosure. It does earn credit for flagging mutation ('写操作'), which is the single most important trait for an unannotated tool, but it says nothing about idempotency, what happens if the course is not currently starred, permission/auth requirements, or that omitting confirm triggers a dry run (that detail lives only in the schema).

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

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

A single short sentence, front-loaded with the action and its target, with zero filler. It is arguably too terse rather than too verbose, but nothing present 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?

For a two-parameter mutation with no annotations and no output schema, the description covers the minimum: what it does and that it writes. It leaves the agent without any account of result semantics (e.g. outcome when the star does not exist) or safety/permission context, which is a meaningful gap for an unannotated write tool.

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

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

Schema description coverage is 100%, with both course (id or name keyword) and confirm (execute vs preflight) documented inline, so the schema does the heavy lifting. The description adds only the object of the operation and no format, matching, or ambiguity-resolution detail beyond it, making baseline 3 appropriate.

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

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

States a specific verb ('取消' / un-star) plus a specific resource ('课程个人收藏/星标'), so an agent knows exactly the operation. It does not explicitly name the inverse sibling canvas_star, but the naming symmetry makes the distinction obvious 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?

Usage is only implied: remove an existing course star. There is no statement of when to prefer this over canvas_star, no prerequisite (e.g. the course must currently be starred), and no note on how the confirm preflight should be sequenced before executing. The '（写操作）' tag is the only usage-relevant cue.

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

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

With no annotations provided, the description carries the full burden, and it does disclose that this is a write operation, that it requires a Canvas API token, and that the default is a non-destructive dry-run. It leaves out size and type limits, overwrite behavior, and what a successful pre-check or upload returns.

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

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

It is a single compact sentence with the write/token caveat and the dry-run rule front-loaded, and every clause carries information an agent needs before calling it.

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

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

For a two-parameter upload tool with no annotations and no output schema, the description covers the essentials: mutation semantics, authorization requirement, and the dry-run default. It would be stronger if it mentioned size/type limits or overwrite behavior, but nothing required for a correct call is missing.

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

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

Schema coverage is 100%, and the schema itself documents both file_path and confirm, including the pre-check semantics of confirm. The description reinforces the confirm behavior but adds no format or constraint detail beyond what the schema already 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 and resource (upload a local file to the Canvas personal files cloud drive) and marks it as a write operation, so it is clearly separable from read-oriented siblings such as canvas_files or share_files. It stops short of naming a sibling or stating an explicit boundary against them, so it is clear but not fully differentiated.

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 the crucial operating rule: by default the call only pre-checks size and type, and actual upload happens only with confirm=true. That is clear guidance for how to invoke it safely. It does not say when to prefer this over related file tools, so there is no explicit alternative routing.

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

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

With no annotations, the description carries the full burden and does disclose two important behaviors: that it auto-authenticates using a unified password (so the caller needs no credentials) and that it is read-only. It does not mention rate limits, page-size ceilings, or what happens if the login state cannot be established.

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 resource and scope. Every clause earns its place, though the parenthetical packing of kinds plus pagination plus auth plus read-only makes it slightly hard to scan.

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

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

For a read-only paginated list tool with fully documented parameters and no output schema, the description covers the essentials (scope, kinds, auth model, read-only). It is silent on result ordering, whether 'full' means it auto-iterates all pages or just returns one page, and on fields returned, which leaves an agent guessing about the pagination contract.

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

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

Schema coverage is 100%, with all three parameters, their defaults, ranges, and the kind enum already documented in the schema. The description only restates the four kinds and the notion of pagination/full retrieval, adding no syntax or semantics beyond the schema. 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 description names a specific resource (the employment service site's list) and the four enumerable kinds (campus/jobfair/teachin/news), plus pagination. It implies a distinction from career_latest and career_detail via 'deep' and 'logged-in state', but never names those siblings explicitly, so the differentiation is inferred rather than stated.

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

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

Usage is only implied: 'deep / logged-in / full pagination' suggests this is the tool for comprehensive authenticated listings versus the lighter career_latest or single-item career_detail. There is no explicit when-to-use or when-not-to-use statement, and nothing tells the agent what to do if auto-login fails.

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

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

With no annotations, the description carries the full burden, and it does disclose two real traits: the page is SSR (so it is a rendered page fetch, not a clean API), and it requires login (an auth precondition that will fail otherwise). It also signals that only a body *summary* plus attachment references are returned, not full text. It does not say what happens on auth failure, whether content is truncated, or how attachments are represented.

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 line: purpose first, then the returned fields, then the operational constraints in parentheses. Every element earns its place and nothing is repeated from the schema or restated as a title.

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

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

For a one-parameter read-only detail tool with full schema coverage, the definition covers purpose, payload shape, auth requirement, and rendering mode, which is close to complete. The remaining gap is that it never states failure or edge behavior for a missing/expired ref or a logged-out session.

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 schema already explains that 'ref' accepts a career_deep item id, a news tag, or a full URL. The description adds nothing beyond that, so the baseline 3 applies — the parameter meaning is fully carried by structured data.

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 and operation: the detail page of a career-service news item, and enumerates the fields it surfaces (title / date / body summary / attachments). Combined with the schema note that 'ref' comes from career_deep output, an agent can place it in the career flow (career_latest → career_deep → career_detail), though the description itself does not contrast it with those siblings.

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

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

When-to-use is only implied: it is a detail fetch keyed by a ref produced by career_deep, which the input schema states but the description does not. There is no explicit statement of when to prefer this over career_latest or career_deep, and no guidance on what to do if the ref is a URL versus an id/tag.

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

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

No annotations are supplied, so the description carries the full burden. It does reveal that this is a public homepage surface (implying no authentication) and that entries carry date, time slot, venue, and status. But it never states that the operation is read-only, whether results are paginated or sorted, or how fresh 'latest' actually is — significant omissions for an unannotated 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?

A single front-loaded sentence with no filler, and the three-block scope comes before the field-level parenthetical. The stacked parentheses make it slightly dense, 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?

For a read-only listing tool with three optional parameters and no output schema, the description supplies the key missing piece: the shape of returned entries (date, time slot, venue, status). Only freshness/pagination and explicit read-only signaling are left unstated.

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 kind, limit, and keyword are fully documented in the schema, including the enum mapping. The description's three-block list merely restates the enum values and adds no filtering semantics (e.g., whether keyword matches across blocks) beyond what the schema already says.

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 (career service site latest updates) and enumerates the three content blocks it returns (recruitment notices, job fairs, info sessions). The 'latest/homepage' framing implicitly separates it from career_detail and career_deep, though it never names those siblings.

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

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

Usage is only implied: 'latest' and 'homepage public surface' suggest a quick snapshot, and the sibling names career_deep/career_detail hint that this is the shallow listing. There is no explicit when-to-use, when-not-to-use, or alternative-routing statement.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It never states that this is a static read-only reference lookup, whether results are cached or live, or what form the addresses/contacts come back in; it only implies content by naming categories.

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 that front-loads the resource categories, with no filler. It is arguably too terse rather than too verbose, but nothing present 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?

There is no output schema, so the description should indicate what the caller receives; it names the data categories but not the shape (per-campus grouping, fields per contact). For a trivial zero-parameter info tool this is close to adequate, but the return surface remains guesswork.

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

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

The tool takes zero parameters and the description adds no parameter claims, so there is nothing to misdescribe. Baseline for a 0-param tool applies; the only minor point is it doesn't say the call is unconditional and returns everything at once.

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

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

Names a concrete resource set: three-campus addresses plus transport, and frequently used phone numbers / emails. The content is unmistakable, but there is no verb (lookup? list?) and no explicit statement of how this differs from nearby siblings such as campus_map or campus_services.

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 or when-not-to-use guidance at all. With siblings like campus_map, campus_services, campus_dining, and transit_next in the same namespace, an agent has no hint about which one answers a 'where is X / how do I get there / who do I call' question.

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

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

No annotations are supplied, so the description carries the full behavioral disclosure burden, and it discloses almost nothing. It does not say the call is read-only (only implied by '快照'), whether the data is live or cached, how fresh the weather and shuttle data are, whether results are scoped to the current user, or how 'level' changes breadth or depth. For a tool that aggregates six data sources, omitting what actually happens at each level is a meaningful gap.

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

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

A single compact line with a label, a colon, and a slash-delimited content list has no wasted words, and the resource name is front-loaded. The format is scannable and dense, but here the extreme terseness comes at the cost of use-case guidance, so the size is efficient while still being incomplete.

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

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

With no output schema and no annotations, the description must carry both what is returned and how it behaves, and it only lists field topics. It does not explain the output shape at each verbosity level, which is essential because 'level' implies the returned structure varies. Compared with the tool's aggregation complexity, the definition is under-specified.

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

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

Schema description coverage is 100%: the single 'level' parameter has an enum (terse/normal/verbose) and a default of 'normal' documented in the schema. The description adds nothing about how each level changes the snapshot, such as terse returning only date/week versus verbose including todos. Per the high-coverage baseline, a 3 is appropriate, but the missing per-level detail is the one thing only the description could supply.

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 the resource (「此刻西湖」快照) and enumerates exactly which data categories are bundled: date, week number, academic calendar events, shuttle, weather, and todo deadlines. This tells an agent more than a generic name would, and no single sibling tool covers all of these categories. The only shortfall is that it is a noun phrase with no verb, so it never explicitly says it 'returns' or 'collects' these items.

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 gives no when-to-use guidance, no 'use this instead of calendar_today / transit_next / canvas_todo' routing, and no conditions that set it apart from the many sibling tools that cover the same data individually. An agent likely finds out that this is an all-in-one overview tool only by inference from the content list. The 'level' parameter, which controls how much data is returned, is never connected to a usage decision.

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

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

No annotations are supplied, so the description carries the full burden, yet it discloses nothing beyond the time window: no ordering, no pagination, no cap on result count, no indication of what an 'event' record contains or whether past events are excluded. Only the 'includes today' boundary is added.

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 clause with zero filler, and the time window is front-loaded. It is efficient rather than padded, though the brevity edges into under-specification rather than polished conciseness.

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, no-required-args read tool with no output schema, a short description can be adequate, and the inclusive-window detail is the key thing an agent needs. Still missing is any hint of what the events are or what comes back, which matters given the crowded calendar/news sibling set.

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

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

Schema description coverage is 100% and the single `days` parameter already documents its default of 14 and 0–90 bounds. The description adds one genuine clarification the schema lacks — that today counts toward the window — which is meaningful but minimal; 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?

"活动预告" plus a time window (next N days, including today) identifies the resource and its scope, but no verb is stated and the domain is ambiguous — with siblings like calendar_today, calendar_week, news_latest and career_latest in the list, an agent cannot tell whether these are campus events, calendar entries, or announcements. It is understandable but not sharply differentiated.

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 guidance on when to pick this over calendar_today, calendar_week, or news_latest, and no exclusions or prerequisites. The agent must infer usage purely from the name and the day-window phrasing.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only lookup but says nothing about result limits, pagination, total-count behavior when both filters are omitted, or whether matching is exact or fuzzy — all relevant for a zero-required-parameter search.

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

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

One compact sentence with the resource front-loaded and the filtering capability immediately following. Nothing is padded, though the extremely short length is partly the source of the transparency gaps.

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

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

For a two-parameter, all-optional read tool with a fully documented schema, the description covers purpose and filter intent. With no output schema, however, an agent gets no hint about what a result entry contains or how large the result set may be.

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

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

Schema description coverage is 100%, with examples (理学院, 工学院) and match fields (姓名/英文名/学科/实验室) already documented in the schema. The description restates the two filters without adding syntax, defaults, or matching semantics, so it meets the baseline 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?

The description gives a specific verb plus resource, 教师名录检索 (search the faculty directory), which is unambiguous. It does not name or differentiate itself from any sibling tool, though no sibling actually competes for the faculty-directory resource, so the omission is minor.

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

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

The parenthetical 可按学院或关键词过滤 implies both filters are optional and can be combined, which is real but implicit usage guidance. There is no statement of when to use this versus other search tools (e.g. program_course_search, instrument_search) and no exclusion or prerequisite 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?

No annotations are supplied, so the description carries the full behavioral burden. It usefully discloses the key trait that matching is synonym-tolerant and colloquial ('论文' → academic resources, '借书' → library), which an agent could not infer elsewhere. However it never says what comes back (a ranked capability list? command names? one match?) and gives no indication of scope limits, so the transparency is partial.

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

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

One sentence, front-loaded with the routing purpose before the parenthetical on synonym support. Nothing is padding; the example pairs are the shortest possible demonstration of the synonym behavior.

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

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

For a lightweight discovery tool with no annotations and no output schema, the description covers purpose and usage well. The notable gap is that the response shape is undefined in both description and structured fields, so an agent cannot predict whether it receives tool names, capability descriptions, or ranked suggestions – a meaningful omission for a router whose whole job is producing a next step.

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 'query' parameter, so the schema already defines it and supplies the same style of examples (作业 / 论文 / 班车 / 待办 / 预约). The description reinforces that natural-language or colloquial keywords are acceptable, which adds mild value, but the baseline of 3 applies when the schema does the documenting.

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 in a compact formula – '需求→能力路由' (need-to-capability routing) – and immediately defines what it searches over: which command/tool a need belongs to. It is unambiguous and clearly distinct from every sibling, which are concrete domain tools rather than a routing layer.

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 an explicit trigger condition: use it first when you are unsure which command/tool a requirement maps to. What is missing is the complementary clause – that you should skip it when the target tool is already known – and any guidance on what to do with the result once returned.

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

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

With no annotations at all, the description carries the full burden of disclosure, and it does not meet that burden. It never states that the operation is read-only, how deep the traversal goes, whether all sections are returned or only a subset, whether a missing host errors or returns empty, or anything about response shape.

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

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

It is a single short sentence with no filler, which is good, but its brevity comes at the cost of under-specification rather than efficiency. Nothing is front-loaded beyond a restatement of the tool name, and the parenthetical adds no 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?

There is no output schema and no annotations, so the description must explain what 'sections and items' actually look like, how the two relate, and how large a response can be. None of that is present, leaving an agent unable to predict the result or choose this tool confidently over its several close 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 the host parameter already documents itself with short-name examples (career / its / officialweb-test). The description only restates '某个子域' (a certain subdomain) and adds no new meaning such as accepted formats, case sensitivity, or behavior for unknown hosts, 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 phrase "取某个子域的栏目与条目" names a verb (fetch) and a resource (subdomain sections and items), so the basic purpose is inferrable. However, the qualifier "（通用挖掘）" (general mining) is vague and the description never distinguishes this tool from sibling tools such as site_content, site_detail, sites_index, or hosts_inventory, all of which operate on the same site/host space.

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 this tool should be used instead of hosts_inventory, site_content, site_detail, or sites_index. No prerequisites, no exclusions, and no indication of what 'general mining' means relative to the more specific-looking sibling tools.

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

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

No annotations are supplied, so the description has to carry the behavioral load. It does hint that liveness is assessed (存活/不可达) and that manual-configuration state is included, which are useful traits beyond the schema. But it never says whether the liveness check is a live network probe, how expensive or slow that is, what the ordering or scope is, or whether the call is purely read-only caching.

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

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

It is a single compact clause with the key information, the full inventory and its fields, front-loaded and free of filler. The downside is that this extreme terseness leaves the when-to-use context entirely absent, and the result reads more like a title than a description.

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

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

With no annotations and no output schema, the description must cover everything, and it does name the returned fields, which helps. Still missing are the scope of the inventory, whether the liveness results are fresh or cached, and its relationship to hosts_content, so an agent cannot fully predict the result.

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

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

The tool takes no parameters, so there is nothing parameter-related for the description to explain, and it correctly stays silent. Baseline 4 applies; there is no gap to compensate for.

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

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

The description states a specific verb (取) and resource (全量子域清单), and even enumerates the fields returned (存活/不可达、标题、是否人工配置). This is much more concrete than the bare name hosts_inventory, but it never says how it differs from hosts_content, the sibling most likely to be confused with it.

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 guidance on when to call this tool versus hosts_content, site_search, or sites_index. The usage is only implied by the word 清单 (inventory), which an agent has to infer on its own.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the four things the tool surfaces (address, token entry, model list, liveness), which is useful return-shape context, but it never states that it is read-only with no side effects, nor whether a token is required to call it.

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 line with the concrete contents front-loaded and no filler. It is terse to the point of omitting an action verb, 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?

For a zero-parameter tool with no output schema, the description should explain what the caller gets back and how to use it relative to hpc_chat. The enumerated sections partially cover the return values, but the relationship to the sibling chat tool and the auth flow 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?

The tool takes zero parameters and the schema coverage is complete, so there is nothing for the description to compensate for. Baseline 4 applies.

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

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

The description names a concrete resource set — Westlake AI gateway (OpenAI-compatible), gateway address, token-claim entry, model list, liveness probe — so an agent can guess it returns gateway/endpoint metadata. But it is a bare noun list with no verb, and it never distinguishes itself from the sibling hpc_chat, which is the obvious confusable 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?

There is no when-to-use guidance, no mention of prerequisites, and no routing to or away from the sibling hpc_chat. An agent must infer that this is the discovery/credentials tool rather than the chat tool.

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

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

With no annotations, the description carries the full disclosure burden, yet says nothing about authentication, latency, rate limits, cost, or whether conversation state is retained. It only restates the model roster already present in the schema.

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

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

A single front-loaded sentence with no filler beyond a redundant model list. Nothing is buried or padded.

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

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

For a simple three-parameter chat call the description covers the basic identity, but with no annotations and a near-duplicate sibling hpc_ai, it leaves the agent without the differentiation or operational context needed to choose confidently.

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

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

Schema coverage is 100%, so the schema already defines model, prompt, and system with a stated default. The description adds no new parameter meaning beyond repeating the model names, so the baseline of 3 applies.

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

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

States a specific verb and resource: invoke the Westlake AI large-model chat on the university cluster. The model list is repeated from the schema, and the description never distinguishes this tool from the sibling hpc_ai, which appears to cover overlapping territory.

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 use this versus hpc_ai or any other sibling, nor any prerequisites (account, VPN, quota). The agent must infer the choice entirely from the name.

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

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

No annotations are supplied, so the description must carry the full behavioral burden. It does disclose the useful behavior that results in room location, contacts, and a booking entry point, and its verb 检索 implies a read-only operation. But it does not mention caching behavior (which the refresh parameter hints at), how results are ordered, or what happens when no match is found. This is adequate but not rich.

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

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

A single sentence with a parenthetical enumeration, front-loaded on the verb and resource. Nothing is wasted, although the parenthetical mixing instrument examples with return fields is slightly dense and could be split for readability.

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

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

There is no output schema, but the description compensates by naming what a result contains (location, contact, booking link), which covers the main uncertainty of whether this is a directory or a booking tool. With a low-complexity, all-optional-parameter search tool, this is close to complete; only absence of result-shape or empty-result behavior keeps it from a 5.

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

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

Schema description coverage is 100%, and each of the three parameters (limit, keyword, refresh) is documented in the schema with examples and defaults. The prose adds the instrument categories that are valid keyword values, which marginally helps, but it does not explain the left limit bound (1–50) or the interaction between refresh and any caching layer. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

Combines a specific verb (检索) with a specific resource (西湖大学大型科研仪器设备) and enumerates concrete instrument classes (冷冻电镜、质谱仪、核磁共振、激光共焦). It also previews the returned fields (房间地点、联系人与预约入口), making the tool distinguishable from generic search siblings such as site_search or faculty_search. What is missing is explicit differentiation from the closest neighbors, but the domain is narrow enough that the distinction 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?

The description implies usage through the keyword parameter: an empty keyword returns a comprehensive list, and a specific term such as 电镜 narrows the search. However, it does not state when this tool should be preferred over sibling tools like sites_index, campus_map, or contact_info, nor does it give exclusions or prerequisites. The usage context remains 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?

No annotations are provided, so the description carries the full burden. It does disclose the two most important traits: this mutates state (写操作) and it is gated by validation (带校验门禁). It does not say what the gate checks, whether renewal can fail (e.g., renewal limit reached, item on hold), how many times renewal is allowed, or what happens to the due date.

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 first and the two key behavioral traits packed into a parenthetical. Nothing is redundant. It is arguably too terse rather than too long, but it is well 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?

For a write tool with zero annotation coverage and no output schema, the description leaves out what an agent needs to call it safely: eligibility conditions, likely failure modes, whether the result reports a new due date, and confirmation semantics beyond the schema's one-liner. The dry-run gate is the only behavioral detail given.

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%: the barcode and the confirm pre-check/dry-run flag are both documented in the schema itself, including the default behavior when confirm is omitted. The description adds no parameter-level detail beyond that, so the baseline of 3 applies.

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

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

States a specific verb and resource: online renewal of currently-borrowed books, plus a qualifier that it is a write operation with a validation gate. An agent can tell this is not a read/lookup tool. It stops short of naming any sibling or scope boundaries (e.g., which loan records qualify), so it is clear but not fully differentiated.

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

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

There is no explicit when-to-use or when-not-to-use guidance, no prerequisites, and no alternatives named among the many sibling tools. The parenthetical hint that it is a write with a gate implies a two-step flow, but the agent must infer that entirely.

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

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

No annotations are supplied, so the description carries the full disclosure burden and delivers almost nothing: it does not confirm this is a read-only operation, does not state ordering (recency?), the source of the news, or what happens when no items exist. Only the bare concept of 'latest items' is conveyed.

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

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

It is a single short sentence with zero filler and the key qualifier ('最新') front-loaded. The brevity is efficient, though it edges into under-specification rather than tight conciseness.

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-optional-parameter read tool with no output schema, the essentials are barely covered: the agent knows what it fetches but not what fields the items carry, what '西湖' refers to exactly, or how recency is defined. Marginally adequate, with real gaps.

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

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

Schema description coverage is 100% and the single 'limit' parameter is fully documented in the schema (1-50, default 10), so baseline 3 applies. The description adds no meaning beyond the schema, such as how results are ordered when the limit truncates the list.

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 concrete resource plus a scope qualifier ('西湖新闻' + '最新条目'), so an agent can tell it returns recent news items rather than search results or archives. It stops short of distinguishing itself from other '*_latest' siblings (research_latest, career_latest), so it is clear but not differentiated.

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 call this versus researching news through wiki_search/site_search or the other '_latest' tools, and no stated exclusions or prerequisites. The word '最新' implies fresh-content use, but that is inference rather than instruction.

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

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

No annotations are supplied, so the description carries the full behavioral burden, and it does disclose the most important trait: the call is destructive only when confirm=true, otherwise it is a safe existence check. It omits permissions required, whether a deleted job can be recovered, and what happens to a job that is already printing, which keeps it below a 5.

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

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

A single sentence with a colon-delimited structure that front-loads the action and the write-operation warning, then gives the mode switch. No filler and 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?

For a destructive mutation with no annotations and no output schema, the description covers the essentials: scope, default dry-run behavior, and the confirm gate. Only the shape of the precheck result and failure modes remain unspecified, which is a modest gap rather than a blocking one.

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

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

Schema description coverage is 100%, so job_id and confirm are already documented in the input schema, and the description's statements about them largely restate those definitions. It adds the two-phase framing (precheck vs. real delete) but no new detail such as ID format, defaults on the wire, or error semantics for a missing job.

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

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

The description names a specific verb and resource in Chinese: deleting a specified job from the self-service cloud print queue, and explicitly labels it a write operation. That clearly separates it from the read-oriented siblings pms_jobs and pms_stations and from pms_print, so an agent can choose 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?

It states the operating mode clearly: the default call only verifies job existence and returns a precheck result, and only confirm=true actually deletes. That is a concrete guide for how to sequence a call, but it never names an alternative tool or an explicit case where this tool should not be used.

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

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

No annotations are supplied, so the description carries the full disclosure burden, and it does add two useful facts: the list is scoped to the caller's own jobs ('个人') and to jobs not yet printed ('未打印'), plus the login requirement. It says nothing about what happens when unauthenticated, whether the result is empty-safe, or how many entries come back. For a zero-parameter read tool that is an acceptable but thin account.

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 phrase with the resource, the implicit filter, and the auth condition, with the login caveat front-loaded in parentheses. Nothing is redundant. It is arguably too terse to be fully self-sufficient, but no sentence 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?

For a no-parameter read tool with no output schema, the description covers what is listed, whose jobs, and the login gate. It leaves the return shape and ordering unstated, which an agent would need to know before presenting results. Adequate for the tool's low complexity, 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?

The tool takes no parameters, so there is no parameter meaning to add and the baseline applies. The description correctly implies the filtering is implicit (personal scope, unprinted only) rather than argument-driven, which prevents an agent from hunting for filter inputs.

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

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

The description names a specific resource and filter: the user's own unprinted print jobs at the library self-service printing service. The phrase '未打印作业列表' separates it from pms_print and pms_cancel, which act on jobs rather than list them, and from pms_stations, which lists hardware. It stops short of an explicit verb-plus-resource contrast with those siblings.

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

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

The parenthetical '需登录' gives a real prerequisite, implying the tool is only usable in an authenticated session. There is no statement of when to prefer this over pms_stations, pms_print, or pms_cancel, and no exclusion such as whether printed jobs are excluded or how far back the list reaches. Usage is implied rather than specified.

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

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

With no annotations, the description carries the full burden. It usefully discloses the two-phase dry-run/commit behavior and that the file is uploaded into a cloud print queue. It omits important side effects: whether printing consumes quota or balance, whether the job can later be cancelled via pms_cancel, and what the pre-check actually validates.

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, front-loaded with the write action and the pre-check caveat. Slightly telegraphic with the parenthetical service note, but no sentence 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?

For a five-parameter write tool with no annotations and no output schema, the agent still does not know what a pre-check returns or what a successful enqueue yields (job id? status?). The description covers the mutation risk but not the result contract, leaving a meaningful gap.

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

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

Schema description coverage is 100%, so copies, duplex, color and confirm semantics are already fully documented in the schema. The description only restates the settable fields and the confirm toggle, adding no format or constraint detail beyond the schema. 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?

Uses a concrete verb+resource pair: uploads a local document and creates a self-service print job on the cloud print service. It also marks the tool as a write operation, which distinguishes it from read-oriented siblings such as pms_jobs and pms_stations, 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 an actionable workflow rule: by default the call only pre-checks, and only confirm=true actually uploads and enqueues. That tells the agent to probe first and commit second. It does not, however, state when to prefer pms_cancel or pms_jobs afterwards, so alternative routing is left implicit.

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

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

With no annotations, the description carries the burden alone; it does disclose the no-login requirement and enumerates the returned attributes, which is real value. However it is ambiguous about whether only currently usable stations are returned or all stations with a status field, and it says nothing about ordering, pagination, or refresh behavior.

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

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

A single front-loaded sentence with the resource identified first and the return payload and auth note appended. No filler, though the parenthetical packaging is slightly dense compared to a clean clause list.

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-optional-param listing tool with no output schema and no annotations, the description covers identity, scope, returned fields, and the login-free property. The only genuine gap is clarifying the status semantics (all stations vs. available-only) and any ordering.

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

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

Schema description coverage is 100% and the single optional campus parameter already includes example values (「云栖」/「云谷」). The description mentions campus only as a returned field, not as a filter, so it adds no semantics beyond the schema — baseline 3 applies for a one-parameter tool.

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

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

The description names a concrete resource — 图书馆自助文印（联创云打印）网点 — and a read-only listing action (可用网点列表), plus the fields it returns (校区、位置、状态、支持纸型). It is clearly distinct from the sibling pms_print / pms_cancel / pms_jobs tools, though it never names those siblings explicitly.

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

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

Usage context is only implied: an agent can infer this is the discovery step before pms_print, and '无需登录' adds a practical precondition. There is no explicit when-to-use vs. when-to-use-alternative guidance and no statement of what to do with the results.

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

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

No annotations are supplied, so the description carries the full burden of behavioral disclosure. It says answers are authoritative but does not say whether responses are generated (potentially non-deterministic), whether sources or links are returned, whether there is latency or a rate limit, or what happens when the assistant has no answer.

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

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

One sentence, front-loaded with the target system and then the answer domains; nothing is padded. It could be slightly more useful if the second half were spent on behavioral facts instead of enumerating example categories.

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 tool with no output schema, the definition covers what the tool is and roughly what it answers. It omits how the answer comes back and whether it is a free-form AI response, which an agent needs to plan a follow-up call.

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

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

There is a single required parameter, question, whose schema description coverage is already 100% ('提问问题。'). The description adds nothing about phrasing, language, or granularity of a good question, so it can only reach the baseline for a fully documented 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 resource: ask the university's official AI assistant (西湖AI问答) a question. It also narrows the scope to campus regulations, service procedures and life guides, which distinguishes it from data-lookup siblings like wiki_search or affairs_portal. It stops short of naming a sibling 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 content domains (regulations, procedures, life guides) imply when the tool applies, but there is no explicit when-to-use or when-not-to-use guidance, and no mention of alternatives such as wiki_search or portal_cards. An agent must infer routing from the domain words alone.

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

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

No annotations are supplied, so the description carries full responsibility for describing behavior. '获取' implies a read-only retrieval, but the description does not say whether values are cached or how stale they are, even though the existence of a 'refresh' parameter implies cached data. It also omits authentication requirements, whether any data is mutated, or the response shape.

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 zero filler, and the enumeration of returned counts makes the scope immediately legible. Nothing is wasted or buried.

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, single-optional-parameter read tool with no output schema, the description tells the agent enough about what comes back to call it correctly. The only meaningful gap is the freshness and caching behavior implied by 'refresh'.

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

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

Schema description coverage is 100%, and the single optional 'refresh' parameter is documented in the schema as '强制重新拉取' (force refetch). The description adds nothing about the parameter, which is acceptable given the baseline for a fully documented schema, but it misses an easy opportunity to explain freshness 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?

The description states a specific verb and resource ('获取门户个人卡片概览') and enumerates exactly what is returned: unread mail, borrowed books, and pending-todo counts. An agent can tell this is an aggregate dashboard snapshot rather than a detailed list, so it is distinct from siblings such as canvas_todo or canvas_inbox. However, it does not explicitly name or contrast itself with those siblings.

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

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

The description provides no guidance on when to use this tool instead of relevant alternatives (canvas_todo, canvas_inbox, lib_renew, context_snapshot). Usage is only implied by the word '概览' (overview). There is no exclusion or prerequisite stated.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It does implicitly signal a read-only reference lookup and tells the agent which attributes come back (credits, term, prerequisites, teacher), which is useful since there is no output schema, but it says nothing about permissions, pagination, result size, or whether results are exhaustive versus filtered.

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

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

One compact sentence that front-loads the resource and then lists categories and returned fields — no filler or repetition. It is tight to the point of being terse, 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?

For a 3-optional-parameter, no-annotation, no-output-schema catalog tool, the description covers what the tool is and roughly what it returns, which is the minimum viable set. The critical gap is disambiguation: with siblings such as program_course_search, program_curriculum, and program_plan in the same family, an agent cannot tell from this text which one to 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 description coverage is 100%, so detail, keyword, and category are already documented in the schema; the description only echoes the category concept with example fragments (理工/人文/素质) and adds no format or interaction detail. With the schema doing the heavy lifting, the baseline 3 applies.

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

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

The description names the resource precisely — a general-education course catalog — and enumerates its three category buckets (理工基础 / 人文社科艺术 / 基础素质) plus the fields it carries (credits, term, prerequisites, instructor). No verb is used (it reads as a noun phrase rather than 'List/Get ...'), and it never contrasts itself with close siblings like program_course_search, program_curriculum, or canvas_courses.

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

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

There is no when-to-use guidance at all: no statement of the situation that selects this tool, no exclusions, and no mention of program_course_search or program_curriculum as alternatives. The agent must infer from the name alone that this is the browse-the-catalog path rather than the search path.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It states the fields returned, but does not say whether the search is exhaustive or paginated, whether results are limited, whether prerequisites are resolved recursively, or whether it requires enrollment or login — all material for an unannotated tool.

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

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

One sentence, front-loaded with the cross-source scope and then the returned attributes; every clause carries information. It is slightly clipped, packing four concepts into a single line, but there is no filler to cut.

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

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

For a three-parameter, read-only-looking lookup with no output schema, the description gives enough to call it correctly and sketches the return payload. It still leaves the relationship to the five neighboring program_* tools undefined, which is the largest completeness gap for an agent choosing among them.

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

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

Schema description coverage is 100%, so every parameter (keyword substring, detail toggle, common_only catalog restriction) is already documented in the schema. The description adds only the framing that 跨源 spans catalogs and plans, which lightly contextualizes common_only but provides no new syntax or 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?

The description names a specific verb-resource pair — course search — and states the two sources it spans (the general-education catalog and the major training programs) plus what it returns (归属/学分/先修). That is far more specific than a restated title, though it never names the near siblings program_courses or program_curriculum, so the agent must infer the boundary itself.

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 跨源 implicitly signals that this tool aggregates across sources, which hints that it should be preferred when the source is unknown. However, there is no explicit when-to-use, when-not, prerequisite, or named alternative, so the routing decision against program_courses and program_curriculum 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?

No annotations are supplied, so the description must carry the full burden of behavioral disclosure. It identifies the data provenance (招生网公开数据), which is genuinely useful, but it never says that this is a read-only lookup, whether the data is cached or live, how current it is, or what the response looks like.

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

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

One compact, front-loaded sentence enumerating the content categories with no filler. It loses a point only because it reads as a catalog blurb rather than an actionable instruction and carries no verb.

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

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

The low-complexity surface (one optional enum parameter) means little explanation is required. Still, with no output schema and no annotations, the description should say more about what the curriculum record contains or how to read it; listing content categories is only partial compensation.

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 optional parameter (lang), with an enum and 100% schema description coverage, so the schema already explains it fully. The description adds nothing about the parameter, which is acceptable at this coverage level but does not exceed the 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?

The description names a resource and enumerates its contents (核心课程、通识课程简表、专业课程、专业选定规则), so the scope is inferable. However, it is a noun phrase with no verb, and it gives no signal for separating this from the sibling tools program_courses, program_plan, and program_majors, which plausibly cover the same subject matter.

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 offers no when-to-use statement, no exclusions, and no reference to any alternative. An agent cannot tell from this text whether program_curriculum is the entry point for curriculum structure, a supplement to program_courses, or a replacement for program_plan.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses that the content is public admissions-site data, implying static read-only reference material, but never states that it is a read-only lookup, whether results are cached, or how complete/fresh the 8-major list is.

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

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

One front-loaded sentence with the scope and count up front and the data provenance in a short parenthetical; nothing is padded. It is compact enough that no trimming is needed.

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 lookup with one optional enum parameter and no output schema, the description covers what data exists but not what a per-major record contains (degree type, duration, department), forcing the agent to call blind. It is adequate but has a visible 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 the single 'lang' enum parameter is already documented as '站点语言，默认 zh'. The description adds nothing about language behavior (e.g. whether titles are translated), 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 the resource precisely ('本科专业设置', 8 majors in 理学/工学/医学) and its two views (total overview plus per-major introductions), so an agent knows what data it returns. It does not, however, distinguish itself from the closely related sibling program_overview, leaving overlap ambiguous.

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

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

Usage is only implied: the description lets an agent infer this is the place to look up which majors exist, but gives no explicit when-to-use rule and no exclusion such as 'use program_curriculum for course requirements'. With four sibling program_* tools present, that routing guidance is missing.

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

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

With no annotations supplied, the description does add one useful behavioral fact: the data comes from the public admissions site, so it is a safe public read. It says nothing about return size, structure, or whether content is cached or complete.

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

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

One compact sentence with the subject front-loaded and no filler. It is telegraphic to the point of being slightly terse, 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?

For a one-parameter, no-output-schema read tool, this is close to adequate, but it leaves what the response actually contains as prose content versus structured fields unspecified.

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 lang parameter is fully documented with an enum and default in the schema. The description's 'lang=zh/en' merely repeats the enum, adding no extra meaning.

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

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

The description names the specific resource: undergraduate education philosophy, training objectives, and eight training features. That is meaningfully distinct from the curriculum/majors/courses siblings, though it never explicitly contrasts itself with them.

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

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

There is no when-to-use guidance and no mention of the sibling tools (program_curriculum, program_majors, program_plan) that an agent must choose between. The content scope implies the overview role, but selection is left entirely 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?

No annotations are supplied, so the description must carry the behavioral burden. It does disclose genuine context the agent could not otherwise infer: the data comes from a public page on the main site and is in Chinese, implying no authentication and a fixed language. It does not state that the operation is read-only, whether results are cached or how fresh they are, or how large the response can get for a full 8-major default.

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 resource name and followed by the three content components, with the provenance note in parentheses. No filler, though the parenthetical source/language note is dense and would read better separated.

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

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

With no output schema, the description does the right thing by enumerating what is returned (credit blocks, course table, prerequisites), which is adequate for a two-parameter read tool. What is missing is any disambiguation against the other program_* tools and any sense of response shape or size, which matters in a catalog of 60+ 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 coverage is 100%: both parameters are documented, including the substring-matching behavior of 'major' and its default of all 8 majors, plus what 'detail' toggles. The description adds nothing beyond that, so the baseline of 3 is appropriate when the schema does all the work.

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

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

The description names a specific resource and its contents: a major's training plan, organized by credit block, with credit requirements, a course table, and prerequisites. That is far more informative than a restatement of the name. It stops short of a 5 because it never distinguishes this from the closely-named siblings program_curriculum, program_courses, or program_overview, which plausibly return overlapping content.

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

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

There is no when-to-use or when-not-to-use guidance, and no named alternative among the several program_* siblings. The only usage signal is implicit in the content description, and the useful default ('缺省返回全部 8 个专业') lives in the schema rather than the description.

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

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

No annotations are supplied, so the description carries the full burden, yet it discloses nothing about ordering (newest-first?), pagination, or what fields an entry contains. It at least implies a read-only listing operation, but the domain term 科研进展 remains undefined.

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

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

It is a single short sentence fragment with no filler, but that brevity comes from under-specification rather than discipline. Nothing is front-loaded because there is effectively nothing to load.

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

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

With no annotations, no output schema, and an ambiguous resource name, the description should define what a 科研进展 entry is and what a caller receives. It leaves both unanswered, so an agent can invoke the tool but cannot predict its results.

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 (limit) and schema description coverage is 100%, with the schema already stating the max-50 cap and default of 10. The description adds no meaning beyond that, 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?

"科研进展最新条目" restates the tool name research_latest (latest = 最新, research = 科研) without specifying the resource more precisely — it never says whether these are papers, projects, grants, or lab news. It gives no differentiation from near-identical siblings such as news_latest or career_latest.

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 or when-not-to-use guidance, no mention of prerequisites, and no pointer to an alternative tool. An agent seeing news_latest, career_latest and research_latest side by side gets nothing from this description to help choose.

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

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

With no annotations supplied, the description carries the full load and does disclose meaningful behavior: it performs an active beacon probe rather than reading cached state, and results are cached for 30 minutes. It omits what a probe costs in latency, how failures or non-publisher networks are reported, and what the return value looks like, which keeps it below a 5.

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

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

A single sentence with the core question front-loaded and the mechanism/caching detail parenthetical. Nothing is redundant and no explanation is buried at the end.

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 status probe, the definition covers what is checked and the caching behavior, but there is no output schema and no statement of the return shape (boolean vs. structured detail) or error semantics. An agent knows what the tool asks but not what it will receive back.

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 context the schema does not: the 30-minute cache window is exactly what makes the 'refresh' flag meaningful, telling the agent the default is a cached answer. It still gives no guidance on the cost of forcing a re-probe.

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 check: whether the current egress IP is treated as a campus network by publishers, via beacon probing. That is a clear verb+resource statement, and the parenthetical adds the mechanism. It does not differentiate itself from the closest sibling (vpn_status) or from the other scholar_* tools, so it stops short of a 5.

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

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

There is no explicit guidance on when to call this versus alternatives such as vpn_status or scholar_databases, and no stated prerequisites or exclusions. The intended use case (verifying off-campus publisher entitlement) can only be inferred from the purpose statement.

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

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

No annotations are provided, so the description must carry the full burden. It usefully explains the data model by giving meaning to the access-channel codes (campus IP, CARSI SSO, open access, independent account), but it does not state that the operation is read-only, describe the record shape beyond the access-channel field, or mention any constraints. It therefore adds some behavioral context but does not fully meet the burden.

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

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

It consists of one compact sentence, with the resource type front-loaded and the access-channel legend appended efficiently. No word is wasted; the sentence uses telegraphic punctuation instead of more prose-like structure, which is acceptable for a reference definition.

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

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

For a one-parameter lookup tool with no output schema and no annotations, the description covers what the registry contains and how each record is labeled, and it implicitly covers the default to all databases because the schema states that default explicitly. It is nearly complete; only the read-only nature and the expected result granularity are left unstated.

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 a description coverage of 100%; it fully documents the single optional 'keyword' parameter, including the '缺省全部' default. The description adds no meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description identifies a specific resource: a registry of Chinese and Western-language academic databases, with coverage categories (full-text, citation indexes, fact databases, data platforms) and access channels. However, it uses only a noun phrase and does not state an explicit verb such as 'list' or 'search'; this leaves the agent to infer what to do with the resource.

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 gives no guidance about when to use this tool: no prerequisites, no conditions under which another tool is better, and no exclusions. Although sibling tools such as scholar_campus and scholar_resolve_doi clearly have different roles, the description does not tell the agent which one it should choose.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose a non-obvious trait — that the tool probes the publisher landing page (skippable via pdf_url_only) and reports whether the egress IP is inside the campus authentication range — but says nothing about failure modes, rate limits, or what a partial result looks like.

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

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

A single dense sentence that front-loads the action and then the deliverables. Nothing is wasted, though the parenthetical about campus subscription is slightly compressed and could be clearer as a separate 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?

There is no output schema, so the description must convey return content, and it does list the three result components plus the campus-IP signal. Missing only edge-case behavior (DOI not found, no OA copy), which is a modest gap for a two-parameter read tool.

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

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

Schema coverage is 100%, so both doi and pdf_url_only are already documented, including the faster/limited trade-off. The description reinforces the notion of publisher landing-page probing but adds no format or behavioral detail beyond the schema's own text, making baseline 3 appropriate.

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

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

The description states a specific verb (解析) and resource (DOI) and enumerates the three outputs — CrossRef bibliographic record, OA copy, and publisher citation_pdf_url. It is clearly distinct from siblings like scholar_databases or scholar_campus, though it never names those alternatives to sharpen the 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?

Usage is only implied: an agent can infer this is the tool for turning a DOI into full-text/metadata. There is no explicit when-to-use versus scholar_databases or scholar_campus, and no statement of preconditions such as needing to be on the campus network (it only says the tool reports whether you are).

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

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

No annotations exist, so the description carries the full burden. It does disclose the two most important traits — read-only and no download — plus the exact fields returned, which is real value. It is silent on behavior that matters for a share tool: whether listing recurses into subdirectories, what happens with an invalid or unsaved share name, and any permission/auth constraints.

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

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

A single dense sentence with a colon-delimited return-field list plus a short behavioral note '只读，不下载' — front-loaded and free of filler. The very compact Chinese phrasing is efficient, though the field list is slightly cryptic without separators between items.

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 only three parameters, one required, and no output schema, the description does useful work by enumerating return fields and asserting read-only. It still leaves gaps an agent would want before calling: recursion depth, error behavior for an unresolvable share, and any hint about how a saved share name maps to a link.

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

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

Schema description coverage is 100%, so all three parameters (path, match, share) are already documented in the schema, making 3 the baseline. The description adds no extra semantics such as share-name lookup behavior or how path is resolved relative to the share root 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?

The description states a concrete verb+resource: listing files inside a OneDrive/SharePoint shared folder, with the common case (teacher-shared lecture notes) named explicitly. It also enumerates the returned fields (file name / byte size / modified time / is-subdirectory), which pins down the scope. It stops short of contrasting itself with near-siblings such as canvas_files, so not a 5.

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

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

Usage is implied rather than stated: the parenthetical '教师共享的讲义等' tells the agent this is for browsing material someone shared via a OneDrive/SharePoint link, and '不下载' signals the tool will not fetch content. There is no explicit when-not or pointer to an alternative (e.g. canvas_files for Canvas-hosted course files), leaving routing 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?

No annotations are supplied, so the description must carry the behavior burden. The verb 取 implies a read-only lookup, and the parenthetical (配额 / 余量 / 志愿人数) discloses which data is surfaced. However, it says nothing about permissions or scope (is it about the current user only?), nor about what happens before assignment results exist.

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

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

A single compact sentence with the core object (学业导师) front-loaded and return contents after the colon. Nothing is wasted, though the extreme brevity borders on under-specification.

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

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

There is no output schema, so the task of describing what is returned falls on the description. It lists the returned parts (assignment result, per-round rosters, quota/remaining/volunteer counts), which is helpful but does not explain the shape or meaning of these fields. For a zero-parameter read tool, this is adequate but not complete.

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

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

The tool takes zero parameters, so this is the baseline of 4: there is nothing in the schema to clarify beyond the empty object.

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: 取 (fetch) 学业导师 assignment results, plus the rosters per round. That is clearly distinguishable from the other sis_* tools such as sis_volunteer_history or sis_appointments. The only shortfall is that it never explicitly contrasts itself with any 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?

There is no guidance on when to call this rather than a related sibling (e.g. sis_volunteer_list or sis_status), or conditions such as whether the result only appears after allocation. The agent must infer that usage from the name alone.

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

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

No annotations are supplied, so the description carries the full burden. It hints at returned content (week range and occupied slots) but says nothing about whose appointments these are, whether authentication or authorization is required, or how sensitive counseling data is handled — a notable gap for a personal health-related resource.

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 scope qualifier front-loaded in parentheses; nothing is padded or redundant. It is arguably too terse rather than too verbose, but it is well structured.

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

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

With no annotations, no output schema, and no parameters, the description is the only source of behavioral information, and one line is not enough. It omits who the appointments belong to, the response shape, and any privacy or permission considerations for a counseling-data 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for parameter-free tools applies. The parenthetical does clarify what the implicit scope of the result is without any input.

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

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

The description names a specific verb and resource (retrieving this week's counseling/psychology appointments) and adds scope details (week range, occupied slots). However, it does not distinguish this tool from plausible siblings such as calendar_week or sis_schedule, so an agent cannot tell from the text alone which one to call for weekly schedule data.

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 stated prerequisites, and no mention of alternatives. Nothing tells the agent under what circumstances to prefer this over the many calendar/scheduling 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?

With no annotations supplied, the description carries the full burden, and it does disclose the most important trait: the operation is read-only and performs no enrollment writes. It says nothing about authentication requirements, empty-cart behavior, or freshness of the cart state, which are relevant for a session-dependent read.

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: verb plus resource first, then the returned fields, then the read-only scope constraint. Nothing is redundant and nothing needed to be moved forward.

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

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

For a zero-parameter read tool with no output schema and no annotations, the description covers purpose, returned content, and the read-only guarantee, which is enough to call it correctly. A note on what an empty or unavailable cart returns would close the remaining gap.

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

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

The tool takes zero parameters, so the baseline is 4; there is no parameter meaning for the description to add or omit. The field list in the description instead describes output content, which is a sensible use of the space.

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 (取 SIS 选课车内容) and enumerates the returned fields (课程 / 学分 / 状态), so the agent knows exactly what this tool yields. It does not, however, name the sibling tools (e.g. sis_registration) that handle the write-side enrollment that this tool explicitly excludes.

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

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

The parenthetical '只读，不做选课写操作' gives a clear when-not boundary: this is for viewing the cart, not for enrolling, which steers the agent away from using it for write tasks. The gap is that it never names the alternative tool that does perform enrollment, leaving that routing 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?

No annotations are supplied, so the description carries the full burden. It does add useful behavioral context by enumerating what the returned rows contain (学年 / 社团 / 发起人 / 人数), which is not derivable from the empty schema. However, it says nothing about authentication requirements, ordering, pagination, or what an empty list means.

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 action front-loaded and the returned fields glossed in parentheses. No filler, no restatement of the tool name, and nothing that could be trimmed without losing information.

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

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

For a zero-parameter, read-only personal-list tool with no output schema, the description covers both the action and the shape of the result, which is the main thing an agent needs. Only minor gaps remain — no mention of empty-state or whether results span all years.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to mistranslate. The parenthetical field list is a return-value hint rather than parameter meaning, but that is not a semantic defect here.

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 — "取我的社团列表" (get my club list) — with a clear personal scope ("我的"), which separates it from the many other sis_* tools. It is unambiguous what is being retrieved, though it does not explicitly name a sibling it is distinct 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?

Usage is only implied: the possessive "我的" signals that this is a self-scoped, argument-free lookup, so an agent can infer it needs no filters. There is no explicit statement of when to use this versus a general club/search tool, and no exclusions or prerequisites are given.

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

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

No annotations are supplied, so the description carries the full behavioral burden and it does not meet it. 取 implies a read-only fetch, but the description says nothing about what the tasks contain, whether they expire or have deadlines, whether results are scoped to a term, or how many to expect. For a zero-argument tool the risk is low, but essentially no behavioral context 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?

A single front-loaded sentence with no filler, hedging, or redundancy. Nothing in it could be cut, and the key qualifier (尚未完成) appears before the noun it modifies.

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

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

With no annotations and no output schema, the description is the only source of truth about results, and it does not say what a returned 评教任务 looks like or whether the list is per-course, per-term, or deadline-ordered. For a simple zero-argument read that may be tolerable, but it leaves the agent unable to describe or trust the response.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The absence of filters also means there are no parameter semantics an agent could get wrong.

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?

"取尚未完成的评教任务" gives a specific verb (取 = fetch) and a specific resource (评教任务 = teaching-evaluation tasks), further narrowed to incomplete ones. An agent can immediately tell this is a read of outstanding evaluation items, and no sibling tool in the list covers evaluations, so confusion risk is low. It stops short of 5 because it doesn't name its relationship to the surrounding sis_* family.

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 or when-not-to-use guidance, and no alternative is named. The only implied usage cue is the word 尚未完成 (not yet completed), which tells the agent this is for outstanding rather than completed evaluations, but nothing about prerequisites, timing, or when another tool would be preferable.

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

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

No annotations are supplied, so the description carries the burden. The verb 取 (fetch) signals a read-only operation and the parenthetical clarifies what data comes back, but it says nothing about whether results are personal-only, what happens outside exam periods (empty result vs error), or any access constraints.

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