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

Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is low; the description still adds a genuine disclosure beyond them: '不会输出 Key' guarantees the secret is never returned, and '读取当前账号' tells the agent an account identity comes back. What's missing is failure behavior (what a status looks like when the Key is invalid) — largely covered by the 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?

A single compact sentence that front-loads the three checks and ends with the privacy guarantee. Nothing redundant, nothing 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?

Return values are covered by the existing output schema and safety by the annotations, so the description needn't expand there. The one real hole is the undocumented check_remote switch, which matters because it changes whether a network request happens.

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

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

Schema description coverage is 0% and the single parameter check_remote (default true) is never mentioned by name. The phrase '是否有效' hints that remote validity checking is involved, but the agent must guess that check_remote is what toggles local-only vs network validation, and that the default incurs a remote call.

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

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

States a specific verb set (check existence/validity, read current account) on a specific resource (local API Key / current account). Purpose is unambiguous and no sibling tool in the list does authentication, so no explicit differentiation is required.

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 a pre-flight check before invoking the data-fetching siblings, but the description never says when to call it, when not to, or what to do on failure. No alternatives are named.

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

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

Annotations already declare a non-read-only, open-world, non-idempotent write, so the safety profile is partly covered. The description adds genuinely new behavioral information: remote writes are gated behind explicit user authorization and a confirm=true flag, which is exactly the kind of gate an agent must know before invoking. It does not describe failure behavior or what happens if confirm is omitted beyond the 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 sentence that front-loads the action and then the authorization prerequisite. Nothing is padded and every clause carries operational weight.

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

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

The tool has a full output schema and 100% parameter coverage, so return values and argument formats need not be explained. The description supplies the one thing structured fields cannot: the mandatory human-authorization step before this non-idempotent remote write.

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 every parameter including confirm and content constraints, establishing a baseline of 3. The description reinforces the confirm gate and lists the fields to surface to the user before writing, but adds no syntax or format detail beyond what the schema already provides.

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

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

The description states a specific verb and resource ("发布课程评价" — publish a course review), which is unambiguous against the read-side siblings like jcourse_list_course_reviews or jcourse_get_review. It does not explicitly distinguish itself from jcourse_update_review or jcourse_delete_review, so the new-vs-modify boundary is left to inference.

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

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

It gives an explicit pre-call workflow: show the user the final body, rating, semester, and score, obtain authorization, then send confirm=true. That is concrete when-to-use context. It stops short of saying when to prefer this over update_review, and gives no exclusion cases.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds a behavioral gate that the annotations do not: confirm=true is required, tying execution to explicit user authorization. It stops short of saying the deletion is irreversible or what the response reports.

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

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

Two short clauses separated by a semicolon, with the action front-loaded and the two operational requirements packed into the tail. There is no redundant restatement of the tool name or annotations.

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

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

An output schema exists, so return values need not be described, and annotations cover the destructive/non-idempotent profile. The only remaining gap for a destructive mutation is the absence of any note on irreversibility or on what happens when the enrollment no longer exists.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds provenance for enrollment_id (it comes from jcourse_list_enrolled_courses), which the schema only describes as 'a platform object ID, positive integer'. It also reinforces the confirm=true requirement consistent with the schema's default of false.

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

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

States a specific verb plus resource ('删除一条我的选课记录'), and the qualifier '我的' scopes it to the caller's own enrollments, distinguishing it from sibling deletion tools like jcourse_delete_review. An agent can identify exactly what object is affected 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?

Names the workflow prerequisite explicitly: the enrollment_id must come from jcourse_list_enrolled_courses, and confirm=true must be set. It gives the correct upstream tool for obtaining the ID but does not state when deletion should be avoided or what to do if the enrollment is already gone.

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

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

Annotations already flag destructiveHint=true and idempotentHint=false, and the description adds the irreversibility note (可能无法恢复) plus the mandatory confirm gate, which is useful operational context. It still doesn't say what happens when confirm is false or what the response 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?

Single compact sentence with the destructive warning and the confirm requirement front-loaded; no wasted wording.

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?

