classin-mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation3/5
Most tools target distinct resources, but there is overlap between legacy course classes (add_course_class) and newer classroom activities (create_classroom_activity), which are conceptually similar. The 'noclass' suffix in create_activity_noclass is also ambiguous. Descriptions help but the boundaries are not always crystal clear.
Naming Consistency4/5
All tools follow the classin_verb_noun pattern with consistent naming. Minor inconsistencies include plural/singular mismatches (add_class_students vs add_course_student) and the awkward noclass suffix, but overall the pattern is predictable.
Tool Count2/5
With 48 tools, the server is quite heavy, exceeding the 25-tool threshold. While the broad scope of the ClassIn platform justifies many operations, the sheer number makes it unwieldy for an agent to navigate.
Completeness2/5
The tool surface is heavily write-focused with very few read operations. There are no listing or retrieval tools for courses, classes, activities, students, or teachers, which means agents cannot query the current state. Lifecycle coverage also has gaps, such as no delete for school students or courses.
Average 3.7/5 across 48 of 48 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. However, the description adds no context about what destruction occurs, reversibility, permissions, or side effects. The only behavioral statement, '成功返回操作结果', is generic and doesn't clarify the actual outcome.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action. The parameter and return sections are compact but largely duplicate schema information, and the return line is vague. Still, it is efficiently structured with no unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a destructive operation with no output schema, the description is incomplete. It fails to explain the consequences of removing a teacher, error cases, or response structure. A generic 'success returns result' is insufficient for an agent to anticipate the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with more specific descriptions (e.g., courseId obtained from create-course API). The description merely repeats parameter names and minimal definitions, adding no additional meaning beyond the schema. The response_format parameter is omitted entirely from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '从课程中移除老师' (Remove teacher from course), a specific verb+resource action that unambiguously identifies the tool's purpose. It is distinct from sibling tools like classin_add_course_teacher or classin_delete_course_student.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives such as classin_stop_using_teacher or classin_edit_course. There is no context about prerequisites or exclusions, leaving the agent without criteria for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnly=false), idempotent (idempotent=true), and non-destructive (destructive=false). The description adds batch context and the 500-student limit, which is useful. However, it does not clarify behavior when re-adding existing students or response details beyond '成功返回操作结果', so it contributes only modest value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with a clear purpose statement and bulleted parameters. The '返回' section is vague but not wordy. It is well-structured and front-loaded, though the return description adds little value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no output schema, and the description's return statement is too vague to be actionable. It also fails to mention the response_format parameter, which controls output type. However, the schema provides good parameter coverage and annotations give safety context, so it is minimally adequate for a simple batch-add operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, including the response_format parameter which the description omits. The description simply repeats schema information for classId and studentUids without adding meaning (e.g., data types, examples, relationships). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: '向课节中批量添加学生' (batch add students to class section), with specific verb+resource. It distinguishes from siblings by explicitly mentioning '课节' (class period) rather than course/activity/school, but does not name alternatives, so it lacks strong sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus the many similar 'add_student' sibling tools (e.g., classin_add_activity_student, classin_add_course_student). There is no mention of prerequisites, exclusions, or alternative tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating, non-destructive, idempotent operation, so the description adds little beyond confirming it adds students. It does not disclose prerequisites, side effects, error conditions, or behavior when adding duplicate students. The generic '成功返回操作结果' adds no specific behavior detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct, with a clear purpose statement, parameter list, and return note. It is slightly redundant with the schema but remains free of fluff and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the schema is rich, but the description does not mention usage alternatives or error cases. It omits the response_format parameter behavior and does not explain the operation result. Adequate for a straightforward add operation but with gaps in guidance and edge-case transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema provides detailed parameter meanings (e.g., courseId obtained from create course API, identity enum values). The description merely restates the parameter names and minimal meanings, adding no significant value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds students or auditors to a course with the verb '添加' (add) and resource '课程' (course). It distinguishes from sibling tools like classin_delete_course_student and classin_add_activity_student by specifying the target resource as course rather than activity or deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives, no exclusions, and no context such as prerequisites. It simply states the action without explaining situations where this tool is appropriate or when to prefer a different tool like classin_add_activity_student.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and the description adds the explicit warning '删除后不可恢复' (irreversible after deletion), which elaborates on the destructive consequence. However, it does not disclose other behavioral aspects such as required permissions or side effects. The added value beyond annotations is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose. It includes a parameter list and return note, though these are partially redundant with the schema. Overall, it is concise and readable, but the redundant parameter list prevents a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation, the description covers the main purpose, irreversibility, and success return. However, it lacks information on error handling, prerequisites (e.g., the video must exist), and what '操作结果' actually contains. Since there is no output schema, this ambiguity is a notable gap, but the tool's simplicity keeps it from scoring lower.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with classId and videoId fully documented in the schema (including exclusiveMinimum and source for classId) and response_format having an enum and default. The description redundantly lists parameter names without adding any semantic detail beyond the schema, so it adds no value here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('删除单个课节的视频' – delete a single class's video) with a specific verb, resource, and scope. It distinguishes from siblings like classin_set_class_video (set) and classin_update_video_lock_status (update) by explicitly indicating deletion, though it does not explicitly compare with other delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description merely states what it does and the irreversibility, but does not mention prerequisites, exclusions, or when to prefer it over other delete tools. This is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the irreversibility of deletion ('删除后不可恢复'), which adds important behavioral context beyond the annotations' destructiveHint and readOnlyHint. However, it does not explain other behavioral aspects like permissions, side effects, or failure behavior, so the score is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with only two sentences plus parameter and return sections. It is well-structured and front-loaded with the core action. However, the parameter/return sections are redundant with the schema, and the description is extremely brief, making it slightly under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple delete operation with a single required parameter. The description covers the action and irreversibility, and the schema handles parameter details. However, it does not describe the return format or behavior on failure, and no output schema exists, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for both parameters, including classId's source ('通过创建课节接口获得') and response_format's default. The description only repeats 'classId: 课节ID' and adds no semantic value beyond the schema, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action '删除课节' (delete course class) and resource, and adds the key note '删除后不可恢复' (irreversible after deletion), which differentiates it from sibling delete tools like classin_delete_course_student. It provides a specific verb and resource, distinguishing itself effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 versus alternatives. It does not mention prerequisites, context, or why one would use this instead of other delete tools. It simply states the action and irreversibility, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the consequence 'course will become unavailable', which is useful context beyond the destructiveHint annotation. However, it does not mention reversibility, permissions, or effects on associated resources, so transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core action. It includes a redundant parameter list that duplicates schema information, but the overall length is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive tool with good annotations, the description adequately explains the purpose and key consequence. The return value is vaguely described, but given the simplicity, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no additional parameter semantics. The courseId is already explained in the schema, and response_format is fully documented there.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool ends a ClassIn course, using a specific verb and resource. It does not explicitly distinguish from sibling delete operations, but the wording 'end' and 'become unavailable' conveys a distinct action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as classin_delete_course or classin_edit_course. The description does not mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose that the operation is non-read-only, idempotent, and non-destructive. The description adds only '成功返回操作结果' (returns operation result on success), which is minimal and does not cover error behavior, permission needs, or overwrite semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very compact: a single purpose sentence, a short parameter list, and a return note. It is front-loaded and wastes no words, though the parameter section duplicates schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and annotations cover safety traits, but the description lacks usage guidance and fails to mention the configurable response_format. It is minimally viable for a rename operation but leaves gaps for an agent deciding among file-related siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for all parameters (100% coverage), so the baseline is 3. The description merely repeats the schema's parameter names and descriptions without adding additional meaning, and it omits the response_format parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: renaming a file in the cloud drive ('重命名云盘中的文件'). It uses a specific verb and resource, distinguishing it from sibling tools like rename_folder or delete_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description offers no context about prerequisites, exclusions, or comparison with rename_folder and other cloud operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds only '成功返回操作结果' (returns operation result on success), which is vague and does not disclose side effects, permission requirements, or error behavior. Minimal additional value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary action, followed by parameter and return sections. The structure is clean, though the parameter list is partially redundant with the schema, it does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool, the description covers the core operation and parameters but lacks usage context, error handling details, and clarification on how this tool relates to sibling label management tools. The absence of an output schema is partly mitigated by the vague return statement, but not fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all properties described in the schema. The description repeats labelId and labelName but adds no new meaning, and omits response_format. Baseline of 3 is appropriate when the schema carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '修改机构标签名称' (modify institution label name), using a specific verb and resource. It distinguishes from sibling tools like add_school_label and delete_school_label by specifying the modification of the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus adding or deleting labels. The description only lists parameters and return value, with no mention of prerequisites, alternatives, or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'move' and gives a generic success message. It does not disclose that moving is a state change that removes activities from the source unit and adds them to the target, nor any side effects or permissions required. The annotations (readOnlyHint=false, destructiveHint=false) provide minimal context, but the description adds little beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and structured with parameter and return sections. It avoids fluff, but it could be slightly improved by including the response_format parameter and providing a more informative return description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the vague '成功返回操作结果' is insufficient. The description does not explain the return format, potential errors, or behavioral details like whether activities are moved recursively or if ordering is preserved. It is a minimal description for a 4-parameter state-changing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well documented. The description lists only three of the four parameters and does not add any additional meaning beyond their names; the response_format parameter is omitted entirely. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: moving activities under a unit to another unit. It specifies the resource (activities in a unit) and the destination (other unit), distinguishing it from sibling tools like create/delete activities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the verb 'move' and the parameter structure, but there is no explicit guidance on when to use this tool versus alternatives or any prerequisites or exclusions. It does not mention, for example, that the target unit must exist or that this is for reorganizing content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as a non-read-only, idempotent, non-destructive operation. The description adds only that success returns an operation result, which is generic and adds minimal context beyond the annotations. No contradiction exists, but no additional behavioral nuance (e.g., side effects, permissions) 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the purpose. However, the parameter list duplicates schema information and the return line is vague, which slightly reduces value. Overall, it remains efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, but without an output schema, the vague return statement ('成功返回操作结果') leaves result structure unclear. The description also doesn't explicitly explain that changes apply globally, though '全局设置' hints at it. The description is adequate but leaves gaps about return values and scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all three parameters, including response_format. The description redundantly lists the two setting parameters but omits response_format, adding no new information beyond the schema. Since schema coverage is high, the correct baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '修改机构/学校的全局设置' (modify institution/school global settings), specifying a concrete verb and resource. It lists the two settable parameters, which distinguishes it from per-teacher or per-student edit tools like classin_edit_teacher. However, it doesn't explicitly contrast with alternative tools, so it falls short of the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for school-wide global settings but provides no explicit guidance on when to use this versus other edit tools (e.g., classin_edit_teacher, classin_edit_course). There are no exclusions or alternative suggestions, so it only meets the 'implied usage' bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
注解已声明非只读、非破坏且幂等，描述补充了关键前提（用户必须已注册）和返回结果，但未详细说明具体副作用、失败场景或权限要求。在注解基础上略有增益，但深度不足。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
描述结构紧凑，先说明主要功能，再列出参数和返回，易于快速理解。不过参数列表与schema冗余，但未造成臃肿，整体仍简洁高效。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
对于简单的添加操作，描述覆盖了核心行为、必要前提和返回结果，且注解和schema提供了额外的安全与参数信息。虽然没有输出schema或详细错误说明，但已足够支撑典型调用场景。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
输入schema覆盖100%，每个参数都有描述。描述中的参数说明基本与schema重复，未额外提供语义，如studentUid的特定格式或studentName的约束条件。因此保持基线3分。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述明确使用动词'添加'和资源'机构学生'，清晰表明功能是将已注册用户添加为机构学生。与兄弟工具（如添加课程学生、活动学生）能有效区分，因为指定了'机构学生'这一特定实体。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述仅说明操作本身，没有提供何时使用该工具、何时不使用或与替代工具（如classin_add_course_student）的对比。缺乏使用场景的指导，也没有排除不适用的情况。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructive and idempotent behavior. The description adds the batch size limit (max 500) and confirms the removal action. However, it does not describe side effects, error handling, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and well-structured with a purpose statement, parameter list, and return note. No wasted words, though it is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a destructive action, no output schema, and a vague return description ('操作结果'), leaving the agent uncertain about error handling and success details. Also, response_format is not mentioned in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three schema parameters have descriptions, so the description adds little beyond the schema. It reiterates classId and studentUids but omits response_format. The 500-limit is already in the schema, so no additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: batch removing students from a class session (课节). The verb '批量移除' and object '学生' plus context '课节' distinguish it from sibling tools like classin_delete_course_student or classin_delete_course_class.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for batch student removal but does not mention alternatives or when to prefer this over other deletion tools. No exclusions or preconditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate write, destructive, and idempotent behavior. The description adds that both students and auditors are removed and that an operation result is returned, but it does not elaborate on side effects, permissions, or reversibility. It provides minimal supplementary context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose, but it includes a parameter list that duplicates the schema. While not overly verbose, the redundancy prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation, the description covers the essential elements: purpose, parameters, and return behavior. The absence of an output schema is partially compensated by the return statement. It lacks usage context but is adequate given the tool's simplicity and the rich annotations and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters having descriptive text. The description merely repeats the parameter names and types without adding semantic depth, so it does not exceed the baseline established by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '从课程中移除学生或旁听' (remove students or auditors from a course), using a specific verb and resource. This differentiates it from sibling tools like adding students or deleting classes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives. It does not mention prerequisites, preferred contexts, or exclusions, leaving the agent without decision support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and idempotentHint=true, so the agent knows this is a non-destructive write operation. The description adds the partial-update behavior that only provided fields are modified. It does not address the openWorldHint=true annotation, leaving potential side effects undisclosed, and the return note '成功返回操作结果' is largely tautological.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a one-sentence purpose statement followed by a short parameter list and return note. It is well-structured and front-loaded, though the return statement '成功返回操作结果' adds little value. No redundant filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and an empty input schema, the description must supply all operational detail. It provides only courseId and activityId, leaving the actual editable fields unspecified as '其他参数可选'. For an update tool among many activity management siblings, this is insufficient for an agent to safely execute the tool or know what fields can be modified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, making the description the only source of parameter information. It lists courseId and activityId but does not specify their types, required status, or the full set of 'other parameters' that can be passed. The description partially compensates for the schema gap but leaves significant ambiguity about the actual updatable fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as '编辑LMS课堂活动信息' (edit LMS classroom activity information), using a specific verb ('编辑'/'edit') and resource ('课堂活动'/'classroom activity'). It distinguishes from sibling tools like classin_create_classroom_activity and classin_delete_activity through the explicit edit action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via '其他参数可选，只传需要修改的字段' (other parameters optional, pass only fields to modify), indicating partial update semantics. However, it does not explicitly state when to use this tool over alternatives or mention any exclusions, nor does it reference sibling create/delete tools for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already convey the key safety traits (readOnlyHint=false, destructiveHint=false). The description adds the return value (new folder ID) but does not disclose additional behavioral context such as required permissions, duplicate name handling, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose. The parameter list is clear but duplicates schema info and omits the third parameter, so it is not perfectly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, the description covers purpose, parameters, and return value. However, it ignores the response_format parameter and provides no context on where to obtain parentId or any operational prerequisites, leaving gaps for a smooth invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with descriptions for all parameters. The description restates parentId and folderName but omits the response_format parameter entirely, adding no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '在云盘中创建新文件夹' (create a new folder in cloud drive). It uses a specific verb plus resource and is easily distinguished from sibling tools like rename/delete/list folders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and description (create a folder when needed), but there is no explicit guidance on when to use this tool versus alternatives, nor any mention of prerequisites like obtaining parentId from folder list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true, aligning with the description's '编辑' (edit). The description adds the behavioral detail of partial updates ('只传需要修改的字段') and a vague success return, but it does not elaborate on effects on unmodified fields, error conditions, or permission requirements beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and well-structured with clear sections for parameters and return, and it front-loads the purpose. Every sentence contributes meaningful guidance without redundancy, making it easily scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, no output schema, mutation operation), the description is minimal. It relies heavily on the schema and a reference to another tool, leaving gaps such as return value structure, handling of omitted fields, and potential error scenarios. It is adequate but not rich enough for a fully self-contained understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% property description coverage, so the baseline is 3. The description adds value by clarifying that all parameters except courseId are optional and that only fields needing modification should be passed, which is not explicit in the schema. It also directs users to the create-course tool for parameter meanings, providing a useful cross-reference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '编辑ClassIn课程信息' (Edit ClassIn course information), which clearly identifies the action (edit) and resource (course). It is distinct from sibling tools that target other entities like teachers or folders, though it does not explicitly contrast with related course tools such as 'add_course' or 'end_course'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by saying '其他参数同创建课程，只传需要修改的字段' (other parameters same as creating course, only pass fields needing modification), which implies partial update semantics. However, it does not explicitly state when to use this tool versus alternatives like 'add_course' or 'edit_course_class', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false, covering the safety profile. The description adds the return value ('顶级文件夹ID' - top-level folder ID), but it does not disclose any additional behavioral traits such as authentication requirements, rate limits, or error scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short lines: the purpose sentence and the return value. It is front-loaded with the main action, and there is no redundant or extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, rich annotations, and simple single-parameter schema, the description adequately states what the tool does and what it returns. The only gap is the lack of usage guidance, but for a straightforward read-only getter, this is a minor omission. The description is complete enough for most selection scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single optional parameter 'response_format', and it is clearly described with a default value and enum. The description itself adds no extra information about parameters, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '获取' (get) with a clear resource '机构云盘' (organization cloud drive) and a specific target '顶级文件夹ID' (top-level folder ID). This distinguishes it from siblings like classin_get_folder_list, which retrieves folder lists, whereas this tool fetches a single top-level folder ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives. It does not mention any prerequisites, exclusions, or when-not-to-use conditions. The usage is only implied by the name and purpose, which is insufficient for an agent to make a selection decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read/write (readOnlyHint=false), idempotency, and destructiveness, so the description need not repeat those. It adds that only unitId is required and the other fields are optional, plus a success return, but does not describe side effects or response details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with its purpose, followed by a compact parameter list and return note. It could be slightly tighter by not repeating schema details, but there is no wasted or misleading content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters and no output schema, the description gives only a vague '成功返回操作结果' (returns operation result on success) and does not explain the response_format option or error behavior. However, the rich schema and annotations fill in many gaps, making it minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's parameter list mostly repeats schema information (unitId, name, content, publishFlag) and adds 'optional' labels, but it does not provide extra semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '编辑LMS学习单元信息' (Edit LMS unit information), a specific verb and resource that clearly states the tool's function. It is distinct from sibling tools such as classin_create_unit and classin_delete_unit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for modifying an existing LMS unit, but it does not explicitly state when to use it versus creating or deleting a unit. No alternative tools or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare non-read-only, non-destructive, and idempotent behavior, which the description aligns with by presenting update semantics. The description adds that fields are replacements ('新的'), but does not disclose whether omitted fields are left unchanged or cleared, nor any authentication or side-effect details beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: a one-sentence purpose, a bulleted parameter list, and a return line. Each element serves a clear function with no redundant or filler content, making it easy to scan and quickly understand the tool's interface.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the return line '成功返回操作结果' is vague and does not detail the response format. The description lists all editable parameters but omits behavior on partial updates or field validation. However, the extensive schema descriptions and safety annotations compensate for some of these gaps, making the tool minimally complete for straightforward use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already provides 100% coverage with descriptions for all parameters. The description restates parameters in Chinese and adds the '新的' prefix to clarify replacement semantics, but this is minimal additional meaning over the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '修改课节信息' (modify course class information) and enumerates all editable fields with 'new' values, making the tool's purpose specific and distinct from sibling add/delete/rename operations. It is unambiguous that this edits an existing course class.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb '修改' implies editing an existing class, and sibling tools provide alternatives like add and delete. However, there is no explicit statement about when to use this tool versus others, nor any mention of prerequisites or excluded scenarios, leaving the guidance merely 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnly=false and destructive=true, so the description doesn't contradict them. However, it adds no additional behavioral context beyond the fact that it modifies a password, such as permission requirements or side effects. Given the annotations, a neutral score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, starting with a clear purpose statement, followed by a well-structured parameter list and a brief return note. It is concise without unnecessary fluff, but the line breaks and formatting could be improved for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential parameters and return value, but it omits failure behavior, required vs optional parameters, and any permission or error handling details. Since there is no output schema, the description should be more comprehensive, but it is adequate for a simple modification tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), so the description carries the full burden of explaining parameters. It does so clearly: uid, password (6-20 plaintext), and md5pass (32 MD5), with the mutual exclusivity constraint. This is far beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '修改ClassIn用户密码' (Modify ClassIn user password). This is a specific verb+resource pairing that distinguishes it from sibling tools focused on folders, files, courses, and user management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives, such as classin_register_user or classin_edit_teacher, nor does it mention any preconditions or exclusions. It simply lists parameters without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the operation is not read-only (readOnlyHint=false), not destructive (destructiveHint=false), and idempotent (idempotentHint=true). The description adds the basic behavior of renaming a folder and mentions a successful return, but no additional behavioral context such as effects on contents or failure cases. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured with a clear purpose, a parameter list, and a return note. However, the parameter list largely duplicates the schema, and the return statement '成功返回操作结果' is vague, slightly limiting the efficiency of the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (rename folder, few parameters), annotations provide safety context, and the schema fully documents parameters. The description covers the core operation and basic return behavior. It lacks usage guidance and detailed error/response semantics, but the tool's low complexity makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of parameter descriptions, including folderId and folderName. The description repeats these definitions without adding extra meaning, and it omits the response_format parameter entirely. Baseline of 3 is appropriate since the schema already carries the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '重命名云盘中的文件夹' (rename folders in cloud drive), providing a specific verb and resource. This distinguishes it from sibling tools like classin_rename_file and classin_create_folder/delete_folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage solely from the rename operation and sibling names, but it does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria. Usage is implied by the operation itself, meeting the 'implied usage' benchmark.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, and the description does not contradict them. The description adds the prerequisite that the user must be registered and notes a post-usage capability, but it does not disclose details about error handling, idempotency effects, or side effects beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear purpose statement, a brief parameter list, and a return note. It is front-loaded with the main action and avoids unnecessary filler. The parameter list is slightly redundant but not excessive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple add operation with no output schema, the description covers the purpose, key parameters, and return. It also provides useful context about the registered-user prerequisite and the post-condition of being able to assign the user as a teacher. It does not detail the return structure or error cases, but given the tool's simplicity, the level of completeness is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions (100% coverage), so the schema carries the parameter documentation burden. The description repeats teacherUid and teacherName but omits response_format despite it being a schema parameter, and it does not add substantial meaning beyond the schema. The baseline of 3 for high schema coverage is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '将已注册用户添加为机构老师' (add a registered user as an organization teacher), specifying the verb, resource, and target role. It also explains that after adding, the user can be assigned as a teacher in courses, distinguishing it from sibling tools like edit_teacher or stop_using_teacher.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when a registered user needs to become a teacher) and provides a post-condition (can be assigned in courses). However, it does not explicitly state when not to use it or mention alternatives among sibling tools, such as using classin_register_user to create a new user first or classin_edit_teacher to modify existing teacher details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the description's 'Remove' aligns with that. The description adds the return value ('success returns operation result'), but does not detail side effects (e.g., irreversible nature, impact on grades, or authorization requirements). With annotations covering the safety profile, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main purpose. The parameter list is neatly structured and the return note is brief. No extraneous text. The only minor flaw is the slightly awkward 'studentUids/studentUid' notation, but overall it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does explain the return value generically as 'operation result,' which is vague. It does not mention error cases, prerequisites, or whether the action is reversible, but the destructive hint covers some of this. The parameter list compensates for the empty schema, but the overall guidance is minimal for a deletion tool of this scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), so the description carries the full burden of documenting parameters. It lists courseId, activityId, and studentUids/studentUid with brief explanations, including note that studentUids can be a list or single UID. This adds essential meaning beyond the schema, though it lacks explicit types or required flags.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Remove students from LMS activity.' This is a specific verb+resource formulation that distinguishes it from siblings like classin_add_activity_student (which adds students) and classin_delete_activity (which removes the entire activity). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its main sentence—one should use this tool when removing students from an activity. However, it does not explicitly mention when not to use it or suggest alternatives like classin_add_activity_student for the reverse operation. The context is clear but lacks explicit exclusionary or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-destructive, idempotent write operation. The description adds the fact that the operation edits only the name field and returns an operation result on success. It does not disclose potential failure modes or side effects, but for a simple edit, the added context is modest yet useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single line stating the purpose, followed by a brief parameter list and return note. Every sentence earns its place, and there is no redundant text. It is well-structured and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of a complete input schema, the description covers the essential aspects: what it edits, the required parameters, and the general return behavior. There is no output schema, but the return note suffices. It lacks only deeper details like error conditions, which are not critical for this simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all parameters with 100% coverage. The description repeats the parameter meanings (teacherUid, teacherName) without adding extra semantics like formats, constraints, or relationships. It does not go beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool '编辑机构老师信息（姓名）' (edit institution teacher information (name)), specifying the verb 'edit', the resource 'institution teacher', and the specific field 'name'. This clearly distinguishes it from sibling tools like add_teacher, stop_using_teacher, and restart_using_teacher.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly discuss when to use this tool versus alternatives. However, the purpose is clear enough that the intended usage (editing an existing teacher's name) is implied. There are no exclusions or alternative recommendations, so it falls short of providing explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds the return type (file/folder list) but no additional behavioral details like pagination, sorting, or potential errors. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, structured with sections for parameters and returns, and contains no redundant language. Every line adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with good annotations and full schema coverage, the description is adequate. It does not detail return format structure or pagination, but these are not critical for this simple tool. The response_format parameter is covered by schema, so the missing mention is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters (folderId and response_format). The description mentions folderId but not response_format. It explains folderId is the folder ID, but the schema already provides that. Baseline 3 is appropriate as schema carries the parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves files and folders under a specified folder, using a specific verb and resource. It distinguishes from sibling tools like classin_get_folder_list by explicitly mentioning file and folder list within a folder context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context of what the tool does but does not explicitly state when to use it versus alternatives like classin_get_folder_list or classin_get_top_folder_id. Usage is implied rather than directly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond annotations by stating that the operation makes activities visible to students. This is a concrete side effect not captured by the readOnlyHint or destructiveHint flags. It does not describe every potential consequence, but the idempotentHint and non-destructive annotation lower the bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with a clear opening sentence followed by parameter and return sections. It is front-loaded with the purpose, and the extra '返回' line is generic but not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple publish operation, the description covers purpose, parameters, and return value. However, it lacks usage guidance, prerequisites, and error behavior. The mismatch between an empty input schema and listed parameters could also confuse an agent relying on the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so the description carries the full burden of parameter documentation. It lists courseId and activityId/activityIds, explains their meaning, and notes that activity IDs can be a single value or list. This is helpful, though it lacks details like types and required status.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action '发布LMS活动' (release LMS activity) and its effect '使其对学生可见' (make it visible to students). This distinguishes it from sibling tools like create, update, or delete activities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives such as classin_create_activity_noclass or classin_update_classroom_activity. There are no prerequisites, exclusions, or examples of appropriate use contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds the key constraint about ended classes, which is useful behavioral context. However, it does not disclose what happens on partial failure (e.g., some classIds invalid) or whether existing settings are overwritten, so it adds moderate context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear opening statement, a prominent caveat, a param list, and a return statement. It is not overly long, and the note is front-loaded. However, the parameter list largely duplicates schema descriptions, which slightly reduces efficiency and 'earned space'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should clarify return values, but it only states '成功返回操作结果' (returns operation result on success), which is vague. It also omits behavior on invalid inputs or partial failures. Given the annotations cover idempotency and non-destructiveness, the description is adequate but leaves gaps in error/response semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description repeats parameter meanings already present in the schema (e.g., 0=关闭, 1=开启) without adding new semantic details. The only added value is the note about ended classes applying to classIds, but this is minor. Thus, the description does not significantly enhance the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('设置' - set) and specific resource ('课节' - class/lesson) with the options for recording, live streaming, and playback. This distinguishes it from sibling tools like classin_delete_class_video or classin_update_video_lock_status, which handle different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a specific usage constraint: '已结束的课节不能设置录课、直播等功能' (ended classes cannot be set). This provides clear context for when the tool is applicable. It doesn't explicitly name alternatives, but the batch-setting purpose is clear from the title and description, making it easy to differentiate from single-action siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds one useful behavioral detail: the teacher cannot be assigned as a course teacher after disabling. However, it does not disclose what happens to existing course assignments, whether the operation is reversible, or error behavior, which would be valuable for a destructive idempotent operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line purpose, a sentence describing the effect, a parameter list, and a return note. No unnecessary content exists, and the main verb is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter, the description covers the core API: purpose, effect, parameter, and return. However, it leaves ambiguity around the impact on existing course assignments and behavior when already disabled, which is relevant for a destructive, idempotent operation. Overall, it's nearly complete but missing a couple of behavioral nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for both parameters, including descriptions. The description repeats the teacherUid definition but adds no new semantics beyond what the schema provides, such as where to find the UID or any format constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: '停用机构老师' (disable institution teacher). It further clarifies the effect: '停用后该老师无法被指定为课程老师' (after disabling, the teacher cannot be assigned as a course teacher). This distinguishes it from sibling tools like 'classin_restart_using_teacher'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (disable a teacher so they can't be assigned to courses) but does not explicitly mention when to use this tool versus alternatives such as 'classin_restart_using_teacher' or 'classin_edit_teacher'. There are no explicit exclusions or prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as non-readonly, idempotent, and non-destructive. The description adds the behavioral consequence that locking prevents deletion, which provides meaningful context beyond what annotations convey. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and organized into parameter and return sections. It includes the key behavioral note without unnecessary fluff, though the parameter list duplicates schema content, which slightly reduces efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description covers the effect, parameters, and a return statement. However, the return description ('操作结果') is vague, and without an output schema, it doesn't explain the result structure or possible error cases. Some prerequisite context (e.g., classId source) is present in the schema but not reinforced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter is documented in the input schema. The description restates the same parameter meanings without adding extra semantic detail or format guidance, so it does not compensate further beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool modifies the lock status of a class video and explains the consequence (locked videos cannot be deleted). This distinguishes it from sibling tools like classin_delete_class_video, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to prevent video deletion) but does not explicitly state when not to use it or mention alternatives. It lacks direct comparison with sibling tools, so 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false, destructiveHint=false). The description adds useful context such as the required parameters, constraints (e.g., className 1-90 characters, seatNum 0-50 default 6), and the return value (class ID). It does not disclose potential side effects, permission requirements, or error behavior, but given annotation coverage, the additional details are reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief purpose statement followed by a parameter list and return value. Every line provides necessary information without redundancy. It is appropriately sized for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the empty schema and absence of an output schema, the description provides the essential information: purpose, all parameters, and return value. However, it lacks guidance on error handling, permissions, or when to use alternative tools, which would make it fully complete. Annotations cover safety traits, so the 4 reflects the strong parameter/return coverage but missing usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 properties), so the description carries full responsibility for parameter documentation. It lists all 7 parameters with names, required flags, constraints, and default values (e.g., seatNum default 6). This far exceeds the baseline for 0-param schemas, providing comprehensive semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '在课程下创建课节（单课）' which means 'Create a course session (single lesson) under a course.' This uses a specific verb (创建/create) and a specific resource (课节/course session), and differentiates from siblings like edit_course_class or delete_course_class by explicitly indicating creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention related operations like editing or deleting course sessions, nor does it specify prerequisites or conflict scenarios. The usage is only implied by the tool's name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructive=true, but the description adds the critical context '删除后不可恢复' (irreversible after deletion), which goes beyond the annotation. This warns about an important behavioral consequence and does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening sentence is front-loaded with purpose and key warning. The subsequent parameter list is somewhat redundant with the schema, but it is brief and does not bloat the description. Overall, it is compact and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With strong annotations and complete schema, the description covers the essential context: what it deletes, irreversibility, and success return. It does not explain side effects on related data or prerequisites, but for a simple delete tool this is likely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already defines courseId, activityId, and response_format. The description only repeats courseId and activityId without adding new meaning, and omits response_format entirely. Baseline 3 is appropriate since the schema carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '删除LMS活动' (Delete LMS activity), using a specific verb and resource. This distinguishes it from sibling delete tools like delete_folder or delete_file, which target different object types. 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the delete verb and activity resource: use this when deleting an LMS activity. However, no explicit when-not-to-use or alternative tools are mentioned. The irreversibility warning is present but not framed as a decision guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds the irreversible nature ('删除后不可恢复'), which is valuable behavioral context beyond the annotations. It also notes a return result, though vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action, but it repeats parameter information already in the schema, which is mildly redundant. Still, every sentence serves a purpose, including the irreversibility warning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with annotations covering safety and a fully described schema, the description is adequate. It covers the action, irreversibility, and indicates a return value, though it omits details like recursive deletion or permissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full 100% description coverage for both folderId and response_format, so the baseline is 3. The description merely repeats the folderId description without adding new semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '删除云盘中的文件夹' (delete folder in cloud drive), specifying the action and resource. It distinguishes from sibling tools like classin_delete_file and classin_create_folder by targeting folders specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided beyond the basic action; usage is implied by the tool name and description. It does not mention exclusions or when to prefer sibling tools such as classin_delete_file.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states that deletion cannot be recovered, which adds meaningful context beyond the destructiveHint annotation. It also mentions a return result on success, though it does not detail error handling or side effects. This does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and well-structured with a clear purpose statement followed by parameters and return sections. It is front-loaded, though it duplicates parameter information already in the schema, making it slightly redundant but still concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one required parameter, the description provides the core purpose and the key warning of irreversibility. It lacks explicit error handling details and does not describe the exact return format, but given the simplicity and available annotations, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists labelId with the same wording as the schema, adding no new meaning. Schema coverage is 100%, so the baseline is 3; the description does not compensate or add nuance for either parameter, including response_format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states '删除机构标签' (delete institution label), using a specific verb and resource, and distinguishes it from sibling tools like add_school_label or update_school_label by clearly indicating deletion. The irreversibility note further clarifies the intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when deleting a label) but does not explicitly contrast it with alternatives such as add or update school label. No exclusions or prerequisites are mentioned, leaving usage guidance mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 well-covered. The description adds behavioral context beyond annotations by clarifying that omitting classId returns the course live address, and by disclosing the return value is a player URL. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with a clear purpose statement, parameter list, and return description. Each section earns its place, though the parameter details duplicate the schema descriptions, creating minor redundancy. Overall it is efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with strong annotations and no output schema, the description is complete enough: it states the return type (播放器URL) and covers parameter semantics. It does not elaborate on potential URL expiry or auth requirements, but these are not critical for safe invocation given the readOnlyHint and simple contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters, including the optional nature of classId and the response_format enum, yielding 100% schema coverage. The description repeats this information without adding new semantics or usage details, so it adds no value beyond what the schema already supplies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '获取课程或课节的直播/回放播放器地址' (get live/replay player URL for a course or class), specifying both the verb and the resource. It distinguishes itself from sibling tools (which are mostly mutations or other getters for different resources) by naming the specific entity being fetched.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the optional classId behavior ('不传则获取课程直播地址'), giving implicit guidance on when to use the course-level vs class-level functionality. However, it does not explicitly state when to prefer this tool over other sibling getters (e.g., classin_get_cloud_list) or provide alternative scenarios, relying on the agent to infer from the resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating, idempotent operation. The description adds that it targets previously disabled teachers but does not disclose potential side effects, failure behavior, or permission requirements. It is consistent with annotations, so no contradiction, but the added behavioral context is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise and front-loaded with the purpose. The parameter list is somewhat redundant with the schema, but the return-value sentence adds a small amount of information. Overall, it is efficiently structured without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (two parameters, no output schema) and the presence of annotations covering idempotency, the description covers the essential purpose and parameter. The return description is vague ('操作结果'), but this is acceptable because no output schema exists and the operation is simple. It could mention prerequisites or edge cases, but current completeness is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for both parameters (teacherUid and response_format) with 100% coverage. The description simply repeats the teacherUid description and does not add extra meaning or context beyond what the schema 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '重新启用' (re-enable) and the resource '机构老师' (institution teacher), specifying it operates on previously disabled teachers. This directly distinguishes it from the sibling tool 'classin_stop_using_teacher', which disables a teacher.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a disabled teacher needs to be reactivated, providing clear context. However, it does not explicitly mention when not to use it or name alternative tools, though the purpose itself differentiates it from the opposite action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the description does not need to restate those. It adds minimal behavioral context beyond the return value ('成功返回操作结果') but does not mention idempotency, side effects, or permission 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized, listing parameters and return value in a clear, scannable format. Every sentence adds useful information without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple add-student operation, the description covers the core action and parameters, but lacks details on required vs. optional parameters, error conditions, and the exact structure of the returned result. The absence of an output schema increases the need for such information, making this only minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 properties), so the description is the only source of parameter information. It clearly defines courseId, activityId, and studentUids/studentUid, including that the latter accepts a list or a single UID. This fully compensates for the absent schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool adds students to an LMS activity ('向LMS活动添加学生'), using a specific verb and resource. It also lists the key parameters, distinguishing it from sibling tools like classin_delete_activity_student or classin_add_course_student.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose makes the primary use case clear, but there is no explicit guidance on when to choose this tool over alternatives (e.g., classin_add_course_student vs. classin_add_activity_student) or any exclusions. Usage context is implied rather than directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description adds the prerequisite that the teacher must already be an institution teacher, which is useful, but it does not disclose side effects, error behavior, or failure modes beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single action sentence followed by a compact parameter list and a return note. There is no fluff, and the core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple write operation with three well-described parameters and no output schema, the description covers the core purpose, prerequisite, and a generic return message. It could specify the return format in more detail, but it remains sufficient for the task's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for all parameters (100% coverage). The description repeats the parameter names and adds minimal extra context for teacherUid ('需要先添加为机构老师'), so it contributes little beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states '向课程中添加老师' (Add teacher to course), which clearly identifies the verb 'add' and the resource 'course teacher'. This differentiates it from siblings like classin_remove_course_teacher and classin_add_teacher.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite: '需要先添加为机构老师' (teacher must first be added as an institution teacher), implying usage after classin_add_teacher. It gives context for when to use the tool, though it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it is a write operation (readOnlyHint=false) and non-idempotent. The description adds the return behavior (returns label ID on success) but does not disclose side effects, permission requirements, or error conditions. This adds some value but not substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, a bullet list of parameters, and a return note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool, the description covers purpose, parameters, and return value. The optional response_format is documented in the schema, so its omission is not critical. However, it lacks guidance on when to use vs. updating labels, which would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. The description repeats labelName and labelType details but adds no new meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a school label ('创建机构标签') and explains its purpose for classifying teachers or students. The verb '创建' (create) distinguishes it from sibling update/delete label tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool to create a label for categorizing teachers/students. However, it does not explicitly mention when not to use it or point to alternatives like update_school_label or delete_school_label.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false). The description adds valuable context: it uses API v2, enforces uniqueness of unit names under a course, and returns the unit ID on success. These details go beyond the annotation hints and help set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The key information is front-loaded (purpose and unique constraint), but the '参数' section redundantly restates the schema details for every parameter. This makes the description longer than necessary and reduces conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema, and the description covers the essential aspects: creation context, uniqueness constraint, return value, and the publishFlag semantics. It does not explain error behavior or response format details, but the schema covers all parameters, so the overall picture is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description's parameter list largely repeats the schema definitions without adding new meaning. The only added context is the API v2 note, which is not parameter-specific, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '在课程下创建LMS学习单元' (create LMS unit under course), using a specific verb and resource. This distinguishes it from sibling tools like update_unit and delete_unit, which modify or remove units.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (creating a unit under a course) and includes a constraint (no same-name units under a course). However, it does not explicitly mention alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the irreversibility warning '删除后不可恢复' (cannot be recovered after deletion), which goes beyond the destructiveHint annotation. This is valuable behavioral context for an AI agent. It does not mention other side effects or requirements, but the annotations already cover the destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point. The first sentence front-loads the purpose, followed by a clear warning and a simple parameter/return listing. Every sentence earns its place without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential information: the purpose, irreversibility, the key parameter, and that a result is returned. However, the return description '成功返回操作结果' (on success returns operation result) is vague and does not specify the structure or content of the result. Since there is no output schema, a bit more detail would improve completeness, but the simplicity of the delete operation makes this adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning the schema already fully documents the parameters. The description restates the unitId parameter without adding new meaning. It does not mention the response_format parameter, but that is already covered in the schema. No additional semantic value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '删除LMS学习单元' (delete LMS learning unit). It uses a specific verb and resource, distinguishing it from sibling tools that delete other resource types like folders, files, or activities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for deleting LMS units but provides no explicit when-to-use vs. when-not-to-use guidance. It does not mention alternatives or scenarios where a different delete tool would be more appropriate, so usage is only implied by the resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write (readOnlyHint=false), non-destructive, idempotent operation. The description adds that it returns an operation result but gives no further behavioral details like error handling or side effects. With annotations covering the safety profile, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line purpose, a bulleted parameter list, and a return statement. No unnecessary words or redundancy, earning its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple edit operation with comprehensive schema and annotations, the description covers the essential purpose, parameters, and return. It does not mention prerequisites or error scenarios, but given the tool's simplicity and existing structured data, the description is sufficiently complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, describing studentUid, studentName, and response_format in detail. The description's parameter list essentially repeats the schema information without adding new meaning, so it meets the baseline but does not go beyond.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Edit school student information (name)' with a specific verb and resource. It distinguishes from siblings like add_school_student and delete_course_student by focusing on editing an existing student's name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear this tool is for editing a school student's name, which implies the appropriate context. However, it does not explicitly mention when not to use it or point to alternative tools for other operations, so it lacks explicit exclusions but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive nature. The description adds behavioral context beyond annotations: it limits the list to folders, restricts to two levels under root, and specifies the returned fields (folder ID, parent ID, name). This helps the agent set expectations without needing an 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences. The main action is in the first sentence, and the return structure is in the second. Every word contributes to understanding the tool's purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one optional parameter, the description covers the purpose, scope, and return fields. Since there is no output schema, the return description is valuable. Minor gaps like pagination or ordering are not critical for this tool's typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the only parameter 'response_format' fully described in the schema. The description does not add parameter-specific guidance, but the schema already handles parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '获取' (get) and resource '机构云盘根目录下两级的文件夹列表', specifying exactly what it retrieves. It distinguishes from sibling tools by adding the two-level depth under root, which is not present in generic cloud list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the explicit scope '根目录下两级', but it does not provide explicit when-to-use guidance or name alternatives like classin_get_cloud_list. The agent must infer when this tool is the correct choice based on the folder-depth constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false, destructiveHint=false). The description adds valuable behavioral context: it states the return value (course ID), explains the idempotency protection via courseUniqueIdentity, and clarifies parameter effects like mainTeacherUid's management role. No contradictions 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief intro, a bullet-style parameter list, and a return statement. It is appropriately sized for 11 parameters, and every part is relevant, though the parameter list partially duplicates schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, 1 required) and lack of an output schema, the description covers the return value, parameter semantics, and the conceptual role of a course. It doesn't mention authorization needs or error cases, but the provided info is sufficient for an agent to make a successful call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema already provides full parameter coverage (100%), the description adds semantic value by explaining subjectId categories (0:空, 1:语文, 2:数学...) and clarifying expiryTime's default behavior. This goes beyond the schema's terse descriptions and aids correct parameter selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '创建ClassIn课程' (create a ClassIn course) and defines a course as a container for class sessions, which distinguishes it from sibling tools like adding students to courses or editing courses. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (to create a course) but does not explicitly specify when to use this tool versus alternatives like classin_edit_course or classin_end_course. There are no explicit exclusions or prerequisites, so it provides clear context without direct alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the description is not required to restate those. The description adds the return behavior (returns activity ID on success) and the optional timestamps, but it does not disclose potential side effects, such as duplicate creation on repeated calls, beyond what annotations imply. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-sentence purpose followed by a structured parameter list and a return-value note. Every line is informative and necessary, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a complete picture for creating an activity: purpose, parameters with types and optional markers, and the return value. It is sufficient for an agent to select and invoke the tool, though it doesn't explicitly list which parameters are required (implied by optional markers) or error conditions, which would be nice but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description is the sole source of parameter information. It lists all 7 parameters with clear descriptions and explicit enum values for activityType, and marks startTime/endTime as optional. This fully compensates for the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates non-classroom activities (homework, quiz, recorded course, etc.) under an LMS unit, using a specific verb '创建' and resource '非课堂活动'. It distinguishes from sibling 'classin_create_classroom_activity' by explicitly mentioning '非课堂' (non-classroom) and the LMS unit context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('在LMS单元下创建非课堂活动') and the list of activity types gives some idea of when to use it. However, it does not explicitly state when to prefer this over alternatives like classin_create_classroom_activity, nor does it mention any exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds irreversibility ('删除后不可恢复') beyond the destructiveHint annotation, and also mentions the return of an operation result. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, with the core action and consequence in the first sentence, followed by a short parameter list. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete-by-ID operation, the description covers the action, irreversibility, and mentions a result. It does not elaborate on error handling or output structure, but annotations and schema cover safety and parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (100% coverage); the description repeats fileId but adds no new semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '删除云盘中的文件' (delete files in cloud drive) with a specific verb and resource, distinguishing it from sibling file operations like rename or folder delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly mention alternatives or exclusions, but the purpose is clear enough that an agent would know when to invoke it for file deletion rather than folder deletion or renaming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a write, idempotent, non-destructive operation, and the description goes beyond this by explaining the exact transformation: it replaces group nicknames (defaulted to user nicknames) with the institution backend's 'student name'. It also discloses the effect on IM group and classroom displays, adding useful behavioral context without contradicting any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (功能说明, 使用场景, 参数, 返回), front-loaded with the primary purpose. Every sentence contributes meaningful context without redundancy, and the length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool, the description provides thorough context: how class groups are created, why this modification is needed, when to invoke it, and what is affected. The return value is vaguely described as '成功返回操作结果', but given the lack of an output schema and the simplicity of the operation, this is not a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with detailed descriptions for both courseId and response_format. The tool description's parameter section only repeats 'courseId: 课程ID', adding little beyond the schema, though the functional explanation helps clarify the course-group relationship. Baseline 3 is appropriate since the schema carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '批量修改课程班级群中所有学生和旁听生的班级昵称' (batch modify class nicknames for all students and auditors in a course class group). It uses a specific verb (modify), identifies the resource (class group member nicknames), and defines the scope (all students and auditors), which distinguishes it from other modify tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a dedicated '使用场景' (usage scenario) section explaining when to use the tool: to resolve mismatches when students change their user nicknames in ClassIn, and recommends calling it after creating a course and adding students/auditors. This provides clear context, though it does not explicitly mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false, destructiveHint=false). The description adds that a successful call returns an activity ID, which is useful. However, it does not disclose permissions, failure modes, or side effects beyond creation, so it only partially augments the annotation-provided safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose statement first, followed by an important note, a clear parameter list, and return value. Every sentence adds value, and the parameter formatting is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with no output schema, the description covers the core need: what it creates, key parameters, and the return value. It lacks error-condition details and explicit permission requirements, but given the annotation context and sibling tool set, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so the description carries the full burden for parameter documentation. It lists all seven parameters with meanings, optionality (unitId), types (timestamps in seconds), and default values (seatNum=7), providing complete semantic context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a classroom activity under an LMS unit, using the verb '创建' (create) and a specific resource. The note about classroom being an upgraded version of 课节 and the sibling tool 'classin_create_activity_noclass' help distinguish this from similar create operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes the recommendation to use classroom over lesson for new integrations, providing context for when this tool is appropriate. It also explains optional parameters (unitId) and defaults, though it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral detail beyond annotations: success returns a user UID, and if the phone/email is already registered, it returns error codes 135/461 while still returning the existing user's UID. It also mandates consent before invocation. This is consistent with annotations (readOnlyHint=false) and provides concrete outcomes not available elsewhere.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a bolded warning, bulleted parameters, and a return-value section. Each line provides essential information without redundancy. It is appropriately sized for the complexity of the operation and front-loads the purpose and critical consent requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the empty input schema and lack of output schema, the description fully covers parameters, return behavior, error handling, and prerequisites. It explains the 'already registered' scenario and return of existing UID, making the tool's behavior predictable. No critical gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty ({}), so the description is the sole source of parameter documentation. It lists all parameters with formats (telephone formats, password length 6-20, md5pass 32 chars), mutual exclusivity constraints, and exact enum meanings for addToSchoolMember. This is exceptionally thorough and compensates entirely for the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '注册ClassIn用户账号。为机构的用户代注册ClassIn账号。' (Register a ClassIn user account. Register on behalf of institution users). It uses a specific verb (register) and resource (user account), and clearly differentiates from sibling tools like classin_add_teacher or classin_add_school_student, which handle specific user types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite (consent from the phone/email user) and explains parameter selection rules (telephone/email mutual exclusivity, password/md5pass mutual exclusivity, addToSchoolMember enum values). It gives context on when to use the tool, though it does not explicitly name alternatives or exclusion conditions relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![classin-mcp-server MCP server](https://glama.ai/mcp/servers/yuanlang12/classin-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/yuanlang12/classin-mcp-server)

Score Badge

Copy to your README.md:

[![classin-mcp-server MCP server](https://glama.ai/mcp/servers/yuanlang12/classin-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/yuanlang12/classin-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/yuanlang12/classin-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server