Output schema exists so return values need no explanation, and annotations cover the safety profile; description supplies irreversibility and the confirm gate. Minor gap: no mention of authentication or failure behavior for a destructive write.

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 confirm parameter is fully documented in the schema ('仅在用户已明确授权此次远端写入后设为 true'), so the description's mention of confirm=true is largely redundant. 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?

Specific verb (删除) + resource (评价) + scope (我发布的), which separates it cleanly from create_review, update_review and the read-only list/get 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?

States a precondition (confirm=true) but does not contrast with alternatives such as update_review or explain when not to delete; the use case (removing one's own review) is only implied.

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

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

Annotations already declare this a read-only, idempotent, non-destructive operation. The description adds that it surfaces user-specific state (follow status, my enrollment, my review), hinting at an auth dependency, but since an output schema exists the enumerated return fields carry limited extra disclosure.

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

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

A single front-loaded sentence that lists the payload with zero filler. Every token contributes to understanding what the tool returns.

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

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

With an output schema, full param coverage, and rich annotations, the description is largely sufficient. Minor gaps remain: it does not state the auth requirement for the personalized fields nor how to obtain a valid course_id, but these are small against the structured data provided.

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 single parameter has 100% schema description coverage ('平台对象 ID，正整数'), so the schema already documents type, minimum, and meaning. The description adds no syntax or format detail beyond that baseline.

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

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

States a specific verb (读取) and resource (课程详情) and enumerates the exact data returned: teacher group, semester, rating distribution, follow status, enrollment, and my review. This lets an agent know precisely what it retrieves, though it does not explicitly distinguish itself from siblings like jcourse_get_course_review_trend or jcourse_get_teacher.

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

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

Usage is implied: call it to fetch a single course's detail given a course_id. There is no explicit when/when-not guidance and no mention of alternatives such as jcourse_search_courses for obtaining IDs, or siblings for reviews/trends, 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds that results include counts alongside values, which is useful behavioral context, but says nothing about auth requirements, caching, or cost for an openWorldHint 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 sentence, front-loaded with the action and immediately followed by the concrete facet list. No filler.

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

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

A no-argument, read-only query tool with an output schema and full annotation coverage needs little more than this; the description names the facets so an agent knows what the output schema will contain. Only the connection to jcourse_search_courses as the downstream consumer is 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?

Zero parameters, so the baseline of 4 applies; the description correctly spends no words on argument semantics and instead describes the returned facets.

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

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

States a specific verb (读取) and resource (课程筛选值及计数) and enumerates the facets returned: credits, department, category, target grade, language, semester. The 'course' qualifier implicitly separates it from jcourse_get_course_review_filters and jcourse_get_teacher_filters, though no sibling is named explicitly.

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

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

Usage is only implied: an agent can infer this is for discovering available filter values (with counts) before calling jcourse_search_courses. There is no explicit 'use this when…' statement, no mention of when to prefer the review or teacher filter variants, and no stated prerequisites.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds only what the returned content is (semesters and rating options); it says nothing further about scoping, freshness, or empty-result behavior, which is acceptable but modest value-add.

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 and no redundancy. It is appropriately terse for a single-purpose lookup tool, though it lacks any structural cue about ordering or the shape of the result.

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 lookup with full schema coverage, annotations, and an output schema that defines the return values, the description supplies enough to call the tool correctly. The only missing piece is explicit guidance on when this lookup is the right step versus the sibling filter/search tools.

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

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

There is a single required parameter with 100% schema description coverage ('平台对象 ID，正整数'), so the schema fully documents it. The description does not restate or extend parameter meaning, which is the baseline case rather than an added-value case.

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

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

The description names a specific verb (读取) and resource (某门课程评价可用的学期和评分筛选项), so an agent knows it returns filter metadata rather than reviews themselves. It does not, however, differentiate itself from the similarly named sibling jcourse_get_course_filters or say how it relates to jcourse_list_course_reviews.

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 it should call this before list_course_reviews to discover valid semester/rating values. There is no explicit statement of when to use it, when not to, or which sibling to prefer for course-level filters.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered structurally. The description adds only that output is per-semester counts and averages; it says nothing about how empty semesters or missing scores are handled, or about result ordering/limits.

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

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

One short sentence, front-loaded with the aggregation verb and granularity, with zero filler. It is terse to the point of omitting caveats, but nothing is wasted.

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

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

An output schema exists, so return-value detail need not be restated, and the single parameter is fully described in the schema. For a simple read-only aggregation over one ID, the description plus structured fields cover what an agent needs to select and call 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?

With a single required parameter and 100% schema description coverage, the schema already fully documents course_id as a positive integer platform object ID. The description only implies that the ID refers to the course being summarized, adding no format or lookup guidance beyond the schema.

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

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

States a specific verb (汇总/aggregate) and resource (某门课程的评价) plus the granularity (按学期) and the metrics produced (数量与平均分). This clearly separates it from jcourse_list_course_reviews, which returns individual reviews, though no sibling is named explicitly.

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

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

Usage is only implied: '汇总' signals aggregation, so an agent can infer this is for trend/summary questions rather than browsing reviews. There is no explicit when-to-use, no when-not-to-use, and no mention of alternatives such as list_course_reviews.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety burden is low. The description earns credit for a real semantic caveat beyond structured data: the hot score reflects community activity, not course rating — this prevents the agent from misreporting the ranking as quality.

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

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

Two short clauses, front-loaded with the scope and followed immediately by the disambiguation caveat. Nothing is padded, though the second clause could be framed as actionable guidance rather than a bare statement of fact.

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?

Output schema exists, so return values need no explanation, and annotations cover the safety profile. Still missing: any mention of limit behavior (default 10, max 50) and how results are ordered/paginated, which matters for a ranked-list 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 0%, so the description must carry parameter meaning. It covers the period dimension ('本周或本月' maps to the week/month enum) but says nothing about limit, its default, or its 50 cap; the limit parameter stays undocumented in both places.

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

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

States a specific verb (读取) and resource (热门课程) plus the time scope (本周或本月), which is more than the bare name gives. It is distinguishable from search_courses and list_enrolled_courses, 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?

The week/month framing implies a discovery/browsing use case, but there is no explicit when-to-use or when-not-to-use guidance relative to jcourse_search_courses or jcourse_list_enrolled_courses. The agent must infer the selection rule 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description is fully consistent with that safe read profile. It adds real context the annotations don't: the data is scoped to the caller's own account, and pagination exists with defaults of 1/20, capped at 20, though that detail comes only from 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?

It is a single compact clause with the resource named first and the scope exclusion second, so nothing is buried. It is arguably terse enough that an agent must infer the pagination behavior from the schema, 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?

With an output schema present and annotations covering the safety profile, the description only needs to establish scope, which it does. Nothing essential is missing – the return shape is documented elsewhere and both parameters are self-describing – though a note on soft limits or auth requirements would have raised the score.

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% – page and page_size both carry their own Chinese descriptions with defaults and bounds – so the schema handles parameter semantics. The description implies paginated records ('积分记录') but adds no format or usage detail beyond that, which is the expected baseline 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?

States a specific verb and resource: read ('读取') the caller's points total and points history. It also scopes the tool by excluding spending/transfer operations, so an agent immediately knows this is a read-only balance/history lookup.

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

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

The phrase '读取我的' signals this covers only the authenticated user's own points, and the exclusion clause '不涉及积分消费或转账' tells the agent what not to expect from it. No sibling tool handles points, so no explicit alternative is needed, but it never states a when-to-use trigger beyond that.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered structurally. The description adds value by naming what the caller receives — vote statistics and moderator notes are non-obvious side content — but does not say what happens for a missing or deleted review id, so the addition is moderate rather than 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?

One front-loaded sentence with the verb and scope first, then the returned contents; no filler or redundancy. It is tight enough to be efficient, though the payload enumeration is a compact list rather than a prioritized statement of what matters most.

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

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

An output schema exists and annotations cover safety, so the description only needs to establish selection and payload shape, which it does. The only gap is error/edge behavior for a nonexistent review id, which is minor for a read-only single-record fetch.

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

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

There is a single parameter with 100% schema description coverage ('平台对象 ID，正整数' plus minimum 1), so the schema already carries the semantics. The description's 单条 reinforces that the id targets one review, but it adds no format, range, or lookup guidance 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?

The description uses a specific verb (读取) with a precisely scoped resource (单条评价, i.e. a single review), and it enumerates the payload (full text, course info, vote stats, moderator notes, web link). The word 单条 distinguishes it cleanly from the list_* siblings such as jcourse_list_reviews and jcourse_list_course_reviews without needing to open any schema.

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

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

Usage is only implied: fetching one review by id is self-evidently different from the list tools, but the description never states when to prefer this over jcourse_list_course_reviews or jcourse_get_course, and it gives no prerequisites or exclusions. The agent must infer the routing from the tool name and scope words.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely new behavior – that values marked 'secret' are filtered out of the response – which prevents an agent from assuming it will receive the full config. It stops short of describing anything else about the returned payload.

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

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

Two short clauses, zero filler, with the resource and the most consequential caveat (secret filtering) both up front. Every clause earns its place.

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

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

A zero-parameter read tool with an output schema and full annotation coverage needs little more than a purpose statement plus the filtering caveat, both of which are present. Nothing required to invoke it correctly is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No misleading parameter claims are made.

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

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

The description states a specific verb+resource ('读取站点公开系统设置') and narrows scope to public settings. It is clearly distinguishable from the course/review/teacher siblings by resource, though it never names an alternative explicitly.

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

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

Usage is implied – an agent infers this is the tool for site-level metadata such as feature flags or config – but there is no stated when/when-not guidance. Given no sibling covers site settings, the absence of alternatives costs little, but nothing is made explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds the set of fields returned, which is mild extra value but partly redundant with the output schema; it does not discuss error behavior for invalid IDs or rate limits.

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

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

A single compact sentence front-loads the verb and resource, then lists the payload fields; there is no filler. It is appropriately sized for a simple one-parameter read tool.

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

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

For a simple read-only lookup with a single fully documented parameter, complete annotations and an existing output schema, the description covers what an agent needs to select and call it. The only shortfall is the absence of sibling routing guidance.

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 at 100% schema description coverage, with the schema already documenting it as a positive integer platform object ID. The description adds no additional meaning beyond identifying that a teacher is being looked up, 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 uses a specific verb (读取/read) with a specific resource (教师详情/teacher details) and enumerates the returned fields (name, code, department, title, webpage link), which makes the tool's purpose unambiguous. It does not, however, explicitly distinguish itself from search_teachers or list_teacher_courses, leaving sibling differentiation 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?

Usage is only implied: the required teacher_id parameter suggests an ID-based detail lookup versus the search-style siblings. There is no explicit statement of when to use this instead of jcourse_search_teachers or jcourse_list_teacher_courses, and no exclusions or prerequisites 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds that filter values include counts, but provides little additional behavioral context beyond annotations and the 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?

A single compact sentence with the key information front-loaded: verb, resource, and returned filter categories. No wasted text.

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, the description is largely complete: annotations cover safety, an output schema exists, and the description names the returned filter dimensions. It could mention usage context, but no critical information is missing for invocation.

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

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

The tool has zero parameters, so there are no parameter semantics to document. Per the rubric, zero parameters receive a baseline score of 4.

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

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

States a specific verb and resource: reading teacher filter values, and clarifies the values are departments and titles with counts. It is clear what the tool returns, though it does not explicitly differentiate itself from sibling jcourse_get_course_filters.

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: the tool is for obtaining teacher filter values. However, there is no explicit guidance on when to use it versus siblings like jcourse_search_teachers or jcourse_get_course_filters, and no when-not guidance.

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

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

Annotations already declare this as a safe, idempotent, non-destructive read, so the safety profile is carried. The description adds one genuine behavioral fact — that only currently-valid announcements are returned ('当前有效') — but says nothing about ordering, volume, or whether expired/pinned announcements are 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?

One front-loaded sentence naming the verb, the resource, and the returned fields — no filler, nothing an agent must scroll past.

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

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

An output schema exists, so the description needn't enumerate return values, and the annotations cover the safety contract. For a parameterless read tool this is close to sufficient; only the 'what counts as active' filter and result ordering are left implicit.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain; the baseline score applies. The description correctly implies no input is needed by simply listing what is read.

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

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

Names a specific verb and resource ('读取...公告') plus the fields involved (time, priority, external link). The announcements domain is clearly distinct from the course/review/teacher siblings, though the description doesn't explicitly state 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?

Usage is only implied — an agent can infer it should call this to see site announcements. There is no explicit when-to-use, no prerequisites, and no mention of how it relates to jcourse_get_system_settings or the auth tools, which are the nearest neighbours in the site-metadata family.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, so the safety profile is covered. The description adds pagination plus the default sort semantics (like_count), which is real context, but says nothing about result volume, auth requirements, or how paging interacts with total counts despite being an open-world web-backed 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 with the core action front-loaded and the ordering trade-off attached as a clarifying clause. Zero filler, nothing repetitive.

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

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

With an output schema and full annotations, the description needn't explain return values, and it covers the pagination and default-sort essentials. But for an 8-parameter tool with four undocumented parameters and several near-identical list-review siblings, an agent still lacks guidance on filtering semantics and sibling choice.

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 exactly 50%: q, page, course_id, and page_size are documented in the schema, while order_by, ascend, rating, and semester are not. The description only partially compensates, explaining the meaning of like_count vs time-based ordering but leaving ascend direction, rating filtering, and semester matching entirely to the enum/type definitions.

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

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

States a specific verb and resource (分页读取课程评价) plus the default ordering behavior, so an agent can immediately tell it lists paginated reviews for a course. It does not distinguish itself from the close siblings jcourse_list_reviews or jcourse_list_followed_reviews, which is the only missing piece for 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?

It gives useful selection guidance for ordering (获赞 for representative reviews, 时间 for recent feedback), which is genuinely actionable. However, it never says when to prefer this over jcourse_list_reviews, list_my_reviews, or create/update_review, and gives no prerequisites or exclusions, so usage is only implied.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered and the description does not need to restate it. What the description adds is the cross-tool dependency: the returned ID is the input for a delete operation, which is genuinely useful behavioral context. It stops short of describing result shape or whether the list is scoped to current term or all history.

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

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

Two tight clauses, zero filler. The primary purpose is stated first and the downstream-use note follows, so an agent skimming the first few characters already knows what the tool returns.

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

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

An output schema exists, so return-value structure need not be explained. Parameter count is zero, so there is no schema gap to compensate for, and the description covers the one non-obvious fact: the ID feeds deletion. Slightly incomplete in not indicating scope (all enrollments vs. active only), but that is a minor gap for a simple list 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 the schema baseline of 4 applies. The description correctly avoids inventing parameter guidance and instead spends its words on the return-value semantics an agent needs (per-record IDs).

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?

A specific verb+resource in the first clause ('列出我的选课记录' — list my enrolled course records) plus a second clause that identifies what each entry contains (record ID). This distinguishes it from the many other jcourse list_* siblings (followed, ignored, my_reviews) without ambiguity about which collection is returned.

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

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

The clause '删除记录时需要使用该 ID' implies the tool is a prerequisite step for jcourse_delete_enrollment, which is a real usage signal beyond the name. However, it never names the sibling tool explicitly and gives no when-not guidance (e.g. how it differs from jcourse_list_followed_courses or jcourse_list_ignored_courses).

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is fully covered. The description adds one genuinely useful behavioral fact — that 'followed' means notification level 1 — but says nothing about pagination limits, ordering behavior, or auth requirements.

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

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

A single tight sentence with the resource and its defining constraint front-loaded and no filler. It is efficient, though its brevity comes at the cost of leaving ordering and scope questions unanswered.

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

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

An output schema exists, so return values need not be explained, and the annotations cover safety. However, for a four-parameter list tool with an ordering enum and a boolean sort direction, the description leaves the sorting semantics entirely unexplained and gives no guidance on choosing among the several sibling list tools.

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 only 50%: 'page' and 'page_size' are documented in the schema, but 'order_by' (an enum of rating_score/rating_count/rating_avg) and 'ascend' have no description anywhere. The description's mention of 分页 (pagination) merely restates what the schema already documents and does not compensate for the undocumented sorting parameters.

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

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

The description states a specific verb (列出/list) and resource (我关注的课程/followed courses), and disambiguates the scope by defining 'followed' as notification level 1. This distinguishes it from siblings like jcourse_list_enrolled_courses and jcourse_list_ignored_courses, though it does not name them explicitly.

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

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

There is no guidance on when to use this tool versus jcourse_list_enrolled_courses, jcourse_list_ignored_courses, or jcourse_set_course_notification. Usage is only implied by the tool name and the parenthetical definition of 'followed'.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and openWorld, so the safety profile is fully covered. The description adds only the pagination behavior and default ordering, both of which largely duplicate schema defaults; it doesn't clarify what 新评价 means (unread? recently created?) or how pagination terminates.

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, which is the right shape. It is arguably too terse for a seven-parameter tool, but nothing in it 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 seven parameters, 43% schema coverage, and several unlabeled filters (rating, semester, ascend), the description is far too thin. The output schema covers return values, but an agent still cannot tell how the filters interact or what 'new reviews' scopes.

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 only 43%, so the description is expected to compensate but does not. It says nothing about the filter parameters q, rating, semester, order_by, or ascend, leaving four of seven parameters with no explanation anywhere.

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

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

The description gives a specific verb (分页读取), resource (已关注课程的新评价), and scope restriction to followed courses, which separates it from generic review listers like jcourse_list_reviews or jcourse_list_my_reviews. It doesn't name any sibling explicitly, so it falls short of a 5.

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

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

The phrase 已关注课程 implies the usage context (you must follow courses for this to return anything), but there is no explicit statement of when to prefer this over jcourse_list_reviews or jcourse_list_course_reviews, and no prerequisites are spelled out. Usage is inferable but not guided.

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

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

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile needs no restating. The description adds one useful behavioral fact the annotations don't carry — that 'ignored' means notification level 2 — but says nothing about auth requirements, sort semantics, or result completeness across pages.

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; the meaning of 'ignored' is parenthetically defined rather than buried. Brevity is appropriate for a simple paginated list, though it leaves the ordering options unexplained.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile. Still, for a list tool with a sort/order surface (three order_by values plus ascend) that the description never touches, the definition is only minimally sufficient.

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 only 50%: page and page_size are documented in-schema, while ascend and order_by (an enum of rating_score / rating_count / rating_avg) have no schema description. The description's 分页 adds nothing beyond the schema and gives no meaning for the ordering parameters, so it fails to compensate for the gap.

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

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

States a specific verb (分页列出) and resource (忽略的课程), and defines the otherwise-ambiguous term 'ignored' as notification level 2, which an agent could not infer alone. It does not explicitly name the sibling list tools (jcourse_list_enrolled_courses / jcourse_list_followed_courses) it differs from, so 4 rather than 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 scope is narrow enough that usage is implied (this is the only tool that returns ignored courses), but there is no explicit when-to-use, no mention of how a course becomes ignored (jcourse_set_course_notification), and no routing away from the other list_* 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?

The annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the pagination trait and enumerates available filter dimensions, but says nothing about default ordering, result size/limits, or auth requirements. No contradiction with annotations.

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

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

A single front-loaded sentence with the resource scope first and the filter capabilities after. Nothing is wasted and nothing is 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?

An output schema exists, so return values need not be explained, and annotations cover safety. But for a 7-parameter listing tool with only 43% schema description coverage, the description is thin: default ordering, the relationship between ascend and order_by, and the practical difference from the other list_* siblings are all 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 description coverage is only 43%, so the description must carry weight; it names the four filter dimensions (keyword, semester, rating, sort) which maps onto q, semester, rating, order_by/ascend. However it adds no semantics beyond naming — no default sort direction, no note that ascend only matters with order_by, no constraint hints for rating or page_size.

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 a clearly scoped resource (我发布的评价), which distinguishes it from jcourse_list_reviews and jcourse_list_course_reviews. The sibling names are never referenced explicitly, so the agent must infer the distinction from the possessive scope alone.

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

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

Usage is only implied: the possessive 我发布的 signals 'use this for my own reviews', and the filter list hints at narrowing. There is no explicit statement of when to prefer this over jcourse_list_reviews or jcourse_list_followed_reviews, and no prerequisites or exclusions are given.

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

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

Annotations already declare this a safe, idempotent read, so the bar is lower; the description still adds genuine behavioral information by disclosing that ignored courses are excluded from results — a non-obvious side effect an agent could otherwise misread as missing data. It stops short of mentioning default ordering or pagination limits.

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

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

Two short clauses, front-loaded with the operation and scope before the filtering caveats; nothing is redundant. It is arguably over-compressed given the number of undocumented ordering parameters, but every sentence earns its place.

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

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

An output schema exists so return values need no explanation, and annotations cover the safety profile, but with 7 optional parameters and only 43% schema coverage the description leaves ordering and direction semantics unaddressed. Adequate for selecting the tool, thin for invoking it precisely.

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 43% (below 50%), so the description must compensate more than it does. It covers q, semester, and rating filtering, but says nothing about order_by (three enum values, default updated_at) or ascend, which are exactly the undocumented parameters that control result ordering.

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

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

"分页读取全站评价" names a specific verb (分页读取) and resource (评价) and states the scope as site-wide, which implicitly contrasts with the course-scoped, followed, and personal review lists among the siblings. It does not explicitly name those siblings, 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 word 全站 signals this is the broad discovery endpoint rather than jcourse_list_course_reviews or jcourse_list_my_reviews, and the filters hint at search-style usage. However, there is no explicit "use this instead of X when..." and no statement of prerequisites (e.g., whether auth is needed for ignored-course exclusion).

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds pagination and the supported filter/sort axes, but says nothing about default ordering (rating_score), the 100-item page cap, or how ascend interacts with order_by.

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 that states the operation and enumerates the filter axes with no filler. It is efficient, though the filter list is a bare enumeration rather than prioritized 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?

With 12 parameters (11 optional filters) and an output schema, the description should at minimum explain the sort/pagination knobs; it covers most filter names but omits has_review, ascend semantics and how target_years values are sourced. Adequate, but leaves real gaps for a heavily-parameterized list 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 50%: q, page, page_size, categories, target_years and teacher_id are documented inline, while ascend, credit, language, order_by, has_review and department are not. The description echoes keyword/department/language/category/credit/sorting, giving partial coverage but no meaning for ascend, has_review, or the order_by enum values beyond 'rating sorting'.

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 a clearly scoped resource (教师开设的课程), which separates it from jcourse_search_courses and jcourse_get_course by teacher scope. It does not explicitly name those siblings as alternatives, 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?

The teacher-scoped phrasing plus the required teacher_id implies you must already know the teacher, but the description never states when to prefer this over jcourse_search_courses or how to obtain teacher_id (e.g. via jcourse_search_teachers). Usage is inferable but not guided.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, and an output schema exists, so listing return fields adds little. The description says nothing about pagination behavior, sorting defaults (order_by='rating_score'), or the dependency on filter tools for the categories/target_years values — the traits that would actually matter here.

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 well-formed sentence with the core action front-loaded and zero filler. It is efficient, though its content is thin relative to the tool's 11-parameter surface.

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 an 11-parameter search tool with enum-based sorting, array filters sourced from separate filter tools, and pagination, one sentence is not enough. Key operational facts — how to discover valid category/year values and how sorting/paging behave — are left entirely to the schema.

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 only 45% across 11 parameters, and the description compensates for none of it: no mention of q, credit, language, department, has_review, order_by semantics, or pagination. A one-line mention of '筛选' does not explain which filters exist or how they combine.

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 clear verb+resource pair ('搜索或筛选课程') and even enumerates the returned fields, so the agent knows this is the course search endpoint. It does not, however, distinguish it from adjacent siblings such as jcourse_get_hot_courses, jcourse_list_teacher_courses, or jcourse_list_enrolled_courses, which all return courses under different scopes.

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

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

There is no statement of when to use this tool versus the many course-listing siblings (hot courses, teacher courses, enrolled/followed/ignored courses), nor any precondition such as needing to fetch filter values first. The agent must infer the routing decision from 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds nothing beyond annotations, because it does not cover pagination, combination of filters, result limits, or authentication.

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 one short sentence that front-loads the action and then lists the return fields, with no wasted wording. It is tight, though possibly too tight for a tool with five parameters.

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

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

An output schema exists, so explaining return values is not strictly needed, and the annotations cover the safety profile. However, with two of the five parameters undocumented in the schema and no notes on pagination or filter combination, the description is 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 60%: q, page and page_size are documented in the schema, while title and department have no description. The mention of 院系 and 职称 in the return-field list only weakly hints that these are filterable, so this falls in the baseline range.

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 pair (搜索/筛选) and the resource (教师), and it enumerates the fields returned. It is clear what the tool does, but it never names or distinguishes itself from siblings such as jcourse_get_teacher or jcourse_get_teacher_filters.

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 instead of jcourse_get_teacher (single lookup) or jcourse_get_teacher_filters (available filter values). A reader must infer usage from the verb 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?

Annotations already declare readOnly=false, idempotent=true, destructive=false and openWorld=true. The description adds the useful context that this mutates remote state and demands an explicit confirm flag, which goes beyond the annotation set and matches the confirm parameter's stated authorization intent. No contradiction with annotations.

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

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

A single compact sentence with the action and level mapping first, then the write/confirm caveat. Nothing redundant 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 3-parameter mutation with an output schema and rich annotations, the description supplies the enum semantics and the write-safety requirement. Minor residual gaps (auth prerequisites, behavior on invalid course_id) are acceptable given the schema and annotations already cover safety and return 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 coverage is 67%, and the description closes the biggest gap by assigning human-readable meaning to the bare numeric enum values (0/1/2), which the schema only lists as integers. It also flags confirm's role, though it doesn't restate course_id's positive-integer constraint.

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

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

States a specific verb (设置) and resource (课程通知级别) and enumerates the three levels with their meanings (0 正常 / 1 关注 / 2 忽略). An agent can immediately tell this is the per-course notification-level mutation, distinct from the read-only siblings like jcourse_list_ignored_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?

The description states the prerequisite that a remote write occurs and confirm=true is required, which is actionable. However, it gives no guidance on when to prefer this over alternatives, no exclusions, and no mention of what happens if confirm is omitted.

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

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

Annotations already declare destructiveHint=true, openWorldHint=true, idempotentHint=false, and readOnlyHint=false. The description adds meaningful context beyond them: partial-update semantics, score clearing via empty string, and the confirm=true gate. It does not detail return behavior or auth beyond confirm, but that is largely covered by annotations and 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?

The description is a single compact statement, front-loaded with the action and followed by the two critical behavioral caveats. Every clause carries useful 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?

Given that annotations cover safety and side effects and an output schema exists, the description supplies the essential update semantics and confirm requirement. It is still thin on when to use this versus sibling tools and on some optional field meanings, but it is complete enough for correct invocation.

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

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

Schema description coverage is 50%, with rating, content, and semester lacking descriptions. The description adds real semantics for score clearing, confirm=true, and omitted-field retention, but it leaves the meaning of rating, content, and semester largely to the schema.

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

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

The description names a specific verb and resource: 修改 (modify) '我的一条评价' (one of my reviews). This distinguishes it from create_review, delete_review, and vote_review in practice, though it does not explicitly name 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?

It implies use for editing an existing review and gives field-level guidance: omitted fields keep original values, an empty string clears score, and confirm=true is required. It never states when to choose this over create_review, delete_review, or other alternatives, so usage guidance 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?

Annotations declare this is a non-destructive, non-idempotent, open-world write; the description adds genuinely new behavioral context beyond them — a per-day voting cap and the confirm=true authorization requirement. It stops short of 5 because it doesn't say whether re-voting overwrites or how the cap surfaces as an error.

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 with the action set front-loaded and the constraints after it; nothing is wasted. It is slightly terse for the confirm requirement, but structurally sound.

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

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

An output schema exists, so return values needn't be explained, and annotations already cover the safety profile. The description supplies the two non-obvious operational facts (daily cap, confirm gate), making it largely complete for a simple 3-parameter vote 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 67% and the schema already defines the vote enum values and the confirm authorization meaning, so the description's mention of like/dislike/clear and confirm=true largely restates it. review_id is left entirely to the schema. Baseline 3 is appropriate 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?

States a specific verb (vote) and resource (review) and enumerates the three allowed operations (like/dislike/clear), so an agent knows exactly what the tool does. It does not explicitly differentiate itself from sibling review-mutation tools like jcourse_update_review, 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?

Usage is implied through the resource ('给评价点赞') plus the prerequisite '需 confirm=true', giving the agent a gating condition. There is no explicit when-not guidance or named alternative among the many sibling review tools, leaving selection partly to inference.

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